On Tue, Mar 15, 2005 at 01:19:29PM +0200, Modestas Vainius wrote: > The bug only affects the binary compiled with gcc-3.3 using -O1 or greater > level of optimizations. gdb yields the following backtrace on at the time This looks to me (as a total gcc novice) to be a bug in the optimizer for amd64, then. Would you agree? > fbpanel compiled with gcc-3.3 -O1 -g segfaults: [...] > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 46912538764672 (LWP 19381)] > tb_display (tb=0x0) at taskbar.c:661 > 661 if (tb->wins) > (gdb) bt > #0 tb_display (tb=0x0) at taskbar.c:661 > #1 0x00002aaaaf80d68d in taskbar_constructor (p=0x6854a0) at taskbar.c:1148 Now, the odd thing is, that taskbar_constructor() spends quite a bit of time doing tb->this_that_and_the_other manipulations before doing tb_display(tb). There's nowhere in the relevant code that I can see that could run tb = 0 -- which is the only way you could end up with tb = 0x0 come the call to tb_display()... > However, please note, that fbpanel compiled with gcc-3.3 -O0 or gcc-3.4 with > any level of optimizations (I've tested -O2 and -O0) doesn't segfault. So, > overall, it seems fbpanel suffers from miscompilation on amd64 with gcc-3.3 > -O1 or higher level of opts. gcc-3.3 is a default compiler on pure64 OK, should I make gcc3.4 (or gcc >= 3.4 -- I'm not sure which one is the right way to go) a build-dep on amd64 then? I suppose I could, alternately, force the optimization level to -O0 (either for amd64 or in general), but I've got no experience with what that does, performance wise, to the resultant binaries, and since this is intended to be suitable for low-resource systems, every last bit of performance we can reasonably obtain is useful. - Matt
Attachment:
signature.asc
Description: Digital signature