This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ 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 writes:
> 
> >> #ifndef HAVE_SINF
> >> float
> >> sinf(float x)
> >> {
> >> return (float) sin(x);
> >> }
> >> #endif
> >> 
> >> is being compiled as
> 
> Jan> I think we can deal with -fno-builtin-fsin to avoid gcc from being
> Jan> active on optimizing this.
> Jan> The name sinf is reserved by C90 standard, so this is not valid C.
> 
> float
> foo (float x)
> {
>   return (float) sin(x);
> }
> 
> always should be valid without the user having to specify -fno-builtin, as
> your change requires on systems without sinf().  stubs.c could be compiled

As I've mentined I am handling this with the other patch that disables
the transfomration for C90 until we decide how to detect such systems.
On C99 and C++ it is always valid as runtime is required to have it (and
thats why libstdc++ does it).  I hope Richard will have time to take a
look on these patches soon.

I am not configure expert, but can I detect the runtime library
properties in it?  (when we are building without glibc, we need to
rebuild anyway at least on Linux bootstrap, so this should be possible)
Other way would be to use target macro.  Something like
TARGET_C99_RUNTIME.  Ideal would be to push these functions into libgcc,
but I am not quite sure how this can be done (ie so they will be
overwriten by runtime).
What sounds sane?

Honza

> with -fno-builtin, but that's just covering up the incorrect assumption in
> the transformation.
> 
> David


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