https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #28 from Arseny Solokha ---
Yes, I think so.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #27 from Segher Boessenkool ---
So this particular bug is no longer there, and this PR can be closed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #26 from Arseny Solokha ---
Now testcases from comment 8 and the one in the gcc tree from which comment 6
has been reduced both fail the same way as reported in PR96762.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #25 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #24)
> (In reply to Segher Boessenkool from comment #23)
> > Anyway, patch in testing.
>
> Did your patch fix the problem or do we need to take another run at th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #24 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #23)
> Anyway, patch in testing.
Did your patch fix the problem or do we need to take another run at this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #23 from Segher Boessenkool ---
Changing the ABI (silently, even!) is never an expected thing. All of the
four 32-bit ABIs we support have an AltiVec variant that isn't fully
compatible to the non-AltiVec base variant. It would be a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #22 from Michael Meissner ---
When I wrote the original in power7 days, the intent was:
If the user said -mcpu=power7 (for 32-bit) and did not explicitly set either
-mabi=altivec or -mabi=no-altivec, that -mabi=altivec would be set
a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #21 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #20)
> (In reply to Peter Bergner from comment #18)
> > So why don't we default to the Altivec ABI with -m32 on cpus that have
> > Altivec and VSX units???
>
> H
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #20 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #18)
> So why don't we default to the Altivec ABI with -m32 on cpus that have
> Altivec and VSX units???
History. I'm not sure all our ABIs are compatible with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #19 from Segher Boessenkool ---
(In reply to Arseny Solokha from comment #17)
> (In reply to Segher Boessenkool from comment #16)
> > Oh, it's a different testcase, in comment 6. Yeah a new PR would
> > have been better ;-/
>
> Do y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
Peter Bergner changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #17 from Arseny Solokha ---
(In reply to Segher Boessenkool from comment #16)
> Oh, it's a different testcase, in comment 6. Yeah a new PR would
> have been better ;-/
Do you want me to reopen PR97963 and copy comment 14 there until
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #16 from Segher Boessenkool ---
Oh, it's a different testcase, in comment 6. Yeah a new PR would
have been better ;-/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #15 from Segher Boessenkool ---
Why does that compiler default to -mcpu=power10?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
Peter Bergner changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|acsawdey at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #13 from Arseny Solokha ---
The testcase in comment 6 still ICEs when compiled w/ -m32:
% powerpc-e300c3-linux-gnu-gcc-11.0.0 -m32 -c wqugxu8a.c
wqugxu8a.c: In function 'test0':
wqugxu8a.c:8:1: error: insn does not satisfy its constr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #12 from Arseny Solokha ---
*** Bug 97963 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #11 from CVS Commits ---
The master branch has been updated by Aaron Sawdey :
https://gcc.gnu.org/g:6b91b3e9df171970a907638d9b2e0bca1e792975
commit r11-5097-g6b91b3e9df171970a907638d9b2e0bca1e792975
Author: Aaron Sawdey
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #10 from acsawdey at gcc dot gnu.org ---
For now, disabling use of POImode for expansion of memcpy/memmove to avoid this
problem while we figure out the real fix:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553672.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #9 from acsawdey at gcc dot gnu.org ---
I did post a small patch that fixes this, but more for the purpose of provoking
discussion than because I am sure it is the right way to fix this.
https://gcc.gnu.org/pipermail/gcc-patches/2020-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #8 from acsawdey at gcc dot gnu.org ---
Another small test case, reduced from my compile failure of c/c-typeck.c and
modified to provoke truncation from POImode to various other modes:
typedef int *a;
struct b { a ba; };
enum c { c1=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #7 from acsawdey at gcc dot gnu.org ---
I wonder if this other case works properly when compiled with -m64. Trying to
generate a stxvp with a 32-bit address seems odd.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #6 from Arseny Solokha ---
There's also a seemingly related case where gcc ICES in branch
if (GET_MODE_CLASS (to_mode) == MODE_PARTIAL_INT)
instead.
The following testcase is reduced from
gcc/testsuite/gcc.target/powerpc/pr96125.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |acsawdey at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #4 from Bill Schmidt ---
Not the partially dead store code after all -- just a coincidence!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #3 from acsawdey at gcc dot gnu.org ---
This also requires -mbig which may be implicit in the original poster's build.
But I see it failing as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
Bill Schmidt changed:
What|Removed |Added
CC||luoxhu at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
29 matches
Mail list logo
