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
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=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=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
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=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=98734
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment
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=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=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=100706
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
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=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=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=94080
--- Comment #4 from Bill Schmidt ---
Thanks, Jonathan!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88696
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Assignee|unassigned
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=101865
--- Comment #2 from Bill Schmidt ---
The _ARCH_PWR8 predefine is conditioned on a flag that can be disabled by
-mno-vsx or -mno-altivec. That is a Bad Thing.
It appears (as David pointed out privately) that this problem is limited to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102062
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102062
--- Comment #2 from Bill Schmidt ---
As expected, I get similar code when compiling either for P9 or P10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102062
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865
--- Comment #11 from Bill Schmidt ---
Thanks, Tulio, exactly right.
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=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #10 from Bill Schmidt ---
Sorry to be late jumping in.
Previously zero bitfields were spuriously removed, now they're being left in
place and matching C. That's very good.
As Jakub shows, the biggest problem is with homogeneous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #11 from Bill Schmidt ---
Actually, on further review, I guess we have additional concerns. Unnamed
bitfields also have the effect of updating alignment of the subsequent field of
a structure.
"The types of unnamed bit fields have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #12 from Bill Schmidt ---
Never mind my last comment. Segher pointed out that structure layout is done
early enough that this isn't a problem. I verified this using g++ from GCC 11
and GCC 12 to show that we get correct offsets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102062
--- Comment #10 from Bill Schmidt ---
Well, the problem is that we still generate suboptimal code on GCC 11. I don't
know whether we want to address that or not.
I suppose we aren't going to backport Haochen's lovely patch for sign
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://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=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
+++
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=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=101129
Bill Schmidt changed:
What|Removed |Added
Known to fail|12.0|
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101830
Bug ID: 101830
Summary: Incorrect error messages beginning with r12-2591
(backward jump threader)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101830
Bill Schmidt changed:
What|Removed |Added
Known to fail||12.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101830
--- Comment #3 from Bill Schmidt ---
Created attachment 51281
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51281=edit
Preprocessed source
Per request, preprocessed source.
Compile with "g++ rs6000-gen-builtins.ii -c -O2 -Wall -Werror"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101830
--- Comment #5 from Bill Schmidt ---
If I commit the build patch, everyone who doesn't build with --disable-werror
will blame me for breaking bootstrap.
I thought perhaps the way safe_inc_pos was implemented might have made it
possible for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101830
--- Comment #7 from Bill Schmidt ---
Sorry, but that IL looks very strange to me.
BB 5 should be going directly to BB 8, and the value of interest along that
path is pos.80_31. But BB 8 says that it only gets pos.80 from BB 36, and the
value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101830
--- Comment #9 from Bill Schmidt ---
But it doesn't explain the bogus IL in the previous message.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101830
--- Comment #10 from Bill Schmidt ---
As a reminder, the code compiled fine with no warnings until the rewrite of the
back-threader. Based on the IL example above, it looks to me like the new pass
is not producing a self-consistent CFG in all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101830
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101830
--- Comment #13 from Bill Schmidt ---
Yes, absolutely right on safe_inc_pos, will address that as well. Much
obliged!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101531
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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.
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 #6 from Bill Schmidt ---
Currently fixed on trunk. The parts of the fix that don't involve the new
builtin infrastructure should be backported to all releases after some burn-in
time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101985
--- Comment #3 from Bill Schmidt ---
Kunwar, can you please tell us (if you don't mind) where the problem was
detected? Since we're changing behavior of the intrinsic, we'll need to
document this, and knowing whether we have problematic code
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
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
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=101985
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316
Bill Schmidt changed:
What|Removed |Added
Keywords||missed-optimization
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
--- 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 #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 #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
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
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
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
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=103622
Bill Schmidt changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
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':
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.
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
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
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=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=103625
--- Comment #7 from Bill Schmidt ---
Oh, duh, sorry. Yes, I can reproduce as well.
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
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=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=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=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 #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.
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=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
1 - 100 of 129 matches
Mail list logo
