This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] PowerPC 128 bit long double compatibility (PR target/19019)


David Edelsohn <dje@watson.ibm.com> writes:

> >>>>> Geoffrey Keating writes:
> 
> >> /* Standard AIX/Darwin/64-bit SVR4 quad floating point 
> >> routines.  */
> >> !       set_optab_libfunc (add_optab, TFmode, "__gcc_qadd");
> >> !       set_optab_libfunc (sub_optab, TFmode, "__gcc_qsub");
> >> !       set_optab_libfunc (smul_optab, TFmode, "__gcc_qmul");
> >> !       set_optab_libfunc (sdiv_optab, TFmode, "__gcc_qdiv");
> >> }
> >> else
> >> {
> 
> Geoff> Shouldn't this part be conditional on some flag, xlc-compat or 
> Geoff> something?  (The rest looks fine.)
> 
> 	Only AIX and XLC provide the _xlq routines and GCC on platforms
> other than AIX.  Non-AIX platforms do not normally link with the XLC
> support library.  The GCC semantics are stricter, so I think that we only
> lose performance by always using the GCC functions.  I do not see that we
> generate any usable code if we make the symbols conditional on xl-compat.

Well, you'd generate code that could link with xlc...

But I'm fine with the original patch if you think it's right.

Although the semantics are stricter, I'm not sure that you can take an
xlc-derived value and feed it into GCC's supports routines and have it
work; when I was writing the routines I didn't try to analyse invalid
inputs to see what they did.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]