https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101876
--- Comment #5 from Marius Hillenbrand ---
The root cause is not the difference in alignment between vector types in
itself, but the resulting "confusion" in the type system when the #pragma GCC
target switches the default vector alignment.
It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101876
--- Comment #4 from Marius Hillenbrand ---
*** Bug 101877 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101877
Marius Hillenbrand changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101876
--- Comment #3 from Marius Hillenbrand ---
The issue is caused by inconsistent alignment of vector_types between the types
(a) expected or returned by builtin functions and (b) the typedef in the
example code. In the failing cases, there's a mis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101877
--- Comment #1 from Marius Hillenbrand ---
After narrowing down what triggers this bug, it is most likely a duplicate of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101876
when the pragma sets 'vx' before the typedef, then the resulting type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101876
--- Comment #2 from Marius Hillenbrand ---
Narrowed down what triggers the issue after experimenting with another example:
when the pragma sets 'vx' before the typedef, then the resulting type
definition appears broken. when enabling 'vx' only a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101877
Bug ID: 101877
Summary: [s390x] ICE: canonical types differ for identical
types when #pragma GCC target enables vector support
Product: gcc
Version: 12.0
Status: UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101876
--- Comment #1 from Marius Hillenbrand ---
Comparing results with -mdebug, the variant that should match is ignored
with -march=z13:
...
s390_resolve_overloaded_builtin, code = 606, __builtin_s390_vec_permi -
overloaded
checking variant numb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101876
Bug ID: 101876
Summary: [290x] vector builtin vec_permi fails to resolve with
#pragma GCC target
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100552
--- Comment #1 from Marius Hillenbrand ---
Indeed, that line should not use the bash-specific pattern substitution and
instead like this:
diff --git a/gcc/configure.ac b/gcc/configure.ac
index e9ba2af548a..4e788019d99 100644
--- a/gcc/configur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228
--- Comment #24 from Marius Hillenbrand ---
Thanks for the quick fix.
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.
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...
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_packabl
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
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.
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
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&action=edit
Reduced version of gcc/testsuite/gcc.target/s390/md/atomic_compare_exchange-1.c
Reduced testcase which fa
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 as
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,
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98341
--- Comment #3 from Marius Hillenbrand ---
Potential duplicate: I have seen very similar errors on s390x while reproducing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228
There, bisecting lead back to d119f34c952f ("New modref/ipa_modref opti
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 g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228
Marius Hillenbrand changed:
What|Removed |Added
CC||mhillen at linux dot ibm.com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92294
--- Comment #8 from Marius Hillenbrand ---
>From my current understanding, gcc addresses a and b in two different ways,
which is not handled correctly by the dependency analysis / alias analysis
while employed by the cse1 pass, and then causes cs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92294
--- Comment #7 from Marius Hillenbrand ---
A simpler example derived from alias-2.c reproduces this issue on aarch64,
ppc64, and s390x.
int a;
extern int b __attribute__ ((alias("a")));
int off;
int foo()
{
/* make sure off is ahead of a and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92294
--- Comment #6 from Marius Hillenbrand ---
Same behavior on s390x: the testcase always calls abort(). As on aarch64,
-fno-section-anchors avoids the issue.
the first cse pass already makes a mistake -- on both aarch64 and s390x, the
compare loos
27 matches
Mail list logo
