https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113337
jyong at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113850
jyong at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108192
jyong at gcc dot gnu.org changed:
What|Removed |Added
CC||jyong at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109
jyong at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55886
jyong at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100383
jyong at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2021-05-03
Status
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
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.
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 fi
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #60 from jyong at gcc dot gnu.org ---
Thanks all for debugging and finding a solution.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #56 from jyong at gcc dot gnu.org ---
OK, I've tested the patch from attachment 50461, seems to work fine:
gcc uses dwarf 4 by default if it does find a broken linker, but allows the
user to specify -gdwarf-5 if they want, resulting in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #52 from jyong at gcc dot gnu.org ---
Oops I need retest with optimizations enabled to see the debug sections
emitted.
On the other hand, the new adjusted patch detects the binutils bug fine, tested
with new and old binutils.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
jyong at gcc dot gnu.org changed:
What|Removed |Added
Attachment #50459|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #50 from jyong at gcc dot gnu.org ---
I'll try testing it out over the next few days, thanks for the patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #48 from jyong at gcc dot gnu.org ---
Now that's an interesting trick I never thought of.
There's LLVM based mingw, but I have never used nor do I know if it is relevant
here. Gold is ELF only as far as I know, so it would never be us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #46 from jyong at gcc dot gnu.org ---
Is there a machine parsable output from objdump? I'm not sure if using gawk
would be OK. Such a test also won't work in build != host conditions.
I'm considering just having a notice in the gcc-11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #43 from jyong at gcc dot gnu.org ---
Is it as simple as running the following?
${target}-objdump -j .debug_loclists -h a.exe | grep -q 0001
A return code 0 means potentially broken linker script is used.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #40 from jyong at gcc dot gnu.org ---
Personally I'm fine with gcc configure warning of a potentially broken binutils
dwarf5 handing when targeting mingw/cygwin with binutils 2.35.1 or earlier.
How do you even parse binutils versions?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99234
jyong at gcc dot gnu.org changed:
What|Removed |Added
CC||ktietz70 at googlemail dot com,
20 matches
Mail list logo
