On Mon, 17 Jan 2022 at 15:53, Iñaki Ucar <iucar@xxxxxxxxxxxxxxxxx> wrote: > > FlexiBLAS is FTBFS in rawhide [1], and upstream has managed to create a MWE that doesn't involve FlexiBLAS [2]. So it seems like an issue specific to CMake + GCC/GFortran 12 + CMake's FortranC Interface. Possible regression in gcc? > > Iñaki > > [1] https://koschei.fedoraproject.org/package/flexiblas?collection=f36 > [2] https://github.com/mpimd-csc/flexiblas/issues/20#issuecomment-1014597590 I found this is due to the LTO flags in FFLAGS, but this error doesn't happen with gcc 11. Should I disable LTO in FlexiBLAS for the time being? Iñaki > On Fri, 14 Jan 2022 at 15:40, Jakub Jelinek <jakub@xxxxxxxxxx> wrote: >> >> Hi! >> >> gcc 12 snapshot has landed as the system compiler into rawhide today. >> GCC 12 is going to enter its stage4 development phase (only regression >> and documentation bugfixes allowed) on Monday 17th, so there should be >> just those bugfixes and not new features etc. anymore. >> https://gcc.gnu.org/gcc-12/changes.html lists important changes, >> most important is probably that vectorization is enabled at -O2 now >> which is the option with most of the distribution is built with. >> >> https://gcc.gnu.org/gcc-12/porting_to.html is so far incomplete and lists >> some cases where people need to adjust their code. Other things >> include the usual C++ header changes, where previously some standard >> header included some other header as an implementation detail but it doesn't >> any longer and so code that relied on such indirect include that isn't >> required by the standard needs to include the header that provides whatever >> it relies on. Or e.g. packages using -Werror where new warnings are >> reported with the newer compiler and -Werror results in build failures. >> >> If there are bugs on the compiler side, please let me know immediately, >> so that those bugs can be fixed before the mass rebuild next week. >> >> Another important thing I wanted to say is that we'd like to switch >> ppc64le from the numerically problematic IBM extended long double to >> IEEE 754 quad long double. This is an ABI change. Some libraries >> are already built so that they support both ABIs at the same time, >> including glibc, libstdc++, libgcc, libgfortran etc. >> For other libraries and binaries, the compiler, assembler and linker >> will notice if they use long double and flag them as using either >> IBM or IEEE long double and linker (or I think dynamic linker too) >> might complain when things are mixed. >> Right now the rawhide gcc still defaults to -mabi=ibmlongdouble >> but the glibc/gcc libraries are built compatibly with both. >> We'd like to configure gcc shortly before the mass rebuild with >> --with-long-double-format=ieee so that it will default to >> -mabi=ieeelongdouble, probably on a side-tag build first, and it >> will be highly desirable to rebuild at least some of the most commonly >> used library packages in the order of dependencies there, otherwise >> I'd be afraid the mass rebuild could fail for way too many packages >> (as the mass rebuild doesn't do dependency order rebuilds but just >> goes through packages alphabetically or so). >> Any suggestions on which packages have commonly used library packages >> that use long double? >> readelf -A on libraries on ppc64le prints either nothing (either >> the library is thought not to use long double or supports both ABIs >> transparently or hasn't been rebuilt for some years), or >> Attribute Section: gnu >> File Attributes >> Tag_GNU_Power_ABI_FP: hard float, 128-bit IBM long double >> for libraries (or binaries or object files) that use IBM long double >> only or >> Attribute Section: gnu >> File Attributes >> Tag_GNU_Power_ABI_FP: hard float, 128-bit IEEE long double >> for IEEE long doubles. >> So I think we want to rebuild on a side-tag packages that >> provide shared libraries used by hundreds of other packages that >> are >> Tag_GNU_Power_ABI_FP: hard float, 128-bit IBM long double >> right now. >> >> Jakub >> _______________________________________________ >> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx >> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx >> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx >> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure > > > > -- > Iñaki Úcar -- Iñaki Úcar _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
