On i686-apple-darwin9 from revision 138210 with -m64, I get the follwing ICE: [ibook-dhum] f90/bug% gcc44 -m64 -O1 -msse2 -mfpmath=sse -march=k8 /opt/gcc/_gcc_clean/gcc/testsuite/gcc.target/i386/hot-1.c /opt/gcc/_gcc_clean/gcc/testsuite/gcc.target/i386/hot-1.c: In function 'not_hot': /opt/gcc/_gcc_clean/gcc/testsuite/gcc.target/i386/hot-1.c:33: internal compiler error: in mems_in_disjoint_alias_sets_p, at alias.c:278 for gcc.target/i386/hot-1.c, opt-1.c, and opt-2.c.
This regression has been introduced between revisions 137991 and 138210.
I now get the same error for gcc.target/i386/opt-1.c and opt-2.c also in 32 bit mode (default). This appeared between revision r141074 (with the patch for pr37808) and r141083. Note the ICE for gcc.target/i386/hot-1.c disappeared between r139622 and r139843.
Can you try regressing r141079 and see if that suppresses the problem on -m32 for i686-apple-darwin9?
> Can you try regressing r141079 ... This revision is for the ira-merge branch, the revision for trunk is r141077 and given the revision window and the fact that it cannot be r141078 since the failures did not appear with this patch, and that the other revisions are either gfortran or date stamps, I think it is the only candidate without further testing.
To clarify are you saying that the offending revision is likely 141079 or 141077? Both have changes to alias.c.
> To clarify are you saying that the offending revision is likely 141079 or > 141077? Both have changes to alias.c. Both revisions are the same: 141077 is for trunk (what I build and probably you also), 141079 is for the "ira-merge" branch I am not using.
Can you try the failing test cases with -fno-PIC to see if these issues are related to the fact that darwin defaults to -fPIC?
> Can you try the failing test cases with -fno-PIC to see if these issues are > related to the fact that darwin defaults to -fPIC? Apparently the tests pass with -fno-PIC in 32 bit mode but not with -m64: [ibook-dhum] f90/bug% gfc -c -O1 -msse2 -mfpmath=sse -march=k8 -fno-PIC /opt/gcc/_gcc_clean/gcc/testsuite/gcc.target/i386/opt-1.c [ibook-dhum] f90/bug% gfc -c -O1 -msse2 -mfpmath=sse -march=k8 -fno-PIC /opt/gcc/_gcc_clean/gcc/testsuite/gcc.target/i386/opt-2.c [ibook-dhum] f90/bug% gfc -m64 -c -O1 -msse2 -mfpmath=sse -march=k8 -fno-PIC /opt/gcc/_gcc_clean/gcc/testsuite/gcc.target/i386/opt-1.c /opt/gcc/_gcc_clean/gcc/testsuite/gcc.target/i386/opt-1.c: In function 'not_opt3': /opt/gcc/_gcc_clean/gcc/testsuite/gcc.target/i386/opt-1.c:34: internal compiler error: in mems_in_disjoint_alias_sets_p, at alias.c:278 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. [ibook-dhum] f90/bug% gfc -m64 -c -O1 -msse2 -mfpmath=sse -march=k8 -fno-PIC /opt/gcc/_gcc_clean/gcc/testsuite/gcc.target/i386/opt-2.c /opt/gcc/_gcc_clean/gcc/testsuite/gcc.target/i386/opt-2.c: In function 'not_opt3': /opt/gcc/_gcc_clean/gcc/testsuite/gcc.target/i386/opt-2.c:37: internal compiler error: in mems_in_disjoint_alias_sets_p, at alias.c:278 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions.
Well, I guess then the first thing to ask for is for both the gcc.target/i386/opt-1.c and gcc.target/i386/opt-2.c tests to be extended so that they are run with -fPIC. It would be helpful to know if current gcc trunk on i386 linux fail these test with -fPIC to determine if this issue is darwin specific.
(In reply to comment #9) > Well, I guess then the first thing to ask for is for both the > gcc.target/i386/opt-1.c and gcc.target/i386/opt-2.c tests to be > extended so that they are run with -fPIC. It would be helpful to > know if current gcc trunk on i386 linux fail these test with -fPIC > to determine if this issue is darwin specific. I confirm the opt-1/opt-2 failures on i686-linix and x86_64-linux when using -fpic or -fPIC: http://gcc.gnu.org/ml/gcc-testresults/2008-10/msg00958.html http://gcc.gnu.org/ml/gcc-testresults/2008-10/msg00907.html The issue is not darwin-specific.
> I confirm the opt-1/opt-2 failures on i686-linix and x86_64-linux when using > -fpic or -fPIC: > ... > The issue is not darwin-specific. Digging the archives the failures on x86_64-linux when using -fpic or -fPIC appeared between: http://gcc.gnu.org/ml/gcc-testresults/2008-07/msg02246.html and http://gcc.gnu.org/ml/gcc-testresults/2008-07/msg02337.html Kaveh do you have a way to know the corresponding revisions?
Possible candidates revisions 138075, 138089, and 138092.
(In reply to comment #11) > Digging the archives the failures on x86_64-linux when using -fpic or -fPIC > appeared between: > http://gcc.gnu.org/ml/gcc-testresults/2008-07/msg02246.html > and > http://gcc.gnu.org/ml/gcc-testresults/2008-07/msg02337.html > Kaveh do you have a way to know the corresponding revisions? Sorry no. I see that some postings have the revision number in the postiong subject, but I don't know how to do that nor why everyone isn't having that done by default. It would have been useful in retrospect. :-/
> ... I don't know how to do that ... What I do is to edit the file gcc/DATESTAMP to have [revision number] date instead of just date The minor drawback is that there is a conflict with svn update each time the date stamp changes. > why everyone isn't having that done by default ... May be you can ask on the gcc list why this is not done automatically.
I have forgotten to say that I also put the revision numbers in the name of the logs of the tests so I can grep the files for some pattern and have the list of the revisions for which it appears.
(In reply to comment #13) > Sorry no. I see that some postings have the revision number in the postiong > subject, but I don't know how to do that nor why everyone isn't having that > done by default. It would have been useful in retrospect. :-/ > If you use "contrib/gcc_update" to update your SVN tree, "gcc --version" will report 4.4.0 20081015 (experimental) [trunk revision 141140]
Subject: Bug 37106 Author: jakub Date: Tue Nov 4 20:06:33 2008 New Revision: 141584 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141584 Log: PR c/37106 * c-common.c (parse_optimize_options): Save and restore flag_strict_aliasing around decode_options call. * gcc.dg/pr37106-1.c: New test. * gcc.dg/pr37106-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr37106-1.c trunk/gcc/testsuite/gcc.dg/pr37106-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/testsuite/ChangeLog
Fixed.
Blah, turning on/off strict aliasing via the option pragma would be a good idea.