[forwarded from http://bugs.debian.org/238621] A miscompilation of mozilla-firefox. 3.3 CVS 20040306 is known to work, 20040314 fails. A comment from the bug report: The problem is with deallocators, it crashes in nsBufferHandle.h at line 381 and 398, even commenting out both deallocation it crashes in nsEventListenerManager.cpp Currently trying to find a way to update a checkout to a specific date on a branch ...
We really need a simple testcase as running/building takes too long.
The regression was introduced by this patch: 2004-03-12 Gabriel Dos Reis <gdr@integrable-solutions.net> Backport: 2004-01-12 Richard Henderson <rth@redhat.com> PR opt/10776 * typeck2.c (split_nonconstant_init_1, split_nonconstant_init): New. (store_init_value): Use it. * decl.c (check_initializer): Expect full initialization code from store_init_value. * init.c (expand_aggr_init_1): Likewise. * decl2.c (maybe_emit_vtables): Abort if runtime init needed.
Most likely now the issue is in the middle-end doing some messed up with /u and RTX_UNCHANGING_P.
Created attachment 6003 [details] preprocessed source
Created attachment 6004 [details] generated .s file using 3.3 CVS 20030427
Created attachment 6005 [details] generated .s file using 3.3 CVS 20040327 with fix for PR10776 reversed
Created attachment 6006 [details] diff of .s files
compiling the whole app with 3.3 CVS 20040327 results in the segfault. compiling content/events/src/nsEventListenerManager.cpp with the same compiler and the backport for PR10776 reverted and relinking results in a working application. Flags used to compile: /usr/lib/gcc-lib/i486-linux/3.3.3/cc1plus -fpreprocessed nsEventListenerManager.ii -quiet -dumpbase nsEventListenerManager.cpp -auxbase-strip nsEventListenerManager.o -O2 -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-long-long -w -version -fPIC -fno-rtti -fno-exceptions -fshort-wchar -o nsEventListenerManager.s
I confirm the same problem when building Mozilla 1.7 (CVS) using gcc 3.4.0 2004-03-29 (CVS). The problem disappears after reverting the backport for PR10776 and re-building Mozilla. Unfortunately, this bug appears still unassigned.... maybe I'll file a new bug report specifically for gcc3.4.0
We just did not know if this was also a 3.4 (or 3.5) regression at all, please do NOT file another bug.
Gaby: are you aware of this regression on the 3.3 branch due to a backported patch? We could avoid this is we undo the regression by reverting the backport and simply stick with the breakage of PR 10776. Debian maintainers: I think this PR is enough in itself, we don't gain by opening more bug reports about the same problem. However, you could aid us some more by identifying which part of the file you named is miscompiled. For this you'd split up the file into multiple files that each have only one function, and do the same procedure you had for identifying which of the original files was the problem on the new one-function-only files. Thanks Wolfgang
*** Bug 14772 has been marked as a duplicate of this bug. ***
Andrew, I already submitted another bug and then got your reply.... sorry. Anyway, the application are different, although the behaviour is similar: this bug is about compiling Firefox while the new one I opened is about compiling the standard Mozilla browser. Actually, I haven't tried to compile Firefox. Maybe we'd better keep them separate. What do you say ?
Since firefox and mozilla are so close in that they share so many files, the bug is the same as the same file exhibits the bug in both applications as they are very closely related programs.
Why this bug is still UNCONFIRMED? I cannot compile mozilla using 3.3.4 20040328 too. Also 3.4.0 never compiles working mozilla (I tried many times from early 2004).
Uncomfirmed here only means that we have no small testcase, which is one of our requirements to put something into "confirmed" mode. It is certainly on our radar! W.
Subject: Re: [3.3/3.4/3.5 regression] miscompilation of mozilla-firefox (deallocator problems?) "bangerth at dealii dot org" <gcc-bugzilla@gcc.gnu.org> writes: | Gaby: are you aware of this regression on the 3.3 branch due to a | backported patch? Yes, I got two copies of each message since I'm added to the CC list (and no, don't remove me :-)). However, I disagree with your conclusion as you stated below and phrased on gcc@gcc.gnu.org | We could avoid this is we undo the regression | by reverting the backport and simply stick with the breakage | of PR 10776. I suppose that is one way of closing this PR. The original patch was to solve a problem. Reverting the patch will not solve it; it would just hide this problem and unsolve the other one. I would prefer digging up and find ways to solve the regression. Reverting this patch would be the case only if there is no way to get rid of this problem. For what it worths, this problem also affects 3.4.0 and (I think 3.5.0). Thanks for your inputs and monitoring the PR. -- Gaby
Reduced testcase is in bug 14804 so closing as a dup. *** This bug has been marked as a duplicate of 14804 ***
I still get problems with the CVS prerelease of 3.4.0. Could somebody please check that they also fixed the issue in such branch ? Cheers.