public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/111639] New: HAVE_ACOSF etc. are wrong on avr
@ 2023-09-29 13:35 redi at gcc dot gnu.org
  2023-09-29 14:07 ` [Bug libstdc++/111639] " redi at gcc dot gnu.org
                   ` (8 more replies)
  0 siblings, 9 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2023-09-29 13:35 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 111639
           Summary: HAVE_ACOSF etc. are wrong on avr
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: redi at gcc dot gnu.org
  Target Milestone: ---
            Target: avr

The <math.h> in avr-libc does things like this:

extern double acos(double __x) __ATTR_CONST__;
#define acosf   acos            /**< The alias for acos().      */

and then crossconfig.m4 does:

  avr*-*-*)
    AC_DEFINE(HAVE_ACOSF)
    AC_DEFINE(HAVE_ASINF)
    AC_DEFINE(HAVE_ATAN2F)
    AC_DEFINE(HAVE_ATANF)
    AC_DEFINE(HAVE_CEILF)
    AC_DEFINE(HAVE_COSF)
    AC_DEFINE(HAVE_COSHF)
    AC_DEFINE(HAVE_EXPF)
    AC_DEFINE(HAVE_FABSF)
    AC_DEFINE(HAVE_FLOORF)
    AC_DEFINE(HAVE_FMODF)
    AC_DEFINE(HAVE_FREXPF)
    AC_DEFINE(HAVE_SQRTF)
    AC_DEFINE(HAVE_HYPOTF)
    AC_DEFINE(HAVE_LDEXPF)
    AC_DEFINE(HAVE_LOG10F)
    AC_DEFINE(HAVE_LOGF)
    AC_DEFINE(HAVE_MODFF)
    AC_DEFINE(HAVE_POWF)
    AC_DEFINE(HAVE_SINF)
    AC_DEFINE(HAVE_SINHF)
    AC_DEFINE(HAVE_TANF)
    AC_DEFINE(HAVE_TANHF)
    ;;

But this doesn't work, because <cmath> has to #undef all math function names,
so we #undef the acosf macro and then the HAVE_ACOSF macro is left defined but
is now lying.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug libstdc++/111639] HAVE_ACOSF etc. are wrong on avr
  2023-09-29 13:35 [Bug libstdc++/111639] New: HAVE_ACOSF etc. are wrong on avr redi at gcc dot gnu.org
@ 2023-09-29 14:07 ` redi at gcc dot gnu.org
  2023-09-30 19:16 ` gjl at gcc dot gnu.org
                   ` (7 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2023-09-29 14:07 UTC (permalink / raw)
  To: gcc-bugs

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Blocks|                            |79700
   Last reconfirmed|                            |2023-09-29
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
This blocks the fix for PR 79700 because of these lying macros.

The crossconfig.m4 changes were made in 2016 by
g:6649ad7efdd583d84099beb5ee2b03a0ed28b9ee purportedly to fix duplicate
definitions in math_stubs_float.cc, e.g.

In file included from
/home/jwakely/src/gcc/build-avr/gcc-obj/avr/libstdc++-v3/include/cmath:47,
                 from
/home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++98/math_stubs_float.cc:25:
/home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++98/math_stubs_float.cc:35:3:
error: conflicting declaration of C function 'float fabs(float)'
   35 |   fabsf(float x)
      |   ^~~~~
/usr/avr/include/math.h:146:15: note: previous declaration 'double
fabs(double)'
  146 | extern double fabs(double __x) __ATTR_CONST__;
      |               ^~~~


But these are caused by the macros in avr <math.h>, which mean that we end up
defining another fabs instead of the intended fabsf.

I think the correct fix is to remove the crossconfig.m4 changes and do this
instead:

--- a/libstdc++-v3/src/c++98/math_stubs_float.cc
+++ b/libstdc++-v3/src/c++98/math_stubs_float.cc
@@ -31,6 +31,7 @@
 extern "C"
 {
 #ifndef _GLIBCXX_HAVE_FABSF
+#undef fabsf
   float
   fabsf(float x)
   {

And similarly for the other functions in that file.

If defining those functions bloats libstdc++ too much for avr, then we can
consider defining the float and long double stubs as aliases of each other
(since float, double and long double all seem to be the same size on avr).

We could even define them inline in headers, instead of in the lib:

extern "C" inline float fabs(float __x) { return fabs((double)__x); }

But the first priority should be to remove the bogus HAVE_FABSF definitions in
crossconfig.m4


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79700
[Bug 79700] std::fabsf and std::fabsl missing from <cmath>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug libstdc++/111639] HAVE_ACOSF etc. are wrong on avr
  2023-09-29 13:35 [Bug libstdc++/111639] New: HAVE_ACOSF etc. are wrong on avr redi at gcc dot gnu.org
  2023-09-29 14:07 ` [Bug libstdc++/111639] " redi at gcc dot gnu.org
@ 2023-09-30 19:16 ` gjl at gcc dot gnu.org
  2023-09-30 19:21 ` redi at gcc dot gnu.org
                   ` (6 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: gjl at gcc dot gnu.org @ 2023-09-30 19:16 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #2 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #0)
> The <math.h> in avr-libc does things like this:
> 
> extern double acos(double __x) __ATTR_CONST__;
> #define acosf	acos		/**< The alias for acos().	*/

This is no more the case with current AVR-LibC, which uses proper prototypes
and symbols for acos, acosf and acosl etc.

Here is math.h from the AVR-LibC v2.1 release (Jan 2022) :
https://github.com/avrdudes/avr-libc/blob/c466ef11ebf6cf774b7148dbd78c250789989ce0/include/math.h
(which has only acos and acosf, where the alias is implemented using assembly
name __asm("")).

The next release will also include long double prototypes, and they are proper
prototypes (without __asm("") names).

math.h from current HEAD:
https://github.com/avrdudes/avr-libc/blob/main/include/math.h

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug libstdc++/111639] HAVE_ACOSF etc. are wrong on avr
  2023-09-29 13:35 [Bug libstdc++/111639] New: HAVE_ACOSF etc. are wrong on avr redi at gcc dot gnu.org
  2023-09-29 14:07 ` [Bug libstdc++/111639] " redi at gcc dot gnu.org
  2023-09-30 19:16 ` gjl at gcc dot gnu.org
@ 2023-09-30 19:21 ` redi at gcc dot gnu.org
  2023-10-01  8:17 ` gjl at gcc dot gnu.org
                   ` (5 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2023-09-30 19:21 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Ah, good to know, thanks.

Which versions of avr-libc are supported with gcc? The version of avr-libc in
Fedora has the macros, which means I can't build avr-gcc with the patch for pr
79700 applied.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug libstdc++/111639] HAVE_ACOSF etc. are wrong on avr
  2023-09-29 13:35 [Bug libstdc++/111639] New: HAVE_ACOSF etc. are wrong on avr redi at gcc dot gnu.org
                   ` (2 preceding siblings ...)
  2023-09-30 19:21 ` redi at gcc dot gnu.org
@ 2023-10-01  8:17 ` gjl at gcc dot gnu.org
  2023-10-01  8:37 ` redi at gcc dot gnu.org
                   ` (4 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: gjl at gcc dot gnu.org @ 2023-10-01  8:17 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #4 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #3)
> Which versions of avr-libc are supported with gcc?

The versions are only very loosely coupled.  Anything from AVR-LibC v1.8 on (or
maybe even older) should be fine with avr-gcc v5+.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug libstdc++/111639] HAVE_ACOSF etc. are wrong on avr
  2023-09-29 13:35 [Bug libstdc++/111639] New: HAVE_ACOSF etc. are wrong on avr redi at gcc dot gnu.org
                   ` (3 preceding siblings ...)
  2023-10-01  8:17 ` gjl at gcc dot gnu.org
@ 2023-10-01  8:37 ` redi at gcc dot gnu.org
  2023-10-01 16:54 ` gjl at gcc dot gnu.org
                   ` (3 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2023-10-01  8:37 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
So then we do need to fix the autoconf macros.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug libstdc++/111639] HAVE_ACOSF etc. are wrong on avr
  2023-09-29 13:35 [Bug libstdc++/111639] New: HAVE_ACOSF etc. are wrong on avr redi at gcc dot gnu.org
                   ` (4 preceding siblings ...)
  2023-10-01  8:37 ` redi at gcc dot gnu.org
@ 2023-10-01 16:54 ` gjl at gcc dot gnu.org
  2023-10-01 19:04 ` redi at gcc dot gnu.org
                   ` (2 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: gjl at gcc dot gnu.org @ 2023-10-01 16:54 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #6 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
May I ask, are you working on getting libstdc++ to work for avr?

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug libstdc++/111639] HAVE_ACOSF etc. are wrong on avr
  2023-09-29 13:35 [Bug libstdc++/111639] New: HAVE_ACOSF etc. are wrong on avr redi at gcc dot gnu.org
                   ` (5 preceding siblings ...)
  2023-10-01 16:54 ` gjl at gcc dot gnu.org
@ 2023-10-01 19:04 ` redi at gcc dot gnu.org
  2023-10-01 19:05 ` redi at gcc dot gnu.org
  2024-06-15 13:28 ` gjl at gcc dot gnu.org
  8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2023-10-01 19:04 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Not particularly, I just want to be able to bootstrap on avr with
--enable-libstdcxx

It works pretty well already, especially with the -ffreestanding changes in gcc
13.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug libstdc++/111639] HAVE_ACOSF etc. are wrong on avr
  2023-09-29 13:35 [Bug libstdc++/111639] New: HAVE_ACOSF etc. are wrong on avr redi at gcc dot gnu.org
                   ` (6 preceding siblings ...)
  2023-10-01 19:04 ` redi at gcc dot gnu.org
@ 2023-10-01 19:05 ` redi at gcc dot gnu.org
  2024-06-15 13:28 ` gjl at gcc dot gnu.org
  8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2023-10-01 19:05 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Anything that doesn't work on avr should be considered a bug, like any other
target.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug libstdc++/111639] HAVE_ACOSF etc. are wrong on avr
  2023-09-29 13:35 [Bug libstdc++/111639] New: HAVE_ACOSF etc. are wrong on avr redi at gcc dot gnu.org
                   ` (7 preceding siblings ...)
  2023-10-01 19:05 ` redi at gcc dot gnu.org
@ 2024-06-15 13:28 ` gjl at gcc dot gnu.org
  8 siblings, 0 replies; 10+ messages in thread
From: gjl at gcc dot gnu.org @ 2024-06-15 13:28 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #9 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #1)
> since float, double and long double all seem to be the same size on avr

Not necessarily. Since GCC v10, the default for long double is 64 bit (IEEE
double), but [long] double is also switchable per -m[long-]double={32,64}.

https://gcc.gnu.org/gcc-10/changes.html#avr

https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/AVR-Options.html#index-mdouble

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2024-06-15 13:28 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-09-29 13:35 [Bug libstdc++/111639] New: HAVE_ACOSF etc. are wrong on avr redi at gcc dot gnu.org
2023-09-29 14:07 ` [Bug libstdc++/111639] " redi at gcc dot gnu.org
2023-09-30 19:16 ` gjl at gcc dot gnu.org
2023-09-30 19:21 ` redi at gcc dot gnu.org
2023-10-01  8:17 ` gjl at gcc dot gnu.org
2023-10-01  8:37 ` redi at gcc dot gnu.org
2023-10-01 16:54 ` gjl at gcc dot gnu.org
2023-10-01 19:04 ` redi at gcc dot gnu.org
2023-10-01 19:05 ` redi at gcc dot gnu.org
2024-06-15 13:28 ` gjl at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).