Re: [patches] [PATCH] Powerpc/trampline: consider __NO_FPRS__

["Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>]

On Thu, 17 Jun 2010, Steven Munroe wrote:

> On Thu, 2010-06-17 at 20:46 +0000, Joseph S. Myers wrote:
> > I don't see any reason for this to be EGLIBC-specific; have you tried 
> > submitting it to libc-alpha?  If ignored or rejected there (FSF glibc is 
> > unpredictable regarding libc changes for Power soft-float) we can then put 
> > it in EGLIBC.
> > 
> > Send ChangeLog entries as plain text in the body of a patch submission, 
> > not as diffs, since they won't generally apply cleanly if any other 
> > patches have gone in since you prepared the diff.
> > 
> Insead of conditional compiler this should be split between the powerpc/
> and powerpc/fpu implementations.
> 
> Also the I thought this was handled in ports for EABI. I don't know of
> any server or desktop that does not support FPU.

There are existing conditionals in FSF glibc in 
sysdeps/powerpc/fpu/bits/mathinline.h for _SOFT_FLOAT (for installed 
headers, such conditionals are required for EGLIBC, for which it is a 
feature that a single set of headers can be shared between multilibs that 
may differ in such matters as whether an FPU is present).  Pragmatically, 
for this sort of case putting in conditionals makes a lot more sense than 
multiplying variant files - especially when you don't want multiple files 
containing duplicate copies of all the code that applies for both FPU and 
non-FPU, so you'd end up with extra files defining macros to consist just 
of the floating-point register code, or nothing.

In other words, the alternative to __NO_FPRS__ conditionals here in libc 
is more complicated conditionals here in libc in order to allow a libc 
file to specify the existing code and a ports file to specify empty code, 
which seems like gratuitous complexity for the sake of it.

-- 
Joseph S. Myers
joseph@xxxxxxxxxxxxxxxx