clang++ optimizer causes std::bad_alloc in boost::unordered_set<>::insert

[llvmbot]

Bugzilla Link	9640
Resolution	WORKSFORME
Resolved on	Mar 17, 2012 18:14
Version	2.8
OS	Linux
Attachments	C++ code to show misoptimization causing std::bad_alloc
Reporter	LLVM Bugzilla Contributor
CC	@asl,@DougGregor,@tkremenek

Extended Description

clang version 2.8 (branches/release_28)
Target: i386-pc-linux-gnu
Thread model: posix

LSB Version: core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-ia32:core-3.2-ia32:core-4.0-ia32:desktop-4.0-ia32:desktop-4.0-noarch:graphics-2.0-ia32:graphics-2.0-noarch:graphics-3.2-ia32:graphics-3.2-noarch:graphics-4.0-ia32:graphics-4.0-noarch
Distributor ID: SUSE LINUX
Description: openSUSE 11.4 (i586)
Release: 11.4
Codename: Celadon

boost-devel-1.44.0-5.1.i586

Greetings,

the attached program works OK when compiled with g++ 4.5:

copying tokens to capabilities
token FOO
token BAR
token BAZ
IMAPCapa::IMAPCapa(const std::string &) completed

but barfs when compiled with clang++ 2.8:

$ clang++ -Wall -pedantic-errors -Wextra -g -O -fexceptions -march=athlon-xp -o break break.cpp
$ ./break
copying tokens to capabilities
token FOO
caught std::bad_alloc

Apparently clang version 2.9 (trunk 116146) Target: x86_64-unknown-linux-gnu and libboost1.40-dev (Ubuntu 10.10) fares better (and succeeds like g++ 4.5 does).

[asl]

So, you're saying that this problem does not exist in clang 2.9 ?

[llvmbot]

I've tried clang 2.8 on Ubuntu 10.10 amd64/x86_64 with boost 1.42 and with coerced -m32, also tests successfully.

So open questions are if it's

• the boost version
• that I'm running on openSUSE rather than Ubuntu

[tkremenek]

cloned to rdar://problem/9249674

[llvmbot]

Same problem on openSUSE 11.4 i586 with

clang version 2.9 (tags/RELEASE_29/final)
Target: i386-pc-linux-gnu
Thread model: posix

[DougGregor]

Can you provide preprocessed output (generated with -E), so we can test what you're testing?

Also, do you still see the problem with Clang 2.9? 2.8 is extremely old, and we've fixed a huge number of bugs since then.

[DougGregor]

Haven't been able to reproduce this for nearly a year.