https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119702
--- Comment #15 from Segher Boessenkool ---
(In reply to Avinash Jayakar from comment #14)
> (In reply to Surya Kumari Jangala from comment #12)
> > Ok. We also need to tackle the original issue, which is that a shift left
> > can be optimized b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119702
--- Comment #13 from Segher Boessenkool ---
(In reply to Surya Kumari Jangala from comment #12)
> Ok. We also need to tackle the original issue, which is that a shift left
> can be optimized by generating a vector add. Perhaps tackle this issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119702
--- Comment #11 from Segher Boessenkool ---
> Segher, is this a case of needing to add a combiner pattern to translate that
> splat/shift into an add of itself?
You only ever do "combiner patterns" to recognise something that combine
generates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118480
--- Comment #15 from Segher Boessenkool ---
(In reply to Steven Munroe from comment #12)
> Also from PowerISA 3.1C
>
> The result is placed into VSR[VRT+32], except if, for any
> byte element in VSR[VRB+32], the low-order 3 bits are not
> equal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118480
--- Comment #14 from Segher Boessenkool ---
(In reply to Steven Munroe from comment #11)
> And as you point out the instructions vslo/vsro/vsl/vsr only care about bits
> 121..127. Also older machines needed the byte splat for vsl/vsr.
vslq look
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118480
--- Comment #13 from Segher Boessenkool ---
(In reply to Segher Boessenkool from comment #9)
> Both vsl and vslo actually look only at the right-most byte in the shift
> amount argument (bits 125..127 resp. bits 121..124). In original AltiVec i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118480
--- Comment #10 from Segher Boessenkool ---
(In reply to Steven Munroe from comment #8)
> It seems the evolution of the PowerISA and Vector intrinsics has not been
> smooth.
>
> It is not obvious how to generate xxspltib from an intrinsic.
> Ve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118480
--- Comment #9 from Segher Boessenkool ---
Both vsl and vslo actually look only at the right-most byte in the shift
amount argument (bits 125..127 resp. bits 121..124). In original AltiVec it
was required to hold the same value in every lane, b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118890
--- Comment #6 from Segher Boessenkool ---
So, is this all done now?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119702
--- Comment #5 from Segher Boessenkool ---
But of course we need -mcpu=power8 or later for that insn.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119702
--- Comment #4 from Segher Boessenkool ---
No, we should generate code as Peter says in #c1. Doing a shift is worse
code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115242
--- Comment #10 from Segher Boessenkool ---
(In reply to Florian Weimer from comment #9)
> (In reply to Segher Boessenkool from comment #8)
> > Can we have a testcase please?
>
> The test case in glibc: https://sourceware.org/bugzilla/show_bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115242
--- Comment #8 from Segher Boessenkool ---
Can we have a testcase please?
It sounds like the glibc you used was misconfigured. Of course VSX registers
are not restored by the GCC unwinder stuff if you configured GCC to not support
VSX register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118480
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2025-07-30
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93738
--- Comment #15 from Segher Boessenkool ---
(In reply to Kishan Parmar from comment #13)
> Operand of 10 gets converted to below insn
>
> (and:SI (subreg:SI (lshiftrt:DI (reg:DI 129 [ x+-4 ])
> (const_int 12 [0xc])) 4)
> (const_i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119382
--- Comment #11 from Segher Boessenkool ---
The flag wil help. But it isn't as permanent as you should like: it's not
really more than a side effect.
So it won't really vanquish the problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115800
Segher Boessenkool changed:
What|Removed |Added
Status|RESOLVED|WAITING
Resolution|WONTFIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115800
--- Comment #10 from Segher Boessenkool ---
(In reply to Michael Meissner from comment #8)
> Given powerpcle64 requires a minimum of power8, I'm not sure it is worth
> making libgfortran and libstdc++ build using --with-cpu=power5.
In the past,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115800
--- Comment #9 from Segher Boessenkool ---
(In reply to Andreas Schwab from comment #7)
> It is generally assumed that powerpc64le-*-* implies POWER7+ (glibc even
> requires POWER8+). This is independent of the older -mlittle support (which
> d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93738
--- Comment #12 from Segher Boessenkool ---
> However, this pattern is failing to match in some cases,
> and we end up with two separate instructions: one for rotate and another for
> insert.
So this is *not* a combine problem at all you say? J
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108958
--- Comment #4 from Segher Boessenkool ---
(Btw, the subject says "powerpcle", but this is about something very different:
powerpc64le. "powerpcle" is also a valid first component of a target triple!
Almost no one used 32-bit PowerPC in wrong-e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120805
--- Comment #14 from Segher Boessenkool ---
Hi!
(In reply to Avinash Jayakar from comment #12)
> (In reply to Segher Boessenkool from comment #10)
> > As a meta-comment: almost everything using scan-assembler-times is
> > obfuscated.
> >
> > It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120805
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121095
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118480
--- Comment #4 from Segher Boessenkool ---
It's the splitter at altivec.md:321
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118480
--- Comment #3 from Segher Boessenkool ---
Does xxspltib_constant_p return the wrong num_insns, or is the problem
something
lower, some splitter?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007
--- Comment #14 from Segher Boessenkool ---
Thanks!
If there is anything we (Power people) can do, please let us know!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117007
--- Comment #17 from Segher Boessenkool ---
Hi!
So, why do we not generate xxspltib where it would help. Please send a patch?
Improvements will usually be to the xxspltib-generating code itself, not to
the legacy code that generates the old (c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87949
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007
--- Comment #12 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #11)
> Though even there is uninitialized read I guess from temp.a.
> That said, LRA obviously shouldn't hang even on code which has UB at runtime.
Of course.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007
--- Comment #9 from Segher Boessenkool ---
Hrm, the insn here is just a mulldi instruction, a bog-standard integer
multiplication (by a constant, 6 here).
But insn 58 (where the problems start, "Changing address in insn 58
r218:DI&0xfff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007
--- Comment #8 from Segher Boessenkool ---
(Also tested on powerpc-linux (where things just work), and on powerpc64-linux
(the older ABI, correct-endian), where it fails just the same as on LE).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007
--- Comment #7 from Segher Boessenkool ---
Cool, thanks!
121007.c:36:3: warning: 'v4' may be used uninitialized [-Wmaybe-uninitialized]
No clue why it says "may be" there, it obviously *is* used uninitialised,
this is the first time it is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007
--- Comment #4 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #1)
> This is definitely sounding more and more like PR 93658.
Yes, and maybe the error / fix / workaround will be similar: replace a
VECTOR_MEM_ALTIVEC_P by VEC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007
--- Comment #3 from Segher Boessenkool ---
Does anyone want to take this? Fame and fortune await!
We need a reduced test case btw :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101882
--- Comment #26 from Segher Boessenkool ---
(In reply to chenglulu from comment #25)
> > And if the input is non-sensical, the compiler output will be as well, or
> > the
> > compiler can give up in some cases.
> >
> I also don't quite agree t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120983
--- Comment #3 from Segher Boessenkool ---
Please attach a testcase, and how to compile the code (-O2 etc.). Oh, and fill
in
the target field :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101882
--- Comment #24 from Segher Boessenkool ---
(In reply to Xi Ruoyao from comment #21)
> (In reply to Segher Boessenkool from comment #20)
> > (In reply to Peter Bergner from comment #17)
> > > The reason operands 0, 1 and 4 all use the register r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101882
--- Comment #23 from Segher Boessenkool ---
It is a different target. Your issue has nothing at all to do with the
problem we used to have. The root cause is very likely completely unrelated.
Etc. etc. etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101882
--- Comment #20 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #17)
> The reason operands 0, 1 and 4 all use the register r23, is that each
> operand is using the same pseudo, coming from variable "x", which is a user
> defi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101882
--- Comment #19 from Segher Boessenkool ---
Hi Peter!
(In reply to Peter Bergner from comment #18)
> So the error message is coming from this hunk in my patch:
>
> + /* Both the earlyclobber operand and conflicting operand
> +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101882
--- Comment #16 from Segher Boessenkool ---
It is allowed by recog(). Most likely your pattern is incorrect, but it
is not completely impossible there is something wrong in genrecog.cc --
but that isn't combine either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101882
--- Comment #14 from Segher Boessenkool ---
(match_operand:DI 1 "register_operand" "r0")
That means either a general register ("r"), or the same thing as operand 0
(that's what "0" means)!
So the backend explicitly allows it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934
--- Comment #14 from Segher Boessenkool ---
Congratulations, and thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120598
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 120598, which changed state.
Bug 120598 Summary: Compiler is unable to vectorise scalar code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120598
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120598
--- Comment #8 from Segher Boessenkool ---
(In reply to Jeevitha from comment #6)
> The following dot_product function gets vectorized with the latest GCC trunk
> and gcc 15.1.0:
>
> #include
> #include
> extern float dot_product(const int16_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120598
--- Comment #7 from Segher Boessenkool ---
[I cannot read any of the attached code, but...]
The proposed manually vectorised code converts 64-bit integers to IEEE SP
floats,
which is extremely lossy. I don't find it very surprising the compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120681
--- Comment #2 from Segher Boessenkool ---
What is this testcase meant to test? The only thing it *does* test is if this
trivial piece of code compiles at all (it doesn't test if the code generated is
correct, or anything else about it!)
It ju
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120519
--- Comment #10 from Segher Boessenkool ---
I was not cc:'ed. And I did not approve it. It should not have been
committed.
We have (minimal!) process for a reason. It would be chaos without it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74585
--- Comment #17 from Segher Boessenkool ---
The stack is always in memory, AFAIK :-) Do we have any targets where it
is not? Do we have any targets where BLKmode is not always in memory? That
is something that should be documented btw :-)
Any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120519
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74585
--- Comment #15 from Segher Boessenkool ---
The compiler now seems to assume in earlier passes that parameters and
return values are passed in memory. This is very sub-optimal, all but the
last passes cannot do much useful work this way.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115576
--- Comment #9 from Segher Boessenkool ---
This belong in simplify-rtx, not in combine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108415
--- Comment #9 from Segher Boessenkool ---
What is the current state here?
We should simply not allow -mmodulo at all if we do not generate such
insns (we do not have a -mcpu= that allows those). We do not want
multiple ways to do thing, certa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108273
--- Comment #10 from Segher Boessenkool ---
The problem seems to be in generic scheduling code, not in the Power backend.
Can someone confirm this, or point out where the problem is, is show the
problem no longer exists? Whatever way we can re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119600
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108958
--- Comment #2 from Segher Boessenkool ---
(A good patch is like: we currently generate X (because of Y Z A), but we could
do B C D instead, and generate E).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108958
--- Comment #1 from Segher Boessenkool ---
Sure. What do we need to improve on this? Please propose a patch :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97786
--- Comment #9 from Segher Boessenkool ---
(Erm,tdc *is* 3.0, but setbc is 3.1, I can never ever get this right it seems!
But
setb is 3.0).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97786
--- Comment #8 from Segher Boessenkool ---
(In reply to Surya Kumari Jangala from comment #7)
> Hi Segher,
>
> Thanks for the pointers!
> We can optimize the code further and remove the branch completely.
>
> For P10:
>
> xststdcdp 0,1,48
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113939
--- Comment #11 from Segher Boessenkool ---
(In reply to John Paul Adrian Glaubitz from comment #7)
> (In reply to John Paul Adrian Glaubitz from comment #6)
> > I suggest we switch m68k to LRA, so we can close this bug report. Plus file
> > bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117818
--- Comment #8 from Segher Boessenkool ---
We still support powerpc64-* just fine. And powerpc-linux (the 32-bit target)
is
tested just fine as well, and the community does support it. No one cares
_too_
much about it anymore, but why let it d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97786
--- Comment #6 from Segher Boessenkool ---
Hi Surya!
Hrm yes, xststdcdp _does_ return a sign bit as well. Do we currently say
that in RTL as well?
Unfortunately we cannot just follow an xststdcdp by a setb, setb tests bit 1,
but
the tdp sets b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117207
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118541
--- Comment #8 from Segher Boessenkool ---
(The traditional FP comparisons we do use, i.e. fcmpu. We never used fcmpo,
because it is problematic, it needs access to information that in not in the
RTL at the point of the comparison, that informa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118541
--- Comment #7 from Segher Boessenkool ---
isgreater is not supposed to set floating point exception flags at all. So
whether the comparison resulted in unordered (i.e., one of the arguments was a
NaN) or not, isgreater should not set VXVC in p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119468
--- Comment #3 from Segher Boessenkool ---
prtyd and popcntb are executed similarly on all hardware: same execution pipes.
The extsw we currently generate is not needed at all, a very common and
well-known issue, generic as well (not really rs60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119468
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119629
--- Comment #5 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #2)
> (In reply to Peter Bergner from comment #1)
> > > but the conditions that enable the expansion of
> > > __builtin_scalar_byte_in_set
> > > are those of [po
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119629
--- Comment #6 from Segher Boessenkool ---
(In reply to Segher Boessenkool from comment #5)
> This needs splitting up in parts. Maybe then some parts can be correct,
> even!
Of course that requires explanatory comments in the patch submission
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119629
--- Comment #4 from Segher Boessenkool ---
Hi Alex,
(In reply to Alexandre Oliva from comment #0)
> This raises a number of problems:
>
> - instructions and expanders for these builtins don't have their conditions
> tested, so they must necess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119629
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398
--- Comment #26 from Segher Boessenkool ---
(In reply to Richard Sandiford from comment #23)
> Yeah, I'd wondered about limiting it an all cases too. Definitely seems
> worth trying. But given that we're in stage 4, maybe it would make sense t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398
--- Comment #19 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #16)
> Tamar's explanation why #c0 gcc 14 code is better than gcc 15:
> "the mov is a zero latency instruction. sxtw, asr and sbfx themselves are
> aliases to th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398
--- Comment #22 from Segher Boessenkool ---
(In reply to Richard Sandiford from comment #18)
> I'd been reluctant to get involved in this for fear of creating friction or
> being a cook too many,
No, your input is much appreciated!
> but: the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398
--- Comment #14 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #8)
> Because as this PR shows, those 2->2 insn merges with no change on i2 can
> make a lot of sense and allow combination on the second and following user
> of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118638
--- Comment #24 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #21)
> I certainly plan to backport it to those releases as well. But it is just
> latent there...
Where "latent" means "our testcases do not show problems" th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116028
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118663
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #5 from Segher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118556
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115825
--- Comment #27 from Segher Boessenkool ---
> This is a GIMPLE pass which has no idea what the backend will expand
> __builtin_darn() to.
So you are saying >90% of builtins now need to say they are pure and const
(which
makes totally no sense f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115825
--- Comment #25 from Segher Boessenkool ---
No, darn does have a side effect: it returns a random number in the destination
reg (_deliver_ _a_ _r_andom _n_umber). It does not touch memory at all.
There are no call insns at all either, of cours
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115825
--- Comment #24 from Segher Boessenkool ---
> > Okay, two insns, there's an add insn as well. But *not* unrolling this
> > likely
> > makes bigger code already!
>
> This is because
>
> /* If there is call on a hot path through the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115825
--- Comment #20 from Segher Boessenkool ---
gcc.target/powerpc/darn-3.c
I'll quote the whole thing:
===
static int darn32(void) { return __builtin_darn_32(); }
int four(void)
{
int sum = 0;
int i;
for (i = 0; i < 4; i+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115825
--- Comment #18 from Segher Boessenkool ---
So, you are saying the change made us realise some insns can never be optimised
away? It should be obvious in much more fundamental ways that these insns can
never be optimised away (simply because t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115825
--- Comment #16 from Segher Boessenkool ---
Trivial stuff is no longer unrolled at all after this change. It does not
matter
*at all* whether an insn has a side effect or not, for whether code with such
an
insn should be unrolled or not. Any h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115825
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117964
--- Comment #10 from Segher Boessenkool ---
Wrt more barriers than needed... This is always less than the amount of other
extra RTL, so it is kinda harmless. But if we care, we should do prevent this
in emit_barrier itself, so that it is solve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117964
--- Comment #9 from Segher Boessenkool ---
(In reply to rguent...@suse.de from comment #8)
> > maybe_duplicate_computed_goto should never ever decide to know better than
> > its caller. That way insanity lies.
>
> "maybe_" suggests it's not al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117964
--- Comment #7 from Segher Boessenkool ---
When maybe_duplicate_computed_goto is asked to duplicate a block with 9189
successors, it damn well should! If that is a bad idea for the case at hand,
just do not call maybe_duplicate_computed_goto on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117718
--- Comment #4 from Segher Boessenkool ---
The address for lxv and lxvx can be anything. The *offset* in the address for
lxv has to be a multiple of sixteen. This isn't any different from DS-mode
(well,
multiple of 4 there), and we have DQ-mod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117629
--- Comment #2 from Segher Boessenkool ---
"Since C23 "bool" is a keyword designating a type", something like that?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29838
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29838
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113933
--- Comment #25 from Segher Boessenkool ---
(In reply to John David Anglin from comment #24)
> There are a couple of issues. The pa backend only supports memory
> accesses that load to a register or store from a register. LRA was
> creating in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113933
--- Comment #23 from Segher Boessenkool ---
(In reply to John David Anglin from comment #21)
> This bug was fixed by changing PA_HARD_REGNO_MODE_OK. On the 32-bit
> target we no longer allow TI and OI mode in the hard registers. I only
> allow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19779
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117007
--- Comment #7 from Segher Boessenkool ---
It is always more and slower code. Yes.
1 - 100 of 1327 matches
Mail list logo
