A testcase is at http://gcc.gnu.org/bugzilla/attachment.cgi?id=6598&action=view [hjl@gnu-4 linux-2.6.7]$ /usr/gcc-3.4/bin/gcc -O2 -mtune=merced foo.c -S foo.c: In function `ia64_mmu_init': foo.c:55: internal compiler error: in bundling, at config/ia64/ia64.c:7112 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. BTW, gcc 3.4 has many Itanium 1 regressions. I think we should either remove Itanium 1 support or fix all regressions.
Subject: Re: New: [3.4 Regression]: Gcc 3.4 ICE on valid code hjl at lucon dot org wrote: > BTW, gcc 3.4 has many Itanium 1 regressions. I think we should either remove > Itanium 1 support or fix all regressions. I tried to respond to this in bug #15653, but since that was closed already, and this one is still open, I will repeat some of it here. As far as I know, we can't remove the Itanium 1 support because you are using it. If you really aren't using it, then you should either stop reporting bugs against it, or else you should indicate so in your bug reports, so we know that they are not problems that need to be fixed. Reporting lots of problems will not encourage people to fix Itanium1 bugs. All it does is add to my workload. There are already more IA-64 bugs than I have time to fix, so this just makes things worse. If these problems are really not important, then I would like to know. There are other things I could be doing, such as fixing the SPEC benchmark miscompilation problem, or the profilebootstrap failure. Removing the Itanium1 support is an awefully big hammer. If we remove it, it will probably never come back. There are other less radical things that can be done, such as disabling the Itanium1 DFA, or adding an error() call to indicate that it is known to be broken. If we are removing Itanium1 support, then are we also removing it from other packages too? The linux kernel? Binutils? You explicitly added Itanium1 support to binutils a few months ago after I tried to remove it, so my understanding was we still needed Itanium1 support everywhere. I don't mind getting meta-bugs when other major GNU/Linux packages are involved. I suspect all of your testcases are coming from the linux kernel, in which case a single bug reporting that is probably much more useful than the 6 or so separate bugs you have reported so far.
I noticed those regressions while compiling 2.6.7 kernel for Itantium 1. I agree that a single bug report is better than many separate ones in this case. But I was told that I should open separate ones. I doubt there are many Itanium 1 machines left in production use. If people want to use Itanium 1, they can stick with the older gccs. Or they should upgrade their machines. I don't think many people will mind if the new gcc stops supporting Itanium 1. I think disable Itanium 1 DFA is a good idea for gcc 3.4. We can remove it from mainline. Binutils is different. People with Itanium 1 machines still need improved assembler and linker. But they don't necessarily need to upgrade gcc.
What you could do is file a meta bug with reference to all of the Itanium 1 bugs.
Subject: Re: [3.4 Regression]: Gcc 3.4 ICE on valid code On Fri, 2004-06-25 at 00:44, hjl at lucon dot org wrote: > I noticed those regressions while compiling 2.6.7 kernel for Itantium 1. I > agree that a single bug report is better than many separate ones in this > case. But I was told that I should open separate ones. You were asked to file separate bug reports because you never clearly stated that all of the bug reports were linux kernel compilation problems. It was obvious to me, but it wasn't obvious to others. So it looked like you were filing unrelated bugs together which is bad. You also made the mistake of adding new testcases to a bug that was already closed, without explaining why. I see you have filed a new meta-bug 16278 for this. Thanks. It would have been better if you mentioned how to configure the linux kernel to reproduce the error though. You have to explicitly enable the Itanium1 support when configuring the linux kernel, and then that automatically adds the -mtune=merced option to CFLAGS. > Binutils is different. People with Itanium 1 machines still need improved > assembler and linker. But they don't necessarily need to upgrade gcc. If you are assuming that a new binutils will work with an old gcc, then I think you are wrong. The interfaces between binutils and gcc change occasionally, and we can not support using mismatched versions. If we are telling people to use old gcc releases, then we must also tell them to use old binutils releases that worked with that old gcc release.
Subject: Bug 16130 CVSROOT: /cvs/gcc Module name: gcc Changes by: vmakarov@gcc.gnu.org 2004-07-07 15:11:44 Modified files: gcc : ChangeLog gcc/config/ia64: ia64.c Log message: 2004-07-07 Vladimir Makarov <vmakarov@redhat.com> PR target/16130 PR target/16142 PR target/16143 * config/ia64/ia64.c (ia64_dfa_new_cycle): Reset DFA state for asm insn. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.4338&r2=2.4339 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.c.diff?cvsroot=gcc&r1=1.297&r2=1.298
Subject: Bug 16130 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_4-branch Changes by: vmakarov@gcc.gnu.org 2004-07-07 15:15:57 Modified files: gcc : ChangeLog gcc/config/ia64: ia64.c Log message: 2004-07-07 Vladimir Makarov <vmakarov@redhat.com> PR target/16130 PR target/16142 PR target/16143 * config/ia64/ia64.c (ia64_dfa_new_cycle): Reset DFA state for asm insn. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.536&r2=2.2326.2.537 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.265.2.9&r2=1.265.2.10
Fixed.