the recent gcc-4.5-branch produces broken libkhtml.so.5.4.0 from kdelibs-4.4.3. afaics it produces different/broken binaries for khtml/css/parser.cpp and khtml/svg/SVGGradientElement.cpp. finally we get a nice GPF during knode/kmail/konqueror startup: [KCrash Handler] #5 memcpy () at ../sysdeps/x86_64/memcpy.S:78 #6 0x00007f546e63fc5e in QString::QString(QChar const*, int) () from /usr/lib64/libQtCore.so.4 #7 0x00007f5469f70e2e in qString (ps=<value optimized out>) at /usr/src/debug/kdelibs-4.4.3/khtml/css/cssparser.h:84 #8 DOM::CSSParser::parseValue (ps=<value optimized out>) at /usr/src/debug/kdelibs-4.4.3/khtml/css/cssparser.cpp:518 #9 0x00007f5469f95075 in cssyyparse (parser=0x7fff08c22820) at /usr/src/debug/kdelibs-4.4.3/khtml/css/parser.cpp:2969 #10 0x00007f5469f67d00 in DOM::CSSParser::runParser (this=0x7fff08c22820) at /usr/src/debug/kdelibs-4.4.3/khtml/css/cssparser.cpp:151 (...) with svn-bisect i've identified the first affected revision: Author: jamborm Date: Wed Apr 28 13:09:56 2010 New Revision: 158826 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158826 Log: 2010-04-28 Martin Jambor <mjambor@suse.cz> PR tree-optimization/43846 * tree-sra.c (struct access): New flag grp_assignment_read. (build_accesses_from_assign): Set grp_assignment_read. (sort_and_splice_var_accesses): Propagate grp_assignment_read. (enum mark_read_status): New type. (analyze_access_subtree): Propagate grp_assignment_read, create accesses also if both direct_read and root->grp_assignment_read. * testsuite/gcc.dg/tree-ssa/sra-10.c: New test.
Created attachment 20732 [details] preprocessed parser from kdelibs sources.
In meantime - is reversing the problematic gcc commit a sane thing to do for a gcc user? (from what I understand it was simply a better optimization and no real bugfix, right?)
(In reply to comment #2) > In meantime - is reversing the problematic gcc commit a sane thing to do for a > gcc user? (from what I understand it was simply a better optimization and no > real bugfix, right?) > If you're asking about reverting it in your local copy and by sane you mean safe then yes, you certainly can do it. I'll have a look at this as soon as I can but unfortunately that probably means next week.
Unfortunately the preprocessed source from comment #1 seems to be damaged, I get loads of errors like "error: stray '\336' in program." Can you please re-upload it? Thanks.
(In reply to comment #4) > Unfortunately the preprocessed source from comment #1 seems to be > damaged, I get loads of errors like "error: stray '\336' in program." > Can you please re-upload it? Thanks. > have a look at PR44406... i believe its the same thing.
I can provide an .i file, but it would be on x86 (with 4.4.3). Is it likely to be of use?
Created attachment 20839 [details] Preprocessed source Actually, never mind that --- got it on x86-64 from an another KDEer (credit to Alex Fiestas).
(In reply to comment #5) > > have a look at PR44406... i believe its the same thing. > I think it probably is because the patch of mine would lead to code very similar to what exposed PR 44406. However, PR 44406 actually no longer happens on the trunk because it is very likely a duplicate of PR 44164. So can you please verify that this miscompilation still takes place with the current 4.5 branch before I go into all the troubles of looking at what compiles differently and where? Thanks.
(In reply to comment #8) > (In reply to comment #5) > > > > have a look at PR44406... i believe its the same thing. > > > > I think it probably is because the patch of mine would lead to code > very similar to what exposed PR 44406. However, PR 44406 actually no > longer happens on the trunk because it is very likely a duplicate of > PR 44164. > > So can you please verify that this miscompilation still takes place > with the current 4.5 branch before I go into all the troubles of > looking at what compiles differently and where? Thanks. verification in progress...
the gcc-4.5-20100608 still miscompiles kde4libs.
OK, I have found the bug and I admit it is rather embarrassing. I'll submit a patch soon.
Subject: Bug 44258 Author: jamborm Date: Thu Jun 10 16:49:09 2010 New Revision: 160561 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160561 Log: 2010-06-10 Martin Jambor <mjambor@suse.cz> PR tree-optimization/44258 * tree-sra.c (build_access_subtree): Return false iff there is a partial overlap. (build_access_trees): Likewise. (analyze_all_variable_accesses): Disqualify candidates if build_access_trees returns true for them. * testsuite/gcc.dg/tree-ssa/pr44258.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr44258.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c
do you plan to backport this fix to 4.5 branch?
(In reply to comment #13) > do you plan to backport this fix to 4.5 branch? > Of course, I'm running the bootstrap and testsuite right now. I will commit it today if everything goes fine.
Subject: Bug 44258 Author: jamborm Date: Tue Jun 15 10:03:35 2010 New Revision: 160776 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160776 Log: 2010-06-15 Martin Jambor <mjambor@suse.cz> PR tree-optimization/44258 * tree-sra.c (build_access_subtree): Return false iff there is a partial overlap. (build_access_trees): Likewise. (analyze_all_variable_accesses): Disqualify candidates if build_access_trees returns true for them. * testsuite/gcc.dg/tree-ssa/pr44258.c: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/tree-ssa/pr44258.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/tree-sra.c
This is now fixed on both the trunk and the 4.5 branch.