Help with miscompilation bug
Posted: Wed Apr 09, 2008 11:14 am
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:
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.
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>
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.