This is the mail archive of the
mailing list for the libstdc++ project.
Re: basic-improvements merge status
- From: Jan Hubicka <jh at suse dot cz>
- To: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- Cc: David Edelsohn <dje at watson dot ibm dot com>,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: Tue, 17 Dec 2002 09:50:43 +0100
- Subject: Re: basic-improvements merge status
- References: <200212162212.RAA27306@makai.watson.ibm.com> <email@example.com>
> David Edelsohn <firstname.lastname@example.org> writes:
> | >>>>> Zack Weinberg writes:
> | Zack> David Edelsohn <email@example.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 think this is a case where GCC's logic in apply transformations just
> breaks down.
> | 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.
> I don't think libstdc++-v3 is at fault here. I think it is the
> middle-end. That is, if as a programmer, I do know that the target is
> lacking sinf() and consciously I did write "(float) sin(x)", then I
> find it a diservice that GCC calls a sinf(). Really.
Yes, I see that.
But it is really not different from reusing memset() call for totally
different purpose. You function is not valid C so it should use
> I see values for the mentioned transformation. But bindly applying it
> is a -not- a service.
In what conditions do you think we should apply that?
> -- Gaby