https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106577
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
|UNCONFIRMED |NEW
CC||roger at nextmovesoftware dot
com
Ever confirmed|0 |1
--- Comment #3 from Roger Sayle ---
Ah interesting. Because index is a char, the tree-level optimizers realize
that the shift by 4 can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106594
--- Comment #5 from Roger Sayle ---
Hi Tamar,
I think this is where I need to apologize. Combine is now canonicalizing these
equivalent RTL expressions to the zero_extend form, on the assumption that zero
extension has no data dependency and is
|unassigned at gcc dot gnu.org |roger at
nextmovesoftware dot com
Status|NEW |ASSIGNED
|--- |13.0
Resolution|--- |FIXED
CC||roger at nextmovesoftware dot
com
--- Comment #14 from Roger Sayle ---
This is currently fixed (in match.pd).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106577
--- Comment #3 from Roger Sayle ---
Patch proposed:
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599663.html
||roger at nextmovesoftware dot
com
Assignee|unassigned at gcc dot gnu.org |roger at
nextmovesoftware dot com
Status|NEW |ASSIGNED
--- Comment #1 from Roger Sayle ---
Doh! For some reason I used "op1val = XINT (src, 1);"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106594
--- Comment #8 from Roger Sayle ---
Time for a status update. The PR title is a little misleading; sign-extensions
aren't really the problem, but it turns out that the equivalent zero-extensions
aren't always optimized as well as the equivalent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106609
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #9 from Roger Sayle ---
I'm curious why the zero_extend behaves so differently to a sign_extend,
perhaps a missing simplification or pattern. Presumably the CONCAT in the
debug_insn is there whether or not a sign_extend or zero_ext
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106640
Roger Sayle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64992
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98956
Bug 98956 depends on bug 64992, which changed state.
Bug 64992 Summary: More optimize opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64992
What|Removed |Added
--
||roger at nextmovesoftware dot
com
Target Milestone|--- |13.0
Resolution|--- |FIXED
--- Comment #6 from Roger Sayle ---
This should now be fixed on mainline.
|RESOLVED
CC||roger at nextmovesoftware dot
com
Resolution|--- |FIXED
--- Comment #8 from Roger Sayle ---
This should now be fixed on mainline.
||roger at nextmovesoftware dot
com
Assignee|unassigned at gcc dot gnu.org |roger at
nextmovesoftware dot com
--- Comment #3 from Roger Sayle ---
Patch proposed
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601526.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106933
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106933
--- Comment #3 from Roger Sayle ---
Ignore all of Comment 2. The reason the instruction isn't getting split, is
that (unlike the other clones), the pseudo's mode is V1TI (not TI), hence
doesn't match the constraint. The problem is STV (again)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472
Roger Sayle changed:
What|Removed |Added
Assignee|roger at nextmovesoftware dot com |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #6 from Roger Sayle ---
This sounds related to the discussion/patch originally proposed at
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598040.html
and then revised (based on reviewer comments) at
https://gcc.gnu.org/pipermail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
|NEW
Assignee|roger at nextmovesoftware dot com |unassigned at gcc dot
gnu.org
--- Comment #9 from Roger Sayle ---
My proposed patch to solve this problem was posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601423.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103820
--- Comment #3 from Roger Sayle ---
Thanks for investigating this HJ (I'm having difficulty configuring my system
to reproduce this). Is the TARGET_64BIT guard needed by both peephole2s, or is
one sufficient to restore bootstrap? Your fix/work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86948
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
||roger at nextmovesoftware dot
com
Resolution|--- |FIXED
Target Milestone|9.5 |11.3
--- Comment #17 from Roger Sayle ---
According to godbolt, with the example from comment #6, this appears to have
been fixed in gcc 11.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103773
Roger Sayle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
|ASSIGNED
Last reconfirmed||2022-01-20
Assignee|unassigned at gcc dot gnu.org |roger at
nextmovesoftware dot com
--- Comment #1 from Roger Sayle ---
Mine (perhaps?). To quote the review from my HIGHPART_MULT_EXPR patch:
>+ if (opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104140
--- Comment #2 from Roger Sayle ---
Ah. risv.md provides a usmulsidi3 expander that populates a usmul_widen_optab,
performing a widening multiplication with operands of differing signs.
The comment/documentation in tree.def needs to be updated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104140
--- Comment #3 from Roger Sayle ---
Sorry for the noise, but interestingly riscv.md also defines a
usmulsi3_highpart instruction, providing highpart multiplication with different
operand signedness. So in theory an alternate fix might be to allo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103641
--- Comment #20 from Roger Sayle ---
IMHO, the problem is in tree-vect-patterns.cc's vect_synth_mult_by_constant.
The comment above line 3054 reads:
/* Use MAX_COST here as we don't want to limit the sequence on rtx costs.
The vectorizer'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103641
--- Comment #22 from Roger Sayle ---
I completely agree with Richard that the decision to vectorize or not to
vectorize should be made elsewhere taking the whole function/loop into account.
It's quite reasonable to synthesize a slow vector mult
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103641
--- Comment #23 from Roger Sayle ---
In fact I can see from my debugging logs that doing a DImode scalar
multiplication on AArch64 is never more than COSTS_N_INSNS(9) [mult_cost=36],
so doing this is a win if moving back and forth is cheaper tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102950
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104345
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101885
Roger Sayle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |roger at
nextmovesoftware dot com
at gcc dot gnu.org |roger at
nextmovesoftware dot com
--- Comment #3 from Roger Sayle ---
Additional patch proposed:
https://gcc.gnu.org/pipermail/gcc-patches/2022-February/589802.html
I need to figure out how to (re)produce Thomas' "used N registers" reports.
If someone coul
|--- |FIXED
CC||roger at nextmovesoftware dot
com
--- Comment #13 from Roger Sayle ---
Fixed on mainline. [Sorry I've only just noticed this hadn't been closed].
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104422
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
at gcc dot gnu.org |roger at
nextmovesoftware dot com
CC||roger at nextmovesoftware dot
com
--- Comment #2 from Roger Sayle ---
Patch proposed
https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590049.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104420
Roger Sayle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101885
Roger Sayle changed:
What|Removed |Added
Summary|[10/11/12 Regression] wrong |[10/11 Regression] wrong
|1
Assignee|unassigned at gcc dot gnu.org |roger at
nextmovesoftware dot com
Last reconfirmed||2022-02-11
--- Comment #3 from Roger Sayle ---
Patch proposed:
https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590139.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102986
Roger Sayle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
nextmovesoftware dot com |unassigned at gcc dot
gnu.org
dot gnu.org |roger at
nextmovesoftware dot com
CC||roger at nextmovesoftware dot
com
Last reconfirmed||2021-11-20
Status|UNCONFIRMED |ASSIGNED
--- Comment #2 from Roger Sayle ---
Patch
|tree-optimization
Ever confirmed|0 |1
CC||roger at nextmovesoftware dot
com
Last reconfirmed||2021-11-21
--- Comment #1 from Roger Sayle ---
The ior form is percieved in tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103344
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103345
Roger Sayle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |roger at
nextmovesoftware dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98953
Roger Sayle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |roger at
nextmovesoftware dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103376
--- Comment #10 from Roger Sayle ---
Many thanks to Jakub for the speedy fix (and Richard B for the speedy review),
and my apologies for the inconvenience. As diagnosed by Jakub, I hadn't
realized that the bswap pass was performing additional o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102117
Roger Sayle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
nextmovesoftware dot com |unassigned at gcc dot
gnu.org
Summary|[12 Regression] gcc -O0 |gcc -O0 behaves differently
|behaves differently on |on "DBL_MAX related
|"DBL_MAX related|operations" than gcc -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103345
Roger Sayle changed:
What|Removed |Added
Target Milestone|--- |12.0
Status|ASSIGNED
nextmovesoftware dot com |unassigned at gcc dot
gnu.org
--- Comment #4 from Roger Sayle ---
The MULT_EXPR and PLUS_EXPR aspects of this PR are now resolved (i.e. the case
in comment #1), but unfortunately the abs-based indexing used in the original
report still causes problems. The bswap pass doesn&#
||roger at nextmovesoftware dot
com
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #9 from Roger Sayle ---
This PR is now fixed on mainline. Thanks to Jakub (my apologies if I'd seen
comment #2 I wouldn
|--- |FIXED
Status|UNCONFIRMED |RESOLVED
CC||roger at nextmovesoftware dot
com
--- Comment #2 from Roger Sayle ---
This issue appears to be fixed on mainline.
The test case now generates:
f1: orb %dil, %sil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406
Roger Sayle changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45365
Roger Sayle changed:
What|Removed |Added
CC||shaohua.li at inf dot ethz.ch
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53875
--- Comment #6 from Roger Sayle ---
I believe this should be "... && optimize != 0", i.e. we want to eliminate
these calls (only) when optimizing. But this seems like a reasonable
fix/feature request (to identify breakpoints at -O0).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103477
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54063
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103550
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103550
--- Comment #9 from Roger Sayle ---
Note adding -fno-tree-reassoc results in fewer instructions than clang.
||roger at nextmovesoftware dot
com
Assignee|unassigned at gcc dot gnu.org |roger at
nextmovesoftware dot com
--- Comment #3 from Roger Sayle ---
Patch proposed:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586550.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103641
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103601
Roger Sayle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103773
Roger Sayle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |roger at
nextmovesoftware dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103785
--- Comment #4 from Roger Sayle ---
This is either (i) related to PR 103773, where GNAT is somehow setting
optimize_size to a value greater than 1 (i.e. -Oz) and getting hit by the known
memory corruption or (ii) somehow related to the highpart
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103773
--- Comment #3 from Roger Sayle ---
Patch proposed
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587258.html
|RESOLVED
Resolution|--- |FIXED
CC||roger at nextmovesoftware dot
com
--- Comment #7 from Roger Sayle ---
This should now be fixed on mainline.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102134
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100810
Roger Sayle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |roger at
nextmovesoftware dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102134
--- Comment #8 from Roger Sayle ---
It's even more complicated than that. According to wi::clz, if the unsigned
value being stored has a precision that is a multiple of HOST_WIDE_INT it's
sign-extended, and for all other precisions they are zer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100832
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102245
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102245
--- Comment #8 from Roger Sayle ---
Alternate patch proposed:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579378.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88173
Roger Sayle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |roger at
nextmovesoftware dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102245
Roger Sayle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88173
Roger Sayle changed:
What|Removed |Added
Target Milestone|--- |12.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102785
Roger Sayle changed:
What|Removed |Added
Last reconfirmed||2021-10-15
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102840
Roger Sayle changed:
What|Removed |Added
Last reconfirmed||2021-10-19
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102840
--- Comment #3 from Roger Sayle ---
With -m64, before:
test: movq.LC1(%rip), %mm0
paddb .LC0(%rip), %mm0
movq%xmm0, x(%rip)
ret
And after:
test: movq.LC2(%rip), %rax
movq%rax, x(%rip)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102986
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102986
--- Comment #5 from Roger Sayle ---
Patch proposed:
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582931.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #47 from Roger Sayle ---
I really don't believe that using UNSPEC here is the correct way to go, but it
appears to be the (only?) approach that Segher is prepared to approve. Hohum.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107627
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106877
Roger Sayle changed:
What|Removed |Added
Target Milestone|12.3|13.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106933
Roger Sayle changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106959
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
|--- |FIXED
CC||roger at nextmovesoftware dot
com
Target Milestone|--- |13.0
--- Comment #3 from Roger Sayle ---
This should now be fixed/implemented on mainline.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108229
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
|1
Keywords|error-recovery, |ice-on-valid-code
|ice-on-invalid-code |
Status|UNCONFIRMED |NEW
CC||roger at nextmovesoftware dot
com
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
Roger Sayle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |roger at
nextmovesoftware dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
--- Comment #8 from Roger Sayle ---
Created attachment 54195
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54195&action=edit
Roger's proposed patch
Here's my proposed patch (or something close to it, it's still bootstrapping
and regressi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
--- Comment #9 from Roger Sayle ---
Another way to avoid the SCALAR_FLOAT_MODE_P problem is:
/* Add a REG_EQUAL note to allow condition to be shared. */
rtx note = gen_rtx_fmt_ee (orig_code, mode, op0, op1);
/* TMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
--- Comment #14 from Roger Sayle ---
Created attachment 54197
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54197&action=edit
Related optimizations to ix86_expand_int_movcc.
Just for the record, here is a related patch that I was working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
Roger Sayle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105486
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
101 - 200 of 427 matches
Mail list logo
