[PATCH] Builtins and C++ and such

Roger Sayle roger@eyesopen.com
Wed Mar 20 10:40:00 GMT 2002


> I'd still prefer to handle this differently.

I agree with the arguments that this needs to be handled differently
in the long term.  The reason the code is so short is that its ablity
to re-use all of the C/C++ common middle-end handling of built-ins.
However, as has been pointed out, this isn't suitable for Java, FORTRAN
or Ada built-ins, so we should eventually switch to language hooks.
My patch just gives us some breathing room to implement that approch.

In the medium term, the DECL_ANTICIPATED approach might solve both
the ISO C++ conformance problems, and simplify all of the hacks in
the libfn_nothrow and special_function_p code.  I can also lead to
significant simplifications in the attribute handling in the C
front-end, including the performance issues that come from the
current "default_attribute" processing.

The strategy of fixing and simplifying what's there now, will make
it much easier to develop "next generation" built-in handling and
perform tree-level transformations on ASTs.  But I'm willing to
keep an open mind.

Roger
--



More information about the Gcc mailing list