Unreviewed patches

Roger Sayle roger@eyesopen.com
Fri Feb 1 11:07:00 GMT 2002


Hi Joseph and Gaby,
> > The same should apply to builtins.  And I think builtin names should
> > begin with a double underscore.  Why do you want to remove them?
>
> I think the C++ front end is correct just to declare the __builtin names
> (flag_no_builtin always set to 1) and require the headers to make
> appropriate definitions that use the built-in functions.
>
> __builtin names may be predeclared by the compiler.  All others should
> need to be declared explicitly - for C++, by the standard headers, though
> in C it is OK for programs to declare some standard functions themselves
> (and C90 allows implicit declarations).  Such functions should be treated
> as undeclared until they are declared by a header or the program, at which
> point, for C only (since for C++ it must be the headers declaring the
> functions) it may be decided that the function declared can be built-in.
>
> See my outline at http://gcc.gnu.org/ml/gcc-patches/2001-11/msg01783.html
> which discusses a possible direction for cleaning up handling of built-in
> functions and attributes along those lines.

I see this patch, adding builtins to both std and global namespaces, and
several of the others concerning attributes of builtin functions as the
necessary first steps towards implementing Joseph's outline for how
builtins should be handled in the C and C++ front-ends.

The first misunderstanding that needs to be cleared up is that GCC
builtin function does not need to be predeclared.  I completely agree
that for the C++ front-end to make use of an "intrinsic" function, it
needs to be explicitly prototyped, typically by a system header.  Use
of a builtin function without a prototype should result in a compiler
error or warning in both the C and C++ front-ends.  Similarly, it should
be possible to use a builtin identifier in a different context provided
that a prototype hasn't been encountered, "int strlen;".

I believe that the correct way to do this is to correctly honor the
DECL_ANTICIPATED flag on the declaration.  In the C++ front-end,
if builtins were re-enabled, the forms of builtins with names that
start with two underscores are predeclarerd, but the names without
the underscores are registered in the symbol table, but marked as
"anticipated" (DECL_ANTICIPATED(decl) = 1).  My interpretation is
that these identifiers are flagged for special treatment once a
suitable definition or prototype is encountered, but should behave as
undeclared until then.


As I explained http://gcc.gnu.org/ml/gcc-patches/2001-11/msg01723.html
this mechanism of "anticipating" rather than predeclaring identifiers
in the symbol table is dramtically more efficient than trying to recognize
a "special" identifier by other means each time an identifier is
encountered.


Once implemented correctly, DECL_ANTICIPATED, should also be able to
replace both "special_function_p" and in "nothrow_lib_fn_p", as all of
the functions in the standard C library should be anticipated with their
correct function attributes, including "nothrow".  This would then allow
builtins to be re-enabled resulting in nice performance increase for C++
code.


But getting back to that particular patch at hand, both ::strlen and
std::strlen will need to be anticipated in this new scheme.  And both
functions should then be marked "pure" and "nothrow".  Currently
the C front end will optimize "strlen(ptr) > 0". Eventually I would
hope that C++ should be able to optimize both "::strlen(ptr) > 0" and
"std::strlen(ptr) > 0" provided the function has been defined by the
system header.


If you'd like me to explain any more of the intermediate steps in the
planned vision of builtins in the C/C++ front-ends, I'm more than happy
to share, but I've been waiting until after the freeze before continuing
this series of patches.

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-473-0833



More information about the Gcc-patches mailing list