Help with miscompilation bug

[ennuija]

I'm working on a port of DROD (Deadly Rooms of Death) for GBA. One function is causing an infinite loop (according to VBA it is eating all of the stack). I used gdb to track the bug to std::set::clear. This function isn't the problem, though -- the infinite loop happens here (it's infinite recursion of std::_Rb_tree::_M_erase) but the set reference is already screwed up at this point. Here's some assembly:

Code: Select all

    b80a:	469b      	mov	fp, r3
    b80c:	ab2e      	add	r3, sp, #184
    b80e:	781b      	ldrb	r3, [r3, #0]
    b810:	9306      	str	r3, [sp, #24]
    b812:	1c07      	adds	r7, r0, #0
    b814:	6859      	ldr	r1, [r3, #4]
    b816:	6858      	ldr	r0, [r3, #4]
    b818:	4bcc      	ldr	r3, [pc, #816]	(bb4c <.text+0xbb4c>)
    b81a:	6889      	ldr	r1, [r1, #8]
    b81c:	9303      	str	r3, [sp, #12]
    b81e:	f007 f886 	bl	1292e <.text+0x1292e>

The final "bl" is a branch to a stub that calls std::_Rb_tree::_M_erase. r3 is used as the this pointer. Essentially, r3 looks like a fine address at the start, then the lrdb instruction blows it all away.

Funny thing is that this only happens with function inlining on (e.g. occurs in -O3 or -O2 -finline-functions, but not -O3 -fno-inline-functions or -O2). This means it's pretty difficult to produce a simple test case that exhibits this bug, it doesn't happen in isolation...

Okay, so here are the questions: what's the best way to submit this bug? Is it even worth submitting (because it's GCC 4.1.2?) Any suggestions as to isolating it? How about tracking whether it is fixed in later versions?

I'm just going to compile with -O2 for now, so I'm not stuck, but it would be nice to have resolved.

p.s.
It doesn't seem to be an aliasing problem (it was my first guess), the bug still occurs with -fno-strict-aliasing. -fomit-frame-pointer is off the hook too.

[WinterMute]

Is this still a problem with the latest toolchain?