Hi Michael,
perhaps you missed one of arguments I mentioned before. Yes, indeed, the
compiler is not required to insert the symbol reference and is able to
inline the code. But the symbols must still be present, at least to let
legacy/other-vendor-implementation code work. Please, refer to the
doc
Hello,
On Mon, 22 Mar 2021, Dmitry Selyutin wrote:
"is it really the same type?"
A bit ambiguous wording. What I mean is that, for a naturally-aligned type
N, the corresponding call can be generated to routine __atomic_X_N. The code
generator doesn't need to care whether types in the _im
>
> "is it really the same type?"
>
A bit ambiguous wording. What I mean is that, for a naturally-aligned type
N, the corresponding call can be generated to routine __atomic_X_N. The
code generator doesn't need to care whether types in the _implementation_
of __atomic_X_N must literally match those
> But the atomic functions don't do that.
This is wrong. It's not mentioned where they do it or not, because
it's out of scope of atomics how the function passes arguments and how
it returns them.
All that is mentioned is that for naturally-aligned type N there might
be a call generated to routine
> I see. Those return integer types and hence aren't convertible to struct
> types either (not even with a cast). This doesn't (and shouldn't)
> compile:
This is because it's not supposed to be called directly. These calls
are _generated_, they're not some kind of manual call.
From GCC's point of
Hello,
On Mon, 22 Mar 2021, Dmitry Selyutin wrote:
Is the above atomic_load supposed to be similar to the GCC __atomic_load
intrinsic?
No, it's supposed to be similar to __atomic_load_N.
I see. Those return integer types and hence aren't convertible to struct
types either (not even with a
> Is the above atomic_load supposed to be similar to the GCC __atomic_load
> intrinsic?
No, it's supposed to be similar to __atomic_load_N.
> hence structs aren't passed around
It depends on the calling convention.
For the __atomic_##_N, it seems like we can pass things this way, as
long as pointe
Hello,
On Fri, 19 Mar 2021, Dmitry Selyutin wrote:
Some complex types can still be small and simple enough to fit into
register. Other compilers allow some operations on these types, and it
seems to be quite a reasonable choice. From now on, we should be able
to compile the following artificial
Hello,
On Mon, 22 Mar 2021, Dmitry Selyutin wrote:
> Dispatching to per-type functions (instead of per-size ones) is mere busy
work
Having a function per each supported size plus one for emulated locking is
still safer than having a pair, where one deals with opaque data type.
> all that code
> Dispatching to per-type functions (instead of per-size ones) is mere busy
work
Having a function per each supported size plus one for emulated locking is
still safer than having a pair, where one deals with opaque data type.
> all that code is generated and implementation specific, not user
visi
Hello,
On Sat, 20 Mar 2021, Dmitry Selyutin wrote:
This needs casts, both sign- and type-wise, e.g. signed long long to
unsigned char, and has no way to enforce type safety, even in the minimal
form. A minimally suitable form would require a statement expression, plus
typeof, and even then it w
This needs casts, both sign- and type-wise, e.g. signed long long to
unsigned char, and has no way to enforce type safety, even in the minimal
form. A minimally suitable form would require a statement expression, plus
typeof, and even then it would have to be tuned to work with types that are
binar
Dmitry Selyutin wrote:
Actually, why don't you try to use just the normal tcc function parser?
It knows how to type-check arguments, it knows how to assign the correct
return type, it knows how to call functions according to ABI conventions
on Linux and Windows as well, and it kn
>
> struct foo {
> uint8_t a;
> uint16_t b;
> };
> struct foo x, y;
> memset(&x, 1, sizeof(x));
> memset(&y, 2, sizeof(y));
> x.a = y.a = x.b = y.b = 0;
> atomic_compare_exchange(&x, &y, y);
>
This is a good question; for the case you presented, things will work,
since the padding
On Fri, 19 Mar 2021, Dmitry Selyutin wrote:
Some complex types can still be small and simple enough to fit into
register. Other compilers allow some operations on these types, and it
seems to be quite a reasonable choice.
How should padding be handled? For example:
struct foo {
uint
>
> Actually, why don't you try to use just the normal tcc function parser?
>
> It knows how to type-check arguments, it knows how to assign the correct
> return type, it knows how to call functions according to ABI conventions
> on Linux and Windows as well, and it knows how to pass small structs
Dmitry Selyutin wrote:
Some complex types can still be small and simple enough to fit into
register. Other compilers allow some operations on these types, and it
seems to be quite a reasonable choice. From now on, we should be able
to compile the following artificial example:
struct combo {
Some complex types can still be small and simple enough to fit into
register. Other compilers allow some operations on these types, and it
seems to be quite a reasonable choice. From now on, we should be able
to compile the following artificial example:
struct combo {
uint16_t lo;
18 matches
Mail list logo
