[Bug ipa/101382] function declarations with identical asm label aliasing a target function does not compile with -flto

2021-07-29 Thread fparzefall at pjrcorp dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101382

--- Comment #2 from Fabian Parzefall  ---
I am wondering whether LTO is wrong or the default handling when not using LTO
is wrong. As I understand it, the assembly that is generated in this case is
correct. The documentation of GNU as even states:

You may .set a symbol many times in the same assembly provided that the
values given to the symbol are constants. [1]

If I read it right, it is acceptable to even define the symbol multiple times
with different values. From a compiler perspective however in the above code
snippet, x is being defined twice, first through b's and then through c's alias
attribute. In this case, this is harmless, but gcc does not even complain if
the alias of one of them is changed to some different function with an entirely
different signature.

I don't see a technical reason, why GCC should not emit an error here when
symbols with the same asm label are defined twice within a single TU. Either
both declaration are identical, so one of them can be removed, or they differ,
which is probably undefined behavior. Please correct me, if I miss the obvious.

Of course existing code would break (including some code in glibc), so I am not
suggesting this is how this should be fixed. Maybe there could be a warning
when the same asm symbol is defined twice?


[1] https://sourceware.org/binutils/docs/as/Set.html

[Bug ipa/101382] function declarations with identical asm label aliasing a target function does not compile with -flto

2021-07-09 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101382

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||lto
  Component|lto |ipa
 Ever confirmed|0   |1
   Last reconfirmed||2021-07-09
 CC||hubicka at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Confirmed.  I think that's some general issue in the IPA symtab.  Without LTO
we produce

.globl  x
.setx,a
.globl  x
.setx,a

which an assembler might eventually reject.