Bug 17356 - [4.0 Regression] [Ada] [ia64] ACATS c41325a & other ICE, also while building libada
Summary: [4.0 Regression] [Ada] [ia64] ACATS c41325a & other ICE, also while building ...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: rtl-optimization (show other bugs)
Version: 4.0.0
: P2 normal
Target Milestone: 4.0.3
Assignee: Jim Wilson
URL:
Keywords: build, EH, ice-checking, ice-on-valid-code
Depends on:
Blocks:
 
Reported: 2004-09-08 14:49 UTC by Andreas Schwab
Modified: 2005-10-31 23:25 UTC (History)
2 users (show)

See Also:
Host:
Target: ia64-suse-linux
Build:
Known to work: 4.1.0
Known to fail: 4.0.0 4.0.2
Last reconfirmed: 2005-10-17 02:00:49


Attachments
patch to fix ia64-linux libada build failure (650 bytes, patch)
2005-10-17 02:03 UTC, Jim Wilson
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Schwab 2004-09-08 14:49:27 UTC
The Ada compiler now bootstraps ok, but when building the runtime library this 
ICE occurs:   
   
../../xgcc -B../../ -c -g -O2 -fPIC -DUSE_GAS_SYMVER      -W -Wall -gnatpg    
a-teioed.adb -o a-teioed.o   
a-teioed.adb: In function `Ada.Text_Io.Editing.Format_Number':   
a-teioed.adb:843: error: Call edges for non-call insn in bb 526   
a-teioed.adb:843: error: Call edges for non-call insn in bb 525   
a-teioed.adb:843: error: Call edges for non-call insn in bb 524   
a-teioed.adb:843: error: Call edges for non-call insn in bb 523   
a-teioed.adb:843: error: Call edges for non-call insn in bb 522   
a-teioed.adb:843: error: Call edges for non-call insn in bb 521   
a-teioed.adb:843: error: Call edges for non-call insn in bb 520   
a-teioed.adb:843: error: Call edges for non-call insn in bb 519   
a-teioed.adb:843: error: Call edges for non-call insn in bb 518   
a-teioed.adb:843: error: Call edges for non-call insn in bb 517   
a-teioed.adb:843: error: Call edges for non-call insn in bb 516   
a-teioed.adb:843: error: Call edges for non-call insn in bb 515   
a-teioed.adb:843: error: Call edges for non-call insn in bb 514   
a-teioed.adb:843: error: Call edges for non-call insn in bb 513   
a-teioed.adb:843: error: Call edges for non-call insn in bb 512   
+===========================GNAT BUG DETECTED==============================+   
| 3.5.0 20040908 (experimental) (ia64-suse-linux-gnu) GCC error:           |   
| verify_flow_info failed                                                  |   
| Error detected at a-teioed.adb:2909:1                                    |
Comment 1 Andrew Pinski 2004-10-02 04:21:02 UTC
Does this happen anymore or is it breaking somewhere else now?
Comment 2 Andreas Schwab 2004-10-22 09:40:55 UTC
It's still exactly the same, all the time. 
Comment 3 Debian GCC Maintainers 2004-10-31 07:24:57 UTC
same with 20041030
Comment 4 Andrew Pinski 2004-12-01 18:19:01 UTC
I saw that it built now and you posted the results so is this fixed?
http://gcc.gnu.org/ml/gcc-testresults/2004-12/msg00014.html
Comment 5 Andreas Schwab 2004-12-01 20:54:44 UTC
I've only worked around it by using -O0.  The bug is still present and 
responsible for most of the testsuite failures. 
Comment 6 Laurent GUERBY 2004-12-05 16:42:22 UTC
152 ACATS test fail (ICE in verfy_flow_info after error: call edges) on ia64-linux.
Comment 7 Laurent GUERBY 2004-12-05 21:02:36 UTC
The simplest ACATS test I could find that exhibits this ICE is c41325a.
Here is the standalone code with no ties to ACATS support. Removing anything
makes the ICE go away according to Andreas Schwab.

$ cat rep.ads
package Rep is
     procedure FAILED (M : in String);
     procedure RESULT;

     procedure Test (S1, S2 : in String);

   function Ident_Int(X : Integer) return Integer;
   function Ident_Bool (X : Boolean) return Boolean;
end Rep;

$ cat rep.adb
package body Rep is
     procedure Test (S1, S2 : in String) is begin null; end;
     procedure FAILED (M : in String) is
     begin
        raise Program_Error;
     end FAILED;

     procedure RESULT is begin null; end;

   function Ident_Int(X : Integer) return Integer is
   begin
      return X;
   end;

   function Ident_Bool (X : Boolean) return Boolean is
   begin
      return X;
   end;



end Rep;

$ cat pia.adb
with Rep; use Rep;
PROCEDURE PIA IS
   
     PACKAGE P IS
          TYPE CATARRAY IS ARRAY (INTEGER RANGE <>) OF INTEGER;

          TYPE ARRAY_1 IS ARRAY (1..10) OF INTEGER;
          TYPE ARRAY_2 IS ARRAY (1..4, 1..4) OF INTEGER;
          TYPE ARRAY_3 IS ARRAY (1..2, 1..3, 1..4) OF INTEGER;
          TYPE ARRAY_4 IS ARRAY (1..10) OF BOOLEAN;
          TYPE ARRAY_5 IS ARRAY (1..4, 1..4) OF BOOLEAN;
          TYPE ARRAY_6 IS ARRAY (1..2, 1..3, 1..4) OF BOOLEAN;

          OBJ_ARA_1 : ARRAY_1 := (1..10 => IDENT_INT(0));
          OBJ_ARA_2 : ARRAY_2 := (1..4 => (1..4 => IDENT_INT(0)));
          OBJ_ARA_3 : ARRAY_3 := (1..2 => (1..3 =>
                                               (1..4 => IDENT_INT(0))));
          OBJ_ARA_4 : ARRAY_4 := (1..10 => IDENT_BOOL(FALSE));
          OBJ_ARA_5 : ARRAY_5 := (1..4 => (1..4 => IDENT_BOOL(FALSE)));
          OBJ_ARA_6 : ARRAY_6 := (1..2 => (1..3 =>
                                          (1..4 => IDENT_BOOL(FALSE))));
          OBJ_ARA_7 : CATARRAY (1..10) := (1..10 => IDENT_INT(0));
          OBJ_ARA_20 : CATARRAY (1..20) := (1..10 => 1,
                                                11..20 => IDENT_INT(0));
     END P;

     VAR_ARA_1 : P.ARRAY_1 := (1..10 => IDENT_INT(1));
     VAR_ARA_2 : P.ARRAY_2 := (1..4 => (1..4 => IDENT_INT(1)));
     VAR_ARA_3 : P.ARRAY_3 := (1..2 => (1..3 =>
                                               (1..4 => IDENT_INT(1))));
     VAR_ARA_4 : P.ARRAY_4 := (1..10 => IDENT_BOOL(TRUE));
     VAR_ARA_5 : P.ARRAY_5 := (1..4 => (1..4 => IDENT_BOOL(TRUE)));
     VAR_ARA_6 : P.ARRAY_6 := (1..2 => (1..3 =>
                                           (1..4 => IDENT_BOOL(TRUE))));
     VAR_ARA_7 : P.CATARRAY (1..10) := (1..10 => IDENT_INT(1));
     VAR_ARA_8 : P.ARRAY_4 := (1..10 => IDENT_BOOL(TRUE));
     VAR_ARA_20 : P.CATARRAY (1..20) := (1..20 => IDENT_INT(0));
     
BEGIN
     TEST ("C41325A", "CHECK THAT IMPLICITLY DECLARED ENTITIES CAN " &
                      "BE SELECTED FROM OUTSIDE THE PACKAGE USING AN " &
                      "EXPANDED NAME, FOR AN ARRAY TYPE");

     -- CASE 1: MULTIDIMENSIONAL ARRAYS.

     IF P."=" (VAR_ARA_2, P.OBJ_ARA_2) THEN
          FAILED ("INCORRECT RESULTS FROM EXPANDED NAME - 1");
     END IF;

     IF P."=" (VAR_ARA_5, P.OBJ_ARA_5) THEN
          FAILED ("INCORRECT RESULTS FROM EXPANDED NAME - 2");
     END IF;

     IF P."/=" (VAR_ARA_2, P.ARRAY_2'(1..4 => (1..4 => 1))) THEN
          FAILED ("INCORRECT RESULTS FROM EXPANDED NAME - 3");
     END IF;

     IF P."/=" (VAR_ARA_5, P.ARRAY_5'(1..4 => (1..4 => TRUE))) THEN
          FAILED ("INCORRECT RESULTS FROM EXPANDED NAME - 4");
     END IF;

     IF P."=" (VAR_ARA_3, P.OBJ_ARA_3) THEN
          FAILED ("INCORRECT RESULTS FROM EXPANDED NAME - 5");
     END IF;

     IF P."/=" (VAR_ARA_6, P.ARRAY_6'(1..2 =>(1..3 =>(1..4 => TRUE)))) 
          THEN
               FAILED ("INCORRECT RESULTS FROM EXPANDED NAME - 6");
     END IF;

     -- CASE 2: ONE DIMENSIONAL ARRAYS.

     IF P."=" (VAR_ARA_1, P.OBJ_ARA_1) THEN
          FAILED ("INCORRECT RESULTS FROM EXPANDED NAME - 7");
     END IF;

     IF P."/=" (VAR_ARA_1, P.ARRAY_1'(1..10 => 1)) THEN
          FAILED ("INCORRECT RESULTS FROM EXPANDED NAME - 8");
     END IF;

     VAR_ARA_20 := P."&" (VAR_ARA_7, P.OBJ_ARA_7);
     IF P."/=" (VAR_ARA_20, P.OBJ_ARA_20) THEN
          FAILED ("INCORRECT RESULTS FROM EXPANDED NAME - 9");
     END IF;

     IF P."<" (VAR_ARA_1, P.OBJ_ARA_1) THEN
          FAILED ("INCORRECT RESULTS FROM EXPANDED NAME - 10");
     END IF;

     IF P.">" (P.OBJ_ARA_1, VAR_ARA_1) THEN
          FAILED ("INCORRECT RESULTS FROM EXPANDED NAME - 11");
     END IF;

     IF P."<=" (VAR_ARA_1, P.OBJ_ARA_1) THEN
          FAILED ("INCORRECT RESULTS FROM EXPANDED NAME - 12");
     END IF;

     IF P."<=" (VAR_ARA_1, P.ARRAY_1'(1..10 => 1)) THEN
          NULL;
     ELSE
          FAILED ("INCORRECT RESULTS FROM EXPANDED NAME - 13");
     END IF;

     IF P.">=" (VAR_ARA_1, P.ARRAY_1'(1..10 => 2)) THEN
          FAILED ("INCORRECT RESULTS FROM EXPANDED NAME - 14");
     END IF;

     IF P.">=" (VAR_ARA_1, P.ARRAY_1'(1..10 => 1)) THEN
          NULL;
     ELSE
          FAILED ("INCORRECT RESULTS FROM EXPANDED NAME - 15");
     END IF;

     VAR_ARA_8 := P."NOT" (VAR_ARA_4);
     IF P."/=" (VAR_ARA_8, P.OBJ_ARA_4) THEN
          FAILED ("INCORRECT RESULTS FROM EXPANDED NAME - 16");
     END IF;

     VAR_ARA_8 := P."OR" (VAR_ARA_4, P.OBJ_ARA_4);
     IF P."=" (VAR_ARA_8, P.OBJ_ARA_4) THEN
          FAILED ("INCORRECT RESULTS FROM EXPANDED NAME - 17");
     END IF;

     VAR_ARA_8 := P."AND" (VAR_ARA_4, P.OBJ_ARA_4);
     IF P."/=" (VAR_ARA_8, P.OBJ_ARA_4) THEN
          FAILED ("INCORRECT RESULTS FROM EXPANDED NAME - 18");
     END IF;

     VAR_ARA_8 := P."XOR" (VAR_ARA_4, P.OBJ_ARA_4);
     IF P."=" (VAR_ARA_8, P.OBJ_ARA_4) THEN
          FAILED ("INCORRECT RESULTS FROM EXPANDED NAME - 19");
     END IF;

     RESULT;
END;

$ gnatmake -f -O2 pia
# leads to the ICE
Comment 8 Andrew Pinski 2004-12-06 21:57:24 UTC
Hmm, looks like something changed recently:
http://gcc.gnu.org/ml/gcc-testresults/2004-12/msg00280.html
http://gcc.gnu.org/ml/gcc-testresults/2004-12/msg00248.html
Or those results compiled at -O0?
Comment 9 Andrew Pinski 2004-12-06 21:58:33 UTC
Ignore the first link, that was for 3.4.4.
Comment 10 Laurent GUERBY 2004-12-06 22:24:02 UTC
(In reply to comment #8)
> Hmm, looks like something changed recently:
> http://gcc.gnu.org/ml/gcc-testresults/2004-12/msg00248.html
> Or those results compiled at -O0?

Yes the 4.0 run was done at -O0 per my request and Andreas sent me the full
ACATS log, I've used it to file some new PRs and add some ia64 information on
existing PRs.
Comment 11 Andrew Pinski 2005-01-21 18:47:54 UTC
Removing the target milestone as per <http://gcc.gnu.org/ml/gcc/2005-01/msg01255.html> as this 
is only known to happen in Ada.
Comment 12 Andreas Schwab 2005-02-27 15:09:20 UTC
Only happens with --enable-checking. 
Comment 13 Mark Mitchell 2005-08-22 01:42:30 UTC
Ada bugs are not release critical; removing target milestone.
Comment 14 Andrew Pinski 2005-10-15 22:26:08 UTC
(In reply to comment #13)
> Ada bugs are not release critical; removing target milestone.

Even though this is only known to effect Ada, it could most likely effect C++ also, just nobody has found a testcase for this.
Comment 15 Jim Wilson 2005-10-17 02:00:48 UTC
It is dying in rest_of_handle_flow2 -> split_all_insns -> verify_flow_info.  We have non-call insns with EDGE_ABNORMAL_CALL edges attached to them.

The insns are coming from post-reload call insn splits.  Before splitting, we have

(call_insn 118 116 3807 4 (parallel [
            (set (reg:OI 8 r8)
                (call (mem:DI (symbol_ref:DI ("ada__text_io__editing__parse_num\ber_string") [flags 0x3] <function_decl 0x2a9590de00 ada__text_io__editing__par\se_number_string>) [0 S8 A64])
                    (const_int 1 [0x1])))
            (clobber (reg:DI 320 b0))
            (clobber (scratch:DI))
            (clobber (scratch:DI))
        ]) 257 {call_value_gp} (insn_list:REG_DEP_TRUE 117 (nil))
    (expr_list:REG_EH_REGION (const_int 1 [0x1])
        (nil))
    (expr_list:REG_DEP_TRUE (use (reg:DI 1 r1))
        (expr_list:REG_DEP_TRUE (use (reg:TI 120 out0 [ D.1574 ]))
            (nil))))

after splitting we have

(call_insn 4891 116 4892 4 (parallel [
            (set (reg:OI 8 r8)
                (call (mem:DI (symbol_ref:DI ("ada__text_io__editing__parse_num\ber_string") [flags 0x3] <function_decl 0x2a9590de00 ada__text_io__editing__par\se_number_string>) [0 S8 A64])
                    (const_int 0 [0x0])))
            (clobber (reg:DI 320 b0))
        ]) 254 {call_value_nogp} (nil)
    (expr_list:REG_EH_REGION (const_int 1 [0x1])
        (nil))
    (expr_list:REG_DEP_TRUE (use (reg:DI 1 r1))
        (expr_list:REG_DEP_TRUE (use (reg:TI 120 out0 [ D.1574 ]))
            (nil))))

(insn 4892 4891 4893 4 (set (reg:DI 1 r1)
        (plus:DI (reg/f:DI 111 loc79)
            (const_int -80 [0xffffffffffffffb0]))) 105 {adddi3} (nil)
    (nil))

(insn 4893 4892 3807 4 (set (reg:DI 1 r1)
        (mem:DI (reg:DI 1 r1) [0 S8 A64])) 5 {*movdi_internal} (nil)
    (expr_list:REG_EH_REGION (const_int 1 [0x1])
        (nil)))

We call find_bb_boundaries to split this into two blocks, and then purge_dead_edges should delete the abnormal call edge on the load.

But there is a problem here... Ada sets flag_non_call_exceptions by default.  So the load is a trapping insn, just not a call-trapping insn.

In purge_dead_edges, we first verify that an EH edge is OK, then we verify that an abnormal call edge is OK.  But since an abnormal call edge is always an EH edge, the first test triggers, and passes, because we do need an EH edge here.

We can fix this problem by switching the order of the tests.

With this patch, a cross-compiler ada build got all of the way to gnattools, where it died building make.adb.  This means libada built successfully.  The make.adb error is a different unrelated problem.
gcc -c -I./ -I/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/adalib/../adainclude -\I/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/adalib/ -I. -I/home/wilson/GCC/gcc/\gcc/ada -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototype\s -fno-common -gnatpg -gnata -I- /home/wilson/GCC/gcc/gcc/ada/gnatvsn.adb
gcc -c -I./ -I/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/adalib/../adainclude -\I/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/adalib/ -I. -I/home/wilson/GCC/gcc/\gcc/ada -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototype\s -fno-common -gnatpg -gnata -I- /home/wilson/GCC/gcc/gcc/ada/make.adb
make.adb:3577:45: Unmatched actual in call
make.adb:3581:45: Unmatched actual in call
make.adb:3804:13: invalid parameter list in call (use -gnatf for details)
make.adb:5709:10: invalid parameter list in call (use -gnatf for details)
mlib.ads:75:15: "Attribute" is undefined
mlib.ads:75:28: "Time_Stamps" is undefined

I am assuming this is good enough to close the problem after a proper bootstrap test.  I'll have to try a native ia64 bootstrap now. 
Comment 16 Jim Wilson 2005-10-17 02:03:14 UTC
Created attachment 10005 [details]
patch to fix ia64-linux libada build failure

And here's the patch.  It is simple enough that it should be safe.
Comment 17 Andreas Schwab 2005-10-17 12:06:52 UTC
Bootstrap was successful and most Ada tests pass now (http://gcc.gnu.org/ml/gcc-testresults/2005-10/msg00730.html).
Comment 18 CVS Commits 2005-10-18 00:23:00 UTC
Subject: Bug 17356

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	wilson@gcc.gnu.org	2005-10-18 00:22:53

Modified files:
	gcc            : ChangeLog cfgrtl.c 

Log message:
	Fix IA-64 libada build failure, abnormal call edges on non-call insns.
	PR rtl-optimization/17356
	* cfgrtl.c (purge_dead_edges): Check for EDGE_ABNORMAL_CALL before
	checking for EDGE_EH.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.10176&r2=2.10177
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cfgrtl.c.diff?cvsroot=gcc&r1=1.181&r2=1.182

Comment 19 Jim Wilson 2005-10-18 00:52:25 UTC
Fixed on mainline, still broken on gcc-4.0.x branch.  I've started a builds to test it.  This will take a while.
Comment 20 Andrew Pinski 2005-10-18 00:56:54 UTC
(In reply to comment #19)
> Fixed on mainline, still broken on gcc-4.0.x branch.  I've started a builds to
> test it.  This will take a while.

Removing the 4.1 regression marker than since it will be a while.
Comment 21 Jim Wilson 2005-10-19 23:10:47 UTC
I done bootstrap tests for the gcc-4.0.x branch.  I bootstrapped all default languages plus ada with and without the patch.  There were no regressions.  There was also no failure as reported in the PR, which seemed funny, until I reread the PR.

The failures reported here only happen with --enable-checking.  So what we have here is a minor internal inconsistency, which has caused no known end user problems.  From my investigation, I think the worst this problem will cause is missed optimizations.  Since nothing is seriously broken, I think applying the patch to gcc-4.0 branch is an unnecessary risk.

I no longer think my patch is completely safe, as I now think I screwed up.  I think there are 3 kinds of edges we need to deal with here, EH edges, abnormal call EH edges, and abnormal call non-EH edges, and we need to perform both tests for the abnormal call EH edges instead of switching the order of the tests as I did.  I need to look at this a bit more and check to see if this is the case.  If I did screw up, then I've got plenty of time to fix this before the gcc-4.1 release so things are OK there.  But on the gcc-4.0.x branch, I'd be making things worse than they already are.  Hence, I'd rather leave well enough alone on the gcc-4.0.x branch.

In summary, I think we should close this as fixed in gcc-4.1 and as a wontfix for gcc-4.0.  Unless someone wants to argue otherwise.
Comment 22 Jim Wilson 2005-10-31 23:24:43 UTC
Subject: Bug 17356

Author: wilson
Date: Mon Oct 31 23:24:36 2005
New Revision: 106297

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106297
Log:
Rewrite fix for PR 17356, fix for enable checking ada build failure.
cfgrtl.c (purge_dead_edges): Undo last change.  In EDGE_EH code,
add check for CALL_INSN if EDGE_ABRNOMAL_CALL true.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cfgrtl.c

Comment 23 Jim Wilson 2005-10-31 23:25:24 UTC
Fixed for gcc-4.1.  Won't fix for gcc-4.0.3.