This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Invalid code in <limits>
Phil Edwards <phil@jaj.com> writes:
| On Wed, Jan 29, 2003 at 03:45:18PM +0100, Gabriel Dos Reis wrote:
| > Phil Edwards <phil@jaj.com> writes:
| >
| > [...]
| >
| > | Perhaps we should try to evaluate and fold the expression before diagnosing
| > | the presence of a function call?
| > |
| > | 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.
| >
| > Builtins are defined with various attributes, among which a bit to
| > tell that the compiler *do* about the builtin and it is its
| > responsability to make sense of it:
| >
| > /* Like DEF_LIB_BUILTIN, except that the function is expanded in the
| > front-end. */
| > #undef DEF_FRONT_END_LIB_BUILTIN
| > #define DEF_FRONT_END_LIB_BUILTIN(ENUM, NAME, TYPE, ATTRS) \
| > DEF_BUILTIN (ENUM, NAME, BUILT_IN_FRONTEND, TYPE, TYPE, \
| > true, true, false, ATTRS)
| >
| > The basic machinery is already there.
|
| Yes, I'm making use of it already. :-) Perhaps we can examine the "what
| to do if the builtin cannot be expanded by the compiler" part;
That is a hard error. If the built-in were intended to have a
fallback, then it would have been declared with the BUILT_IN_NORMAL
bit.
-- Gaby