Re: [PATCH 2/3 V2] Do not include stdio.h in libgcc's Decimal/Float128 conversions.

[Segher Boessenkool <segher@kernel.crashing.org>]

On Tue, Mar 02, 2021 at 04:25:33PM -0500, Michael Meissner wrote:
> On Mon, Mar 01, 2021 at 05:15:44PM -0600, Segher Boessenkool wrote:
> > On Mon, Mar 01, 2021 at 12:18:52PM -0500, Michael Meissner wrote:
> > > The _sprintfkf.c file was including stdio.h to get the definition of sprintf.
> > 
> > (declaration of)
> > 
> > > This patch modifies this so that stdio.h is not included in order to support
> > > freestanding cross compilers that might not provide stdio.h.
> > 
> > So the code cannot work at all there?  Will not link?
> > 
> > > +   We use __builtin_sprintf so that we don't have to include stdio.h to define
> > > +   sprintf.  Stdio.h might not be present for freestanding cross compilers that
> > > +   do not need to include a library.  */
> > 
> > "declare sprintf", and the function is called stdio.g (all lowercase).
> > It is often written <stdio.h>, which makes it easier to handle in
> > sentences.
> > 
> > > @@ -54,5 +57,5 @@ int __sprintfkf (char *restrict string,
> > >    if (__sprintfieee128)
> > >      return __sprintfieee128 (string, format, number);
> > >  
> > > -  return sprintf (string, format, (long double) number);
> > > +  return __builtin_sprintf (string, format, (long double) number);
> > 
> > sprintf as well as __builtin_sprintf do not exist exactly when <stdio.h>
> > does not (or are not guaranteed to exist, anyway).
> 
> There are 2 issues:
> 
> The first issue is whether you get an error when you are building a cross
> compiler and the target you are using does not provide a stdio.h.  This is the
> error that this patch fixes.  I tend to regard not being able to build the
> toolchain are higher in priority than whether it works at runtime.

And I see both as basic requirements.  A patch that adds X should make X
work.

If you want to make decimal and/or QP float work only on 64-bit LE Linux
you should say so.  And in that case, that is certainly not acceptable
if it doesn't "sorry" at configure time already.

> The second is whether you get an error at link time because there is not
> sprintf or strtold functions.  For normal archive libraries, this would only be
> an issue if you actually do the conversion.  I have my doubts whether there is
> any extant code that wants to convert _Float128 to one of the Decimal types or
> vice versa.

So what are these patches for at all, again?

Anyway, if some conversion doesn't work (or cannot work correctly at
all, which is the same thing), you should simply disable the conversion
routines themselves (and then cascade that through the possible callers:just make them say "sorry, unimplemented").

> Note the second issue would affect x86_64 cross compilers as well, since they
> use those two functions to do the _Float128/Decimal versions.

Yes, it cannot work correctly at all there, either.

> I am open to suggestions of how to move forward.  I think we have to have a way
> to build cross compilers without decimal support (i.e. my third patch).
> Secondarily, I think we should allow the compiler to be built if there is no
> stdio.h, but the user did not disable decimal floating point.

Yes.  So just do not use it then.  Disable the feature that would use it.

> I don't think rewriting the Decimal conversions not to use GLIBC is really
> practical.

It is necessary if you want to support it on any other systems than the
one you use.


Segher