https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
--- Comment #11 from Peter Bergner ---
(In reply to Nicholas Krause from comment #9)
> Sorry if I'm misunderstanding the power code but is there a way to rewrite
> the test to:
> if (VECTOR_MEM_ALTIVEC(mode)
> and another branch for VSX_P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
--- Comment #10 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #8)
> With a reversion we get to a known state, keeping it we remain in far less
> tested state, so unless one bug is much more severe than the other one, I'd
> go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
Nicholas Krause changed:
What|Removed |Added
CC||xerofoify at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
--- Comment #8 from Jakub Jelinek ---
Well, there is a significant difference, the other PR has been there for more
than 2 years before somebody discovered it, while this one was discovered much
quicker and there is a possibility there could be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
--- Comment #7 from Peter Bergner ---
Another option would be to release now without reverting. If we revert and
then release, then we're shipping a compiler with bug PR93658 in it. If we
release now without reverting, then PR93658 is fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
--- Comment #6 from Jakub Jelinek ---
My slight preference would be probably reversion, maybe even on both 8 and 9
branches, do the releases, fix on the trunk, give it two or three weeks to
settle and then backport again, but maybe I'm just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
Segher Boessenkool changed:
What|Removed |Added
Component|target |rtl-optimization
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
Peter Bergner changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|9.3 |8.4
Summary|[9/10
