https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99143
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99143
--- Comment #7 from Jakub Jelinek ---
See e.g.
https://lore.kernel.org/linux-toolchains/20201022073816.gq2...@hirez.programming.kicks-ass.net/T/#mb5c0e7711db14091d8d7dcbe0f4087f2fb65b6db
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99143
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99143
--- Comment #5 from Andreas Schwab ---
That's still sacrificing speed for space.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99143
--- Comment #4 from Will ---
That's great to know and I may use it as a stopgap/workaround, but it's not so
much about saving space as preserving the packing behavior of sections that
seems to work as expected on other architectures (even 64bit o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99143
--- Comment #3 from Andreas Schwab ---
If you want to save space you should use -Os, not -O2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99143
--- Comment #2 from Will ---
The issue is that these are not getting aligned down to the size of the type
causing extra space in the linker sets. The above may be a bad reduced test
case. Below is a test case that focuses on 4-byte alignment whic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99143
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-02-17
Status|UNCONFIRME
