ar normal operation).
>From Power4 on already (not sure about Power6, but does anyone care?)
Segher
On Tue, Sep 01, 2020 at 04:09:53PM +0800, luoxhu wrote:
> On 2020/9/1 01:04, Segher Boessenkool wrote:
> > For v a V4SI, x a SI, j some int, what do we generate for
> >v[j&3] = x;
> > ?
> > This should be exactly the same as we generate for
> >vec_ins
(It is a pretty common problem in testcases; another
trick is to put asm(""); at the end of a function).
Okay for backporting. Thanks!
Segher
l showed no regressions either. Ok for trunk and GCC 10 after
> a couple of days of burn in?
Okay for both. Thanks!
Segher
sn't seem that important in the grand scheme of things, but
> there is some embarrassment from the missed combines and from the AFAICT
> impossibility to get GCC to issue the most compact (and possibly
> fastest) insn sequence on x86* for a 'memory += value;' spelled as
> __builtin_add_overflow, when the result of the overflow checking is
> used.
GCC does not handle RMW to memory very well (partially because it
*cannot* really be handled well). There are some PRs about this I
think (at least wrt combine).
Segher
_type_node,
> + 2);
Can't you just use long_long_integer_type_node in all cases? Or, what
else is intDI_type_node for 32 bit?
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr96139-a.c
> @@ -0,0 +1,32 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -Wall -m32 " } */
(trailing space, here and elsewhere -- not that it matters of course)
Segher
Hi!
On Wed, Sep 02, 2020 at 11:16:00AM +0800, Kewen.Lin wrote:
> on 2020/9/1 上午3:41, Segher Boessenkool wrote:
> > On Tue, Aug 25, 2020 at 08:46:55PM +0800, Kewen.Lin wrote:
> >> 1) Currently address_cost hook on rs6000 always return zero, but at least
> >> from P
): Remove.
> +/* { dg-final { scan-assembler-times {\mstd\M} 2 { xfail { { {!
> has_arch_pwr9} && has_arch_pwr8 } && be } } } } */
Not sure you need all braces here. But this isn't pure tcl, some of it
is parsed by routines in dejagnu (which allow much less), so who knows.
Okay for trunk. Thanks!
Segher
On Thu, Sep 03, 2020 at 07:03:53AM -0300, Alexandre Oliva wrote:
> On Sep 2, 2020, Segher Boessenkool wrote:
> > (And aarch, but not the other targets with default clobbers).
>
> And arm. I didn't look very hard for others yet; I wasn't sure it would
> be worth
Hi!
On Thu, Sep 03, 2020 at 10:37:33AM -0500, will schmidt wrote:
> On Wed, 2020-09-02 at 05:13 -0500, Segher Boessenkool wrote:
> > On Tue, Sep 01, 2020 at 09:00:20PM -0500, will schmidt wrote:
> > > This corrects an issue with the powerpc vector long long
> > > sub
On Thu, Sep 03, 2020 at 02:07:24PM -0300, Alexandre Oliva wrote:
> On Sep 3, 2020, Segher Boessenkool wrote:
> > On Thu, Sep 03, 2020 at 07:03:53AM -0300, Alexandre Oliva wrote:
> >> On Sep 2, 2020, Segher Boessenkool wrote:
> >> >> we might succeed, but only
On Thu, Sep 03, 2020 at 02:17:04PM -0300, Alexandre Oliva wrote:
> On Sep 3, 2020, Segher Boessenkool wrote:
> > Oh, I meant what was in your patch. From a grep, all of mn10300, nds32,
> > arm, cris, pdp11, rs6000, i386, visium, aarch64 have default clobbers.
> > Hrm,
On Thu, Sep 03, 2020 at 10:24:21AM +0800, Kewen.Lin wrote:
> on 2020/9/2 下午6:25, Segher Boessenkool wrote:
> > On Wed, Sep 02, 2020 at 11:16:00AM +0800, Kewen.Lin wrote:
> >> on 2020/9/1 上午3:41, Segher Boessenkool wrote:
> >>> On Tue, Aug 25, 2020 at 08:46:55PM +0
Hi!
On Fri, Sep 04, 2020 at 08:55:43AM +0200, Richard Biener wrote:
> On Thu, Sep 3, 2020 at 8:10 PM Segher Boessenkool
> wrote:
> > On Thu, Sep 03, 2020 at 10:37:33AM -0500, will schmidt wrote:
> > > On Wed, 2020-09-02 at 05:13 -0500, Segher Boessenkool wrote:
> > >
l,
> SET_EXPR_LOCATION (stmt, loc);
> stmt = build1 (COMPOUND_LITERAL_EXPR, arg1_type, stmt);
> }
> -
> - innerptrtype = build_pointer_type (arg1_inner_type);
> -
> - stmt = build_unary_op (loc, ADDR_EXPR, stmt, 0);
> - stmt = convert (innerptrtype, stmt);
> - stmt = build_binary_op (loc, PLUS_EXPR, stmt, arg2, 1);
> - stmt = build_indirect_ref (loc, stmt, RO_NULL);
> - stmt = build2 (MODIFY_EXPR, TREE_TYPE (stmt), stmt,
> -convert (TREE_TYPE (stmt), arg0));
> + stmt = build_array_ref (loc, stmt, arg2);
> + stmt = fold_build2 (MODIFY_EXPR, TREE_TYPE (arg0), stmt, arg0);
>stmt = build2 (COMPOUND_EXPR, arg1_type, stmt, decl);
>return stmt;
> }
You should make a copy of the vector, not modify the original one in
place? (If I read that correctly, heh.) Looks good otherwise.
Segher
Hi Bin,
On Fri, Sep 04, 2020 at 04:27:32PM +0800, Bin.Cheng wrote:
> On Fri, Sep 4, 2020 at 6:37 AM Segher Boessenkool
> wrote:
> > It should have cost, certainly, but not address_cost I think. The total
> > cost of an ldu should be a tiny bit less than that of ld + tha
date form memory insns either. What happens
is simply that no shorter latency insns are issued by the core so long
as longer latency insns (like most float insns) are available. So in
really nice floating point loops we execute the few integer add insns
much too late, much later than they were in the machine code, which then
makes the memory insns late as well, etc.
Segher
s in combine itself (not in
recog)? In combine we know that there are at most 4 sets (and usually
at most 3), and we also often have a good idea what swaps are likely
to work and which not, so maybe trying just one extra thing will have
good results already.
Segher
On Thu, Sep 03, 2020 at 04:46:43PM -0300, Alexandre Oliva wrote:
> On Sep 3, 2020, Segher Boessenkool wrote:
> > The idea is that none of them will need adjustment. This hook runs
> > before the "none" code will run, and it can just clear all clobbers
> > then.
pilogue, you also need to make sure it is
done on every path that returns *without* epilogue.
Segher
On Mon, Aug 24, 2020 at 03:43:11PM -0500, Qing Zhao wrote:
> > On Aug 24, 2020, at 3:20 PM, Segher Boessenkool
> > wrote:
> >> For this testing? (Is CPU2017 good enough)?
> >
> > I would use something more real-life, not 12 small pieces of code.
>
> The
these benchmarks are kind of a "worst case" scenario
> with regard to performance, yes? As in it's mostly tight call loops?)
I call this very expensive, already, and it is benchmarked on a target
where this should be very cheap (it has few registers) :-/
Segher
in principle we don't need a libc to test the
> builtins, but I thought I would ended up reimplementing the builtins
> themselves and other fenv.h functions (with chances of getting them
> wrong), and that doing the test comparing against the standard library
> implementation would be more robust. Should I change it?
I don't know, that's why I asked :-) We'll just have to try it out.
Thanks,
Segher
inimize the runtime overhead.
There also is a real cost to the compiler *developers*. Which is my
prime worry here. If this gives users at most marginal value, then it
is real cost to us, but nothing to hold up to that.
Segher
feature is designed for normal return with epilogue.
Very many normal returns do *not* pass through an epilogue, but are
simple_return. Disabling that is *much* more expensive than that 2%.
Segher
On Fri, Sep 04, 2020 at 11:52:13AM -0700, H.J. Lu wrote:
> On Fri, Sep 4, 2020 at 11:09 AM Segher Boessenkool
> wrote:
> > On Fri, Sep 04, 2020 at 10:34:23AM -0700, H.J. Lu wrote:
> > > > You probably have to do this for every target separately? But it is not
> >
; There also is a real cost to the compiler *developers*. Which is my
> > prime worry here. If this gives users at most marginal value, then it
> > is real cost to us, but nothing to hold up to that.
>
> Here, you mean the future maintenance cost for this part of the code?
Not just that. *All* support costs, and consider all other
optimisations it will interfere with, etc.
Segher
ead is of course bearable for most programs / users, but what
is the return? For what percentage of programs are ROP attacks no
longer possible, for example.
Segher
);
> + }
Hrm, I guess we should make that a parameterized name (future work,
don't do it now :-) )
> +(define_expand "absolute_tablejumpsi"
Don't prefix names; it should start with "tablejump".
Segher
ct with that code (mostly in varasm.c), so don't use the same name
meaning something else?
You need an RTL maintainer or global maintainer to review this...
Segher
Hi!
Sorry this took so long to come back to...
On Tue, Aug 25, 2020 at 02:39:56PM -0600, Jeff Law wrote:
> On Fri, 2020-08-07 at 21:51 +0000, Segher Boessenkool wrote:
> > When the compgotos pass copies the tail of blocks ending in an indirect
> > jump, there is a micro-optimizat
ot often win.
I.e.: it needs to be measured. Intuition is often wrong here.
Segher
On Wed, Sep 09, 2020 at 04:28:19PM +0200, Richard Biener wrote:
> On Wed, Sep 9, 2020 at 3:49 PM Segher Boessenkool
> wrote:
> >
> > Hi!
> >
> > On Tue, Sep 08, 2020 at 10:26:51AM +0200, Richard Biener wrote:
> > > Hmm, yeah - I guess that's what sho
();
> }
> - [(set_attr "type" "vecperm")])
> + [(set_attr "type" "vecperm,vecmove")])
mtvsrdd is a mtvsr, sorry, mffgpr just the same? It isn't vecmove?
> @@ -4440,7 +4440,7 @@ (define_insn "vsx_splat__reg"
>"@
> xxpermdi %x0,%x1,%x1,0
> mtvsrdd %x0,%1,%1"
> - [(set_attr "type" "vecperm")])
> + [(set_attr "type" "vecperm,vecmove")])
Same here.
Segher
On Wed, Sep 09, 2020 at 05:30:33PM -0500, Pat Haugen wrote:
> On 9/9/20 4:41 PM, Segher Boessenkool wrote:
> > On Wed, Sep 09, 2020 at 04:14:37PM -0500, Pat Haugen wrote:
> > Can we rename mftgpr/mffgpr globally? Maybe even as mfvsr and mtvsr,
> > because that is what is
were seeing is DSE (of all things!) tries to extract a DImode
from a POImode (and expects that insn to exist!) That is no good.
Segher
e good, yes.
Segher
nd" "=v")
(subreg:VEC_I128
(vec_select:V2DI
(match_operand:V2DI 1 "vsx_register_operand" "v")
(parallel [(const_int 1) (const_int 0)]))
0))]
or similar (i.e., just cast it to the type you want -- in hardware, all
vectors are just an opaque 128 bits, but in RTL they have a type).
(You probably want to cast operands[1] as well).
Segher
return type
> to bool.
> (rs6000_emit_int_cmove): Change return type to bool.
Okay for trunk. Thanks!
Segher
)
Without naming each thing twice, even.
Segher
instructions. */
Just write the actual mnemonics please.
Okay for trunk with those things fixed. Thanks!
Segher
other mode attributes (Ff, Fv) used for setting constraints
> based on the mode.
Yes, and those are unnecessarily cryptic as well! Not to mention this
Studly Case thing ;-)
Segher
")
> + (fp_minmax:FSCALAR
> + (match_operand:FSCALAR 1 "vsx_register_operand" "")
> + (match_operand:FSCALAR 2 "vsx_register_operand" "")))]
> "TARGET_VSX && TARGET_HARD_FLOAT"
> {
> + if (FLOAT128_IEEE_P (mode))
> +return "xscqp %0,%1,%2";
Nope. Since you need to handle this with completely separate code
anyway, just make it a separate instruction pattern please. And there
is no need for a define_expand for it, so you can just leave that one
intact as-is.
Segher
bout does not
let us progress in one way or the other.
Segher
On Tue, Sep 08, 2020 at 11:43:30AM -0500, Qing Zhao wrote:
> > On Sep 7, 2020, at 10:58 AM, H.J. Lu wrote:
> > On Mon, Sep 7, 2020 at 7:06 AM Segher Boessenkool
> > mailto:seg...@kernel.crashing.org>> wrote:
> >> On Fri, Sep 04, 2020 at 11:52:13AM -0700, H.J. Lu
On Fri, Sep 11, 2020 at 08:07:39AM +0200, Richard Biener wrote:
> On Thu, Sep 10, 2020 at 5:12 PM Segher Boessenkool
> wrote:
> > On Thu, Sep 10, 2020 at 04:33:30PM +0200, Richard Biener wrote:
> > > On Thu, Sep 10, 2020 at 4:22 PM Aaron Sawdey
> > > wrote:
> &g
vial, but it is hard
to tell.
Segher
ry (sub-)target-specific, it cannot be done by generic
code on its own *at all*.
Segher
aningless. It only holds meaning for a
function calling another, and then only to know which registers lose
their value then. It has no semantics for other cases, like a function
that will return soonish, as here.
Segher
e also is separate shrink-wrapping, which you haven't touched on at
all yet. Joy.
Segher
@
> /* { dg-do run } */
> -/* { dg-options "-O2 -Wall" } */
> +/* { dg-options "-O2 -Wall -maltivec" } */
> /* { dg-require-effective-target powerpc_altivec_ok } */
But this one as well, why does it not need VSX like the rest?
Segher
On Fri, Sep 11, 2020 at 06:32:56PM +0100, Richard Sandiford wrote:
> Unlike Segher, I think this can/should be done in target-independent
> code as far as possible (like the patch seemed to do).
My problem with that is that it is both incorrect *and* inefficient. It
writes registers it
On Fri, Sep 11, 2020 at 02:40:06PM -0500, Qing Zhao wrote:
> > On Sep 11, 2020, at 12:13 PM, Segher Boessenkool
> > wrote:
> > On Fri, Sep 11, 2020 at 11:52:29AM -0500, Qing Zhao wrote:
> >> I don’t understand why it’s not correct if we clearing call-clobbered
y of non-vector instructions
> (lis,ori,std,addi,... bl..). So it simply does not need the vsx
> support.
Ah, this testcase will not actually use vectors at all. It just needs
-maltivec for altivec.h to work, and for the "vector" keyword.
Okay for trunk. Thank you!
Segher
On Fri, Sep 11, 2020 at 03:17:19PM -0500, Qing Zhao wrote:
> > On Sep 11, 2020, at 3:05 PM, Segher Boessenkool
> > wrote:
> > On Fri, Sep 11, 2020 at 02:40:06PM -0500, Qing Zhao wrote:
> >>> On Sep 11, 2020, at 12:13 PM, Segher Boessenkool
> >>> wrote
call an attacker wants, and he has to
construct that sequence himself; but it very effective and cheap then).
Segher
?
Okay for all. You may want to check it into 9 a bit faster than usual,
to meet the release schedule. It should be perfectly safe enough for
that. Do run the regstraps, of course ;-)
Thanks!
Segher
> gcc/
> PR target/93658
> * config/rs6000/rs6000.c (rs6000_legitimate_a
On Mon, Feb 17, 2020 at 02:48:20PM -0600, will schmidt wrote:
> On Thu, 2020-02-13 at 17:23 -0600, Segher Boessenkool wrote:
> > On Thu, Feb 13, 2020 at 04:41:09PM -0600, will schmidt wrote:
> > > -/* { dg-final { scan-tree-dump-times "LOOP VECTORIZED" 14 "vect&q
(vsx_extract__var, VSX_EXTRACT_I iterator): Use 'Q' for
> doing vector extract from memory.
> (vsx_extract__mode_var): Use 'Q' for doing vector
> extract from memory.
>
> Only for GCC 8:
>
> * gcc.target/powerpc/vsx-vector-6-le.c: Update fragile insn count.
All those are okay to backport. Thanks!
Segher
not work with *any* underlying ABI? What *is* this, what is it *for*,
where is the documentation, where is the design documentation? Etc.
Segher
++ gcc/testsuite/gcc.target/s390/pr93908.c 2020-02-24 18:39:18.928495337
> +0100
> @@ -0,0 +1,5 @@
> +/* PR rtl-optimization/93908 */
> +/* { dg-do run { target s390_zEC12_hw } } */
> +/* { dg-options "-O2 -march=zEC12 -mtune=z13" } */
> +
> +#include "../../gcc.c-torture/execute/pr93908.c"
This file isn't in the changelog, please fix that?
Segher
, we should also test
everything everywhere, whenever reasonable.
For the glibc side I have no opinion.
Segher
require-effective-target powerpc_p9vector_ok } */
> +/* { dg-options "-mcpu=power9" } */
Add -O2 as well?
Okay for trunk with those tweaks. Does this need backports as well?
Thanks!
Segher
t and vector unsigned long long
> arguments.
* doc/extend.texi (PowerPC AltiVec Built-in Functions Available on
ISA 3.0): Something that mentions the old wrong name and the new
corrected names.
Okay for trunk with that, and backports too. Thanks!
Segher
-linux-gnu. Is this
> okay for trunk?
Okay, thanks!
Should there be a testsuite/gcc.target/powerpc/ppc64-abi-pcrel.c as well?
Segher
} } */
That checks if either the string
\mstvx
or the string
stxv\M
is part of the generated code.
You want
{\m(stvx|stxv)\M}
or
{\mstvx\M|\mstxv\M}
or
{\mst(vx|xv)\M}
or one of many more variants (maybe you want to allow stxvx as well, for
example).
Segher
Hi!
On Tue, Feb 25, 2020 at 07:43:09PM -0600, Bill Schmidt wrote:
> On 2/25/20 12:45 PM, Segher Boessenkool wrote:
> >I don't agree we should have a new ABI, and an API (which this *is* as
> >far as I can tell) works fine on *any* ABI. Homogeneous aggregates has
> >n
#ifndef _ARCH_PWR5
> + #error does not have power5 support.
> + #else
> + /* "has power5 support" */
> + #endif
> + }]
> +}
> +proc check_effective_target_has_arch_pwr6 { } {
Please put empty lines between the functions.
With that, okay for trunk. Thanks!
Segher
esign this with ELFv2 in mind, of course, but
making a dependency on the (current!) (very complex!) ELFv2 rules for
absolutely no reason at all is a mistake, in my opinion.
Segher
target { be && ilp32 }
> } } } */
> -/* { dg-final { scan-assembler-times {\mmtvsrd\M} 0 { target { lp64 } } } }
> */
> -/* { dg-final { scan-assembler-times {\mmtvsrd\M} 0 { target { be && ilp32 }
> } } } */
> +/* { dg-final { scan-assembler-times {\mvslo\M} 3 { target lp64 } } } */
All this stays super fragile.
Okay for trunk. Thanks!
Segher
re broken by the
> register allocation behavior. Can I check these patches into GCC 9?
So what is different in this backport?
Either way, it needs some soaking time first. This patch is not much
safer than average.
Segher
On Thu, Feb 27, 2020 at 06:53:10PM -0500, Michael Meissner wrote:
> On Thu, Feb 27, 2020 at 04:57:28PM -0600, Segher Boessenkool wrote:
> > On Thu, Feb 27, 2020 at 03:38:54PM -0500, Michael Meissner wrote:
> > > Here are the equivalent changes for PR target/93932 for the GCC 9
SA 2.05/2.06 which HI/QI modes need
> 2.07, etc.).
>
> Given we are in stage 4, I think #4 is not appropriate (but if you want, I can
> do the patches).
That goes for option 3 as well.
Thanks,
Segher
correct.
> With this option, you got exactly what you wanted.
It happens with -O2 already.
The frontend generates a MIN_EXPR (or MAX_EXPR) for this, which is
undefined for NaNs already. I think the testcase is just invalid?
Segher
o both this list and
gcc-patches.
Segher
On Fri, Feb 28, 2020 at 04:32:05PM +0100, Jakub Jelinek wrote:
> On Fri, Feb 28, 2020 at 04:11:15PM +0100, Tobias Burnus wrote:
> > On 2/28/20 3:53 PM, Segher Boessenkool wrote:
> > > It happens with -O2 already. The frontend generates a MIN_EXPR (or
> > > MAX_EXPR) f
", but "criterium" would be more suitable here.
Segher
y
> for OPTION_MASK_ALTIVEC.
(and indent the rest with tabs as well?)
Segher
On Mon, Mar 02, 2020 at 07:41:42PM -0500, Michael Meissner wrote:
> On Fri, Feb 28, 2020 at 06:45:25AM -0600, Segher Boessenkool wrote:
> > On Fri, Feb 28, 2020 at 12:32:06AM -0500, Michael Meissner wrote:
> > > There is a wider issue to optimize all cases of vec_extract to
the header file
> for MAX_MACHINE_MODE.
The changelog entry should say *what* file is included, and under what
condition. It doesn't have to say why (that belongs in the commit
message).
But, can't you just include it unconditionally? Don't we already,
anyway, via coretypes.h -> machmode.h -> insn-modes.h?
Segher
;
> OK for master?
Yes please. Thanks!
(On 9 branch as well, if it is a fix there? If it misses 9.3, that's
not a big deal of course, but if it is tested before the RC spins, it
is a very safe patch).
Segher
on the platform.
>
> Sniff tested successfully. (mostly obvious).
>
> OK for master?
Okay for trunk. Thanks!
Segher
0/rs6000.h
> @@ -2494,6 +2494,7 @@ extern GTY(()) tree
> rs6000_builtin_types[RS6000_BTI_MAX];
> extern GTY(()) tree rs6000_builtin_decls[RS6000_BUILTIN_COUNT];
> extern GTY(()) tree builtin_mode_to_type[MAX_MACHINE_MODE][2];
> extern GTY(()) tree altivec_builtin_mask_for_load;
> +extern union GTY(()) section *toc_section;
Why does this add "union"?
Segher
your suggestion.
What about the second part? Shouldn't it already be included anyway?
> * config/rs6000/rs6000-internal.h (altivec_builtin_mask_for_load,
> builtin_mode_to_type[MAX_MACHINE_MODE][2]): Remove GTY(()).
This changelog entry needs updating now. (And please check the rest
as well.)
Segher
it ok for trunk, and backport to GCC 9 after some burn-in time?
Why is any of this Power-specific? Does it work on other targets if
!vect_hw_misalign?
The patch is fine everywhere as far as the rs6000 port is concerned, but
I'd like someone else who actually understands this stuff to have a look
at it as well ;-)
Segher
he scope of that
declaration is the function declaration, making this union a different
type from any later uses of it! (This problem is more commonly seen
with struct, but it is exactly the same with union).
You should make sure "section" is declared before this, instead.
Segher
Hi!
On Wed, Mar 04, 2020 at 06:35:23PM +0800, Kewen.Lin wrote:
> Another try seems to move it into #ifndef USED_FOR_TARGET hunk.
> Since "typedef union section section" is guard by #ifndef USED_FOR_TARGET
> in coretypes.h. It can make them consistent.
Yes, that should work, good idea.
Segher
On Fri, Feb 28, 2020 at 05:31:56PM +0100, Jakub Jelinek wrote:
> On Fri, Feb 28, 2020 at 04:23:03PM +, GT wrote:
> > Do we want to change the name and title of the document since Segher
> > doesn't believe it
> > is an ABI. My initial suggestion: "POWE
Hi Bin Bin,
On Thu, Mar 05, 2020 at 10:31:39AM +0800, binbin wrote:
> On 2020/3/5 上午2:35, Segher Boessenkool wrote:
> >On Wed, Mar 04, 2020 at 03:08:41PM +0800, binbin wrote:
> >>>> * config/rs6000/rs6000.h (MAX_MACHINE_MODE): Include the header file
> >>>>
tion *toc_section;
No empty line before this please?
Thanks!
Segher
st as well? Or, how else was this checked?
> PR target/93800
> * config/rs6000/rs6000.c (rs6000_option_override_internal):
> Remove set of str_align_loops and str_align_jumps as these
> should be set in previous 2 conditions in the function.
Okay for trunk, maybe with an added test. Thanks!
Segher
s (but not all) use two spaces after a dot (just like comments
and documentation do).
Thanks!
Segher
t, but some
emacs users like one space, instead; same indent as the case labels
isn't correct).
Segher
begins?
It will be handled for GCC 11. Please ping the patch when GCC 11 has
opened (if necessary)? We can of course keep discussing it now (if
there are any open questions left.
Segher
or_load;
Add a newline here please?
> /* A C structure for machine-specific, per-function data.
> This is added to the cfun structure. */
> typedef struct GTY(()) machine_function
Okay for trunk with those tweaks. Thanks!
Segher
t; 2020-03-09 Bin Bin Lv
>
> * config/rs6000/rs6000-internal.h (toc_section): Remove the declaration.
> * config/rs6000/rs6000.h (toc_section): Add the declaration.
> * config/rs6000/rs6000.c (toc_section): Remove the declaration.
This looks fine. Okay for trunk. Thanks!
Segher
On Mon, Mar 09, 2020 at 09:48:01AM -0500, will schmidt wrote:
> On Tue, 2020-02-25 at 12:15 -0600, will schmidt wrote:
> > PR90763: PowerPC vec_xl_len should take const argument.
>
> ping! :-)
https://gcc.gnu.org/pipermail/gcc-patches/2020-February/540969.html
Segher
...)
> {
> foo should be still zero, but SSA doesn't have the correct use
> here
> }
>
> that means the compiler really assumes the asm will populate the outputs
> even when it throws.
How is memory any different here? In both cases you do not know if it
is the old value or some new value in foo, after it threw an exception.
Segher
ag_signed_zeros))
> max_p = !max_p;
I know I asked for it, but should this use HONOR_NANS (compare_mode)
instead? Infinities will work fine? Just NaNs and zeros won't.
Okay for trunk with that change (if it works :-) ) Thanks!
Segher
On Thu, Mar 05, 2020 at 02:21:58AM -0600, luo...@linux.ibm.com wrote:
> From: Xionghu Luo
>
> Backport the patch to fix failures on P9 and P8BE, P7LE for PR94036.
No changes were needed?
> Tested pass on P9/P8/P7, ok to commit?
Yes, okay for 9. Thanks!
Segher
>
1801 - 1900 of 6091 matches
Mail list logo
