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.
|--- |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=93709
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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=94019
--- Comment #4 from Bill Schmidt ---
Oh sorry, we are awaiting a backport. Never mind.
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 co
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=9
Bill Schmidt changed:
What|Removed |Added
Last reconfirmed||2020-04-02
Ever confirmed|0
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=91153
Bill Schmidt changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 f
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=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=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 #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 the
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=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: ---
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=95082
Bill Schmidt changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRMED
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=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=70053
Bill Schmidt changed:
What|Removed |Added
Ever confirmed|0 |1
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=95737
Bill Schmidt changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65010
Bill Schmidt changed:
What|Removed |Added
CC||jens.seifert at de dot ibm.com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95952
Bill Schmidt changed:
What|Removed |Added
CC||willschm at gcc dot gnu.org
--- Comment #
,
||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=96017
Bill Schmidt changed:
What|Removed |Added
Target Milestone|9.4 |11.0
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=96139
--- Comment #2 from Bill Schmidt ---
Have you tried it for -m32, out of curiosity?
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 e
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 #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
--- Comment #8 from Bill Schmidt ---
I'm working on a patch.
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=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
--- 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=92132
--- Comment #2 from Bill Schmidt ---
Yes, odd that the comparison is flagged as not vectorizable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92093
--- Comment #4 from Bill Schmidt ---
Author: wschmidt
Date: Thu Oct 17 15:32:40 2019
New Revision: 277117
URL: https://gcc.gnu.org/viewcvs?rev=277117&root=gcc&view=rev
Log:
2019-10-17 Bill Schmidt
Backport from mainline
2019-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92093
--- Comment #5 from Bill Schmidt ---
Author: wschmidt
Date: Thu Oct 17 15:33:58 2019
New Revision: 277118
URL: https://gcc.gnu.org/viewcvs?rev=277118&root=gcc&view=rev
Log:
2019-10-17 Bill Schmidt
Backport from mainline
2019-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92093
--- Comment #6 from Bill Schmidt ---
Author: wschmidt
Date: Thu Oct 17 15:35:28 2019
New Revision: 277119
URL: https://gcc.gnu.org/viewcvs?rev=277119&root=gcc&view=rev
Log:
2019-10-17 Bill Schmidt
Backport from mainline
2019-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92093
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92093
Bill Schmidt changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #8 from Bill Schmidt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92126
--- Comment #4 from Bill Schmidt ---
Should we close this? I found it on an internal list of old failures on P7
that need looking at. Not sure having this issue open provides value.
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:
i
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 wan
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=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=92398
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
||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
||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
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 ar
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=93013
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93013
Bill Schmidt changed:
What|Removed |Added
Target|powerpc-ibm-aix7.1.0.0 |powerpc-*-*-*
Component|tree-opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70928
Bill Schmidt changed:
What|Removed |Added
CC||jens.seifert at de dot ibm.com
--- Commen
||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=93206
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment
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 t
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 urgen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93230
--- Comment #6 from Bill Schmidt ---
That should read "rs6000_gimple_fold_builtin".
||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 fo
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 vector
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=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 __bui
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 Doing
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 expand
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=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
Keywords||ice-on-invalid-code
Target Milestone|10
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=93570
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=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=93819
Bill Schmidt changed:
What|Removed |Added
Component|c |target
Target Milestone|---
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=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 #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 #6 from Bill Schmidt ---
OK, looks like the gimple has changed so we don't see the opportunity anymore
in GCC 10.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56321
William J. Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56321
--- Comment #5 from William J. Schmidt 2013-02-14
14:43:29 UTC ---
Actually I might be wrong about that, now that I think about it -- probably
this was done in 4.8. It seems longer ago than that. ;)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56321
--- Comment #6 from William J. Schmidt 2013-02-14
20:11:32 UTC ---
Odd. Reassociation makes a correct and profitable transformation into
foo (int n)
{
double _2;
double _5;
double _6;
double _7;
double _8;
float _9;
AssignedTo|unassigned at gcc dot |wschmidt at gcc dot gnu.org
|gnu.org |
--- Comment #7 from William J. Schmidt 2013-02-14
22:27:21 UTC ---
I see. The problem is a memory VUSE on the return statement that no longer has
a def. The VDEF was associated with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56321
--- Comment #10 from William J. Schmidt
2013-02-15 15:13:55 UTC ---
(In reply to comment #8)
> (In reply to comment #7)
> > I see. The problem is a memory VUSE on the return statement that no longer
> > has
> > a def. The VDEF was asso
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56321
--- Comment #11 from William J. Schmidt
2013-02-15 15:49:03 UTC ---
OK, got it. I was on the right track, there were just several locations where
it could happen and I missed one.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636
William J. Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636
William J. Schmidt changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56605
Bug #: 56605
Summary: Redundant branch introduced during loop2 phases
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: missed-op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35308
William J. Schmidt changed:
What|Removed |Added
Target Milestone|4.8.1 |4.9.0
--- Comment #5 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56843
Bug #: 56843
Summary: PowerPC Newton-Raphson reciprocal estimates can be
improved
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56843
--- Comment #2 from Bill Schmidt 2013-04-04
16:12:31 UTC ---
Regarding the last point, I found this in the user manual:
"The double-precision square root estimate instructions are not generated by
default on low-precision machines, since
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56843
--- Comment #3 from Bill Schmidt 2013-04-05
15:03:26 UTC ---
Looks like we can improve performance for three cases on P6 and later machines:
- 32-bit reciprocal square root: remove two instructions
- 32-bit reciprocal: remove three instr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56843
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56933
Bug #: 56933
Summary: [4.9 Regression] Vectorizer missing read-write
dependency for interleaved accesses
Classification: Unclassified
Product: gcc
Version: 4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56962
--- Comment #2 from Bill Schmidt 2013-04-15
13:19:53 UTC ---
The fix looks correct to me. Thanks!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56605
Bill Schmidt changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot |wschmidt at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56605
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56864
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56864
--- Comment #8 from Bill Schmidt 2013-05-01
20:13:35 UTC ---
If possible, please check whether this began failing with r196872. That commit
looks suspicious for at least one other test. I'm stabbing in the dark since I
can't reproduce th
,
||wschmidt at gcc dot gnu.org
--- Comment #2 from Bill Schmidt 2013-05-01
21:58:09 UTC ---
I've reproduced this as well. Additionally, gcc.dg/vect/vect-96.c fails
similarly. Both tests began failing at r196872:
2013-03-21 Richard B
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56865
--- Comment #4 from Bill Schmidt 2013-05-02
15:27:08 UTC ---
(In reply to comment #3)
>
> Correct. Dumping order is affected by the patch though, thus if
> we previously disabled vectorization at some point the dumping
> before that ca
1 - 100 of 1697 matches
Mail list logo
