This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ 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: complex support routines


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



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