http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57357
--- Comment #9 from thutt at vmware dot com ---
(In reply to Andrew Pinski from comment #8)
> Since glibc controls the headers we (GCC) project cannot do anything.
???
>From your standpoint of having cpp produce different output, I understand
your position that the gcc project cannot do anything.
If you look from the standpoint of the user of gcc, that position makes
little sense: changing the value of a compiler option should not cause
code to suddenly produce an error.
The problem doesn't lie in the header file, though it could be fixed there
with preprocessor work.
The problem really lies in the fact that the compiler is producing
an error message for a function that has been parsed, but has not been used:
extern __inline __attribute__ ((__gnu_inline__)) double
__NTH (wcstod (__const wchar_t *__restrict __nptr,
wchar_t **__restrict __endptr))
{ return __wcstod_internal (__nptr, __endptr, 0); }
>From the standpoint of the user, that particular issue
*is* addressable by the gcc team.
Course, that's from the standpoint of the user...
> Why are you using -mno-sse on an user space application anyways?
I volunteer to file defects against gcc because I have an open account,
but I can't speak to the reasoning behind each one that is provided to
me -- I just validate the information, and try to write up a good synopsis.
In this particular case, I think it was found during preliminary testing
before upgrading the compiler; it may have been a one-off by-hand program
to do some other testing, I don't really know... I can go back and ask if you
are really curious...
For the team that I work on, we don't want hardware-using FPU code generated,
mostly.
That was the genesis of the other sse-related ticket I recently filed.
