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

[Georg-Johann Lay]

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
options

--with-double=[32|64]
--with-long-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:

* 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:

  <https://savannah.nongnu.org/bugs/?57071>

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/