https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101129
--- Comment #8 from Bill Schmidt ---
Small change required to actually check that it's a SET insn. (oops)
Otherwise looks like it passed regstrap. Testing the revised patch now.
Thanks for the pre-review!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101129
--- Comment #6 from Bill Schmidt ---
Testing this patch.
diff --git a/gcc/config/rs6000/rs6000-p8swap.c
b/gcc/config/rs6000/rs6000-p8swap.c
index 21cbcb2e28a..00693e6dc60 100644
--- a/gcc/config/rs6000/rs6000-p8swap.c
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101129
--- Comment #5 from Bill Schmidt ---
Uh, yeah, that is completely unexpected behavior for swaps. I'll try to look
at this soon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100866
--- Comment #11 from Bill Schmidt ---
Segher, does this fit naturally in combine?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100866
--- Comment #10 from Bill Schmidt ---
Right, it would be a good optimization. We've stopped focusing much on P8
optimization work at this point simply because of lack of resources.
The needed transform is to recognize load-xxlnor-vperm as a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101022
--- Comment #4 from Bill Schmidt ---
Hi Carl -- while you're in there, can you please remove these?
+BU_P10_OVERLOAD_2 (VRLQ, "vrlq")
+BU_P10_OVERLOAD_2 (VSLQ, "vslq")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101022
--- Comment #2 from Bill Schmidt ---
Looks like the proper pattern should be altivec_eqv1ti.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101022
Bill Schmidt changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org,
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wschmidt at gcc dot gnu.org
Target Milestone: ---
This line appears in a recent patch committed this week:
+BU_P10V_AV_2 (VCMPEQUT,"vcmpequt", CONST,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100930
--- Comment #2 from Bill Schmidt ---
Carl Love implemented these on trunk yesterday. They will be backported to GCC
11 in a week or so, at which point we can close this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100930
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100703
Bill Schmidt changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100749
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100706
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100750
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100750
--- Comment #4 from Bill Schmidt ---
I cannot reproduce failures for powerpc64le on P10 LE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100750
--- Comment #3 from Bill Schmidt ---
Fixed the BE problem. Will look into the GCC11 report.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100809
--- Comment #2 from Bill Schmidt ---
I believe this work is pending, but the patches are still under review.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98734
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94080
--- Comment #4 from Bill Schmidt ---
Thanks, Jonathan!
at gcc dot gnu.org |wschmidt at gcc dot
gnu.org
Resolution|--- |FIXED
--- Comment #4 from Bill Schmidt ---
Documentation fixed today to point to the master intrinsic reference document,
which has the vec_mul omissions fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57547
Bill Schmidt changed:
What|Removed |Added
Assignee|kelvin at gcc dot gnu.org |wschmidt at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96825
--- Comment #3 from Bill Schmidt ---
Is this going to be addressed in GCC 11? Should this be only a P3?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
--- Comment #14 from Bill Schmidt ---
We should definitely not be allowing the AltiVec "& ~16" flavors into these
patterns. I'm not certain whether your fix is the best way to achieve that,
but it could well be; I'll defer to Segher on that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98325
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94080
--- Comment #2 from Bill Schmidt ---
Let's see, with patches from late last year, can this be closed now?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #14 from Bill Schmidt ---
I agree, Peter.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #12 from Bill Schmidt ---
Right...but if somebody specifies an instruction with a 'p' that is
legitimately a pc-relative instruction, we don't want to say that the memory
operand can't use PC-relative addressing, do we? I just want
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #10 from Bill Schmidt ---
But it seems we would also need a new constraint that does permit PC-relative
addresses, since new code will/may not have a TOC.
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
Bill Schmidt changed:
What|Removed |Added
CC||luoxhu at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96787
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96787
--- Comment #8 from Bill Schmidt ---
I'm working on a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96787
--- Comment #7 from Bill Schmidt ---
I believe the problem may be that rs6000_sibcall_aix doesn't contain any
handling for indirect calls, whereas similar code for other ABIs, like
rs6000_sibcall_sysv, does. Alan, does this make sense?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96787
Bill Schmidt changed:
What|Removed |Added
CC||amodra at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96787
--- Comment #5 from Bill Schmidt ---
The divergence occurs after .L75 in the two versions. In the P10 version, we
see that the second bctrl has been converted into a bctr. It looks like a tail
call optimization happening, but we aren't at the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96139
--- Comment #2 from Bill Schmidt ---
Have you tried it for -m32, out of curiosity?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96017
--- Comment #2 from Bill Schmidt ---
Nick reports same behavior at -O3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96017
Bill Schmidt changed:
What|Removed |Added
Target Milestone|9.4 |11.0
,
||wschmidt at gcc dot gnu.org
Target Milestone|--- |9.4
Build|gcc version 9.2.1 20190909 |
|(Debian 9.2.1-8)|
Keywords||missed-optimization
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95952
Bill Schmidt changed:
What|Removed |Added
CC||willschm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65010
Bill Schmidt changed:
What|Removed |Added
CC||jens.seifert at de dot ibm.com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95737
Bill Schmidt changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95737
--- Comment #1 from Bill Schmidt ---
Please test this out of context of a return statement. The problem with
unnecessary extends of return values is widely known and not specific to this
particular case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70053
Bill Schmidt changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053
--- Comment #25 from Bill Schmidt ---
But I'm not going to worry about it further.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95082
Bill Schmidt changed:
What|Removed |Added
Keywords||wrong-code
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wschmidt at gcc dot gnu.org
Target Milestone: ---
For little endian, we need to swap vctzlsbb and vclzlsbb, but today we generate
the BE instruction in all cases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94954
Bill Schmidt changed:
What|Removed |Added
Target Milestone|--- |11.0
Keywords|
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wschmidt at gcc dot gnu.org
Target Milestone: ---
This builtin was mis-implemented. It is supposed to pack 32-bit floating-point
values into 16-bit floating-point form. Instead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94707
--- Comment #8 from Bill Schmidt ---
Thus the compiler is acting as expected in both cases, so far as I can see. If
C++17 has added new hidden fields, that seems to have introduced an
incompatibility between C++17 and C++14 targeted code for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94707
--- Comment #7 from Bill Schmidt ---
ELF V1 does not have a concept of homogeneous aggregates.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94707
--- Comment #6 from Bill Schmidt ---
The ELFv2 ABI has a prominent note specifying:
"Floating-point and vector aggregates that contain padding words and integer
fields with a width of 0 should not be treated as homogeneous aggregates."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91153
--- Comment #4 from Bill Schmidt ---
Perfect, thanks! I'll take it off my concern list...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91153
Bill Schmidt changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91804
Bill Schmidt changed:
What|Removed |Added
Priority|P2 |P4
--- Comment #3 from Bill Schmidt ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
Bill Schmidt changed:
What|Removed |Added
Last reconfirmed||2020-04-02
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87560
Bill Schmidt changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87560
--- Comment #10 from Bill Schmidt ---
rs6000: Fix -mpower9-vector -mno-altivec ICE (PR87560)
PR87560 reports an ICE when a test case is compiled with -mpower9-vector
and -mno-altivec. This patch terminates compilation with an error when
this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94019
--- Comment #4 from Bill Schmidt ---
Oh sorry, we are awaiting a backport. Never mind.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94019
--- Comment #3 from Bill Schmidt ---
Looks like this could be closed, Kewen?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93709
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
|--- |FIXED
CC||wschmidt at gcc dot gnu.org
--- Comment #8 from Bill Schmidt ---
Work is complete.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87560
--- Comment #9 from Bill Schmidt ---
I plan to backport the fix to releases/gcc-9 after 9.3 releases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87560
--- Comment #6 from Bill Schmidt ---
OK, looks like the gimple has changed so we don't see the opportunity anymore
in GCC 10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87560
--- Comment #4 from Bill Schmidt ---
Although perhaps we've done a better job of sorting out these flags since then.
Segher, anything ring a bell?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87560
--- Comment #3 from Bill Schmidt ---
I expect the problem is still there somewhere, but it's gone latent. There
haven't been any changes to *xxspltib__split since 2016. Will need to
look at gcc-9 branch to debug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87560
--- Comment #2 from Bill Schmidt ---
Hm, I can't reproduce this with current trunk. Does it still occur for you,
Martin?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93819
Bill Schmidt changed:
What|Removed |Added
Component|c |target
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93709
--- Comment #1 from Bill Schmidt ---
r10-4160 is the "daily bump" commit. How confident are you in your bisection?
:-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90763
--- Comment #2 from Bill Schmidt ---
Whoops, that was not supposed to go to bz. Sorry about that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93570
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93570
Bill Schmidt changed:
What|Removed |Added
Target Milestone|--- |10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91903
Bill Schmidt changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93570
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91903
Bill Schmidt changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93230
--- Comment #8 from Bill Schmidt ---
Yes, the variable element numbers were the difficulties in question that slowed
things down last time, as I recall. We may want to try to fold the simple
cases in gimple and let the rest run through to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91903
--- Comment #4 from Bill Schmidt ---
Well, we should give you a better error message instead of an ICE. But the ABI
definition of the second argument as "const int" indicates it needs to be an
actual constant in the range 0..31.
So You're
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93449
--- Comment #7 from Bill Schmidt ---
The ELFv2 ABI Appendix B calls for a bcd data type defined as:
typedef bcd vector unsigned char;
and then defines a bunch of potential functions that can be built around it.
The BCD functions (such as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93448
Bill Schmidt changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91274
--- Comment #4 from Bill Schmidt ---
The short answer is history. Those others were inherited from the old Altivec
PIM. Having splat-immediates with different names for different sizes and
signedness isn't consistent with the rest of the
||wschmidt at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #2 from Bill Schmidt ---
Such interfaces were never supported or promised for ppc64le. The fact that
s390 supports them is irrelevant.
The supported interfaces you're looking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93230
--- Comment #6 from Bill Schmidt ---
That should read "rs6000_gimple_fold_builtin".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93230
--- Comment #5 from Bill Schmidt ---
Yeah, vec_extract should get folded in rs6000_fold_builtin eventually. I think
that Will had a patch in progress on this at one time, but ran into some
difficulties and it got abandoned in favor of more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93206
--- Comment #6 from Bill Schmidt ---
(In reply to Jakub Jelinek from comment #4)
> There is no error, it is a note and if some variable at some point, even
> short one, can't be described using just registers or memory, but needs the
> value of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93206
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70928
Bill Schmidt changed:
What|Removed |Added
CC||jens.seifert at de dot ibm.com
---
||wschmidt at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #2 from Bill Schmidt ---
This is a duplicate of PR70928.
*** This bug has been marked as a duplicate of bug 70928 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93013
Bill Schmidt changed:
What|Removed |Added
Target|powerpc-ibm-aix7.1.0.0 |powerpc-*-*-*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93013
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93011
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93011
--- Comment #1 from Bill Schmidt ---
This is worth considering; but offhand I don't believe we should remove this
until common distros that use GCC 4.8 or 4.9 as default are retired (RHEL 7 and
SLES 12, for example, both use 4.8 as default and
||wschmidt at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #2 from Bill Schmidt ---
For clarity, many of these interfaces are only used internally as part of
mappings from overloaded builtins to builtins for a specific set of vector type
||2019-12-12
CC||wschmidt at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Bill Schmidt ---
Confirmed. The problem is bad overloading code for vec_xor, which accepts all
vector types but translates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92398
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 92098, which changed state.
Bug 92098 Summary: [9 Regression] After r262333, the following code cannot be
vectorized on powerpc64le.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92098
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92098
Bill Schmidt changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #32 from Bill Schmidt ---
BTW, we are in close contact with the Clang folks for Power as well, so we're
going to get together with them about constraints consistency and a way forward
to ensure these problems don't recur. I don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92287
--- Comment #5 from Bill Schmidt ---
For 32-bit big-endian PowerPC (using the 32-bit ELF ABI), the same code
generation is provided by GCC and Clang. I.e., here's the code generation for
Clang with -O2 -m32 -mbig-endian, using 6.0.0-1ubuntu2:
101 - 200 of 1696 matches
Mail list logo
