[Bug target/113700] libgcc_s does not include symbols for _Float16 and __bf16 on Solaris/Illumos even though gcc generates code for _Float16 and __bf16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113700 Rainer Orth changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Assignee|unassigned at gcc dot gnu.org |ro at gcc dot gnu.org --- Comment #13 from Rainer Orth --- Mine. Fixed for GCC 14.0.0. Thanks for the report.
[Bug target/113700] libgcc_s does not include symbols for _Float16 and __bf16 on Solaris/Illumos even though gcc generates code for _Float16 and __bf16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113700 --- Comment #12 from GCC Commits --- The master branch has been updated by Rainer Orth : https://gcc.gnu.org/g:c5f48b5fdde849759d0e3b4effd9352a2399d6f9 commit r14-8820-gc5f48b5fdde849759d0e3b4effd9352a2399d6f9 Author: Rainer Orth Date: Tue Feb 6 10:20:30 2024 +0100 libgcc: Export i386 symbols added after GCC_7.0.0 on Solaris [PR113700] As reported in the PR, all libgcc x86 symbol versions added after GCC_7.0.0 were only added to i386/libgcc-glibc.ver, missing all of libgcc-sol2.ver, libgcc-bsd.ver, and libgcc-darwin.ver. This patch fixes this for Solaris/x86, adding all of them (GCC_1[234].0.0) as GCC_14.0.0 to not retroactively change history. Since this isn't the first time this happens, I've added a note to the end of libgcc-glibc.ver to request notifying other maintainers in case of additions. Tested on i386-pc-solaris2.11. 2024-02-01 Rainer Orth libgcc: PR target/113700 * config/i386/libgcc-sol2.ver (GCC_14.0.0): Added all symbols from i386/libgcc-glibc.ver (GCC_12.0.0, GCC_13.0.0, GCC_14.0.0). * config/i386/libgcc-glibc.ver: Request notifications on updates.
[Bug target/113700] libgcc_s does not include symbols for _Float16 and __bf16 on Solaris/Illumos even though gcc generates code for _Float16 and __bf16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113700 --- Comment #11 from Iain Sandoe --- (In reply to Rainer Orth from comment #10) > Patch posted. FWIW Darwin is, indeed, also affected and I have patches in progress to resolve it.
[Bug target/113700] libgcc_s does not include symbols for _Float16 and __bf16 on Solaris/Illumos even though gcc generates code for _Float16 and __bf16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113700 Rainer Orth changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-Februar ||y/645035.html --- Comment #10 from Rainer Orth --- Patch posted.
[Bug target/113700] libgcc_s does not include symbols for _Float16 and __bf16 on Solaris/Illumos even though gcc generates code for _Float16 and __bf16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113700 --- Comment #9 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9f5caef53e7808fef2baf8e6ffac230b9863 commit r14-8750-g9f5caef53e7808fef2baf8e6ffac230b9863 Author: Jakub Jelinek Date: Fri Feb 2 11:46:34 2024 +0100 libgcc: Export XF, TF, HF and BFmode specific _BitInt symbols from libgcc_s.so.1 [PR113700] Rainer pointed out that __PFX__ and __FIXPTPFX__ prefix replacement is done solely for libgcc-std.ver.in and not for the *.ver files in config. I've used the __PFX__ prefix even in config/i386/libgcc-glibc.ver because it was used for similar symbols in libgcc-std.ver.in, and that results in those symbols being STB_LOCAL in libgcc_s.so.1. Tests still work because gcc by default uses -static-libgcc when linking (unlike g++ etc.), but would have failed when using -shared-libgcc (but I see nothing in the testsuite actually testing with -shared-libgcc, so am not adding tests). With the patch, libgcc_s.so.1 now exports __fixtfbitint@@GCC_14.0.0 FUNC GLOBAL DEFAULT __fixxfbitint@@GCC_14.0.0 FUNC GLOBAL DEFAULT __floatbitintbf@@GCC_14.0.0 FUNC GLOBAL DEFAULT __floatbitinthf@@GCC_14.0.0 FUNC GLOBAL DEFAULT __floatbitinttf@@GCC_14.0.0 FUNC GLOBAL DEFAULT __floatbitintxf@@GCC_14.0.0 FUNC GLOBAL DEFAULT on x86_64-linux which it wasn't before. 2024-02-02 Jakub Jelinek PR target/113700 * config/i386/libgcc-glibc.ver (GCC_14.0.0): Remove __PFX prefixes from symbol names.
[Bug target/113700] libgcc_s does not include symbols for _Float16 and __bf16 on Solaris/Illumos even though gcc generates code for _Float16 and __bf16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113700 --- Comment #8 from Jakub Jelinek --- The reason tests work is that we default to -static-libgcc in C, which contains the symbols.
[Bug target/113700] libgcc_s does not include symbols for _Float16 and __bf16 on Solaris/Illumos even though gcc generates code for _Float16 and __bf16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113700 --- Comment #7 from Jakub Jelinek --- I didn't know what it is. But seems you're right, on x86_64-linux 252: 0001c1c0 1974 FUNCLOCAL DEFAULT 13 __floatbitintbf 253: 0001b200 1972 FUNCLOCAL DEFAULT 13 __fixxfbitint 262: 0001b9c0 2046 FUNCLOCAL DEFAULT 13 __floatbitinthf 266: 0001c980 1934 FUNCLOCAL DEFAULT 13 __floatbitintxf 271: 00019220 2271 FUNCLOCAL DEFAULT 13 __fixtfbitint 276: 00019b00 2166 FUNCLOCAL DEFAULT 13 __floatbitinttf aren't exported even when they should be. Let me change it.
[Bug target/113700] libgcc_s does not include symbols for _Float16 and __bf16 on Solaris/Illumos even though gcc generates code for _Float16 and __bf16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113700 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE --- When looking at the 64-bit libgcc_s.so.1 on both Solaris/x86 and Linux/i686, I noticed that all the new GCC_14.0.0 symbols from libgcc-glibc.ver (and now libgcc-sol2.ver) have been demoted to local. IIUC, this happens because the __PFX__ handling (substitution by $(LIBGCC_VER_GNU_PREFIX) as needed) is only applied to libgcc-std.ver.in by Makefile.in. In the i386/libgcc-*.ver files, this substitution doesn't happen, the literal "__PFX__fixxfbitint" etc. symbols are not found in any object, so the unprefixed ones are turned local. >From what I could see in config.host, LIBGCC_VER_GNU_PREFIX only applies to non-x86 targets. Maybe we can just remove __PFX__ from i386/libgcc-*.ver? Jakub?
[Bug target/113700] libgcc_s does not include symbols for _Float16 and __bf16 on Solaris/Illumos even though gcc generates code for _Float16 and __bf16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113700 Rainer Orth changed: What|Removed |Added CC||andreast at gcc dot gnu.org, ||iains at gcc dot gnu.org, ||jakub at gcc dot gnu.org Target|x86_64-*-solaris* |x86_64-*-solaris*, ||i?86-*-solaris* Target Milestone|--- |14.0 --- Comment #5 from Rainer Orth --- The problem is even more widespread than Solaris/x86: beside i386/libgcc-sol2.ver, there are i386/libgcc-darwin.ver (where the versions end at GCC_12.0.0) and i386/libgcc-bsdver (stops at GCC_7.0.0, used by both t-freebsd and t-dragonfly; the latter has no listed maintainer). I wonder if we should add a prominent note to the end of i386/libgcc-glibc.ver to notify other affected maintainers about additions. Those are way too easy to overlook right now.
[Bug target/113700] libgcc_s does not include symbols for _Float16 and __bf16 on Solaris/Illumos even though gcc generates code for _Float16 and __bf16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113700 --- Comment #4 from Niclas Rosenvik --- (In reply to Rainer Orth from comment #3) > (In reply to Niclas Rosenvik from comment #2) > > (In reply to Andrew Pinski from comment #1) > > > >I tried to add the gcc12 and up parts of > > > > > > It is correct except it should just use GCC 14 I think. > > > > I forgot to mention that the problem with _Float16 aka > > __extendhfdf2 has happened on gcc12 as well as gcc14. > > If it was possible to not just choose one version of > > gcc then I would have marked gcc12 to 14. > > You cannot add symbols to symbol versions of older releases retroactively. > Since those versions (GCC_12.0.0, GCC_13.0.0, GCC_14.0.0) were overlooked > before the respective releases, all symbols that are listed in > i386/libgcc-glibc.ver in those versions need to be added to > i386/libgcc-sol2.ver in version GCC_14.0.0 (after verifying that they are > actually defined on Solaris/x86). OK, thanks for explaining.
[Bug target/113700] libgcc_s does not include symbols for _Float16 and __bf16 on Solaris/Illumos even though gcc generates code for _Float16 and __bf16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113700 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-02-01 Ever confirmed|0 |1 --- Comment #3 from Rainer Orth --- (In reply to Niclas Rosenvik from comment #2) > (In reply to Andrew Pinski from comment #1) > > >I tried to add the gcc12 and up parts of > > > > It is correct except it should just use GCC 14 I think. > > I forgot to mention that the problem with _Float16 aka > __extendhfdf2 has happened on gcc12 as well as gcc14. > If it was possible to not just choose one version of > gcc then I would have marked gcc12 to 14. You cannot add symbols to symbol versions of older releases retroactively. Since those versions (GCC_12.0.0, GCC_13.0.0, GCC_14.0.0) were overlooked before the respective releases, all symbols that are listed in i386/libgcc-glibc.ver in those versions need to be added to i386/libgcc-sol2.ver in version GCC_14.0.0 (after verifying that they are actually defined on Solaris/x86).
[Bug target/113700] libgcc_s does not include symbols for _Float16 and __bf16 on Solaris/Illumos even though gcc generates code for _Float16 and __bf16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113700 --- Comment #2 from Niclas Rosenvik --- (In reply to Andrew Pinski from comment #1) > >I tried to add the gcc12 and up parts of > > It is correct except it should just use GCC 14 I think. I forgot to mention that the problem with _Float16 aka __extendhfdf2 has happened on gcc12 as well as gcc14. If it was possible to not just choose one version of gcc then I would have marked gcc12 to 14.
[Bug target/113700] libgcc_s does not include symbols for _Float16 and __bf16 on Solaris/Illumos even though gcc generates code for _Float16 and __bf16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113700 --- Comment #1 from Andrew Pinski --- >I tried to add the gcc12 and up parts of It is correct except it should just use GCC 14 I think.