basic-improvements merge status

[Jan Hubicka]

> David Edelsohn <dje@watson.ibm.com> writes:
> 
> | >>>>> 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 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
-fdisable-builtins.
> 
> 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?

Honza
> 
> -- Gaby