[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 --- Comment #24 from Marius Hillenbrand --- Thanks for the quick fix.
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 Eric Botcazou changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #23 from Eric Botcazou --- Thanks a lot for all the work done for this PR.
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 --- Comment #22 from CVS Commits --- The releases/gcc-9 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:29f721366b718b60d4c72d82e42e1e3d0a6405c2 commit r9-9205-g29f721366b718b60d4c72d82e42e1e3d0a6405c2 Author: Eric Botcazou Date: Tue Jan 26 18:54:26 2021 +0100 Fix PR ada/98228 This is the profiled bootstrap failure for s390x/Linux on the mainline, which has been introduced by the modref pass but actually exposing an existing issue in the maybe_pad_type function that is visible on s390x. The issue is too weak a test for the addressability of the inner component. gcc/ada/ Marius Hillenbrand PR ada/98228 * gcc-interface/utils.c (maybe_pad_type): Test the size of the new packable type instead of its alignment for addressability's sake.
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 --- Comment #21 from CVS Commits --- The releases/gcc-10 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:f3e3fc277502626677c59e2a7f3dcefa9f9123b5 commit r10-9303-gf3e3fc277502626677c59e2a7f3dcefa9f9123b5 Author: Eric Botcazou Date: Tue Jan 26 18:54:26 2021 +0100 Fix PR ada/98228 This is the profiled bootstrap failure for s390x/Linux on the mainline, which has been introduced by the modref pass but actually exposing an existing issue in the maybe_pad_type function that is visible on s390x. The issue is too weak a test for the addressability of the inner component. gcc/ada/ Marius Hillenbrand PR ada/98228 * gcc-interface/utils.c (maybe_pad_type): Test the size of the new packable type instead of its alignment for addressability's sake.
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 --- Comment #20 from CVS Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:9c41bcc59c237aaa629e271f88c20a90cb8e0af5 commit r11-6916-g9c41bcc59c237aaa629e271f88c20a90cb8e0af5 Author: Eric Botcazou Date: Tue Jan 26 18:54:26 2021 +0100 Fix PR ada/98228 This is the profiled bootstrap failure for s390x/Linux on the mainline, which has been introduced by the modref pass but actually exposing an existing issue in the maybe_pad_type function that is visible on s390x. The issue is too weak a test for the addressability of the inner component. gcc/ada/ Marius Hillenbrand PR ada/98228 * gcc-interface/utils.c (maybe_pad_type): Test the size of the new packable type instead of its alignment for addressability's sake.
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 --- Comment #19 from Marius Hillenbrand --- Eric, I have bootstrapped and successfully reg-tested your proposed fix on s390x and x86-64. fwict, it works as intended.
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 --- Comment #18 from Marius Hillenbrand --- The fix looks good -- bootstrap succeeded on s390x, both regular and the 4-stage profiledbootstrap-lean. Still running the test suite...
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 --- Comment #17 from Eric Botcazou --- Created attachment 50041 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50041=edit Tentative fix Please give it a try when you get a chance.
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 Eric Botcazou changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org Status|NEW |ASSIGNED CC|ebotcazou at gcc dot gnu.org | --- Comment #16 from Eric Botcazou --- > # High-level flow of the resulting crashes: > > - the procedure sem_type__get_next_interp has an output parameter of > record type sem_type__interp and overwrites that completely. > - in locations that call sem_type__get_next_interp, local variables of > type sem_type__interp get wrapped by maybe_pad_type in an outer > padding record for proper alignment. the padding record has a single > field "F" for the inner record. > - on s390x, that field gets falsely flagged as nonaddressable (see > zoom-in below). > - as a consequence of that flag, type based alias analysis does not > relate the padded record to the alias set of the inner record. > - modref_may_conflict disambiguates references to the local variables > (padded record) from sem_type__get_next_interp actually overwriting > the (inner) record -- "correct" decision based on the data, but > clearly the wrong result. > - as a result, loops that iterate via sem_type__get_next_interp are > "optimized" into endless loops, because their abort condition is > never checked against the updated data. > - these loops overrun All_Interp.Table and trigger assertions or > segfault (i've seen both). Thanks for the detailed investigation. The effect of nonaddressability on alias sets is as expected, but it is invalid to take the address of a nonaddressable field of course.
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 --- Comment #15 from Marius Hillenbrand --- tl;dr: I found the root cause and a way to repro on x86. When the gnat/gcc interface converts gnat entities into tree decls, maybe_pad_type() pads some record types. maybe_pad_type() calls make_packable_type() to potentially pad a record into an integral type. On s390x, we hit that case for sem_type__interp, which is padded from 12 bytes in BLKmode to a TImode. That results in the wrapped record to be flagged as nonaddressable, which causes mayhem in tbaa (one way this blows up below). On x86-64 in contrast, maybe_pad_type() rejects the padding to TI in that specific case, because TI requires 128-bit or larger alignment on x86-64, while a 64-bit alignment is enough to get TI chosen on s390x). When removing that condition, the issue reproduces on x86-64. When I force that rejection on s390x, bootstrapping is successful (tested with bootstrap-lto-lean, which extensively reproduces; not yet with a full profiledbootstrap). tree packable_type = make_packable_type (type, true, align); if (TYPE_MODE (packable_type) != BLKmode) && align >= TYPE_ALIGN (packable_type)) // <- false on x86 type = packable_type; (I also have tweaked the calling convention for sem_type__get_next_interp to mimic that on s390x, with a pointer for the output parameter It) procedure Get_Next_Interp (I : in out Interp_Index; It : out Interp); pragma Export (C, Get_Next_Interp); pragma Export_Procedure (Get_Next_Interp, External => "sem_type__get_next_interp", Mechanism => (I => Value, It => Reference)); pragma No_Inline (Get_Next_Interp); -- causes repro in more places # High-level flow of the resulting crashes: - the procedure sem_type__get_next_interp has an output parameter of record type sem_type__interp and overwrites that completely. - in locations that call sem_type__get_next_interp, local variables of type sem_type__interp get wrapped by maybe_pad_type in an outer padding record for proper alignment. the padding record has a single field "F" for the inner record. - on s390x, that field gets falsely flagged as nonaddressable (see zoom-in below). - as a consequence of that flag, type based alias analysis does not relate the padded record to the alias set of the inner record. - modref_may_conflict disambiguates references to the local variables (padded record) from sem_type__get_next_interp actually overwriting the (inner) record -- "correct" decision based on the data, but clearly the wrong result. - as a result, loops that iterate via sem_type__get_next_interp are "optimized" into endless loops, because their abort condition is never checked against the updated data. - these loops overrun All_Interp.Table and trigger assertions or segfault (i've seen both). # How does the field get marked nonaddressable? maybe_pad_type calls make_packable_type, which attempts to find an integral type that fits the record to be padded; in our case it chooses TI.
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 --- Comment #14 from Marius Hillenbrand --- Comparing x86-64 to s390x, modref_may_conflict makes a mistake when analyzing whether the called function Get_Next_Interp because of incomplete data on alias sets. That specific analysis involves alias sets 2, 5, and 6, which are missing in vec *alias_sets on s390x, while they are present on x86-64. (I'm using -flto-partition=max and only looking at a single LTO partition of an affected function) looking at loops of this kind: while Present (It.Typ) loop Get_Next_Interp (I, It); end loop; optimization goes off the rails because ipa-modref makes incorrect claims about Get_Next_Interp and how it handles "It" (a padding around a record of type info in the Ada frontend, the variable used like an iterator). ipa-modref: call to sem_type__get_next_interp/2320 does not clobber ref: it.F.typ alias sets: 5->5 ltrans.085i.modref claims to read ok data on both x86-64 and s390x, Read modref for sem_type__get_next_interp/2320 loads: Limits: 32 bases, 16 refs Base 0: alias set 1 Ref 0: alias set 1 Every access Base 1: alias set 2 Ref 0: alias set 2 Every access stores: Limits: 32 bases, 16 refs Base 0: alias set 2 Ref 0: alias set 2 access: Parm 1 param offset:0 offset:0 size:96 max_size:96 parm 0 flags: direct noclobber noescape nodirectescape parm 1 flags: direct noescape nodirectescape yet the alias set 2 does not show up on s390x. The padding record (type of It) has an alias-set in its type-decl (5 on s390x, 6 on x86) yet that does not show up in alias.c:alias_sets. Further, the record-type sem_type__interp (i.e., it.F, inside the padding) has alias set 2 assigned on x86-64, which matches the loaded modref data, but has alias-set -1 on s390x. Another discrepancy: the record-type decl sem_type__interp is flagged unaddressable and has TImode on s390x vs BLKmode on x86-64 (and not flagged unaddressable). Could that flag cause the type to not get associated an alias-set?
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 --- Comment #13 from Marius Hillenbrand --- gnat applies different choices for the calling convention on x86 and s390 for Get_Next_Interp. though, by massaging gcc/ada/sem_type.ads, I got them to produce the same GIMPLE. while compiling sem_type.adb, I see the same results from ipa-modref on s390x and x86-64 (as far as covered in dumps from -fdump-ipa-modref-all) yet, the miscompile does not reproduce on x86-64. so, it could be the serialization/deserialization of the ipa-modref info or how that information is used during lto. Coercing same calling convention on x86-64: diff --git a/gcc/ada/sem_type.ads b/gcc/ada/sem_type.ads index 6c6d5eb7fb5..a1d4b9bf60f 100644 --- a/gcc/ada/sem_type.ads +++ b/gcc/ada/sem_type.ads @@ -146,6 +146,9 @@ package Sem_Type is -- was set by a previous call to Get_First_Interp or Get_Next_Interp, the -- next interpretation is placed in It, and I is updated for the next call. -- The end of the list of interpretations is signalled by It.Nam = Empty. + pragma Export (C, Get_Next_Interp); + pragma Export_Procedure (Get_Next_Interp, + Mechanism => (I => Value, It => Reference));
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 --- Comment #12 from Marius Hillenbrand --- found a miscompilation in gnat1 (that I can trigger to cause a segfault), a loop in sem_res.adb:2405 in procedure Resolve (N : Node_Id; Typ : Entity_Id) while Present (It.Typ) loop Get_Next_Interp (I, It); // <- from sem_type.adb end loop; is optimized into an endless loop, apparently by wrongly concluding that Get_Next_Interp would not change It (which it does). while Present (It.Typ) loop 18558fe: e3 20 f1 14 00 12 lt %r2,276(%r15) 1855904: a7 84 0c 23je 185714a 1855908: b3 cd 00 28lgdr %r2,%f8 looping back here: Get_Next_Interp (I, It); 185590c: b9 04 00 3algr%r3,%r10 1855910: c0 e5 00 00 cb 70 brasl %r14,186eff0 1855916: b9 14 00 22lgfr %r2,%r2 185591a: a7 f4 ff f9j 185590c when suppressing ipa-modref info for Get_Next_Interp, we get a sane check and conditional branch instead.
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 --- Comment #11 from Marius Hillenbrand --- Created attachment 49965 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49965=edit Reduced version of gcc/testsuite/gcc.target/s390/md/atomic_compare_exchange-1.c Reduced testcase which fails correlated to the reported issue.
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228
--- Comment #10 from Marius Hillenbrand ---
I've traced back the failing gnat1 to gcc/ada/sem_type.adb. It looks like
during lto, ipa-modref data about that file causes misoptimizations, resulting
in the generated gnat1 to segfault and/or fail assertions. When I selectively
compile sem_type.adb with -fno-ipa-modref (i.e., the LTO step loads ipa-modref
information only from all other translation units), there are only trivial
differences in the gimple in the two variants of sem_type.o (via lto-dump) yet
the resulting gnat1 behaves ok.
The ICE when building gcc/testsuite/gcc.target/s390/target-attribute/tattr-3.c
was an unrelated messup of a build directory.
However, I found gcc/testsuite/gcc.target/s390/md/atomic_compare_exchange-1.c
that fails with -flto -O2 yet works with -flto -fno-ipa-modref -O2 and thus
looks correlated. In the reduced version, the check "f != 3" gets optimized
away since modref claims that b() would not touch memory behind *c, which it
obviously does.
char a;
void __attribute__((noinline)) b(char *c) {
char d = 0;
__atomic_compare_exchange_n(c, , 3, 1, 2, 0);
}
void e(char *c) {
*c = 0;
b(c);
char f = *c;
if (f != 3)
__builtin_abort();
}
int main() { e(); }
in the dump ...ltrans0.ltrans.106t.fre3:
... (starting at *c = 0)
Value numbering store a to 0
Setting value number of .MEM_4 to .MEM_4 (changed)
Value numbering stmt = # DEBUG D#2 =>
Value numbering stmt = b.constprop ();
Setting value number of .MEM_5 to .MEM_5 (changed)
Value numbering stmt = f_3 = a;
ipa-modref: in main/3, call to b.constprop/7 does not clobber a 0->0
Setting value number of f_3 to 0 (changed)
...
Block 1: BB4 found not executable
(resulting in always calling __builtin_abort()).
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 --- Comment #9 from Marius Hillenbrand --- The failures in gnat1 during bootstrap have not led me anywhere, yet I found useful ICEs while running the test suite on the mostly-bootstrapped tree. The failing code in gnat appears compiled correctly, and I am not familiar enough with Ada to dig deeper (e.g., the segfault results from overrunning the last element of All_Interp.Table, which looks "correct" locally but maybe is the result of a corruption of that table earlier). The ICE when building gcc/testsuite/gcc.target/s390/target-attribute/tattr-3.c is caused by a wrongly resolved struct offset for lang_hooks.types.type_promotes_to() in s390-c.c:s390_fn_types_compatible() in if (lang_hooks.types_compatible_p ( lang_hooks.types.type_promotes_to (in_type), lang_hooks.types.type_promotes_to (b_arg_type))) ... the calls to type_promotes_to() actually call lang_hooks.types.generic_p (two entries, 0x10, earlier in that struct), which returns 0. c_types_compatible_p expects non-null arguments and then segfaults. Program received signal SIGSEGV, Segmentation fault. c_types_compatible_p (x=0x0, x@entry=, y=0x0) at ../../gcc/c/c-objc-common.c:377 377 return comptypes (TYPE_MAIN_VARIANT (x), TYPE_MAIN_VARIANT (y)); (gdb) bt #0 c_types_compatible_p (x=0x0, x@entry=, y=0x0) at ../../gcc/c/c-objc-common.c:377 #1 0x012f72fe in s390_fn_types_compatible (arglist=, typeindex=) at ../../gcc/config/s390/s390-c.c:773 #2 s390_resolve_overloaded_builtin (loc=, ob_fndecl=0x3fffb3ac400, passed_arglist=0x3fffb3f26b8) at ../../gcc/config/s390/s390-c.c:951 ... the stage2 cc1 uses the correct offset yet then miscompiles the stage3 cc1 gcc/config/s390/s390-c.c:773 if (lang_hooks.types_compatible_p ( 12f72d2: c4 18 00 b3 97 4f lgrl%r1,296a170 offset should be +0x268 12f72d8: c4 88 00 b3 96 a0 lgrl%r8,296a018 12f72de: b9 04 00 2a lgr %r2,%r10 12f72e2: 0d e1 basr%r14,%r1 ...
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 --- Comment #8 from Marius Hillenbrand --- Potential duplicate observed for m68k: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98341 Very similar error messages during bootstrap with lto.
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 --- Comment #7 from Marius Hillenbrand --- -flto alone is enough to cause the miscompile. make bootstrap with this config fails in stage3, since the same commit that introduced ipa-modref. when building the Ada runtime libraries with the stage3 gnat, which is the first stage that was compiled with -flto, gnat fails with a segfault: Program received signal SIGSEGV, Segmentation fault. 0x0186f062 in sem_type__get_next_interp (i=53941, it=...) at ../../gcc/ada/sem_type.adb:2425 2425 It := All_Interp.Table (I); (gdb) bt #0 0x0186f062 in sem_type__get_next_interp (i=53941, it=...) at ../../gcc/ada/sem_type.adb:2425 #1 0x01855966 in sem_res__resolve (n=, typ=) at ../../gcc/ada/atree.adb:1438 #2 0x0175c1a6 in sem_res__analyze_and_resolve__2 (typ=1454, n=40376) at ../../gcc/ada/sem_res.adb:329 #3 sem_ch5__analyze_if_statement__analyze_cond_then (cnode=cnode@entry=40375) at ../../gcc/ada/sem_ch5.adb:1801 #4 0x0175eaac in sem_ch5__analyze_if_statement (n=) at ../../gcc/ada/sem_ch5.adb:1776 #5 0x01668b3c in sem__analyze (n=) at ../../gcc/ada/sem.adb:306 #6 0x0175bddc in sem_ch5__analyze_statements (l=) at ../../gcc/ada/table.adb:155 #7 0x0169808e in sem_ch11__analyze_handled_statements (n=) at ../../gcc/ada/sem_ch11.adb:426 #8 0x01668e92 in sem__analyze (n=) at ../../gcc/ada/sem.adb:297 #9 0x0176833a in sem_ch6__analyze_subprogram_body_helper (n=) at ../../gcc/ada/sem_ch6.adb:5204 #10 sem_ch6__analyze_subprogram_body (n=) at ../../gcc/ada/sem_ch6.adb:2818 #11 0x0166911c in sem__analyze (n=) at ../../gcc/ada/sem.adb:547 #12 0x016f7fb4 in sem_ch3__analyze_declarations (l=) at ../../gcc/ada/table.adb:155 #13 0x017881fa in sem_ch7__analyze_package_body_helper (n=2348) at ../../gcc/ada/sem_ch7.adb:954 #14 sem_ch7__analyze_package_body (n=) at ../../gcc/ada/sem_ch7.adb:180 #15 0x0166910e in sem__analyze (n=) at ../../gcc/ada/sem.adb:444 #16 0x016931fc in sem_ch10__analyze_compilation_unit (n=) at ../../gcc/ada/sem_ch10.adb:913 #17 0x01668abe in sem__analyze (n=n@entry=2326) at ../../gcc/ada/sem.adb:180 #18 0x01669c8c in sem__semantics__do_analyze () at ../../gcc/ada/sem.adb:1421 #19 sem__semantics (comp_unit=) at ../../gcc/ada/sem.adb:1615 #20 0x015881a4 in _ada_frontend () at ../../gcc/ada/frontend.adb:422 #21 0x0193cb1e in _ada_gnat1drv () at ../../gcc/ada/osint.adb:2130 #22 0x012a2be6 in gnat_parse_file () at ../../gcc/ada/gcc-interface/misc.c:118 #23 0x01ee0b2c in compile_file () at ../../gcc/toplev.c:457 #24 0x0128ac78 in do_compile () at ../../gcc/toplev.c:2193 #25 _ZN6toplev4mainEiPPc (this=0x3ffee5e, argc=, argv=) at ../../gcc/toplev.c:2332 #26 0x0128b824 in main (argc=, argv=) at ../../gcc/main.c:39 backtrace from the failure in profiledbootstrap: Breakpoint 2, system__assertions__raise_assert_failure (msg=...) at ../../gcc/ada/libgnat/s-assert.adb:43 43 procedure Raise_Assert_Failure (Msg : String) is (gdb) bt #0 system__assertions__raise_assert_failure (msg=...) at ../../gcc/ada/libgnat/s-assert.adb:43 #1 0x01284eba in atree__ekind (e=) at ../../gcc/ada/atree.adb:931 #2 0x019c5c28 in atree__ekind (e=, e=) at ../../gcc/ada/atree.adb:1438 #3 0x022f0c50 in sem_type__disambiguate (n=, i1=, i2=, typ=1409) at ../../gcc/ada/atree.adb:1438 #4 0x0226222e in sem_res__valid_conversion (n=, target=, operand=, report_errs=) at ../../gcc/ada/sem_type.ads:65 #5 0x01ae6bd0 in sem_res__resolve_type_conversion (typ=, n=) at ../../gcc/ada/sem_res.adb:11617 #6 sem_res__resolve (n=, typ=typ@entry=100) at ../../gcc/ada/sem_res.adb:3319 #7 0x01ae707a in sem_res__resolve_op_expon (typ=, n=) at ../../gcc/ada/atree.adb:1438 #8 sem_res__resolve (n=, typ=) at ../../gcc/ada/sem_res.adb:3266 #9 0x020b7c76 in sem_res__resolve_arithmetic_op (n=, typ=) at ../../gcc/ada/sem_res.adb:5637 #10 0x01ae67d2 in sem_res__resolve (n=, typ=) at ../../gcc/ada/atree.adb:1438 #11 0x02269d54 in sem_ch5__analyze_assignment (n=) at ../../gcc/ada/atree.adb:1438 #12 0x01a6617a in sem__analyze (n=) at ../../gcc/ada/sem.adb:150 #13 0x01c3db40 in sem_ch5__analyze_statements (l=) at ../../gcc/ada/nlists.adb:953 #14 0x022ff2dc in sem_ch5__analyze_loop_statement (n=) at ../../gcc/ada/sem_ch5.adb:3354 #15 0x01a662c0 in sem__analyze (n=) at ../../gcc/ada/sem.adb:336 #16 0x01c3db40 in sem_ch5__analyze_statements (l=) at ../../gcc/ada/nlists.adb:953 #17 0x022299c0 in sem_ch11__analyze_handled_statements (n=) at ../../gcc/ada/sem_ch11.adb:426 #18 0x01a66188 in sem__analyze (n=) at ../../gcc/ada/sem.adb:297 #19 0x021957ca in sem_ch6__analyze_subprogram_body_helper (n=) at ../../gcc/ada/sem_ch6.adb:5204 #20 sem_ch6__analyze_subprogram_body (n=) at
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 Marius Hillenbrand changed: What|Removed |Added CC||mhillen at linux dot ibm.com --- Comment #6 from Marius Hillenbrand --- I reproduced and bisected with the config shared by Matthias. The issue begins with the introduction of ipa-modref. There is an inbetween range of commits that fail with a different symptom, yet this commit is the first I found that exactly fails as initially reported here: commit d119f34c952f8718fdbabc63e2f369a16e92fa07 Author: Jan Hubicka Date: Sun Sep 20 07:25:16 2020 +0200 New modref/ipa_modref optimization passes 2020-09-19 David Cepelik Jan Hubicka * Makefile.in: Add ipa-modref.c and ipa-modref-tree.c. * alias.c: (reference_alias_ptr_type_1): Export. * alias.h (reference_alias_ptr_type_1): Declare. * common.opt (fipa-modref): New. * gengtype.c (open_base_files): Add ipa-modref-tree.h and ipa-modref.h * ipa-modref-tree.c: New file. * ipa-modref-tree.h: New file. * ipa-modref.c: New file. * ipa-modref.h: New file. * lto-section-in.c (lto_section_name): Add ipa_modref. * lto-streamer.h (enum lto_section_type): Add LTO_section_ipa_modref. * opts.c (default_options_table): Enable ipa-modref at -O1+. * params.opt (-param=modref-max-bases, -param=modref-max-refs, -param=modref-max-tests): New params. * passes.def: Schedule pass_modref and pass_ipa_modref. * timevar.def (TV_IPA_MODREF): New timevar. (TV_TREE_MODREF): New timevar. * tree-pass.h (make_pass_modref): Declare. (make_pass_ipa_modref): Declare. * tree-ssa-alias.c (dump_alias_stats): Include ipa-modref-tree.h and ipa-modref.h (alias_stats): Add modref_use_may_alias, modref_use_no_alias, modref_clobber_may_alias, modref_clobber_no_alias, modref_tests. (dump_alias_stats): Dump new stats. (nonoverlapping_array_refs_p): Fix formating. (modref_may_conflict): New function. (ref_maybe_used_by_call_p_1): Use it. (call_may_clobber_ref_p_1): Use it. (call_may_clobber_ref_p): Update. (stmt_may_clobber_ref_p_1): Update. * tree-ssa-alias.h (call_may_clobber_ref_p_1): Update.
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 --- Comment #5 from Martin Liška --- I can confirm that as well with --enable-checking=yes.
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-12-14 CC||ebotcazou at gcc dot gnu.org --- Comment #4 from Eric Botcazou --- This looks like a miscompilation of the compiler so probably not reproducible with a cross compiler.
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 --- Comment #3 from Matthias Klose --- I still see this with 20201212, 54f75d8fb3f:a415eda93e0:cc9b9c0b68233d38a26f7acd68cc5f9a8fc4d994
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 --- Comment #2 from Matthias Klose --- you have: --enable-languages=c,c++,objc,fortran,obj-c++,go,d --enable-checking=release --disable-werror --with-gxx-include-dir=/usr/include/c++/11 --enable-ssp --disable-libssp --disable-libvtv --disable-cet --disable-libcc1 --disable-plugin --with-system-zlib --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --with-default-libstdcxx-abi=gcc4-compatible --enable-libphobos --enable-version-specific-runtime-libs --with-gcc-major-version-only --enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function --program-suffix=-11 --without-system-libunwind --with-tune=zEC12 --with-arch=z196 --with-long-double-128 --enable-decimal-float --build=s390x-suse-linux --host=s390x-suse-linux so apparently some additional flags: --enable-libstdcxx-allocator=new --with-default-libstdcxx-abi=gcc4-compatible --enable-gnu-indirect-function and a different base line: --with-tune=zEC12 --with-arch=z196
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 --- Comment #1 from Martin Liška --- It builds for me: https://build.opensuse.org/build/devel:gcc/SLE-12/s390x/gcc11/_log Do you know what's the difference?
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0 Keywords||build
