This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: basic-improvements merge status
- From: Jan Hubicka <jh at suse dot cz>
- To: David Edelsohn <dje at watson dot ibm dot com>
- Cc: Zack Weinberg <zack at codesourcery dot com>, Jan Hubicka <jh at suse dot cz>,gcc at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org
- Date: Mon, 16 Dec 2002 23:18:28 +0100
- Subject: Re: basic-improvements merge status
- References: <87bs3l3ab5.fsf@egil.codesourcery.com> <200212162212.RAA27306@makai.watson.ibm.com>
> >>>>> Zack Weinberg writes:
>
> Zack> David Edelsohn <dje@watson.ibm.com> writes:
> >> Any idea what change in GCC 3.4BIB is causing GCC to "optimize"
> >>
> >> (float) sin(x)
> >>
> >> as
> >>
> >> sinf(x)?
>
> Zack> I remember such an optimization being implemented but I can't find the
> Zack> change log entry for it. My recollection is that it was Jan Hubicka
> Zack> who coded it. Jan?
>
> Yes, it appears to be due to the builtins.def changes by Jan which
> assumes that all of those functions natively are available on every
> target. One cannot make that assumption. Testing for the existence of
> those functions on the target is not easy.
I noticed that already and there is patch waiting for that. So hope it
will get reviewed soon.
I am not quite sure how to deal with this (whether we can autoconfigure
on whether runtime does have them or not). At the moment I do the
transformation only when -std=c99 or gnu99 is specified when the
transformation is valid as the standard requires these functions.
Honza
>
> In most cases, the transformation will result in a linker error on
> systems which do not provide the function, but libstdc++-v3 graciously
> provides the symbols, creating a recursion in those definitions.
>
> David