https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #31 from Segher Boessenkool ---
An asm clobber just means "may be an output", and no operand will be assigned
a register mentioned in a clobber. There is no magic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #29 from Segher Boessenkool ---
(In reply to Rich Felker from comment #27)
> Also just realized:
>
> > Rich, forcing "n" to be in "$r10" seems to do the trick? Is that a
> > reasonable
> solution for you?
>
> It doesn't even
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #23 from Segher Boessenkool ---
It is harder for us to track it in an older bug with many older patches
for it, including stuff that needed fixups later. And, the "correct"
older bug for it would not be this one, anyway!
Before RA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #20 from Segher Boessenkool ---
Confirmed with various 7 and 8 (I don't have a mips 6 around).
Don't reopen this bug, it is not necessarily related. Instead, please
open a new PR. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #15 from Segher Boessenkool ---
(In reply to Rich Felker from comment #12)
> > You can work around it on older GCC by simply not using a register var
> > for more than one asm operand, I think?
>
> Nope. Making a syscall inherently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94176
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
(This PR is just to test BZ commit integration).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #11 from Segher Boessenkool ---
(In reply to Rich Felker from comment #10)
> This is a rather huge bug to have been fixed silently. Could someone who
> knows the commit that fixed it and information on what versions are affected
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94148
--- Comment #5 from Segher Boessenkool ---
commit 5c7e6d4bdf879b437b43037e10453275acabf521
Author: Segher Boessenkool
Date: Thu Mar 12 07:12:50 2020 +
df: Don't abuse bb->aux (PR94148, PR94042)
The df dataflow solvers use the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94148
--- Comment #4 from Segher Boessenkool ---
Fixed on trunk so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
Segher Boessenkool changed:
What|Removed |Added
Target|powerpc64-suse-linux|powerpc*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94148
--- Comment #3 from Segher Boessenkool ---
Fixed on trunk so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94135
--- Comment #3 from Segher Boessenkool ---
Both subfic and neg are 1-2 if run on the integer units. neg can run on
more units, but it is always 2 cycles then! (And the conditions where you
*can* have 1 cycle are not very often satisfied,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145
--- Comment #10 from Segher Boessenkool ---
The resolved address can only change before the first call to it, so we
could even automatically insert code checking that, perhaps.
My other concern is not slowing down the code if LD_BIND_NOW is in
|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
--- Comment #2 from Segher Boessenkool ---
Yes, and it assumes it stays cleared for any new blocks, and some more
subtleties.
I have a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145
--- Comment #3 from Segher Boessenkool ---
C11 6.6/9 says it *always* is constant, even.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145
--- Comment #2 from Segher Boessenkool ---
How could the function address ever not be constant?
Hoisting it to somewhere where it is (dynamically) more expensive is a
bad idea, of course.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94135
Segher Boessenkool changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94135
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94123
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
mal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
df-core.c:df_worklist_dataflow_doublequeue uses bb->aux, clobbering it,
while that field is documented as
/* Auxiliar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94148
Segher Boessenkool changed:
What|Removed |Added
Blocks||94042
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #46 from Segher Boessenkool ---
Thank you very much for that new testcase! I wish I had it before :-)
Yesterday I found the problem. It is in separate shrink-wrapping. The
fix is probably simple; hang on :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #42 from Segher Boessenkool ---
Okay, I see your dumps are 64-bit as well. But mine are very different, huh.
Still, it crashes in pretty much the same way.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #38 from Segher Boessenkool ---
Then, how did you do that?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #37 from Segher Boessenkool ---
Oh wait. I am dumb I guess? You did those dumps with a stage1 compiler?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #36 from Segher Boessenkool ---
> > I did that (with /usr/bin/gcc etc. though, won't work at all otherwise),
> > but that builds stage2 as 64-bit?
>
> Hm, that's possible. But the stage2 should not crash right?
It doesn't work, of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #34 from Segher Boessenkool ---
(In reply to Vladimir Makarov from comment #29)
> Sorry for all the troubles with my latest patch and thank you for fair
> criticism. I've decided to revert the patch as soon as git starts working.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #33 from Segher Boessenkool ---
(In reply to Martin Liška from comment #31)
> (In reply to Segher Boessenkool from comment #30)
> > I cannot reproduce the problem, btw (I cannot build a 32-bit hosted
> > toolchain).
> > Martin, you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #32 from Segher Boessenkool ---
Sigh. No, this is *not* a target bug (or we certainly do not know it is),
please stop marking it that.
It seems to be a bug in shrink-wrapping, but the dump does not show enough
information (only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #30 from Segher Boessenkool ---
I cannot reproduce the problem, btw (I cannot build a 32-bit hosted toolchain).
Martin, you have a working recipe?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #34 from Segher Boessenkool ---
Yeah, 16 (or really 12-ish, not all are available) I call "tiny" :-)
It is very surprising (and not pleasantly so) that this overrides
REG_ALLOC_ORDER. We allocate GPR0 last (of the volatile GPRs),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #32 from Segher Boessenkool ---
So it sounds like this helps for targets with tiny register sets?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #30 from Segher Boessenkool ---
r10-6919 isn't good for Power, btw. Why would it *ever* be a good idea?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
Segher Boessenkool changed:
What|Removed |Added
Assignee|marxin at gcc dot gnu.org |segher at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91638
--- Comment #5 from Segher Boessenkool ---
Yeah, not sure. A user can just do `-mlong-double-128`, and will get whichever
128-bit format is the default. That is the "old" way, when we only had the
ibm128 format, and it will be the new way too,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49854
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84302
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85170
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87083
Segher Boessenkool changed:
What|Removed |Added
Target Milestone|--- |8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37759
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71012
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81628
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85121
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86133
Segher Boessenkool changed:
What|Removed |Added
Target Milestone|--- |8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86772
Bug 86772 depends on bug 86801, which changed state.
Bug 86801 Summary: Powerpcspe port (may) need updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86801
What|Removed |Added
||segher at gcc dot gnu.org
Resolution|--- |WONTFIX
--- Comment #1 from Segher Boessenkool ---
GCC 9 does not support powerpcspe.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80700
Segher Boessenkool changed:
What|Removed |Added
Known to work||9.0
Summary|[8/9/10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81288
--- Comment #10 from Segher Boessenkool ---
Works in GCC 9, as in, the target does not exist any more in GCC 9.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91799
Segher Boessenkool changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91799
--- Comment #7 from Segher Boessenkool ---
I hadn't fully tested it yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93981
--- Comment #7 from Segher Boessenkool ---
(In reply to jwjagersma from comment #5)
> (In reply to Segher Boessenkool from comment #4)
> > Pretending any asm can throw would be a pretty serious code degradation.
> >
> > Any asm that is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93981
--- Comment #4 from Segher Boessenkool ---
Pretending any asm can throw would be a pretty serious code degradation.
Any asm that is not volatile cannot throw (and be correct code). But
most volatile asm in the wild can never throw, either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
Segher Boessenkool changed:
What|Removed |Added
Component|target |rtl-optimization
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93981
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91797
--- Comment #6 from Segher Boessenkool ---
I don't think I marked this as P1, fwiw, I hardly ever prioritise bugs,
and I would never make a test tweak a P1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91797
--- Comment #5 from Segher Boessenkool ---
This and PR88233 were lost somewhere behind the sofa ;-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91797
--- Comment #4 from Segher Boessenkool ---
commit 6cad71cf330623d4a01cb1bb77d4398b1674c776
Author: Segher Boessenkool
Date: Wed Jul 10 21:58:08 2019 +
fix pr68805.c
diff --git a/gcc/testsuite/gcc.target/powerpc/pr68805.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91799
--- Comment #4 from Segher Boessenkool ---
Apparently I missed committing the above. Will do later, when I am
awake again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91799
--- Comment #3 from Segher Boessenkool ---
commit 9b46c7543834c1a2004321dbf487fce29e015aae
Author: Segher Boessenkool
Date: Wed Jul 10 21:58:36 2019 +
fix pr88233.c
diff --git a/gcc/testsuite/gcc.target/powerpc/pr88233.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87560
--- Comment #5 from Segher Boessenkool ---
This code is unmodified since 2016, and we didn't change the flag handling
afair.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92656
--- Comment #6 from Segher Boessenkool ---
The is no simple solution, yeah. It may be possible to have a simple change
that results in better code on average, but that will be marginal :-/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92656
--- Comment #4 from Segher Boessenkool ---
The whole reg_stat thing cannot ever reliably track known bits. We need
some other mechanism to do this, something that *is* reliable, and does
not give different results if you try combinations in a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92342
--- Comment #12 from Segher Boessenkool ---
Gimple can help writing silly expressions like this in a more canonical
form (whatever we decide to use for that) at least, yeah. But you can
not do RTL's job in gimple ;-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93012
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93932
--- Comment #2 from Segher Boessenkool ---
So the issue is that input_operand allows too much?
Other patterns that could use such a fix are float2,
floatuns2, movsd_store, movsd_load,
*vsx_le_permute_, vsx_set_v1ti, vsx_extract__var,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93168
--- Comment #7 from Segher Boessenkool ---
(In reply to David Malcolm from comment #6)
> Segher: did the above patch fix it for your terminal?
I haven't found time to test it on all those systems yet, no.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #22 from Segher Boessenkool ---
T0T2T3T4
alpha 6049096 100.020% 100.018% 100.001%
arc 4019384 100.000% 99.989% 99.989%
arm 14177962 99.999% 99.999%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93583
--- Comment #4 from Segher Boessenkool ---
The line where things crash is
rtx temp = gen_reg_rtx (GET_MODE (valreg));
but presumably valreg is just 0 here?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #21 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #20)
> (In reply to Segher Boessenkool from comment #18)
> > Created attachment 47841 [details]
> > Patch to treat sign_extend as is_just_move
>
> Do you think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #19 from Segher Boessenkool ---
With that above patch, I get (T0 is original, T2 is with patch, these are
file sizes of a Linux build, mostly defconfig):
T0T2
alpha 6049096 100.020%
arc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #18 from Segher Boessenkool ---
Created attachment 47841
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47841=edit
Patch to treat sign_extend as is_just_move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #17 from Segher Boessenkool ---
That above commit is just a spec special, it doesn't solve anything else,
imnsho.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #16 from Segher Boessenkool ---
It is not the same cost. It reduces the path length.
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
The new testcase pr93661.c does not warn.
int f ()
{
unsigned x = 0x;
__builtin_memset (1+(char *) , 0, -1); /* { dg-warning "maximum o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #13 from Segher Boessenkool ---
nonzero_bits is not reliable. We also cannot really do what you propose
here, all of this is done for *every* combination.
We currently generate
(set (reg/v:SI 96 [ a ])
(and:SI (reg:SI 104)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #11 from Segher Boessenkool ---
(The original problem I have an idea for -- don't generate a parallel of
two SETs with equal SET_SRC -- but that doesn't handle the new case).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #10 from Segher Boessenkool ---
One of the first things combine tries is
Trying 7 -> 8:
7: r96:SI=r104:SI&0xe
REG_DEAD r104:SI
8: r99:DI=sign_extend(r96:SI)
...
Successfully matched this instruction:
(set (reg/v:SI 96
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66552
--- Comment #12 from Segher Boessenkool ---
Sure, but what makes shift amount special here? This works just fine in
any other expression as well. That is, for unsigned n; for negative numbers
modulo works differently: it returns 0 or negative,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66552
--- Comment #10 from Segher Boessenkool ---
What makes shift amount special at all, for those gimple simplifications?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71509
--- Comment #12 from Segher Boessenkool ---
But it could do just
stw r4,0(r3)
(on LE; and with a rotate first, on BE).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92518
--- Comment #8 from Segher Boessenkool ---
I confirm this is caused by r278207.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92518
--- Comment #7 from Segher Boessenkool ---
Ah, -fdump-ipa-all-all . So it seems like ppc-round.c.072i.icf is what is
wrong; it says
Equals called for: round_float_uint/3:round_float_int/1 with result: true
Equals called for:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92518
--- Comment #6 from Segher Boessenkool ---
It is still okay in ppc-round.c.048t.local-fnsummary2 but it is wrong
in ppc-round.c.088t.fixup_cfg3 (the pass immediately after it, at -O2).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92518
--- Comment #5 from Segher Boessenkool ---
Actually, this is simply wrong.
===
;; Function round_double_uint (round_double_uint, funcdef_no=5, decl_uid=2879,
cgraph_uid=3, symbol_order=2)
round_double_uint (double a)
{
int _4;
double _5;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #7 from Segher Boessenkool ---
What makes that move redundant? I don't see it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #5 from Segher Boessenkool ---
IOW, we need hard numbers, not guesstimates :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #4 from Segher Boessenkool ---
Why would that be unlikely? It lengthens the lifetime of that pseudo,
potentially significantly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93512
--- Comment #4 from Segher Boessenkool ---
I said (or I meant, at least) that as far as I see and know, all rotate
instructions on all machines do this truncation. It is of course possible
for targets to write it in RTL that only works for a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91638
--- Comment #2 from Segher Boessenkool ---
That isn't documentation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87213
Segher Boessenkool changed:
What|Removed |Added
Resolution|INVALID |WORKSFORME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87213
--- Comment #2 from Segher Boessenkool ---
I don't know how I reproduced this before, but I cannot any more.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #2 from Segher Boessenkool ---
Of course it first tried to do
Failed to match this instruction:
(parallel [
(set (reg:DI 101 [ _9 ])
(ctz:DI (reg/v:DI 98 [ x ])))
(set (reg:DI 100)
(ctz:DI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93505
--- Comment #18 from Segher Boessenkool ---
PR93512 is marked as enhancement, but if we don't fix this it is a regression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93509
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93505
--- Comment #13 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #11)
> and so I'd say even if we just don't fix expand_binop, this shows an
> optimization opportunity for the rs6000 backend
> if the rotlw instruction only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93505
--- Comment #12 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #10)
> Created attachment 47740 [details]
> gcc10-pr93505.patch
>
> Untested combiner fix. IMHO even when we fix expand_binop we want it
> anyway, because we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91938
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
1001 - 1100 of 3161 matches
Mail list logo
