This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Define __NO_MATH_INLINES and __NO_STRING_INLINES
On Thu, 27 May 2004, Giovanni Bajo wrote:
> > Since other systems than Linux (e.g. GNU Hurd, *bsd-gnu) use glibc, I
> > don't think linux.h is the right place.
>
> Right, but it looked good enough as a first step. Suggestions?
There's gnu.h and kfreebsdgnu.h as well at least, but maybe we should
refactor now rather than later for glibc systems and create a glibc.h
(which right now can have nonempty contents; linux.h defines
TARGET_C99_FUNCTIONS (as does alpha/linux.h) which should also apply for
all glibc systems).
> After that, I can prepare such project list if it is a requirement for the
> approval, but my understanding is that nobody will ever go through it until we
> find real world testcases where we regressed, or until people like Ukos start
> working on builtins because they need to. Either way, having a list of what we
> would lose from glibc inlines does not seem to be a great help for development.
The old list I put in the projects page - which used to be a lot longer -
was certainly used for that purpose, e.g.
<http://gcc.gnu.org/ml/gcc-patches/2000-11/msg01571.html>. The work at
that time was cooperative with glibc, with macros being disabled in glibc
for those functions for which built-in versions had been done in GCC.
> I *really* don't expect them cheating on us by changing the name of those
> macros or playing tricks like that.
My concern is rather that future optimizations may be added to glibc that
are actually useful but are hidden by those macros rather than being added
to GCC. The GCC and glibc developers should work out together the correct
development directions for this part of the GNU system that includes both
GCC and glibc (in particular with agreement about where future
optimizations go) rather than two parts each going their separate ways
with potential duplication of efforts.
--
Joseph S. Myers
jsm@polyomino.org.uk