Re: [committed] libstdc++: Move closing brace outside #endif [PR104866]
Hi Jonathan, On 3/10/22 22:11, Jonathan Wakely wrote: Tested x86_64-linux, pushed to trunk. Thanks. With this and the other fix I was able to build the complete libstdc++ for AVR based on AVR Libc 2.0 (plus some ad hoc AVR header fixes) from git master 5e28be89. And a small example with pmr::string and pmr::vector worked :-) Thanks again, Detlef
Re: [committed] libstdc++: Move closing brace outside #endif [PR104866]
On 3/11/22 16:12, Jonathan Wakely wrote:
On Fri, 11 Mar 2022 at 14:28, Detlef Vollmann wrote:
With this and the other fix I was able to build the complete
libstdc++ for AVR based on AVR Libc 2.0 (plus some ad hoc
AVR header fixes) from git master 5e28be89.
Nice. I finally figure out that I need to use --enable-libstdcxx *not*
--enable-libstdc++-v3 to build for AVR,
Yes, I had the same problem.
A comment in the 'configure' script still says libstdc++-v3
and in the configure docs at
<https://gcc.gnu.org/install/configure.html>
or
<https://gcc.gnu.org/onlinedocs/libstdc++/manual/configure.html>
there's neither :-(
and now I get errors due to
EOVERFLOW being undefined. Is that what you fixed?
One of them.
We should make that work. Arguably, all values of std::errc should
exist, even if the OS doesn't provide a constant. We could
define the missing ones ourselves, choosing numbers > 1000 (and hope
the OS uses small numbers for its own errno values).
I simply defined all that were required.
I've attached a tarball with all my header fixes.
To get them picked up while compiling libstdc++ I had to
put them into ${prefix}/avr/lib/include.
But these are really ad hoc, some of the problems I think should
be fixed in the libstdc++ sources.
E.g. I think it's wrong to expect that specific functions are
available if a respective header is available (e.g. close()
in unistd.h).
Detlef
avr-fixups.tar.bz2
Description: Binary data
Re: [committed] libstdc++: Move closing brace outside #endif [PR104866]
On 3/11/22 18:59, Jonathan Wakely wrote: Thanks. Now I'm getting a build failure because libtol wasn't created in the avr/libstdc++-v3 directory of the build tree, but I'll have to look into that next week. /bin/sh: ../libtool: No such file or directory Here's my configure call: $REPO_DIR/configure \ --prefix=$PREFIX \ --target=avr \ --enable-languages=c,c++ \ --with-dwarf2 \ --enable-multilib \ --enable-libstdcxx \ --disable-decimal-float \ --disable-libffi \ --disable-libgomp \ --disable-libmudflap \ --disable-libquadmath \ --disable-libssp \ --disable-libstdcxx-pch \ --disable-nls \ --without-included-gettext \ --disable-libstdcxx-verbose \ --disable-shared \ --disable-threads \ --disable-tls \ --disable-plugin \ --with-system-zlib \ --with-native-system-header-dir=$PREFIX/port/include \ --with-headers=yes \ --with-gnu-as \ --with-gnu-ld \ --with-avrlibc \ --with-build-time-tools=$PREFIX/lib/avr/bin --disable-threads is probably wrong, as I definitly have threads (any ISR counts as thread). I added it in the (wrong) assumption that it would build support for std::thread... Detlef
Re: [committed] libstdc++: Move closing brace outside #endif [PR104866]
On 3/11/22 20:24, Detlef Vollmann wrote: On 3/11/22 18:59, Jonathan Wakely wrote: Thanks. Now I'm getting a build failure because libtol wasn't created in the avr/libstdc++-v3 directory of the build tree, but I'll have to look into that next week. /bin/sh: ../libtool: No such file or directory Here's my configure call: $REPO_DIR/configure \ --prefix=$PREFIX \ --target=avr \ --enable-languages=c,c++ \ --with-dwarf2 \ --enable-multilib \ --enable-libstdcxx \ --disable-decimal-float \ --disable-libffi \ --disable-libgomp \ --disable-libmudflap \ --disable-libquadmath \ --disable-libssp \ --disable-libstdcxx-pch \ --disable-nls \ --without-included-gettext \ --disable-libstdcxx-verbose \ --disable-shared \ --disable-threads \ --disable-tls \ --disable-plugin \ --with-system-zlib \ --with-native-system-header-dir=$PREFIX/port/include \ --with-headers=yes \ --with-gnu-as \ --with-gnu-ld \ --with-avrlibc \ --with-build-time-tools=$PREFIX/lib/avr/bin --disable-threads is probably wrong, as I definitly have threads (any ISR counts as thread). I added it in the (wrong) assumption that it would build support for std::thread... Just for completeness: for the previous steps building the toolchain I followed <http://www.nongnu.org/avr-libc/user-manual/install_tools.html>. Using binutils: 2.37 and AVR LibC 2.0.0 (from SVN). Detlef
[PATCH] libstdc++: Fix build for AVR [PR115481, PR111639]
The attached patch fixes 115481 and 111639.
It was tested against avr-libc 2.0.0 (which has *f as macros),
2.1.0 (which has *f as functions, but no long double), and
2.2.0 (which has long double functions).
Only the libstdc++ build was tested, not the resulting library.
Detlef
commit 9112ae579f73b249e9515d5ac9ddc3a76b067c39
Author: Detlef Vollmann
Date: Fri Jun 14 14:34:31 2024 +0200
libstdc++-v3: detect math functions when using avr-libc and handle macros
Different versions of avr-libc have different definitions of
math functions:
- 2.0.0 and earlier have float versions as macros
- 2.1.0 has float versions as proper functions, but no long double versions
- 2.2.0 has long double versions
This commit tells configure to always check if these functions are available.
It also #undef's any macros.
libstdc++-v3/ChangeLog:
* crossconfig.m4 [avr*-*-*]: Add compile-checks for
float and long double functions.
* configure: Regenerate.
* src/c++98/math_stubs_float.cc: #undef any macros.
diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
index 5645e991af7..17dbae7bd87 100755
--- a/libstdc++-v3/configure
+++ b/libstdc++-v3/configure
@@ -5080,7 +5080,7 @@ else
We can't simply define LARGE_OFF_T to be 9223372036854775807,
since some C++ compilers masquerading as C compilers
incorrectly reject 9223372036854775807. */
-#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
+#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31))
int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
&& LARGE_OFF_T % 2147483647 == 1)
? 1 : -1];
@@ -5126,7 +5126,7 @@ else
We can't simply define LARGE_OFF_T to be 9223372036854775807,
since some C++ compilers masquerading as C compilers
incorrectly reject 9223372036854775807. */
-#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
+#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31))
int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
&& LARGE_OFF_T % 2147483647 == 1)
? 1 : -1];
@@ -5150,7 +5150,7 @@ rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
We can't simply define LARGE_OFF_T to be 9223372036854775807,
since some C++ compilers masquerading as C compilers
incorrectly reject 9223372036854775807. */
-#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
+#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31))
int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
&& LARGE_OFF_T % 2147483647 == 1)
? 1 : -1];
@@ -5195,7 +5195,7 @@ else
We can't simply define LARGE_OFF_T to be 9223372036854775807,
since some C++ compilers masquerading as C compilers
incorrectly reject 9223372036854775807. */
-#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
+#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31))
int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
&& LARGE_OFF_T % 2147483647 == 1)
? 1 : -1];
@@ -5219,7 +5219,7 @@ rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
We can't simply define LARGE_OFF_T to be 9223372036854775807,
since some C++ compilers masquerading as C compilers
incorrectly reject 9223372036854775807. */
-#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
+#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31))
int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
&& LARGE_OFF_T % 2147483647 == 1)
? 1 : -1];
@@ -28628,51 +28628,2354 @@ case "${host}" in
;;
avr*-*-*)
-$as_echo "#define HAVE_ACOSF 1" >>confdefs.h
-$as_echo "#define HAVE_ASINF 1" >>confdefs.h
-$as_echo "#define HAVE_ATAN2F 1" >>confdefs.h
-$as_echo "#define HAVE_ATANF 1" >>confdefs.h
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking for acosf declaration" >&5
+$as_echo_n "checking for acosf declaration... " >&6; }
+if ${glibcxx_cv_func_acosf_use+:} false; then :
+ $as_echo_n "(cached) " >&6
+else
+
+
+ ac_ext=c
+ac_cpp='$CPP $CPPFLAGS'
+ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
+ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
+ac_compiler_gnu=$ac_cv_c_compiler_gnu
+
+ cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h. */
+
+#include
+#ifdef HAVE_IEEEFP_H
+# include
Re: [PATCH] libstdc++: Fix build for AVR [PR115481, PR111639]
On 6/14/24 19:45, Xi Ruoyao wrote: On Fri, 2024-06-14 at 19:37 +0200, Detlef Vollmann wrote: diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure index 5645e991af7..17dbae7bd87 100755 --- a/libstdc++-v3/configure +++ b/libstdc++-v3/configure @@ -5080,7 +5080,7 @@ else We can't simply define LARGE_OFF_T to be 9223372036854775807, since some C++ compilers masquerading as C compilers incorrectly reject 9223372036854775807. */ -#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62)) +#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31)) int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721 && LARGE_OFF_T % 2147483647 == 1) ? 1 : -1]; This shouldn't happen. Please regenerate using *vanilla* autoconf-2.69. Sorry, I was surprised myself, when I looked at the changes. But after looking at the actual change I thought it doesn't matter. I used Debian's version, I'll try to get a vanilla version working tomorrow (I actually plan anyway to run a test with the built libstdc++ on simulavr). Detlef
Re: [PATCH] libstdc++: Fix build for AVR [PR115481, PR111639]
On 6/15/24 10:30, Georg-Johann Lay wrote: Am 14.06.24 um 21:11 schrieb Detlef Vollmann: I actually plan anyway to run a test with the built libstdc++ on simulavr. As an aside, simulavr tries to simulate an exact match of the hardware including internal I/O like timers, IRQs, etc. For GCC regression testing, no internal I/O is needed; all what's required for testing algorithms is a core simulator like avrtest: https://github.com/sprintersb/atest https://github.com/sprintersb/atest?tab=readme-ov-file#running-the-avr-gcc-testsuite-using-the-avrtest-simulator avrtest runs orders of magnitude faster than simulavr, however it doesn't implement a GDB server, EEPROM or timers (none of which is required for the GCC testsuite). Thanks for the pointer. Apart from that, only being a core simulator, you can test for more cores than covered by simulavr. simulavr supports devices that cover the following 8 multilib variants: avr2 tiny-stack avr25 avr25/tiny-stack avr4 avr5 avr51 avr6 out of the 19 variants available in avr-gcc, like avr3, avr31, avrtiny, and all the avrxmega[2-7] variants that can be used with avrtest. avr-gcc 15 actually has 57 multilib variants (long-double32, double64 and short-calls versions). avr-libc 2.2.0 uses -print-multi-lib to build them all, avr-libc 2.0.0 has only 17 variants hardcoded. But right now I'm fighting against an ICE in cmath, i.e. so far any tests of cmath fail... I'll investigate this tomorrow and decide then what I'll do... Detlef
Re: [PATCH v2] libstdc++: Fix build for AVR [PR115481, PR111639]
On 6/14/24 19:59, Jonathan Wakely wrote:
On Fri, 14 Jun 2024 at 18:45, Xi Ruoyao wrote:
On Fri, 2024-06-14 at 19:37 +0200, Detlef Vollmann wrote:
diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
index 5645e991af7..17dbae7bd87 100755
--- a/libstdc++-v3/configure
+++ b/libstdc++-v3/configure
@@ -5080,7 +5080,7 @@ else
We can't simply define LARGE_OFF_T to be 9223372036854775807,
since some C++ compilers masquerading as C compilers
incorrectly reject 9223372036854775807. */
-#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
+#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31))
int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
&& LARGE_OFF_T % 2147483647 == 1)
? 1 : -1];
This shouldn't happen. Please regenerate using *vanilla* autoconf-2.69.
Yes, please, if possible. But I can regenerate it locally before
pushing if needed.
This version of the patch doesn't have the problem (this was the
easy part :-)
However, my tests show that this is only a partial solution.
But I believe the patch is correct, and it solves the build
problems for libstdc++ for AVR target.
However, at least for avr-libc 2.0.0 (the version that has the
*f functions as macros) it's not a complete patch:
std::sinf etc, and std::sinl etc are not provided
(::sinf and ::sinl are not provided either).
std::sin exists and has overloads for float, double and lon double.
And calling std::sin(float) only works if the call is inlined,
otherwise I get a linker error
".text._ZSt3sinf[_ZSt3sinf]+0x10): undefined reference to `sinf'".
I don't get a similar error for sinl when calling std::sin(long double).
I didn't have time to dig into the build of libstdc++ to find out
what the difference is.
For avr-libc 2.1.0 (that provides real *f functions but no *l)
I still get the error that std::sinl is not provided but none
of the other problems.
For avr-libc 2.2.0 (that provides real *f and *l functions) I don't
get any of the problems above.
But for all three avr-libc versions I get the problem that the
C++ sin(long double) returns a different value than the C sinl
(which is just another linker name for sin):
I don't really know about floating point representations, but
it looks like the C version fills the mantissa for a long double
return with 0, while the C++ version has bits there.
Looking at the implementation in math_stubs_long_double.cc,
which only calls the double version and promotes the return
to long double this looks strange.
But probably libstdc++ is compiled with different flags than
my test program.
And if I convert the long double result back to double I get
the same value as for C, so it's not really wrong, but it's
irritating...
So again, I think my patch helps, but is not a complete solution.
Detlef
commit 1e68bbe1da86913820af146ec5294d1ab53d72f7
Author: Detlef Vollmann
Date: Sat Jun 15 00:19:45 2024 +0200
libstdc++-v3: detect math functions when using avr-libc and handle macros
Different versions of avr-libc have different definitions of
math functions:
- 2.0.0 and earlier have float versions as macros
- 2.1.0 has float versions as proper functions, but no long double versions
- 2.2.0 has long double versions
This commit tells configure to always check if these functions are available.
It also #undef's any macros.
libstdc++-v3/ChangeLog:
* crossconfig.m4 [avr*-*-*]: Add compile-checks for
float and long double functions.
* configure: Regenerate.
* src/c++98/math_stubs_float.cc: #undef any macros.
diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
index 5645e991af7..891a5f8e053 100755
--- a/libstdc++-v3/configure
+++ b/libstdc++-v3/configure
@@ -28628,51 +28628,2354 @@ case "${host}" in
;;
avr*-*-*)
-$as_echo "#define HAVE_ACOSF 1" >>confdefs.h
-$as_echo "#define HAVE_ASINF 1" >>confdefs.h
-$as_echo "#define HAVE_ATAN2F 1" >>confdefs.h
-$as_echo "#define HAVE_ATANF 1" >>confdefs.h
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking for acosf declaration" >&5
+$as_echo_n "checking for acosf declaration... " >&6; }
+if ${glibcxx_cv_func_acosf_use+:} false; then :
+ $as_echo_n "(cached) " >&6
+else
+
+
+ ac_ext=c
+ac_cpp='$CPP $CPPFLAGS'
+ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
+ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
+ac_compiler_gnu=$ac_cv_c_compiler_gnu
+
+ cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h. */
+
+#include
+#ifdef HAVE_IEEEFP_H
+# include
+#endif
+#
