This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: atomic memory operation builtins, v2
- From: Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>
- To: Richard Henderson <rth at redhat dot com>, Mark Mitchell <mark at codesourcery dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 15 Apr 2005 09:23:15 +0200
- Subject: Re: atomic memory operation builtins, v2
- References: <20050408220513.GA11088@redhat.com> <20050414233910.GA25705@redhat.com>
Richard Henderson wrote:
I've committed the following patch. Follow on patches
for i686 and ia64 will follow shortly.
Tested on i686 and ia64 linux.
Here is the patch that I am using to implement Altivec builtins in C++
(this is stage2 material); it matches very closely how you call
resolve_overloaded_builtin in the C front-end. Can you expand on what's
wrong with it?
Index: cp/call.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/call.c,v
retrieving revision 1.534
diff -p -u -u -r1.534 call.c
--- cp/call.c 1 Apr 2005 08:29:49 -0000 1.534
+++ cp/call.c 15 Apr 2005 07:20:22 -0000
@@ -2752,6 +2752,22 @@ build_new_function_call (tree fn, tree a
if (args == error_mark_node)
return error_mark_node;
+ /* Implement target-directed function overloading for builtins.
+ The target handles all type checking. The result is a complete
+ expression that implements this function call. */
+ /* ??? This is ugly. Please don't let this existance of this hook
+ encourage anyone to emulate the horrible things that AltiVec has
+ perpetrated. */
+ if (targetm.resolve_overloaded_builtin
+ && TREE_CODE (fn) == FUNCTION_DECL
+ && DECL_BUILT_IN_CLASS (fn) == BUILT_IN_MD)
+ {
+ result = targetm.resolve_overloaded_builtin (fn, args);
+ if (result)
+ return result;
+ }
+
+
/* Get the high-water mark for the CONVERSION_OBSTACK. */
p = conversion_obstack_alloc (0);