[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Elijah Stone
Subject: Re: [Tinycc-devel] [PATCH 1/3] stdatomic: atomic builtins parsing support
Date: 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 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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]