https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121095
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comm
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
--- Comm
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
--- Comm
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
--- Comm
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
--- Comm
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
--- Comm
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
--- Comm
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
--- Comm
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
--- Comm
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
--- Comme
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
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117007
--- Comment #7 from Segher Boessenkool ---
It is always more and slower code. Yes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117291
--- Comment #14 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #13)
asm-generic/ is a kernel thing, not relevant at all. bits/resource.h is used
by , the header you should use.
That is used by "system.h" under a
#ifdef H
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117291
--- Comment #9 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #2)
> I am not sure if there is not much to be done.
> The front-end is recusive here:
So you found the bug already. Now fix it :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117291
--- Comment #12 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #10)
> void
> stack_limit_increase (unsigned long pref ATTRIBUTE_UNUSED)
> {
> #if defined(HAVE_SETRLIMIT) && defined(HAVE_GETRLIMIT) \
> && defined(RLIMIT_S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117291
--- Comment #11 from Segher Boessenkool ---
(In reply to Richard Biener from comment #5)
> I agree it's difficult to solve. GCC tries to up the stack limit to
> unlimited, why isn't this working for you? Maybe we should remember the
> failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117251
--- Comment #12 from Segher Boessenkool ---
(In reply to Richard Biener from comment #7)
> Is it possible to define a fused and/xor+xor alternative that's split after
> RA, slightly pessimized to prefer the altivec alternative, to allow the XXL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116780
--- Comment #17 from Segher Boessenkool ---
(In reply to Georg-Johann Lay from comment #16)
> (In reply to Segher Boessenkool from comment #15)
> > It makes sense never, not on any target, not with LRA nor without.
> Though there are test cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117238
--- Comment #2 from Segher Boessenkool ---
So the only way you can handle anything OImode is via a function call, with it
pointed to by a function argument? Should you support OImode at all then
(you can do that with a pointer to void argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115242
--- Comment #7 from Segher Boessenkool ---
(In reply to Florian Weimer from comment #6)
> The issue on POWER is different because the ABI was enhanced retroactively,
> supposedly in a transparent way.
The PowerPC AltiVec ABI is separate from th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116780
--- Comment #15 from Segher Boessenkool ---
(In reply to Georg-Johann Lay from comment #14)
> (In reply to Segher Boessenkool from comment #13)
> > But this testcase is in gcc.target/ anyway, right?
> That's just a copy of gcc.dg/torture/pr6408
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116780
--- Comment #13 from Segher Boessenkool ---
(In reply to Georg-Johann Lay from comment #9)
> (In reply to Segher Boessenkool from comment #8)
> > That is invalid C code, of course (an out of bounds access).
> What about the other test case
> htt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116780
--- Comment #12 from Segher Boessenkool ---
(In reply to denisc from comment #11)
> (In reply to Segher Boessenkool from comment #8)
> > (In reply to denisc from comment #2)
> > > Comment on attachment 59393 [details]
> > > Simplified testcase
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116780
--- Comment #8 from Segher Boessenkool ---
(In reply to denisc from comment #2)
> Comment on attachment 59393 [details]
> Simplified testcase
>
> void
> f ()
> {
> volatile char c[0];
> c[0] = 0;
> }
That is invalid C code, of course (an o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113933
--- Comment #20 from Segher Boessenkool ---
(In reply to John David Anglin from comment #19)
> (In reply to Segher Boessenkool from comment #17)
> > (In reply to John David Anglin from comment #15)
> > > While bootstrap is okay, there are some n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113933
--- Comment #17 from Segher Boessenkool ---
(In reply to John David Anglin from comment #15)
> While bootstrap is okay, there are some new test fails:
>
> AIL: gcc.c-torture/compile/pr92618.c -O1 (internal compiler error:
> maximum number of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113933
--- Comment #16 from Segher Boessenkool ---
(In reply to GCC Commits from comment #13)
> The master branch has been updated by John David Anglin
> :
>
> https://gcc.gnu.org/g:44a81aaf73f795e6992cbfb98ec48480e5ca94ec
>
> commit r15-4483-g44a81a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116550
--- Comment #13 from Segher Boessenkool ---
Yeah :-) So post an actual patch, to gcc-patches@? :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113954
--- Comment #9 from Segher Boessenkool ---
Add a RejectNegative perhaps, because -mno-lra no longer does what the user
expects? And/or WarnRemoved? And the
;; lra is still unproven for ARC, so allow to fall back to reload with
-mno-lra.
line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113953
--- Comment #4 from Segher Boessenkool ---
Heh, I thought you forgot the manual, but -mlra apparently never was mentioned
in there anyway :-)
Thanks for the help pulling GCC kicking and streaming into the 21st century!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113954
--- Comment #4 from Segher Boessenkool ---
Yup. What I meant is, if the port still sees some use in their -mlra, there is
no pressure from us to have them remove it, we'll just make it not do anything
anymore :-) Maybe they still see some prob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113954
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113933
--- Comment #2 from Segher Boessenkool ---
(In reply to dave.anglin from comment #1)
> On 2024-02-15 2:01 p.m., sjames at gcc dot gnu.org wrote:
> > People are getting eager to require LRA. Please port the PA target to LRA
> > (see
> > PR113932
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114531
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113174
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comm
1 - 100 of 940 matches
Mail list logo
