[Bug lto/109854] New: Error: junk `(%rip)' after expression when using -flto on files compiled with and without -masm=intel

[Bug lto/109854] New: Error: junk `(%rip)' after expression when using -flto on files compiled with and without -masm=intel

[bouanto at zoho dot com]

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

            Bug ID: 109854
           Summary: Error: junk `(%rip)' after expression when using -flto
                    on files compiled with and without -masm=intel
           Product: gcc
           Version: 13.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bouanto at zoho dot com
                CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Hi.
With those two source files:

a.c:

#include <stdio.h>

void a(void) {
    puts("A");
}

main.c:

void a(void);

int main(void) {
    a();
    return 0;
}

and by running the following commands:

gcc -c -flto a.c              # Note the absence of -masm=intel
gcc -masm=intel -O3 -flto a.o main.c -o main

I get the following error:

/tmp/cca9LQNs.s: Assembler messages:
/tmp/cca9LQNs.s:17: Error: junk `(%rip)' after expression
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 the a.c file with -masm=intel solves the issue.

(Doing the opposite, that is compiling a.c with -masm=intel and main.c without
gives a different error: /usr/bin/ld: /tmp/ccMwJTwN.ltrans0.ltrans.o:
relocation R_X86_64_32S against undefined symbol `$8' can not be used when
making a PIE object; recompile with -fPIE
Please tell me if you want me to open a different issue for this case.)

Thanks to fix this issue.

[Bug target/109854] Error: junk `(%rip)' after expression when using -flto on files compiled with and without -masm=intel

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2023-05-15

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
I get instead

/usr/bin/ld: /tmp/cc9ZP9FF.ltrans0.ltrans.o: in function `a':
<artificial>:(.text+0x7): undefined reference to `$.LC0'
collect2: error: ld returned 1 exit status

I would recommend against mixing different -masm dialects since at least
for inline asm that can lead to different asm dialects being mixed.

[Bug target/109854] Error: junk `(%rip)' after expression when using -flto on files compiled with and without -masm=intel

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The assembler (at least gas) can do it, it has directives to change the
dialect.
ix86_asm_dialect is already TargetSave, so I think all we'd need is emit
directive to switch asm dialect if it differs from the previously emitted (or
sorry if assembler doesn't support those directives).

[Bug target/109854] Error: junk `(%rip)' after expression when using -flto on files compiled with and without -masm=intel

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
As for inline asm, one has always the possibility to support both through the
{att|intel} syntax, not really sure in which dialect toplevel asms would be
emitted though, and whether we allow inlining between functions in different
asm dialects (if yes, then of course all the inline asms in the mixed
environment would need to be written to support both dialects).