[llvm-dev] Over-ride the compiler built-in functions .

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[llvm-dev] Over-ride the compiler built-in functions .

Jeremy Morse via llvm-dev
Hi All,

We are trying to override the compiler atomic builtin functions like 

int  __sync_val_compare_and_swap( int *p,int x ,int y)
{
         return *p; //ignore the function semantics here
}

int main()
{
         int x = 0, y = 1;
   y = __sync_val_compare_and_swap(&x, x, y);

   return x + y;
}

clang throws the error like 

test.c:1:6: error: cannot redeclare builtin function '__sync_val_compare_and_swap'
int  __sync_val_compare_and_swap( int *p,int x ,int y)
     ^
test.c:1:6: note: '__sync_val_compare_and_swap' is a builtin with type 'void ()'
test.c:1:6: error: definition of builtin function '__sync_val_compare_and_swap'
int  __sync_val_compare_and_swap( int *p,int x ,int y)

But GCC compiles it and we think that GCC is right here unlike clang.

We would like to hear from the community view on this.

Thank you 
~Umesh 

  

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [cfe-dev] Over-ride the compiler built-in functions .

Jeremy Morse via llvm-dev
On Mon, 20 Jan 2020 at 10:57, Umesh Kalappa via cfe-dev
<[hidden email]> wrote:
> But GCC compiles it and we think that GCC is right here unlike clang.

Names starting with two underscores (or a single underscore and a
capital letter) are reserved by the C and C++ standards for the
compiler to use. Defining any function like that is technically
undefined behaviour; defining one the compiler actually does use like
these atomic ones is extremely risky and Clang has decided it's better
to diagnose these issues than proceed with unknown behaviour.

Without the diagnostic, I believe your implementations would never be
called the way Clang is currently implemented.

> We would like to hear from the community view on this.

I think Clang is certainly technically in the right, and I'm not
convinced the ability to override them is a feature worth
implementing.

Cheers.

Tim.
_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev