basic-improvements merge status

[Gabriel Dos Reis]

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.

I see values for the mentioned transformation.  But bindly applying it
is a -not- a service.

-- Gaby