https://sourceware.org/bugzilla/show_bug.cgi?id=28867
--- Comment #7 from Nick Clifton <nickc at redhat dot com> --- Hi Eric, Thanks for the files. I was able to confirm that the fail.o file really is broken. However I am unable to reproduce its generation. That is, I cannot assemble the fail.s file and get a broken object file. I tried using the 2.37-3.fc35 mingw-binutils as well as the current mainline sources and both produced good object files. I tried both with the LANG environment variable to fr_FR.utf8, and set to en_GB.UTF-8, but that did not change anything. Possibly there is an assembler command line option that is missing from my tests. Are you able to capture gcc's assembler command line and check ? For reference this is the test I ran in a Fedora 35 mock chroot: % export LANG="fr_FR.utf8" % i686-w64-mingw32-objdump -d fail.o > /dev/null i686-w64-mingw32-objdump: fail.o: unrecognized storage class 0 for *UND* symbol `ì' % i686-w64-mingw32-as fail.s -o fred.o % i686-w64-mingw32-objdump -d fred.o > /dev/null % Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
