releases anymore, see https://gcc.gnu.org/gcc-12/
for example). Oh, and send email when you have backported something :-)
Cheers,
Segher
atic void warn_about_jump(enum jump_type jtype, location_t goto_loc,
> > + location_t label_loc, tree decl, tree label)
>
> This needs fixing to GNU formatting (static void on own line,
So that you can find always find all function defitions by searching for
^some_name. Very handy :-)
Segher
ave only partial
data. If it turns out you balanced not so super well, you can always
correct that later ;-)
Segher
cost is not
> accounted for.
Various older (generic) things do not use insn_cost, but instead use
rtx_cost. A very bad plan! This function estimates how expensive some
RTX operation would be without knowing what insns will be created for
it. I have modified various passes over the years to create some
temporary RTL just to calculate the actual cost for using it. If you
find any more that needs attention please let me know :-)
Segher
Hi!
On Wed, Sep 03, 2025 at 07:50:32PM +0530, Avinash Jayakar wrote:
> On Fri, 2025-08-29 at 13:14 -0500, Segher Boessenkool wrote:
> > Please don't do this. Just do a define_insn that recognises a shift
> > by
> > const int 1, and emits an vaddudm machine insn fo
rred between processor caches.
Hiding this in an unrelated parameter is obfuscation. I'd rather not.
(EH=1 is a variant of the larx insn, the LL in LL/SC. This patch is to
make a __atomic_compare_exchange_local which has the same semantics as
__atomic_compare_exchange, just perhaps different performance).
Segher
On Mon, Sep 01, 2025 at 09:54:41PM +0530, Ayappan wrote:
> Yes, that would be really helpful.
What release branches do you want this backported to, then? I cannot
(always) read minds :-)
Segher
> On Mon, Sep 1, 2025 at 9:31 PM Segher Boessenkool <[1]
> seg...@kernel.crashin
found
> compilation terminated.
>
> I am not sure whether we really need a testcase for this.
I would think the generic -fstack-protector testcases would already pick
this up. But apparently there doesn't exist any testcase for it! So
this failure mode wasn't detected either. Oh well.
Not something I'll ask you to improve then!
Segher
On Tue, Sep 02, 2025 at 12:12:43PM +0200, Jakub Jelinek wrote:
> On Tue, Sep 02, 2025 at 05:01:37AM -0500, Segher Boessenkool wrote:
> > On Tue, Sep 02, 2025 at 07:56:58AM +0200, Jakub Jelinek wrote:
> > > On Tue, Sep 02, 2025 at 09:32:15AM +0530, Surya Kumari Jangala w
have a testcase for it? _Do_ we have a testcase for it?
Segher
p.s. Please do not top-post.
> On Mon, Sep 1, 2025 at 10:11 PM Segher Boessenkool <[1]
> seg...@kernel.crashing.org> wrote:
>
> On Mon, Sep 01, 2025 at 09:54:41PM +0530, Ayappan wrote:
> > Yes
Excellent. Thank you. Okay for trunk, as David said.
Do you want backports for this?
Segher
On Mon, Sep 01, 2025 at 07:22:17PM +0530, Ayappan Perumal wrote:
> From: Ayappan Perumal
>
> ---
> stack-protector is not supported in GCC on AIX. This patch is to fail the
> compila
igned long long *a)
> +{
> + a[0] += a[0];
> + a[1] += a[1];
> +}
> +
> +vector ull add_vector(vector ull a) {
> + return a + a;
> +}
> +
> +void mult2(unsigned long long *a)
> +{
> + a[0] *= 2;
> + a[1] *= 2;
> +}
> +
> +vector ull mult2_vector(vector ull a)
> +{
> + return a*2;
> +}
> +
> +/* { dg-final { scan-assembler-times {\mvaddudm?\M} 6 } } */
Why the "?" in "m?". There does not exist any insn without a "m" here!
Maybe you can make the testcase work for b, h, w as well?
Segher
or not enabled on AIX}"
"not enabled" isn't very useful wording. "not supported" maybe?
Segher
0a02789f1), shift counts
> were only checked for nonzero but not for being within valid bounds.
> This patch tightens those conditions by enforcing that shift counts are
> greater than zero and less than HOST_BITS_PER_WIDE_INT."
>
> With the above change, the patch looks good to m
ms to want VSX at all anyway?
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr107757-2.c
> @@ -0,0 +1,13 @@
> +/* { dg-do compile } */
> +/* { dg-options "-mdejagnu-cpu=power8 -O2" } */
> +/* { dg-require-effective-target powerpc_vsx } */
Same here.
Segher
bool
> > later on by users or redefines to something else will be still diagnosed.
>
> Could we suppress warnings for all builtin_define instead of specifically
> for these names?
Maybe that is a good idea. OTOH maybe it is a good idea if people
reconsider if we still want this anyway!
Segher
= NODE_WARN;
twice? It works correctly way more often (what you have does not always
restore the original!)
And a comment would help, of course.
Why put this inside an "if" anyway, can't you disable the warning even
if it won't ever fire anyway?
> + if (warn_keyword_macro && !c_dialect_cxx ())
The warn_ flag at least seems superfluous. You might want a comment
that this is what this is for though :-)
Segher
ST_BITS_PER_WIDE_INT - shift));
So there were good examples already! Why change this though? Ah, the
rightmost part can shift by a register worth of bits, which isn't valid
C, although it would be perfectly fine machine code for us. Yeah ok.
Okay for trunk with those things fixed. Thank you!
Segher
uble-128} configuration option,
(Is this something that changed over the years? That would explain some
things).
Segher
at I prepare separate
> backport
> patches for these branches, or will the backports be handled by maintainers?
Like I said above, all backports are approved. Please send emails here
(i.e. gcc-patches@) when you do one, maybe with the patch if it needs
modification, etc.
Segher
he master branch after the GCC 14 release.
So, how do you resolve it in this backport, simply leaving out those
hunks?
If so: okay for 14. You don't want to backport further, right? More
stuff becomes missing :-)
Thanks!
Segher
n the path
we would care about?": nope, it just says soft-fp, and that will be
clear from context anyway.
Okay for trunk (with the commit message improved). Thank you!
Do you want backports? Okay for those as well (if they are wanted).
Segher
; +;; when the user changes the default cpu via #pragma GCC target("cpu=future")
> +;; and then resets it later.
What does that mean? It hints at a bug elsewhere, but not more than
hints unfortunately.
Segher
r
> address.
> (process_address): Constrain the iteration number.
Is that just for extra robustness, or did you see any unconstrained
iteration even after the fixes?
When it no longer hangs, how will we find out there is a problem in the
future, btw? Hanging has its benefits, too :-)
Segher
t; registers moves before reload. I.e.
>
> register int r4 asm("r4");
> register int r5 asm("r5");
> r4 += r5;
As Vlad says, yes. We already try to do that!
Hard regs should only be allowed in simple register moves, before
reload. And it should be pretty easy to write RTL checking for that!
RTL checking is often hard to do, there is not enough context available
often, but here it should work fine :-) (Or, maybe we can do some much
stronger kind of RTL checking, run from emit_insn perhaps!)
Segher
l call replacement, altering expected test
> > behavior.
> > + Disabling ICF ensures correct execution of the test. */
>
> Can you please mention the PR number in the comment above?
> Also please reword as follows:
> "This results in the compiler replacing insert_di_0_v2 with a tail call to
> insert_di_0, altering expected test behavior."
Yes please.
> With the above changes, the patch is fine. However, I cannot approve the
> patch.
But I can :-) Yes, okay with such changes. Thanks!
Segher
d to the maintainers, so we didn't see it.
Please repost, cc:ing us. Also show examples of old and new output!
Segher
te.crashing.org/
Did you not get that email?
Segher
t could optimise this whole stuff out (that's what in rs6000 the
frame_pointer_needed_indeed thing is for:
frame_pointer_needed_indeed
= frame_pointer_needed
&& df_regs_ever_live_p (HARD_FRAME_POINTER_REGNUM);
)
Segher
Hi!
On Sat, Jul 05, 2025 at 11:10:05PM +0800, Xi Ruoyao wrote:
> Possibly this is https://gcc.gnu.org/PR101882. Specifically comment 5
> from Segher:
>
> "The LRA change is correct AFAICS. But combine makes a change that
> violates the earlyclobber... I need to do somet
code and conducted a comparison test, and found
> that the binary unchanged. Unfortunately, I didn't identify any opportunities
> for optimization, I think it's better to keep them. Not sure if there might
> be any corner case issues.
For most archs and ABIs it is very beneficial to use
-fomit-frame-pointer, I thought that was true for x86 even? There is
a special reg for it, sure, but you can use that reg as a general reg as
well, and that is way useful on an arch with so few registers :-)
Segher
o yeah, then things should just work
like that :-)
Good luck, have fun, don't do cargo-cult,
Segher
On Wed, Jul 02, 2025 at 11:06:38AM +0200, Jakub Jelinek wrote:
> On Tue, Jul 01, 2025 at 02:50:40PM -0500, Segher Boessenkool wrote:
> > No tests become good tests without effort. And tests that are not good
> > tests require constant maintenance!
>
> Here are two patches,
Hi!
On Tue, Jul 01, 2025 at 08:39:26PM +0200, Jakub Jelinek wrote:
> On Tue, Jul 01, 2025 at 12:04:04PM -0500, Segher Boessenkool wrote:
> > On Mon, Feb 17, 2025 at 02:28:50PM +, Alex Coplan wrote:
> > > After the recent alignment peeling enhancements in the vectorize
hey were not designed for :-)
> The following patch fixes that by using arrays of 2 elements, so that
> the overwriting of 1 byte happens to the part of the same variable.
>
> Tested on powerpc64le-linux both without and with -fstack-protector-strong,
> ok for trunk and 15.2/14.4?
lled "vsx-vectorize-*". Even if it is just to some part of the code;
if you want to only test some part of code, put it in a different file.
If the testcases are less than stellar (and pretty much anything using
scan-assembler-times is!), fix *that*?
Segher
ed)
> +bitmap_clear_bit (components, HARD_FRAME_POINTER_REGNUM);
What is that about? Isn't that one of the bigger possible wins?
Anyway, nice to see SWS finally used for x86 as well!
Segher
(and some actually do
return something else!)
"tuning_p10", or "tuning_is_for_p10", or whatever. A predicate by
definition should contain a verb (and a subject)!
Segher
runc_int_for_mode (val - low, mode);
> + /* Avoid signed overflow by computing difference in unsigned domain. */
> + unsigned HOST_WIDE_INT urest = (unsigned HOST_WIDE_INT)val - (unsigned
> HOST_WIDE_INT)low;
You never need to cast both arms of a binary operator. C will promote
one side automatically.
> + HOST_WIDE_INT rest = trunc_int_for_mode (urest, mode);
>
>operands[4] = GEN_INT (low);
>if (mode == SImode || satisfies_constraint_L (GEN_INT (rest)))
So, it is probably best if you use somnething like
unsigned HOST_WIDE_INT val = UINTVAL (operands[2]);
at the start, and no other changes are needed?
Segher
ing at actual
differences for example, or just seeing if rs6000_cpu changes.
> > +mfuture
> > +Target Undocumented Mask(FUTURE) Var(rs6000_isa_flags) WarnRemoved
It should obviously not be "WarnRemoved". It did not exist in the past,
so how can it be removed now?
Segher
gt;
> nit: "influencing"
Speling fixes are never a nit! Attention to details is important.
> Also, in rs6000.opt, mblock-ops-vector-pair is marked as Undocumented. Should
> we
> change this?
Probably yes. If the option is worth being user-selectable at all, we
should document it.
Segher
On Mon, Jun 16, 2025 at 08:34:23PM +0200, Martin Uecker wrote:
> Am Montag, dem 16.06.2025 um 12:56 -0500 schrieb Segher Boessenkool:
> > So, now the warning no longer does what the name says, or what its
> > documentation says. Please update the documentation at least!
>
&g
andled by the compiler.
Completly utterly foolish of course, to have compilation ternminated
abnormally without output whenever the compiler saw something that
looks suspicious, and as any good heuristic thing it wanted to tell you
about it, but heh, the user *wanted* pain, that is why he/she used
-Werror!)
Anyway, please update the documentation for the warning if you change
what the warning does :-)
Segher
, the sole maintainer of this (*), heavily object.
Please follow process. Post this to gcc-patches@, as well as to the
maintainers of the affected areas of the compiler (you can find those in
the MAINTAINERS file). And then patiently wait.
Segher
(*) Yes, this is a problem. And yes, workin
something (not define_insn_and_split, I mean pure splitters here;
sometimes you want to allow combine to create something complex).
Segher
Hi!
On Tue, Apr 01, 2025 at 09:35:53PM -0600, Jeff Law wrote:
> Segher -- there's a combine question near the end...
> So this is a nasty little problem and touches on a deeper issue.
>
> The core problem is that combine doesn't know anything about
> constraints. It
Hi!
On Mon, Jun 02, 2025 at 08:37:19PM +0200, Martin Uecker wrote:
> Am Montag, dem 02.06.2025 um 13:19 -0500 schrieb Segher Boessenkool:
> > On Mon, Jun 02, 2025 at 05:50:08PM +0200, Martin Uecker wrote:
> > > According to the discussion in the bugzilla there seems to be
>
noying, but the
requirements for the two are essentially the same, just the limit
"this is *too* annoying" shifted a bit.
Why do this in -Wc++-compat at all? You don't say. Well, you say that
is a bugfix, so it should be a separate (and trivial) patch.
Segher
On Thu, May 29, 2025 at 03:07:34PM -0500, Peter Bergner wrote:
> On 5/29/25 5:35 AM, Segher Boessenkool wrote:
> >
> > Add yourself to suthors as well?
>
> Agreed. Just add your name/email address directly under mine, like so:
>
> 2025-05-29 Peter Bergner
>
manually disabled things,
but that is not something we can accommodate)
> +/* Test whether the ISA 3.0 amo (atomic memory operations) functions perform
> as
> + expected. */
That sounds like this is a run test, but it isn't.
> diff --git a/gcc/testsuite/gcc.target/powerpc/amo4.c
> b/gcc/testsuite/gcc.target/powerpc/amo4.c
> new file mode 100644
> index 000..fce85c8dc52
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/amo4.c
> @@ -0,0 +1,92 @@
> +/* { dg-do run { target { lp64 && p9vector_hw } } } */
Please use a more appropriate selector?
> +/* { dg-options "-mdejagnu-cpu=power9 -O2" } */
> +/* { dg-require-effective-target powerpc_vsx } */
And get rid of this last one please.
Thanks,
Segher
ncludes as well :-)
Committing to trunk.
Segher
---
gcc/config/rs6000/rs6000.cc | 1 -
1 file changed, 1 deletion(-)
diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index 12dbde2bc630..9b01d3e29167 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
ill trap if one of the
> + arguments is a signalling NaN. */
> #define REVERSIBLE_CC_MODE(MODE) 1
Those insns *are* ordered comparison insns (in the Power ISA sense), and
they are unwanted for all the same reasons as we do not want the simpler
similar insns.
So please make a patch that instead of unnecessarily and wrongly
changing the fundamentals of how we handle FP comparisons in our
backend, just fixes the one pattern where we already messed up?
Segher
Hi!
On Wed, May 21, 2025 at 06:27:38AM +0200, Richard Biener wrote:
> On Wed, May 21, 2025 at 12:30 AM Segher Boessenkool
> wrote:
> >
> > On Mon, May 12, 2025 at 06:35:15PM -0400, Michael Meissner wrote:
> > > On Mon, May 12, 2025 at 01:24:04PM +0530, Surya Kumari Jan
is being thrown due to qNaNs.
>
> But -Ofast says not to worry about Nans (signalling or otherwise). But if
> Segher desires, I remove the test for Ofast.
That is not what -Ofast means at all. It means "-O3, but also
-ffast-math, and some other not recommendable things". Its nam
dentical, except for these two attributes. Which will automatically be
set to the correct values if you use simpler code, btw.
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr108958.c
> @@ -0,0 +1,27 @@
> +/* { dg-do compile } */
That's the default. You can leave this out.
So please make this work in way more cases, simpler code with better
results!
Segher
is being thrown due to qNaNs.
>
> But -Ofast says not to worry about Nans (signalling or otherwise). But if
> Segher desires, I remove the test for Ofast.
That is not what either of the five constituent options of -ffast-math
means. Any code should use (some of) those five options, almost
ct like that
> is still fine, you just get the pointer in a roundabout way. It would be
> different if the machine actually does a "keep following pointers until the
> 'this is a pointer' flag is false" mode, which some old machines do.
How should that even be expressed in GCC? Heh.
Segher
etter from an overall project maintenance
> standpoint, though it may not be the best solution for the targets which
> support double-indirect addressing modes.
It is pretty hard to work with double-indirect things, often have to
make sure the two memory accesses are not to the same address, etc.
Segher
up repeatedly - I can find the last
It was agreed that I could delete old reload completely in GCC 16.
I should have something ready in a week or so (almost everything needs
to be redone because of unrelated changes, again).
Segher
> proposal for GCC 13 and somehow remember we agreed to fina
would have been
really good if ports that have such difficulties had tried to use LRA
before! But here we are.
Segher
ever heve been a user option at all, it
either is okay or it isn't.
Maybe that thing should not be user-selectable at all.
("Maybe", like I guarantee I will okay a patch doing jsut that!)
(Not "would", but "will", thanks)
So yeah, tha patch is okay. Thank you!
Segher
On Tue, Mar 25, 2025 at 07:00:34PM -0500, Peter Bergner wrote:
> On 3/25/25 5:17 PM, Segher Boessenkool wrote:
> > On Tue, Mar 25, 2025 at 03:33:59PM -0500, Peter Bergner wrote:
> >> Segher, any reason you can give on why we shouldn't go the easy route to
> >>
ope :-)
> As shown here, they're pretty fragile to changes in the compiler.
Pretty much all scan-assembler-times tests are very suspect, not to say
plain wrong.
> That said, I'm not sure it's really worth splitting this older Power7
> test case up, so I guess adding -fno-ipa
; +/* { dg-options "-mdejagnu-cpu=power9 -O2" } */
> /* { dg-require-effective-target powerpc_vsx } */
This test is not typically needed at all, but yeah, it is possible some
tester decides to sabotage himself and disables VSX on new systems. The
extra check isn't really harmful anyway (it just might suggest to others
that it is required).
Okay for trunk and any backports you want. Thanks!
Segher
du)
>
> This doesn't make any sense to me. This is a new file with new
> code not copied form anywhere else, so why the Contributed by
> Richard Kenner line? Cut/paste error?
If a file is largely copied from some other file, it makes sense to keep
attribution. If not, not.
Same for that "1991-2024" btw. Dates should be factual.
Segher
On Tue, Nov 05, 2024 at 04:26:13PM -0600, Peter Bergner wrote:
> On 11/5/24 1:16 PM, Segher Boessenkool wrote:
> > Would it not have been better to not use -O0 at all here? -O0 is
> > not realistic if you expect any reasonable optimisation!
>
> That's what I first att
immune from any future
> changes in jump table generation behavior.
Please don't do such things.
Would it not have been better to not use -O0 at all here? -O0 is
not realistic if you expect any reasonable optimisation!
Segher
; and
Thank you! Okay for trunk; also okay for all backports (which backports
do you want?)
Segher
scan-assembler "stq \[123\]?\[02468\]" } } */
Please use {} quoting, and no backslashes. Also use \m and \M.
Or something like
scan-assembler { \mstq .*[02468], }
(you do not have to match the things you don't care about, and you only
need to look at the last digit to see if a number is even).
The patch looks good otherwise, but please fix these things and repost.
In a new thread :-)
Thanks,
Segher
On Wed, Sep 18, 2024 at 01:51:21AM -0400, Michael Meissner wrote:
> On Tue, Sep 17, 2024 at 02:33:09AM -0500, Segher Boessenkool wrote:
> > Hi!
> >
> > On Mon, Sep 16, 2024 at 11:40:45PM -0400, Michael Meissner wrote:
> > > With this patch, GCC now realizes that the
> +++ b/gcc/testsuite/gcc.target/powerpc/pr89213.c
> @@ -0,0 +1,106 @@
> +/* { dg-do compile { target { lp64 } } } */
Why only on 64-bit systems? Does it fail with -m32? Why / how?
With that, okay for trunk. Thanks!
Segher
or you don't care about that target, or just
cargo-cult, is wrong, and encourages more wrongness.
Segher
Also
okay with just the MODE_UNIT_SIZE (mode) == 16 thing, after you tested
that of course :-)
Thanks!
Segher
On Mon, Aug 12, 2024 at 10:59:01AM -0500, Peter Bergner wrote:
> Ping * 3. [Message-ID: <1e003d78-3b2e-4263-830a-7c00a3e9d...@linux.ibm.com>]
>
> Segher, this resolves the issues you mentioned in your review.
> This was on the top of your patch review queue before, so may
bit
even.
This is handy for people reading the ISA, like most of us: the
instruction descriptions talk about MSR[VEC] and MSR[VSX] all over the
place. And people will less easily understand this as being about just
the old insns!
Segher
Hi!
On Mon, Aug 12, 2024 at 10:42:48AM +0800, Kewen.Lin wrote:
> on 2024/8/10 05:43, Segher Boessenkool wrote:
> IIUC, we want to split TARGET_P[89]_VECTOR into TARGET_P[89]_ALTIVEC and
> TARGET_P[89]_VSX (or just TARGET_POWER[89] && TARGET_VSX or TARGET_ALTIVEC)
> according
well-formed, but it doesn't make sense, indeed :-) Named patterns
have requirements on their arguments, but everything else is whatever
the target wants :-)
Hopefully *no* passes will consider this a pure input, we have that "+"
after all! It would be better if it wasn't there, sure.
Segher
On Fri, Aug 09, 2024 at 03:50:50PM -0500, Peter Bergner wrote:
> On 8/9/24 12:54 PM, Segher Boessenkool wrote:
> >> --- a/gcc/config/rs6000/altivec.md
> >> +++ b/gcc/config/rs6000/altivec.md
> >> @@ -623,7 +623,7 @@ (define_insn "altivec_eqv1ti&q
ot a VSX insn (for which MSR[VSX]=1 is needed).
We test TARGET_ALTIVEC for that, not TARGET_VSX.
In general, we want to get rid of TARGET_Pxxx_VECTOR, not introduce new
stuff like it!
Segher
Hi!
On Wed, Jul 24, 2024 at 11:38:11AM -0700, Carl Love wrote:
> On 7/24/24 10:03 AM, Segher Boessenkool wrote:
> >So much manual stuff needed, sigh.
> >
> >On Fri, Jul 19, 2024 at 01:04:12PM -0700, Carl Love wrote:
> >>gcc/ChangeLog:
> >> * c
On Wed, Jul 24, 2024 at 12:16:33PM -0500, Peter Bergner wrote:
>
> On 7/24/24 12:03 PM, Segher Boessenkool wrote:
> >> +/* { dg-options "-mdejagnu-cpu=power10 -save-temps" } */
> >
> > Why the -save-temps? Always document it if you want that for something,
On Wed, Jul 24, 2024 at 12:12:05PM -0500, Peter Bergner wrote:
> On 7/24/24 12:06 PM, Segher Boessenkool wrote:
> I thought we always wanted the predicate to match the constraint being used?
Predicates and constraints have different purposes, and are used at
different times (typ
R))]
> >"TARGET_POWER10"
>
> I know the old code used the register_operand predicate for the vector
> operands, but those really should be changed to altivec_register_operand.
register_operand is just fine usually. The "v" constraint already makes
sure things end up in a VMX (a lower VSX) register, the predicate
doesn't help here. register_operand is shorter (and thus, preferred),
and also more likely correct if the code changes later :-)
Segher
run, one for compiling only. It's
a bit simpler and cleaner.
> +/* { dg-options "-mdejagnu-cpu=power10 -save-temps" } */
Why the -save-temps? Always document it if you want that for something,
but never put it in the testcase if not. A leftover from development?
Okay for trunk, thank you! Well Peter had some comments too, modulo
those I guess, I'll read them now ;-)
Segher
On Thu, Jul 18, 2024 at 09:53:05AM -0500, Peter Bergner wrote:
> On 7/18/24 8:23 AM, Segher Boessenkool wrote:
> > Everything in gcc.target/powerpc is only run for target powerpc*-*-*
> > anyway, so make this just
> >
> > /* { dg-do compile } */
> >
> >
-* } } */
> +/* Require VSX and Linux to eliminate systems where you can't do
> + __attribute__((__target_clones__(...))). */
All the same things here, mutatis mutandis.
Segher
R10 and POWER11 processors.
The official names are Power10 and Power11 (only the P a capital).
Okay for trunk with that fixed. Also okay for backport to 14. (After
the usual burn-in period of course). Thanks!
Segher
{powerpc}, @samp{powerpc64},
> -@samp{powerpc64le}, @samp{rs64}, and @samp{native}.
> +@samp{power9}, @samp{power10}, @samp{power11},
> +@samp{powerpc}, @samp{powerpc64}, @samp{powerpc64le},
> +@samp{rs64}, and @samp{native}.
Hint: you do not need to layout TeXinfo source code. TeX itself takes
care of that much better than you can. It is fine to keep some short
lines, this will be rewrapped in output anyway.
Okay for trunk with those changes. Also fine for backport to 14.
Thank you!
Segher
for -mcpu=power11 support.
>
> In order to use -mcpu=power11, you will need to use a new enough binutils that
> supports the .machine power11 option.
This is a general thing: we always assume you have a binutils at least
as new as your GCC.
Segher
al RTL name for it. That is fine, that is
what we do in many other places already. It is clear what is meant no
matter what :-)
Segher
see an existing optab for andn.
For most RTL stuff we can deal with it just fine using existing
define_insn etc. stuff. I have no idea if any of this is harder in
Gimple?
> So OK from my side in case there are no negative comments or
> bikeshedding on the name. I can't approve the rs6000 changes
> though.
But I can :-) I'll reply to just that. Thanks for handling this!
Segher
I didn't see this before. Sigh.
On Tue, Jan 02, 2024 at 09:47:11AM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Tue, Oct 24, 2023 at 07:49:10PM +0100, Richard Sandiford wrote:
> >> This patch adds a combine pass that runs late in the pipeline.
>
works
best for you :-)
> Bootstrapped and regtested on powerpc64-linux-gnu P8/P9
> and powerpc64le-linux-gnu P9 and P10.
That also tested -m32 (on BE at least), right?
Okay for trunk, thanks for dealing with this!
Segher
On Tue, Jun 18, 2024 at 12:53:09PM -0500, Peter Bergner wrote:
> On 6/18/24 8:20 AM, Segher Boessenkool wrote:
> > On Mon, Jun 17, 2024 at 08:54:46PM -0500, Peter Bergner wrote:
> >> So we should be able to shrink-wrap in the presence of the ROP protection.
> [snip]
> &
the widen
things, don't try to do the compilers job of specialising stuff, it
only makes things much less readable, and causes more mistakes. Just do
like what was there before, essentially.
Segher
On Mon, Jun 17, 2024 at 08:54:46PM -0500, Peter Bergner wrote:
> On 6/17/24 7:57 PM, Segher Boessenkool wrote:
> > On Mon, Jun 17, 2024 at 06:49:18PM -0500, Peter Bergner wrote:
> >> On 6/17/24 6:11 PM, Segher Boessenkool wrote:
> >> Yeah, I didn't write that, I
Hi!
On Mon, Jun 17, 2024 at 06:49:18PM -0500, Peter Bergner wrote:
> On 6/17/24 6:11 PM, Segher Boessenkool wrote:
> >> - /* If we are inserting ROP-protect instructions, disable shrink wrap.
> >> */
> >> - if (rs6000_rop_protect)
> >> -flag_shrink_
p. */
> - if (rs6000_rop_protect)
> -flag_shrink_wrap = 0;
> }
(Yes, I know the original code didn't say either, but let's try to make
things better :-) )
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr114759-1.c
> @@ -0,0 +1,16 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -mdejagnu-cpu=power10 -mrop-protect
> -fdump-rtl-pro_and_epilogue" } */
> +/* { dg-require-effective-target rop_ok } */
Do you want rop_ok while you are *forcing* it to be okay anyway? Why?
Segher
e compiler with LTO to undo that optimization. */
Some of these array names no longer have the rs6000_ prefix now. Oh
wait, you already took that into account? I'm not saying anything :-)
The patch is fine for trunk, thank you! If you want backports those
are okay, too (but I don't think you want any? Or does this work
withput the previous patches as well?)
Segher
p the size of the
> rs6000_init_generated_builtins function quite a lot.
> The above patch decreases it back, to even less than the size of
> the function before my fix.
A patch in the middle of a thread. I missed it, sorry. Please send
patches as separate threads?
Segher
1 - 100 of 1221 matches
Mail list logo
