AVR C Runtime Library - Bugs: bug #57071, Fix math.h and function names that...
You are not allowed to post comments on this tracker with your current authentication level.
bug #57071: Fix math.h and function names that block 64-bit double
Submitter: | Georg-Johann Lay <gjlayde> | ||
Submitted: | Thu 17 Oct 2019 07:10:37 AM UTC | ||
Category: | None | Severity: | 3 - Normal |
Priority: | 5 - Normal | Item Group: | None |
Status: | None | Percent Complete: | 0% |
Assigned to: | None | Open/Closed: | Open |
Release: | 2.0.0 | Fixed Release: | None |
( Jump to the original submission )
Fri 17 Jan 2020 10:52:34 AM UTC, comment #13: |
Georg-Johann Lay <gjlayde> |
Thu 16 Jan 2020 03:58:00 PM UTC, comment #12: Here is a small addendum which fixes some problems that I ran into when building avr-libc with avr-gcc v3.4.6:
1) The compiler might not recognize -Wno-sign-compare or -Wno-maybe-uninitialized which are used to silence some build warnings.
2) Old GCC does not built-in define __SIZEOF_DOUBLE__ and __SIZEOF_LONG_DOUBLE__, hence do it by hand.
|
Georg-Johann Lay <gjlayde> |
Mon 09 Dec 2019 05:34:39 PM UTC, comment #11: Hi, here is an updated version of the patch. Compared to the patch proposed in comment #10, it fixes the vfprintf issues:
|
Georg-Johann Lay <gjlayde> |
Wed 27 Nov 2019 04:51:30 PM UTC, comment #10: Here is an updated version of the patch with the following changes:
|
Georg-Johann Lay <gjlayde> |
Fri 08 Nov 2019 08:31:47 AM UTC, comment #9: The GCC feature is upstream: https://gcc.gnu.org/r277908
The new configure options are:
For a documentation, see
https://gcc.gnu.org/install/configure.html#avr
Only 14 of the 20 combinations are valid, resulting in 12 different configurations total. Depending on the configuration, there will be up to 57 = 3*19 multilib variants.
The new compiler options are:
For a documentation, see
https://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html#index-mdouble
To display the mapping between option sets and multilib variants, use
To show which multilib variant is actually picked for a specific set of options, use
To factor out different floating-point layouts in a target program, you can use -- like always -- the built-in defines
The libgcc build just copies the double64 and long-double64 multilib variants from the vanilla one so that the build times won't go through the roof -- these variants would not contain any differences to the vanilla version, anyway.
There is also the (undocumented, avr) configure option --with-fixed-point=no which skips the build of the thousands of libgcc fixed-point modules. You can use this during development for sane build times. |
Georg-Johann Lay <gjlayde> |
Fri 25 Oct 2019 03:52:54 PM UTC, comment #8: FYI, there is the according GCC issue + patch
From the doc of https://gcc.gnu.org/bugzilla/attachment.cgi?id=47114&action=diff
|
Georg-Johann Lay <gjlayde> |
Fri 25 Oct 2019 07:18:01 AM UTC, comment #7:
|
Georg-Johann Lay <gjlayde> |
Fri 25 Oct 2019 07:15:16 AM UTC, comment #6:
|
Georg-Johann Lay <gjlayde> |
Thu 24 Oct 2019 05:57:13 PM UTC, comment #5: Thanks for the explanation.
I think I'll apply the patch then as is by now, and we might add some words about the usage later on, when the configuration is settled. |
Joerg Wunsch <joerg_wunsch>![]() |
Thu 24 Oct 2019 02:26:48 PM UTC, comment #4:
--with-double=[32|64]
where --with-double= triggers availability of, say, -mdouble64 and also sets the default: --with-double=32 would make 64-bit double available, but the default would still be double=float.
But the problem is not with the (configure) option(s), it's the extension of the multilib space:
We currently have float/double/long-double = 32/32/32, and with the new multilib variants we'd also have 32/32/64 and 32/64/64. This would mean blowing up the number of multilibs to 57 or beyond...
For libgcc I am using a hack to copy the [long-]double multilibs from the traditional one so that the build-times don't go up. This works because the multilibs are the same: double=64 vs. double=32 is accomplished by referencing __adddf3 instead of __addsf3, not by a different implementation of __adddf3.
For libc, there are only changes in a few places:
|
Georg-Johann Lay <gjlayde> |
Wed 23 Oct 2019 08:45:12 PM UTC, comment #3: Thanks, something "auto-configuring" like the second patch is much appreciated.
Curious, what's the compiler switch to select 32- vs. 64-bit double? I'd like to add a bit of documentation about the entire topic as well. |
Joerg Wunsch <joerg_wunsch>![]() |
Fri 18 Oct 2019 01:54:49 PM UTC, comment #2: Here is a version without __asm(symbol) that defines a symbol for double only if sizeof(double) == sizeof(float).
|
Georg-Johann Lay <gjlayde> |
Thu 17 Oct 2019 08:30:43 AM UTC, comment #1:
|
Georg-Johann Lay <gjlayde> |
Thu 17 Oct 2019 07:10:37 AM UTC, original submission:
Implementation of math.h / libm currently blocks 64-bit double, namely:
1) Function names are wrong, e.g. 32-bit implementation of sine is named "sin", not "sinf".
2) There are "aliases" in math.h (macros actually) that define the float version (like "sinf") to the double version (like "sin"). Problem is that this:
2a) This is the wrong way round ("sin" should be alias of "sinf").
2b) There are no proper prototypes.
2c) Macros are bad, e.g. in C++ when some class implements a method for which math.h defines a macro, C++ functions / methods are silently renamed.
3) math.h is unconditional, i.e. treats double != float just like double = float.
|
Georg-Johann Lay <gjlayde> |
Depends on the following items: None found
Items that depend on this one: None found
Follow 5 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2020-01-16 | gjlayde | Attached File | - | ![]() |
Added math64-addend1.diff, #48240 |
2019-12-09 | gjlayde | Attached File | - | ![]() |
Added math64-3.diff, #48029 |
2019-11-27 | gjlayde | Attached File | - | ![]() |
Added math64-2.diff, #47938 |
2019-10-18 | gjlayde | Attached File | - | ![]() |
Added math64-syms.diff, #47711 |
2019-10-17 | gjlayde | Attached File | - | ![]() |
Added math64.diff, #47705 |
comment #12:
Note: Just the fact that current avr-libc can be built with avr-gcc v3.4.6 does not mean the result is usable in any way. Modern avr-libc drags device properties from avr-gcc's built-in macros like __AVR_HAVE_JMP_CALL__ which archaic avr-gcc does not define.