On Mon, Mar 28, 2022 at 06:30:41PM -0400, Michael Meissner wrote:
> On Mon, Mar 28, 2022 at 12:14:09PM -0500, Segher Boessenkool wrote:
> > On Mon, Mar 28, 2022 at 12:26:02PM -0400, Michael Meissner wrote:
> > > However on power9 and power10 it generates:
> > >
> &g
ot
see it, always a possibility of course.
> * config/rs6000/rs6000.md (vsx_extract_): Allow destination
> to be an Altivec register.
... to be any VSX register.
Okay for trunk with those things fixed. Thanks!
Segher
Hi!
On Tue, Feb 22, 2022 at 07:56:40PM -0600, Paul A. Clarke wrote:
> On Tue, Feb 22, 2022 at 06:41:45PM -0600, Segher Boessenkool wrote:
> > That said...
> >
> > > -/* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
> > > -/* { dg-skip-if &quo
ght3.C: Likewise.
> * g++.dg/other/spu2vmx-1.C: Likewise.
Those things can be done later, so: okay for trunk. Thanks!
Segher
runk?
Okay for trunk. Thanks!
I'll apply it myself :-)
Segher
> 2022-01-27 Bill Schmidt
>
> gcc/
> * config/rs6000/rs6000-builtin.def (NEG_V16QI): Move to [altivec]
> stanza.
> (NEG_V4SF): Likewise.
> (NEG_V4SI): Likewise.
> (NEG_
ially applied (or not at all even?)
It is a mess :-(
I'll look into it tomorrow.
Segher
On Wed, Mar 30, 2022 at 06:07:26PM -0500, Segher Boessenkool wrote:
> On Tue, Mar 15, 2022 at 02:18:00PM +0100, Jakub Jelinek wrote:
> > On Fri, Jan 28, 2022 at 11:50:26AM -0600, Bill Schmidt via Gcc-patches
> > wrote:
> > > PR104004 caught some misses on my part in conver
se move this to later, since you touch it anyway:
bool max_p;
>if (code == GE || code == GT)
> max_p = true;
>else if (code == LE || code == LT)
Okay for trunk with those finishing touches. Thanks!
Segher
On Wed, Mar 30, 2022 at 06:41:59PM -0400, Michael Meissner wrote:
> On Mon, Mar 28, 2022 at 03:28:39PM -0500, Segher Boessenkool wrote:
> > On Mon, Mar 28, 2022 at 12:27:05PM -0400, Michael Meissner wrote:
> > > In looking at PR target/99293, I noticed that th
x m; struct insn_link **l; } where;
NAK. It is not clear at all what "rtx m" means, esp. since there is an
"rtx *r" already. In the PR you said "machine_mode m", that is clear of
course, can you do that instead?
Okay for trunk with those things fixed. Thanks!
Segher
w it can contain any others as long as it has that flag as well.
Please fix.
Not every LONG_CALL needs a TOC restore though? I won't ask you to
make it work in those cases of course, but change the comment to not be
as misleading? Taking the "Only" out is good already I think :-)
You probably should have the same condition here as actually doing a
longcall as well, something involving SYMBOL_REF_FUNCTION_P?
Thanks,
Segher
code, you may need to do the same?
Segher
2022-04-06 Segher Boessenkool
PR target/105147
* testsuite/gcc.dg/pr105140.c: Skip for powerpc*-*-*.
---
gcc/testsuite/gcc.dg/pr105140.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/testsuite/gcc.dg/pr105140.c b/gcc
Hi!
So, the core of this problem is once again that regno_reg_rtx is
reallocated. It will be another decade until we got rid of all fallout
of breaking that guarantee :-(
On Wed, Apr 06, 2022 at 10:50:40AM +0200, Jakub Jelinek wrote:
> On Tue, Apr 05, 2022 at 04:56:55PM -0500, Seg
d uses stack_usage_watermark rather than a map.
Thanks for the fix!
Segher
one extra to the big list here, but, why do we need all these
manual exclusions anyway? What is broken about the test itself?
It would be so much more useful if the tests would help us, instead of
producing a lot of extra busy-work.
Segher
t; with the given configuration. While with new bif infrastructure, it
> becomes available and gets ICE due to incomplete supports.
>
> Segher and Peter pointed out that we should make them available with
> soft float, I agree we can extend them to cover both soft and hard
> float. But
On Thu, Apr 07, 2022 at 08:50:53AM -0500, will schmidt wrote:
> On Thu, 2022-04-07 at 06:00 -0500, Segher Boessenkool wrote:
> > On Thu, Apr 07, 2022 at 12:29:45AM -0400, Michael Meissner wrote:
> > > In PR target/104253, it was pointed out the that test case added as part
>
n?
There is -fpeel-loops as well, and cunroll is independent of all of
these as well?
> I would
> expect the effect of the option, versus the pragma, two to roughly
> equivalent. Obviously it is not. :-)
Yes, me too. And I do not see what makes the difference, if it isn't
the peel thing :-(
Ke Wen, can you try with -fno-peel-loops please?
Segher
Hi!
On Thu, Apr 07, 2022 at 02:59:55PM -0400, Michael Meissner wrote:
> On Thu, Apr 07, 2022 at 06:00:51AM -0500, Segher Boessenkool wrote:
> > On Thu, Apr 07, 2022 at 12:29:45AM -0400, Michael Meissner wrote:
> > > In PR target/104253, it was pointed out the that test case adde
Hi!
Thanks for investigating.
On Fri, Apr 08, 2022 at 03:25:51PM +0800, Kewen.Lin wrote:
> on 2022/4/8 3:29 AM, Segher Boessenkool wrote:
> > On Thu, Apr 07, 2022 at 09:19:51AM -0500, will schmidt wrote:
> >> On Mon, 2022-02-28 at 13:37 +0800, Kewen.Lin via Gcc-patches wrote:
t; with the given configuration. While with new bif infrastructure, it
> becomes available and gets ICE due to incomplete supports.
>
> Segher and Peter pointed out that we should make them available with
> soft float, I agree we can extend them to cover both soft and hard
> float. But consi
On Thu, Apr 07, 2022 at 03:00:14PM +0200, Jakub Jelinek wrote:
> On Thu, Apr 07, 2022 at 06:09:52AM -0500, Segher Boessenkool wrote:
> > On Thu, Mar 03, 2022 at 10:11:32AM +0800, Kewen.Lin wrote:
> > > As PR103623 shows, it's a regression failure due to new built-in
&
operand:QI 2 "const_0_to_1_operand" "i,i,i")]
UNSPEC_UNPACK_128BIT))]
"(!TARGET_POWERPC64 || !TARGET_DIRECT_MOVE) && FLOAT128_2REG_P (mode)"
"#"
@@ -14600,7 +14600,7 @@ (define_insn_and_split "unpack_nodm"
operands[3] = gen_rtx_REG (mode, fp_regno);
}
- [(set_attr "type" "fp,fpstore")])
+ [(set_attr "type" "fp,fpstore,store")])
(define_insn_and_split "pack"
[(set (match_operand:FMOVE128 0 "register_operand" "=&d")
===
Segher
ional (we have an actual reg in one of
the cases currently). What do you consider wrong about the old pattern,
what in the generated code is different from what you expect?
It works correctly on p7 etc. btw; where do you see it fail? p10?
Segher
Hi!
On Mon, Apr 11, 2022 at 04:29:40PM +0800, Kewen.Lin wrote:
> on 2022/4/9 1:31 AM, Segher Boessenkool wrote:
> > On Fri, Apr 08, 2022 at 10:09:44AM +0800, Kewen.Lin wrote:
> > For me it fails during combine: the unspec suddenly doesn't recog
> > anymore. That might b
trunk.
Segher
2022-04-11 Segher Boessenkool
PR target/105213
PR target/103623
* config/rs6000/rs6000.md (unpack_nodm): Add m,r,i alternative.
---
gcc/config/rs6000/rs6000.md | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/gcc/config/rs6000/rs6000
On Wed, Apr 06, 2022 at 02:33:52PM -0500, Peter Bergner wrote:
> On 4/5/22 10:33 PM, Peter Bergner via Gcc-patches wrote:
> > On 4/5/22 5:32 PM, Segher Boessenkool wrote:
> >> On Tue, Apr 05, 2022 at 05:06:50PM -0500, Peter Bergner wrote:
> So the updated change looks like bel
P8_FUSION_SIGN) Var(rs6000_isa_flags)
> -Allow sign extension in fusion operations.
> +Target Undocumented WarnRemoved
Don't WarnRemoved. Do Ignore. Just remove the whole thing please.
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr102059-4.c
> @@ -0,0 +1,23 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -mdejagnu-cpu=power10" } */
> +/* { dg-require-effective-target power10_ok } */
These last two lines the other way around: first state requirements, and
only then the options that those are for.
Please resend with those things fixed. Thanks!
Segher
ed things very thoroughly if
you do quick backports like this (although the only thing that seems to
be in danger are longcall things, and does anyone use those?) (don't
answer that :-) )
Segher
On Tue, Apr 05, 2022 at 10:33:14PM -0500, Peter Bergner wrote:
> On 4/5/22 5:32 PM, Segher Boessenkool wrote:
> >> + gcc_assert (rs6000_pcrel_p ());
> >> + func_desc = rs6000_longcall_ref (func_desc, tlsarg);
> >> +}
> >> + else
>
[SD]I) \((?:sub)?reg:[SD]I} 1 "combine" } } */
Ah, a nice small change. This looks fine, thanks! Okay for trunk.
It is fine to allow zero_extend:SI of :SI or :DI, those are invalid RTL,
testcases do not have to test there is no invalid RTL, in general.
Segher
On Mon, Apr 11, 2022 at 10:47:53AM +0800, HAO CHEN GUI wrote:
> There are two issues left in this PR. One is pr56605.c. My patch fixes it.
> Another is prefix-no-update.c. The patch Segher proposed in 103197 could fix
> it.
So today all remaining problems will be fixed. Thanks for sh
powerpc_vsx_ok is satisfied) you always are
compiling for power7 or higher.
What goes wrong?
Segher
alternatives for those.
Doing one final testsuite run on this now, will commit to trunk once
that finishes. It probably will need some backports as well.
Segher
2022-04-12 Segher Boessenkool
PR target/103197
PR target/102146
* config/rs6000/rs6000.md (*movsi_internal1
ongdouble128 instead?
/* { dg-require-effective-target longdouble128 } */
Okay for trunk, preferably like that. Thanks!
Segher
On Tue, Apr 12, 2022 at 10:02:06AM +0800, Kewen.Lin wrote:
> on 2022/4/11 11:42 PM, Segher Boessenkool wrote:
> > On Mon, Apr 11, 2022 at 04:29:40PM +0800, Kewen.Lin wrote:
> >> Nice, I confirmed this makes ICE gone, I've filed one new PR
> >> PR105213 for GCC13
rs6000/, we get SImode. Adjust the expectations.
>
> Tested with gcc-11 targeting ppc64-vx7r2. Ok to install?
This should have been tested on Linux as well: it is now broken on both
-m32 and -m64 there. Please revert?
Segher
On Wed, Apr 13, 2022 at 04:30:36PM -0500, Segher Boessenkool wrote:
> This should have been tested on Linux as well: it is now broken on both
> -m32 and -m64 there. Please revert?
Sorry, confusing with another new regression: this one is only -m64 of
course.
Segher
Hi!
On Sat, Apr 17, 2021 at 06:19:02AM -0300, Alexandre Oliva wrote:
> On Apr 12, 2021, Segher Boessenkool wrote:
> > On Fri, Apr 02, 2021 at 01:52:59PM -0300, Alexandre Oliva wrote:
> >> Several compile tests that use the __ieee128 type do not ensure it is
> >>
On Wed, Apr 13, 2022 at 08:37:40PM -0300, Alexandre Oliva wrote:
> On Apr 17, 2021, Alexandre Oliva wrote:
> > On Apr 12, 2021, Segher Boessenkool wrote:
> My supposition was wrong. It turned out to be just because in
> vxworks.h, for TARGET_VXWORKS7, there&
power9 (etc.) to enable VSX
just as well.
You should not change such defaults for your platform.
Segher
On Thu, Apr 14, 2022 at 01:56:39PM -0300, Alexandre Oliva wrote:
> On Apr 14, 2022, Segher Boessenkool wrote:
> > On Sat, Apr 17, 2021 at 06:19:02AM -0300, Alexandre Oliva wrote:
> >> On Apr 12, 2021, Segher Boessenkool wrote:
> >> > On Fri, Apr 02, 2021 at 01:
25 and r12-8039, this fix is to add the dg-skip-if for
> powerpc*-*-* and s390*-*-*.
>
> Tested on powerpc64le-linux-gnu P9 and it should work on s390
> as its similar PR105147.
>
> Is it ok for trunk?
Yes. Thanks!
Segher
+those. */
That sounds like we do not know what is correct to do, so just sweep it
under the carpet and hope it works out. "Just drop those, that is
always safe"? (Is it always safe?)
Okay for trunk with maybe a word or two more there. Thanks!
Segher
On Tue, Apr 19, 2022 at 02:58:26PM +0200, Richard Biener wrote:
> On Tue, 19 Apr 2022, Segher Boessenkool wrote:
> The assert was for any landing pad which obviously failed - the
> testsuite fails were all for MUST_NOT_THROW (negative) regions
> which do not end basic-blocks.
I
On Tue, Apr 19, 2022 at 05:00:12PM +0200, Richard Biener wrote:
> On Tue, 19 Apr 2022, Segher Boessenkool wrote:
> > > > And that always is safe? Why do we have REG_EH_REGION for those cases
> > > > at all, then?
> > >
> > > It's the only "
(clobber (scratch:DI))
]) 207 {*anddi3_imm_mask_dot}
(expr_list:REG_DEAD (reg:SI 136 [ niters.6 ])
(nil)))
The paradoxical subreg in the latter wasn't expected :-)
Segher
resulting
> +insns and just pick the first. */
> + if (!find_reg_note (i3, REG_EH_REGION, NULL_RTX)
> + && (CALL_P (i3)
> + || (cfun->can_throw_non_call_exceptions
> + && may_trap_p (i3
> + place = i3;
> + if (i2
> + && !find_reg_note (i2, REG_EH_REGION, NULL_RTX)
> + && cfun->can_throw_non_call_exceptions
> + && may_trap_p (i2))
> + {
> + if (place)
> + place2 = i2;
> + else
> + place = i2;
> + }
> + }
> + break;
> + }
Okay for trunk with the spello fixed, and maybe one more assert added.
Thanks for all the work on this!
Segher
This series adds "?" on the "Z" for lfiwzx and similar, so that we
preferably choose some D-form storage insn, instead of the X-form insn.
The D-form insns work on GPRs only, but it is still much preferred.
Committing to trunk.
Segher
Segher Boessenkool (3):
rs6000:
This is true if we have -mpowerpc64.
2022-04-21 Segher Boessenkool
gcc/testsuite/
* lib/target-supports.exp (check_effective_target_has_arch_ppc64): New.
---
gcc/testsuite/lib/target-supports.exp | 10 ++
1 file changed, 10 insertions(+)
diff --git a/gcc/testsuite/lib/target
alternatives for those.
2022-04-21 Segher Boessenkool
PR target/103197
PR target/102146
* config/rs6000/rs6000.md (zero_extendqi2 for EXTQI): Disparage
the "Z" alternatives in {l,st}{f,xs}iwzx.
(zero_extendhi2 for EXTHI): Ditto.
(zero_extendsi2
This testcase does not generate anywhere near optimal code for 32-bit
code. For p10 it actually now fails this testcase, after the previous
patch. Let's xfail it.
2022-04-21 Segher Boessenkool
gcc/testsuite/
PR target/103197
PR target/102146
* gcc.target/po
fsanitize-coverage=trace-pc
> -fnon-call-exceptions --param=max-cse-insns=1 -frounding-math" } */
> +/* { dg-additional-options "-mstack-arg-probe" { target x86_64-*-* i?86-*-*
> } } */
> +
> +void baz (int *);
> +void bar (double, double, _Decimal64);
> +
> +void
> +foo (void)
> +{
> + int s __attribute__((cleanup (baz)));
> + bar (0xfffe, 0xebf3fff2fbebaf7f, 0xff);
> +}
Why the int32plus? It needs 64-bit integers, and the size of "int"
does not matter at all afaics? Maybe you want lp64?
Okay for trunk with the naming and comment stuff looked at. Thank you!
Segher
On Tue, Jan 18, 2022 at 05:21:30PM +0100, Martin Liška wrote:
> I'm going to install the following -Wformat-diag that is based on Segher's
> wording.
Thanks!
(But please fix the format=flawed:
> Content-Type: text/plain; charset=UTF-8; format=flowed
)
Segher
erpc/pr104015-2.c: New test.
> OK for the target-independent part, thanks. IMO it's OK independently
> of the rs6000 tests.
The rs6000 parts are fine as well. Thanks!
I see you got rid of the ilp32 tests, I was going to holler about that,
there is no reason this should only work (or only be tested) on 64-bit
systems :-)
Segher
d it will do exactly the same as not having a default at all. Not
having such useless code is by far the most readable, so please don't
include a default case at all.
Okay with those changes. Thanks!
Segher
On Wed, Jan 19, 2022 at 12:27:32PM +0100, Jakub Jelinek wrote:
> On Wed, Jan 19, 2022 at 07:54:19AM +0100, Sebastian Huber wrote:
> > On 18/01/2022 22:42, Segher Boessenkool wrote:
> > > > +default:
> > > > + break;
> > > Please don'
4, the testcase could use "long" instead
> of "long long".
The testcase really needs "powerpc64", if that would mean "test if
-mpowerpc64 is (implicitly) used". But that is not what it currently
means (it is something akin to "powerpc64_hw", instead).
So we test lp64, which is set if and only if -m64 was used. It is
reasonable coverage, no one cares much for -m32 -mpowerpc64 .
Segher
uot; 32 } } */
This will need modification for the phase of the moon. It also does not
even test only xxlor insn (also xxlorc insns, for example).
> +/* { dg-final { scan-assembler-times "xxsldwi" 10 } } */
Okay if you make this
\mxxsldwi\M
or even
\m(?:xxsldwi|vsldoi)\M
Thanks!
Segher
r something.
Not really worth it unless you need this often, the four we have now
(which could be two perhaps, by merging each pair of patterns again)
isn't enough to warrant the extra indirection.
Okay for trunk. Also fine for backports if you need them.
Thanks!
Segher
t code to check builtins return code.
> + Added more tests to test all valid (standard) exceptions input
This is okay for trunk (Jeff already approved the generic parts).
Thanks!
Segher
of
> ieee128_mangling_gcc_8_1 ? "U10__float128" : "u9__ieee128".
> (rs6000_globalize_decl_name): Remove.
> * config/rs6000/rs6000-call.cc (init_cumulative_args,
> rs6000_function_arg_advance_1): Don't set rs6000_passes_ieee128.
I love deleting code :-)
Segher
ate check.
Perfect, and pushed. Thank you!
Segher
and tested one below patch to remove all the code using
> >> RS6000_CONSTRAINT_v on powerpc64le-linux-gnu P10 and P9,
> >> powerpc64-linux-gnu P8 and P7 with no regressions.
> > I would prefer that we not make gratuitous changes to this code, but
> > maybe Segher has a
before it is used, not at the
start of the function?
Okay for trunk like that. Thanks! Also any and all backports you want
are fine.
Segher
ertain code we want to disallow whole register banks.
But disallowing or allowing some instructions separately is not a good
idea: it doesn't give any useful extra functionality, it is hard to use,
and it is a lot of extra work for us (it is impossible to test, already,
too many combinations).
Segher
ilp32 } */
> +/* We don't have one powerpc.*_ok for Power6, use altivec_ok conservatively.
> */
> +/* { dg-require-effective-target powerpc_altivec_ok } */
> +/* { dg-options "-mdejagnu-cpu=power6" } */
It is okay always, no _ok at all please.
Okay for trunk with those things (but do test of course). Thanks!
Segher
On Thu, Jan 27, 2022 at 07:24:53PM +0800, Kewen.Lin wrote:
> on 2022/1/27 上午1:57, Segher Boessenkool wrote:
> > I like your original patch better. But for stage 1, sorry.
>
> Thanks Segher! Is it ok to commit it then? Or I'll repost this once
> next stage1 starts.
Eith
owerpc/pr103627-1.c: New test.
> * gcc.target/powerpc/pr103627-2.c: New test.
Okay for trunk. Thanks!
Segher
ger
problem, and nothing that a few scattershot tests will help fix :-(
Segher
ut some number of
if statements. You cannot use a switch as a shorthand for this because
we have a silly warning and -Werror for this use.
You probably get easier to understand code that way, too, you can get
rid of the above (just do some early returns), etc.
Segher
t;By removing the apply"... What does that mean?
Nice cleanup (and nice bugfix of course). Okay for trunk (with that
comment improved a bit perhaps). Thanks!
Segher
On Fri, Jan 28, 2022 at 03:19:48PM -0600, Bill Schmidt wrote:
> On 1/28/22 1:11 PM, Segher Boessenkool wrote:
> > On Fri, Jan 28, 2022 at 11:50:19AM -0600, Bill Schmidt wrote:
> >> + and the generic code will issue the appropriate error message. Skip
> >> + th
be a literal
> between X' and Y', inclusive". During reviews, Segher requested that I
> eventually convert all messages of the first form into the second form for
> consistency. That's what this patch does, replacing all -form
> constraints (first form) with -form
On Mon, Jan 31, 2022 at 11:21:32AM -0600, Bill Schmidt wrote:
> On 1/28/22 5:24 PM, Segher Boessenkool wrote:
> > On Fri, Jan 28, 2022 at 11:50:21AM -0600, Bill Schmidt wrote:
> >> When introducing the new built-in support, I tried to match as many
> >> existing error
, it is much nicer to have those explicit everywhere.
> +#ifndef OPTION_GLIBC
> +#define OPTION_GLIBC 0
> +#endif
So can you add a comment like that before this please?
Okay for trunk with that. Thanks!
Segher
compiler configured the same should behave the same, whatever
the host compiler does. I've told you this before.
Segher
; +void
> +rs6000_init_builtins (void)
> +{
> + tree tdecl;
> + tree t;
Don't declare things long before they are used please.
...
Bah, I am commenting on existing code... Please do not mix code
movement and other things in the same patch. In the (very few!) cases
where you need things to stay together for bisectability, you can still
submit it as multiple patches (and you have that, that is how you write
it in the first place!), just comment that you need to check in a few
patches together.
Is it a big hassle to do that now, for this patch?
Segher
On Mon, Jan 31, 2022 at 02:38:27PM -0500, Michael Meissner wrote:
> On Mon, Jan 31, 2022 at 12:52:28PM -0600, Segher Boessenkool wrote:
> > Hi!
> >
> > On Mon, Jan 31, 2022 at 01:49:03PM -0500, Michael Meissner wrote:
> > > * config/rs6000/rs6000.cc (TA
On Mon, Jan 31, 2022 at 04:01:58PM -0600, Bill Schmidt wrote:
> On 1/31/22 3:32 PM, Segher Boessenkool wrote:
> > On Fri, Jan 28, 2022 at 11:50:22AM -0600, Bill Schmidt wrote:
> >> Overloading support remains in rs6000-c.cc.
> > So, what is needed to move that as well? Is
ee %s = NULL_TREE;\n if (float128_type_node)\n",
> + buf);
>else if (dfp_found)
> - fprintf (init_file, " if (dfloat64_type_node)\n ");
> +fprintf (init_file,
> + " tree %s = NULL_TREE;\n if (dfloat64_type_node)\n",
> + buf);
Things are much more readable if you break this into multiple print
statements. I realise the existomg code is like that, but that could
be improved.
So, okay for trunk (modulo what Bill finds), and you can include the
testcase as well after I have fixed the selector. Thanks Jakub!
Segher
code == RS6000_OVLD_VEC_INSERT)
> +returned_expr = resolve_vec_insert (&res, arglist, nargs, loc);
> + else if (fcode == RS6000_OVLD_VEC_STEP)
> +returned_expr = resolve_vec_step (&res, arglist, nargs);
> +
> + if (res == resolved)
> +return returned_expr;
This is so convoluted because the functions do two things, and have two
return values (res and returned_expr).
Segher
eed to be 1ULL btw? (You need this if restr_val1[i]
can be greater than or equal to 32). (32 itself would work, but is UB
nevertheless).
Okay with that. Thanks!
Segher
; (VCTZLSBB_V4SI): Likewise.
> (VCTZLSBB_V8HI): Likewise.
Please don't break lines early? Changelog lines are one tab followed
by 72 chars.
The patch is fine though. Thanks!
Segher
>
> The default is to ask for back ports after a break. Can I back port the
> patch (with the default: break) to GCC 10 and 11 now?
I have many more changes, but I'll deal with that. Okay for 11 and 10.
Thanks!
Segher
Tested on powerpc64-linux {-m32,-m64}. Committed.
Segher
2022-02-02 Segher Boessenkool
gcc/testsuite/
* lib/target-supports.exp (check_effective_target_powerpc_altivec_ok):
Return 0 if the target is not Power. Restructure and add some comments.
---
gcc/testsuite/lib
rd ends there, there is
no need to assert that :-)
Okay for trunk like that. Thanks!
Segher
TS
> +|| fcode == RS6000_OVLD_VEC_EXTRACT
> +|| fcode == RS6000_OVLD_VEC_INSERT
> +|| fcode == RS6000_OVLD_VEC_STEP))
> return NULL;
Even I can understand that! Thank you! :-)
Okay for trunk.
Segher
p (reg, SET_DEST (set1)))
> + {
> + undo_all ();
> + return 0;
> + }
> + }
> + }
The patch is okay for trunk. Thank you!
Also okay for backports (after waiting for fallout a week or two).
Segher
he gcc -v output)
dows not say what defaults the build compiler used.
I already NAKed this patch for weeks, and I do it again now.
Segher
On Fri, Feb 04, 2022 at 02:10:03PM -0600, Peter Bergner wrote:
> On 2/4/22 12:03 PM, Segher Boessenkool wrote:
> > On Fri, Feb 04, 2022 at 04:43:53PM +0100, Andreas Schwab wrote:
> >> On Feb 04 2022, Michael Meissner via Gcc-patches wrote:
> >>> If the user did not
but then error; in all other cases it should do it.
This patch is pretty much equal to not allowing any inlining if the
caller and callee have not identical compilation options. So sure, it
causes us to not have any unwanted inlining, but it does that by
preventing all other inlining at the same time.
Segher
On Mon, Feb 07, 2022 at 01:54:00PM +0800, Kewen.Lin wrote:
> on 2022/1/28 上午1:17, Segher Boessenkool wrote:
> > On Thu, Jan 27, 2022 at 07:21:33PM +0800, Kewen.Lin wrote:
> >>PR target/103627
> >>* config/rs6000/rs6000.cc (rs6000_option_override_intern
r_operand" "v")
> + (match_operand:V1TI 3 "register_operand" "v")]
> +UNSPEC_VMSUMCUD))]
> + "TARGET_POWER10"
> + "vmsumcud %0,%1,%2,%3"
> + [(set_attr "type" "vecsimple")]
> +)
This can be properly described in RTL instead of using an unspec. This
is much preferable. I would say compare to maddhd[u], but those insns
aren't implemented either (maddld is though).
Segher
On Mon, Feb 07, 2022 at 10:06:36PM -0600, Bill Schmidt wrote:
> On 2/7/22 5:05 PM, Segher Boessenkool wrote:
> > On Mon, Feb 07, 2022 at 04:20:24PM -0600, Bill Schmidt wrote:
> >> I observed recently that a couple of Power10 instructions and built-in
> >> func
parent goal here is to give users compilers that default to IEEE
QP long double earlier. That is a fine goal, but it should be achieved
bu actually changing the default earlier, not by leaving behind a large
fraction of users!
Segher
ken. You could use const_0_to_15_operand together with an insn
condition for example. It seems all uses of 0_to_12 have similar
problems? Removing it completely also saves use from having to fix its
documentation (in predicates.md) :-)
The patch is okay for trunk. Thanks!
Segher
gt; +/* { dg-do compile { target ia32 } } */
> +/* { dg-options "-O2 -mrtd" } */
> +
> +register volatile int a __asm__("%esp");
> +void foo (void *);
> +void bar (void *);
> +
> +void
> +baz (void)
> +{
> + foo (__builtin_return_address (0));
> + a = 0;
> + bar (__builtin_return_address (0));
> +}
So does it not fail if you make this valid code (by using another
register)? bp, si, or di maybe?
Okay with that fixed. If fixing it is too hard, okay like this (I don't
have to maintain other peoples' backends' testsuites after all...)
Thanks!
Segher
On Thu, Feb 10, 2022 at 05:21:07PM +0100, Jakub Jelinek wrote:
> On Thu, Feb 10, 2022 at 10:10:13AM -0600, Segher Boessenkool wrote:
> > But we do have that in other cases, and not just for combine. IMO it
> > is a good idea to robustify for_each_inc_dec (simply have it skip if the
On Thu, Feb 10, 2022 at 06:23:58PM +0100, Jakub Jelinek wrote:
> On Thu, Feb 10, 2022 at 10:42:03AM -0600, Segher Boessenkool wrote:
> > > Not on x86, that isn't a general auto-inc-dec target, but uses PRE_DEC
> > > etc. only for the sp hard register.
> >
> &g
501 - 600 of 6091 matches
Mail list logo
