rts you
want (after waiting to see if it creates problems on trunk, as usual).
Thanks!
Segher
On Mon, Dec 14, 2020 at 05:29:30PM +0100, Piotr Kubaj wrote:
> On 20-12-14 10:22:32, Segher Boessenkool wrote:
> > On Mon, Dec 14, 2020 at 03:57:27PM +0100, Piotr Kubaj wrote:
> > > > It is both, actually (-mcpu= implies -mtune=)
> > > Yes, but -mtune doesn't i
P (vals, 0, i));
> + op[i] = simplify_gen_subreg (Pmode, tmp, inner_mode, 0);
> }
Pmode is defined based on TARGET_64BIT, not TARGET_POWERPC64.
But, can you not always use SImode here?
The rest of the patch is fine of course.
Segher
ubregs, subregs are worse most of the time).
Segher
ems a really bad design: this is
obviously exactly the same on any architecture.
> +proc check_effective_target_ppc_long_double_64bit { } {
> +return [check_cached_effective_target ppc_long_double_64bit {
> + int main()
> + {
> + #ifndef _ARCH_PPC
> + return 1;
> + #else
> + return sizeof (long double) != 8;
> + #endif
> + }
> +}]
> +}
Ditto.
Segher
bably really want some add_options_for_ thing, and use that
everywhere else?
Before this patch you did not test for anything printf (or glibc at
all); why is that suddenly necessary?
Segher
On Tue, Dec 15, 2020 at 12:29:45AM +0100, Gerald Pfeifer wrote:
> On Mon, 14 Dec 2020, Segher Boessenkool wrote:
> >> + powerpc*le-*-*)
> >> + tm_file="${tm_file} rs6000/sysv4le.h" ;;
> >> + esac
> > What an obvious filename ;-)
>
&
get a new maintainer for AVR in place? Any nominations?
I nominate Georg-Johann Lay as the obvious choice, since he has authored
333 of the 511 patches that went into config/avr/ the last ten years.
Segher
Hi Ke Wen,
On Tue, Dec 15, 2020 at 03:53:29PM +0800, Kewen.Lin wrote:
> on 2020/12/15 上午2:51, Segher Boessenkool wrote:
> > On Wed, Dec 02, 2020 at 05:44:24PM +0800, Kewen.Lin wrote:
> >> --- a/gcc/config/rs6000/rs6000.c
> >> +++ b/gcc/config/rs6000/rs6000
On Wed, Dec 16, 2020 at 04:19:12PM +0800, Kewen.Lin wrote:
> on 2020/12/15 下午10:40, Segher Boessenkool wrote:
> > I mean do
> >
> > rtx tmp = force_reg (inner_mode, XVECEXP (vals, 0, i));
> > op[i] = simplify_gen_subreg (SImode, tmp, inner_mode,
t; Bootstrap/regtest on powerpc64le (Power8/Power10) with no new regressions. Ok
> for trunk?
Okay for trunk. Thanks!
Segher
allowing EDGE_CROSSING.
> Also tested in GCC 8 with this patch and don't see ICEs there either
> (though, of course, I'm not suggesting we should backport this to release
> branches).
The patch looks fine to me of course, modulo that worry.
Segher
On Wed, Dec 16, 2020 at 04:36:37PM +0100, Jakub Jelinek wrote:
> On Wed, Dec 16, 2020 at 09:28:56AM -0600, Segher Boessenkool wrote:
> > This used to not work, as mentioned in the original patch submission:
> > https://patchwork.ozlabs.org/project/gcc/patch/52f14532eb742ac8d878a185a
On Wed, Dec 16, 2020 at 06:31:35PM +0100, Jakub Jelinek wrote:
> On Wed, Dec 16, 2020 at 11:17:29AM -0600, Segher Boessenkool wrote:
> > It was just a bootstrap+regression check, so no new testcase was needed.
> > I don't remember what target, but powerpc (32+64, BE) probably.
y to fix it by hand... Wish me
luck :-)
Segher
On Tue, Dec 15, 2020 at 12:29:45AM +0100, Gerald Pfeifer wrote:
> > The patch looks fine. Okay for trunk. Also okay for any backports you
> > want (after waiting to see if it creates problems on trunk, as usual).
>
> Thank you! Segher doesn't have write access, and usual
are required only when adding support for
> setting specific condition code bits.
When some instruction sets the condition mode bits in a different way /
with a different meaning than normal comparison instructions do, more
generally.
Segher
On Thu, Dec 17, 2020 at 10:07:22AM -0500, Paul Koning wrote:
> > On Dec 17, 2020, at 6:21 AM, Segher Boessenkool
> > wrote:
> > On Thu, Dec 17, 2020 at 02:15:51PM +0530, Senthil Kumar Selvaraj via
> > Gcc-patches wrote:
> >> The work on my github branch was no
On Fri, Dec 18, 2020 at 06:13:22PM +0100, Georg-Johann Lay wrote:
> Segher Boessenkool schrieb:
> >On Thu, Dec 17, 2020 at 10:07:22AM -0500, Paul Koning wrote:
> >>>On Dec 17, 2020, at 6:21 AM, Segher Boessenkool
> >>> wrote:
> >>>On Thu, Dec 17, 202
) and cmp (4) insns, since it is "just one insn"...
but we can do better than that, make it a bit cheaper).
Segher
hat
exposed the problem (for onlookers like me who do not know this code
well, anyway ;-) )
Segher
On Mon, Dec 28, 2020 at 12:44:15PM +0100, Gerald Pfeifer wrote:
> On Wed, 16 Dec 2020, Segher Boessenkool wrote:
> >> Any chance (one of you) can help and commit this?
> > Done now.
> >
> > Please remind me in a week or so to do the backports?
>
> Thank you,
e used outside of
combine, too? This can lead to insns that do not recog() then? Is
there anything that prevents that from happening?
Segher
Hi!
On Thu, Dec 31, 2020 at 09:54:01AM +0100, Uros Bizjak wrote:
> On Thu, Dec 31, 2020 at 9:40 AM Segher Boessenkool
> wrote:
> > Nice. Just one thing: in principle the splitters can be used outside of
> > combine, too? This can lead to insns that do not recog() then? Is
On Thu, Dec 31, 2020 at 04:39:52PM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > It isn't likely that any other pass would try to create this pattern,
> > but this isn't guaranteed, and such other passes do not necessarily do
> > the add-the-clobb
u probably still need most of this code, but at least it will be more
obvious how to handle conflicts in user-specified options.
Segher
We indent with tabs, not spaces. This fixes it.
Committed.
2021-01-12 Segher Boessenkool
* MAINTAINERS: Fix spacing.
---
MAINTAINERS | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index e88808f..6ec346c 100644
--- a
> Andreas Jaeger
> Harsha Jagasia
> Fariborz Jahanian
> +Qian Jianhua
Indents should be with tabs here. I fixed it (and some others).
Segher
elled without dash. The warning is
mistaken, and its advice (not phrased as advice) is bad advice.
[-- Attachment #2: format-diag.diff --]
[-- Type: text/x-patch, Encoding: quoted-printable, Size: 2.2K --]
Please use plain text attachments, so that people can a) read it on the
mail archives, and b) apply the patches easily, etc.
Segher
rehensible
> either to users or to tranlators (acronyms like elt or rtx aren't
> universally understood).
Neither translators or even users are an audience for those messages at
all: the only thing they should see is "internal error", and perhaps
how to report it. Reporting a translated version of the message is a
bad idea.
Segher
Hi!
On Wed, Jan 13, 2021 at 12:49:42AM +, Joseph Myers wrote:
> On Tue, 12 Jan 2021, Segher Boessenkool wrote:
> > On Sat, Jan 09, 2021 at 07:44:31PM +0100, Matthias Klose wrote:
> > > These warnings, including the suggested fixes are seen on power*-linux
> > > b
On Thu, Jan 07, 2021 at 11:20:39AM -0300, Raoni Fassina Firmino wrote:
> On Wed, Nov 18, 2020 at 06:38:22AM -0600, Segher Boessenkool wrote:
> > We can handle the constants issue similarly to what we do for
> > __builtin_fpclassify, too.
>
> I think that if we must saf
)
Likely because it results in this, and this insn isn't recognised. So
this can be fixed by adding a pattern for it (it needs to make sure all
but the bottom 32 bits of reg 131 are zero; it can use nonzero_bits for
that).
Long ago I had the following patch for this. Not
as well).
> This proposal is to check whether the last_set_table safely happens
> after the current set, make the set still valid if so.
I don't think this is safe to do like this, unfortunately. There are
more places that set last_set_invalid (well, one more), so at the very
minimum this needs a lot more justification.
Segher
really can advantageously use the rl*imi insns often!)
Segher
ot;) (DF "64")
> +(V4SI "32") (V2DI "64")])
The comment needs a clarification what this means for vector modes.
"How many bits (per element) in this mode?" perhaps? Does that sound
good?
The patch is okay for trunk with such a tweak. Thank you!
Segher
(after many fixes!)
I don't think this is a good idea at all, fwiw. Before we even should
think about doing 4->3 combinations, we should stop severely limiting
what combinations of 4 insns we allow; and we do that because it will
slow down the compiler a lot, for no big gain.
Segher
>
> This patch replaces patches previously submitted:
What did you change after I approved it?
Segher
On Thu, Jan 14, 2021 at 12:09:36PM -0500, Michael Meissner wrote:
> [PATCH] PowerPC: Add float128/Decimal conversions.
Same question here.
Segher
e when targetting older machines,
so who knows -- that -mcpu=power8 was there already, and it does require
testing an effective target).
Okay for trunk with this fixed one way or another. Thanks!
Segher
not happen).
If this regstraps, I'll commit it tomorrow morning.
Segher
2021-01-19 Segher Boessenkool
* config/rs6000/rs6000.c (rs6000_emit_le_vsx_store): Change assert.
Adjust comment. Simplify code.
---
gcc/config/rs6000/rs6000.c | 8 +++-
1 file chang
(IBM128_CFLAGS): New make variable.
> (gcc_s_compile): Add -mno-gnu-attribute to all shared library
> modules.
Okay for 10. Thanks!
Is there a reason we do not have that testcase in the testsuite, btw?
Segher
0, 7))
Space before ( please (twice).
The rest looks fine -- either repost this with a better changelog, or
immediately commit it with that (and the nit fixed), whichever you
prefer. Thanks!
Segher
!= SFmode)
> +{
> + printf("ERROR, rs6000_constF32toI32 mode not equal to
> SFmode.\n");
Let's not have the printf :-)
> + gcc_unreachable ();
Is the gcc_unreachable still useful? If so, write it as
gcc_assert (GET_MODE (operand) == SFmode);
? And if not, just drop it :-)
> +@smallexample
> +@exdent vector double vec_splatid (const float);
> +@end smallexample
> +
> +Convert a floating-point value to double-precision and splat the
> result to a
> +vector of double-precision floats.
You probably should say the floating-point value you start with is
single precision.
Segher
lend-runnable.c
> +/* { dg-final { scan-assembler-times {\msplati\M} 6 } } */
> +/* { dg-final { scan-assembler-times {\msrdbi\M} 6 } } */
These do not work like this? Some v or xx splti*, and vsrdbi?
Thanks!
Segher
er-times {\mmulld\M} 1 } } */
> +/* { dg-final { scan-assembler-times {\mmodsd\M} 2 } } */
> +/* { dg-final { scan-assembler-times {\mpld\M} 1 } } */
This needs some more documentation what it tests, and how.
And/or maybe the dg-require-effective-target powerpc_pcrel shouldn't
be there?
Okay for trunk with those two things cleared up. Thanks!
Segher
Some testcases failed (esp. with --with-cpu=power9) after my change to
prefer xxperm over vperm when all else is equal. Fix that. (This also
tightens the relevant REs somewhat).
Tested on way too many configurations. Committed to trunk.
Segher
2020-06-09 Segher Boessenkool
gcc
iption for each selector is clear and
accurate, and guides the potential user to what selector to use where).
Okay for trunk with that changed. Thanks!
Segher
Hi!
On Mon, Jun 08, 2020 at 02:22:23PM +0800, luoxhu wrote:
> On 2020/6/3 04:32, Segher Boessenkool wrote:
> > On Tue, Jun 02, 2020 at 04:41:50AM -0500, Xionghu Luo wrote:
> >> + if (TREE_CODE (type) == RECORD_TYPE
> >> + && rs6000_discover_homogeneou
uot;isa" "*,p9v")])
> + [(set_attr "length" "4,12,4")
"*,12,*" perhaps?
> + (set_attr "type" "shift,*,vecperm")
I don't know if "shift" is a good type at all, but it'll be adjusted for
the scheduling models anyway. Okay.
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/bswap64-5.c
> @@ -0,0 +1,42 @@
> +/* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
Why does this test only on 64-bit systems? Why is the file called
"bswap64", while it tests smaller sizes as well?
Split the test into two?
Rest looks fine.
Segher
(rs6000_emit_hw_fp_minmax): ... this.
> (rs6000_emit_hw_fp_cmove): Rename rs6000_emit_p9_fp_cmove.
> (rs6000_emit_cmove): Update calls to rs6000_emit_hw_fp_minmax and
> rs6000_emit_hw_fp_cmove.
Just "Adjust." is fine :-)
Segher
l { scan-assembler "xscmpeqqp" } } */
> +/* { dg-final { scan-assembler "xscmpgtqp" } } */
> +/* { dg-final { scan-assembler "xscmpgeqp" } } */
> +/* { dg-final { scan-assembler "xsmaxcqp" } } */
> +/* { dg-final { scan-assembler "xsmincqp" } } */
> +/* { dg-final { scan-assembler "xxsel" } } */
\m and \M please. And could you use scan-assembler-times here? If so,
please do (all of this is very general advice).
Segher
at
can be quite a bit of (testing) work, and is it worth it at all.
> Please let me know how you would like me to handle this issue.
Either way is okay (I'd go for just the 2-line patch).
Thanks,
Segher
Hi!
On Tue, Jun 09, 2020 at 05:01:45PM -0700, Carl Love wrote:
> On Fri, 2020-06-05 at 16:28 -0500, Segher Boessenkool wrote:
> > > +;; Return 1 if op is a 32-bit constant signed integer
> > > +(define_predicate "s32bit_cint_operand"
>
r_mode (op, SImode))
(which neatly uses the _target_ SImode).
trunc_int_for_mode always sign-extends; we don't have one that zero-
extends afaik, but that one is much easier to write anyway:
IN_RANGE (UINTVAL (op), 0, 0x)
Segher
;for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
> {
> gimple *stmt = gsi_stmt (gsi);
> + if (is_gimple_debug (stmt))
> + continue;
Yes, this is fine for trunk (with the indent fixed), thanks!
Or you could use gsi_next_nondebug? That is a bit neater. Either way
is okay.
Thanks!
Segher
y_operand")
> + (match_operand:QI 2 "int_reg_operand")]
Why this? gpc_reg_operand will just work, no? (Even just
register_operand should, but let's not go there today ;-) )
Okay for trunk with that change, or with some explanation. Thanks!
Segher
On Tue, Jun 09, 2020 at 02:29:13PM -0600, Jeff Law wrote:
> On Sun, 2020-05-24 at 11:22 -0500, Segher Boessenkool wrote:
> > OTOH, you don't need to name Tuple at all... It should not *have* a
> > constructor, since you declared it as class... But you can just use
On Tue, Jun 09, 2020 at 09:51:12AM -0600, Martin Sebor wrote:
> >I think the backend declaration is wrong, the function only takes
> >a void * argument and returns a long.
>
> Thanks. In his comment on the bug Segher (CC'd) points to
> the internals manual that document
On Fri, Jun 12, 2020 at 10:46:33AM +0200, Richard Biener wrote:
> On Fri, Jun 12, 2020 at 2:31 AM Segher Boessenkool
> wrote:
> > Why did this work before, and not anymore? That sounds like a missing
> > or broken test?
>
> It "worked" before because GIM
unnable.c
> +++ b/gcc/testsuite/gcc.target/powerpc/builtins-1-p9-runnable.c
> @@ -1,25 +1,37 @@
> /* { dg-do run { target { powerpc*-*-linux* && { lp64 && p9vector_hw } } } }
> */
Why the lp64 here?
> /* { dg-require-effective-target powerpc_p9vector_ok } */
That is implied by p9vector_hw (or it should be, at least :-) )
Segher
On Mon, Jun 15, 2020 at 09:25:40AM -0500, Aaron Sawdey wrote:
> Now that this has been in trunk for a bit with no issues, ok to back port to
> 10?
Yes please. Thanks!
Segher
> > The same problem also arises for plfs where prefixed_load_p()
> > doesn't recognize it so
act
name of the value added (spelled in full).
(Not that it matters much in this case anyway: no one will search the
changelog for "type" or even "\" or "\.*):", although,
hrm I did search for that in "git log config/rs6000", but most commits
do not have changelog entries in the commit message yet).
Segher
gimple_stmt_iterator *gsi)
The comment needs changing, explaining what the new arg is.
Segher
tes the type of the result. */
> + TYPE indicates the type of the result.
(trailing spaces)
> + GSI points to a GIMPLE statement that we are currently folding. */
That isn't a useful thing to say. Write that this function inserts new
code before there?
Okay for trunk with those changes. Thanks!
Segher
EE_P (TYPE_MODE (type)))
> return ieee128_mangling_gcc_8_1 ? "U10__float128" : "u9__ieee128";
>
> + if (type == vector_pair_type_node) return "u13__vector_pair";
> + if (type == vector_quad_type_node) return "u13__vector_quad";
Line breaks?
> /* No data type wants to be aligned rounder than this. */
> -#define BIGGEST_ALIGNMENT 128
> +#define BIGGEST_ALIGNMENT ((TARGET_MMA) ? 512 : 128)
No silly parens around TARGET_MMA please (macros should protect
themselves, sure, but not try to protect other macros).
Okay for trunk modulo the above. Thanks! This was much less painful
than I feared. Well, maybe it is all in the other patches, I'll get to
those tomorrow ;-)
Segher
_operand" "mwa")
> + (match_operand:PXI 3 "mma_input_operand" "mwa")
> + (match_operand:PXI 4 "mma_input_operand" "mwa")]
> + UNSPEC_MMA_ASSEMBLE_ACC))]
I would expect all those four last match_operand to be :V16QI, so why
does it use this strange mode?
In general, many of the MMA insns play loose and fast with the modes.
This probably works fine, since everything is unspec, but eww :-)
Anyway, okay for trunk. Thanks! Thanks to all who worked on this, it
was a painful trip getting to here.
Segher
es {\mpmxvi8ger4\M} 1 } } */
> +/* { dg-final { scan-assembler-times {\mpmxvi8ger4pp\M} 1 } } */
> +/* { dg-final { scan-assembler-times {\mpmxvi8ger4spp\M} 1 } } */
Nowhere does it say how many of which insns are expected in which of the
twenty-odd functions, so this can become a maintenance nightmare. If
anything ever changes, and it will be *your* nightmare anyway ;-)
Okay for trunk. Thanks!
Segher
; >> V4DFmode,
> >> +OImode,
> >> +XImode,
> >> +POImode,
> >> +PXImode,
> >> CCmode,
> >> CCUNSmode,
> >> CCEQmode,
> >> +CCFPmode,
> >>};
> >
> > Same for the CCFP one here.
>
> Mike added those. I guess I thought they were needed. Mike?
> If they're not needed for MMA, I'll remove them from this patch
> and they be submitted in a separate patch if they are needed for
> something else.
You can keep them, it's compiler debug only, but the changelog should
mention it (it looks like an accident now, which maybe it was ;-) )
Segher
Imode and PImode.
If you need to keep it, please add a comment explaining why?
Segher
ignore every dot file (except those few we then
unignore)?
Segher
t_ops once that patch is
> reviewed/approved.
If you insist. I find this futile busy-work, now and in the future :-/
Segher
core, so this
> would be “len_load_optab” and “len_load$a” (or “len_load_$a”,
> there's no real consistency on that). Same for stores.
With a second underscore is better readable than with just one (the mode
does not apply to just the part after the underscore).
Thanks,
Segher
h
that I'll just do your change, but :-)
> > This part is approved for trunk. Thanks!
>
> Thanks to you too. Alas, my credentials from the CVS days of GCC almost
> certainly don't
> work any more (in git), so I'm now reliant on the generosity of others to
> push changes
> into the tree.
It still accepts my 2000-era RSA key, apparently (but not DSA any
more :-( )
> I promise that if I make a habit of contributing regularly
> again, I'll learn
> the new ways of doing things, but it's a little awkward after being a
> maintainer.
Not too much changed! Well, maybe all the details did ;-)
Segher
;;
> "" | common | native \
> - | power[3456789] | power5+ | power6x \
> + | power[3456789] | power10 | power5+ | power6x \
And this one never had a future. Good.
Okay for trunk with that change. Thanks!
(I'll do the backport to 10, fold it in with the rest).
Segher
Thanks! Also okay for backport to 10, if you want that.
Segher
guess that is just a mail issue.
Okay for trunk with those trivialities, and the things Will found, fixed
up. Thanks! Just writing out the full instruction names is the easiest
for everyone btw, unless that then needs to be a huge list, that isn't
very helpful to anyone.
Segher
;t there before
GCC 10 :-)
Segher
> int' and 'const char' [-Werror=sign-compare]”
>
> OK for master?
Of course, pretty much trivial :-) Thanks Iain!
Segher
From: Roger Sayle
2020-06-24 Roger Sayle
* simplify-rtx.c (simplify_unary_operation_1): Simplify
(parity (parity x)) as (parity x), i.e. PARITY is idempotent.
---
gcc/simplify-rtx.c | 4
1 file changed, 4 insertions(+)
diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.
From: Roger Sayle
2020-06-24 Roger Sayle
Segher Boessenkool
* simplify-rtx.c (simplify_unary_operation_1): Simplify rotates by 0.
---
gcc/simplify-rtx.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c
index 65008ea..3e913b5
es/commits was straight forward and I'm
> currently bootstrapping/regtesting the backports on both powerpc64le-linux
> and powerpc64-linux. Is this (including the hunk below) ok for GCC 10
> release branch assuming the tests come back clean?
Yes, all are okay for 10 as well (incl. Kelvin's backport). Thanks!
> rs6000: Backport u8bit_cint_operand predicate.
(No dot at the end of the subject please.)
Segher
ically the insns that consume the values loaded will use
the same masks again, so that may not be such a strong point.
Segher
texi: Update documentation for vec_extractl.
> Replace builtin name vec_extractr with vec_extracth. Update description
> of vec_extracth.
Okay for trunk. Thanks!
Segher
_, vinsertvr_internal_,
> vinsertgl_internal_, vinsertgr_internal_, mode VEC_I.
> * doc/extend.texi: Add documentation for vec_insertl, vec_inserth.
Okay for trunk. Thanks!
Segher
ble.c
> @@ -0,0 +1,289 @@
> +/* { dg-do run } */
> +/* { dg-require-effective-target powerpc_future_hw } */
This now is "power10_hw". Similarly, "power10_ok" in other testcases.
> +/* { dg-options "-mdejagnu-cpu=future" } */
And this "-mdejagnu-cpu=power10".
Okay for trunk with those changes. Thanks!
Segher
get/powerpc/prefix-si-constant.c: New test.
> * gcc.target/powerpc/prefix-di-constant.c: New test.
This is okay for trunk (with required changes: -mdejagnu-cpu=power10,
and the selector names have changed to be something with power10 instead
of something with future; please retest before commit).
Thanks!
Segher
ew test.
Okay for trunk (with changes as 2/7). Thanks!
Segher
On Mon, Jun 01, 2020 at 03:53:39PM -0400, Michael Meissner wrote:
> This test makes sure we do not generate a prefixed instruction with an update
> form.
>
> 2020-06-01 Michael Meissner
>
> * gcc.target/powerpc/prefix-no-update.c: New test.
Okay like 2 and 3. Thanks!
Segher
ere are reason you don't have \M on pli, or is that an oversight?
Okay for trunk with that looked at, and the necessary "no future"
changes (and retesting ofc). Thanks!
Segher
c: New test.
> * gcc.target/powerpc/prefix-pcrel-v2df.c: New test.
> * gcc.target/powerpc/prefix-pcrel.h: Include file for new tests.
OKay for trunk like 5. Thank you!
Segher
rotect.c: New test.
> +/* { dg-do compile } */
> +/* { dg-require-effective-target powerpc_prefixed_addr } */
Is this test necessary anymore, does -mcpu=power10 not guarantee that?
Okay for trunk with that looked at. Thanks!
Segher
;
> + return CONST0_RTX (tmode);
> + }
> + }
"must be a constant in the range"... maybe?
Okay for trunk with that considered (and the obvious testsuite changes
from the future->power10 changes). Thanks!
Segher
;> 32) == 0))
> + {
> +/* Value fits in 32-bits */
> +return 1;
> +}
> + else
> +/* Not the expected mode. */
> +return 0;
> +})
I don't think this is the correct test. What you want to see is if the
number in "op" can be converted to an IEEE single-precision number, and
back again, losslessly. (And subnormal SP numbers aren't allowed
either, but NaNs and infinities are).
Rest looks fine. Sorry it took me so long to spot this.
Segher
(eg, POWER10)
Nothing new apparently, but it is spelled "e.g." :-/ Oh well.
Okay for trunk (maybe leave out the comma part). Thanks!
Segher
On Fri, Jun 26, 2020 at 03:52:33AM -0400, Michael Meissner wrote:
> On Thu, Jun 25, 2020 at 06:54:26PM -0500, Segher Boessenkool wrote:
> > On Thu, Jun 25, 2020 at 06:36:51PM -0500, Peter Bergner wrote:
> > > * config/rs6000/rs6000-call.c (cpu_is_info) : New.
> &g
uts generate the proper code. */
> +
> +/* { dg-do compile } */
> +/* { dg-require-effective-target powerpc_p8vector_ok } */
> +/* { dg-options "-mdejagnu-cpu=power8 -O3" } */
This needs to change to power9 as well?
Thanks,
Segher
On Sat, Jun 27, 2020 at 01:50:48AM -0400, Michael Meissner wrote:
> On Thu, Jun 25, 2020 at 12:18:42PM -0500, Segher Boessenkool wrote:
> > > +/* { dg-do compile } */
> > > +/* { dg-require-effective-target powerpc_prefixed_addr } */
> >
> > Is this test necessar
On Sat, Jun 27, 2020 at 01:55:19AM -0400, Michael Meissner wrote:
> On Thu, Jun 25, 2020 at 12:09:41PM -0500, Segher Boessenkool wrote:
> > On Thu, Jun 04, 2020 at 01:03:51PM -0400, Michael Meissner wrote:
> > > +/* { dg-final { scan-assembler-times {\mpaddi\M|\mpli|\mpla\M} 3
On Sat, Jun 27, 2020 at 01:49:23AM -0400, Michael Meissner wrote:
> On Thu, Jun 25, 2020 at 11:52:50AM -0500, Segher Boessenkool wrote:
> > On Mon, Jun 01, 2020 at 03:53:37PM -0400, Michael Meissner wrote:
> > > Add tests for -mcpu=future that test the generation of PADDI (an
2301 - 2400 of 6092 matches
Mail list logo
