[Bug c/99872] [11 Regression] optimizations sometimes lead to missing asm prefixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99872 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- 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: fldsLC1 ... .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 c/99872] [11 Regression] optimizations sometimes lead to missing asm prefixes
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99872 Richard Biener 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 --- Are you saying your provided __fpclassify should not have another underscore?
