Opened 3 months ago

Closed 2 months ago

#4847 closed task (fixed)


Reported by: Xi Ruoyao Owned by: Douglas R. Reno
Priority: normal Milestone: 11.0
Component: Book Version: SVN
Severity: normal Keywords:


The release branch of gcc-11 has been forked and it should be released in two or three weeks.

Change History (13)

comment:1 by Xi Ruoyao, 3 months ago

It's scheduled to be released on Apr 27.

The new features are documented in The breaking changes are documented in

comment:2 by Xi Ruoyao, 3 months ago

Summary: gcc-11.1.0 (wait for this version)gcc-11.1.0
The GCC developers are proud to announce another major GCC release, 11.1.

This release switches the default debugging format to DWARF 5 [1] on most
targets and switches the default C++ language version to -std=gnu++17.
It makes great progress in the C++20 language support, both on the compiler
and library sides [2], adds experimental C++23 support, some C2X enhancements,
various optimization enhancements and bug fixes, several new hardware
enablement changes and enhancements to the compiler back-ends and many other

Some code that compiled successfully with older GCC versions might require
source changes, see for

comment:4 by Xi Ruoyao, 3 months ago

It can be simplified to a sed: sed 's/amx_/amx-/' -i sysdeps/x86/tst-cpu-features-supports.c.

comment:5 by Xi Ruoyao, 3 months ago

constexpr-52830 and bad-mapper-3 FAIL.

asan_test.C, co-ret-17-void-ret-coro.C, pr95519-05-gro.C, pr80166.c no longer FAIL.

comment:6 by Bruce Dubbs, 3 months ago

Are these two new failures mentioned at all in upstream builds?

comment:7 by Xi Ruoyao, 3 months ago

There is no result posted in gcc-testresults for 11.1.0 now.

I'll report these two to gcc bugzilla.

comment:8 by Xi Ruoyao, 3 months ago

52830 is mentioned at It's a tricky bug in GCC since 4.8. The status quo is actually better: at least the compiler won't crash, but it still rejects the valid code.

Last edited 3 months ago by Xi Ruoyao (previous) (diff)

comment:9 by Xi Ruoyao, 3 months ago

bad-mapper-3 does not FAIL on the completed LFS system. In the log it says:

Temporary failure in name resolution mapper 'localhost:172477262'

I'm not sure what happened in LFS chroot: in theory our minimal /etc/hosts created in Chapter 7 should prevent this kind of issue.

comment:10 by Xi Ruoyao, 3 months ago

I commented out the line for ::1 in /etc/hosts and this test FAILs again. So I think adding a line

::1 localhost

into chapter 7 /etc/hosts will prevent bad-mapper-3 failure.

comment:11 by Bruce Dubbs, 3 months ago

Milestone: 10.211.0

Milestone renamed

comment:12 by Douglas R. Reno, 3 months ago

Owner: changed from lfs-book to Douglas R. Reno
Status: newassigned

comment:13 by Douglas R. Reno, 2 months ago

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.