User account creation filtered due to spam.

Bug 15653 - [3.4 Regression]: Gcc 3.4 ICE on valid code
Summary: [3.4 Regression]: Gcc 3.4 ICE on valid code
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 3.4.1
: P2 normal
Target Milestone: 3.4.1
Assignee: Vladimir Makarov
URL:
Keywords:
: 15655 (view as bug list)
Depends on:
Blocks: 16278
  Show dependency treegraph
 
Reported: 2004-05-25 19:32 UTC by H.J. Lu
Modified: 2005-07-23 22:49 UTC (History)
2 users (show)

See Also:
Host: ia64-unknown-linux-gnu
Target: ia64-unknown-linux-gnu
Build: ia64-unknown-linux-gnu
Known to work:
Known to fail:
Last reconfirmed:


Attachments
A different testcase (381 bytes, text/plain)
2004-05-25 22:28 UTC, H.J. Lu
Details
Another testcase (567 bytes, text/plain)
2004-06-21 23:33 UTC, H.J. Lu
Details

Note You need to log in before you can comment on or make changes to this bug.
Description H.J. Lu 2004-05-25 19:32:14 UTC
[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.
Comment 1 H.J. Lu 2004-05-25 22:28:19 UTC
Created attachment 6383 [details]
A different testcase
Comment 2 Jim Wilson 2004-06-01 06:00:45 UTC
Looks like same bug as 15598.
Comment 3 CVS Commits 2004-06-10 21:06:11 UTC
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

Comment 4 CVS Commits 2004-06-10 21:10:13 UTC
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

Comment 5 Andrew Pinski 2004-06-10 22:20:59 UTC
Fixed.
Comment 6 H.J. Lu 2004-06-11 23:05:53 UTC
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
Comment 7 Mark Mitchell 2004-06-12 22:11:55 UTC
Jim, as IA64 maintainer would you please take a look at this?
Comment 8 Vladimir Makarov 2004-06-15 16:11:11 UTC
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
Comment 9 Jim Wilson 2004-06-16 01:13:29 UTC
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.
Comment 10 CVS Commits 2004-06-16 15:47:42 UTC
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

Comment 11 CVS Commits 2004-06-16 15:51:45 UTC
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

Comment 12 Andrew Pinski 2004-06-16 19:06:18 UTC
Fixed.
Comment 13 Jim Wilson 2004-06-17 07:15:39 UTC
*** Bug 15655 has been marked as a duplicate of this bug. ***
Comment 14 H.J. Lu 2004-06-21 23:08:47 UTC
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.
Comment 15 H.J. Lu 2004-06-21 23:33:09 UTC
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.
Comment 16 H.J. Lu 2004-06-21 23:40:24 UTC
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.
Comment 17 Mark Mitchell 2004-06-22 08:14:15 UTC
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.
Comment 18 Jim Wilson 2004-06-23 22:11:49 UTC
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?