Bug 17356

Does this happen anymore or is it breaking somewhere else now?

It's still exactly the same, all the time. 

same with 20041030

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

I've only worked around it by using -O0.  The bug is still present and 
responsible for most of the testsuite failures. 

152 ACATS test fail (ICE in verfy_flow_info after error: call edges) on ia64-linux.

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

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?

Ignore the first link, that was for 3.4.4.

(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.

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.

Only happens with --enable-checking. 

Ada bugs are not release critical; removing target milestone.

(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.

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. 

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.

Bootstrap was successful and most Ada tests pass now (http://gcc.gnu.org/ml/gcc-testresults/2005-10/msg00730.html).

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

Fixed on mainline, still broken on gcc-4.0.x branch.  I've started a builds to test it.  This will take a while.

(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.

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.

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

Fixed for gcc-4.1.  Won't fix for gcc-4.0.3.