This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Pure and const attributes for builtins
- From: Roger Sayle <roger at eyesopen dot com>
- To: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- Cc: <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 26 Nov 2001 14:44:48 -0700 (MST)
- Subject: Re: [PATCH] Pure and const attributes for builtins
Hi Joseph,
> The C front end already has other O(n^2) lookups. I couldn't work out
> which of the many hash table implementations available in GCC would have
> been the appropriate one to use for lazy attributes.
> ...
> It checks them according to a strange undocumented procedure with
> allowances for pre-ISO system headers (which probably differs in the
> C and C++ front ends).
> ...
> If you want to create a type-checking function (implementing the existing
> rules for when types are or are not consistent - with testcases, of
> course) that works in both the C and C++ front ends, feel free to do so.
I think that a far cleaner solution is to have a single hash-table for
identifiers (c.f. the work integrating the preprocessor's symbol table),
and re-use the code that compares types that already in c-decl.c and
cp/decl.c that is used by the existing builtin implementation. I really
can't see any point in duplicating this code, that is already efficiently
reused by the existing builtin system.
> The existing system applies the attribute if it is consistent with the
> function prototype (silently dropping it if not consistent with the
> prototype, which is better than the old system of applying the format
> attributes to the function names, not decls, regardless).
I believe that you're getting confused here. The original builtin system
applies the attributes if they are consistent, it's your recent patch
http://gcc.gnu.orh/ml/gcc-patches/2001-09/msg01078.html, Lazy default
attributes patch, that doesn't check the types match. Look at where my
the original builtins are processed in gcc/c-decl.c and gcc/cp/decl.c to
see that they have explicit type matching dependent upon the front-end.
Roger
--
Roger Sayle, E-mail: roger@eyesopen.com
OpenEye Scientific Software, WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road, Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507. Fax: (+1) 505-438-3470