This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: complex support routines
- From: "Gabriel Dos Reis" <gdr at acm dot org>
- To: "Jason Merrill" <jason at redhat dot com>
- Cc: gdr at acm dot org, "Jan Beulich" <jbeulich at novell dot com>,libstdc++ at gcc dot gnu dot org
- Date: Thu, 8 Jul 2004 23:58:43 +0200 (CEST)
- Subject: Re: complex support routines
- References: <s0ed2176.060@emea1-mh.id2.novell.com><32944.::ffff:24.250.169.187.1089279422.squirrel@webmail.nerim.net> <xypacyae5a5.fsf@miranda.boston.redhat.com>
- Reply-to: gdr at acm dot org
Jason Merrill:
> On Thu, 8 Jul 2004 11:37:02 +0200 (CEST), "Gabriel Dos Reis" <gdr@acm.org>
> wrote:
>
>> Jan Beulich:
>>> libstdc++'s complex header makes unconditional use of functions like
>>> __builtin_cabs[fl], which the compiler may (have to) expand to a
>>> function call to the normal (C99) function. However, not all platforms
>>> support this, and libmath support for all of the complex functions
>>> appears to have benn removed in late 2000. What I'd like to understand
>>> is how I'm supposed to use complex functions on a system that does not
>>> fully (or not at all) support C99 math/complex functionality.
>>
>> I think the proper fix is to have the compiler always emit the
>> apropriate
>> instructions without relying on the target having C99 functions.
>
> Surely you aren't suggesting that all processors have complex math
> instructions?
no. I'm suggesting:
(1) either they can be reasonably inlined, and they're inlined.
(2) or they are not, then, they're put into the runtime support
of the *compiler*, just like built-in stuff.
>> I don't have the time to propose a patch for that right now. However, a
>> short-term hack is to detect presence or absence of those and put stubs
>> in libmath. But, that would be the short-term hack for that problem.
>
> That seems like the right fix to me, not a short-term hack.
No. It can only be a very short-term fix, it can't possibly
be a long term fix. Most of those stuff are at the intersection
of the languages supported by GCC. I don't believe it would
be a good idea for each of those language runtime support to
implement their own versions (while the compiler applies
uniform treatments), each incompatible with other, with lots
of duplications.
Furthermore, the __builtin_xxx() stuff falling back to xxx()
causes name space issues. Joseph Meyers and I briefly
discussed this a couople of weeks ago on gcc-patches.
I believe, they should at least fall back to something
like __gcc_xxx or equivalent, which makes it possible for
each language to satisfy name space issues.
-- Gaby