This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Invalid code in <limits>
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Phil Edwards <phil at jaj dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, "gdr at integrable-solutions dot net" <gdr at integrable-solutions dot net>, "rth at redhat dot com" <rth at redhat dot com>
- Date: Wed, 29 Jan 2003 08:59:28 -0800
- Subject: Re: Invalid code in <limits>
--On Wednesday, January 29, 2003 09:30:42 AM -0500 Phil Edwards
<phil@jaj.com> wrote:
Perhaps all __builtin_xxx functions which are capable of being in an
i.c.e. should simply have a certain attribute on them? The compiler sees
const static int foo = ...... fn() ...
and checks for the attribute on fn; if not there, it's an error.
Again, all we need here is the notion of a builtin *value*. There's
nothing scarier about adding those then adding lots of builtin
*functions* that always return the same value.
The condition we could try to test for using the existing syntax is
that (a) it's a builtin function, (b) there are no parameters, (c)
the function has the "const" attribute, (d) it's on a special list
of things we know how to fold.
The (b) requirement is perhaps not strictly necessary, but in order
not to make things unbelievably complex you need it.
Furthermore, there are issues with name mangling:
template <typename T>
void f(int (*)[__builtin_fn() + sizeof (T)])
needs a manglined name. Do you mangle the builtin as a function call?
Or as the underlying value? Is __builtin_strchr("abc", 'b') valid?
We do not want to go here, and there is no compelling need. It's
perfectly possible to implement <limits> without using these extensions,
and while still preserving scalability, flexibility, extensibility,
and lots of other ibilities.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com