Implementing "external" built-in functions

Hi,

clang emits calls to external functions for built-in functions it
cannot implement, the way GCC does:

From GCC doc about built-in functions for memory accesses:

"Not all operations are supported by all target processors. If a
particular operation cannot be implemented on the target processor, a
warning will be generated and a call an external function will be
generated. The external function will carry the same name as the
builtin, with an additional suffix `_n' where n is the size of the
data type."

Is is possible to implement those "external" built-in functions and
compile them with clang? The "problem" is that clang recognizes their
signature, and emit an error, such as:

error: definition of builtin function
   '__sync_fetch_and_and_4'

I'm unable to find a clang front-end option switch to disable this behavior.
What is the recommended way to compile such a built-in function?

I'm looking for a way to compile those functions in a dedicated
library, outside the clang build tree.

Thanks,
Emmanuel.

Have you tried -fno-builtin?

-Chris

Hi, I ran into this exact problem with an out-of-tree backend that will do stuff like that:

setOperationAction(ISD::ATOMIC_SWAP,  MVT::i32, Expand);

It seems -fno-builtin will only disable builtins marked as “f”

from \include\clang\Basic\Builtins.def
// f → this is a libc/libm function without the ‘_builtin’ prefix. It can
// be followed by ‘:headername:’ to state which header this function
// comes from.

I do not understand the rational for that.
I tried to disable all builtins when -fno-builtin but this caused about a dozen clang tests to fail
I didn’t investigate further.

I currently get around this problem by using this patch that allows builtins definition if -fno-builtin
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130603/081354.html

This is a particularly irritating misfeature of clang. In some parts of compiler-rt, I've hacked around this with #pragma redefine_extname, which causes clang to see one name when doing this analysis but use another when emitting the object code.

I don't really understand the rationale for the error. At best it should be a warning, but in my experience it's a warning with a 100% false positive rate...

David

I have seen cases where it makes sense, but there must be an easier /
less hackish way to override the default bheavior.

Joerg