https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
Roger Sayle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
--- Comment #18 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:650c36ec461a722d9c65e82512b4c3aeec2ffee1
commit r14-335-g650c36ec461a722d9c65e82512b4c3aeec2ffee1
Author: Roger Sayle
Date: Fri A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
Roger Sayle changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
--- Comment #16 from Wilhelm M ---
(In reply to Roger Sayle from comment #14)
> My apologies for the delay/issues. My bootstrap and regression testing of
> this patch (on x86_64-pc-linux-gnu) revealed an issue or two (including the
> reported I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
--- Comment #15 from Wilhelm M ---
Just checked actual gcc 13.0.1 without the patch: then no ICE accurs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
--- Comment #14 from Roger Sayle ---
My apologies for the delay/issues. My bootstrap and regression testing of this
patch (on x86_64-pc-linux-gnu) revealed an issue or two (including the reported
ICE). My plan was to fix/resolve all these befo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
--- Comment #13 from Wilhelm M ---
Yes, the ICE is with the patch. I'm pretty sure that this does not happen
without the patch, but I will that check again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
--- Comment #12 from Segher Boessenkool ---
With the modified compiler? Does it ICE with an unmodified compiler as well?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
--- Comment #11 from Wilhelm M ---
After testing some more code, I got this ICE:
/home/lmeier/Projekte/wmucpp/boards/rcfoc/gimbal_sbus_01.cc: In static member
function 'static void GlobalFsm::ratePeriodic() [with BusDevs
=BusDevs > >]':
/home/l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
--- Comment #10 from Richard Biener ---
(In reply to Roger Sayle from comment #7)
> Created attachment 54843 [details]
> proposed patch
>
> Proposed patch. Does this look reasonable?
Yes, but doesn't this work for all GET_CODE (op) != ASHIFTR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
--- Comment #9 from Segher Boessenkool ---
That patch looks fine :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
--- Comment #8 from Wilhelm M ---
Yes. Looks like the patch does its job.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
--- Comment #6 from Wilhelm M ---
The following "solution"
constexpr uint16_t mul(const uint8_t a, const uint16_t b) {
const auto aa = std::bit_cast>(b);
return aa[1] * a;
}
or
constexpr uint16_t mul(const uint8_t a, const uint16_t b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
--- Comment #5 from Segher Boessenkool ---
Correct, this certainly can not be done by combine, it see two independent
pseudos here. For hard registers it *can* do many tricks, but not for
pseudos like this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
Richard Biener changed:
What|Removed |Added
Component|target |rtl-optimization
Ever confirmed|0
16 matches
Mail list logo
