------- Comment #4 from pcarlini at suse dot de 2005-12-09 10:33 -------
(In reply to comment #3)
> Comment #2 is generally wrong: a change in GCC codegen can certainly expose a
> coding bug in libstdc++ despite "nothing changed" there.
Yes, in principle you are right.
As the bug is exposed
> by libstdc++, it is correct to set component to "libstdc++" pending further
> analysis. I guess you disagree,
Yes, I disagree ;) The reason is a very pragmatic one: usually, in such cases
people stop paying attention to the issue and just wait for the libstdc++ to do
something, without any hurry. I don't like that. Of course, I don't like that
especially when I have strong reasons to believe that the bug is *not* a
libstdc++ bug, like in this case. Probably we should have a way to leave the
component totally unspecified pending further analysis.
Anyway, on ia64-linux I'm even getting a Segmentation fault, very hard to the
debug on the library side, because goes away if I rebuild the library itself
passing anything lower than -O2, -O1 suffices... Frankly, seems a
miscompilation to me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25315
