This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: basic-improvements merge status


Jan Hubicka <jh@suse.cz> writes:

| > 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.

Which function is not valid C? 

Please, do remember that libtdc++-v3 is part of the compiler runtime
support, so your argument that it is not valid is pointless.

| > 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?

There ought to be a switch to tell the compiler which functions not to
use its transformations.

-- Gaby


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]