On 07/14/2015 09:01 AM, Jason Merrill wrote:
I wonder if it would make sense to handle this when we actually try to
emit a reference to one of these functions in the back end, rather than
in many places through the front end.
If it's going to stay in the front end, the C and C++ front-ends should
share an implementation of this function, in c-common.c.
Thanks for the comments and the suggestion. It would certainly
be much cleaner if it could be detected in one place. Let me
investigate the back end option.
FWIW, my initial attempt at a patch did have a single function
with common logic, until it became clear that the C++ conditions
the function tested were slightly different (and more involved
due to the checks for operators new and delete) than those in
C. But since they don't seem to be incompatible with one another,
as long as no one minds that when called from the C front end
the function ends up doing some unnecessary work I can merge
them back (if the back end idea doesn't pan out).
Most of the calls in the C++ front end can be replaced by a single call
in mark_rvalue_use.
-#ifdef ENABLE_CHECKING
+#if 0 // def ENABLE_CHECKING
This change is unrelated.
Yes, sorry about that.
+#define DECL_IS_GCC_BUILTIN(DECL) \
This macro name could be clearer. DECL_IS_ONLY_BUILTIN?
DECL_IS_NOFALLBACK_BUILTIN?
I derived DECL_IS_GCC_BUILTIN from the DEF_GCC_BUILTIN macro
in builtins.def used to define such builtins. There are no
DECL_IS_XXX_BUILTINs for the other DEF_XXX_BUILTIN macros yet
but I imagine there could be and it seems that keeping the
names consistent would make the two sets of macros easier to
understand and work with. But if you don't think this is
important I'm fine renaming the macro.
Martin
