> 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. ср, 27 янв. 2021 г., 02:46 Elijah Stone <elro...@elronnd.net>: > 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 >
_______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
