https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95082
Bill Schmidt changed:
What|Removed |Added
Known to fail|11.0|
Summary|[11] LE
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100808
Bill Schmidt changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
||2022-02-04
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot
gnu.org
--- Comment #4 from Bill Schmidt ---
Confirmed, I'll clean it up.
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=104335
Bill Schmidt changed:
What|Removed |Added
Target Milestone|--- |12.0
Keywords|
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=104172
--- Comment #13 from Bill Schmidt ---
We discussed this with Jakub today, and we concur.
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=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=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=103981
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=100952
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment
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=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=81953
Bill Schmidt changed:
What|Removed |Added
Status|ASSIGNED|NEW
--- Comment #6 from Bill Schmidt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103981
Bill Schmidt changed:
What|Removed |Added
Ever confirmed|0 |1
Target|
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wschmidt at gcc dot gnu.org
Target Milestone: ---
Per the PVIPR documentation, vec_cntlz_lsbb should generate vctzlsbb for little
endian, and vclzlsbb for big endian
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=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=103625
Bill Schmidt changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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=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 #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 #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=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=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=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=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=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 #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=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=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=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=103625
--- Comment #7 from Bill Schmidt ---
Oh, duh, sorry. Yes, I can reproduce as well.
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=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
Bill Schmidt changed:
What|Removed |Added
Ever confirmed|0 |1
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
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=102347
Bill Schmidt changed:
What|Removed |Added
See Also|https://gcc.gnu.org/bugzill |
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=103625
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
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=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=101985
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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 #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 #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=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 #4 from Bill Schmidt ---
Above was compiled with -O2 -mcpu=power10.
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
Bill Schmidt changed:
What|Removed |Added
Keywords||missed-optimization
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wschmidt at gcc dot gnu.org
Target Milestone: ---
While working on replacing the old builtins infrastructure for the rs6000 back
end, I observed that we generate poor code
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=101985
--- Comment #2 from Bill Schmidt ---
Patch posted at
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580235.html.
|NEW
Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot
gnu.org
Last reconfirmed||2021-09-23
--- Comment #1 from Bill Schmidt ---
Confirmed. I'll take a look.
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=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=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
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=93011
Bill Schmidt changed:
What|Removed |Added
Resolution|--- |FIXED
Status|SUSPENDED
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=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
Bill Schmidt changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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
--- 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 #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=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=101865
--- Comment #11 from Bill Schmidt ---
Thanks, Tulio, exactly right.
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=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 #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=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=102062
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
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
CC||wschmidt at gcc dot gnu.org
--- Comment
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=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=101830
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
--- 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 #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 #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 #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
Bill Schmidt changed:
What|Removed |Added
Known to fail||12.0
Target Milestone|---
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wschmidt at gcc dot gnu.org
Target Milestone: ---
I've been adding some code to the rs6000 back end that hasn't yet been part of
the build. As I got ready
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=101531
Bill Schmidt changed:
What|Removed |Added
Target Milestone|11.2|11.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101531
Bill Schmidt changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101531
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=101129
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101129
Bill Schmidt changed:
What|Removed |Added
Known to fail|12.0|
Known to work|
1 - 100 of 1696 matches
Mail list logo
