> 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.
> 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; also the names used in fact are __atomic_store_8, not __atomic_store. 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.
On Tue, 26 Jan 2021, Dmitry Selyutin wrote:
> +/* memory models */
> + DEF(TOK___ATOMIC_RELAXED, "__ATOMIC_RELAXED")
> + DEF(TOK___ATOMIC_CONSUME, "__ATOMIC_CONSUME")
> + DEF(TOK___ATOMIC_ACQUIRE, "__ATOMIC_ACQUIRE")
> + DEF(TOK___ATOMIC_RELEASE, "__ATOMIC_RELEASE")
> + DEF(TOK___ATOMIC_ACQ_REL, "__ATOMIC_ACQ_REL")
> + DEF(TOK___ATOMIC_SEQ_CST, "__ATOMIC_SEQ_CST")
Should these be tokens? I think it makes more sense for them to be
preprocessor macros, as in gcc/clang.
> + DEF(TOK___atomic_store, "__atomic_store")
> + DEF(TOK___atomic_load, "__atomic_load")
> + DEF(TOK___atomic_exchange, "__atomic_exchange")
> *snip*
GCC uses those same names for intrinsics with different semantics.
(https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html)
I think supporting the GCC intrinsics would be cool, but that failing that
we shouldn't collide with their names.
-E
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel