[Bug target/81288] [8/9/10 Regression] ICE on 32-bit BE powerpcspe w/ -misel -O2 (-O3, -Ofast, -Os)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81288 --- Comment #10 from Segher Boessenkool --- Works in GCC 9, as in, the target does not exist any more in GCC 9.
[Bug target/80700] [8 Regression] ICE: Bus error (on SPE target)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80700 Segher Boessenkool changed: What|Removed |Added Known to work||9.0 Summary|[8/9/10 Regression] ICE:|[8 Regression] ICE: Bus |Bus error (on SPE target) |error (on SPE target) --- Comment #11 from Segher Boessenkool --- The target has been removed in GCC 9.
[Bug target/86801] Powerpcspe port (may) need updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86801 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||segher at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #1 from Segher Boessenkool --- GCC 9 does not support powerpcspe.
[Bug target/86772] [meta-bug] tracking port status for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86772 Bug 86772 depends on bug 86801, which changed state. Bug 86801 Summary: Powerpcspe port (may) need updating for CVE-2017-5753 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86801 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX
[Bug target/86133] powerpc (-mcpu=8548) internal compiler error for double variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86133 Segher Boessenkool changed: What|Removed |Added Target Milestone|--- |8.5
[Bug target/85121] Assembler messages: Error: operand out of range (264 is not between 0 and 248)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85121 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org Target Milestone|--- |8.5
[Bug target/81628] Backport r250637 and r250638 to the powerpcspe* target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81628 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org Target Milestone|--- |8.5
[Bug target/71012] ICE: in expand_expr_real_2, at expr.c:9348 when compiling stress-ng
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71012 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org Target Milestone|--- |8.5
[Bug target/37759] powerpc option -mabi=no-spe still generates SPE instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37759 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org Target Milestone|--- |8.5
[Bug target/87083] ICE in extract_insn, at recog.c:2305 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87083 Segher Boessenkool changed: What|Removed |Added Target Milestone|--- |8.5
[Bug target/85170] ICE: in final_scan_insn_1, at final.c:3139 (error: could not split insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85170 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org Target Milestone|--- |8.5
[Bug target/84302] ICE: Segmentation fault (in extract_insn) on SPE target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84302 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org Target Milestone|--- |8.5
[Bug target/49854] Clean up SPE/e500 option handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49854 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org Target Milestone|--- |8.5
[Bug target/91638] powerpc -mlong-double-NN (documentation) issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91638 --- Comment #5 from Segher Boessenkool --- Yeah, not sure. A user can just do `-mlong-double-128`, and will get whichever 128-bit format is the default. That is the "old" way, when we only had the ibm128 format, and it will be the new way too, when ibm128 has become a bad dream and everything uses ieee128. Maybe just something like Use -mlong-double-128 for an 128-bit floating point format (either IEEE or IBM)?
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
Segher Boessenkool changed:
What|Removed |Added
Assignee|marxin at gcc dot gnu.org |segher at gcc dot
gnu.org
--- Comment #29 from Segher Boessenkool ---
I found the problem.
We have
===
/* Implement TARGET_SHRINK_WRAP_DISQUALIFY_COMPONENTS. */
void
rs6000_disqualify_components (sbitmap components, edge e,
sbitmap edge_components, bool /*is_prologue*/)
{
/* Our LR pro/epilogue code moves LR via R0, so R0 had better not be
live where we want to place that code. */
if (bitmap_bit_p (edge_components, 0)
&& bitmap_bit_p (DF_LIVE_IN (e->dest), 0))
{
if (dump_file)
fprintf (dump_file, "Disqualifying LR because GPR0 is live "
"on entry to bb %d\n", e->dest->index);
bitmap_clear_bit (components, 0);
}
}
===
But looks at LIVE_IN for the epilogue as well, which is wrong (should be
LIVE_OUT then, epilogue is placed at the end of the BB).
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #30 from Segher Boessenkool --- r10-6919 isn't good for Power, btw. Why would it *ever* be a good idea?
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #32 from Segher Boessenkool --- So it sounds like this helps for targets with tiny register sets?
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #34 from Segher Boessenkool --- Yeah, 16 (or really 12-ish, not all are available) I call "tiny" :-) It is very surprising (and not pleasantly so) that this overrides REG_ALLOC_ORDER. We allocate GPR0 last (of the volatile GPRs), on purpose. Other volatile registers we also do not do in order at all, and this has been heavily tuned over the years. And for non-GPRs it is even more wild, like CRs are 0 7 5 6 1 (and yes, this matters). We don't want HONOR_REG_ALLOC_ORDER, it is way *too* strict, but all else being equal, we probably(*) want our order to be followed, as it was before. (*) I didn't actually benchmark things yet!
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #30 from Segher Boessenkool --- I cannot reproduce the problem, btw (I cannot build a 32-bit hosted toolchain). Martin, you have a working recipe?
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #32 from Segher Boessenkool --- Sigh. No, this is *not* a target bug (or we certainly do not know it is), please stop marking it that. It seems to be a bug in shrink-wrapping, but the dump does not show enough information (only contradictory info :-/ ), and I cannot yet reproduce the problem.
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #33 from Segher Boessenkool --- (In reply to Martin Liška from comment #31) > (In reply to Segher Boessenkool from comment #30) > > I cannot reproduce the problem, btw (I cannot build a 32-bit hosted > > toolchain). > > Martin, you have a working recipe? > > Go to gcc110 machine and do: > $ CC="gcc -m32" CXX="g++ -m32" ../configure --enable-languages=c,c++ > --disable-lto > $ CC="gcc -m32" CXX="g++ -m32" make -j64 STAGE1_CFLAGS="-O2 -g" I did that (with /usr/bin/gcc etc. though, won't work at all otherwise), but that builds stage2 as 64-bit? Is that stage1 flags the secret sauce?
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #34 from Segher Boessenkool --- (In reply to Vladimir Makarov from comment #29) > Sorry for all the troubles with my latest patch and thank you for fair > criticism. I've decided to revert the patch as soon as git starts working. > I'll work to find a better solution after this. Thanks! Btw, on powerpc64-linux your patch changed the allocation order of the non-volatile registers, which is a big regression (we need bigger stack frames that way).
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #36 from Segher Boessenkool --- > > I did that (with /usr/bin/gcc etc. though, won't work at all otherwise), > > but that builds stage2 as 64-bit? > > Hm, that's possible. But the stage2 should not crash right? It doesn't work, of course (mixed 32-bit and 64-bit thing). And I need a 32-bit stage2 in any case, to have a compiler that miscompiles pt.c:tsubst_template_arg, to figure out why it thinks it as allowed to use GPR0 somewhere it obviously is live.
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #37 from Segher Boessenkool --- Oh wait. I am dumb I guess? You did those dumps with a stage1 compiler?
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #38 from Segher Boessenkool --- Then, how did you do that?
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #42 from Segher Boessenkool --- Okay, I see your dumps are 64-bit as well. But mine are very different, huh. Still, it crashes in pretty much the same way.
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #46 from Segher Boessenkool --- Thank you very much for that new testcase! I wish I had it before :-) Yesterday I found the problem. It is in separate shrink-wrapping. The fix is probably simple; hang on :-)
[Bug rtl-optimization/94148] The DF framework uses bb->aux, which is for passes only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94148 Segher Boessenkool changed: What|Removed |Added Blocks||94042 Target Milestone|--- |10.0 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 [Bug 94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
[Bug rtl-optimization/94148] New: The DF framework uses bb->aux, which is for passes only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94148
Bug ID: 94148
Summary: The DF framework uses bb->aux, which is for passes
only
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
df-core.c:df_worklist_dataflow_doublequeue uses bb->aux, clobbering it,
while that field is documented as
/* Auxiliary info specific to a pass. */
PTR GTY ((skip (""))) aux;
and some passes that do use DF also use bb->aux. This gives problems
with overlapping lifetimes.
This blocks fixing PR94042 properly.
[Bug target/94123] [10 regression] r10-1734, SVN r273240, causes gcc.target/powerpc/pr87507.c to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94123 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-03-11 Ever confirmed|0 |1 --- Comment #5 from Segher Boessenkool --- Confirmed. On p9 it is all fine. On p7 it is worse, you get std's followed by an lxvd2x from the same stack address (big LHS/SHL hazard there), and then two stxvd2x. On p8 the TImode values aren't split at all, not until final output anyway.
[Bug target/94135] PPC: subfic instead of neg used for rotate right
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94135 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #1 from Segher Boessenkool --- On what CPU do subfic and neg execute at different speed? (neg is better, of course, it doesn't write CA). GCC does not know rotates work for any masking of the amount (with 1's in the low 5 (resp. 6) bits); the rs6000 target code does not know about any masking (the SHIFT_COUNT_TRUNCATED macro cannot be used, but we could have more patterns, and then combine can do this in many cases).
[Bug target/94135] PPC: subfic instead of neg used for rotate right
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94135 Segher Boessenkool changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-03-11 Status|UNCONFIRMED |NEW
[Bug target/94145] Longcalls mis-optimize loading the function address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145 --- Comment #2 from Segher Boessenkool --- How could the function address ever not be constant? Hoisting it to somewhere where it is (dynamically) more expensive is a bad idea, of course.
[Bug target/94145] Longcalls mis-optimize loading the function address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145 --- Comment #3 from Segher Boessenkool --- C11 6.6/9 says it *always* is constant, even.
[Bug rtl-optimization/94148] The DF framework uses bb->aux, which is for passes only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94148 Segher Boessenkool changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org --- Comment #2 from Segher Boessenkool --- Yes, and it assumes it stays cleared for any new blocks, and some more subtleties. I have a patch.
[Bug target/94145] Longcalls mis-optimize loading the function address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145 --- Comment #10 from Segher Boessenkool --- The resolved address can only change before the first call to it, so we could even automatically insert code checking that, perhaps. My other concern is not slowing down the code if LD_BIND_NOW is in use.
[Bug target/94135] PPC: subfic instead of neg used for rotate right
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94135 --- Comment #3 from Segher Boessenkool --- Both subfic and neg are 1-2 if run on the integer units. neg can run on more units, but it is always 2 cycles then! (And the conditions where you *can* have 1 cycle are not very often satisfied, anyway).
[Bug rtl-optimization/94148] The DF framework uses bb->aux, which is for passes only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94148 --- Comment #3 from Segher Boessenkool --- Fixed on trunk so far.
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 Segher Boessenkool changed: What|Removed |Added Target|powerpc64-suse-linux|powerpc* Host|powerpc64-suse-linux| Build|powerpc64-suse-linux| --- Comment #48 from Segher Boessenkool --- Solved on trunk
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 Segher Boessenkool changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #49 from Segher Boessenkool --- Fixed.
[Bug rtl-optimization/94148] The DF framework uses bb->aux, which is for passes only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94148 --- Comment #4 from Segher Boessenkool --- Fixed on trunk so far.
[Bug rtl-optimization/94148] The DF framework uses bb->aux, which is for passes only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94148 --- Comment #5 from Segher Boessenkool --- commit 5c7e6d4bdf879b437b43037e10453275acabf521 Author: Segher Boessenkool Date: Thu Mar 12 07:12:50 2020 + df: Don't abuse bb->aux (PR94148, PR94042) The df dataflow solvers use the aux field in the basic_block struct, although that is reserved for any use by passes. And not only that, it is required that you set all such fields to NULL before calling the solvers, or you quietly get wrong results. This changes the solvers to use a local array for last_change_age instead, just like it already had a local array for last_visit_age. PR rtl-optimization/94148 PR rtl-optimization/94042 * df-core.c (BB_LAST_CHANGE_AGE): Delete. (df_worklist_propagate_forward): New parameter last_change_age, use that instead of bb->aux. (df_worklist_propagate_backward): Ditto. (df_worklist_dataflow_doublequeue): Use a local array last_change_age.
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 --- Comment #11 from Segher Boessenkool --- (In reply to Rich Felker from comment #10) > This is a rather huge bug to have been fixed silently. Could someone who > knows the commit that fixed it and information on what versions are affected > attach the info to the tracker here? And ideally some information on working > around it for older GCCs? > > From what I can tell experimenting so far, adding a dummy "0"(r0) > constraint, or using + instead of =, makes the problem go away, but > potentially has other ill effects from use of an uninitialized object..? This wasn't silent. There was a whole bunch of commits, all before this PR was filed. You can start looking at PR87600 maybe, and from there follow the trails. AFAIR all older versions (well, of this decade, anyway) have these problems, but the patches are much to involved to backport. You can work around it on older GCC by simply not using a register var for more than one asm operand, I think?
[Bug target/94176] New: rs6000/test: Fix selector in fold-vec-mule-misc.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94176 Bug ID: 94176 Summary: rs6000/test: Fix selector in fold-vec-mule-misc.c Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: segher at gcc dot gnu.org Target Milestone: --- (This PR is just to test BZ commit integration).
[Bug target/94176] rs6000/test: Fix selector in fold-vec-mule-misc.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94176 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Segher Boessenkool --- Fixed (and the integration looks to be fixed too, woohoo).
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 --- Comment #15 from Segher Boessenkool --- (In reply to Rich Felker from comment #12) > > You can work around it on older GCC by simply not using a register var > > for more than one asm operand, I think? > > Nope. Making a syscall inherently requires binding specific registers for > all of the inputs/outputs, unless you want to spill everything to an > explicit structure in memory and load them all explicitly in the asm block. > So it really is a big deal. I didn't say this very well... The only issue is using the same hard register for two different operands. You don't need to do this for syscalls (and you do not *need* that *ever*, of course). Can you post some code that fails? If you think this is a GCC bug (in some older branch?) that we should fix, please open a new PR for it.
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 --- Comment #20 from Segher Boessenkool --- Confirmed with various 7 and 8 (I don't have a mips 6 around). Don't reopen this bug, it is not necessarily related. Instead, please open a new PR. Thanks!
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 --- Comment #23 from Segher Boessenkool --- It is harder for us to track it in an older bug with many older patches for it, including stuff that needed fixups later. And, the "correct" older bug for it would not be this one, anyway! Before RA we have asm inputs [ (reg/v:SI 196 [ n ]) (reg/v:SI 4 $4 [ r4 ]) (reg/v:SI 5 $5 [ r5 ]) (reg/v:SI 6 $6 [ r6 ]) (reg/v:SI 7 $7 [ r7 ]) (reg/v:SI 8 $8 [ r8 ]) (reg/v:SI 9 $9 [ r9 ]) ] (and $2 an earlyclobber). But then IRA decides Disposition: 0:r195 l0 21:r196 l0 2 Peter, do you know which patch fixed this (is that the one you quoted above?), and if it could feasibly be backported separately? Only GCC 8 and later branches are still open, fwiw (but some distros still have older maintained versions). Rich, forcing "n" to be in "$r10" seems to do the trick? Is that a reasonable solution for you?
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 --- Comment #29 from Segher Boessenkool --- (In reply to Rich Felker from comment #27) > Also just realized: > > > Rich, forcing "n" to be in "$r10" seems to do the trick? Is that a > > reasonable > solution for you? > > It doesn't even work, because the syscall clobbers basically all > call-clobbered registers. Current kernels are preserving at least $25 (t9) > and $28 (gp) and the syscall argument registers, so $25 may be usable, but > it was deemed not clear in 2012. I'm looking back through musl git history, > and this is actually why the "i" alternative was wanted -- in basically all > uses, "i" is satisfiable, and avoids needing to setup a stack frame and > spill a call-saved register to the stack in order to use it to hold the > syscall number to reload on restart. You need to make $r10 not a clobber but an inout, of course. And not allowing the "i" just costs one more register move, not so bad imo. So you do have a workaround now. Of course we should see if this can actually be fixed instead ;-)
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 --- Comment #31 from Segher Boessenkool --- An asm clobber just means "may be an output", and no operand will be assigned a register mentioned in a clobber. There is no magic.
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #32 from Segher Boessenkool ---
===
#define SYSCALL_CLOBBERLIST \
"$1", "$3", "$11", "$12", "$13", \
"$14", "$15", "$24", "$25", "hi", "lo", "memory"
long syscall6(long n, long a, long b, long c, long d, long e, long f)
{
register long r4 __asm__("$4") = a;
register long r5 __asm__("$5") = b;
register long r6 __asm__("$6") = c;
register long r7 __asm__("$7") = d;
register long r8 __asm__("$8") = e;
register long r9 __asm__("$9") = f;
register long r10 __asm__("$10") = n;
register long r2 __asm__("$2");
__asm__ __volatile__ (
"subu $sp,$sp,32 ; sw $8,16($sp) ; sw $9,20($sp) ; "
"addu $2,$0,%4 ; syscall ;"
"addu $sp,$sp,32 # %0 %1 %2 %3 %4 %5 %6 %7"
: "=&r"(r2), "+r"(r7), "+r"(r8), "+r"(r9)
: "ir"(r10), "r"(r4), "r"(r5), "r"(r6)
: SYSCALL_CLOBBERLIST);
return r7 && r2>0 ? -r2 : r2;
}
long syscall69(long a, long b, long c, long d, long e, long f) { return
syscall6(9, a, b, c, d, e, f); }
===
This is inlined just fine?
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 --- Comment #34 from Segher Boessenkool --- Oh, your real code is different, and $10 doesn't work for that? I see.
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 --- Comment #36 from Segher Boessenkool --- The kernel jumps back to an instruction *before* the syscall?!? (I do not want to know about that any more, then, I am sure :-) )
[Bug target/94135] PPC: subfic instead of neg used for rotate right
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94135 --- Comment #5 from Segher Boessenkool --- Please try it out on hardware (or on a cycle-accurate simulator) if you don't believe me ;-)
[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886 --- Comment #36 from Segher Boessenkool --- (In reply to Rich Felker from comment #34) > Per the IBM docs, LE/elfv2 (which they confusingly equate) Where do you see this, btw? The introduction of the ABI doc says > The OpenPOWER ELF V2 ABI is intended for use in little- and big-endian > environments. and I don't see it contradict that elsewhere.
[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886 --- Comment #37 from Segher Boessenkool --- Oh, hrm, I am looking at an older version. Ugh.
[Bug target/87583] error: unrecognizable insn on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87583 --- Comment #5 from Segher Boessenkool --- commit 68dd57808f7c0147acdb5ca72c88ff655afcb0ce Author: Carl Love Date: Fri Mar 20 18:15:05 2020 -0500 rs6000: Add command line and builtin compatibility check 2020-03-20 Carl Love PR/target 87583 * gcc/config/rs6000/rs6000.c (rs6000_option_override_internal): Add check for TARGET_FPRND for Power 7 or newer.
[Bug target/94254] [10 regression] r10-7312 causes compiler hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254 --- Comment #8 from Segher Boessenkool --- SFmode values are stored as DP IEEE float normally. There may be other cases as well, but this is the obvious one.
[Bug target/94254] [10 regression] r10-7312 causes compiler hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254 Segher Boessenkool changed: What|Removed |Added CC||meissner at gcc dot gnu.org --- Comment #10 from Segher Boessenkool --- An SDmode value is stored in the rightmost 32 bits of an FPR, while a DDmode one uses all 64 bits of an FPR. So yeah I think you're plan is correct and will work. (Cc: Mike, he should know more, I only read manuals :-) )
[Bug target/94254] [10 regression] r10-7312 causes compiler hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254 --- Comment #12 from Segher Boessenkool --- That patch looks fine, thank you! Is there some way you can test if this works? Ideally in the testsuite of course, but that can be hard :-/
[Bug target/94254] [10 regression] r10-7312 causes compiler hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254 --- Comment #15 from Segher Boessenkool --- (In reply to rsand...@gcc.gnu.org from comment #13) > (In reply to Segher Boessenkool from comment #12) > > That patch looks fine, thank you! > > > > Is there some way you can test if this works? Ideally in the testsuite > > of course, but that can be hard :-/ > > I've now tried doing a bootstrap & regtest with --with-cpu-power6 as well, > comparing without the lra patch with after both patches. (With master the > build hangs in the same way as it did for Zdenek.) There didn't seem > to be any differences in test results. > > Hopefully that will have given some execution test coverage when > running things like gcc.dg/dfp and c-c++-common/dfp. Excellent :-) Segher
[Bug target/94254] [10 regression] r10-7312 causes compiler hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254 --- Comment #16 from Segher Boessenkool --- (In reply to Zdenek Sojka from comment #14) > (In reply to rsand...@gcc.gnu.org from comment #11) > > Created attachment 48088 [details] > > Candidate patch > > It fixes the build for me. > I am unable to find a way how to run the testsuite on a non-native system > (using qemu userspace emulation). Yeah, with qemu it is harder than with proper emulators (qemu does not mimic any existing cpu model closely). It should be possible if you do some magic in a boards file. Maybe ask on gcc@? And/or start a topic for it on the wiki?
[Bug target/81594] Optimize PowerPC vector set and store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81594 --- Comment #5 from Segher Boessenkool --- Hi Mike, Please explain (in the code!) why we need a peephole here, why we cannot generate the faster code earlier? Or why we choose not to? Etc.
[Bug target/81594] Optimize PowerPC vector set and store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81594 --- Comment #7 from Segher Boessenkool --- Peepholes catch fewer cases, and it is very hard to write correct peepholes. The only reason to use peepholes is when the other passes leave some important optimisation on the table, and you cannot feasibly fix that problem. They are not a substitute for proper optimisation (for example, almost all "interesting" optimisation happen before it, so you cannot rely on combine or cse or *prop etc. to do anything -- so, if you want some simple optimisations with it you need to write that manually (an exponential amount of work). This even applies to "trivial" things like constant arguments. Peepholes are nice for mopping up those cases that for one reason or the other the other compiler passes cannot / do not get right. They can "tune" the compiler output to be just a teeny bit better. They cannot do anything more than that.
[Bug middle-end/86715] ICE passing too large argument on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86715 Segher Boessenkool changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #2 from Segher Boessenkool --- "struct Matrix" is over 2GB big. The whole stack is just a few megabytes typically. Passing "struct Matrix" on the stack is entirely unreasonable. The comment right before this sorry() is /* We don't allow passing huge (> 2^30 B) arguments by value. It would cause an overflow later on. */ and this is in generic code. Closing as WONTFIX. Sorry.
[Bug target/87163] ICE in extract_insn, at recog.c:2305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163 --- Comment #9 from Segher Boessenkool --- So what causes this TF vs. IF? Cross and native should be exactly the same, but perhaps there is a difference in the configurations you have for the two?
[Bug target/87163] ICE in extract_insn, at recog.c:2305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163 --- Comment #13 from Segher Boessenkool --- If both compilers default to ibmlongdouble, both should use TFmode, no?
[Bug c/94389] __attribute__((warn_unused_result)) will warn if the result is discarded as an optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94389
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
CC||segher at gcc dot gnu.org
Last reconfirmed||2020-03-30
--- Comment #2 from Segher Boessenkool ---
Earlier than that, we have
;; Function get_flags (null)
;; enabled by -tree-original
{
return text_mode ();, 0;
}
which already has lost (and looks funny btw).
Confirmed btw.
[Bug c/94389] __attribute__((warn_unused_result)) will warn if the result is discarded as an optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94389 --- Comment #3 from Segher Boessenkool --- The C frontend dumps nothing for -fdump-lang-all, but the C++ frontend shows (in .002l.raw) that the ?: is optimised to just a constant zero there, already.
[Bug c/94389] __attribute__((warn_unused_result)) will warn if the result is discarded as an optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94389 --- Comment #5 from Segher Boessenkool --- The language frontend shouldn't do this kind of code transformations, whether you think the warning should warn or not here, imo.
[Bug c/94389] __attribute__((warn_unused_result)) will warn if the result is discarded as an optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94389 --- Comment #7 from Segher Boessenkool --- (In reply to felix from comment #6) > I don’t mind the transformation being applied. That is not what I said. I said the **language frontend** should not do this. A language frontend should give an as faithful as possible description of the source code to the rest of the compiler.
[Bug target/94420] [8/9/10 Regression] ICE error: insn does not satisfy its constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94420 --- Comment #2 from Segher Boessenkool --- Reserving a register that already *is* reserved (by the ABI) is undefined, of course. But we shouldn't ICE.
[Bug target/94420] [8/9/10 Regression] ICE error: insn does not satisfy its constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94420 --- Comment #4 from Segher Boessenkool --- cprop1 has done LOCAL COPY-PROP: Replacing reg 2 in insn 7 with reg 118 which is wrong: the insn isn't valid after that. But there is nothing that expresses that, the "R" constraint "just" becomes unsatisfiable.
[Bug target/94420] [8/9/10 Regression] ICE error: insn does not satisfy its constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94420 --- Comment #5 from Segher Boessenkool --- It is undefined behaviour to access such a register in any way -- sure, you *can* inspect it, there just is no guarantee at all what value you will get. It still is a useful thing to do in debug code and the like, of course.
[Bug target/94420] [8/9/10 Regression] ICE error: insn does not satisfy its constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94420 Segher Boessenkool changed: What|Removed |Added Keywords|ice-on-invalid-code |ice-on-valid-code --- Comment #7 from Segher Boessenkool --- But okay, let's call it valid code, it doesn't actually *do* anything with the undefined value in this example :-)
[Bug target/94420] [8/9/10 Regression] ICE error: insn does not satisfy its constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94420 Segher Boessenkool changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org --- Comment #8 from Segher Boessenkool --- I put it in the insn condition, testing it now.
[Bug target/94420] [8/9/10 Regression] ICE error: insn does not satisfy its constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94420 --- Comment #9 from Segher Boessenkool --- diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md index dcccb03..11ab745 100644 --- a/gcc/config/rs6000/rs6000.md +++ b/gcc/config/rs6000/rs6000.md @@ -10311,7 +10311,8 @@ (define_insn "*largetoc_low_aix" (define_insn_and_split "*tocref" [(set (match_operand:P 0 "gpc_reg_operand" "=b") (match_operand:P 1 "small_toc_ref" "R"))] - "TARGET_TOC" + "TARGET_TOC +&& legitimate_constant_pool_address_p (operands[1], QImode, false)" "la %0,%a1" "&& TARGET_CMODEL != CMODEL_SMALL && reload_completed" [(set (match_dup 0) (high:P (match_dup 1))) This works on the testcase fine; regression testing now.
[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886 --- Comment #39 from Segher Boessenkool --- commit 07fe4af4d51d74b63a76ea632d4db01d1f69f037 Author: Segher Boessenkool Date: Wed Mar 18 21:58:45 2020 + rs6000: Add back some w* constraints (PR91886) In May and June last year I deleted many of our (vector) constraints. We can now just use "wa" for those, together with some other conditions, which can be per alternative using the "enabled" attribute (which in turn primarily uses the "isa" attribute). But, it turns out that Clang implements some of those constraints as well, and at least musl uses some of them. It is easy for us to add those contraints back (as undocumented aliases to "wa", which always did mean the same thing for valid inline assembler code), so do that. gcc/ * config/rs6000/constraints.md (wd, wf, wi, ws, ww): New undocumented aliases for "wa". (I forgot to mark it appropriately, whoops).
[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886 --- Comment #41 from Segher Boessenkool --- Fixed.
[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886 Segher Boessenkool changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #42 from Segher Boessenkool --- I said FIXED. Grr, BZ.
[Bug target/91804] [10 regression] r265398 breaks gcc.target/powerpc/vec-rlmi-rlnm.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91804
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|NEW
CC||bergner at gcc dot gnu.org
--- Comment #1 from Segher Boessenkool ---
This extra move is created by IRA:
Examining insn 22, def for 133
all ok and transp
Creating newreg=134 from oldreg=133
rescanning insn with uid = 22.
scanning new insn with uid = 25.
New r134: setting preferred ALTIVEC_REGS, alternative VSX_REGS
Why?!
It was
(insn 22 11 20 2 (set (reg:V16QI 133)
(vec_duplicate:V16QI (const_int 8 [0x8]))) "vec-rlmi-rlnm.c":45:10 1204
{xxspltib_v16qi}
(nil))
and it is used only in
(insn 23 19 9 2 (set (reg:V2DI 127)
(unspec:V2DI [
(reg:V16QI 133)
] UNSPEC_VSX_SIGN_EXTEND)) "vec-rlmi-rlnm.c":45:10 1533
{vsx_sign_extend_qi_v2di}
(expr_list:REG_DEAD (reg:V16QI 133)
(expr_list:REG_EQUAL (const_vector:V2DI [
(const_int 8 [0x8]) repeated x2
])
(nil
so copying it to another reg cannot help anything here?
Peter, can you take a look?
[Bug tree-optimization/94451] [10 Regression] April 1st 2020 GCC does not compile spec 2017 gcc_r benchmark with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94451 Segher Boessenkool changed: What|Removed |Added Priority|P2 |P1 --- Comment #4 from Segher Boessenkool --- powerpc*-linux is a primary platform, so anything "critical" is a P1.
[Bug target/61837] missed loop invariant expression optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61837 --- Comment #4 from Segher Boessenkool --- If the ble 7,.L7 is taken once, it will be taken all of the time, since cr7 isn't assigned to any more -- and then the whole loop does nothing.
[Bug rtl-optimization/94291] [10 Regression] ICE: in reg_or_subregno, at jump.c:1928 at -Og since r10-3993-ga79048f6250febc1acce09d790035276d534e754
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94291 --- Comment #7 from Segher Boessenkool --- Doesn't it still need backports?
[Bug rtl-optimization/94291] [10 Regression] ICE: in reg_or_subregno, at jump.c:1928 at -Og since r10-3993-ga79048f6250febc1acce09d790035276d534e754
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94291 --- Comment #9 from Segher Boessenkool --- You mean you do not have a good enough testcase yet :-( Okay.
[Bug target/61837] missed loop invariant expression optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61837 --- Comment #6 from Segher Boessenkool --- But -funswitch-loops is much stronger than we want here, and the wrong thing to use at -O2 (it often generates *slower* code!)
[Bug target/61837] missed loop invariant expression optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61837
--- Comment #8 from Segher Boessenkool ---
-funswitch-loops changes things like
for (...) {
if (...)
...1;
else
...2;
}
into
if (...) {
for (...)
...1;
} else {
for (...)
...2;
}
which often is not a good idea. This is why this is not done at -O2:
-O2 is only for optimisations that almost never hurt performance.
[Bug rtl-optimization/93974] [10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
--- Comment #23 from Segher Boessenkool ---
(cannot_substitute_mem_equiv_p,
"A target hook which returns @code{true} if @var{subst} can't\n\
substitute safely pseudos with equivalent memory values during\n\
register allocation.\n\
I guess "ICEs the compiler" falls under "not safely" ;-)
Since AltiVec addresses are "legacy", this is a fine change (well
I haven't seen the actual patch yet, heh).
[Bug target/94613] S/390: Wrong code generated for vec_sel builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613 Segher Boessenkool changed: What|Removed |Added Target|s390x |s390x powerpc*-*-* Last reconfirmed||2020-04-16 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #7 from Segher Boessenkool --- Yes. The rs6000 code is bad as well: (define_insn "*altivec_vsel" [(set (match_operand:VM 0 "altivec_register_operand" "=v") (if_then_else:VM (ne:CC (match_operand:VM 1 "altivec_register_operand" "v") (match_operand:VM 4 "zero_constant" "")) (match_operand:VM 2 "altivec_register_operand" "v") (match_operand:VM 3 "altivec_register_operand" "v")))] "VECTOR_MEM_ALTIVEC_P (mode)" "vsel %0,%3,%2,%1" [(set_attr "type" "vecmove")]) That is not what the insn does (the compare should be *bitwise*: it does op0 := (op2 & ~op1) | (op3 & op1) This can be written a few different ways in RTL; we'll have to find out what works best.
[Bug target/94630] General bug for changes needed to switch the PowerPC long double default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94630 --- Comment #6 from Segher Boessenkool --- Please mention in the TITLE that this is ONLY for the ELFv2 ABI?
[Bug target/94420] [8/9 Regression] ICE error: insn does not satisfy its constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94420 Segher Boessenkool changed: What|Removed |Added Summary|[8/9/10 Regression] ICE |[8/9 Regression] ICE error: |error: insn does not|insn does not satisfy its |satisfy its constraints |constraints Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #12 from Segher Boessenkool --- And backports haven't been done yet. Don't close bugs like this, just edit the title :-)
[Bug rtl-optimization/94665] missed minmax optimization opportunity for if/else structure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94665 Segher Boessenkool changed: What|Removed |Added Last reconfirmed||2020-04-20 Ever confirmed|0 |1 CC||segher at gcc dot gnu.org Status|UNCONFIRMED |WAITING
[Bug rtl-optimization/94665] missed minmax optimization opportunity for if/else structure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94665 --- Comment #2 from Segher Boessenkool --- If vara is a NaN, this is not the same; it needs -ffinite-math-only. And in fact adding that option does the trick (on powerpc that is, I don't have an aarch64 Fortran handy). Could you check this please?
[Bug rtl-optimization/94665] missed minmax optimization opportunity for if/else structure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94665 --- Comment #5 from Segher Boessenkool --- Can you show the -fdump-rtl-combine-all dump where that insn is created? It is fine to generate min or max insns here; but you need to handle the case where vara is NaN: you should return that NaN then. Other than that your function is just the max of vara, varb, varc.
[Bug rtl-optimization/94665] missed minmax optimization opportunity for if/else structure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94665 --- Comment #7 from Segher Boessenkool --- Can r94 or r93 be NaN there? (I should build an aarch64 compiler... takes almost a day though :-) )
[Bug rtl-optimization/94665] missed minmax optimization opportunity for if/else structure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94665
Segher Boessenkool changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID |---
--- Comment #9 from Segher Boessenkool ---
Okay, native aarch64 compiler built. Phew.
vara, varb, varc are in regs r92, r93, r94. The code before combine is:
37: cc:CCFPE=cmp(r92:SF,r93:SF)
38: r93:SF={(cc:CCFPE<0)?r93:SF:r92:SF}
REG_DEAD r92:SF
REG_DEAD cc:CCFPE
39: cc:CCFPE=cmp(r94:SF,r93:SF)
40: r94:SF={(cc:CCFPE<0)?r94:SF:r93:SF}
REG_DEAD r93:SF
REG_DEAD cc:CCFPE
and it leaves 37+38 as it was:
Trying 37 -> 38:
37: cc:CCFPE=cmp(r92:SF,r93:SF)
38: r93:SF={(cc:CCFPE<0)?r93:SF:r92:SF}
REG_DEAD r92:SF
REG_DEAD cc:CCFPE
Failed to match this instruction:
(set (reg:SF 93 [ _2 ])
(if_then_else:SF (lt (reg:SF 92 [ _1 ])
(reg:SF 93 [ _2 ]))
(reg:SF 93 [ _2 ])
(reg:SF 92 [ _1 ])))
but it combines 39+40:
Trying 39 -> 40:
39: cc:CCFPE=cmp(r94:SF,r93:SF)
40: r94:SF={(cc:CCFPE<0)?r94:SF:r93:SF}
REG_DEAD r93:SF
REG_DEAD cc:CCFPE
Successfully matched this instruction:
(set (reg:SF 94 [ _4 ])
(smin:SF (reg:SF 94 [ _4 ])
(reg:SF 93 [ _2 ])))
allowing combination of insns 39 and 40
original costs 4 + 4 = 8
replacement cost 8
deferring deletion of insn with uid = 39.
modifying insn i340: r94:SF=smin(r94:SF,r93:SF)
REG_DEAD r93:SF
deferring rescan insn with uid = 40.
So huh, simplify_if_then_else seems to be buggy:
/* Look for MIN or MAX. */
if ((! FLOAT_MODE_P (mode) || flag_unsafe_math_optimizations)
&& comparison_p
&& rtx_equal_p (XEXP (cond, 0), true_rtx)
&& rtx_equal_p (XEXP (cond, 1), false_rtx)
&& ! side_effects_p (cond))
that isn't correct afaics?
[Bug rtl-optimization/94665] missed minmax optimization opportunity for if/else structure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94665 --- Comment #10 from Segher Boessenkool --- (Because it should handle NaNs, and SMAX etc. do not).
[Bug rtl-optimization/94665] missed minmax optimization opportunity for if/else structure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94665 Segher Boessenkool changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org Priority|P3 |P2 --- Comment #11 from Segher Boessenkool --- Confirmed the comment 4 problem, on all archs. This is a very old bug.
[Bug rtl-optimization/94665] missed minmax optimization opportunity for if/else structure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94665 --- Comment #15 from Segher Boessenkool --- replacing flag_unsafe_math_operations by flag_finite_math_only isn't correct, but you can add it instead, i.e. - if ((! FLOAT_MODE_P (mode) || flag_unsafe_math_optimizations) + if (!FLOAT_MODE_P (mode) + || (flag_unsafe_math_optimizations && flag_finite_math_only)) or such? Thanks for working on a patch!
[Bug target/94710] [8/9/10 Regression] Assembler messages: Error: operand out of range (4 is not between 0 and 3) (xxsldwi 0,32,33,4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94710 Segher Boessenkool changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org
