Re: [Tinycc-devel] [PATCH 1/3] stdatomic: atomic builtins parsing support

[Elijah Stone]

On Wed, 27 Jan 2021, Dmitry Selyutin wrote:

> > Should these be tokens?  I think it makes more sense for them to 
> > be preprocessor macros, as in gcc/clang.
> Could you point me, please, to the place which defines these macros? 
> I've been under impression these are intrinsics as well. 
> Frankly speaking, I'd go for enum memory_model, but I'm unsure of the 
> place where to provide it.

You can do, for example, '#undef __ATOMIC_RELAXED' in gcc and it will work 
fine.  They are predefined automatically.

The right place to put this for tcc is probably just tccdefs.h.  The 
memory_model enum should still be defined in terms of __ATOMIC_*.


> > GCC uses those same names for intrinsics with different semantics.
> Yes, I'm know. These exact names are built-ins in gcc, not symbols, so 
> we should be safe wrt names collisions

I mean, if you have some code that currently assumes it's being compiled 
by gcc, it may have a line in it like __atomic_exchange(something, 
something, something, something).  Which obviously won't work in tcc with 
the current patch.  But the error message will be confusing since tcc 
still has an intrinsic by the same name (even though it has different 
behaviour).

It would also mean that, if we want to support the gcc intrinsics in the 
future, we wouldn't be able to do so without breaking compatibility.


> I can prefix our symbols with something like __tcc_ for now though, and 
> possibly on some later stage the code would support aliases if needed.

How about __c11_, for clang compatibility?

 -E