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

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

[fabian.parzefall at mailbox dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101382

            Bug ID: 101382
           Summary: function declarations with identical asm label
                    aliasing a target function does not compile with -flto
           Product: gcc
           Version: 11.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: fabian.parzefall at mailbox dot org
                CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 51120
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51120&action=edit
Input reproducing the bug

GCC cannot compile a module containing two function declarations with the same
asm label and the same alias attribute when -flto is enabled. Here is an
excerpt from the attachment:

    void a(void) { ... }
    extern typeof(a) b asm("x") __attribute__((alias("a")));
    extern typeof(a) c asm("x") __attribute__((alias("a")));

When compiling with:

    gcc -flto -c -o gcc-lto-asm-label-bug.o gcc-lto-asm-label-bug.c
    gcc -flto -o gcc-lto-asm-label-bug gcc-lto-asm-label-bug.o

The second command invoked produces this error message:

    lto1: fatal error: missing resolution data for *x
    compilation terminated.
    lto-wrapper: fatal error: gcc returned 1 exit status
    compilation terminated.
    /usr/bin/ld: error: lto-wrapper failed
    collect2: error: ld returned 1 exit status

Compiling without -flto works as expected. GCC versions tested are 9.3.0 and
11.1.0 on Ubuntu 20.04.

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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101382

Richard Biener <rguenth at gcc dot gnu.org> 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 <rguenth at gcc dot gnu.org> ---
Confirmed.  I think that's some general issue in the IPA symtab.  Without LTO
we produce

        .globl  x
        .set    x,a
        .globl  x
        .set    x,a

which an assembler might eventually reject.

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

[fparzefall at pjrcorp dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101382

--- Comment #2 from Fabian Parzefall <fparzefall at pjrcorp dot com> ---
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