Re: [Patches] Fix (or workaround?) s_fma/s_fmaf build failure on soft-float ColdFire

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

On Thu, 20 Oct 2011, Julian Brown wrote:

> The attached patch seems to suffice to allow the library to build
> again, as long as the following (in-discussion) patch is also present:
> 
> http://comments.gmane.org/gmane.comp.lib.glibc.alpha/16740

My version of that was committed some time ago.

commit e057a1b5930ec538c2b8abbba700a436ef2c81d5
Author: Joseph Myers <joseph@xxxxxxxxxxxxxxxx>
Date:   Wed Sep 21 13:27:50 2011 -0700

    Link libresolv.so with ld.so for __stack_chk_guard.

> OK to apply, or any comments?

I think you should join in the discussion in 
<http://sourceware.org/bugzilla/show_bug.cgi?id=13304> of approaches to a 
proper fma implementation for targets without exceptions / rounding modes.

> ChangeLog (ports)
> 
>     sysdeps/
>     * m68k/coldfire/s_fma.c: New.
>     * m68k/coldfire/s_fmaf.c: New.

There is no ChangeLog at the sysdeps/ subdirectory; all ports ChangeLogs 
are relative to toplevel.  I'd have expected a nofpu/ directory to be used 
so that such versions are only used for the no-FPU case, not for ColdFire 
with FPU.

(Given use in proper subdirectories, I think the versions here probably 
would be correct in the presence of a proper fma implementation in libc 
not relying on exceptions / rounding modes - in that the proper 
implementation would probably replace the present math/s_fma* files.)

Note that right now ColdFire also needs __*_finite updates to 
sysdeps/m68k/coldfire/fpu/e_sqrt*, to update it for libc commit 
0ac5ae2335292908f39031b1ea9fe8edce433c0f.  And classic m68k was updated 
for that commit but hasn't yet been updated for the subsequent commit 
bcf01e6d800e837622ddbc851b42b55fa99e5636 adding such aliases for exp, 
expf, expl.

-- 
Joseph S. Myers
joseph@xxxxxxxxxxxxxxxx
_______________________________________________
Patches mailing list
Patches@xxxxxxxxxx
http://eglibc.org/cgi-bin/mailman/listinfo/patches