[Bug target/95082] LE implementations of vec_cnttz_lsbb and vec_cntlz_lsbb are wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95082 Bill Schmidt changed: What|Removed |Added Known to fail|11.0| Summary|[11] LE implementations of |LE implementations of |vec_cnttz_lsbb and |vec_cnttz_lsbb and |vec_cntlz_lsbb are wrong|vec_cntlz_lsbb are wrong --- Comment #10 from Bill Schmidt --- >From some private discussion today, this goes back quite some ways, and we're simply going to document this as a change in behavior. The old behavior was wrong and usage of these built-ins is not very prevalent. We'll make a point of this change in the release notes, rather than do any backports.
[Bug target/95082] [11] LE implementations of vec_cnttz_lsbb and vec_cntlz_lsbb are wrong
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 implementations |[11] LE implementations of |of vec_cnttz_lsbb and |vec_cnttz_lsbb and |vec_cntlz_lsbb are wrong|vec_cntlz_lsbb are wrong Known to fail||11.0 --- Comment #8 from Bill Schmidt --- This still needs a backport to 11, but I won't be able to work on that.
[Bug target/100808] PPC: ISA 3.1 builtin documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100808 Bill Schmidt changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Bill Schmidt --- Ugh, bad commit message... but fixed.
[Bug target/100808] PPC: ISA 3.1 builtin documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100808 Bill Schmidt changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||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.
[Bug target/103686] ICE in rs6000_expand_new_builtin at rs6000-call.c:15946
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103686 Bill Schmidt changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #13 from Bill Schmidt --- Fixed now.
[Bug target/104335] [12 regression] build failure if go is included in languages after r12-6747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104335 Bill Schmidt changed: What|Removed |Added Target Milestone|--- |12.0 Keywords||build, ice-on-valid-code
[Bug target/100930] PPC: Missing builtins for P9 vextsb2w, vextsb2w, vextsb2d, vextsh2d, vextsw2d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100930 Bill Schmidt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Bill Schmidt --- So, fixed.
[Bug target/104172] [9/10/11/12 Regression] ppc64le mangling ICE with -flto -ffat-lto-objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104172 --- Comment #13 from Bill Schmidt --- We discussed this with Jakub today, and we concur.
[Bug target/104172] [9/10/11/12 Regression] ppc64le mangling ICE with -flto -ffat-lto-objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104172 Bill Schmidt changed: What|Removed |Added CC||wschmidt at gcc dot gnu.org --- Comment #5 from Bill Schmidt --- (In reply to Jakub Jelinek from comment #3) > E.g. I think all the libstdc++ work is only in GCC 11, so yes, one could use > C++, but couldn't use the standard C++ library in GCC 8. Yes, that's true.
[Bug target/103686] ICE in rs6000_expand_new_builtin at rs6000-call.c:15946
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?
[Bug target/95082] LE implementations of vec_cnttz_lsbb and vec_cntlz_lsbb are wrong
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. ***
[Bug target/103981] powerpc64le: Wrong code generated for vec_cntlz_lsbb, vec_cnttz_lsbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103981 Bill Schmidt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Bill Schmidt --- This turns out to be a rediscovery of 95082. *** This bug has been marked as a duplicate of bug 95082 ***
[Bug target/101022] rs6000: __builtin_altivec_vcmpequt expands to wrong pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101022 Bill Schmidt changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Bill Schmidt --- Looks like this was fixed some time ago.
[Bug target/100952] [12 regression] several test case failures after r12-1202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100952 Bill Schmidt changed: What|Removed |Added CC||wschmidt at gcc dot gnu.org --- Comment #14 from Bill Schmidt --- Which tests are still failing?
[Bug target/100085] Bad code for union transfer from __float128 to vector types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085 Bill Schmidt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Bill Schmidt --- This was fixed a while back in r12-1316 by Xiong Hu Luo.
[Bug rtl-optimization/68212] Loop unroller breaks basic block frequencies
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 Status|ASSIGNED|NEW --- Comment #6 from Bill Schmidt --- Kelvin has moved on...
[Bug tree-optimization/81953] Code sinking increases register pressure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81953 Bill Schmidt changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #6 from Bill Schmidt --- Resetting to unassigned as Kelvin left the project.
[Bug target/103981] powerpc64le: Wrong code generated for vec_cntlz_lsbb, vec_cnttz_lsbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103981 Bill Schmidt changed: What|Removed |Added Ever confirmed|0 |1 Target||powerpc64le-linux-gnu Status|UNCONFIRMED |NEW Last reconfirmed||2022-01-11 Target Milestone|--- |12.0 Keywords||wrong-code CC||bergner at gcc dot gnu.org, ||dje at gcc dot gnu.org, ||segher at gcc dot gnu.org --- Comment #1 from Bill Schmidt --- Confirmed. Need to review earlier releases for the same issue.
[Bug target/103981] New: powerpc64le: Wrong code generated for vec_cntlz_lsbb, vec_cnttz_lsbb
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 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. vec_cnttz_lsbb should do the opposite. The little-endian code generation is incorrect for both. Clang gets this right, for what it's worth.
[Bug target/103622] [12 Regression] ICE: Segmentation fault (in altivec_resolve_new_overloaded_builtin)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103622 Bill Schmidt changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #12 from Bill Schmidt --- Fixed now.
[Bug target/103624] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
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 --- Comment #9 from Bill Schmidt --- After some discussion, Segher will take a run at this one, so unassigning myself.
[Bug target/103625] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103625 Bill Schmidt changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #11 from Bill Schmidt --- Fixed.
[Bug target/103623] [12 Regression] error: unable to generate reloads (ICE in curr_insn_transform, at lra-constraints.c:4132), or error: insn does not satisfy its constraints (ICE in extract_constrain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623 Bill Schmidt changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Bill Schmidt --- Fixed.
[Bug target/103686] ICE in rs6000_expand_new_builtin at rs6000-call.c:15946
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. Silently ignoring a flag violates the principle of least astonishment.
[Bug target/103686] ICE in rs6000_expand_new_builtin at rs6000-call.c:15946
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.
[Bug target/103686] ICE in rs6000_expand_new_builtin at rs6000-call.c:15946
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. :-)
[Bug target/103625] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
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
[Bug target/103624] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
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
[Bug target/103623] [12 Regression] error: unable to generate reloads (ICE in curr_insn_transform, at lra-constraints.c:4132), or error: insn does not satisfy its constraints (ICE in extract_constrain
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
[Bug target/103622] [12 Regression] ICE: Segmentation fault (in altivec_resolve_new_overloaded_builtin)
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
[Bug target/103686] ICE in rs6000_expand_new_builtin at rs6000-call.c:15946
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.
[Bug target/103622] [12 Regression] ICE: Segmentation fault (in altivec_resolve_new_overloaded_builtin)
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/rs6000-c.c b/gcc/config/rs6000/rs6000-c.c
index 8e83d97e72f..fc4cc929884 100644
--- a/gcc/config/rs6000/rs6000-c.c
+++ b/gcc/config/rs6000/rs6000-c.c
@@ -2943,6 +2943,12 @@ altivec_resolve_new_overloaded_builtin (location_t loc,
tree fndecl,
for (; instance != NULL; instance = instance->next)
{
+ /* It is possible for an instance to require a data type that isn't
+ defined on this target, in which case instance->fntype will be
+ NULL. */
+ if (!instance->fntype)
+ continue;
+
bool mismatch = false;
tree nextparm = TYPE_ARG_TYPES (instance->fntype);
[Bug target/103622] [12 Regression] ICE: Segmentation fault (in altivec_resolve_new_overloaded_builtin)
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 have been type coercion involved here.
[Bug target/103624] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
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.
[Bug target/103625] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
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.
[Bug target/103625] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103625 --- Comment #7 from Bill Schmidt --- Oh, duh, sorry. Yes, I can reproduce as well.
[Bug target/103623] [12 Regression] error: unable to generate reloads (ICE in curr_insn_transform, at lra-constraints.c:4132), or error: insn does not satisfy its constraints (ICE in extract_constrain
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': pr103623.c:2:16: error: '__builtin_unpack_longdouble' requires long double to be IBM 128-bit format 2 | #define UNPACK __builtin_unpack_longdouble |^ pr103623.c:11:15: note: in expansion of macro 'UNPACK' 11 | double x0 = UNPACK (a, 0); | ^~ Arseny, does this properly diagnose the issue for you?
[Bug target/103623] [12 Regression] error: unable to generate reloads (ICE in curr_insn_transform, at lra-constraints.c:4132), or error: insn does not satisfy its constraints (ICE in extract_constrain
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. Safest is to use FLOAT128_2REG_P (TFmode), i.e., applied to the mode used for long double, which is what enables the corresponding pack and unpack patterns.
[Bug target/103624] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
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.def
index 30556e5c7f2..2becd96a36c 100644
--- a/gcc/config/rs6000/rs6000-builtin-new.def
+++ b/gcc/config/rs6000/rs6000-builtin-new.def
@@ -2799,15 +2799,9 @@
; Miscellaneous P9 functions
[power9]
- signed long long __builtin_darn ();
-DARN darn {}
-
signed int __builtin_darn_32 ();
DARN_32 darn_32 {}
- signed long long __builtin_darn_raw ();
-DARN_RAW darn_raw {}
-
const signed int __builtin_dtstsfi_eq_dd (const int<6>, _Decimal64);
TSTSFI_EQ_DD dfptstsfi_eq_dd {}
@@ -2840,6 +2834,12 @@
void __builtin_altivec_stxvl (vsc, void *, long);
STXVL stxvl {}
+ signed long long __builtin_darn ();
+DARN darn {}
+
+ signed long long __builtin_darn_raw ();
+DARN_RAW darn_raw {}
+
const signed int __builtin_scalar_byte_in_set (signed int, signed long
long);
CMPEQB cmpeqb {}
[Bug target/103625] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103625 Bill Schmidt changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-12-12 Status|UNCONFIRMED |NEW --- Comment #5 from Bill Schmidt --- Confirmed by Kewen, so setting status.
[Bug target/103625] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
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/build/gcc-e300/gcc/as: line 114: exec: -m: invalid option exec: usage: exec [-cl] [-a name] [command [arguments ...]] [redirection ...]
[Bug target/103624] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103624 Bill Schmidt changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-12-12 Ever confirmed|0 |1 --- Comment #3 from Bill Schmidt --- Hm, I see a slightly different error (just a seg fault), but still, confirmed.
[Bug target/103622] [12 Regression] ICE: Segmentation fault (in altivec_resolve_new_overloaded_builtin)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103622 Bill Schmidt changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-12-12 --- Comment #6 from Bill Schmidt --- Confirmed.
[Bug target/102347] "fatal error: target specific builtin not available" with MMA and LTO
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=103622| --- Comment #14 from Bill Schmidt --- Removing the "see also" for 103622, which is not really related.
[Bug target/103625] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
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.
[Bug target/103625] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
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 Target Milestone|--- |12.0 --- Comment #2 from Bill Schmidt --- Mine.
[Bug target/103624] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
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 Target Milestone|--- |12.0 --- Comment #2 from Bill Schmidt --- Mine.
[Bug target/103623] [12 Regression] error: unable to generate reloads (ICE in curr_insn_transform, at lra-constraints.c:4132), or error: insn does not satisfy its constraints (ICE in extract_constrain
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 --- Comment #3 from Bill Schmidt --- Mine. Probably will be next week before I get to these, but let's see.
[Bug target/103622] ICE: Segmentation fault (in altivec_resolve_new_overloaded_builtin)
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_vec_scalar_extract_exp (a); | ^~
[Bug target/103622] ICE: Segmentation fault (in altivec_resolve_new_overloaded_builtin)
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 Target Milestone|--- |12.0 --- Comment #4 from Bill Schmidt --- I'll have a look.
[Bug target/101985] vec_cpsgn parameter order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101985 Bill Schmidt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Bill Schmidt --- Now fixed everywhere.
[Bug target/103316] PowerPC: Gimple folding of int128 comparisons produces suboptimal code
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 general, since we tend to find such missing cases more > > often than I'd like... > > It would be great if there was some standard way of seeing what targets > implement (and do not implement!) what. It will be hugely useful when > implementing a new port for example, but also great when maintaining one. I agree. Some tooling around this would be a big benefit to the community. Maybe some GSOC person would like to do that. :)
[Bug target/103316] PowerPC: Gimple folding of int128 comparisons produces suboptimal code
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...
[Bug target/103316] PowerPC: Gimple folding of int128 comparisons produces suboptimal code
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 just an oversight in our back end, and once we correct it, this should all fall out nicely (I hope).
[Bug target/103316] PowerPC: Gimple folding of int128 comparisons produces suboptimal code
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.
[Bug target/103316] PowerPC: Gimple folding of int128 comparisons produces suboptimal code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316 --- Comment #4 from Bill Schmidt --- Above was compiled with -O2 -mcpu=power10.
[Bug target/103316] PowerPC: Gimple folding of int128 comparisons produces suboptimal code
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
mfvsrld 8,34
mfvsrd 11,35
mfvsrld 10,35
li 7,1
cmpd 0,9,11
bgt 0,.L2
cmpld 0,9,11
beq 0,.L5
.L3:
li 7,0
.L2:
subfic 10,7,0
subfe 11,11,11
mtvsrdd 34,11,10
blr
.p2align 4,,15
.L5:
cmpld 0,8,10
bgt 0,.L2
b .L3
The desired code generation is just
vcmpgtsq 2,2,3
[Bug target/103316] PowerPC: Gimple folding of int128 comparisons produces suboptimal code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316 Bill Schmidt changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW CC||bergner at gcc dot gnu.org, ||segher at gcc dot gnu.org Ever confirmed|0 |1 Target||powerpc*-*-* Last reconfirmed||2021-11-18 Target Milestone|--- |12.0 --- Comment #1 from Bill Schmidt --- Confirmed.
[Bug target/103316] New: PowerPC: Gimple folding of int128 comparisons produces suboptimal code
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 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 for 128-bit comparisons if we enable gimple folding on such builtins. These included (old internal names): P10V_BUILTIN_VCMPEQUT P10V_BUILTIN_CMPNET P10V_BUILTIN_CMPGE_1TI P10V_BUILTIN_CMPGE_U1TI P10V_BUILTIN_VCMPGTUT P10V_BUILTIN_VCMPGTST P10V_BUILTIN_CMPLE_1TI P10V_BUILTIN_CMPLE_U1TI I disabled gimple folding for these with the new support, but we need to look into why we generated bad code here. I suspect it's something as simple as missing optab entries. This isn't a regression, just a potential improvement.
[Bug target/101985] vec_cpsgn parameter order
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.
[Bug target/101985] vec_cpsgn parameter order
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 in the wild that relies on present behavior would be helpful.
[Bug target/101985] vec_cpsgn parameter order
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.
[Bug target/101985] vec_cpsgn parameter order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101985 Bill Schmidt changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |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.
[Bug target/102024] [12 Regression] zero width bitfields and ABIs
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:
const char *url = CHANGES_ROOT_URL "gcc-10/changes.html#empty_base";
inform (input_location,
"parameter passing for argument of type %qT "
"when C++17 is enabled changed to match C++14 "
"%{in GCC 10.1%}", type, url);
[Bug target/102353] powerpc64le-linux-gnu build failure when build != host
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.
[Bug target/102353] powerpc64le-linux-gnu build failure when build != host
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/config/rs6000/t-rs6000 @@ -53,8 +53,7 @@ rbtree.o: $(srcdir)/config/rs6000/rbtree.c $(POSTCOMPILE) rs6000-gen-builtins: rs6000-gen-builtins.o rbtree.o - $(LINKER_FOR_BUILD) $(BUILD_LINKERFLAGS) $(BUILD_LDFLAGS) -o $@ \ - $(filter-out $(BUILD_LIBDEPS), $^) $(BUILD_LIBS) + $(LINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) $< rbtree.o -o $@ # TODO: Whenever GNU make 4.3 is the minimum required, we should use # grouped targets on this: Thanks! Bill
[Bug target/102353] powerpc64le-linux-gnu build failure when build != host
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 Ever confirmed|0 |1 CC||wschmidt at gcc dot gnu.org Last reconfirmed||2021-09-15 Status|UNCONFIRMED |NEW --- Comment #2 from Bill Schmidt --- Ah, sorry for the silly mistake. Mine.
[Bug target/93011] PowerPC GCC has warning that aggregate alignment changed in GCC 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93011 Bill Schmidt changed: What|Removed |Added Resolution|--- |FIXED Status|SUSPENDED |RESOLVED --- Comment #4 from Bill Schmidt --- We relented on this and removed it in GCC 12. :-)
[Bug target/102148] ppc64le: homogeneous float arguments are not passed correctly
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. It would be helpful to add some clarifying text for the following points. (1) The parameter save area layout is completely independent from the rules for passing homogeneous aggregates in registers. (2) The size of a homogeneous aggregate parameter in the parameter save area is the size of that aggregate by normal rules of alignment and padding. This means that the parameter save area for a homogeneous aggregate of 32-bit floats takes up less room than the amount of register space consumed. (3) The number of GPRs skipped is based upon the size of the aggregate in the parameter save area. An example of this exists (Figure 2.26 in revision 1.5), but it is easy to have difficulty spotting the information there.
[Bug target/102148] ppc64le: homogeneous float arguments are not passed correctly
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.
[Bug target/102107] protocol register (r12) corrupted before a tail call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102107 Bill Schmidt changed: What|Removed |Added CC||wschmidt at gcc dot gnu.org --- Comment #7 from Bill Schmidt --- Paul, what does gcc -v show?
[Bug target/102127] [12 Regression] ICE when compiling (m32) powerpc/440-mulchw-1.c since g:ff6bb9dde10ab665a35bb75527313cd9f7d52f8e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102127 Bill Schmidt changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from Bill Schmidt --- This should be fixed now, with commit of r12-3229. Please reopen if any of these failures still occur.
[Bug target/102127] [12 Regression] ICE when compiling (m32) powerpc/440-mulchw-1.c since g:ff6bb9dde10ab665a35bb75527313cd9f7d52f8e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102127 --- Comment #7 from Bill Schmidt --- ...by always initializing these types, not builtins...
[Bug target/102127] [12 Regression] ICE when compiling (m32) powerpc/440-mulchw-1.c since g:ff6bb9dde10ab665a35bb75527313cd9f7d52f8e
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 missed. Patch 18/34 (approved but not yet committed) should solve this problem by always initializing these builtins. Will catch up on commits and make sure the problems are fixed.
[Bug target/102127] [12 Regression] ICE when compiling (m32) powerpc/440-mulchw-1.c since g:ff6bb9dde10ab665a35bb75527313cd9f7d52f8e
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 combination here.
[Bug target/102127] [12 Regression] ICE when compiling (m32) powerpc/440-mulchw-1.c since g:ff6bb9dde10ab665a35bb75527313cd9f7d52f8e
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.
[Bug target/101865] _ARCH_PWR8 is not defined when using -mcpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865 --- Comment #11 from Bill Schmidt --- Thanks, Tulio, exactly right.
[Bug target/102024] [12 Regression] zero width bitfields and ABIs
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 for the previous example in both cases.
[Bug target/102024] [12 Regression] zero width bitfields and ABIs
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 no effect on the alignment of a structure
or union. However, the offsets of an individual bit field's member must comply
with the alignment rules. An unnamed bit field of zero width causes sufficient
padding (possibly none) to be inserted for the next member, or the end of the
structure if there are no more nonzero width members, to have an offset from
the start of the structure that is a multiple of the size of the declared type
of the zero-width member."
That's from ELFv2, but I imagine the same language exists in ELFv1, as I don't
believe this was meant to be a change from the previous ABI.
An example from the ABI to test is:
struct {
char c;
int : 0;
char d;
short : 9;
char e;
};
I wouuld expect that prior to Jakub's change, we would not see three bytes of
pad between c and d, but with his change, we would.
We can probably warn for this as well, but might be a little trickier. This is
more likely to come up than the homogeneous aggregate case, I guess.
[Bug target/102024] [12 Regression] zero width bitfields and ABIs
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 aggregates of floating-point and vector types in the ELFv2 ABI used for powerpc64le today. Before Jakub's change, we would (wrongly) treat the "struct S" as a homogeneous aggregate and pass the arguments in floating-point registers. With Jakub's change, we (correctly) pass the arguments in GPRs and/or memory. Otherwise I think our ABIs are unaffected. We'll need to add a Wpsabi message in the case where we used to recognize a homogeneous aggregate but no longer do. We ought to be able to add that easily in rs6000_discover_homogeneous_aggregate (rs6000-call.c).
[Bug c/102062] powerpc suboptimal unrolling simple array sum
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 extensions, and it's probably not worth messing around with variable expansion just for GCC 11... Nick, can you use the -ftree-vectorize -fvect-cost-model=cheap to deal with this (or even use -O3, which is recommended and probably does the same thing)? Or are you holding out for some fix in GCC 11.x?
[Bug c/102062] powerpc suboptimal unrolling simple array sum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102062 Bill Schmidt changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-08-25 --- Comment #4 from Bill Schmidt --- Interesting. I dug up an older GCC 11 compiler off of one of my systems and it behaves as you report. No idea why this should differ between 11 and 12, as the user of variable expansion as default goes back at least to 11 (I'm thinking as early as 9). Confirmed.
[Bug c/102062] powerpc suboptimal unrolling simple array sum
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.
[Bug c/102062] powerpc suboptimal unrolling simple array sum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102062 Bill Schmidt changed: What|Removed |Added CC||wschmidt at gcc dot gnu.org --- Comment #1 from Bill Schmidt --- Regarding the latter question, I'm surprised it's not being done. This behavior is controlled by -fvariable-expansion-in-unroller, which was enabled by default for PowerPC targets a couple of releases back. You reported this against GCC 11.2, but I'm skeptical. What options are you using? Compiling with -O2 and current trunk, I see variable expansion kicking in, and I also see the same base register in use in all references in the loop: test: .LFB0: .cfi_startproc .localentry test,1 slwi 4,4,1 li 10,0 li 7,0 addi 9,3,-4 extsw 4,4 andi. 6,4,0x3 addi 5,4,-1 mr 8,4 beq 0,.L9 cmpdi 0,6,1 beq 0,.L13 cmpdi 0,6,2 bne 0,.L22 .L14: lwzu 6,4(9) addi 4,4,-1 add 10,10,6 .L13: lwzu 6,4(9) cmpdi 0,4,1 add 10,10,6 beq 0,.L19 .L9: srdi 8,8,2 mtctr 8 .L2: lwz 4,4(9) lwz 5,12(9) lwz 6,8(9) lwzu 8,16(9) add 10,4,10 add 10,10,5 add 7,6,7 add 7,7,8 bdnz .L2 .L19: add 3,10,7 extsw 3,3 blr .p2align 4,,15 .L22: lwz 10,0(3) mr 9,3 mr 4,5 b .L14
[Bug target/101865] _ARCH_PWR8 is not defined when using -mcpu=power8
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 _ARCH_PWR8, as the other _ARCH levels are using stable tests that can't be so easily disabled.
[Bug tree-optimization/101830] [12 Regression] Incorrect error messages beginning with r12-2591 (backward jump threader)
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!
[Bug tree-optimization/101830] [12 Regression] Incorrect error messages beginning with r12-2591 (backward jump threader)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101830 Bill Schmidt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #11 from Bill Schmidt --- Aha. There is a coding bug in consume_whitespace () that *could* allow a buffer overrun. while (pos < LINELEN && isspace(linebuf[pos]) && linebuf[pos] != '\n') pos++; Subsequent reading of linebuf[pos] might read past the end of the buffer. There should be a guard afterwards if pos exceeds LINELEN - 1. Fixing this does allow the code to compile with the current compiler. So, I'm sorry for the false report. The warning message is still misleading, saying that there is definitely an overrun, when there is only the possibility of one. (We never encounter the overrun on a rather large set of inputs.) I'm not sure what can be done about that. I think the IL above that looks funky is probably just some sort of cut and paste problem. I didn't see the oddity in compiler dumps when I was trying to find it. So that's likely a red herring. Thanks for having a look, Martin!
[Bug tree-optimization/101830] [12 Regression] Incorrect error messages beginning with r12-2591 (backward jump threader)
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 cases.
[Bug tree-optimization/101830] [12 Regression] Incorrect error messages beginning with r12-2591 (backward jump threader)
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.
[Bug tree-optimization/101830] [12 Regression] Incorrect error messages beginning with r12-2591 (backward jump threader)
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 along that path is pos.80_81. For the index to be in the range [1024, INT_MAX] is absurd on its face, coming from BB 5 where it is clearly constrained to be within [INT_MIN, 1023]. Can you please explain? I don't understand this at all.
[Bug tree-optimization/101830] [12 Regression] Incorrect error messages beginning with r12-2591 (backward jump threader)
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 warning machinery to make this error, but I experimented with changes and nothing helps. Just to be clear: The code is fine. The warning is bogus.
[Bug tree-optimization/101830] [12 Regression] Incorrect error messages beginning with r12-2591 (backward jump threader)
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" to reproduce.
[Bug tree-optimization/101830] Incorrect error messages beginning with r12-2591 (backward jump threader)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101830 Bill Schmidt changed: What|Removed |Added Known to fail||12.0 Target Milestone|--- |12.0 Status|UNCONFIRMED |NEW Keywords||diagnostic, rejects-valid Target||powerpc*-*-* Ever confirmed|0 |1 CC||aldyh at gcc dot gnu.org, ||bergner at gcc dot gnu.org, ||msebor at gcc dot gnu.org, ||segher at gcc dot gnu.org Last reconfirmed||2021-08-09 --- Comment #1 from Bill Schmidt --- COnfirmed.
[Bug tree-optimization/101830] New: Incorrect error messages beginning with r12-2591 (backward jump threader)
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: 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 to commit the patch to start building the code, I found that it has recently stopped building due to bogus error messages. These started with r12-2591 (new backward jump threader) but is presumably also related to the new pass for array bounds checking. $ $GCC_INSTALL/bin/g++ $GCC_SRC/gcc/config/rs6000/rs6000-gen-builtins.c -c -O2 -Wall -Werror /home/wschmidt/newgcc/gcc/config/rs6000/rs6000-gen-builtins.c: In function 'int match_bracketed_pair(typeinfo*, char, char, restriction)': /home/wschmidt/newgcc/gcc/config/rs6000/rs6000-gen-builtins.c:824:22: error: array subscript 1024 is above array bounds of 'char [1024]' [-Werror=array-bounds] 824 | if (linebuf[pos] != ',') | ~~~^ /home/wschmidt/newgcc/gcc/config/rs6000/rs6000-gen-builtins.c:186:13: note: while referencing 'linebuf' 186 | static char linebuf[LINELEN]; | ^~~ /home/wschmidt/newgcc/gcc/config/rs6000/rs6000-gen-builtins.c:843:22: error: array subscript 1024 is above array bounds of 'char [1024]' [-Werror=array-bounds] 843 | if (linebuf[pos] != close) | ~~~^ /home/wschmidt/newgcc/gcc/config/rs6000/rs6000-gen-builtins.c:186:13: note: while referencing 'linebuf' 186 | static char linebuf[LINELEN]; | ^~~ ...and many more, all referencing uses of linebuf[pos]. There are several problems with these messages: (1) linebuf and pos are global variables, and the compiler cannot tell whether or not there are problems with array bounds accesses here. Indeed, pos is only incremented by a function called "safe_inc_pos" that ensures we *don't* ever access beyond the end of linebuf. (2) The error message is far too certain of itself! It says that we have definitely addressed out of bounds when that is certainly not known to be true. (3) Some uses of linebuf[pos] are flagged, and others are not, often within the same function. You can reproduce this as above with the code that is upstream in trunk. This is holding up committing some approved patches, so I appreciate anything you can do to sort this out.
[Bug testsuite/101531] [11 regression] gcc.target/powerpc/pr101129.c has excess errors after r11-8780
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101531 Bill Schmidt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Bill Schmidt --- Now fixed everywhere.
[Bug testsuite/101531] [11 regression] gcc.target/powerpc/pr101129.c has excess errors after r11-8780
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101531 Bill Schmidt changed: What|Removed |Added Target Milestone|11.2|11.3
[Bug testsuite/101531] [11 regression] gcc.target/powerpc/pr101129.c has excess errors after r11-8780
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101531 Bill Schmidt changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-07-21 Status|UNCONFIRMED |NEW --- Comment #3 from Bill Schmidt --- Fixed on trunk, awaiting backports. (Confirmed, BTW.)
[Bug testsuite/101531] [11 regression] gcc.target/powerpc/pr101129.c has excess errors after r11-8780
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 --- Comment #1 from Bill Schmidt --- Looks like an int128 dependency. Sorry to have missed that. Mine.
[Bug target/101129] [11/12 Regression] wrong code at -O1 since r11-5839
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101129 Bill Schmidt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Known to fail|11.1.1 | --- Comment #14 from Bill Schmidt --- Now fixed everywhere.
[Bug target/101129] [11/12 Regression] wrong code at -O1 since r11-5839
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101129 Bill Schmidt changed: What|Removed |Added Known to fail|12.0| Known to work||12.0 --- Comment #10 from Bill Schmidt --- Fixed on trunk, but will require backports.
