https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91322
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
Target Mil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91322
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91322
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91322
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|WAITING
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91322
Wilco changed:
What|Removed |Added
CC||wdijkstr at arm dot com
--- Comment #2 from Wilc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91322
--- Comment #3 from Martin Liška ---
(In reply to Wilco from comment #2)
> (In reply to Martin Liška from comment #1)
> > I've just run the test-case on aarch64 and it works fine (-O2, -O2 -flto,
> > -O3 -flto -fno-early-inlining). And lto.exp te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91322
Martin Liška changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91322
--- Comment #5 from Christophe Lyon ---
Created attachment 48183
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48183&action=edit
executable asm from objdump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91322
--- Comment #6 from Christophe Lyon ---
Created attachment 48184
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48184&action=edit
GCC passes dumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91322
--- Comment #7 from Christophe Lyon ---
Created attachment 48185
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48185&action=edit
qemu execution trace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91322
--- Comment #8 from Jan Hubicka ---
Do we have compile farm machine where this can be reproduced?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91322
--- Comment #9 from Martin Liška ---
(In reply to Jan Hubicka from comment #8)
> Do we have compile farm machine where this can be reproduced?
I guess we don't have any.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91322
--- Comment #10 from Wilco ---
(In reply to Christophe Lyon from comment #6)
> Created attachment 48184 [details]
> GCC passes dumps
So according to that, in 105t.vrp1 it removes the branch and unconditionally
calls abort:
Folding statement: _4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91322
--- Comment #11 from Jan Hubicka ---
The problem is that on ARM sizeof (short) == sizeof (int)
and LTO will glob all short and int pointers together. So this is missed
optimization only.
We do this globing sort of by design. For GCC11 I plan to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91322
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91322
--- Comment #13 from Jan Hubicka ---
> Which ARM target has 16-bit int?
> I don't see INT_TYPE_SIZE nor SHORT_TYPE_SIZE defined in config/arm/*, neither
> BITS_PER_WORD, so all depends on UNITS_PER_WORD, which is 4 and thus short is
> 16-bit and
> Which ARM target has 16-bit int?
> I don't see INT_TYPE_SIZE nor SHORT_TYPE_SIZE defined in config/arm/*, neither
> BITS_PER_WORD, so all depends on UNITS_PER_WORD, which is 4 and thus short is
> 16-bit and int is 32-bit.
Hmm, you are right - I messed up target triplets. With arm-linux-gnueabi
I
17 matches
Mail list logo