[hjl@gnu-4 itanium]$ cat lock.c extern void __free_pages_bulk (unsigned long); int free_pages_bulk(int count, unsigned int order) { unsigned long mask, flags; int ret = 0; mask = (~0UL) << order; asm volatile ("mov %0=psr" : "=r"(flags)); while (count--) { __free_pages_bulk(mask); } return ret; } [hjl@gnu-4 itanium]$ /usr/gcc-3.4/bin/gcc -S -O2 -mtune=itanium -S lock.c lock.c: In function `free_pages_bulk': lock.c:15: internal compiler error: in bundling, at config/ia64/ia64.c:7358 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions.
Created attachment 6383 [details] A different testcase
Looks like same bug as 15598.
Subject: Bug 15653 CVSROOT: /cvs/gcc Module name: gcc Changes by: vmakarov@gcc.gnu.org 2004-06-10 21:06:08 Modified files: gcc : ChangeLog haifa-sched.c Log message: 2004-06-10 Vladimir Makarov <vmakarov@redhat.com> PR target/15653 * haifa-sched.c (schedule_block): Finish cycle after issuing asm insn. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.3915&r2=2.3916 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/haifa-sched.c.diff?cvsroot=gcc&r1=1.243&r2=1.244
Subject: Bug 15653 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_4-branch Changes by: vmakarov@gcc.gnu.org 2004-06-10 21:10:09 Modified files: gcc : ChangeLog haifa-sched.c Log message: 2004-06-10 Vladimir Makarov <vmakarov@redhat.com> PR target/15653 * haifa-sched.c (schedule_block): Finish cycle after issuing 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.492&r2=2.2326.2.493 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/haifa-sched.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.236.2.1&r2=1.236.2.2
Fixed.
The bug is not fixed. Please check all testcases in the bug report. The one failed is lock.c. I am enclosing here again: [hjl@gnu-4 itanium]$ cat lock.c extern void __free_pages_bulk (unsigned long); int free_pages_bulk(int count, unsigned int order) { unsigned long mask, flags; int ret = 0; mask = (~0UL) << order; asm volatile ("mov %0=psr" : "=r"(flags)); while (count--) { __free_pages_bulk(mask); } return ret; } [hjl@gnu-4 itanium]$ make lock.o /export/build/gnu/gcc-3.4/build-ia64-linux/gcc/xgcc -B/export/build/gnu/gcc- 3.4/build-ia64-linux/gcc/ -O2 -mtune=itanium -c -o lock.o lock.c lock.c: In function `free_pages_bulk': lock.c:15: internal compiler error: in bundling, at config/ia64/ia64.c:7359 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. make: *** [lock.o] Error 1
Jim, as IA64 maintainer would you please take a look at this?
When I wrote the patch I worked on kernel_time.c. And the pacth solves the problem with the test. The test lock.c has another reason for the crash. It is in code putting additional nops between shift insn and a dependent insn. This code is specific for itanium1 only. As I see it does not work when the next insn is an asm insn. I'll send a patch for solving this problem too. I don't think we should pay attention to legacy hardware like itanium1. Could somebody tell me how many itanium1 machines are used now? And who are using them? I think we should remove code supporting Itanium1. Vlad
Subject: Re: [3.4 Regression]: Gcc 3.4 ICE on valid code On Tue, 2004-06-15 at 09:11, vmakarov at redhat dot com wrote: > I'll send a patch for solving this problem too. I don't think we should pay > attention to legacy hardware like itanium1. Could somebody tell me how many > itanium1 machines are used now? And who are using them? I think we should > remove code supporting Itanium1. We can't just drop Itanium1 support. I tried reducing Itanium1 support from binutils. Specifically, I modified binutils to emit the brl (branch long) instruction by default instead of a longer non-brl sequence. This instruction is implemented in hardware in Itanium2, and emulated in software on Itanium1. The ABI requires that brl be emulated, so the only effect on Itanium1 was that some large programs would run a little slower. A few months later, HJ submitted a binutils patch that added an option to emit the non-brl sequence for Itanium1 targets. Obviously, someone still cares about Itanium1 performance, though it is likely a very small number of people. Maybe someone has a large installation of Itanium1 machines that they can't afford to just throw away? For FSF GCC release purposes, I think we can consider Itanium1 specific optimization bugs as less important than general Itanium bugs.
Subject: Bug 15653 CVSROOT: /cvs/gcc Module name: gcc Changes by: vmakarov@gcc.gnu.org 2004-06-16 15:47:30 Modified files: gcc : ChangeLog gcc/config/ia64: ia64.c Log message: 2004-06-16 Vladimir Makarov <vmakarov@redhat.com> PR target/15653 * config/ia64/ia64.c (ia64_dfa_new_cycle): Do not insert nops after shifts before asm. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.3993&r2=2.3994 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.c.diff?cvsroot=gcc&r1=1.291&r2=1.292
Subject: Bug 15653 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_4-branch Changes by: vmakarov@gcc.gnu.org 2004-06-16 15:51:34 Modified files: gcc : ChangeLog gcc/config/ia64: ia64.c Log message: 2004-06-16 Vladimir Makarov <vmakarov@redhat.com> PR target/15653 * config/ia64/ia64.c (ia64_dfa_new_cycle): Do not insert nops after shifts before asm. 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.508&r2=2.2326.2.509 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.8&r2=1.265.2.9
*** Bug 15655 has been marked as a duplicate of this bug. ***
I found another Itanium 1 bug. This time, -mtune=merced and -frename-registers are involved. As I understand, -frename-registers may be buggy (see bug 15569). Should -frename-registers be disabled for Itanium 1 as a workaround? Gcc 3.4 has many Itanium 1 regressions. I think we should either remove Itanium 1 support or fix all regressions.
Created attachment 6598 [details] Another testcase [hjl@gnu-4 linux-2.6.7]$ /usr/gcc-3.4/bin/gcc -O2 -mtune=merced foo.c -S -frename-registers 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.
The bug has nothing to do with -frename-registers: [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.
HJ, please do not add new test cases for new bugs to an existing PR. There's no evidence that they are the same bug. As such, I've closed this PR; you can open a new PR with the new bug.
Subject: Re: [3.4 Regression]: Gcc 3.4 ICE on valid code On Mon, 2004-06-21 at 16:08, hjl at lucon dot org wrote: > Gcc 3.4 has many Itanium 1 regressions. I think we should either remove Itanium > 1 support or fix all regressions. I find this very confusing. I assumed that we can not remove Itanium1 support because a) You re-added binutils support after I removed it. b) You are reporting gcc bugs for it. If we really can remove it, then why are you reporting all of these bugs? At the very least, you should mark them as minor problems so I know that they aren't important. The Itanium port has far more problems than there are people to fix them. Every time you report a bug you don't care about, you make this worse. People aren't going to volunteer to fix Itanium bugs just because you report them. All that happens is that you increase my work load. I've been spending time looking at these Itanium1 bug reports because they seemed important to you. Meanwhile, other important bugs are going unfixed. You are only hurting your own cause by diverting my attention from more important problems if you really don't care about the Itanium1 support. Keep in mind that just because it is broken doesn't mean we have to remove it. Removing it is a big hammer. There are easier solutions, such as ignoring the problem for now, or disabling it, or adding an error() call to document that it is broken. If we just leave it alone, maybe someone will volunteer to fix the problems 6 months from now. This won't happen if we just remove it. If we do remove the support, then what exactly are we removing? What about the kernel support? What about the binutils support? Are there other things affected, like glibc? Are we removing all Itanium1 support? Or are we just removing the DFA scheduler for Itanium1? What about people that still have Itanium1 machines?