Bug 15598 - [3.4 Regression]: Gcc 3.4 ICE on valid code
Summary: [3.4 Regression]: Gcc 3.4 ICE on valid code
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 3.4.1
: P2 normal
Target Milestone: 3.4.1
Assignee: Jan Hubicka
Keywords: ice-on-valid-code
Depends on:
Blocks: 16278
  Show dependency treegraph
Reported: 2004-05-23 05:04 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: 2004-05-23 13:27:35

A testcase (262 bytes, text/plain)
2004-05-23 05:09 UTC, H.J. Lu

Note You need to log in before you can comment on or make changes to this bug.
Description H.J. Lu 2004-05-23 05:04:24 UTC
-O2 -mtune=itanium causes ICE.
Comment 1 H.J. Lu 2004-05-23 05:09:43 UTC
Created attachment 6363 [details]
A testcase

make[1]: Entering directory `/export/home/hjl/bugs/gcc/itanium'
-B/export/build/gnu/gcc-next/build-ia64-linux/gcc/ -O2 -mtune=itanium	-c -o
bar.o bar.c
bar.c: In function `ia64_handle_irq':
bar.c:20: internal compiler error: in bundling, at config/ia64/ia64.c:6715
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
make[1]: *** [bar.o] Error 1
make[1]: Leaving directory `/export/home/hjl/bugs/gcc/itanium'

This patch


causes bootstrap failure on many platforms, including Linux/ia64. But gcc
passes this testcase. This patch


may fix the bootstrap problem. But gcc fails the testcase.
Comment 2 Andrew Pinski 2004-05-23 11:33:13 UTC
Are you sure that not caused by a modified 3.4.1? As on line 6715 in ia64.c there is no abort.
Comment 3 Andreas Schwab 2004-05-23 13:27:34 UTC
I can reproduce with today's 3.4 branch. 
bar.c:20: internal compiler error: in bundling, at config/ia64/ia64.c:6902 
Comment 4 H.J. Lu 2004-05-23 15:12:40 UTC
The difference of the cgraph RTL dump between bad and good ones are

+Final callgraph:
+ia64_handle_irq: 27 insns needed inlinable
+  called by:
+  calls: do_IRQ
+  called by: ia64_handle_irq
+  calls:

The bad one is missing "Final callgraph".
Comment 5 H.J. Lu 2004-05-23 15:17:46 UTC
The bad one died before final call graph could be dumped.
Comment 6 Jim Wilson 2004-06-01 06:04:19 UTC
I don't understand this code well enough to easily debug it, and I am leaving
for the gcc summit tomorrow.

However, I did notice that if I delete the volatile from the first asm, then it
works.  Also, it works if I use -mvolatile-asm-stop.  Since that option adds
extra unnecessary stop bits, it should be an acceptable work around in the short

I also noticed that the same workarounds worked for the testcase in 15653.  I
didn't try the testcase in 15655.
Comment 7 H.J. Lu 2004-06-02 20:24:23 UTC
If I use the patch below, this testcase will pass, but not others.

2004-05-24  H.J. Lu  <hongjiu.lu@intel.com>

        * config/ia64/itanium1.md (1_ialu_addr): Also allow I-unit.
        (1b_ialu_addr): Likewise.

--- gcc/config/ia64/itanium1.md.bundle  2003-07-07 06:58:34.000000000 -0700
+++ gcc/config/ia64/itanium1.md 2004-05-25 11:26:10.563164935 -0700
@@ -580,7 +580,7 @@
          (eq (symbol_ref
               "!bundling_p && ia64_produce_address_p (insn)")
              (const_int 1)))
-    "1_M")
+    "1_A")
 (define_insn_reservation "1_icmp"    1
   (and (and (eq_attr "cpu" "itanium")
             (eq_attr "itanium_class" "icmp"))
@@ -1449,7 +1449,7 @@
          (eq (symbol_ref
               "bundling_p && ia64_produce_address_p (insn)")
              (const_int 1)))
-    "1b_M")
+    "1b_A")
 (define_insn_reservation "1b_icmp"    1
   (and (and (eq_attr "cpu" "itanium")
             (eq_attr "itanium_class" "icmp"))
Comment 8 Jim Wilson 2004-06-08 07:33:49 UTC
Subject: Re:  [3.4 Regression]: Gcc 3.4 ICE on valid code

hjl at lucon dot org wrote:
>         * config/ia64/itanium1.md (1_ialu_addr): Also allow I-unit.
>         (1b_ialu_addr): Likewise.

I do not believe this patch is correct.  I believe the 1*_ialu_addr 
patterns are deliberately using M instead of A.

Use of M instead of A restricts bundling unnecessarily, however, it 
allows us to accurately model the latency of the operation, which is 
particularly important when we have an ialu instruction that generates a 
load/store address.

Use of A would not restrict bundling, but would not let us model 
latencies accurately.  An insn can only have one latency, but the 
latency of an ialu insn varies depending on whether it gets scheduled to 
an M slot or an I slot.

Hence there is a trade off here between getting bundling right or 
getting latencies right.  The code as written gets the latecy right when 
an ialu generates a load/store address, presumably to avoid an AGI 
stall, and gets the bundling right otherwise.
Comment 9 CVS Commits 2004-06-08 15:57:07 UTC
Subject: Bug 15598

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_4-branch
Changes by:	vmakarov@gcc.gnu.org	2004-06-08 15:56:59

Modified files:
	gcc            : ChangeLog 
	gcc/config/ia64: ia64.c 

Log message:
	2004-06-08  Vladimir Makarov  <vmakarov@redhat.com>
	PR target/15598
	* config/ia64/ia64.c (bundling): Add missed TYPE_A.


Comment 10 CVS Commits 2004-06-08 15:58:34 UTC
Subject: Bug 15598

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	vmakarov@gcc.gnu.org	2004-06-08 15:58:29

Modified files:
	gcc            : ChangeLog 
	gcc/config/ia64: ia64.c 

Log message:
	2004-06-08  Vladimir Makarov  <vmakarov@redhat.com>
	PR target/15598
	* config/ia64/ia64.c (bundling): Add missed TYPE_A.


Comment 11 Andrew Pinski 2004-06-08 18:00:44 UTC