F42-gcc-15-mass-prebuild

GCC 15 mass prebuild

These are notes to myself on my attempts to use mass-prebuilder to test GCC 15 in Fedora in December 2024 in preparation for Changes/GNUToolchainF42

Trying it yourself

GCC 15 is not yet in rawhide, but you can use the scratch build via:

$ copr mock-config dmalcolm/gcc-15-smoketest-3 fedora-rawhide-x86_64 > ~/.config/mock/fedora-rawhide-gcc15-x86_64.cfg
$ fedpkg mockbuild --root fedora-rawhide-gcc15-x86_64

Current status

• Mass prebuild of rawhide with GCC 15 on aarch64, ppc64le, s390x, and x86_64 ran here: https://copr.fedorainfracloud.org/coprs/dmalcolm/gcc-15-smoketest-3/builds/
  • 7273 successful builds with gcc 15
  • 1438 builds that failed for some reason with gcc 15
• Rerunning the 1438 failed builds:
  • with gcc 15 (experiment): https://copr.fedorainfracloud.org/coprs/dmalcolm/gcc-15-smoketest-3.failed/builds/
  • with gcc 14 (control): https://copr.fedorainfracloud.org/coprs/dmalcolm/gcc-15-smoketest-3.failed.checker/builds/
  • Status at 2025-01-07 15:39:16+00:00

   440 out of 1438 builds are done.
   Pending: 515       
   Running: 13        
   Success: 29        
   Under check: 470       
   Manual confirmation needed: 147       
   Failed: 264       

• This is a failure rate of about 60%, suggesting about 862 will fail
  • 3 ICEs seen so far; filed in Fedora BZ
• Tracker bug for failures here

Older status

• Was having quota issues uploading the repos, so was only testing aarch64 at first. This is now fixed.
• Timeout building GCC in copr, so using one of Jakub's scratch builds, turned into repos here.
• Disabling annobin in redhat-rpm-config in the copr for now due to https://sourceware.org/bugzilla/show_bug.cgi?id=32429
• Had to rebuild libtool against the new gcc due to:

Problem: cannot install both gcc-15.0.0-0.2.fc42.aarch64 from https_dmalcolm_fedorapeople_org_gcc_gcc_15_mass_prebuild_arch and gcc-14.2.1-6.fc42.aarch64 from fedora
  - package libtool-2.5.4-1.fc42.aarch64 from fedora requires gcc(major) = 14, but none of the providers can be installed
  - cannot install the best candidate for the job
  - conflicting requests
You can try to add to command line:
  --no-best to not limit the transaction to the best candidates

Copr build error: Build failed

• I was running into exceptions being thrown by mpb, both when trying to analyze the failures by building against a baseline gcc 14 and when trying to get more accurate stats. These are fixed now (issues were 404 when trying to download log files due to results being cleaned up, and the .checker copr project only containing one arch, not all 4).

Kinds of failures seen

"internal compiler error"

These always indicate a GCC bug.

Examples:

• RHBZ #2336130
• RHBZ #2336136
• RHBZ #2336140
• RHBZ #2336214
• RHBZ #2336215

C23: New keywords

GCC 15 defaults to C23, which adds various new keywords, including "true", "false" and "bool". Examples:

• RHBZ #2336032: aime fails to build with GCC 15/C23 ("int true;")
• RHBZ #2336026: abcm2ps fails to build with GCC 15/C23 ("int bool;")

C23: Function prototypes with empty params change from implicit "int" to "void"

GCC 15 defaults to C23, in which () now means the same as (void) in both function declarations and definitions, where previously that change had been made for definitions only.

Hence

extern int foo();

now means:

extern int foo(void);

rather than:

extern int foo(int)

which may require changes to prototypes and header files (or the use of -std=c17 or similar).

Note: the commit in question was https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=0a4b219d39c74aec7ebf87ac3be38d8f93efd634

Examples:

• RHBZ #2331208 epson-inkjet-printer-escpr fails to build with GCC 15 (implicit int param in function prototype)

C++: "'TYPE_t' has not been declared"

See e.g.:

• RHBZ #2336046 - astromenace fails to build with GCC 15 ("error: 'uint32_t' has not been declared")
• RHBZ #2336010 - amdsmi fails to build with GCC 15 ("error: 'uintptr_t' does not name a type")

Presumably due to changes in C++ stdlib headers; adding "#include <cstdint>" explicitly may fix it.

C++: error with -Wtemplate-body

I'm seeing various C++ build failures with member lookup, where it emits -Wtemplate-body.

Examples:

• RHBZ #2336002 - ClanLib1 failed to build with GCC 15 ("error: 'class CL_Signal_v3<PARAM1, PARAM2, PARAM3>' has no member named 'owner' [-Wtemplate-body]")
• RHBZ #2336030 - actor-framework fails to build with GCC 15 ("error: 'value' is not a member of 'caf::detail::tl_is_distinct<List>' [-Wtemplate-body]")

This seems to be because g++ 15 became more aggressive about name lookup checking (as of upstream GCC commit r15-2117-g313afcfdabeab3); it *might* be due to pre-existing code containing templates are never actually instantiated, which would be why older GCC compiled the code without failing.

The easiest fix on the package side would be to use -fpermissive or more narrowly -Wno-error=template-body. (-Wtemplate-body was added in (upstream GCC commit r15-2774-g596d1ed9d40b10) https://gcc.gnu.org/PR116064).

Failures that don't match any of the above

• RHBZ #2336253 - NLopt failed to build with gcc 15 on ppc64le ("Could NOT find NumPy (missing: NUMPY_INCLUDE_DIRS)")
• RHBZ #2336255 - PyMCA fails to build with GCC 15 on ppc64le ("Illegal instruction (core dumped) ")
• RHBZ #2336256 - R fails to build with GCC 15