[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #57071] Fix math.h and function names that block 64-bit double

From: Georg-Johann Lay
Subject: [bug #57071] Fix math.h and function names that block 64-bit double
Date: Thu, 24 Oct 2019 10:26:49 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:64.0) Gecko/20100101 Firefox/64.0

Follow-up Comment #4, bug #57071 (project avr-libc):

[comment #3 comment #3:]
> 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.

I didn't settle on an interface yet, my preferred choice would be configure


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:

* How and if symbol aliases are provided (i.e. the topic of this issue).

* How printf et al. interprets %f, %lf, %g etc.

* For any functions that use open-coded [long-]double like dtostre (which is
ftostre actually).  We can implement this as ftostre and provide an alias or a
prototype with asm name depending on double layout.

* And of course the multilib structure.  I still have no clue how to integrate
`avr-gcc --print-multi-lib` into the configure process and how to make use of
`avr-gcc --print-multi-directory --mmcu=MMCU ...`.  This would be very much
appreciated in order to make avr-libc more independent of avr-gcc's version,
multilib-structure and multilib-options.  Ideas?


Reply to this item at:


  Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]