[Bug libstdc++/100017] New: error: 'fenv_t' has not been declared in '::' x86_64-w64-mingw32 host cross toolchain fails to build

[Bug libstdc++/100017] New: error: 'fenv_t' has not been declared in '::' x86_64-w64-mingw32 host cross toolchain fails to build

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

            Bug ID: 100017
           Summary: error: 'fenv_t' has not been declared in '::'
                    x86_64-w64-mingw32 host cross toolchain fails to build
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: unlvsur at live dot com
  Target Milestone: ---

Created attachment 50547
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50547&action=edit
error message

/home/cqwrteur/myhome/mingw-w64-cross/gcc/x86_64-w64-mingw32/libstdc++-v3/include/fenv.h:58:11:
error: 'fenv_t' has not been declared in '::'
   58 |   using ::fenv_t;

[Bug libstdc++/100017] error: 'fenv_t' has not been declared in '::' x86_64-w64-mingw32 host cross toolchain fails to build

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #1 from cqwrteur <unlvsur at live dot com> ---
I tried to build a full host GCC toolchain from Linux to Windows and fenv_t
does not exist.

[Bug libstdc++/100017] error: 'fenv_t' has not been declared in '::' x86_64-w64-mingw32 host cross toolchain fails to build

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

cqwrteur <unlvsur at live dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #2 from cqwrteur <unlvsur at live dot com> ---
not a bug

[Bug libstdc++/100017] error: 'fenv_t' has not been declared in '::' x86_64-w64-mingw32 host cross toolchain fails to build

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

cqwrteur <unlvsur at live dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |---
             Status|RESOLVED                    |UNCONFIRMED

--- Comment #3 from cqwrteur <unlvsur at live dot com> ---
(In reply to cqwrteur from comment #2)
> not a bug

it is weird tbh. There must be something to do with cfenv header or charconv

[Bug libstdc++/100017] error: 'fenv_t' has not been declared in '::' x86_64-w64-mingw32 host cross toolchain fails to build

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #4 from cqwrteur <unlvsur at live dot com> ---
(In reply to cqwrteur from comment #2)
> not a bug

it looks like it is a bug here.

[Bug libstdc++/100017] error: 'fenv_t' has not been declared in '::' x86_64-w64-mingw32 host cross toolchain fails to build

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #5 from cqwrteur <unlvsur at live dot com> ---
Created attachment 50548
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50548&action=edit
linux build, FreeBSD host, Windows target

The error still exists.

It looks MSVCRT does not always define those C11 cfenv functions and the
feature testing macro does not detect them correctly???

[Bug libstdc++/100017] error: 'fenv_t' has not been declared in '::' x86_64-w64-mingw32 host cross toolchain fails to build

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
>From IRC:

It works if I add -nostdinc++ manually to the compile line that fails then I
don't get the error

[Bug libstdc++/100017] error: 'fenv_t' has not been declared in '::' x86_64-w64-mingw32 host cross toolchain fails to build

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2021-04-21
     Ever confirmed|0                           |1

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The target build is finding the host libstdc++'s <fenv.h> which has the same
_GLIBCXX_FENV_H include guard, so when the target <fenv.h> does:

#include_next <fenv.h>

it doesn't do anything.

It might be necessary to do something simialr to what's in <cstdlib>:

// Need to ensure this finds the C library's <stdlib.h> not a libstdc++
// wrapper that might already be installed later in the include search path.
#define _GLIBCXX_INCLUDE_NEXT_C_HEADERS
#include_next <stdlib.h>
#undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS

where the libstdc++ <stdlib.h> wrapper does:

#if !defined __cplusplus || defined _GLIBCXX_INCLUDE_NEXT_C_HEADERS
# include_next <stdlib.h>
#else

#ifndef _GLIBCXX_STDLIB_H
#define _GLIBCXX_STDLIB_H 1

That ensures that we eventually reach the libc <stdlib.h> and not just another
libstdc++ wrapper.

[Bug libstdc++/100017] error: 'fenv_t' has not been declared in '::' x86_64-w64-mingw32 host cross toolchain fails to build

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I can only fix the case where the target <fenv.h> (in the build tree) is found
first and then its #include_next finds the host <fenv.h> (installed on the
host).

But that seems to be the case that's breaking the canadian cross build.

[Bug libstdc++/100017] error: 'fenv_t' has not been declared in '::' x86_64-w64-mingw32 host cross toolchain fails to build

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #9 from cqwrteur <unlvsur at live dot com> ---
(In reply to Jonathan Wakely from comment #8)
> I can only fix the case where the target <fenv.h> (in the build tree) is
> found first and then its #include_next finds the host <fenv.h> (installed on
> the host).
> 
> But that seems to be the case that's breaking the canadian cross build.

it looks like the issue still exists in GCC 12.0.0

[Bug libstdc++/100017] error: 'fenv_t' has not been declared in '::' x86_64-w64-mingw32 host cross toolchain fails to build

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #10 from cqwrteur <unlvsur at live dot com> ---
(In reply to Jonathan Wakely from comment #8)
> I can only fix the case where the target <fenv.h> (in the build tree) is
> found first and then its #include_next finds the host <fenv.h> (installed on
> the host).
> 
> But that seems to be the case that's breaking the canadian cross build.

The same issue happens with x86_64-linux-gnu build, x86_64-w64-mingw32 host,
x86_64-ubuntu-linux-gnu target

/home/cqwrteur/myhome/glibc231/mingw_toolchain/mingw-host-linux/gcc/x86_64-ubuntu-linux-gnu/libstdc++-v3/include/cfenv:77:11:
error: 'feupdateenv' has not been declared in '::'
   77 |   using ::feupdateenv;

Looks like it has something to do with fenv.h

[Bug libstdc++/100017] error: 'fenv_t' has not been declared in '::' x86_64-w64-mingw32 host cross toolchain fails to build

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #11 from cqwrteur <unlvsur at live dot com> ---
(In reply to Jonathan Wakely from comment #8)
> I can only fix the case where the target <fenv.h> (in the build tree) is
> found first and then its #include_next finds the host <fenv.h> (installed on
> the host).
> 
> But that seems to be the case that's breaking the canadian cross build.

yeah. looks like this issue is very similar to stdint.h. I just removed fenv.h
in libstdc++'s build and it works.

[Bug libstdc++/100017] error: 'fenv_t' has not been declared in '::' x86_64-w64-mingw32 host cross toolchain fails to build

[davem at devkitpro dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #12 from Dave Murphy <davem at devkitpro dot org> ---
Naive patch based on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017#c7
gets my canadian crosses building. 

diff --git a/libstdc++-v3/include/c_compatibility/fenv.h
b/libstdc++-v3/include/c_compatibility/fenv.h
index 0413e3b7c25..56cabaa3635 100644
--- a/libstdc++-v3/include/c_compatibility/fenv.h
+++ b/libstdc++-v3/include/c_compatibility/fenv.h
@@ -26,6 +26,10 @@
  *  This is a Standard C++ Library header.
  */

+#if !defined __cplusplus || defined _GLIBCXX_INCLUDE_NEXT_C_HEADERS
+# include_next <fenv.h>
+#else
+
 #ifndef _GLIBCXX_FENV_H
 #define _GLIBCXX_FENV_H 1

diff --git a/libstdc++-v3/include/c_global/cfenv
b/libstdc++-v3/include/c_global/cfenv
index 0b0ec35a837..d24cb1a3c81 100644
--- a/libstdc++-v3/include/c_global/cfenv
+++ b/libstdc++-v3/include/c_global/cfenv
@@ -37,9 +37,11 @@

 #include <bits/c++config.h>

-#if _GLIBCXX_HAVE_FENV_H
-# include <fenv.h>
-#endif
+// Need to ensure this finds the C library's <fenv.h> not a libstdc++
+// wrapper that might already be installed later in the include search path.
+#define _GLIBCXX_INCLUDE_NEXT_C_HEADERS
+#include_next <fenv.h>
+#undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS

 #ifdef _GLIBCXX_USE_C99_FENV_TR1

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- cross toolchain fails to build

[belyshev at depni dot sinp.msu.ru]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

Serge Belyshev <belyshev at depni dot sinp.msu.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Build|x86_64-linux-gnu            |
   Last reconfirmed|2021-04-21 00:00:00         |2021-6-13
               Host|x86_64-w64-mingw32          |
                 CC|                            |belyshev at depni dot sinp.msu.ru
             Target|x86_64-w64-mingw32          |
      Known to fail|                            |11.1.1, 12.0
            Summary|error: 'fenv_t' has not     |[11/12 regression] error:
                   |been declared in '::'       |'fenv_t' has not been
                   |x86_64-w64-mingw32 host     |declared in '::' -- cross
                   |cross toolchain fails to    |toolchain fails to build
                   |build                       |

--- Comment #13 from Serge Belyshev <belyshev at depni dot sinp.msu.ru> ---
I'm seeing this also with  --build=x86_64-pc-linux-gnux32
--host=riscv-unknown-linux-gnu --target=riscv-unknown-linux-gnu, so not mingw
specific.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- cross toolchain fails to build

[dilfridge at gentoo dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

Andreas K. Huettel <dilfridge at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dilfridge at gentoo dot org

--- Comment #14 from Andreas K. Huettel <dilfridge at gentoo dot org> ---
also seen with 
 *      --host=riscv32-unknown-linux-gnu 
 *      --target=riscv32-unknown-linux-gnu 
 *      --build=x86_64-pc-linux-gnu 

(building a native riscv32 gcc using Gentoo's crossdev)

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- cross toolchain fails to build

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #15 from Iain Sandoe <iains at gcc dot gnu.org> ---
@dave 

Perhaps you could post the patch at C#12 for review (it would be useful to get
this cleared)

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- cross toolchain fails to build

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #16 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I don't think the patch is sufficient, I think I had a complete one.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- cross toolchain fails to build

[davem at devkitpro dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #17 from Dave Murphy <davem at devkitpro dot org> ---
(In reply to Jonathan Wakely from comment #16)
> I don't think the patch is sufficient, I think I had a complete one.

Shall I leave this or submit the patch I made as a starting point for review?

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- cross toolchain fails to build

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.2

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- cross toolchain fails to build

[ofer.shinaar at wdc dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

Ofer Shinaar <ofer.shinaar at wdc dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ofer.shinaar at wdc dot com

--- Comment #18 from Ofer Shinaar <ofer.shinaar at wdc dot com> ---
(In reply to Jonathan Wakely from comment #16)
> I don't think the patch is sufficient, I think I had a complete one.

Can the patch be shared before the 11.2 cycle?

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- cross toolchain fails to build

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.2                        |11.3

--- Comment #19 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 11.2 is being released, retargeting bugs to GCC 11.3

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- cross toolchain fails to build

[yangyujie at alumni dot sjtu.edu.cn]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

Yujie Yang <yangyujie at alumni dot sjtu.edu.cn> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yangyujie at alumni dot sjtu.edu.c
                   |                            |n

--- Comment #20 from Yujie Yang <yangyujie at alumni dot sjtu.edu.cn> ---
This patch works for my cross-native build.

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])

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- cross toolchain fails to build

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #21 from cqwrteur <unlvsur at live dot com> ---
加QQ群1076846339

Get Outlook for Android<https://aka.ms/AAb9ysg>

________________________________
From: yangyujie at alumni dot sjtu.edu.cn <gcc-bugzilla@gcc.gnu.org>
Sent: Wednesday, August 4, 2021 3:45:37 AM
To: unlvsur@live.com <unlvsur@live.com>
Subject: [Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been
declared in '::' -- cross toolchain fails to build

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D100017&amp;data=04%7C01%7C%7C653e82d3249e48040a3008d9571bda20%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637636599397520649%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=FKy8fg1EZAP5JsEVt2lfiHaDsT7zdnxvTCn7dcXg0ng%3D&amp;reserved=0

Yujie Yang <yangyujie at alumni dot sjtu.edu.cn> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yangyujie at alumni dot
sjtu.edu.c
                   |                            |n

--- Comment #20 from Yujie Yang <yangyujie at alumni dot sjtu.edu.cn> ---
This patch works for my cross-native build.

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])

--
You are receiving this mail because:
You are on the CC list for the bug.
You reported the bug.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- cross toolchain fails to build

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dilyan.palauzov at aegee dot org

--- Comment #22 from Jonathan Wakely <redi at gcc dot gnu.org> ---
*** Bug 101060 has been marked as a duplicate of this bug. ***

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- cross toolchain fails to build

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #23 from cqwrteur <unlvsur at live dot com> ---
(In reply to Jonathan Wakely from comment #22)
> *** Bug 101060 has been marked as a duplicate of this bug. ***

I can confirm Yujie Yang's patch works. Just add -nostdinc++ to configure and
configure.ac in gcc root repository (not in gcc subdirectory nor libstdc++-v3
subdirectory)

Yes. So it is very easy to fix.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- cross toolchain fails to build

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #24 from cqwrteur <unlvsur at live dot com> ---
(In reply to Jonathan Wakely from comment #22)
> *** Bug 101060 has been marked as a duplicate of this bug. ***

We can fix it today XDXD 

PROFIT PROFIT PROFIT!!!

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- cross toolchain fails to build

[abrodkin at synopsys dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #25 from Alexey Brodkin <abrodkin at synopsys dot com> ---
> (In reply to Jonathan Wakely from comment #22)
> > *** Bug 101060 has been marked as a duplicate of this bug. ***
> 
> We can fix it today XDXD 
> 
> PROFIT PROFIT PROFIT!!!

Given there's a solution/patch suggested by Yujie Yang is there a chance to get
it fixed in upstream sources?

For the record I'm also seeing initially reported problem when trying to build
canadian cross GCC with Crosstool-NG (well, it's clear build system doesn't
matter but just in case).

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #26 from cqwrteur <unlvsur at live dot com> ---
(In reply to Alexey Brodkin from comment #25)
> > (In reply to Jonathan Wakely from comment #22)
> > > *** Bug 101060 has been marked as a duplicate of this bug. ***
> > 
> > We can fix it today XDXD 
> > 
> > PROFIT PROFIT PROFIT!!!
> 
> Given there's a solution/patch suggested by Yujie Yang is there a chance to
> get it fixed in upstream sources?
> 
> For the record I'm also seeing initially reported problem when trying to
> build canadian cross GCC with Crosstool-NG (well, it's clear build system
> doesn't matter but just in case).

why do you use Crosstool-NG?? It sucks.

Just manually compile by yourself. Simple and no bullshit.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[ofer.shinaar at wdc dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #27 from Ofer Shinaar <ofer.shinaar at wdc dot com> ---
(In reply to cqwrteur from comment #23)
> (In reply to Jonathan Wakely from comment #22)
> > *** Bug 101060 has been marked as a duplicate of this bug. ***
> 
> I can confirm Yujie Yang's patch works. Just add -nostdinc++ to configure
> and configure.ac in gcc root repository (not in gcc subdirectory nor
> libstdc++-v3 subdirectory)
> 
> Yes. So it is very easy to fix.

and what if I do want to use libstdc++ ? the first soultion allows me that

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #28 from cqwrteur <unlvsur at live dot com> ---
(In reply to Ofer Shinaar from comment #27)
> (In reply to cqwrteur from comment #23)
> > (In reply to Jonathan Wakely from comment #22)
> > > *** Bug 101060 has been marked as a duplicate of this bug. ***
> > 
> > I can confirm Yujie Yang's patch works. Just add -nostdinc++ to configure
> > and configure.ac in gcc root repository (not in gcc subdirectory nor
> > libstdc++-v3 subdirectory)
> > 
> > Yes. So it is very easy to fix.
> 
> and what if I do want to use libstdc++ ? the first soultion allows me that

no. it does not affect how libstdc++ builds. It is a bug in the build process
that the GCC will prefer finding headers in the C++ cross compiler. It should
not use C++ standard library headers in your cross compiler.

Add -nostdinc++ is adding a toggle at the build process that fixes all sorts of
issues that relate to the build of libstdc++.

It won't affect you for using it after the build.

There are some other problems of Canadian compilation here, like copying wrong
DLLs when you build with multilibs. Those are separate issues.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[vvinayag at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

vvinayag at arm dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vvinayag at arm dot com

--- Comment #29 from vvinayag at arm dot com ---
Can we expect a patch for this upstream?

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[aladjev.andrew at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #30 from Andrew Aladjev <aladjev.andrew at gmail dot com> ---
Created attachment 51746
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51746&action=edit
Include fenv dirty patch for gcc 11.2.0

Please apply carefully, it is not safe.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #31 from cqwrteur <unlvsur at live dot com> ---
(In reply to Andrew Aladjev from comment #30)
> Created attachment 51746 [details]
> Include fenv dirty patch for gcc 11.2.0
> 
> Please apply carefully, it is not safe.

no. adding -nostdinc++ is the right solution. yours are wrong.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[aladjev.andrew at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #32 from Andrew Aladjev <aladjev.andrew at gmail dot com> ---
I've added include_next_fenv dirty patch. I want just to quickly explain how to
use it.

First of all I've noticed (many years ago) that gcc developers are making
releases based on limited set of basic tests. These tests include one self
compilation using same version of gcc: gcc 11.2.0 amd64 -> gcc 11.2.0 amd64.
But in reality you have the following case:

gcc #{prev_version} #{platform1} #{env1} -> gcc #{next_version} #{platform2}
#{env2}

This movement is very hard task in practice, so I've added an additional step:

gcc #{prev_version} #{platform1} #{env1} -> dirty gcc #{next_version}
#{platform2} #{dirty_env2} -> gcc #{next_version} #{platform2} #{env2}

"dirty gcc" and "dirty env" step is very usefull when nobody have a solution.
You can invent your own dirty bicycle, apply it and you will receive clean gcc
on target platform in the last step anyway.

You may also review the following repo
https://github.com/andrew-aladev/test-images with my some test images.

Thank you.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #33 from cqwrteur <unlvsur at live dot com> ---
(In reply to Andrew Aladjev from comment #32)
> I've added include_next_fenv dirty patch. I want just to quickly explain how
> to use it.
> 
> First of all I've noticed (many years ago) that gcc developers are making
> releases based on limited set of basic tests. These tests include one self
> compilation using same version of gcc: gcc 11.2.0 amd64 -> gcc 11.2.0 amd64.
> But in reality you have the following case:
> 
> gcc #{prev_version} #{platform1} #{env1} -> gcc #{next_version} #{platform2}
> #{env2}
> 
> This movement is very hard task in practice, so I've added an additional
> step:
> 
> gcc #{prev_version} #{platform1} #{env1} -> dirty gcc #{next_version}
> #{platform2} #{dirty_env2} -> gcc #{next_version} #{platform2} #{env2}
> 
> "dirty gcc" and "dirty env" step is very usefull when nobody have a
> solution. You can invent your own dirty bicycle, apply it and you will
> receive clean gcc on target platform in the last step anyway.
> 
> You may also review the following repo
> https://github.com/andrew-aladev/test-images with my some test images.
> 
> Thank you.

I can ensure your patch is not correct

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #34 from cqwrteur <unlvsur at live dot com> ---
Created attachment 51747
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51747&action=edit
Correct Patch by just fixing configure and configure.ac with -nostdinc++

Tested with over 20 canadian cross builds without any issues.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[aladjev.andrew at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #35 from Andrew Aladjev <aladjev.andrew at gmail dot com> ---
Hello cqwrteur, do you have an influence on core gcc developers? Please provide
an idea to add at least one "canadian" test before release. x86_64-pc-linux-gnu
-> x86_64-unknown-linux-gnu will be enough. We should not definitely meet here
trying to treat "childhood" issues.

Thank you.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #36 from cqwrteur <unlvsur at live dot com> ---
(In reply to Andrew Aladjev from comment #35)
> Hello cqwrteur, do you have an influence on core gcc developers? Please
> provide an idea to add at least one "canadian" test before release.
> x86_64-pc-linux-gnu -> x86_64-unknown-linux-gnu will be enough. We should
> not definitely meet here trying to treat "childhood" issues.
> 
> Thank you.

I built that before. x86_64-pc-linux-gnu -> x86_64-ubuntu-linux-gnu Canadian
native.

x86_64-pc-linux-gnu build x86_64-w64-mingw32 cross x86_64-ubuntu-linux-gnu
Canadian cross build.


That patch works of course.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #37 from cqwrteur <unlvsur at live dot com> ---
(In reply to cqwrteur from comment #36)
> (In reply to Andrew Aladjev from comment #35)
> > Hello cqwrteur, do you have an influence on core gcc developers? Please
> > provide an idea to add at least one "canadian" test before release.
> > x86_64-pc-linux-gnu -> x86_64-unknown-linux-gnu will be enough. We should
> > not definitely meet here trying to treat "childhood" issues.
> > 
> > Thank you.
> 
> I built that before. x86_64-pc-linux-gnu -> x86_64-ubuntu-linux-gnu Canadian
> native.
> 
> x86_64-pc-linux-gnu build x86_64-w64-mingw32 cross x86_64-ubuntu-linux-gnu
> Canadian cross build.
> 
> 
> That patch works of course.

cqwrteur@localhost:~$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/cqwrteur/x86_64-ubuntu-linux-gnu/bin/../libexec/gcc/x86_64-ubuntu-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-ubuntu-linux-gnu
Configured with: ../../../gcc/configure --disable-werror --disable-nls
--enable-languages=c,c++ --enable-multilib --disable-bootstrap
--disable-libstdcxx-verbose
--with-gxx-libcxx-include-dir=/home/cqwrteur/canadian/x86_64-ubuntu-linux-gnu_canadian/x86_64-ubuntu-linux-gnu/x86_64-ubuntu-linux-gnu/c++/v1
--prefix=/home/cqwrteur/canadian/x86_64-ubuntu-linux-gnu_canadian/x86_64-ubuntu-linux-gnu
--with-pkgversion=cqwrteur --with-multilib-list=m64,m32,mx32
--target=x86_64-ubuntu-linux-gnu --host=x86_64-ubuntu-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210910 (experimental) (cqwrteur)


D:\hg>x86_64-ubuntu-linux-gnu-g++ -v
Using built-in specs.
COLLECT_GCC=x86_64-ubuntu-linux-gnu-g++
COLLECT_LTO_WRAPPER=d:/x86_64-windows-gnu/x86_64-ubuntu-linux-gnu/bin/../libexec/gcc/x86_64-ubuntu-linux-gnu/12.0.0/lto-wrapper.exe
Target: x86_64-ubuntu-linux-gnu
Configured with: ../../../gcc/configure --disable-nls --disable-werror
--prefix=/home/cqwrteur/canadian/x86_64-ubuntu-linux-gnu
--target=x86_64-ubuntu-linux-gnu --host=x86_64-w64-mingw32
--with-gxx-libcxx-include-dir=/home/cqwrteur/canadian/x86_64-ubuntu-linux-gnu/x86_64-ubuntu-linux-gnu/include/c++/v1
--enable-multilib --with-multilib-list=m64,mx32,m32 --disable-libstdcxx-verbose
--enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211005 (experimental) (GCC)

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[aladjev.andrew at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #38 from Andrew Aladjev <aladjev.andrew at gmail dot com> ---
Sure, patches works perfect. But we need somehow decrease the chance of similar
regressions in future. It is possible by adding any basic "canadian" build into
the list of tests to be done before release. We should not try to add such test
into codebase itself, we need just to intrigue any of core gcc developers to
add this test into the virtual checklist.

Thank you.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #39 from cqwrteur <unlvsur at live dot com> ---
(In reply to Andrew Aladjev from comment #38)
> Sure, patches works perfect. But we need somehow decrease the chance of
> similar regressions in future. It is possible by adding any basic "canadian"
> build into the list of tests to be done before release. We should not try to
> add such test into codebase itself, we need just to intrigue any of core gcc
> developers to add this test into the virtual checklist.
> 
> Thank you.

You do not need to worry tbh, people like me would test before you.

They have much more issues than just a Canadian build tbh. Like copying wrong
DLLs for multilibs. Nobody ever built that before probably.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #40 from cqwrteur <unlvsur at live dot com> ---
(In reply to Andrew Aladjev from comment #38)
> Sure, patches works perfect. But we need somehow decrease the chance of
> similar regressions in future. It is possible by adding any basic "canadian"
> build into the list of tests to be done before release. We should not try to
> add such test into codebase itself, we need just to intrigue any of core gcc
> developers to add this test into the virtual checklist.
> 
> Thank you.

Issues like this are exactly why i would never use a script (including things
like cross-ng) to build anything. I would build everything manually since it is
very likely to fail for all sorts of different reasons, neither their testing
would fix it since they have to include different libcs (we have hundreds of
different libcs) to test each of them, which is not possible.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #41 from cqwrteur <unlvsur at live dot com> ---
(In reply to Andrew Aladjev from comment #38)
> Sure, patches works perfect. But we need somehow decrease the chance of
> similar regressions in future. It is possible by adding any basic "canadian"
> build into the list of tests to be done before release. We should not try to
> add such test into codebase itself, we need just to intrigue any of core gcc
> developers to add this test into the virtual checklist.
> 
> Thank you.

The only thing you can do is that if you find a build bug, report to bugzilla

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #42 from cqwrteur <unlvsur at live dot com> ---
Created attachment 51816
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51816&action=edit
patch after today's update to configure

add a patch for today's update

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #43 from cqwrteur <unlvsur at live dot com> ---
Created attachment 51910
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51910&action=edit
new patch after today's update

Can we just push this to main?

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pedro.falcato at gmail dot com

--- Comment #44 from Jonathan Wakely <redi at gcc dot gnu.org> ---
*** Bug 103570 has been marked as a duplicate of this bug. ***

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[vvinayag at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #45 from vvinayag at arm dot com ---
(In reply to Jonathan Wakely from comment #44)
> *** Bug 103570 has been marked as a duplicate of this bug. ***

Hi Jonathan, 

I see that you plan to fix this soon
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103570#c1), and thank you for
that. Do you have a rough estimate of when we would see a fix for this? One of
our releases depends on a fix for this issue.

Kind regards
Vasee

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #46 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I hope to get to it next week.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #47 from cqwrteur <unlvsur at live dot com> ---
(In reply to Jonathan Wakely from comment #46)
> I hope to get to it next week.

lul it is not fixed in entire week.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #48 from cqwrteur <unlvsur at live dot com> ---
(In reply to Jonathan Wakely from comment #46)
> I hope to get to it next week.

what's the problem of just adding --nostdinc++ for RAW_CXX_FOR_TARGET??

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #49 from cqwrteur <unlvsur at live dot com> ---
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587254.html

I just send an email to add a patch for this. Jonathan Wakely, can you review
the patch here?

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #50 from cqwrteur <unlvsur at live dot com> ---
Backported GCC 11 patch
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587255.html

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[kallisti5 at unixzen dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

Alexander von Gluck <kallisti5 at unixzen dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kallisti5 at unixzen dot com

--- Comment #51 from Alexander von Gluck <kallisti5 at unixzen dot com> ---
Just saw this one bootstrapping Haiku riscv64 with gcc 11.1 under Linux.  
We're quite Canadian.


Adding some error spam for others searching for this issue.
```
/home/kallisti5/Code/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-11.1.0_2021_04_27/sources/gcc_bootstrap-11.1.0_2021_04_27-obj/riscv64-unknown-haiku/libstdc++-v3/include/fenv.h:58:11:
error: 'fenv_t' has not been declared in '::'
   58 |   using ::fenv_t;
      |           ^~~~~~
/home/kallisti5/Code/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-11.1.0_2021_04_27/sources/gcc_bootstrap-11.1.0_2021_04_27-obj/riscv64-unknown-haiku/libstdc++-v3/include/fenv.h:59:11:
error: 'fexcept_t' has not been declared in '::'
   59 |   using ::fexcept_t;
      |           ^~~~~~~~~
/home/kallisti5/Code/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-11.1.0_2021_04_27/sources/gcc_bootstrap-11.1.0_2021_04_27-obj/riscv64-unknown-haiku/libstdc++-v3/include/fenv.h:62:11:
error: 'feclearexcept' has not been declared in '::'
   62 |   using ::feclearexcept;
      |           ^~~~~~~~~~~~~
/home/kallisti5/Code/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-11.1.0_2021_04_27/sources/gcc_bootstrap-11.1.0_2021_04_27-obj/riscv64-unknown-haiku/libstdc++-v3/include/fenv.h:63:11:
error: 'fegetexceptflag' has not been declared in '::'
   63 |   using ::fegetexceptflag;
      |           ^~~~~~~~~~~~~~~
/home/kallisti5/Code/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-11.1.0_2021_04_27/sources/gcc_bootstrap-11.1.0_2021_04_27-obj/riscv64-unknown-haiku/libstdc++-v3/include/fenv.h:64:11:
error: 'feraiseexcept' has not been declared in '::'
   64 |   using ::feraiseexcept;
      |           ^~~~~~~~~~~~~
/home/kallisti5/Code/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-11.1.0_2021_04_27/sources/gcc_bootstrap-11.1.0_2021_04_27-obj/riscv64-unknown-haiku/libstdc++-v3/include/fenv.h:65:11:
error: 'fesetexceptflag' has not been declared in '::'
   65 |   using ::fesetexceptflag;
      |           ^~~~~~~~~~~~~~~
/home/kallisti5/Code/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-11.1.0_2021_04_27/sources/gcc_bootstrap-11.1.0_2021_04_27-obj/riscv64-unknown-haiku/libstdc++-v3/include/fenv.h:66:11:
error: 'fetestexcept' has not been declared in '::'
   66 |   using ::fetestexcept;
      |           ^~~~~~~~~~~~
/home/kallisti5/Code/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-11.1.0_2021_04_27/sources/gcc_bootstrap-11.1.0_2021_04_27-obj/riscv64-unknown-haiku/libstdc++-v3/include/fenv.h:68:11:
error: 'fegetround' has not been declared in '::'
   68 |   using ::fegetround;
      |           ^~~~~~~~~~
/home/kallisti5/Code/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-11.1.0_2021_04_27/sources/gcc_bootstrap-11.1.0_2021_04_27-obj/riscv64-unknown-haiku/libstdc++-v3/include/fenv.h:69:11:
error: 'fesetround' has not been declared in '::'
   69 |   using ::fesetround;
      |           ^~~~~~~~~~
/home/kallisti5/Code/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-11.1.0_2021_04_27/sources/gcc_bootstrap-11.1.0_2021_04_27-obj/riscv64-unknown-haiku/libstdc++-v3/include/fenv.h:71:11:
error: 'fegetenv' has not been declared in '::'
   71 |   using ::fegetenv;
      |           ^~~~~~~~
/home/kallisti5/Code/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-11.1.0_2021_04_27/sources/gcc_bootstrap-11.1.0_2021_04_27-obj/riscv64-unknown-haiku/libstdc++-v3/include/fenv.h:72:11:
error: 'feholdexcept' has not been declared in '::'
   72 |   using ::feholdexcept;
      |           ^~~~~~~~~~~~
/home/kallisti5/Code/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-11.1.0_2021_04_27/sources/gcc_bootstrap-11.1.0_2021_04_27-obj/riscv64-unknown-haiku/libstdc++-v3/include/fenv.h:73:11:
error: 'fesetenv' has not been declared in '::'
   73 |   using ::fesetenv;
      |           ^~~~~~~~
/home/kallisti5/Code/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-11.1.0_2021_04_27/sources/gcc_bootstrap-11.1.0_2021_04_27-obj/riscv64-unknown-haiku/libstdc++-v3/include/fenv.h:74:11:
error: 'feupdateenv' has not been declared in '::'
   74 |   using ::feupdateenv;
      |           ^~~~~~~~~~~
```

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #52 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Andrew Aladjev from comment #35)
> Hello cqwrteur, do you have an influence on core gcc developers?

He has negative influence. The more he comments on a bug, the less likely I am
to even read it, let alone fix it.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #53 from cqwrteur <unlvsur at live dot com> ---
(In reply to Jonathan Wakely from comment #52)
> (In reply to Andrew Aladjev from comment #35)
> > Hello cqwrteur, do you have an influence on core gcc developers?
> 
> He has negative influence. The more he comments on a bug, the less likely I
> am to even read it, let alone fix it.

lol. but hey. std::format is sometimes 4x slower than stringstream. you wg21
loves it right?? lol

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #54 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Andrew Aladjev from comment #38)
> Sure, patches works perfect. But we need somehow decrease the chance of
> similar regressions in future. It is possible by adding any basic "canadian"
> build into the list of tests to be done before release. We should not try to
> add such test into codebase itself, we need just to intrigue any of core gcc
> developers to add this test into the virtual checklist.

There is no "virtual checklist". If you care about a particular configuration
then YOU should be submitting results to the gcc-testresults mailing list to
report on the status of that config.

The GCC devs are testing the configs and the targets that THEY care about.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #55 from cqwrteur <unlvsur at live dot com> ---
(In reply to Jonathan Wakely from comment #54)
> (In reply to Andrew Aladjev from comment #38)
> > Sure, patches works perfect. But we need somehow decrease the chance of
> > similar regressions in future. It is possible by adding any basic "canadian"
> > build into the list of tests to be done before release. We should not try to
> > add such test into codebase itself, we need just to intrigue any of core gcc
> > developers to add this test into the virtual checklist.
> 
> There is no "virtual checklist". If you care about a particular
> configuration then YOU should be submitting results to the gcc-testresults
> mailing list to report on the status of that config.
> 
> The GCC devs are testing the configs and the targets that THEY care about.

so you mean GCC devs do not care about Canadian compilation?

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[kallisti5 at unixzen dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #56 from Alexander von Gluck <kallisti5 at unixzen dot com> ---
Canadian builds are pretty important in GCC.

clang doesn't really need Canadian builds since they support all targets out of
the box on every platform, but we don't have that luxury with gcc.

With that said, the proposed patch solved the issue for us and we applied it to
our toolchains here:
https://github.com/haikuports/haikuports.cross/blob/master/sys-devel/gcc_bootstrap/patches/gcc-11.2.0_2021_07_28.patchset

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #57 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I don't see how the patch could be correct.
Looking at RAW_CXX_FOR_TARGET in configure, I see:
(starting with the line you're proposing to change):
RAW_CXX_FOR_TARGET="$CXX_FOR_TARGET"
...
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking where to find the target c++
for libstdc++" >&5
$as_echo_n "checking where to find the target c++ for libstdc++... " >&6; }
if test "x${build}" != "x${host}" ; then
  if expr "x$RAW_CXX_FOR_TARGET" : "x/" > /dev/null; then
    # We already found the complete path
    ac_dir=`dirname $RAW_CXX_FOR_TARGET`
    { $as_echo "$as_me:${as_lineno-$LINENO}: result: pre-installed in $ac_dir"
>&5
$as_echo "pre-installed in $ac_dir" >&6; }
  else
    # Canadian cross, just use what we found
    { $as_echo "$as_me:${as_lineno-$LINENO}: result: pre-installed" >&5
$as_echo "pre-installed" >&6; }
  fi
else

So, if CXX_FOR_TARGET starts with /, e.g. /opt/gcc-11.1/bin/g++ , then
the above will use dirname /opt/gcc-11.1/bin/g++ and set ac_dir to
/opt/gcc-11.1/bin
But with the proposed change, $RAW_CXX_FOR_TARGET will be /opt/gcc-11.1/bin/g++
-nostdinc++ and dirname will fail miserably and not set ac_dir to anything:
dirname /opt/gcc-11.1/bin/g++ -nostdinc++
dirname: invalid option -- 'n'
Try 'dirname --help' for more information.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #58 from cqwrteur <unlvsur at live dot com> ---
(In reply to Alexander von Gluck from comment #56)
> Canadian builds are pretty important in GCC.
> 
> clang doesn't really need Canadian builds since they support all targets out
> of the box on every platform, but we don't have that luxury with gcc.
> 
> With that said, the proposed patch solved the issue for us and we applied it
> to our toolchains here:
> https://github.com/haikuports/haikuports.cross/blob/master/sys-devel/
> gcc_bootstrap/patches/gcc-11.2.0_2021_07_28.patchset

clang does need Canadian builds. For example Canadian compile a clang runs on
windows but builds on linux. Or Canadian compile a low power aarch64 raspi from
x86_64 ryzen powerful machine.

For example.

https://bitbucket.org/ejsvifq_mabmip/windows-hosted-llvm-clang/src/master/

I Canadian compile this from linux,

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #59 from cqwrteur <unlvsur at live dot com> ---
(In reply to Jakub Jelinek from comment #57)
> I don't see how the patch could be correct.
> Looking at RAW_CXX_FOR_TARGET in configure, I see:
> (starting with the line you're proposing to change):
> RAW_CXX_FOR_TARGET="$CXX_FOR_TARGET"
> ...
> { $as_echo "$as_me:${as_lineno-$LINENO}: checking where to find the target
> c++ for libstdc++" >&5
> $as_echo_n "checking where to find the target c++ for libstdc++... " >&6; }
> if test "x${build}" != "x${host}" ; then
>   if expr "x$RAW_CXX_FOR_TARGET" : "x/" > /dev/null; then
>     # We already found the complete path
>     ac_dir=`dirname $RAW_CXX_FOR_TARGET`
>     { $as_echo "$as_me:${as_lineno-$LINENO}: result: pre-installed in
> $ac_dir" >&5
> $as_echo "pre-installed in $ac_dir" >&6; }
>   else
>     # Canadian cross, just use what we found
>     { $as_echo "$as_me:${as_lineno-$LINENO}: result: pre-installed" >&5
> $as_echo "pre-installed" >&6; }
>   fi
> else
> 
> So, if CXX_FOR_TARGET starts with /, e.g. /opt/gcc-11.1/bin/g++ , then
> the above will use dirname /opt/gcc-11.1/bin/g++ and set ac_dir to
> /opt/gcc-11.1/bin
> But with the proposed change, $RAW_CXX_FOR_TARGET will be
> /opt/gcc-11.1/bin/g++ -nostdinc++ and dirname will fail miserably and not
> set ac_dir to anything:
> dirname /opt/gcc-11.1/bin/g++ -nostdinc++
> dirname: invalid option -- 'n'
> Try 'dirname --help' for more information.

So is this just an issue to libstdc++'s configure script only? Why the autotool
fails to find header files?

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #60 from cqwrteur <unlvsur at live dot com> ---
(In reply to Alexander von Gluck from comment #56)
> Canadian builds are pretty important in GCC.
> 
> clang doesn't really need Canadian builds since they support all targets out
> of the box on every platform, but we don't have that luxury with gcc.
> 
> With that said, the proposed patch solved the issue for us and we applied it
> to our toolchains here:
> https://github.com/haikuports/haikuports.cross/blob/master/sys-devel/
> gcc_bootstrap/patches/gcc-11.2.0_2021_07_28.patchset


Canadian Compilation 11 : Canadian Compile LLVM/clang with
x86_64-w64-mingw32-gcc posix.

https://youtu.be/U3KtVhLxlK4

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #61 from cqwrteur <unlvsur at live dot com> ---
(In reply to Alexander von Gluck from comment #56)
> Canadian builds are pretty important in GCC.
> 
> clang doesn't really need Canadian builds since they support all targets out
> of the box on every platform, but we don't have that luxury with GCC.

TBH, I failed to see how cross-compile in llvm is simple compared to GCC. The
problem is that you still need to build libc, you still need to build
compiler-rt, you still need to build libcxx, libcxxabi, libunwind whatever
manually one by one. Building them wastes more time than building a GCC cross
compiler.

That is why people just build GCC cross compiler and then use clang --target to
GCC's libraries.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #62 from Jonathan Wakely <redi at gcc dot gnu.org> ---
But that's off topic for GCC's bugzilla, please try to focus.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #63 from cqwrteur <unlvsur at live dot com> ---
(In reply to Jonathan Wakely from comment #62)
> But that's off topic for GCC's bugzilla, please try to focus.

so what's your solution to fix this problem? Are we going to fix it after
GCC13?

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[kallisti5 at unixzen dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #64 from Alexander von Gluck <kallisti5 at unixzen dot com> ---
(In reply to cqwrteur from comment #61)
> TBH, I failed to see how cross-compile in llvm is simple compared to GCC.

I mean... bootstrap.  Compiling Canadian toolchains to compile non-Canadian
toolchains is a pretty difficult task.   It's a big reason the BSD's went
clang.

*ANYWAY* wasn't looking to start a holy war.. just point out that Canadian
builds in gcc are important and should likely have a few base tests.

(In reply to Jonathan Wakely from comment #62)
> But that's off topic for GCC's bugzilla, please try to focus.

Indeed.   Back on topic, the patchset listed definitely does solve the issue
for us.   I didn't commit it to our gcc fork (that we plan on working to
upstream for Haiku support) though since a final iteration wasn't decided /
committed yet here.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #65 from cqwrteur <unlvsur at live dot com> ---
(In reply to Jonathan Wakely from comment #62)
> But that's off topic for GCC's bugzilla, please try to focus.

Is that because
#if _GLIBCXX_HAVE_FENV_H
# include <fenv.h>
#endif
here _GLIBCXX_HAVE_FENV_H in the libstdc++ build scripts fails to detect
fenv.h?
What about replacing it with #if __has_include(<fenv.h>) ?

(In reply to Alexander von Gluck from comment #64)
> (In reply to cqwrteur from comment #61)
> > TBH, I failed to see how cross-compile in llvm is simple compared to GCC.
> 
> I mean... bootstrap.  Compiling Canadian toolchains to compile non-Canadian
> toolchains is a pretty difficult task.   It's a big reason the BSD's went
> clang.
> 
> *ANYWAY* wasn't looking to start a holy war.. just point out that Canadian
> builds in gcc are important and should likely have a few base tests.
> 
> (In reply to Jonathan Wakely from comment #62)
> > But that's off topic for GCC's bugzilla, please try to focus.
> 
> Indeed.   Back on topic, the patchset listed definitely does solve the issue
> for us.   I didn't commit it to our gcc fork (that we plan on working to
> upstream for Haiku support) though since a final iteration wasn't decided /
> committed yet here.

Difficult? hmmm. Even middle school kids could easily do this.
I guess nowadays people just randomly search things on the internet for wrong
sources and rely on the things like cross-ng that adds difficulties to it. In
fact cross-ng just makes simple things hard not simple.
I am against all these auto build scripts. They just make simple things hard
and constantly break for all sorts of reasons.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #66 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to cqwrteur from comment #63)
> so what's your solution to fix this problem? Are we going to fix it after
> GCC13?

I'm working on it right now, but it would help if you would just shut the hell
up. Clang is off topic here. Your stupid opinions on other people's projects
are off topic here. Just shut up.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[kallisti5 at unixzen dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #67 from Alexander von Gluck <kallisti5 at unixzen dot com> ---
(In reply to cqwrteur from comment #65)
>
> Difficult? hmmm. Even middle school kids could...

Uh uh.   Yeah i'm just tuning you out at this point.


*anyway* for the adults left in the thread.  Jonathan, let me know if theres
anything I can test out to help you.

Thanks!

 -- Alex

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #68 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #57)
> I don't see how the patch could be correct.
> [...]
> So, if CXX_FOR_TARGET starts with /, e.g. /opt/gcc-11.1/bin/g++ , then
> the above will use dirname /opt/gcc-11.1/bin/g++ and set ac_dir to
> /opt/gcc-11.1/bin
> But with the proposed change, $RAW_CXX_FOR_TARGET will be
> /opt/gcc-11.1/bin/g++ -nostdinc++ and dirname will fail miserably and not
> set ac_dir to anything:
> dirname /opt/gcc-11.1/bin/g++ -nostdinc++
> dirname: invalid option -- 'n'
> Try 'dirname --help' for more information.

Jakub's analysis is correct. If the cross compiler is found in PATH then the
patch works OK. The configure output shows:

checking where to find the target c++... pre-installed
checking where to find the target c++ for libstdc++... pre-installed


If you build with something like
CXX_FOR_TARGET=/home/jwakely/gcc/aarch64/bin/aarch64-none-linux-gnu-g++ then
configure shows:

checking where to find the target c++... pre-installed in
/home/jwakely/gcc/aarch64/bin
checking where to find the target c++ for libstdc++... pre-installed in
/home/jwakely/gcc/aarch64/bin

But with the patch that prints an error:

checking where to find the target c++... pre-installed in
/home/jwakely/gcc/aarch64/bin
checking where to find the target c++ for libstdc++... dirname: invalid option
-- 'n'
Try 'dirname --help' for more information.
pre-installed in 

I don't think that actually causes a problem though. The build still works. The
dirname command is only used to print the result during configure. It's not
great though.

If we do this instead, then we don't have that problem:

diff --git a/Makefile.in b/Makefile.in
index 79c77fccf0f..ada25b8f11b 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -329,7 +329,7 @@ BASE_TARGET_EXPORTS = \
 RAW_CXX_TARGET_EXPORTS = \
        $(BASE_TARGET_EXPORTS) \
        CXX_FOR_TARGET="$(RAW_CXX_FOR_TARGET)"; export CXX_FOR_TARGET; \
-       CXX="$(RAW_CXX_FOR_TARGET) $(XGCC_FLAGS_FOR_TARGET) $$TFLAGS"; export
CXX;
+       CXX="$(RAW_CXX_FOR_TARGET) -nostdinc++ $(XGCC_FLAGS_FOR_TARGET)
$$TFLAGS"; export CXX;

 NORMAL_TARGET_EXPORTS = \
        $(BASE_TARGET_EXPORTS) \
diff --git a/Makefile.tpl b/Makefile.tpl
index ef58fac2b9a..fc10c7a771d 100644
--- a/Makefile.tpl
+++ b/Makefile.tpl
@@ -332,7 +332,7 @@ BASE_TARGET_EXPORTS = \
 RAW_CXX_TARGET_EXPORTS = \
        $(BASE_TARGET_EXPORTS) \
        CXX_FOR_TARGET="$(RAW_CXX_FOR_TARGET)"; export CXX_FOR_TARGET; \
-       CXX="$(RAW_CXX_FOR_TARGET) $(XGCC_FLAGS_FOR_TARGET) $$TFLAGS"; export
CXX;
+       CXX="$(RAW_CXX_FOR_TARGET) -nostdinc++ $(XGCC_FLAGS_FOR_TARGET)
$$TFLAGS"; export CXX;

 NORMAL_TARGET_EXPORTS = \
        $(BASE_TARGET_EXPORTS) \

I think that will mean we get -nostdinc++ twice for build==host builds, but
that's harmless.

The other reason I'm unsure about adding -nostdinc++ to RAW_CXX_FOR_TARGET is
that it's also used for building other target libs, specifically libsanitizer
and libvtv. I think it's correct for them too.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #69 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Do we have a guarantee that $(RAW_CXX_FOR_TARGET) is always some version of
GCC?
I mean, other compilers might not support -nostdinc++ option at all (older
versions of GCC might not either, but we only support GCC that can do C++11 now
and those all support it).

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #70 from Jonathan Wakely <redi at gcc dot gnu.org> ---
We're using it to build libstdc++ so it needs to be very very close to gcc in
terms of language support, and libstdc++ uses all kinds of flags like
-fno-implicit-templates that are gcc-specific.

I don't think it's really plausible to build libstdc++ with anything except a
gcc that closely matches the version of libstdc++ being built.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #71 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Tomorrow I'll test my more complete patch based on comment 7 (and comment 12)
as that should also solve it, and without changes to configury.

Conceptually, adding -nostdinc++ seems cleaner (it's what we already do when
building the target libs with the just-built gcc) but I'm less certain about
unwanted side effects.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #72 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Guess another option would be to do that
RAW_CXX_FLAGS_FOR_TARGET="$RAW_CXX_FLAGS_FOR_TARGET -nostdinc++"
in the toplevel configure.ac after all the GCC_TARGET_TOOL lines.
While GCC_TARGET_TOOL does AC_SUBST on the second argument, so
AC_SUBST(RAW_CXX_FLAGS_FOR_TARGET), in autoconf AC_SUBST just remembers
that it should be substituted and does the substitutions late, so when the var
is changed in between it will propagate to the Makefiles etc.

--- configure.ac        2022-01-04 23:11:22.153595595 +0100
+++ configure.ac        2022-01-06 21:59:49.274985505 +0100
@@ -3669,6 +3669,8 @@ GCC_TARGET_TOOL(strip, STRIP_FOR_TARGET,
 GCC_TARGET_TOOL(windres, WINDRES_FOR_TARGET, WINDRES, [binutils/windres])
 GCC_TARGET_TOOL(windmc, WINDMC_FOR_TARGET, WINDMC, [binutils/windmc])

+RAW_CXX_FOR_TARGET="$RAW_CXX_FOR_TARGET -nostdinc++"
+
 AC_SUBST(FLAGS_FOR_TARGET)
 AC_SUBST(RAW_CXX_FOR_TARGET)


completely untested...

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #73 from cqwrteur <unlvsur at live dot com> ---
(In reply to Jakub Jelinek from comment #72)
> Guess another option would be to do that
> RAW_CXX_FLAGS_FOR_TARGET="$RAW_CXX_FLAGS_FOR_TARGET -nostdinc++"
> in the toplevel configure.ac after all the GCC_TARGET_TOOL lines.
> While GCC_TARGET_TOOL does AC_SUBST on the second argument, so
> AC_SUBST(RAW_CXX_FLAGS_FOR_TARGET), in autoconf AC_SUBST just remembers
> that it should be substituted and does the substitutions late, so when the
> var is changed in between it will propagate to the Makefiles etc.
> 
> --- configure.ac	2022-01-04 23:11:22.153595595 +0100
> +++ configure.ac	2022-01-06 21:59:49.274985505 +0100
> @@ -3669,6 +3669,8 @@ GCC_TARGET_TOOL(strip, STRIP_FOR_TARGET,
>  GCC_TARGET_TOOL(windres, WINDRES_FOR_TARGET, WINDRES, [binutils/windres])
>  GCC_TARGET_TOOL(windmc, WINDMC_FOR_TARGET, WINDMC, [binutils/windmc])
>  
> +RAW_CXX_FOR_TARGET="$RAW_CXX_FOR_TARGET -nostdinc++"
> +
>  AC_SUBST(FLAGS_FOR_TARGET)
>  AC_SUBST(RAW_CXX_FOR_TARGET)
>  
> 
> completely untested...

Also. Can I propose another patch that fixes multilib canadian builds for
mingw-w64 and cygwin? i think I have a patch to fix that.

The build sripts in GCC copy wrong DLLs when we build multilibs when we build
Canadians. It is also a problem for native but native is usually buggy that
cannot build multilibs.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #74 from cqwrteur <unlvsur at live dot com> ---
(In reply to cqwrteur from comment #73)
> (In reply to Jakub Jelinek from comment #72)
> > Guess another option would be to do that
> > RAW_CXX_FLAGS_FOR_TARGET="$RAW_CXX_FLAGS_FOR_TARGET -nostdinc++"
> > in the toplevel configure.ac after all the GCC_TARGET_TOOL lines.
> > While GCC_TARGET_TOOL does AC_SUBST on the second argument, so
> > AC_SUBST(RAW_CXX_FLAGS_FOR_TARGET), in autoconf AC_SUBST just remembers
> > that it should be substituted and does the substitutions late, so when the
> > var is changed in between it will propagate to the Makefiles etc.
> > 
> > --- configure.ac	2022-01-04 23:11:22.153595595 +0100
> > +++ configure.ac	2022-01-06 21:59:49.274985505 +0100
> > @@ -3669,6 +3669,8 @@ GCC_TARGET_TOOL(strip, STRIP_FOR_TARGET,
> >  GCC_TARGET_TOOL(windres, WINDRES_FOR_TARGET, WINDRES, [binutils/windres])
> >  GCC_TARGET_TOOL(windmc, WINDMC_FOR_TARGET, WINDMC, [binutils/windmc])
> >  
> > +RAW_CXX_FOR_TARGET="$RAW_CXX_FOR_TARGET -nostdinc++"
> > +
> >  AC_SUBST(FLAGS_FOR_TARGET)
> >  AC_SUBST(RAW_CXX_FOR_TARGET)
> >  
> > 
> > completely untested...
> 
> Also. Can I propose another patch that fixes multilib canadian builds for
> mingw-w64 and cygwin? i think I have a patch to fix that.
> 
> The build sripts in GCC copy wrong DLLs when we build multilibs when we
> build Canadians. It is also a problem for native but native is usually buggy
> that cannot build multilibs.

Also another patch on fixing freestanding C++ build

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #75 from cqwrteur <unlvsur at live dot com> ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100427
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587838.html

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #76 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to cqwrteur from comment #74)
> Also another patch on fixing freestanding C++ build

There's a patch on PR 103866 to fix freestanding, but that's irrelevant to this
bug. Please try to stay on topic and stop going off on tangents. There are
already 76 comments here, and half of them are from you, and most of those are
unnecessary or unhelpful. When you can't stop yourself from vomiting your
stupid opinions all over bugzilla it makes it difficult and unpleasant to try
and follow the bugs. And so less likely to get fixed.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #77 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:4fde88e5dd152fe866a97b12e0f8229970d15cb3

commit r12-6406-g4fde88e5dd152fe866a97b12e0f8229970d15cb3
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Fri Jan 7 15:21:03 2022 +0000

    libstdc++: Add -nostdinc++ for c++17 sources [PR100017]

    When building a build!=host compiler, the just-built gcc can't be used
    to build the target libstdc++ (because it is built for the host triplet,
    not the build triplet). The top-level configure.ac sets up the build
    flags for libstdc++ (and other "raw_cxx" libs) like this:

    GCC_TARGET_TOOL(c++ for libstdc++, RAW_CXX_FOR_TARGET, CXX,
                    [gcc/xgcc -shared-libgcc -B$$r/$(HOST_SUBDIR)/gcc
-nostdinc++ -L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src
-L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src/.libs
-L$$r/$(TARGET_SUBDIR)/libstdc++-v3/libsupc++/.libs],
                    c++)

    The -nostdinc++ flag is only used for the IN-TREE-TOOL, i.e. when using
    the just-built gcc/xgcc compiler. This means that the cross-compiler
    used to build libstdc++ will add its own libstdc++ headers to the
    include path. That results in the #include <cfenv> in
    src/c++17/floating_to_chars.cc and src/c++17/floating_from_chars.cc
    doing #include_next <fenv.h> and finding the libstdc++ fenv.h wrapper
    from the host compiler. Because that has the same include guard as the
    <fenv.h> in the libstdc++ we're trying to build, we never reach the
    underlying <fenv.h> from libc. That results in several errors of the
    form:

    error: 'fenv_t' has not been declared in '::'

    The most correct fix would be to add -nostdinc++ to the
    RAW_CXX_FOR_TARGET variable in configure.ac, or the
    RAW_CXX_TARGET_EXPORTS variable in Makefile.tpl.

    Another solution would be to make the libstdc++ <fenv.h> wrapper use
    _GLIBCXX_INCLUDE_NEXT_C_HEADERS like our <stdlib.h> and other C header
    wrappers.

    For now though, the simplest and safest solution is to just add
    -nostdinc++ to the CXXFLAGS used for src/c++17/*.cc, which is what this
    does.

    libstdc++-v3/ChangeLog:

            PR libstdc++/100017
            * src/c++17/Makefile.am (AM_CXXFLAGS): Add -nostdinc++.
            * src/c++17/Makefile.in: Regenerate.

[Bug libstdc++/100017] [11 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[stammark at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

Stam Markianos-Wright <stammark at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |stammark at gcc dot gnu.org

--- Comment #78 from Stam Markianos-Wright <stammark at gcc dot gnu.org> ---
Thank you, Jonathan! Is that commit OK to be backported to gcc-11, as well?

[Bug libstdc++/100017] [11 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #79 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I'm doing that now.

[Bug libstdc++/100017] [11 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

--- Comment #80 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
<redi@gcc.gnu.org>:

https://gcc.gnu.org/g:01a70ccd723eb9a479186fe37c972b0d0f8676cf

commit r11-9448-g01a70ccd723eb9a479186fe37c972b0d0f8676cf
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Fri Jan 7 15:21:03 2022 +0000

    libstdc++: Add -nostdinc++ for c++17 sources [PR100017]

    When building a build!=host compiler, the just-built gcc can't be used
    to build the target libstdc++ (because it is built for the host triplet,
    not the build triplet). The top-level configure.ac sets up the build
    flags for libstdc++ (and other "raw_cxx" libs) like this:

    GCC_TARGET_TOOL(c++ for libstdc++, RAW_CXX_FOR_TARGET, CXX,
                    [gcc/xgcc -shared-libgcc -B$$r/$(HOST_SUBDIR)/gcc
-nostdinc++ -L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src
-L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src/.libs
-L$$r/$(TARGET_SUBDIR)/libstdc++-v3/libsupc++/.libs],
                    c++)

    The -nostdinc++ flag is only used for the IN-TREE-TOOL, i.e. when using
    the just-built gcc/xgcc compiler. This means that the cross-compiler
    used to build libstdc++ will add its own libstdc++ headers to the
    include path. That results in the #include <cfenv> in
    src/c++17/floating_to_chars.cc and src/c++17/floating_from_chars.cc
    doing #include_next <fenv.h> and finding the libstdc++ fenv.h wrapper
    from the host compiler. Because that has the same include guard as the
    <fenv.h> in the libstdc++ we're trying to build, we never reach the
    underlying <fenv.h> from libc. That results in several errors of the
    form:

    error: 'fenv_t' has not been declared in '::'

    The most correct fix would be to add -nostdinc++ to the
    RAW_CXX_FOR_TARGET variable in configure.ac, or the
    RAW_CXX_TARGET_EXPORTS variable in Makefile.tpl.

    Another solution would be to make the libstdc++ <fenv.h> wrapper use
    _GLIBCXX_INCLUDE_NEXT_C_HEADERS like our <stdlib.h> and other C header
    wrappers.

    For now though, the simplest and safest solution is to just add
    -nostdinc++ to the CXXFLAGS used for src/c++17/*.cc, which is what this
    does.

    libstdc++-v3/ChangeLog:

            PR libstdc++/100017
            * src/c++17/Makefile.am (AM_CXXFLAGS): Add -nostdinc++.
            * src/c++17/Makefile.in: Regenerate.

    (cherry picked from commit 4fde88e5dd152fe866a97b12e0f8229970d15cb3)

[Bug libstdc++/100017] [11 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #81 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed for gcc 11.3