[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tinycc-devel] [PATCH 1/3] stdatomic: atomic builtins parsing suppor
Re: [Tinycc-devel] [PATCH 1/3] stdatomic: atomic builtins parsing support
Tue, 26 Jan 2021 23:46:43 -0800 (PST)
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
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?