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

            Bug ID: 121719
           Summary: inline asm defining label + -O2 -flto
                    -ffat-lto-objects result in duplicated symbol
           Product: gcc
           Version: 15.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: romain.geissler at amadeus dot com
  Target Milestone: ---

Hi,

When building this specific ARM64 test case of valgrind
(https://sourceware.org/git/?p=valgrind.git;a=blob_plain;f=memcheck/tests/arm64/bug484935.c;hb=HEAD)
I noticed something that I think is a bug. When some inline asm defines a
label, it seems that using the CFLAGS "-O2 -flto -ffat-lto-objects". Here is
some stripped down reproducer (for ARM64, I didn't check if similarly with
x86_64 asm defining some label we have the same issue):

void* load_memory_content(void** ptr)
{
   void* result;
   __asm__ volatile(
      // load x0, x1, x2 with data from ptr, and loop for a while. If we get
      // a signal in the loop, these registers have uninitialized data in
      // them, but should be valid inside the signal handler. Without our
      // patch, valgrind complains. We can remove the individual lines from
      // the patch, and see each argument in turn affecting valgrind
      "LDR x0, [%1]\n"
      "LDR x1, [%1, #8]\n"
      "LDR x2, [%1, #16]\n"
      "mov %0, x0\n"
      "mov x3, #2000\n"
      "loop:"
      " subs x3, x3, #1\n"
      " b.ne loop\n"
      : "=r"(result)
      : "r"(ptr)
      : "x0", "x1", "x2", "x3");
   return result;
}

int main() {
        load_memory_content(0);
}


[root@c361dae39680 reproducer]# /opt/1A/toolchain/aarch64-v25/bin/gcc -O2 -flto
-ffat-lto-objects -c -o bug484935.o bug484935.c
/tmp/cc9T5yCB.s: Assembler messages:
/tmp/cc9T5yCB.s:115: Error: symbol `loop_bug484935' is already defined

It's also reproducible on Compiler Explorer: https://godbolt.org/z/7d9MEfdh3

Interestingly, clang (when also using recent version that supports fat LTO
objects) behaves exactly the same way. So if both compiler do agree, does it
mean this valgrind test case is actually wrongly written and there shouldn't be
ASM labels defined like this ?

Cheers,
Romain

Reply via email to