This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: basic-improvements merge status
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- 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: 17 Dec 2002 09:37:04 +0100
- Subject: Re: basic-improvements merge status
- Organization: Integrable Solutions
- References: <200212162212.RAA27306@makai.watson.ibm.com>
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