Hi there.
I noticed with -O2 level optimization using gcc 4.1 built on IBM AIX (for use with 5.3 and 6.1) that a bunch of lwz rxxx,offsetyyy(r2) sequences are added to an inline sequence, before bctrl (calling a method or function) is done. After the register is loaded, it is never used again after the return from the method or function - effectively, it is a no-op. This instruction happens after loading a new $toc (loading a new global data section pointer), so the register is not being loaded from the right place - the same instruction happens higher up, but in the valid $toc context. It is as if instruction blocks are not being moved around correctly.
With a system that isn't busy, all shared libraries are loaded contiguously in the 32-bit address space of the shared library. When the system is busy, with arbitrary zero reference counted shared libraries being tossed, the junk lwz instruction can refer to address ranges which are not in the active program's legitimate address range, so you have an access violation.
I have found that up to now, the only way to prevent this problem is to compile with -fno-gcse or even turn off inlining, explicit and implicit, but these will both have a performance impact.
I have also tried using -mno-longcall, but this seems to have no effect - I still see the problematic lwz instruction appear before bctrl.
I have also tried changing the explicitly inlined templates to no longer be inlined, but this only stops a couple of bad lwz instructions appearing.
The other switch I tried to use with -fno-exceptions. This got rid of the problem, but my C++ code would never be able to work under these circumstances.
I have tried declaring the local variables used in the inline template methods as volatile , to force using the stack, but this had no effect either.
I have tried all of the minor -fgcse options including -fgcse-after-reload, but they had no effect.
Is there a way of working around this problem, say with a --param setting? I have seen in gcc's Bugzilla a number of issues like this, but not precisely like this.