etter
and getter of the CC reg both use CCV (so never use any other flag at
the same time; CCV has an empty intersection with all other CC modes).
Segher
that we should not lose, but it does a pretty bad job of CSE.
> Method3: For some record type, use "PARALLEL:BLK" instead "MEM:BLK".
:BLK can never be optimised well. It always has to live in memory, by
definition.
Segher
ld keep them as annotated memcpy calls. This roughly corresponds to
> your second suggestion.
Ideally this won't ever make it as far as RTL, if the structures do not
need to go via memory. All high-level optimissations should have been
done earlier, and hopefully it was not expand tiself that forced stuff
into memory! :-/
Segher
l other
MODE_CC handling, and only works because of that. And a small
modification to the backend, completely elsewhere, can make that house
of cards collapse. It is much more robust to use a different relation,
not EQ, to decribe this. Something with an unspec is fine.
But what the sparc backend does does work.
Segher
Hi!
On Thu, Aug 11, 2022 at 10:11:45AM +0800, HAO CHEN GUI wrote:
> On 11/8/2022 上午 1:38, Segher Boessenkool wrote:
> > On Fri, Jul 22, 2022 at 03:07:55PM +0800, HAO CHEN GUI wrote:
> >> This patch creates a new function - change_pseudo_and_mask. If recog
> >> fails,
; --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr99888-3.c
> @@ -0,0 +1,12 @@
> +/* { dg-require-effective-target powerpc_elfv2 } */
> +/* { dg-options "-fpatchable-function-entry=1" } */
> +
> +/* Verify no errors, using command line option instead of function
> + attribute. */
> +
> +extern int a;
> +
> +int test (int b) {
> + return a + b;
> +}
And more.
Rest looks good, thanks!
Segher
ev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr63281.c
> @@ -0,0 +1,11 @@
> +/* PR target/63281 */
> +/* { dg-do compile { target lp64 } } */
> +/* { dg-options "-O2 -std=c99" } */
Why std=c99 btw? The default is c17. Is there something we need to
disable here?
Segher
Hi!
On Mon, Jun 27, 2022 at 10:47:26AM +0800, Kewen.Lin wrote:
> on 2022/6/25 00:49, Segher Boessenkool wrote:
> Many thanks for all the further explanation above! The attached patch
> updated the misleading comments as you pointed out and suggested, could
> you help to have
st five years before anything works again (for users).
This agrees with what you propose afaics, but let's make this explicit?
It helps us sleep at night :-)
Segher
cal entry point, and N-M after", something like that?
Segher
generated elsewhere in the testcase, and the crux of the
check is that we have to make sure no duplicate happens.
I see no better way forward than to delete this testcase.
Comments? I'll commit this tomorrow.
Segher
2022-08-18 Segher Boessenkool
gcc/testsuite/
PR target/1
e the following?
>
> gcc/
> PR rtl-optimization/105586
> * sched-rgn.cc (save_state_for_fallthru_edge): New function.
> (schedule_region): Use it for all blocks.
That looks perfect, it doesn't say "why" either :-)
Segher
his always. It is default on 64-bit systems, but it is
simpler to just always add it:
/* { dg-additional-options "-mpowerpc64" } */
Or are there subtargets that will error on this?
> +/* { dg-require-effective-target has_arch_ppc64 } */
This is redundant, the previous line makes this always pass.
Segher
t;
> What's your opinion?
I'm not sure what the question is, sorry.
If you want different semantics for ELFv2 (which might well be useful),
we need some new command line option for that.
I suggested here to just describe in the existing doc what is done for
global and local entry points on ELFv2.
Segher
already means
exactly that.
> +(define_insn_and_split "*extendtfif2_internal"
> + [(set (match_operand:IF 0 "gpc_reg_operand" "=d,&d")
> + (float_extend:IF
> + (match_operand:TF 1 "input_operand" "0,d")))]
> + "FLOAT128_IBM_P (TFmode)"
> + "#"
> + "&& reload_completed"
Why would this ever need reload_completed? It is a no-op move!
Segher
ditional branch at all? Unpredictable
conditional branches are extremely costly.
> +/* { dg-require-effective-target lp64 } */
arch_ppc64
> +/* { dg-final { scan-assembler-times "cmpldi" 10 } } */
> +/* { dg-final { scan-assembler-times "cmpdi" 4 } } */
> +/* { dg-final { scan-assembler-times "rotldi" 14 } } */
Please use \m and \M .
Thanks,
Segher
On Wed, Aug 24, 2022 at 03:30:51PM +0800, Kewen.Lin wrote:
> on 2022/8/23 22:33, Segher Boessenkool wrote:
> I thought if we can consider [1] and updated the documentation similarly
> like "For PowerPC with the ELFv2 ABI, there will be M nops before the global
> entry point,
On Wed, Aug 24, 2022 at 03:48:49PM +0800, Jiufu Guo wrote:
> Segher Boessenkool writes:
> >> + "TARGET_POWERPC64 && !reload_completed && can_create_pseudo_p ()
> >
> > reload_completed in splitters is almost always wrong. It isn't
Hi!
On Thu, Aug 25, 2022 at 08:11:31PM +0800, Jiufu Guo wrote:
> Segher Boessenkool writes:
> > You usually can split fine if you cannot create new pseudos, by reusing
> > existing registers.
> >
> > FAIL will cause an ICE: the RTL instruction does match, but w
On Wed, Aug 24, 2022 at 01:11:39PM +0800, HAO CHEN GUI wrote:
> On 23/8/2022 下午 10:26, Segher Boessenkool wrote:
> > On Fri, Aug 19, 2022 at 10:35:54AM +0800, HAO CHEN GUI wrote:
> >> --- a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-exp-0.c
> >> +++ b/gcc/tests
ld
> have been allowed.
Such conversions are explicitly allowed in C, even (6.3.2.3/7).
> The fix is to just remove the MMA pointer conversion
> handling code altogether.
Okay for trunk and all backports. Thanks!
Segher
of interest, did you see failures from this, was
it just by visual inspection, something else?
Thanks,
Segher
s testcase, both
-m32 -mno-powerpc64 and -m32 -mpowerpc64 are ilp32.
Segher
any source code is the humans who read it,
and humans read code top down.
Segher
On Wed, Aug 31, 2022 at 10:48:26AM -0500, Peter Bergner wrote:
> On 8/31/22 10:24 AM, Segher Boessenkool wrote:
> > Should *any* explicit command line flag ever be disabled like that?
> > (Not talking about things like -m32 -m64, ...
>
> In a general sense, I'd agree tha
On Wed, Aug 31, 2022 at 12:00:14PM -0500, Peter Bergner wrote:
> On 8/31/22 11:05 AM, Segher Boessenkool wrote:
> > On Wed, Aug 31, 2022 at 10:48:26AM -0500, Peter Bergner wrote:
> >> Ditto for -msoft-float better disable any -maltivec and -mvsx, etc.
> >
> > Oh? W
ector_pair_type_node;
If you split a?b:c over multiple lines, please make it three lines.
Segher
On Wed, Aug 31, 2022 at 02:53:07PM -0500, Peter Bergner wrote:
> On 8/31/22 2:28 PM, Segher Boessenkool wrote:
> > On Wed, Aug 31, 2022 at 12:00:14PM -0500, Peter Bergner wrote:
> Right, but haven't the 64-bit Linux kernels been fixed forever to always
> save/restore the
On Wed, Aug 31, 2022 at 04:38:02PM -0500, Peter Bergner wrote:
> On 8/31/22 4:07 PM, Segher Boessenkool wrote:
> > On Wed, Aug 31, 2022 at 02:53:07PM -0500, Peter Bergner wrote:
> >> Changing OS_MISSING_POWERPC64 as I mentioned would not add
> >> OPTION_MASK_POWERPC64
debugging code. Or this truly should never
happen in LTO?
Segher
he pointer type being used.
Okay for trunk and all backports (after it has survived a breath of
fresh air). Thanks!
Segher
On Thu, Sep 01, 2022 at 04:28:56PM +0800, Kewen.Lin wrote:
> tree.def has some note about VIEW_CONVERT_EXPR, it quite matches what Segher
> replied.
> In my experience, VIEW_CONVERT_EXPR are used a lot for vector type conversion.
It is needed whenever vector types are not compatible
apparently we have a bug here, which will
make what you did malfunction in some cases -- the test will not run for
ilp32 if you have RUNTESTFLAGS {-m32,-m64}.
It should not make a difference, -mpowerpc64 and -m32 should be wholly
independent, and their order should not matter. So the order of the
/* { dg-require-effective-target ilp32 } */
/* { dg-options "-O2 -mpowerpc64" } */
lines should not make a difference either. But it does :-(
Segher
ne options "-mno-powerpc64 -m64" not
> raise error, but I think having it to error makes more senses.
Agreed.
> btw, I guess the option compatibility isn't an blocking issue
> here, right?
We have survived for years with the status quo, nothing changed recently
that makes it more urgent to fix this.
Segher
ite/gcc.target/powerpc/pr93453-1.c
> +++ b/gcc/testsuite/gcc.target/powerpc/pr93453-1.c
> @@ -1,5 +1,6 @@
> -/* { dg-do compile { target has_arch_ppc64 } } */
> +/* { dg-do compile } */
> /* { dg-options "-mdejagnu-cpu=power6 -O2" } */
> +/* { dg-require-effective-target has_arch_ppc64 } */
This is fine, but it doesn't change anything, unless we have a bug.
Segher
nal { scan-assembler-times {(?n)^\s+[a-z]} 9 } } */
Also test the expected insns separately please? The std's (just with
\mstd so it will catch all variations as well), the blr, the pli's and
the rldimi etc.?
We also should test all special cases as well. Especially those that do
not happen all over the place, we will notice something is broken there
easy enough. But unlikely cases can take years to show up.
Okay for trunk with the formatting fixed. Thank you!
Segher
r for multi-insn constant loads): Ditto.
You should mention the changed to *both* splitters. For nameless
splitters it helps if you can describe it a bit. This is hard, yes :-/
Okay for trunk like that. Thanks!
Segher
itter checks `const_scalar_int_operand`, this one is never
> used now.
> Now, HOST_BITS_PER_WIDE_INT is forced to 64, this splitter is safe
> to remove.
Okay for trunk. Thanks!
Segher
/* { dg-do run { target { powerpc*-*-linux* } } } */
> /* { dg-options "-mdejagnu-cpu=power9" } */
> +/* { dg-require-effective-target has_arch_ppc64 } */
> +/* { dg-require-effective-target p9vector_hw } */
Nothing in gcc.target/powerpc has to check for powerpc*-*-* at all. If
you want to test for linux (you shouldn't here afaics?), that is just
*-*-linux* .
Segher
n-assembler-times {(?n)^\s+[a-z]} 9 } } */
> >
> > Also test the expected insns separately please? The std's (just with
> > \mstd so it will catch all variations as well), the blr, the pli's and
> > the rldimi etc.?
> The reason of using "(?n)^\s+[a-z]" is to keep this test case pass no
> matter the splitter running before or after RA.
Ah. Some short comment in the testcase please?
Thanks again,
Segher
On Fri, Sep 02, 2022 at 10:29:35AM -0500, Peter Bergner wrote:
> On 9/1/22 4:52 PM, Segher Boessenkool wrote:
> > On Thu, Sep 01, 2022 at 11:24:00AM +0800, Jiufu Guo wrote:
> >> As mentioned in PR106550, since pli could support 34bits immediate, we
> >> could
>
Or maybe we do to make other potential backports
> easier?
> I'm fine either way.
I wouldn't worry about backports. If it does make other backports
easier in the future, we can decide to backport this *then*.
Okay for trunk. Thanks!
(Did you also look at non-MMA VIEW_CONVERT_EXPR uses btw?)
Segher
On Fri, Sep 02, 2022 at 12:02:54PM -0500, Peter Bergner wrote:
> On 9/2/22 11:31 AM, Segher Boessenkool wrote:
> > (Did you also look at non-MMA VIEW_CONVERT_EXPR uses btw?)
>
> I did. It seemed they were all related to pointers to vectors and I remember
> you mentioning
On Fri, Sep 02, 2022 at 08:50:52AM +0800, Kewen.Lin wrote:
> on 2022/9/1 22:57, Segher Boessenkool wrote:
> > These two are independent, but apparently we have a bug here, which will
> > make what you did malfunction in some cases -- the test will not run for
> > ilp32 if
On Fri, Sep 02, 2022 at 08:51:01AM +0800, Kewen.Lin wrote:
> on 2022/9/1 23:04, Segher Boessenkool wrote:
> > On Thu, Sep 01, 2022 at 05:05:44PM +0800, Kewen.Lin wrote:
> >> Without any explicit -mpowerpc64 (and -mno-), I think we all agree
> >> that -m64 should set OP
Hi!
On Fri, Sep 02, 2022 at 11:43:28AM +0800, HAO CHEN GUI wrote:
> On 2/9/2022 上午 12:07, Segher Boessenkool wrote:
> >> +/* { dg-do compile { target { ! has_arch_pwr9 } } } */
> > Please keep dg-do first thing in the file.
> Could you inform me if it's a must to put dg
est :-)
The changes / additions we agreed to are preapproved btw. But please
post the thing you eventually commit to the mailing list :-)
Segher
ffective_target_ppc_float128): Likewise.
> (check_effective_target_ppc_float128_insns): Likewise.
> (check_effective_target_powerpc_vsx): Likewise.
Sorry, I thought you had committed this already. Oops.
Okay for trunk, and for all backports you want. Thanks!
Segher
On Mon, Sep 05, 2022 at 11:25:21AM +0200, Richard Biener wrote:
> On Fri, Sep 2, 2022 at 7:24 PM Segher Boessenkool
> wrote:
> > On Fri, Sep 02, 2022 at 12:02:54PM -0500, Peter Bergner wrote:
> > > On 9/2/22 11:31 AM, Segher Boessenkool wrote:
> > > &
t has the output
register as one of the input registers as well. "Good" to see not just
the compiler has problems with this, but humans do as well! ;-)
Otherwise looks good to me. Okay for trunk with that fixed somehow.
Thanks!
Segher
Hi!
On Mon, Sep 05, 2022 at 02:36:30PM +0800, HAO CHEN GUI wrote:
> On 2/9/2022 下午 11:56, Segher Boessenkool wrote:
> >> - const signed long __builtin_vsx_scalar_extract_exp (double);
> >> + const unsigned long long __builtin_vsx_scalar_extract_exp (double);
>
On Fri, Sep 02, 2022 at 01:51:33PM -0400, Michael Meissner wrote:
> On Tue, Aug 23, 2022 at 04:13:45PM -0500, Segher Boessenkool wrote:
> > Please do not send new patches as replies to other patches.
>
> This was sent as a new patch.
It probably was the partially copied to the ma
Hi!
On Wed, Sep 07, 2022 at 08:51:17AM -0500, Paul A. Clarke wrote:
> On Tue, Sep 06, 2022 at 12:19:06PM -0500, Segher Boessenkool wrote:
> > On Mon, Sep 05, 2022 at 02:36:30PM +0800, HAO CHEN GUI wrote:
> > > The return type of vec_ version built-ins are different than their
On Wed, Sep 07, 2022 at 04:25:49PM -0400, Michael Meissner wrote:
> On Tue, Sep 06, 2022 at 05:22:11PM -0500, Segher Boessenkool wrote:
> > Please do this. It is the biggest problem I have with most of your
> > patches: you seem to save up development of a week, and then send it
uiltin infrastructure rewrite broke it. And if so, what
we should do now? The argument for not deleting these legacy builtins
is that someone might use them, but that seems unlikely since it has
been utterly broken for a while now, and no one has complained.
Segher
uad to be
> used as actual arguments to non-builtin functions. We do allow
> pointers to those types though.
It would be nice to support that, if it isn't too hard. It won't be
digging us into a hole, experience has taught us :-)
Segher
OST_WIDE_INT *offset,
> HOST_WIDE_INT *size)
> {
>rtx addr_rtx;
> - if (MEM_SIZE_KNOWN_P (mem))
> + if MEM_SIZE_KNOWN_P (mem)
> *size = MEM_SIZE (mem);
>else
> return false;
This patch is generated backwards.
I committed the following.
y handle subregs of memory here? Those are antiquated, and should go
away pretty soon.
All of {expand,make}_compound_operation should be removed. But this is
non-trivial work. All of {SIGN,ZERO}_EXTRACT should be eradicated as
well, in my opinion.
Segher
On Mon, Sep 12, 2022 at 11:47:47AM -0500, Segher Boessenkool wrote:
> On Mon, Sep 12, 2022 at 12:40:31AM +0100, Roger Sayle wrote:
> > * gcc/combine.cc (expand_compound_operation): Don't expand/transform
> > ZERO_EXTEND or SIGN_EXTEND on targets where rtx_
For PR103623 I fixed unpack, but pack is broken as well, as reported in
PR105334. Fixing that is a bit more code, but it is pretty simple code
nonetheless.
Committing to trunk.
Segher
2022-04-22 Segher Boessenkool
PR target/105334
* config/rs6000/rs6000.md (pack for
Tested on powerpc64-linux {-m32,-m64}. Also manually checked the
gcc.log; it did the wrong thing before, it does the right thing now.
Committing.
Segher
2022-04-26 Segher Boessenkoool
gcc/testsuite/
PR target/105349
* lib/target-supports.exp
ables both tests to
> pass.
This is not okay, sorry. The testcase uses _Float128, what code that
generates should not depend on your long double setting. Please file
a PR instead?
Segher
gt; >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.target/powerpc/pr105271.c: New test.
>
> I'd like to ping this patch, one of the last few remaining P1s we have for
> GCC 12.
Heh. I approved it this morning (off-list). Kewen will commit it
soonish (somewhere during your night probably) :-)
Segher
targetm.calls.split_complex_arg && type
No space after "!" (or any other unary operator not written with
letters).
> + && TREE_CODE (type) == COMPLEX_TYPE && elt_mode == KCmode)
> + cum->vregno++;
> +
With those trivialities fixed, okay for trunk. Thanks!
Segher
Hi!
Thank you for doing this testcase.
On Wed, Apr 27, 2022 at 06:29:07PM +0800, Kewen.Lin wrote:
> As discussed in PR105334, this patch is to add the test coverage for
> the two recent fixes r12-8091 and r12-8226 from Segher, aix is skipped
> since it takes soft-float and long-d
messages, one for
double, one for 64-bit long double.
Okay for trunk without this part of the patch, and the spaces after the
hash signs deleted. Or send a new patch with the "[long] double" thing
fixed?
Thanks!
Segher
was undefined (and did not work):
error: use of 'double' in AltiVec types is invalid without '-mvsx'
Segher
Hi!
On Thu, Apr 28, 2022 at 10:53:40PM -0300, Alexandre Oliva wrote:
> On Apr 28, 2022, Segher Boessenkool wrote:
> > On Thu, Apr 28, 2022 at 03:09:54AM -0300, Alexandre Oliva wrote:
> >> +"no __intrinsic_type support for [long] double on PPC w/o
> >>
e exception, and convert to the qNaN.
There is no sane way you can raise the exception manually, so you should
make sure we end up with a real operation in the RTL, and then generate
proper machine code for it as well. See rs6000 extendsfdf2 for example,
for that last part.
And of course both the gimple min_expr and the RTL smin are not defined
for NaN inputs at all anyway :-P
Segher
those ought to narrow to a mem anyway.)
Or we can simply threaten to drop all unconverted targets. That way at
least there is a *chance* (a slim chance, but still) that the conversion
will ever be finished.
Paradoxical subregs of memory are already not allowed on targets with
instruction scheduling, btw.
Segher
On Thu, May 05, 2022 at 03:52:01AM -0300, Alexandre Oliva wrote:
> The testcase for pr100106, compiled with optimization for 32-bit
> powerpc -mcpu=604 with -mstrict-align expands the initialization of a
> union from a float _Complex value into a load from an SCmode
> constant pool entry, aligned t
h me. A bare LIKELY isn't though. We have much
more common macros having LIKELY in the name already (PROB_*LIKELY,
CLASS_LIKELY_SPILLED, the various IPA things, loop versioning, etc.),
but also we have LIKELY and UNLIKELY as function arguments in various
places.
Segher
ted WarnRemoved
i.e. just like all other removed flags. If someone explicitly tries to
enable it he/she *should* get a warning.
> mpower8-fusion-sign
> -Target Undocumented Mask(P8_FUSION_SIGN) Var(rs6000_isa_flags)
> -Allow sign extension in fusion operations.
> +Target Undocumented Ignore
And this one should be completely removed, since no one ever used it.
Segher
2059#c31
Just an unconditional
callee_isa &= ~OPTION_MASK_P8_FUSION;
explicit_isa &= ~OPTION_MASK_P8_FUSION;
will do, no? That is fine since these options should never have been
used to determine if anything can be inlined, in the first place.
A patch like that is pre-approved, even for trunk.
Thanks,
Segher
On Thu, May 05, 2022 at 02:59:07PM -0500, Peter Bergner wrote:
> On 5/5/22 2:35 PM, Segher Boessenkool wrote:
> > On Thu, May 05, 2022 at 01:59:05PM -0500, Peter Bergner wrote:
> >> If we cannot get this in soonish, maybe we can at least get approval for
> >> applying
On Thu, May 05, 2022 at 04:21:21PM -0400, Michael Meissner wrote:
> On Thu, May 05, 2022 at 02:12:43PM -0500, Segher Boessenkool wrote:
> > On Tue, Apr 12, 2022 at 09:14:55PM -0400, Michael Meissner wrote:
> > > This is V4 of the patch. Compared to V3 of the patch, GCC will ju
On Mon, May 02, 2022 at 11:00:02PM -0300, Alexandre Oliva wrote:
> On May 2, 2022, Segher Boessenkool wrote:
> > Send full patches always please.
>
> I'll try to remember that. In case I fail, I hope you won't mind too
> much reminding me.
>
> (You'
compile } */
This is the default, you can leave it out if you want.
Okay for trunk with or without it. Thanks!
Segher
use the same units and have the
> same latency,
> no benefits to replace with xs{min,max}cdp.
I never understood any of this. Mike? Why do we do those "c" things
at all, ever?
> So I wonder if it would be more clear with:
> 1) add new define_insn for xs{min,max}dp
No, the existing thing should always do these insns.
> 2) use them for new define_expand of fmin/fmax
> 3) use them for bif expansion pattern
There is no way to express fmin/fmax without unspecs currently (without
fastmath). This is a serious problem.
Segher
The example missed the mode condition in the replacement text.
Committed as obvious.
Segher
2022-05-10 Segher Boessenkool
* doc/md.texi (Defining Mode Iterators): Correct example replacement
text.
---
gcc/doc/md.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion
On Tue, May 10, 2022 at 02:56:58PM -0400, Michael Meissner wrote:
> On Tue, May 10, 2022 at 07:27:30AM -0500, Segher Boessenkool wrote:
> > > IMHO, it's something we want to fix as well, based on the reasons:
> > > 1) bif names have the corresponding mnemoni
V16QI 1 "vsx_register_operand" "v,v,?d,?d")
> + (match_operand:V16QI 2 "vsx_register_operand" "v,?d,v,?d")]
This is more involved than just replacing one constrait with two. You
shoould say that in the changelog (and in your message).
Out of interest, did you try using v,?wa (so just two alternatives, not
four)? Or did you think it wouldresult in measurably worse code? Or
did you decide it is not such bad backend code size explosion after
all :-)
Okay for trunk with a slightly better changelog. Thanks!
Segher
Hi~
On Wed, May 11, 2022 at 04:53:08PM +0800, Kewen.Lin wrote:
> on 2022/5/10 20:27, Segher Boessenkool wrote:
> > Yes. RTL iterators and attributes are textual replacement and expansion
> > only: there is no deeper semantic meaning to it. In fact, we should
> > have onl
ince it
always is "wa", and it simplifies things nicely now that we can also
delete .
Tested on powerpc64-linux {-m32,-m64}. Committing to trunk.
Segher
Segher Boessenkool (3):
rs6000: Delete RS6000_CONSTRAINT_f
rs6000: Remove
rs6000: Remove
gcc/config/rs6000/constraints.
Constraint "f" is always exactly the same as constraint "d", so we do
not need RS6000_CONSTRAINT_f.
2022-05-11 Segher Boessenkool
* config/rs6000/constraints.md (register_constraint "f"): Use
RS6000_CONSTRAINT_d.
* config/rs6000/rs6000.cc
The mode iterator can just use "d" always.
2022-05-11 Segher Boessenkool
* config/rs6000/rs6000.md: Use d instead of .
---
gcc/config/rs6000/rs6000.md | 117 +---
1 file changed, 57 insertions(+), 60 deletions(-)
diff --git a/
The mode iterator always expands to "wa".
2022-05-11 Segher Boessenkool
* config/rs6000/rs6000.md: Use wa instead of .
---
gcc/config/rs6000/rs6000.md | 98 +
1 file changed, 46 insertions(+), 52 deletions(-)
diff --git a/
[ have_feenableexcept="yes" ],
> +[ have_feenableexcept="no" ])])
Please get rid of all surplus whitespace here. Imitate existing tests,
if you need inspiration :-)
Segher
Hi!
On Mon, Apr 18, 2022 at 12:15:35PM -0500, Paul A. Clarke wrote:
> A few tests need not be restricted to 'lp64', so remove the restriction.
>
> A few of those need a simple change to the DejaGnu directives to suppress
> '-mcmodel' flags for '-m32'.
Okay for trunk. Thanks!
Segher
lousy reason, and
not a good precedent to create. It is much better to let the Darwin
maintainer deal with this *if* it fails. If you have proof it fails on
Darwin, just say *that* (or even say *why* it fails!)
Other than that this looks good.
Segher
On Fri, May 13, 2022 at 12:34:05PM +0200, Piotr Kubaj wrote:
> On 22-05-13 10:59:59, Kewen.Lin wrote:
> > on 2022/5/13 04:16, Segher Boessenkool wrote:
> > > On Tue, May 03, 2022 at 12:21:12PM +0200, pku...@freebsd.org wrote:
> > >> FreeBSD/powerpc* has feenableexc
that reason isn't obvious, make a short note in the
testcase itself:
/* { dg-do compile { target lp64 } } */
/* This requires lp64 because of XYZ. */
or similar).
So please add that TARGET_POWERPC64 and remove the lp64 from the
testcase. Oh and the pattern name. Looks perfect to me then. Thanks,
Segher
x27;s not necessary to explain everything, but
giving some leads to whoever gets to investigate this testcase next is
useful :-)
Segher
ble at all.
Segher
ment still relevant? If so a bit more rephrasing woukd be
good; if not, just remove it?
Okay for trunk with those things dealt with somehow. Thanks!
Segher
On Mon, May 16, 2022 at 05:31:31PM -0500, Peter Bergner wrote:
> On 5/10/22 5:35 PM, Segher Boessenkool wrote:
> > Out of interest, did you try using v,?wa (so just two alternatives, not
> > four)? Or did you think it wouldresult in measurably worse code? Or
> > did you
compiler does, and they are used all
over the place (the gcc/ dir has some thousand mentions of it for
example).
Please don't make life hard for everyone by overloading this term.
Segher
On Wed, May 18, 2022 at 04:24:06PM -0400, Andrew MacLeod wrote:
> On 5/18/22 14:13, Segher Boessenkool wrote:
> >"Side effect" already has a meaning, very commonly used in language
> >theory, and even in the C standard itself: a function has a side effect
> >if i
On Thu, May 19, 2022 at 09:22:32AM -0400, Andrew MacLeod wrote:
> On 5/18/22 16:40, Segher Boessenkool wrote:
> >On Wed, May 18, 2022 at 04:24:06PM -0400, Andrew MacLeod wrote:
> >>On 5/18/22 14:13, Segher Boessenkool wrote:
> >>>"Side effect" already has a
; GCC might be called like 'deduce_ranges_from_stmt'.
>
> Or "infer", "inference", "inferring a range".
"Infer" is great here, yes!
infer (verb):
deduce or conclude (something) from evidence and reasoning rather than
from explicit statements
It has exactly the connotation wanted here, I would say.
Segher
701 - 800 of 6132 matches
Mail list logo
