I configured the build as follows:

/home/roman/gcc-source/configure

Best regards,
Roman

Revision 246482.

Maybe PR 40974 again, which nobody can reproduce as it only happens due to some system-specific weirdness. We need more information about your system, what kind of OS distro are you using? etc. etc.

Could you try adding --disable-libstdcxx-pch to the configure command?

Thank you for your quick response.

I am using Gentoo. I'll give that option a try.

The build system is:
/usr/local/bin/gcc --version
gcc (GCC) 7.0.1 20170304 (experimental)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I'll report the result, when the build has finished, either by failure, or by success, respectively.

Best regards,
Roman

Thank you, Jonathan.

Disable the pre compiled header for libstdc++-v3,
did solve the problem. However, a new one occured
for which I filed a new bug (80200).

Best regards,
Roman

Reopening. We still need to know why building the PCH fails to find fenv_t for some people.

Same problem while trying to build gcc 11.1.0 on Arch Linux (host and target = Windows).

Configuration:

configure --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix="$PREFIX" --disable-nls --enable-languages=c,c++,ada --with-pkgversion=GR20210618 --enable-threads=win32 --disable-win32-registry --disable-multilib --enable-shared --enable-static --disable-sjlj-exceptions --with-dwarf2

Adding the '--disable-libstdcxx-pch' option doesn't help in my case, same errors.

The cross-compiler installed on my Arch Linux for building Windows executables is x86_64-w64-mingw32-gcc.

'x86_64-w64-mingw32-gcc -v' yields:

Utilisation des specs internes.
COLLECT_GCC=x86_64-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-w64-mingw32/11.1.0/lto-wrapper
Cible : x86_64-w64-mingw32
Configuré? avec: /build/mingw-w64-gcc/src/gcc/configure --prefix=/usr --libexecdir=/usr/lib --target=x86_64-w64-mingw32 --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,lto,c++,ada,objc,obj-c++,fortran --enable-shared --enable-static --enable-threads=posix --enable-fully-dynamic-string --enable-libstdcxx-time=yes --enable-libstdcxx-filesystem-ts=yes --with-system-zlib --enable-cloog-backend=isl --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-sjlj-exceptions --with-dwarf2
Modè?le de thread: posix
Algorithmes de compression LTO supporté?s: zlib zstd
gcc version 11.1.0 (GCC)

Created attachment 51076 [details]
full build log, xz-compressed

(In reply to Andreas K. Huettel from comment #8)
> Created attachment 51076 [details]
> full build log, xz-compressed

^ Build log for a failure with
 *      --host=riscv32-unknown-linux-gnu 
 *      --target=riscv32-unknown-linux-gnu 
 *      --build=x86_64-pc-linux-gnu 

(Gentoo crossdev build of a native riscv32 compiler)

Failure in gcc 11.1.0 is new and was introduced in 2251b4a5423efa8ee0d7e67537b63e404a1f6afa.

If we are building a canadian cross compiler, then
libstdc++-v3/src/c++17/floating_from_chars.cc will be compiled
with -I<build-dir>/libstdc++-v3/include where fenv.h is.
fenv.h here is the C++ include file which tries to include
the C include file with the same name by using include_next,
but finds the C++ include file from the cross compiler used for
building gcc which becomes empty because of the same include guard
used.

Thanks! Wasn't happening with previous versions. Is there a workaround?

I patched libstdc++-v3/acinclude.m4 to add -nostdinc++ in GLIBCXX_INCLUDES and it worked for me.

(My previous analysis was wrong. This issue is in canadian cross compilers where GXX_FOR_TARGET includes its own C++ headers, but with native compilers GXX_FOR_TARGET is xgcc which doesn't include C++ headers by default)

I ran into this issue with:

--build=aarch64-unknown-linux-gnu
--host=x86_64-unknown-linux-gnu
--target=x86_64-unknown-linux-gnu


I applied this patch from Yujie Yang, on comment 20 of PR 100017, and it fixed the issue for me.

diff --git a/configure b/configure
index 6157a8c87fb..2a4a05b4edf 100755
--- a/configure
+++ b/configure
@@ -16653,7 +16653,7 @@ else
 fi


-RAW_CXX_FOR_TARGET="$CXX_FOR_TARGET"
+RAW_CXX_FOR_TARGET="$CXX_FOR_TARGET -nostdinc++"

 { $as_echo "$as_me:${as_lineno-$LINENO}: checking where to find the target ar" >&5
 $as_echo_n "checking where to find the target ar... " >&6; }
diff --git a/configure.ac b/configure.ac
index 2ff48941754..01ecc8c42d9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -3515,7 +3515,7 @@ ACX_CHECK_INSTALLED_TARGET_TOOL(STRIP_FOR_TARGET, strip)
 ACX_CHECK_INSTALLED_TARGET_TOOL(WINDRES_FOR_TARGET, windres)
 ACX_CHECK_INSTALLED_TARGET_TOOL(WINDMC_FOR_TARGET, windmc)

-RAW_CXX_FOR_TARGET="$CXX_FOR_TARGET"
+RAW_CXX_FOR_TARGET="$CXX_FOR_TARGET -nostdinc++"

 GCC_TARGET_TOOL(ar, AR_FOR_TARGET, AR, [binutils/ar])
 GCC_TARGET_TOOL(as, AS_FOR_TARGET, AS, [gas/as-new])

OK, this patch fixes it for me as well.

(In reply to Jonathan Wakely from comment #6)
> Reopening. We still need to know why building the PCH fails to find fenv_t
> for some people.
I ran into this issue doing a very bog-standard build of the newly released GCC 12.1 on linux X86-64, using a configuration that previously successfully built GCC '12.0.1 20220424 (experimental)' a week or so ago.

I did not save the output from the failed build, but it would eventually fail with 'error: 'fenv_t' has not been declared in '::' ... '

For reasons that I'll skip, between the successful build of 12.0.1 and now I had added:

export CPLUS_INCLUDE_PATH=/opt/local/include/c++/12.0.1:/opt/local/include/c++/12.0.1/x86_64-linux-gnu/

to my .bashrc

Removing the 'CPLUS_INCLUDE_PATH' environment variable made the problem go away.

(In reply to Eddy L O Jansson from comment #15)
> For reasons that I'll skip, between the successful build of 12.0.1 and now I
> had added:
> 
> export
> CPLUS_INCLUDE_PATH=/opt/local/include/c++/12.0.1:/opt/local/include/c++/12.0.
> 1/x86_64-linux-gnu/
> 
> to my .bashrc

Don't do that. This causes GCC 12.1 to find the headers for GCC 12.0.1 instead of the libc headers. That breaks the build, but is user error.

The problem for canadian crosses (comment 10 onwards) was PR 100017 and is fixed now.