https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228
--- Comment #10 from Marius Hillenbrand <mhillen at linux dot ibm.com> ---
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, &d, 3, 1, 2, 0);
}
void e(char *c) {
*c = 0;
b(c);
char f = *c;
if (f != 3)
__builtin_abort();
}
int main() { e(&a); }
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 => &a
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()).
