https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94665
--- Comment #17 from Segher Boessenkool ---
[ Please don't add other email addresses for me; I get enough mail already,
I don't need all bugzilla mail in duplicate :-) ]
(In reply to z.zhanghaij...@huawei.com from comment #16)
> Ok, I will cre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94708
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2020-04-22
Status|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94710
--- Comment #7 from Segher Boessenkool ---
Needs -mvsx -mlittle -O0 to fail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94710
--- Comment #8 from Segher Boessenkool ---
Patch is bootstrapping.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94710
Segher Boessenkool changed:
What|Removed |Added
Known to work||10.0
Summary|[8/9/10 Reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94740
--- Comment #6 from Segher Boessenkool ---
It is of course good to wrap things with CONST whenever possible, but it
isn't documented anywhere (afaics) that this would be required, so this
is a workaround, not a fix?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94812
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2020-04-28
Status|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94850
--- Comment #3 from Segher Boessenkool ---
Did combine try combining four insns here? If not, would it have helped?
|UNCONFIRMED |NEW
CC||segher at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Segher Boessenkool ---
Confirmed.
At combine time we start with
insn_cost 4 for25: r130:V1TI=%2:V1TI
REG_DEAD
|1
CC||segher at gcc dot gnu.org
Status|UNCONFIRMED |NEW
--- Comment #1 from Segher Boessenkool ---
li 9,-2 ; rotldi 9,9,62 or similar, even.
Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93802
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
Ever
|1
Status|UNCONFIRMED |NEW
CC||segher at gcc dot gnu.org
--- Comment #1 from Segher Boessenkool ---
Confirmed.
|UNCONFIRMED |NEW
Ever confirmed|0 |1
CC||segher at gcc dot gnu.org
--- Comment #3 from Segher Boessenkool ---
Confirmed. Apparently this builtin isn't used much at all :-/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873
--- Comment #7 from Segher Boessenkool ---
REG_EQ* is documented as only being allowed on insns that set only one
register. If you want to change that, you'll have to check *all* code
that consumes this, see if they rely on that fact or not, and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94864
--- Comment #3 from Segher Boessenkool ---
vec_duplicate of vec_select is just a vec_select. Any vec_merge is a
vec_select as well, as you say.
Canonicalisation should make vec_select always.
We probably should have canonicalisation rules for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873
--- Comment #9 from Segher Boessenkool ---
"clobber" is a red herring; it is impossible to make a REG_EQ* note for
a clobber, a clobber does not set a new value (that is the whole point
of a clobber).
I think we could allow auto-modify, sure, ju
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873
--- Comment #10 from Segher Boessenkool ---
Oh, and ideally, we would replace the whole REG_EQ* stuff with a more
powerful interface that is to-the-side, not embedded in the instruction
stream. For known exact values, nonzero_bits, known ranges,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873
--- Comment #14 from Segher Boessenkool ---
So, hrm, we could in principle attach a REG_EQ* note to any single_set
instruction?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873
--- Comment #19 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #18)
> Created attachment 48451 [details]
> gcc11-pr94873.patch
>
> Untested patch then.
This one-liner is pre-approved. Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95032
--- Comment #1 from Segher Boessenkool ---
Ah. I couldn't reproduce this, but I used -mcpu=future.
Please don't use -mfuture, it does not work, it cannot work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95032
--- Comment #2 from Segher Boessenkool ---
(It currently enables p10 insns, but it leaves p9 insns disabled (and any
older insns your compiler doesn't default to as well)).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95082
--- Comment #4 from Segher Boessenkool ---
But this PR has more info, so I'll close the older one as dup, instead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95070
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95082
--- Comment #3 from Segher Boessenkool ---
*** Bug 95070 has been marked as a duplicate of this bug. ***
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
Doug Rupp says that it fixes his problems:
https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546176.html
(thread starts at
||2020-05-20
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70053
--- Comment #8 from Segher Boessenkool ---
I see no conversion there?
But, why does it it store to memory at all?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69493
--- Comment #11 from Segher Boessenkool ---
Why does our unpack expander use UNSPEC_UNPACK_128BIT at all, why
can it not simply generate simple code (without unspecs) directly?
(Same goes for "pack").
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94812
--- Comment #5 from Segher Boessenkool ---
Thanks :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92860
--- Comment #20 from Segher Boessenkool ---
We are in stage 1 now (for GCC 11), so nothing should be deferred now.
|1
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Segher Boessenkool ---
Mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49854
--- Comment #6 from Segher Boessenkool ---
Please *NEVER* close bugs for things you are not the maintainer for.
|ASSIGNED|RESOLVED
CC||segher at gcc dot gnu.org
--- Comment #1 from Segher Boessenkool ---
The powerpcspe backend has been deprecated in GCC 8 and removed during GCC 9
development. See corresponding mailing list threads[1,2,3] for details
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30259
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30370
Bug 30370 depends on bug 30259, which changed state.
Bug 30259 Summary: ICE on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30259
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37759
--- Comment #12 from Segher Boessenkool ---
The powerpcspe backend has been deprecated in GCC 8 and removed during GCC 9
development. See corresponding mailing list threads[1,2,3] for details.
[1] https://gcc.gnu.org/legacy-ml/gcc/2018-04/msg001
|UNCONFIRMED |RESOLVED
CC||segher at gcc dot gnu.org
--- Comment #4 from Segher Boessenkool ---
The powerpcspe backend has been deprecated in GCC 8 and removed during GCC 9
development. See corresponding mailing list threads[1,2,3] for details
|--- |WONTFIX
CC||segher at gcc dot gnu.org
--- Comment #3 from Segher Boessenkool ---
The powerpcspe backend has been deprecated in GCC 8 and removed during GCC 9
development. See corresponding mailing list threads[1,2,3] for details
|--- |WONTFIX
CC||segher at gcc dot gnu.org
--- Comment #5 from Segher Boessenkool ---
The powerpcspe backend has been deprecated in GCC 8 and removed during GCC 9
development. See corresponding mailing list threads[1,2,3] for details
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49854
--- Comment #7 from Segher Boessenkool ---
The powerpcspe backend has been deprecated in GCC 8 and removed during GCC 9
development. See corresponding mailing list threads[1,2,3] for details.
[1] https://gcc.gnu.org/legacy-ml/gcc/2018-04/msg0010
||segher at gcc dot gnu.org
Status|UNCONFIRMED |RESOLVED
--- Comment #3 from Segher Boessenkool ---
The powerpcspe backend has been deprecated in GCC 8 and removed during GCC 9
development. See corresponding mailing list threads[1,2,3] for details
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57389
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57872
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71012
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86133
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
||segher at gcc dot gnu.org
Status|UNCONFIRMED |RESOLVED
--- Comment #10 from Segher Boessenkool ---
The powerpcspe backend has been deprecated in GCC 8 and removed during GCC 9
development. See corresponding mailing list threads[1,2,3] for details
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60158
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60158
--- Comment #8 from Segher Boessenkool ---
It does not happen on any target currently, and it has never happened
on non-SPE targets before.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79251
--- Comment #4 from Segher Boessenkool ---
The Gimple code is "bad" already (it explicitly does the short write).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95531
--- Comment #3 from Segher Boessenkool ---
What is the question? 4+4 = 16? Not all costs are included in
that "4+4" :-) It does look weird; patches welcome.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68837
--- Comment #4 from Segher Boessenkool ---
On Power9 the lwa insn is cracked into an lwz and an extsw, just like
on older CPUs. Cracked instructions have fewer constraints on p9 than
they did on most older CPUs though (it doesn't have to be firs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60158
--- Comment #11 from Segher Boessenkool ---
Do you have a reproducer you can share?
I'll happily reopen the PR then, of course!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95531
--- Comment #5 from Segher Boessenkool ---
Various things can change the comparison mode. simplify_compare_const
is the most prominent example (hrm, maybe the only one now?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95531
--- Comment #6 from Segher Boessenkool ---
There is also SELECT_CC_MODE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95581
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95469
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
||2020-06-10
Target|powerpc-*-*-* |powerpc*-*-*
CC||segher at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Segher Boessenkool ---
Interesting! I tried it out, and
|1
CC||segher at gcc dot gnu.org
Last reconfirmed||2020-06-17
--- Comment #2 from Segher Boessenkool ---
(In reply to Jens Seifert from comment #0)
> PowerPC processors don't like branches an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95704
--- Comment #4 from Segher Boessenkool ---
It no longer generates that rldicl in GCC 9 (or GCC 10).
You do get straight-line code already if you use -mcpu=power9, btw
(isel; and not totally awful code, but it isn't super of course).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95704
--- Comment #6 from Segher Boessenkool ---
13 insns, but the longest chain is 4. As I said, not totally awful, and
much better than the branchy code (which does not predict well, for more
general inputs anyway).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87600
--- Comment #9 from Segher Boessenkool ---
(In reply to Alexandre Oliva from comment #8)
> I've noticed regressions caused by make_more_copies, in scenarios that used
> subreg s for the low part of promoted incoming parms. With hard regs, the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95737
Segher Boessenkool changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89310
--- Comment #4 from Segher Boessenkool ---
Maybe you can make a define_insn_and_split for the lshrdi3 plus this?
Which will split to an insn fewer immediately.
If you split after reload you need many extra patterns to get the most
basic optimisa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95907
--- Comment #1 from Segher Boessenkool ---
Confirmed (in C, with _Bool).
This is yet another case of enabling some insns but disabling many other
insns: our power10 support requires insns we enable on power9 and later
only (set[n]bc[r] is a spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95918
--- Comment #4 from Segher Boessenkool ---
Or even just { target le } yes. You can put that as the selector on just
the scan tests, and even do a separate BE version as well.
You can quote regexps with {} instead of "", that makes them much m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89310
--- Comment #6 from Segher Boessenkool ---
rldicr is one of the insns generated by "*rotl3_mask", which
recognises all canonical formulations of all our rotate-and-mask
instructions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95952
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96017
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2020-07-01
Status|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96017
--- Comment #10 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #6)
> Right, that's why we need to add the copies before RA, so we don't have to
> look for unused regs. But we don't want to add the copies too early just
> for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96017
--- Comment #11 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #9)
> (In reply to Peter Bergner from comment #8)
> > At first, I thought that split_live_ranges_for_shrink_wrap() split this
> > nicely, but what I found is that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89310
--- Comment #7 from luoxhu at gcc dot gnu.org ---
(In reply to Segher Boessenkool from comment #6)
> rldicr is one of the insns generated by "*rotl3_mask", which
> recognises all canonical formulations of all our rotate-and-mask
> instructions.
Y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95581
--- Comment #12 from Segher Boessenkool ---
This is pre-approved with a testcase (if it fixes that testcase, etc.,
yadda yadda).
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
Bug 94042 depends on bug 94148, which changed state.
Bug 94148 Summary: The DF framework uses bb->aux, which is for passes only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94148
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94148
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94393
--- Comment #6 from Segher Boessenkool ---
It certainly would be nice to improve this :-) It won't help most code
very much -- how often do two-word values happen at all -- but we have
to revisit how all this is decided anyway (for prefixed inst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92488
Segher Boessenkool changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #2 from Segher Boes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87949
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|NEW
--- Comment #14 from Segher Boe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92488
--- Comment #5 from Segher Boessenkool ---
operands[2] needs an earlyclobber as well (it is written while some
operands are still read later). Everything else is fine as far as I
can see :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92488
--- Comment #6 from Segher Boessenkool ---
(So, pre-approved with that change, and with a testcase... A run test
ideally, if that isn't too hard?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96298
--- Comment #3 from Segher Boessenkool ---
It doesn't fail with 9.3 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96298
--- Comment #5 from Segher Boessenkool ---
Trying 17, 14 -> 18:
17: r147:DI=r145:DI^r121:DI
REG_DEAD r145:DI
REG_DEAD r121:DI
14: r144:DI=r142:DI^r121:DI
REG_DEAD r142:DI
18: r148:DI=r144:DI^r147:DI
REG_DEAD r147:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96298
Segher Boessenkool changed:
What|Removed |Added
Assignee|segher at gcc dot gnu.org |sayle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95907
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96343
--- Comment #3 from Segher Boessenkool ---
Thanks for the report.
Yes, not sure we can reproduce it like this. We might need something
smaller, more self-contained.
In the meantime... Can you check if this still happens with trunk,
or with GC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96446
--- Comment #2 from Segher Boessenkool ---
*movpxi tries to not split xxsetaccz insns, but that one is only for
fpr_reg_operand as operands[0], while *movpxi uses something more
general.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475
--- Comment #2 from Segher Boessenkool ---
That option was removed in GCC 6, already.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475
--- Comment #4 from Segher Boessenkool ---
https://gcc.gnu.org/g:1f9ceff11132
-ftree-coalesce-vars it sounds like? But that isn't a 1-1 replacement
probably (or, what was the point of this change otherwise?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475
--- Comment #6 from Segher Boessenkool ---
I have a patch (since yesterday; just no time to send it :-/ )
Assignee: dmalcolm at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
On powerpc64-linux.
For -m32:
+FAIL: gcc.dg/analyzer/init.c (test for warnings, line 100)
+FAIL: gcc.dg/analyzer/init.c (test for warnings, line 101)
+FAIL: gcc.dg/analyzer/init.c (test
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
Reported by Sergei in
https://sourceware.org/bugzilla/show_bug.cgi?id=26522
This happens since gcc.gnu.org/g:2d94f7dea9c7 (but that is just what
triggered it, not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96786
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96786
--- Comment #1 from Segher Boessenkool ---
Perhaps we should just ignore AltiVec for the .machine selection?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96933
--- Comment #1 from Segher Boessenkool ---
Is that actually faster though? The original has shorter dependency
chains. Or is this to avoid some LHS/SHL?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96933
--- Comment #4 from Segher Boessenkool ---
Yes, timing suggests there is some SHL/LHS flush.
On p9 and later we can use mtvsrdd instead of mtvsrd (moving two
bytes into place at one), which reduces the number of moves from
16 to 8, and the numbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85830
--- Comment #10 from Segher Boessenkool ---
Thanks Carl!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96933
--- Comment #7 from Segher Boessenkool ---
There are vmrglb and vrghb etc.?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96933
--- Comment #9 from Segher Boessenkool ---
I'm not sure what you mean.
vmrglb merges the vectors
abcdefghijklmnop
and
ABCDEFGHIJKLMNOP
to
iIjJkKlLmMnNoOpP
... ah, I see what you mean I guess.
So, use something else instead? How about vp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96965
Segher Boessenkool changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475
Segher Boessenkool changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475
--- Comment #10 from Segher Boessenkool ---
Please show the full message? (It starts with "internal compiler error".)
101 - 200 of 3228 matches
Mail list logo
