> 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. a quick&dirty scan of /usr/lib64 on my F-34 workstation shows many ./libQt5* many ./libLLVM* ./libgobject-2.0 ./libgio-2.0 ./libglib-2.0 ./libexiv2-xmp ./libhwy ./python3.9/site-packages/numpy/* ./libSDL2 ./libiberty ./clang/12.0.1/lib/libclang_rt.builtins-powerpc64le.a ./ghdl/llvm/libgrt.a ./libc as users of the Tag_GNU_Power_ABI_FP attribute. A vast majority of the hits are "Tag_GNU_Power_ABI_FP: hard float, unspecified long double" Translated to packages it is qt5-*, llvm + clang, numpy, SDL2, glib2, exiv2, glibc, highway

> The -mabi=ieeelongdouble defaulting gcc is now in the > f36-build-side-49600 side-tag (gcc -0.5.1.fc36, same as -0.5.fc36 in > rawhide except for the different ppc64le default ABI). is it right, that the attribute appears only in static libs? I did a scratch build for glib2 (https://koji.fedoraproject.org/koji/taskinfo?taskID=81396901) and "readelf -A libglib-2.0.so.0.7100.0" shows nothing, but "readelf -A libglib-2.0.a" returns "Tag_GNU_Power_ABI_FP: hard float, 128-bit IEEE long double" for some *.o files in the archive.

gcc 12 snapshot has landed as the system compiler into rawhide today.

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.

Rebuilding folly, and building the latest tagged release, both fail with GCC 12: https://bugzilla.redhat.com/show_bug.cgi?id=2042690 It happens that libfmt has also been upgraded, so it's hard to pinpoint. I'm going to see if I can tag a scratch build of the newer fmt on a F35 sidetag so we can rule that out.

Ceph fails with gcc-12 too. scratch build at https://koji.fedoraproject.org/koji/taskinfo?taskID=81280838 upstream ceph bug at https://tracker.ceph.com/issues/53896

I tried recompiling qemu and it fails with an odd error in the RCU torture test. Bug submitted upstream here: https://gitlab.com/qemu-project/qemu/-/issues/823 ... but since GCC 12 is the only big thing that has changed since we just rebuilt qemu, could that be a reason? https://gitlab.com/qemu-project/qemu/-/blob/1cd2ad11d37c48f284f557954e1df... Anyway I'll try to nudge someone on the virt team who knows about these things to take a look.

Perhaps Paolo Bonzini is familiar with both qemu and gcc...

On 17/01/2022 15:00, Ben Beasley wrote: > dependency “json”: https://github.com/nlohmann/json/issues/3138 https://bugzilla.redhat.com/show_bug.cgi?id=2041187

On Mon, 2022-01-17 at 14:36 +0000, Sérgio Basto wrote: > On Mon, 2022-01-17 at 15:10 +0100, Vitaly Zaitsev via devel wrote: > > On 17/01/2022 15:00, Ben Beasley wrote: > > > dependency “json”: https://github.com/nlohmann/json/issues/3138 > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2041187 > > > > Rawhide compose doomed again [1] :( , I still haven't the results of > koschei opencv altivec build with gcc-12.0.0-0.5, it failed with gcc- > 12.0.0-0.4 [2] > Build with gcc-12.0.0-0.5 not fixed the error related with altivec https://bugzilla.redhat.com/show_bug.cgi?id=2041573

On Mon, 17 Jan 2022 at 14:01, Ben Beasley <code(a)musicinmybrain.net&gt; wrote: > Skimming through Koschei, here are a sampling of regressions that seem > to be associated with GCC 12. Some of these are in packages I maintain > directly; others are via @neuro-sig. > > With a few exceptions, I have triaged these only to the extent of > confirming the problem appeared at the same time as GCC 12 and noting > the initial error. I mostly haven’t gotten around to filing or searching > for bugs, upstream or downstream. > > Explicit deletion of the > std::string(nullptr_t)/std::string_view(nullptr_t) constructors seems > like it is going to be a popular cause of FTBFS in C++ packages. Use of > this constructor mostly happens implicitly. I think explicit use of the > default constructor, e.g. std::string_view(), will usually be the > simplest correct substitute. > All such uses were undefined behaviour (and should have thrown an exception at runtime if the code was ever executed. Fixing those is good.

> New compilation errors: > > COPASI: “error: passing 'const CDataVectorN<CCopasiTask>' as 'this' > argument discards qualifiers [-fpermissive]” > What's the context? Is that being used as a comparison function in a std:: container or something? > > grpc: initializing std::string_view/absl::string_view with nullptr – > fixed and PR sent upstream > > python-steps: “static assertion failed: key equality predicate must be > invocable with two arguments of key type” via > c++/12/bits/hashtable_policy.h > Maybe a variant of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103923 > > vxl: “error: conversion from 'int' to 'std::__cxx11::basic_string<char>' > is ambiguous” – looks like an attempt to initialize a string by > std::string(nullptr), which is now explicitly deleted > (“basic_string(nullptr_t) = delete”) > If it's actually initializing it with nullptr, that's just undefined (and going to be ill-formed in C++23) and the code should be fixed. If it's like the nlohmann:json case, I need to investigate more whether it's a defect in the C++23 spec or the code should be fixed.

> **Compilation error from a dependency header:** > > dependency “boost”: “# error "Never use <bmiintrin.h> directly; include > <x86intrin.h> instead."”, via > boost/multiprecision/cpp_int/intel_intrinsics.hpp This is weird. bmiintrin.h had: #ifndef _X86GPRINTRIN_H_INCLUDED # error "Never use <bmiintrin.h> directly; include <x86gprintrin.h> instead." #endif in both gcc 11 and 12. In fact, most of the more recent *intrin.h headers want users to only use one of x86intrin.h, x86gprintrin.h or maybe immintrin.h.

On Wed, Jan 26, 2022 at 01:29:37PM +0100, Dan Horák wrote: > > > **Compilation error from a dependency header:** > > > > > > dependency “boost”: “# error "Never use <bmiintrin.h> directly; include > > > <x86intrin.h> instead."”, via > > > boost/multiprecision/cpp_int/intel_intrinsics.hpp > > > > This is weird. > > bmiintrin.h had: > > #ifndef _X86GPRINTRIN_H_INCLUDED > > # error "Never use <bmiintrin.h> directly; include <x86gprintrin.h> instead." > > #endif > > in both gcc 11 and 12. In fact, most of the more recent *intrin.h headers > > want users to only use one of x86intrin.h, x86gprintrin.h or maybe > > immintrin.h. > > this is being discussed in > https://github.com/boostorg/multiprecision/issues/419 Ah, ppc*, that indeed looks like a gcc bug.

> debugbreak: %check uses gdb, which now crashes (“(core dumped) gdb -q -x > "${exe}-rpm-test.gdb" --batch < /dev/null”) on ppc64le/x86_64, but not on > aarch64 If gdb crashes, it would be nice if somebody from the gdb team had a look, of course it can be a gcc bug too.

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(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

On Mon, 17 Jan 2022 at 15:53, Iñaki Ucar <iucar(a)fedoraproject.org&gt; 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? > > [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 tried compiling colobot with the new gcc, expecting it to break in some new and fascinating way, and got the following error: In function 'std::char_traits<char>::copy(char*, char const*, unsigned long)', inlined from 'std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_S_copy(char*, char const*, unsigned long)' at /usr/include/c++/12/bits/basic_string.h:423:21, inlined from 'std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_S_copy(char*, char const*, unsigned long)' at /usr/include/c++/12/bits/basic_string.h:418:7, inlined from 'std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_replace(unsigned long, unsigned long, char const*, unsigned long)' at /usr/include/c++/12/bits/basic_string.tcc:532:22, inlined from 'std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::assign(char const*)' at /usr/include/c++/12/bits/basic_string.h:1645:19, inlined from 'std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::operator=(char const*)' at /usr/include/c++/12/bits/basic_string.h:813:28, inlined from 'Ui::CList::SetItemName(int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' at /builddir/build/BUILD/colobot-colobot-gold-0.2.0-alpha/src/ui/controls/list.cpp:664:28: /usr/include/c++/12/bits/char_traits.h:431:56: error: 'memcpy' accessing 9223372036854775810 or more bytes at offsets -4611686018427387902 and [-4611686018427387903, 4611686018427387904] may overlap up to 9223372036854775813 bytes at offset -3 [-Werror=restrict] 431 | return static_cast<char_type*>(__builtin_memcpy(__s1, __s2, __n)); | ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~ The relevant bit of code is this line: m_items[i].text = " "; Where the ".text" struct member is an std::string. Any suggestions on how to fix this will be appreciated.

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.

On Mon, Jan 17, 2022 at 12:27:15PM -0600, Justin Forbes wrote: > > 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. > > > > I suppose I should have checked fedora-devel before trying to chase > down build failures as kernel merge window issues. Kernel builds are > failing in a few places (depending on arch). For kernel, the only bug on the GCC side I'm aware of is https://gcc.gnu.org/PR101941

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.

On Fri, Jan 14, 2022 at 3:33 PM Jakub Jelinek <jakub(a)redhat.com&gt; wrote: > 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. > While I was trying to rebuild some Intel components, i've encountered this issue, which seems to be caused by libstdc. It affects intel-graphics-compiler (not yet in Fedora). That is compiled with clang, however, since gcc/libstdc 12, I am hitting this: /builddir/build/BUILD/intel-graphics-compiler-igc-1.0.9933/IGC/VectorCompiler/lib/GenXCodeGen/GenXLiveness.cpp:590:46: error: call to constructor of 'LiveRangeMap_t::value_type' (aka 'pair<const llvm::genx::SimpleValue, llvm::genx::LiveRange *>') is ambiguous auto [i, isInserted] = LiveRangeMap.insert(LiveRangeMap_t::value_type(V, 0)); ^ ~~~~ /usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_pair.h:425:17: note: candidate constructor [with _U1 = const llvm::genx::SimpleValue, _U2 = llvm::genx::LiveRange *, $2 = true] constexpr pair(const _T1& __a, const _T2& __b) ^ /usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_pair.h:492:18: note: candidate constructor [with _U1 = llvm::genx::SimpleValue &, $1 = true] constexpr pair(_U1&& __x, __null_ptr_constant) ^ 1 error generated. I've tried to locally recompile clang and llvm against the new libstdc (as it seems ambiguousness is caused by #if _GLIBCXX_USE_DEPRECATED being met), but that didn't help. Maybe I am missing some library that needs to be recompiled too. Anyhow, is this expected behavior? The affected file is this one: https://github.com/intel/intel-graphics-compiler/blob/master/IGC/VectorCo...

On Tue, 18 Jan 2022 at 11:04, Jonathan Wakely <jwakely(a)redhat.com&gt; wrote: > > > On Tue, 18 Jan 2022 at 10:29, Frantisek Zatloukal <fzatlouk(a)redhat.com&gt; > wrote: > >> >> >> On Fri, Jan 14, 2022 at 3:33 PM Jakub Jelinek <jakub(a)redhat.com&gt; wrote: >> >>> 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. >>> >> >> While I was trying to rebuild some Intel components, i've encountered >> this issue, which seems to be caused by libstdc. It affects >> intel-graphics-compiler (not yet in Fedora). That is compiled with clang, >> however, since gcc/libstdc 12, I am hitting this: >> >> /builddir/build/BUILD/intel-graphics-compiler-igc-1.0.9933/IGC/VectorCompiler/lib/GenXCodeGen/GenXLiveness.cpp:590:46: >> error: call to constructor of 'LiveRangeMap_t::value_type' (aka 'pair<const >> llvm::genx::SimpleValue, llvm::genx::LiveRange *>') is ambiguous >> auto [i, isInserted] = >> LiveRangeMap.insert(LiveRangeMap_t::value_type(V, 0)); >> ^ >> ~~~~ >> /usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_pair.h:425:17: >> note: candidate constructor [with _U1 = const llvm::genx::SimpleValue, _U2 >> = llvm::genx::LiveRange *, $2 = true] >> constexpr pair(const _T1& __a, const _T2& __b) >> ^ >> /usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_pair.h:492:18: >> note: candidate constructor [with _U1 = llvm::genx::SimpleValue &, $1 = >> true] >> constexpr pair(_U1&& __x, __null_ptr_constant) >> ^ >> 1 error generated. >> >> I've tried to locally recompile clang and llvm against the new libstdc >> (as it seems ambiguousness is caused by #if _GLIBCXX_USE_DEPRECATED being >> met), but that didn't help. Maybe I am missing some library that needs to >> be recompiled too. Anyhow, is this expected behavior? >> >> The affected file is this one: >> https://github.com/intel/intel-graphics-compiler/blob/master/IGC/VectorCo... >> > > > I think the code is just wrong, and should use nullptr instead of 0 in > that initializer on line 590. > Even better would be to stop creating the unnecessary temporary: auto [i, isInserted] = LiveRangeMap.emplace(V, nullptr);

> > It's related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101124 > though. I tried to keep that old incorrect code working, but apparently > failed. > >

On Tue, 18 Jan 2022 at 10:29, Frantisek Zatloukal <fzatlouk(a)redhat.com&gt; wrote: > > > On Fri, Jan 14, 2022 at 3:33 PM Jakub Jelinek <jakub(a)redhat.com&gt; wrote: > >> 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. >> > > While I was trying to rebuild some Intel components, i've encountered > this issue, which seems to be caused by libstdc. It affects > intel-graphics-compiler (not yet in Fedora). That is compiled with clang, > however, since gcc/libstdc 12, I am hitting this: > > /builddir/build/BUILD/intel-graphics-compiler-igc-1.0.9933/IGC/VectorCompiler/lib/GenXCodeGen/GenXLiveness.cpp:590:46: > error: call to constructor of 'LiveRangeMap_t::value_type' (aka 'pair<const > llvm::genx::SimpleValue, llvm::genx::LiveRange *>') is ambiguous > auto [i, isInserted] = > LiveRangeMap.insert(LiveRangeMap_t::value_type(V, 0)); > ^ > ~~~~ > /usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_pair.h:425:17: > note: candidate constructor [with _U1 = const llvm::genx::SimpleValue, _U2 > = llvm::genx::LiveRange *, $2 = true] > constexpr pair(const _T1& __a, const _T2& __b) > ^ > /usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_pair.h:492:18: > note: candidate constructor [with _U1 = llvm::genx::SimpleValue &, $1 = > true] > constexpr pair(_U1&& __x, __null_ptr_constant) > ^ > 1 error generated. > > I've tried to locally recompile clang and llvm against the new libstdc > (as it seems ambiguousness is caused by #if _GLIBCXX_USE_DEPRECATED being > met), but that didn't help. Maybe I am missing some library that needs to > be recompiled too. Anyhow, is this expected behavior? > > The affected file is this one: > https://github.com/intel/intel-graphics-compiler/blob/master/IGC/VectorCo... > I think the code is just wrong, and should use nullptr instead of 0 in that initializer on line 590. It's related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101124 though. I tried to keep that old incorrect code working, but apparently failed.

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.

On Tue, Jan 18, 2022 at 05:40:31PM +0100, Adrian Reber wrote: > > 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. > > Not sure if it is a bug, CRIU no longer works with GCC 12. > > CRIU creates something called 'parasite code' which is injected into > running processes for checkpointing and that part is built with > '-nostdlib'. Starting with GCC 12 we see 'strlen()' being pulled into > the parasite code which it wasn't with GCC 11. strlen is a standard C function, so I don't see any bug in that being used unless you do a freestanding compilation (-nostdlib isn't that). If you mail me preprocessed source of handle-elf-host.c + gcc command line used to compile it, I can have a look what exactly changed.

On Tue, Jan 18, 2022 at 07:08:00PM +0100, Adrian Reber wrote: > On Tue, Jan 18, 2022 at 05:56:45PM +0100, Jakub Jelinek wrote: > > On Tue, Jan 18, 2022 at 05:40:31PM +0100, Adrian Reber wrote: > > > > 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. > > > > > > Not sure if it is a bug, CRIU no longer works with GCC 12. > > > > > > CRIU creates something called 'parasite code' which is injected into > > > running processes for checkpointing and that part is built with > > > '-nostdlib'. Starting with GCC 12 we see 'strlen()' being pulled into > > > the parasite code which it wasn't with GCC 11. > > > > strlen is a standard C function, so I don't see any bug in that being used > > unless you do a freestanding compilation (-nostdlib isn't that). > > If you mail me preprocessed source of handle-elf-host.c + gcc > > command line used to compile it, I can have a look what exactly changed. > > Thanks for mentioning freestanding compilations. That seems to have been > the problem. > > On aarch64 I actually got a slightly different error message: > > ld: criu/pie/restorer.o: in function `lsm_set_label': > /drone/src/criu/pie/restorer.c:174: undefined reference to `strlen' > > Line 174 is: "for (len = 0; label[len]; len++)" > > Although there is no direct use of strlen(), it seems GCC 12 uses > strlen() for that line which did not happen with GCC 11. Using > '-ffreestanding' makes the compilation work with GCC 12 and CI still > looks happy. Thanks. https://gcc.gnu.org/r12-4283-g6f966f06146be76 Note, gcc has been doing something similar for years for memcpy and memset. -fno-tree-loop-distribute-patterns will work too.

Hi! gcc 12 snapshot has landed as the system compiler into rawhide today.

On Wed, Jan 19, 2022 at 07:27:44AM +0100, Remi Collet wrote: > Le 14/01/2022 à 15:31, Jakub Jelinek a écrit : >> gcc 12 snapshot has landed as the system compiler into rawhide today. > > PHP is now FTBFS on s390x only > https://koji.fedoraproject.org/koji/taskinfo?taskID=81436437 > > > Any help welcome, > Remi > > > P.S. from build.log > > > /builddir/build/BUILD/php-8.1.2/Zend/zend_variables.h: In function > 'ZEND_FETCH_OBJ_IS_SPEC_CONST_TMPVAR_HANDLER': > /builddir/build/BUILD/php-8.1.2/Zend/zend_variables.h:32:32: error: inlining > failed in call to 'always_inline' 'zval_ptr_dtor_nogc': target specific > option mismatch > 32 | static zend_always_inline void zval_ptr_dtor_nogc(zval *zval_ptr) > | ^~~~~~~~~~~~~~~~~~ > In file included from > /builddir/build/BUILD/php-8.1.2/Zend/zend_execute.c:5071: > /builddir/build/BUILD/php-8.1.2/Zend/zend_vm_execute.h:8772:9: note: called > from here > 8772 | zval_ptr_dtor_nogc(EX_VAR(opline->op2.var)); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ That error means that there is difference in the target attribute or #pragma GCC target between the caller of the always_inline function and the always_inline function which prevents the inlining (and always_inline requires to be inlined). I'd need preprocessed source + gcc command line to say more.

That error means that there is difference in the target attribute or #pragma GCC target between the caller of the always_inline function and the always_inline function which prevents the inlining (and always_inline requires to be inlined). I'd need preprocessed source + gcc command line to say more.

Jakub _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

I thought I'd solved all my gcc-12-isms in ceph by running --scratch --arch-override=x86_64 builds, so I tried a full build and ran into this on aarch64. :-(

/usr/bin/g++ -DBOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION -DBOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT -DHAVE_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_REENTRANT -D_THREAD_SAFE -D__CEPH__ -D__STDC_FORMAT_MACROS -D__linux__ -I/builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/src/include -I/builddir/build/BUILD/ceph-16.2.7/src -isystem /builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/include -isystem /builddir/build/BUILD/ceph-16.2.7/src/xxHash -isystem /builddir/build/BUILD/ceph-16.2.7/src/rapidjson/include -isystem /usr/include/python3.10 -O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -O2 -g -DNDEBUG -fPIE -U_FORTIFY_SOURCE -Wall -fno-strict-aliasing -fsigned-char -Wtype-limits -Wignored-qualifiers -Wpointer-arith -Werror=format-security -Winit-self -Wno-unknown-pragmas -Wnon-virtual-dtor -Wno-ignored-qualifiers -ftemplate-depth-1024 -Wpessimizing-move -Wredundant-move -Wstrict-null-sentinel -Woverloaded-virtual -fno-new-ttp-matching -fstack-protector-strong -fdiagnostics-color=auto -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free -std=c++17 -MD -MT src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -MF src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o.d -o src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -c /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc FAILED: src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o /usr/bin/g++ -DBOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION -DBOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT -DHAVE_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_REENTRANT -D_THREAD_SAFE -D__CEPH__ -D__STDC_FORMAT_MACROS -D__linux__ -I/builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/src/include -I/builddir/build/BUILD/ceph-16.2.7/src -isystem /builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/include -isystem /builddir/build/BUILD/ceph-16.2.7/src/xxHash -isystem /builddir/build/BUILD/ceph-16.2.7/src/rapidjson/include -isystem /usr/include/python3.10 -O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -O2 -g -DNDEBUG -fPIE -U_FORTIFY_SOURCE -Wall -fno-strict-aliasing -fsigned-char -Wtype-limits -Wignored-qualifiers -Wpointer-arith -Werror=format-security -Winit-self -Wno-unknown-pragmas -Wnon-virtual-dtor -Wno-ignored-qualifiers -ftemplate-depth-1024 -Wpessimizing-move -Wredundant-move -Wstrict-null-sentinel -Woverloaded-virtual -fno-new-ttp-matching -fstack-protector-strong -fdiagnostics-color=auto -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free -std=c++17 -MD -MT src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -MF src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o.d -o src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -c /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc In file included from /usr/include/boost/integer.hpp:20, from /usr/include/boost/integer/integer_mask.hpp:16, from /usr/include/boost/random/mersenne_twister.hpp:26, from /usr/include/boost/uuid/random_generator.hpp:17, from /usr/include/boost/uuid/uuid_generators.hpp:17, from /builddir/build/BUILD/ceph-16.2.7/src/include/uuid.h:16, from /builddir/build/BUILD/ceph-16.2.7/src/include/types.h:21, from /builddir/build/BUILD/ceph-16.2.7/src/msg/msg_types.h:23, from /builddir/build/BUILD/ceph-16.2.7/src/common/ceph_context.h:36, from /builddir/build/BUILD/ceph-16.2.7/src/common/dout.h:29, from /builddir/build/BUILD/ceph-16.2.7/src/common/debug.h:18, from /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc:16: /usr/include/boost/integer_traits.hpp:83:64: error: narrowing conversion of '255' from 'int' to 'char' [-Wnarrowing] 83 | public detail::integer_traits_base<char, CHAR_MIN, CHAR_MAX> | https://koji.fedoraproject.org/koji/taskinfo?taskID=81520773 Are we expecting an update to boost by any chance? On Fri, Jan 14, 2022 at 9:33 AM Jakub Jelinek <jakub(a)redhat.com&gt; 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(a)lists.fedoraproject.org > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Kaleb

On Thu, 20 Jan 2022 at 12:54, Kaleb Keithley <kkeithle(a)redhat.com&gt; wrote: > > > I thought I'd solved all my gcc-12-isms in ceph by running --scratch --arch-override=x86_64 builds, so I tried a full build and ran into this on aarch64. :-( > > /usr/bin/g++ -DBOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION -DBOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT -DHAVE_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_REENTRANT -D_THREAD_SAFE -D__CEPH__ -D__STDC_FORMAT_MACROS -D__linux__ -I/builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/src/include -I/builddir/build/BUILD/ceph-16.2.7/src -isystem /builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/include -isystem /builddir/build/BUILD/ceph-16.2.7/src/xxHash -isystem /builddir/build/BUILD/ceph-16.2.7/src/rapidjson/include -isystem /usr/include/python3.10 -O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -O2 -g -DNDEBUG -fPIE -U_FORTIFY_SOURCE -Wall -fno-strict-aliasing -fsigned-char -Wtype-limits -Wignored-qualifiers -Wpointer-arith -Werror=format-security -Winit-self -Wno-unknown-pragmas -Wnon-virtual-dtor -Wno-ignored-qualifiers -ftemplate-depth-1024 -Wpessimizing-move -Wredundant-move -Wstrict-null-sentinel -Woverloaded-virtual -fno-new-ttp-matching -fstack-protector-strong -fdiagnostics-color=auto -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free -std=c++17 -MD -MT src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -MF src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o.d -o src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -c /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc > FAILED: src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o > /usr/bin/g++ -DBOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION -DBOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT -DHAVE_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_REENTRANT -D_THREAD_SAFE -D__CEPH__ -D__STDC_FORMAT_MACROS -D__linux__ -I/builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/src/include -I/builddir/build/BUILD/ceph-16.2.7/src -isystem /builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/include -isystem /builddir/build/BUILD/ceph-16.2.7/src/xxHash -isystem /builddir/build/BUILD/ceph-16.2.7/src/rapidjson/include -isystem /usr/include/python3.10 -O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -O2 -g -DNDEBUG -fPIE -U_FORTIFY_SOURCE -Wall -fno-strict-aliasing -fsigned-char -Wtype-limits -Wignored-qualifiers -Wpointer-arith -Werror=format-security -Winit-self -Wno-unknown-pragmas -Wnon-virtual-dtor -Wno-ignored-qualifiers -ftemplate-depth-1024 -Wpessimizing-move -Wredundant-move -Wstrict-null-sentinel -Woverloaded-virtual -fno-new-ttp-matching -fstack-protector-strong -fdiagnostics-color=auto -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free -std=c++17 -MD -MT src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -MF src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o.d -o src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -c /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc > In file included from /usr/include/boost/integer.hpp:20, > from /usr/include/boost/integer/integer_mask.hpp:16, > from /usr/include/boost/random/mersenne_twister.hpp:26, > from /usr/include/boost/uuid/random_generator.hpp:17, > from /usr/include/boost/uuid/uuid_generators.hpp:17, > from /builddir/build/BUILD/ceph-16.2.7/src/include/uuid.h:16, > from /builddir/build/BUILD/ceph-16.2.7/src/include/types.h:21, > from /builddir/build/BUILD/ceph-16.2.7/src/msg/msg_types.h:23, > from /builddir/build/BUILD/ceph-16.2.7/src/common/ceph_context.h:36, > from /builddir/build/BUILD/ceph-16.2.7/src/common/dout.h:29, > from /builddir/build/BUILD/ceph-16.2.7/src/common/debug.h:18, > from /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc:16: > /usr/include/boost/integer_traits.hpp:83:64: error: narrowing conversion of '255' from 'int' to 'char' [-Wnarrowing] > 83 | public detail::integer_traits_base<char, CHAR_MIN, CHAR_MAX> > | > > https://koji.fedoraproject.org/koji/taskinfo?taskID=81520773 > > Are we expecting an update to boost by any chance? No, not for F36 (it would be a systemwide change, and we prefer to do it before the mass rebuild if we do it). I don't think this is a problem with Boost anyway. This error makes no sense. Either char is signed, in which case CHAR_MAX should be 127, or char is unsigned in which case char{255} is not narrowing.

I thought I'd solved all my gcc-12-isms in ceph by running --scratch --arch-override=x86_64 builds, so I tried a full build and ran into this on aarch64. :-( In file included from /usr/include/boost/integer.hpp:20, from /usr/include/boost/integer/integer_mask.hpp:16, from /usr/include/boost/random/mersenne_twister.hpp:26, from /usr/include/boost/uuid/random_generator.hpp:17, from /usr/include/boost/uuid/uuid_generators.hpp:17, from /builddir/build/BUILD/ceph-16.2.7/src/include/uuid.h:16, from /builddir/build/BUILD/ceph-16.2.7/src/include/types.h:21, from /builddir/build/BUILD/ceph-16.2.7/src/msg/msg_types.h:23, from /builddir/build/BUILD/ceph-16.2.7/src/common/ceph_context.h:36, from /builddir/build/BUILD/ceph-16.2.7/src/common/dout.h:29, from /builddir/build/BUILD/ceph-16.2.7/src/common/debug.h:18, from /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc:16: /usr/include/boost/integer_traits.hpp:83:64: error: narrowing conversion of '255' from 'int' to 'char' [-Wnarrowing] 83 | public detail::integer_traits_base<char, CHAR_MIN, CHAR_MAX> | https://koji.fedoraproject.org/koji/taskinfo?taskID=81520773 Are we expecting an update to boost by any chance?

The qemu bug led to this optimizer mis-compilation bug which seems very serious: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103721 I'm not sure I would try GCC 12 generated code until this gets fixed.

[…] 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. […]

On Fri, Jan 14, 2022 at 7:32 AM Jakub Jelinek <jakub(a)redhat.com&gt; wrote: > 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). I don't know if this change is involved, but I've got several packages that failed to build on ppc64le only, with what look like gcc segfaults: - cli11: https://koji.fedoraproject.org/koji/taskinfo?taskID=81476792 - dra2ter: https://koji.fedoraproject.org/koji/taskinfo?taskID=81482527 - libfplll: https://koji.fedoraproject.org/koji/taskinfo?taskID=81533813 - libpoly: https://koji.fedoraproject.org/koji/taskinfo?taskID=81536797 - mp: https://koji.fedoraproject.org/koji/taskinfo?taskID=81548297 - python-fpylll: https://koji.fedoraproject.org/koji/taskinfo?taskID=81597035

On Fri, Jan 21, 2022 at 10:06 AM Dan Horák <dan(a)danny.cz&gt; wrote: > could be https://bugzilla.redhat.com/show_bug.cgi?id=2043517 Thanks for the pointer, Dan.

> > Also note that libmpc failed to build on ppc64le only: > https://koji.fedoraproject.org/koji/taskinfo?taskID=81535783 one test core-dumps, I will try a local build to see what's in the core

On Fri, 21 Jan 2022 09:55:01 -0700 Jerry James <loganjerry(a)gmail.com&gt; wrote: > On Fri, Jan 14, 2022 at 7:32 AM Jakub Jelinek <jakub(a)redhat.com&gt; wrote: > > 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). > > I don't know if this change is involved, but I've got several packages > that failed to build on ppc64le only, with what look like gcc > segfaults: > - dra2ter: https://koji.fedoraproject.org/koji/taskinfo?taskID=81482527 > - libfplll: https://koji.fedoraproject.org/koji/taskinfo?taskID=81533813 > - libpoly: https://koji.fedoraproject.org/koji/taskinfo?taskID=81536797 > - mp: https://koji.fedoraproject.org/koji/taskinfo?taskID=81548297 ^^^ those are probably https://bugzilla.redhat.com/show_bug.cgi?id=2043517

I know you want FTBFS bugs now for gcc-12 issues, but let me run this by you first and I will open a BZ if necessary. For ceph I've hacked up a fix for all the other gcc-12isms in ceph and now it fails to build on ppc64le[1] with ... /usr/bin/ld: /builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/lib/libceph-common.so.2: undefined reference to `int fmt::v8::detail::format_float<__ieee128>(__ieee128, int, fmt::v8::detail::float_specs, fmt::v8::detail::buffer<char>&)' /usr/bin/ld: /builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/lib/libceph-common.so.2: undefined reference to `int fmt::v8::detail::snprintf_float<__ieee128>(__ieee128, int, fmt::v8::detail::float_specs, fmt::v8::detail::buffer<char>&)' collect2: error: ld returned 1 exit status

> The long double change is an ABI change, so this is kind of expected. > Mass rebuild unfortunately doesn't go according to the dependency graph > (and > unfortunately it isn't a tree, there are cycles). > Indeed. fmt has not been rebuilt, or more accurately, it failed in the mass rebuild. Specifically the ppc64le build failed. see https://koji.fedoraproject.org/koji/taskinfo?taskID=81489199

On Sat, Jan 22, 2022 at 2:28 PM Kaleb Keithley <kkeithle(a)redhat.com&gt; wrote: > >> The long double change is an ABI change, so this is kind of expected. >> Mass rebuild unfortunately doesn't go according to the dependency graph >> (and >> unfortunately it isn't a tree, there are cycles). >> > > Indeed. fmt has not been rebuilt, or more accurately, it failed in the > mass rebuild. Specifically the ppc64le build failed. see > https://koji.fedoraproject.org/koji/taskinfo?taskID=81489199 > I may have missed the email about this. (Sorry if I have.) Is there an action on someone's part to fix the assembler, or fix the assembly that gcc-12 is emitting on ppc64le that the assembler is puking on?

I do hope this can be cleaned up soon. Dropping arches from packages is a very big hammer and should be wielded extremely sparingly. Unless ceph was unusable without a rebuild on the other arches, it would've been better to wait until this issue was resolved before rebuilding ceph.

The long double change is an ABI change, so this is kind of expected.

On 22/01/2022 17:22, Jakub Jelinek wrote: > The long double change is an ABI change, so this is kind of expected. abidiff automatic test found no ABI changes between 8.0 and 8.1.

Which I presume is related to the failed rebuild of fmt[2] with gcc-12 and thus I'm still getting a version of fmt compiled with gcc-11.

gcc 12 snapshot has landed as the system compiler into rawhide today.

On 14/01/2022 15:31, Jakub Jelinek wrote: > gcc 12 snapshot has landed as the system compiler into rawhide today. Another ICE on ppc64le with all packages contains catch2 library. Task: https://koji.fedoraproject.org/koji/taskinfo?taskID=81641415

Have the command line arguments that are accepted by gcc? The test suite of the "cc" crate (used for compiling and linking to C code within Rust projects) started failing with GCC 12 with this error: gcc: error: unrecognized command-line option '-arbitrary'