https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90293
--- Comment #4 from Zev Weiss ---
I have no idea about the relative ease of implementation, but might it at least
partially suffice for the compiler to propagate the information provided by
__builtin_expect() beyond the expression it appears in?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85185
--- Comment #9 from Zev Weiss ---
I've just encountered another related-looking problem -- the inline asm sees
0xfffc here instead of the intended 0xfffc:
$ cat x.c
static inline void foo(unsigned short n)
{
__asm__("foo %0" :: "r"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85185
--- Comment #5 from Zev Weiss ---
Created attachment 43837
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43837&action=edit
codegen & RTL dump for aarch64 & avr
(Attached generated code & -fdump-rtl-expand output for aarch64 and avr, both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85185
--- Comment #4 from Zev Weiss ---
I'm afraid I'm not quite GCC-savvy enough to know exactly what PROMOTE_SUBREG
refers to or which targets it covers (a quick grep of the source tree didn't
appear turn up any clues).
As for the RTL (hopefully I'v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85185
--- Comment #2 from Zev Weiss ---
I was wondering if I might be unwittingly violating some subtle rule like that;
are the details of this documented? I don't see anything obvious in section
6.45.2.5 ("Input Operands") of the GCC manual, but per
: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: zev+gccbug at bewilderbeest dot net
Target Milestone: ---
Created attachment 43832
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43