Hi Bastian, Thanks for replying and checking stuff. > On Thu, Jul 17, 2008 at 03:34:59AM +0200, Michael Tautschnig wrote: > > When rebuilding diagnostics, it failed on s390 during the selftests [0]. The > > failing piece of code is attached. > > This includes too many preprocessor magic. Please provide an example > without. > I tried to, but the slightest modification of the code made me unable to reproduce the bug. I'm well aware of the fact that this makes it more or less impossible to diagnose the problem. > I was not even able to link libdiagnostics properly because it include > unresolvable symbols. > Huh? That should not happen. Could you provide some details? Probably a bug to be filed against diagnostics or just communicate in PM as it does not belong to this report, but it'd be interesting nevertheless. > Anyway, the access to m_throw as class member is somehow screwed if both > m_class_invariance and the destructor of Dummy_Class_With_Invariance is > inline. > I don't really get what you're after. Why actually is there a problem with that? The destructor is not defined, so it will be generated, but it will be a no-op anyway. Why does inlining play a specific role here? > > (all controllable options enabled by -O) does _not_ yield the errornous > > behavior, and dropping -fgcse also stops the runtime failure. > > -fgcse is not the root cause. -O0 -fgcse does not show this behaviour. > Ok, so it is some interplay of optimizations, which makes it more or less impossible to debug. I guess there is no other option than waiting for next gcc upload to become available in unstable so I can re-check on raptor.d.o. Nevertheless, it would be interesting to get some more details on your suspections noted above. Thanks, Michael
Attachment:
pgp_r3FMhShXA.pgp
Description: PGP signature