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

["archicharmer at mail dot ru" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #4 from Den <archicharmer at mail dot ru> ---
> 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.

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