[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