#149 missing prototypes for GCC __atomic_* builtins

[Ben Liblit]

gcc-4.7 introduced a new suite of builtins for atomic operations. These __atomic_* builtins are intended to replace the older __sync_* builtins, although the latter are being retained for backward compatibility. CIL does not have any inbuilt prototypes for these newer __atomic_* builtins. If any code uses them, CIL generates generic (and wrong) prototypes for what it thinks are calls to ordinary, undeclared functions. These explicit prototypes then result in undefined symbol references in the compiled object files, which in turn prevent the CIL-transformed program from linking. This is especially of concern to me because the version of GNOME that will ship with Fedora 21 now uses these __atomic_* builtins for various purposes. Thus, this CIL bug prevents me from building instrumented versions of GNOME applications, which is a fairly important thing for me to do.

The attached C source file demonstrates the problem, though without any GNOME dependencies. This source file compiles just fine using gcc test.c. However, when compiled using cilly test.c, we get a compile-time warning about conflicting types for built-in function '__atomic_load_4', and then a link-time error about undefined reference to '__atomic_load_4'. Inspecting intermediate files clearly shows that the cilly-compiled object file has an undefined reference to __atomic_load_4, but the gcc-compiled object file does not.

See https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html#g_t_005f_005fatomic-Builtins for details about the types of these builtin functions. Note that most are overloaded to work with multiple types, similar to the overloading of __sync_*. I hope that this will be a relatively easy fix by creating new CIL builtin entries for __atomic_* similar to those CIL already has for __sync_*.

[Ben Liblit]

Oops, it looks like many of the __atomic_* builtins do already have CIL prototypes, added in [ac5fd5] by Charlie Shepherd over year ago. There's really just a few new ones that we need to add. So far I've found __atomic_{load,store,compare_exchange}_{1,2,4,8,16} as missing. All of those already have similar prototypes for a variant ending in "_n" instead of a specific number. So the new ones should be pretty easy to add based on what's already there.

[Ben Liblit]

I have a fix in progress. The list of new builtins is actually fairly large, but quite regular in structure.

[Ben Liblit]

Fixed in [1c7ede], with a few purely-cosmetic tweaks immediately after in [122189] and [1eaf4a]. Unfortunately I think I don't actually have permission to close this bug ticket. Gabriel, perhaps you could do that for me?