On Fri, 8 Sep 2006, Edmar Wienskoski wrote: > So the key questions are: > 1 - What should I expect in regards to __lttf2 (and similar symbols). > (like, when they should be defined, referenced, and when not)
They should not be defined or used at all. IBM long double should use __gcc_*, and IEEE long double (not supported for Linux) should use _q_*. (Perhaps *tf* are appropriate for any functions for IEEE long double that don't have _q_ versions in the PowerPC SysV ABI.) See <http://sources.redhat.com/bugzilla/show_bug.cgi?id=2749>. As well as glibc patches, it includes a GCC patch from David Edelsohn to support IBM long double with soft-float. For E500 single you'll need this patch, plus further changes to use the same helper functions for E500 single as for soft-float. For E500 double you'll need to add machine description patterns like those that implement long double in terms of 6xx floating point. > 2 - Why darwin-ldouble.c only generates code for __gcc_qadd if fp registers > are present ? > NOTE: The 8548 does have hardware instructions for implementing f.p. (s.p. and > d.p.) but > it uses the gp registers. So the definition of __NO_FPRS__ is correct for this > target. It requires fused multiply add instructions and has them hardcoded in an asm (two asms using fmsub). To use with soft-float, fused multiply add support is needed in soft-fp, which shouldn't be hard to implement. Steven Munroe was working on this. (Note that such patches would need to be accepted in glibc before new sources are imported into GCC, in accordance with the policy on imported sources. As soft-fp maintainer for GCC I can only approve changes to soft-fp build support, not to the core code.) It appears E500 double doesn't include fused multiply add support, so you'd need to use soft-fp for this case as well. > 3 - Is the use of configuration option --disable-shared required for this > target (because hardware differences > like the lack of fp registers) or am I just avoiding a problem that should be > fixed ? It's avoiding a problem. -- Joseph S. Myers [EMAIL PROTECTED]
