[Bug ports/28872] Building glibc for MIPSel single float targets

["adhemerval.zanella at linaro dot org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=28872

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adhemerval.zanella at linaro dot o
                   |                            |rg

--- Comment #5 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Den from comment #4)
> > But are double-precision values passed in exactly the same way as when 
> > building for a processor supporting double-precision in hardware, so that 
> > objects built for double-precision hardware could run against a shared 
> > libm built for single-precision hardware, passing double values to the 
> > libm functions that take double arguments and getting double return values 
> > from them, as long as this is run in double-precision hardware, for 
> > example?
> > processors with only single-precision float in hardware 
> > have double-precision registers and double-precision loads and stores, so 
> > there is no separate single-precision ABI.  Though such processors aren't 
> > actually relevant for glibc because they aren't 'A' variant.)
> Double precision are emulating by GCC. For example, it "melts" opcode s.d
> (8) into a two sdc1 (4+4). But in case when there are assembler inlines with
> unsupported opcodes set exactly in them then, of course, the compiler will
> be rumbling.
> The question is not to thought-out a whole line of rewritting the glibc
> building for a single float abi, neither to create the special abi. There
> are exact files are failing to be compiled because of their assembler
> inlines with an unsupported opcodes set directly. Let everything will be
> with double precision as it is, but is there a way to rewrite these
> assembler inlines corectly so it can be compiled with the supported opcodes?
> That is not r5900 specific issue. If to build a cross compiler for r6000
> with setting it have no double float, then it appears here too. r6000 have
> double precision either the related opcodes, but the omission of the
> -mdoobule-float flag sets such opcodes like s.d,l.d and sqrt.d unsupported.

Not sure if it would characterize as a new ABI, at least libgcc seems to handle
it by checking __mips_fpr and setting macros for float and double load/store. 
Maybe you could use the same on the affected assembly in glibc.

-- 
You are receiving this mail because:
You are on the CC list for the bug.