[PR42535, fixed in 4.5] -fschedule-insns crashes g++

Binary package hint: gcc-4.4

g++ crashes when -fschedule-insns is activated, possibly because of other optimization options.

brief foreword:

if -O2 or -O3 is specified, while using boost::interprocess (1.40.0), pthread_mutex_unlock fails with EPERM in boost/.../interprocess_recursive_mutex.hpp:107 upon calling -- in my project -- managed_shared_memory::find. but everything's fine with -O1 or the default -O0! extrapolating the offending code into a clean project, however, works seamlessly with both -O2 and -O3. NO crashes on g++ here, just a run-time assertion failure that I rooted to the EPERM failure.

details:

I thus tried to specify on my Makefile's CPPFLAGS the flag -O1 and I then added all the optimization switches triggered by -O2 and -O3, as specified by "man gcc". curiously enough, they crashed g++ on compiling the problematic module above (everything's ok with the other project's sources). checking by hand, I found out that simply removing -fschedule-insns both avoid the g++ crash AND solves my mutex problem.

note that something like -O3 -fno-schedule-insns won't give any crash on g++ side, but will yield the described mutex problem.

I'm a bit confused about these strange behaviors (why specifying the switches triggered by -O2 or -O3 is different than actually having -O2 or -O3? why a run-time error depending on the optimization level, but not when the same code is compiled alone elsewhere?), but I hope they can be meaningful for improving gcc.

(I believe the preprocessed input was sent attached this report, please let me know should this not be the case.)

ProblemType: Crash
Architecture: amd64
Date: Wed Nov 11 11:47:42 2009
DistroRelease: Ubuntu 9.10
ExecutablePath: /usr/lib/gcc/x86_64-linux-gnu/4.4.1/cc1plus
NonfreeKernelModules: wl nvidia
Package: g++-4.4 4.4.1-4ubuntu8
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: gcc-4.4
Uname: Linux 2.6.31-14-generic x86_64