[Bug c/99872] New: [11 Regression] optimizations sometimes lead to missing asm prefixes

[Bug c/99872] New: [11 Regression] optimizations sometimes lead to missing asm prefixes

[jyong at gcc dot gnu.org]

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

            Bug ID: 99872
           Summary: [11 Regression] optimizations sometimes lead to
                    missing asm prefixes
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jyong at gcc dot gnu.org
  Target Milestone: ---
              Host: x86_64-pc-linux-gnu
            Target: x86_64-w64-mingw32
             Build: x86_64-pc-linux-gnu

Created attachment 50497
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50497&action=edit
lib32_libmingwex_a-pow.c test case

Compiling with the following command line:
x86_64-w64-mingw32-gcc -O2 -c lib32_libmingwex_a-pow.c -std=gnu99 -m32

Causes an undefined symbols with the wrong asm prefixes to be emitted:
00000000 T ___attribute__pow
00000010 B ___attribute__pow_d
00000008 B ___attribute__pow_x
00000000 B ___attribute__pow_y
00000000 b .bss
00000000 d .data
         U ___fpclassify
         U _internal_modf
         U LC5
         U _LC6
00000000 r .rdata
00000000 r .rdata$zzz
         U ___signbit
00000000 t .text

Adding -fno-leading-underscore makes the symbols resolved, 32bit Windows code
is supposed to have a leading underscore.

[Bug c/99872] [11 Regression] optimizations sometimes lead to missing asm prefixes

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.0
   Last reconfirmed|                            |2021-04-06
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Are you saying your provided __fpclassify should not have another underscore?

[Bug c/99872] [11 Regression] optimizations sometimes lead to missing asm prefixes

[jyong at gcc dot gnu.org]

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

--- Comment #2 from jyong at gcc dot gnu.org ---
No, its the internal compiler symbols like LC5 and _LC6 generated by GCC
ignoring the underscore prefix setting for the target, causing GAS to emit them
as external undefined symbols. LD fails to find the symbols to satisfy them
upon linking.

32bit Windows PE symbols should come with an underscore prefix, this does not
apply to 64bit Windows code.

[Bug c/99872] [11 Regression] optimizations sometimes lead to missing asm prefixes

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So perhaps it was my r11-2944-g0106300f6c3f7bae5eb1c46dbd45aa07c94e1b15
that broke it?
Seems mingw -m32 uses empty LOCAL_LABEL_PREFIX:
#define LOCAL_LABEL_PREFIX (TARGET_64BIT ? "." : "")
and so emits:
        flds    LC1
...
        .section .rdata,"dr"
        .align 4
LC1:
        .long   -8388608
        .align 4
LC2:
        .long   2139095040
etc.
But on the testcase it emits:
        .set    _LC5,_LC6
If you change manually that .set _LC5,_LC6 to .set LC5,LC6, does it work then?

[Bug target/99872] [11 Regression] optimizations sometimes lead to missing asm prefixes

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 50511
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50511&action=edit
gcc11-pr99872.patch

So perhaps this patch?
I went through all ASM_OUTPUT_DEF definitions and all of them use assemble_name
for each of the last 2 arguments separately, and assemble_name should handle
the
* etc. at the start of the symbols.
Verified with the cross to mingw -m32 that it now emits .set LC5,LC6, and
verified that on x86_64-linux it didn't change anything e.g. on the testcase
mentioned in the commit message.

I have no way to test this on mingw32, neither 32-bit nor 64-bit, but will test
it on x86_64-linux and i686-linux tonight.

[Bug target/99872] [11 Regression] optimizations sometimes lead to missing asm prefixes

[jyong at gcc dot gnu.org]

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

--- Comment #5 from jyong at gcc dot gnu.org ---
I'll test out the patch soon.

[Bug target/99872] [11 Regression] optimizations sometimes lead to missing asm prefixes

[jyong at gcc dot gnu.org]

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

--- Comment #6 from jyong at gcc dot gnu.org ---
I can confirm the symbols are correctly generated regardless of
-fno-leading-underscore or not, the internal symbols are no longer emitted as
undefined after assembly.

GCC can also finish building the target libraries without any problems for
32bit MinGW.

[Bug target/99872] [11 Regression] optimizations sometimes lead to missing asm prefixes

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org
           Priority|P3                          |P1

[Bug target/99872] [11 Regression] optimizations sometimes lead to missing asm prefixes

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:b51321bc5193b65b308a26663fc02f786ba6cc89

commit r11-8028-gb51321bc5193b65b308a26663fc02f786ba6cc89
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Apr 7 15:51:15 2021 +0200

    varasm: Fix up constpool alias handling [PR99872]

    Last year, I have added in
r11-2944-g0106300f6c3f7bae5eb1c46dbd45aa07c94e1b15
    (aka PR54201 fix) code to find bitwise duplicates in constant pool and
output
    them as aliases instead of duplicating the data.

    Unfortunately this broke mingw32 -m32.
    On most targets, ASM_GENERATE_INTERNAL_LABEL with "LC" emits something like
    *.LC123 and the targets don't add user label prefixes, so the aliases
    that we print should be something like
            .set    .LC5, .LC6
    or
            .set    .LC5, .LC6 + 8
    and I wasn't sure if ASM_OUTPUT_DEF can handle the * and therefore I have
    stripped it.
    But, on mingw32 -m32, ASM_GENERATE_INTERNAL_LABEL with "LC" emits
    *LC123 and the target has user label prefixes, which means what I wrote
    results in
    LC6:
            ...
            .set    _LC5, _LC6
    which results in unresolved symbols.  I went through the ASM_OUTPUT_DEF
    definitions of all targets and all of them use assemble_name twice under
    the hood (with various differences on what they print before, in between or
    after those names).  And assemble_name handles the name encoding properly,
    so if we pass it ASM_OUTPUT_DEF (..., "*.LC123", "*.LC456+16") it will
    emit .LC123 and .LC456+16 and if we pass it "*LC789", it will emit
    LC789.

    2021-04-07  Jakub Jelinek  <jakub@redhat.com>

            PR target/99872
            * varasm.c (output_constant_pool_contents): Don't strip name
encoding
            from XSTR (desc->sym, 0) or from label before passing those to
            ASM_OUTPUT_DEF.

[Bug target/99872] [11 Regression] optimizations sometimes lead to missing asm prefixes

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Hopefully fixed.