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=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=88696
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94080
--- Comment #4 from Bill Schmidt ---
Thanks, Jonathan!
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=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 t
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=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=98325
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment #
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=98734
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment #
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=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=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
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100706
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
Reso
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=100703
Bill Schmidt changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
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=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=101022
Bug ID: 101022
Summary: rs6000: __builtin_altivec_vcmpequt expands to wrong
pattern
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101022
Bill Schmidt changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org,
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
--- 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=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 gr
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=95082
Bill Schmidt changed:
What|Removed |Added
Known to fail|11.0|
Summary|[11] LE implementatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103622
Bill Schmidt changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103981
Bug ID: 103981
Summary: powerpc64le: Wrong code generated for vec_cntlz_lsbb,
vec_cnttz_lsbb
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103981
Bill Schmidt changed:
What|Removed |Added
Ever confirmed|0 |1
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81953
Bill Schmidt changed:
What|Removed |Added
Status|ASSIGNED|NEW
--- Comment #6 from Bill Schmidt ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68212
Bill Schmidt changed:
What|Removed |Added
Assignee|kelvin at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100952
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101022
Bill Schmidt changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103981
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95082
--- Comment #6 from Bill Schmidt ---
*** Bug 103981 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103686
--- Comment #10 from Bill Schmidt ---
It turns out not to be undocumented -- but I'd like to remove it anyway. Any
objections?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104172
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104172
--- Comment #13 from Bill Schmidt ---
We discussed this with Jakub today, and we concur.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100930
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104335
Bill Schmidt changed:
What|Removed |Added
Target Milestone|--- |12.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103686
Bill Schmidt changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100808
Bill Schmidt changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100808
Bill Schmidt changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95082
Bill Schmidt changed:
What|Removed |Added
Known to work||12.0
Summary|[11/12] LE implem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316
Bug ID: 103316
Summary: PowerPC: Gimple folding of int128 comparisons produces
suboptimal code
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316
Bill Schmidt changed:
What|Removed |Added
Keywords||missed-optimization
Status|U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316
--- Comment #3 from Bill Schmidt ---
Sure. Consider:
#include
vector bool __int128
foo (vector signed __int128 a, vector signed __int128 b)
{
return vec_cmpgt (a, b);
}
With gimple folding we emulate in 64-bit mode:
mfvsrd 9,34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316
--- Comment #4 from Bill Schmidt ---
Above was compiled with -O2 -mcpu=power10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316
--- Comment #5 from Bill Schmidt ---
At first glance, this is probably because vector.md's definition of
vec_cmp isn't defined for V1TImode. Probably needs to be changed
to use VEC_IP rather than VEC_I and implement all the cases for 128-bit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316
--- Comment #10 from Bill Schmidt ---
FWIW, I think the vector lowering pass is reasonable. These things always look
horrible in isolation, but the lowering allows more optimization when the
target doesn't really support the data type.
This is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316
--- Comment #11 from Bill Schmidt ---
As I mentioned privately, we could do with an audit of our implementation of
standard patterns in general, since we tend to find such missing cases more
often than I'd like...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316
--- Comment #14 from Bill Schmidt ---
(In reply to Segher Boessenkool from comment #13)
> (In reply to Bill Schmidt from comment #11)
> > As I mentioned privately, we could do with an audit of our implementation of
> > standard patterns in gener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101985
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103622
Bill Schmidt changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot
gnu.org
Ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103622
--- Comment #5 from Bill Schmidt ---
Expected behavior is:
pr103622.c: In function 'get_float128_exponent':
pr103622.c:4:3: error: invalid parameter combination for AltiVec intrinsic
'__builtin_vec_scalar_extract_exp'
4 | return __builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
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=103624
Bill Schmidt changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot
gnu.org
Ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103625
Bill Schmidt changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot
gnu.org
Ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103625
--- Comment #3 from Bill Schmidt ---
BTW, Arseny, please CC me on any other built-in issues you see.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102347
Bill Schmidt changed:
What|Removed |Added
See Also|https://gcc.gnu.org/bugzill |
|a/show_bug.cgi?id=10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103622
Bill Schmidt changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103624
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103625
--- Comment #4 from Bill Schmidt ---
Kewen, how did you confirm this? My cross doesn't accept -mvsx as valid.
$ /home/wschmidt/gcc/build/gcc-e300/gcc/xgcc -c -O2 -mvsx pr103625.c
-B/home/wschmidt/gcc/build/gcc-e300/gcc
/home/wschmidt/gcc/buil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103625
Bill Schmidt changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103624
--- Comment #4 from Bill Schmidt ---
__builtin_darn and __builtin_darn_raw are in the wrong stanza. Moving them to
[power9-64] fixes it on my cross:
diff --git a/gcc/config/rs6000/rs6000-builtin-new.def
b/gcc/config/rs6000/rs6000-builtin-new.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #5 from Bill Schmidt ---
Agreed that this needs a new attribute, and digging through the macros used to
guard the associated patterns, this really does need to be restricted to the
case when long double is implemented by IBM-128. Sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #6 from Bill Schmidt ---
With a quick and dirty patch to implement this, I get:
$ /home/wschmidt/gcc/build/gcc-e300/gcc/xgcc -c -O2 pr103623.c
-B/home/wschmidt/gcc/build/gcc-e300/gcc -mcpu=401
pr103623.c: In function 'main':
pr10362
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103625
--- Comment #7 from Bill Schmidt ---
Oh, duh, sorry. Yes, I can reproduce as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103625
--- Comment #8 from Bill Schmidt ---
And Kewen's analysis is spot-on, will fix that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103624
--- Comment #6 from Bill Schmidt ---
We have __builtin_darn_32 for the 32-bit case. The changes for the two
64-bit-only interfaces reflect the previous behavior.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103622
--- Comment #7 from Bill Schmidt ---
It seems to me the problem is that long double was resolved to _Float128 when
there is no _Float128 support on the target. There is no specific overloaded
interface that accepts "long double," so there must
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103622
--- Comment #8 from Bill Schmidt ---
Hm, no, it's probably just that it's iterating looking for long double and runs
across this instance with an uninitialized function type. So this patch solves
the problem:
diff --git a/gcc/config/rs6000/rs6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103686
--- Comment #1 from Bill Schmidt ---
I think that the MMA implementation is incompatible with -mno-fold-gimple.
We'll need to prevent that flag combination, I think.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103622
--- Comment #9 from Bill Schmidt ---
Patch posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586715.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #8 from Bill Schmidt ---
Patch posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586712.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103624
--- Comment #7 from Bill Schmidt ---
Patch posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586711.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103625
--- Comment #9 from Bill Schmidt ---
Patch posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586713.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103686
--- Comment #4 from Bill Schmidt ---
Please don't make changes to the old builtin support, which has been disabled.
:-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103686
--- Comment #5 from Bill Schmidt ---
More properly, please don't rely on a bit that is being destroyed by the new
support. You need to look at built-in function attributes instead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103686
--- Comment #6 from Bill Schmidt ---
if (bif_is_mmaint (rs6000_builtin_info_x[uns_fcode])
&& !rs6000_fold_gimple)
is what you're looking for. However, I would much rather see rejection of the
-mno-fold-gimple flag when MMA is enabled. Sil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
Bill Schmidt changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103625
Bill Schmidt changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103624
Bill Schmidt changed:
What|Removed |Added
Assignee|wschmidt at gcc dot gnu.org|unassigned at gcc dot
gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102127
--- Comment #3 from Bill Schmidt ---
Also reported for AIX over the weekend. Seems to occur on all BE targets.
I'll try to look at this later today.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102127
--- Comment #5 from Bill Schmidt ---
This will be similar to some other issues that arose in the past -- there are
function types that shouldn't be built when the type of an operand or return
value doesn't exist. I must have missed some such co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102127
--- Comment #6 from Bill Schmidt ---
OK, I see. This involves vector_pair_type_node and
vector_quad_type_node...which are not getting initialized because
TARGET_EXTRA_BUILTINS is false. This is a patch-ordering problem in the series
that I mis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102127
--- Comment #7 from Bill Schmidt ---
...by always initializing these types, not builtins...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102127
Bill Schmidt changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102107
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102148
--- Comment #4 from Bill Schmidt ---
Thanks, Julian. I'll record this for the next ABI update.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102148
--- Comment #5 from Bill Schmidt ---
For anyone running into this problem and wondering about the resolution:
It is a matter of some confusion how homogeneous aggregates are mapped to the
parameter save area. This came up recently with
https://
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93011
Bill Schmidt changed:
What|Removed |Added
Resolution|--- |FIXED
Status|SUSPENDED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102353
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=102353
--- Comment #3 from Bill Schmidt ---
Hi Sandra,
Does the following work for your cross?
diff --git a/gcc/config/rs6000/t-rs6000 b/gcc/config/rs6000/t-rs6000
index 92766d8ea25..738d4cf9493 100644
--- a/gcc/config/rs6000/t-rs6000
+++ b/gcc/confi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102353
--- Comment #6 from Bill Schmidt ---
Thanks, Tobias! I'm sorry for getting this exactly backwards...
Your patch looks good. I am doing a quick host=target=build bootstrap and will
respond on-list when it'sdone.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #15 from Bill Schmidt ---
Jakub, could you add a note with a section ID in
https://gcc.gnu.org/gcc-12/changes.html as was done for the similar case in GCC
10? This allowed us to specify a URL in the informational diagnostic, like so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101985
Bill Schmidt changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101985
--- Comment #2 from Bill Schmidt ---
Patch posted at
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580235.html.
1 - 100 of 129 matches
Mail list logo
