et to delete the file, it isn't in your patch.)
Segher
times {\mxxlandc\M} 12 } } */
> +/* { dg-final { scan-assembler-times {\mxxlxor\M} 3 } } */
> +/* { dg-final { scan-assembler-times {\mxxsel\M} 2 } } */
Yeah, not funny how many actual change there are.
Okay for trunk. Thanks!
Segher
be make an
alias to push a local branch to the server the first time... Completely
untested:
[alias]
new-user-branch = !git push $1:users/myname/heads/$1
(And yes, I know this doesn't work as written if you have tag names
the same as branch names. That *deserves* punishment :-) )
Segher
which is easier for us,
the expansion of ctz depends on multiple factors). (Note that "foo" has
UB whenever x == 0, btw. -- it would be nice if something like "bar" would
generate the optimal code as well. Is there some other code that will just
work?)
> and if for all that have CTZ_DEFINED_VALUE_AT_ZERO 1,
> we could perhaps just emit branchy code and wait for RTL to fix that up.
Where would RTL fix that? In what pass, I mean.
Segher
On Sun, Jan 12, 2020 at 01:31:13PM +, Iain Sandoe wrote:
> Segher Boessenkool wrote:
> > Why would people want to name their local branches "me/thing" instead
> > of just "thing", btw?
>
> it’s a way of making things distinct and allows the push ru
l bad, are our
target costs bad, or something like that?
Segher
+ if (loop->unroll > 0 && loop->unroll < USHRT_MAX)
> +{
> + /* It should have been peeled instead. */
> + if (const_niter == 0 || (unsigned) loop->unroll > const_niter - 1)
> + loop->estimated_uf = 1;
> + else
> + loop->estimated_uf = loop->unroll;
> + return true;
> +}
"If loop->unroll is set, use that as loop->estimated_unroll"?
Segher
e [reg] addressing in either form as well. Whether D-form
can be used for some access depends on many factors (ISA version, mode of
the datum, alignment, and how big the offset is of course). But the usual
legitimate_address_p hook should do fine. The ivopts code already has an
addr_offset_valid_p function, maybe that could be adjusted for this?
Segher
e when other optimization passes evolve. */
> +
> +/* { dg-final { scan-assembler {\mlxv\M} } } */
Maybe you can also test there ar no lxvx insns generated?
Segher
anyway. Maybe
it would help to make this non-zero for reg+reg addressing, thanks for
the hint.
There must be something else wrong as well though; I don't see how
ivopts could come up with what it does currently as the best plan.
Segher
that change, and for release branches a bit later
(wait for AIX and Darwin test results if you can?)
Thanks!
Segher
On Tue, Jan 21, 2020 at 12:23:02AM +0100, Jakub Jelinek wrote:
> On Mon, Jan 20, 2020 at 05:10:55PM -0600, Segher Boessenkool wrote:
> > On Mon, Jan 20, 2020 at 11:52:55PM +0100, Jakub Jelinek wrote:
> > > PR target/93073
> > > * config/rs6000/rs6000.c (r
Hi!
On Mon, Jan 20, 2020 at 08:31:43PM -0500, Nicholas Krause wrote:
> On 1/20/20 6:51 PM, Segher Boessenkool wrote:
> >We can (and should) use other instructions than just fsel here as well
> >(say, xscmpgedp followed by xxsel). This can also work for QP float,
> >which als
been broken up to provide for review.
All non-trivial series, yeah.
Maybe we should mention how v2 etc. of patch series should show what is
changed? If there is a good standard practice for that at all :-)
Segher
On Wed, Jan 22, 2020 at 10:00:00AM +, Richard Earnshaw (lists) wrote:
> On 21/01/2020 19:26, Segher Boessenkool wrote:
> >On Tue, Jan 21, 2020 at 02:52:00PM +, Richard Earnshaw (lists) wrote:
> >>+ A brief summary
> >
> >You could stress that this is the
t everything it can do
is okay here at all apparently, it is a bad choice.
It looks like your patch will pessimise code in some cases as well, btw?
Segher
g generation.
Note that this isn't specific to sws at all: there isn't anything
stopping later passes from doing this either. Is there anything that
protects us from sched2 doing similar here, for example?
Segher
get your changes included at the cost of basic quality.
Anyway, 90% of the advantages of using Git come from using it *locally*,
which many of us have been doing since forever and a day already.
Segher
l with -O2 and mainly
> affects -O3, the simplest option is to disable code hoisting for -O3 and
> higher.
Should this be a generic thing, not target-specific?
Segher
ence of the bit-test
> (btstq) instruction.
That's PR93372 (not X :-) ).
Do you have any estimate how much removing cc0 this way costs in
performance (or code size, or any other metric)?
Segher
logue can create new store
insns (ignoring peepholes and splitters, that would be almost *asking*
for trouble ;-) ). I see. Thanks for explaining.
Segher
On Tue, Jan 28, 2020 at 10:42:16AM +0100, Richard Biener wrote:
> On Mon, Jan 27, 2020 at 10:47 PM Segher Boessenkool
> wrote:
> > On Tue, Jan 21, 2020 at 02:10:21PM +, Wilco Dijkstra wrote:
> > > While code hoisting generally improves codesize, it can affect perform
On Tue, Jan 28, 2020 at 10:43:24AM +, Richard Sandiford wrote:
> Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
> OK to install?
Yes, thank you.
Segher
> 2020-01-28 Richard Sandiford
>
> gcc/testsuite/
> PR testsuite/93393
>
constraints.md (let
alone generated from it), so the two diverged. I tried to correct
that, too.
Please let me know if you have any ideas how to improve it further, or
if I did something terribly wrong, or anything else. Thanks,
Segher
---
gcc/config/rs6000/constraints.md | 159
inner_mode,
> + XEXP (SUBREG_REG (op0), 0),
> + tmp);
> +
> return lowpart_subreg (int_mode, tmp, inner_mode);
> }
Should this be done for at least left shifts, too?
Looks good with those things fixed.
Segher
Okay for trunk either way. Thanks!
Segher
good simple way to write what it does
anyway (because it *isn't* simple), I hoped I could just keep this for
now.
Hrm, I lost markup there, will fix.
> >+@item wZ
> >+Indexed or indirect memory operand, ignoring the bottom 4 bits.
> >+@end ifset
>
> For consistency, "An indexed..." ?
Yes, thanks!
> >+@item Z
> >+A memory operand that is an indexed or indirect from a register.
>
> "indexed or indirect access"?
And s/from a register// yeah.
> Great improvements!
Thanks :-)
Somewhere it should say (in the gcc.* doc) that there are other
constraints and output modifiers as well, and some are even supported
for backwards compatibility, but here only the ones you should use are
mentioned. Not sure where to do that.
Segher
t_op));
> +}
This sets the same pseudo twice (or is it never a pseudo?), not a good
idea in general.
Okay for trunk, with comments improved please. Thanks!
Segher
On Fri, Jan 31, 2020 at 10:56:10AM -0600, Bill Schmidt wrote:
> On 1/31/20 9:42 AM, Segher Boessenkool wrote:
> >On Fri, Jan 31, 2020 at 08:49:21AM -0600, Bill Schmidt wrote:
> >>>+(define_register_constraint "wa"
> >>>"rs6000_constraints[RS6000_CONS
he xfc4-terminal to _ever_ implement URLs,
This is true for *most* terminal emulators.
I have nothing against this feature, I just wish it wouldn't annoy me
on pretty much every system I use. None of which use "TERM=dumb", but
none of which use "TERM=fancy-pants-term-v42" either. (Did anyone ever
use "dumb", anyway?)
Segher
ORM load, and the bottom 2 bits are non-zero;
> + We need to use a DQ-FORM load, and the bottom 2 bits are non-zero;
> + Only X_FORM loads can be done, and the address is D_FORM. */
4 bits for DQ-form?
Okay for trunk with those tweaks. Thanks!
Segher
en you don't need all these "else"s either, or all
these nested blocks. The NULL here is never used, either (you call
gcc_unreachable instead of returning it).
But, okay for trunk. Thanks!
Segher
ot;, "-mprefixed-addr", "-mabi=elfv2");
It would be good if the error messages also said "currently" somehow (it
is not an actual limitation, it's just a matter of code). "Is only
supported with -mabi=elfv2", perhaps?
Segher
On Fri, Jan 31, 2020 at 11:38:04PM +, Bernd Edlinger wrote:
> On 1/31/20 11:54 PM, Segher Boessenkool wrote:
> > about most, which caused me to open PR93168, is TERM=screen (which is
> > what tmux uses), so at least exclude that one? And doing all this
>
> Definitely,
), yes please, do not do the url thing
with TERM=dumb or TERM=ansi or TERM=screen and maybe some similar; but I
think many people will like their colours enabled.
Segher
On Sat, Feb 01, 2020 at 08:41:15AM -0500, David Malcolm wrote:
> Does our existing colorization code not work with TMUX, or is it just the
> new URLs that are broken? Segher?
I don't know, I have colourisation turned off in GCC pretty much always
on systems I use with tmux. Some oth
abling should
> have a very specific terminal detection logic.
Jakub says that he tested with a recent gnome-terminal. That works, of
course. Mnay other terminals will not, and switching what terminal is
attached to your screen session will not work well either, as far as I
can tell.
Segher
tart, and the PR number at the end,
and of course the actual subject itself, so we should not put in too
much fluff in the subject, there needs to be room left (in the less than
fifty chars total) for an actual subject :-)
(The example in the patch does not capitalise the subject line, btw.
It should.)
Segher
thing, dunno. I guess
I'll test with more tmux versions when I find some more time for this.
> But work fine when the compiler runs natively in a gnome-terminal.
It is big garbage for me, both with bell (which is much worse on some
other terminals), and with the string terminator escape (ESC \).
Segher
ce with it, is just wrong, and does not help anyway.
Segher
On Mon, Feb 03, 2020 at 01:59:58PM +, Richard Earnshaw (lists) wrote:
> On 03/02/2020 13:54, Segher Boessenkool wrote:
> >None of this are *rules*. We should not pretend they are. An email
> >subject should be useful to what the receivers of that email use it for:
&g
On Mon, Feb 03, 2020 at 01:59:58PM +, Richard Earnshaw (lists) wrote:
> On 03/02/2020 13:54, Segher Boessenkool wrote:
> >None of this are *rules*. We should not pretend they are. An email
> >subject should be useful to what the receivers of that email use it for:
&g
nd a few minutes on it, think of the thousands of people who will
later read it.
Segher
This un-documents constraints that cannot (or should not) be used in
inline assembler. It also improves markup, and presentation in general.
More work is needed, but gradual improvement is easier to do.
Committing to trunk.
Segher
2020-02-03 Segher Boessenkool
* config/rs6000
back.
It's irrelevant whether a patch is committed or not whather it needs
review, imnsho :-)
"rfc" is useful, certainly. It makes clear that the sender would like
some help, and/or that the subject might be controversial, both things
that have more time pressure than most.
Segher
aries are more related to people
> writing them than to length, IOW, I fear a larger limit like 72 characters
> won't help that.
Yup. If it helps, don't think of it as "summary", think of it as "title".
Segher
r setups, too (will have to check
the rest when I have time, unfortunately the weekend is just past).
Segher
, you can't do PCREL.
If you are building shared stuff at all. Right.
So toolchain support and dl support (i.e. binutils and glibc)?
Anything else?
We'll be best off if you separate those out now, because those
restrictions are independent. Also handled by different people on
different projects ;-)
Thanks,
Segher
On Mon, Feb 03, 2020 at 05:02:25PM -0500, Michael Meissner wrote:
> On Fri, Jan 31, 2020 at 11:30:22AM -0600, Segher Boessenkool wrote:
> > But why is that the correct thing to do? Garbage in, garbage out is
> > perfectly fine? Or do we have (e.g.) builtins that specify this mas
On Mon, Feb 03, 2020 at 06:19:07PM -0500, Michael Meissner wrote:
> On Fri, Jan 31, 2020 at 05:43:20PM -0600, Segher Boessenkool wrote:
> > On Thu, Jan 09, 2020 at 07:27:58PM -0500, Michael Meissner wrote:
> > > * config/rs6000/rs6000.c (reg_to_non_prefixed): Add forward
es is easier to
review; if there is just one case that is different, put it in a separate
patch if that can be done; otherwise, please point it out in the patch
commit message.
> Initial create of rs6000-genbif.c.
Subjects do not end in a dot (but do start with a capital).
> Add stubs for input files. These will grow much larger.
The second half of this does not belong in the title, but in the body.
Segher
+ Blank lines may be used as desired in these files.
Between stanzas and stuff only? There are places where newlines are
significant and not just whitespace, right?
Great docs, thanks!
Segher
Committed.
Segher
---
htdocs/git.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/git.html b/htdocs/git.html
index 66d68eb..7fd22a9 100644
--- a/htdocs/git.html
+++ b/htdocs/git.html
@@ -44,7 +44,7 @@ through, you can replace git:// with
https://.
If there is
just whitespace, right?
>
> I don't believe so, although there may be places where I forgot to allow
> a line to be advanced -- that would be a bug, though, so let me know if
> you see any. Blank lines don't have any inherent meaning in the input
> files.
Not blank lines, I'm asking about newlines :-) But those are not allowed
to be inserted just anywhere, a line has to be one line, iiuc?
Segher
> >or
> > [1]
> >for always, or
> > [0]
> >for never ("commented out").
> Ah! Sorry for misunderstanding. Right now just an identifier is
> allowed, but we could certainly grab the whole string between the [] and
> drop it in with no concerns. Hopefully we both remember when we get to
> the patch that reads the stanzas...
:-)
Segher
ld use the
exact same condition (same predicate function for example) as what
would lead to the problem later, or we'll be playing whack-a-mole for
a while (or CSE is completely rewritten soon, my preferred option, but
"soon" on a GCC timescale will take way too long for the PR).
Segher
Hi!
On Wed, Feb 05, 2020 at 08:57:16AM +0100, Richard Biener wrote:
> On Tue, Feb 4, 2020 at 6:40 PM Segher Boessenkool
> wrote:
> > On Mon, Feb 03, 2020 at 08:26:01PM -0600, Bill Schmidt wrote:
> > > My intent is to make adding new built-in functions as simple as adding
&
s6000.md (untyped_call): add emit_clobber.
"Add", capital.
> gcc/testsuite
> 2020-02-05 Jiufu Guo
>
> PR target/93047
> * gcc.dg/torture/stackalign/builtin-return-2.c: New case.
"New test case." (And there is trailing whitespace here; Git warns
about that, so this won't happen much in the future :-) )
Segher
> - rtx addr = XEXP (mem, 0);
> - gcc_assert (satisfies_constraint_Q (addr));
> + gcc_assert (satisfies_constraint_Q (mem));
>
>/* Mask the element to make sure the element number is between 0 and the
> maximum number of elements - 1 so that we don't generate an address
Okay for trunk. Thank you!
Segher
LL_P separately from
> the simplify-rtx stuff which Segher objected to. THat'd likely solve
> the ARM ICEs and take you a tiny step forward on optimizing that SVE
> case. Thoughts?
CSE should consistently keep track of what insns are no-op moves (in its
definition, all passes have
sts.
>
> [1] https://gcc.gnu.org/ml/gcc-help/2020-02/msg00023.html
> [2] https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01901.html
> [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91085
Thanks for the investigation and patch!
If no one comes up with a better suggestion soon, I'll apply your patch
so that your AT builds work again. (I'll write a changelog etc.)
Segher
sters. So, mark
> clobber for all touched registers maybe more safe.
Well, we can derive what registers it sets, perhaps? What does x86 do
here? It does something, I know that, haven't looked much deeper yet
though :-)
In general: this is not a problem for us only; some other archs may have
found a good solution already.
Segher
bout vectors in those regs? It says we can use
DQ-mode here, but that is only true from p9 onward, no?
Segher
.
Segher
2020-02-06 Segher Boessenkool
* config/rs6000/rs6000.c (rs6000_emit_set_long_const): Handle the case
where the low and the high 32 bits are equal to each other specially,
with an rldimi instruction.
gcc/testsuite/
* gcc.target/powerpc/pr93012.c: New
t; gen_rtx_SET (end_addr,
>gen_rtx_PLUS (Pmode, stack_pointer_rtx,
> rs)));
So please fix the comment?
Segher
changelog is testsuite/ChangeLog, so entries there do not have
"testsuite/" in it.
Segher
On Thu, Feb 06, 2020 at 01:40:03PM -0500, Michael Meissner wrote:
> This patch addresses the concern the Segher raised in the original submission
> of the patch to fix PR target/93569. In addition to checking for D*-form
> addresses in the traditional Altivec registers, this patch also c
Hi again,
On Thu, Feb 06, 2020 at 08:51:06PM +0100, Jakub Jelinek wrote:
> On Thu, Feb 06, 2020 at 01:15:25PM -0600, Segher Boessenkool wrote:
> > On Thu, Jan 30, 2020 at 05:14:08PM +0100, Jakub Jelinek wrote:
> > > Here is what I meant as the alternative, i.e. don'
cheduling after reload is not done, they might not be
> + split until final which doesn't allow splitting
> + if HAVE_ATTR_length. */
> + return !enable_split_before_sched2 ();
> +#else
> + return false;
> +#endif
> +}
flow.c was deleted in 2006... Is this split still needed at all? If
so, change the comment please? :-)
Segher
On Tue, Feb 04, 2020 at 02:55:14PM +0100, Martin Liska wrote:
>
> gcc/ChangeLog:
>
> 2020-02-04 Martin Liska
>
> PR c/92472.
That trailing dot should not be there (in some other patches as well).
Segher
(j = hard_regno_nregs (hard_regno, mode) - 1; j >= 0; j--)
> {
> + if (hard_regno + j >= FIRST_PSEUDO_REGISTER)
> + break;
if (!HARD_REGISTER_NUM_P (hard_regno + j))
?
Segher
irectly
before final). This has been true for so long that lots of things are
bound to rely on it. "#" only has real meaning in final, of course
(but is nice documentation for everything else).
Maybe we should just always run split5, and not do it in final at all
anymore? Or at least always for targets with the "length" attribute?
Segher
CSE; combine does the *opposite* of CSE,
in some regards. You shouldn't do CSE without a cost model for it, in
any case.
Segher
ly, of course, which says you
don't have *any* NaNs.
Segher
Hi!
On Fri, Feb 07, 2020 at 03:10:05PM +0800, Jiufu Guo wrote:
> Segher Boessenkool writes:
> > On Thu, Feb 06, 2020 at 10:49:36AM +0800, Jiufu Guo wrote:
> >> > ... and nothing in the rtl stream says that those return registers are
> >> > actually set b
On Fri, Feb 07, 2020 at 09:00:40AM -0700, Jeff Law wrote:
> On Thu, 2020-02-06 at 07:56 -0600, Segher Boessenkool wrote:
> > On Wed, Feb 05, 2020 at 11:48:23AM -0700, Jeff Law wrote:
> > > Yea, it's closely related. In your case you need to effectively ignore
> &
Hi!
On Fri, Feb 07, 2020 at 06:22:56PM -0600, Peter Bergner wrote:
> On 1/9/20 6:29 PM, Peter Bergner wrote:
> > On 1/9/20 4:51 PM, Segher Boessenkool wrote:
> >> Splitting out separate functions in the testcase shouldn't be so much
> >> work? Or am I too opti
Hi again,
On Sat, Feb 08, 2020 at 11:54:48AM +0100, Uros Bizjak wrote:
> On Fri, Feb 7, 2020 at 5:41 PM Segher Boessenkool
> wrote:
> > On Thu, Feb 06, 2020 at 12:13:35PM +0100, Uros Bizjak wrote:
> > > The names of split_before_sched2 ("split4") and split_before_r
On Sat, Feb 08, 2020 at 10:17:42AM -0600, Segher Boessenkool wrote:
> And we do not know which of the register will be used for the return, in
> untyped_call (only untyped-return knows). But we can add clobbers of all
> registers that *might* be used for the return, we do know that
On Mon, Feb 10, 2020 at 03:07:49PM +0100, Jakub Jelinek wrote:
> + || strncmp (name, ".lbss.", sizeof (".lbss.") - 1) == 0
You can just use strlen (".lbss.") which is nicer to read and compiles
to the same thing?
Segher
On Mon, Feb 10, 2020 at 10:05:48AM -0800, Andrew Benson wrote:
> I don't think I have the ability to mark the PR as resolved. Can someone do
> that?
You have an @gcc.gnu.org account; if you use that for your BZ account,
you will magically get everything you need here.
Segher
Hi!
On Mon, Feb 10, 2020 at 02:17:04PM +0800, Kewen.Lin wrote:
> on 2020/1/20 下午8:33, Segher Boessenkool wrote:
> > On Thu, Jan 16, 2020 at 05:36:52PM +0800, Kewen.Lin wrote:
> >> As we discussed in the thread
> >> https://gcc.gnu.org/ml/gcc-patches/2020-01/msg0019
* tree-ssa-loop-manip.h (estimate_unroll_factor): New declare.
"New declaration."
Segher
t; * gcc.target/powerpc/p9-dform-3.c: New test.
> * gcc.target/powerpc/p9-dform-4.c: New test.
> * gcc.target/powerpc/p9-dform-generic.h: New test.
This is fine for trunk (after the other patches are in so this no longer
fails, of course ;-) ).
Segher
It is easier to read and understand strlen ("string") than it is to
read and understrand sizeof ("string") - 1 .
Tested on powerpc64-linux {-m32,-m64}. Committing to trunk.
Segher
2020-02-10 Segher Boessenkool
* config/rs6000/rs6000.c (rs6000_debug_pr
zeof (" Upper=y") - 1;
> config/rs6000/rs6000.c: strcpy (name, bname + sizeof ("__builtin_") - 1);
> config/rs6000/rs6000.c: len += sizeof ("no-") - 1;
> config/rs6000/rs6000.c: len += sizeof ("no-") - 1;
> config/rs6000/rs6000.c: comma_len = sizeof (", ") - 1;
Okay, I fixed those :-)
Segher
ing mode of the 68000 directly, instead of
> using a global offset table. At present, this option implies @option{-fpic},
This isn't a correct change.
Okay for trunk modulo the m68k change. Thanks!
Segher
ot;-O2 -flto -mno-vsx" } */
> +/* { dg-options "-O2 -flto -maltivec -mno-vsx" } */
> /* { dg-require-effective-target lto } */
You need to check for powerpc_altivec_ok if you use -maltivec?
Okay for trunk with that. Thanks!
Segher
+ check_runtime_nocache ppc_ieee128_ok {
> + int main()
> + {
> + __ieee128 a;
> + return 0;
> + }
> + } $options
> + }
Why do you use -mvsx while we actually need a superset of that?
Segher
y miss
> to update it.
Just tell the maintainers of those ports about it? They are responsive,
and of course they will know what they will want to do :-)
Segher
On Mon, Feb 10, 2020 at 10:22:37PM -0600, Bill Schmidt wrote:
> On 2/10/20 9:24 PM, Segher Boessenkool wrote:
> >>If you use -mpcrel, the compiler will generate PC-relative
> >>loads and stores to access items, rather than the current TOC based loads
> >>and
> &g
On Tue, Feb 11, 2020 at 08:34:15AM +0100, Richard Biener wrote:
> On Mon, 10 Feb 2020, Segher Boessenkool wrote:
> > Yes, we should decide how often we want to unroll things somewhere before
> > ivopts already, and just use that info here.
> >
> > Or are there advant
iteration retires?
That will be terrible on register-rich architectures: it *already* is
problematic how often some things are unrolled, blindly unrolling more
would make things worse. We need to unroll more where it helps, but
less where it does not. For that we need a good cost/benefit estimate.
Segher
ot to mention developer time).
Maybe the implementation can be improved, but probably we should do this
in a different way altogether. The current situation is not good.
Segher
+ } $options
> + }
> +}]
> +}
It would be better if you didn't need to special-case AIX here, if the
actual test would figure out it cannot do __ieee128 on AIX.
But, okay for trunk. Thanks!
Segher
s per 4. -ffast-math -frounding-math should
>not set the __FAST_MATH__ macro.)
>This is also a documentation change.
Ack.
All looks good to me, but I'm not maintainer of this.
This should be mentioned in the release notes I think, it does change
behaviour (for the better, but any change is a change).
Thanks,
Segher
On Wed, Feb 12, 2020 at 09:12:58AM +0100, Richard Biener wrote:
> On Tue, 11 Feb 2020, Segher Boessenkool wrote:
> > Basic block partitioning has wildly disproportionate fallout in all
> > later passes, both in terms of what those *do* (or don't, if partitioning
> > is
On Wed, Feb 12, 2020 at 09:07:27AM +0100, Richard Biener wrote:
> On Tue, 11 Feb 2020, Segher Boessenkool wrote:
>
> > On Tue, Feb 11, 2020 at 02:58:47PM +0100, Richard Biener wrote:
> > > On Tue, 11 Feb 2020, Roman Zhuykov wrote:
> > > > 11.02.2020 11:01, Richard
On Wed, Feb 12, 2020 at 11:53:22AM +0100, Richard Biener wrote:
> On Wed, 12 Feb 2020, Segher Boessenkool wrote:
> > On Wed, Feb 12, 2020 at 09:12:58AM +0100, Richard Biener wrote:
> > > On Tue, 11 Feb 2020, Segher Boessenkool wrote:
> > > > Basic block partitioni
, so it now
> FAIL: gcc.target/powerpc/pr93122.c (test for excess errors)
> Excess errors:
> xgcc: error: unrecognized command-line option '-mprefixed-addr'; did you mean
> '-mprefixed'?
>
> Fixed thusly, bootstrapped/regtested on powerpc64le-linux, committed to
> trunk as obvious.
Thanks!
Segher
901 - 1000 of 6091 matches
Mail list logo
