This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] C++ builtins go in std and global namespaces

> > At the moment, this fix is moot as builtins are currently disabled in
> > the C++ front-end.  However accepting this patch now will simplify the
> > process of reviewing a patch to enable builtins in C++, once all of
> > the type-checking and semantic issues have been fixed (basically the
> > DECL_ANTICIPATED flag needs to be honored, so that a builtin doesn't
> > exist until it is prototyped).
> I thought we were agreed that we were moving towards not predeclaring
> these functions at all, but rather recognizing them when they are
> declared and annotating them appropriately.

I thought the most recent consensus was summarised in Joseph Myer's
If the views expressed there don't reflect the opinion of the general
body of GCC maintainers and contributors, it needs to be discussed

I believe that avoiding predeclaring functions would be working around
the real problems rather than solving them.

The fundamental problem is that DECL_ANITICIPATED is not correctly being
repected.  This leads to non-conformant warnings about identifiers being
redeclared of a different types, etc...

Instead of fixing this problem, GCC front-ends have come up with numerous
impressive work arounds purely to avoid the issue.  For example, declaring
builtins as NOT_BUILT_IN, declaring ALWAYS_BUILTIN functions that never
fall back to a library function, completely disabling builtins in C++
(for a significant performance loss) and of course special_function_p
and nothrow_libfn_p.

And because function attributes aren't currently preserved across
prototypes or function declarations, we've also come up with mechanisms
that recognize that a function prototype is in the standard library.
This is purely so that they can retain attributes, but this does
nothing fix attributes on user declared functions.

There's also the performance issue.  Checking whether we recognize a
function each time an identifier is encountered can be performed by
piggy backing on the existing symbol table lookup mechanisms.  This
would avoid duplicating code for hash tables (and would be much better
than the current O(n) sequential search implementation).

Of course with all things GCC, contributing a clean and efficient
implementation that conforms to language standards, compiles faster
and generates better code is likely to sway the argument.

Roger Sayle,                         E-mail:
OpenEye Scientific Software,         WWW:
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-438-3470

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]