wish: gcc_jit_type_get_atomic

wish: gcc_jit_type_get_atomic

[Basile Starynkevitch]

Hello all,

GCC JIT has gcc_jit_type_get_volatile to support the volatile qualifier.

But shouldn't it also have a gcc_jit_type_get_atomic to support the C11 
_Atomic qualifier?
http://en.cppreference.com/w/c/atomic

Cheers.

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: wish: gcc_jit_type_get_atomic

[Basile Starynkevitch]

Hello All,

In message https://gcc.gnu.org/ml/jit/2016-q2/msg00013.html David 
Malcolm nicely explained that

> Client code might be able to implement it without explicit libgccjit support
> by generating calls to the relevant builtins "by hand".


But I am not sure to understand exactly how that can be done in (more or 
less portable)
C code calling libgccjit-6. In particular I am thinking of coding in C 
some code which would use libgccjit-6 but would not be compiled by gcc-6 
(but some other C compiler, perhaps a future gcc-7, or clang, or tinycc, 
etc...)

What I am understanding is that I should construct with GCCJIT an AST 
similar to the following C code:

extern int a;
extern void show_int(int);

int
get_atomic_a ()
{
   return __atomic_load_n (&a, __ATOMIC_SEQ_CST);
}

void
put_atomic_a(int x)
{
   __atomic_store_n(&a, x,  __ATOMIC_SEQ_CST);
}

void
show_atomic_seq_cst(void)
{
   show_int(__ATOMIC_SEQ_CST);
}

Please notice that AFAIU, the __ATOMIC_SEQ_CST name is not standardized 
in C99 (or C11) -but I could be very wrong-. Also, there is no #include 
in the above code. On my Debian/Linux/x86-64 machine, __ATOMIC_SEQ_CST 
(I don't know how magic it is in GCC; is it a preprocessor symbol or 
some magic enum?) happens to be 5 (I examined the assembler code 
generated by gcc-6 -O1 -fverbose-asm -S on above C code). But can I be 
sure that it would be defined, and defined to the same value, with other 
C compilers.

My feeling (but I might be wrong) is that GCCJIT should give some way to 
retrieve that __ATOMIC_SEQ_CST. Apparently it is a magic preprocessor 
symbol (perhaps GCC specific!) implemented in gcc/cppbuiltin.c (near 
line 68, defined as MEMMODEL_SEQ_CST); but if I understand correctly 
GCCJIT does not give access to the compiler's magic preprocessor symbols.

I feel that GCCJIT might want to have a function like
int gccjit_atomic_seq_cst_value(); // value of __ATOMIC_SEQ_CST in the 
GCC used by GCCJIT
or perhaps a more general function
int gccjit_compiler_magic_int(const char*);
that I would call as gccjit_compiler_magic_int("__ATOMIC_SEQ_CST");

Perhaps I am misunderstanding something obvious (I have a cold right now 
because of allergy, so my thinking is not the best), but I cannot 
understand today how exactly should I build in GCCJIT6 the 
gcc_jit_function-s equivalent to my get_atomic_a & put_atomic_a.... So 
please explain if you can!

Regards.

-- 
Basile STARYNKEVITCHhttp://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: wish: gcc_jit_type_get_atomic

[Basile Starynkevitch]

On 05/20/2016 01:46 PM, Basile Starynkevitch wrote:
>
> My feeling (but I might be wrong) is that GCCJIT should give some way 
> to retrieve that __ATOMIC_SEQ_CST. Apparently it is a magic 
> preprocessor symbol (perhaps GCC specific!) implemented in 
> gcc/cppbuiltin.c (near line 68, defined as MEMMODEL_SEQ_CST); but if I 
> understand correctly GCCJIT does not give access to the compiler's 
> magic preprocessor symbols.
>
> I feel that GCCJIT might want to have a function like
> int gccjit_atomic_seq_cst_value(); // value of __ATOMIC_SEQ_CST in the 
> GCC used by GCCJIT
> or perhaps a more general function
> int gccjit_compiler_magic_int(const char*);
> that I would call as gccjit_compiler_magic_int("__ATOMIC_SEQ_CST");

FWIW, there is a dirty hack to get that. On a Debian system with both 
libgccjit-6-dev & gcc-6-plugin-dev packages installed the 
/usr/lib/gcc/x86_64-linux-gnu/6/plugin/include/coretypes.h header file 
(provided by libgccjit-6-dev) defines an enum memmodel with 
MEMMODEL_SEQ_CST = 5; So I guess that I could use that MEMMODEL_SEQ_CST 
as an argument to gcc_jit_context_new_rvalue_from_int.

But some distributions don't package GCC plugin headers (in particular, 
in the past, some GCC versions on some Redhat systems disabled plugins 
in GCC; I don't know if that is true today). And at least, it is not 
documented that GCCJIT is related to GCC plugins.

Regards.

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: wish: gcc_jit_type_get_atomic

[Marc Nieper-Wißkirchen]

)Am Fr., 20. Mai 2016 um 13:46 Uhr schrieb Basile Starynkevitch
<basile@starynkevitch.net>:
>
> Hello All,
>
> In message https://gcc.gnu.org/ml/jit/2016-q2/msg00013.html David
> Malcolm nicely explained that
>
> > Client code might be able to implement it without explicit libgccjit support
> > by generating calls to the relevant builtins "by hand".
>
>
> But I am not sure to understand exactly how that can be done in (more or
> less portable)
> C code calling libgccjit-6. In particular I am thinking of coding in C
> some code which would use libgccjit-6 but would not be compiled by gcc-6
> (but some other C compiler, perhaps a future gcc-7, or clang, or tinycc,
> etc...)
>
> What I am understanding is that I should construct with GCCJIT an AST
> similar to the following C code:
>
> extern int a;

Is this well-defined by the standard? Or do we have to declare `a' as
an atomic int? (I know that this is currently impossible with
libgccjit, but implementing this is the easier part of the original
wish stated in this thread.)

> extern void show_int(int);
>
> int
> get_atomic_a ()
> {
>    return __atomic_load_n (&a, __ATOMIC_SEQ_CST);
> }
>
> void
> put_atomic_a(int x)
> {
>    __atomic_store_n(&a, x,  __ATOMIC_SEQ_CST);
> }
>
> void
> show_atomic_seq_cst(void)
> {
>    show_int(__ATOMIC_SEQ_CST);
> }
>
> Please notice that AFAIU, the __ATOMIC_SEQ_CST name is not standardized
> in C99 (or C11) -but I could be very wrong-. Also, there is no #include
> in the above code. On my Debian/Linux/x86-64 machine, __ATOMIC_SEQ_CST
> (I don't know how magic it is in GCC; is it a preprocessor symbol or
> some magic enum?) happens to be 5 (I examined the assembler code
> generated by gcc-6 -O1 -fverbose-asm -S on above C code). But can I be
> sure that it would be defined, and defined to the same value, with other
> C compilers.
>
> My feeling (but I might be wrong) is that GCCJIT should give some way to
> retrieve that __ATOMIC_SEQ_CST. Apparently it is a magic preprocessor
> symbol (perhaps GCC specific!) implemented in gcc/cppbuiltin.c (near
> line 68, defined as MEMMODEL_SEQ_CST); but if I understand correctly
> GCCJIT does not give access to the compiler's magic preprocessor symbols.

This is also one of my wishes. As soon as Andrea's patch
(https://gcc.gnu.org/ml/jit/2019-q1/msg00040.html), as a workaround,
one could write a simple C file defining `put_atomic_a' and
`get_atomic_a' and link its object file with LTO to the code generated
by libgccjit.

-- Marc

[...]

> I feel that GCCJIT might want to have a function like
> int gccjit_atomic_seq_cst_value(); // value of __ATOMIC_SEQ_CST in the
> GCC used by GCCJIT
> or perhaps a more general function
> int gccjit_compiler_magic_int(const char*);
> that I would call as gccjit_compiler_magic_int("__ATOMIC_SEQ_CST");
>
> Perhaps I am misunderstanding something obvious (I have a cold right now
> because of allergy, so my thinking is not the best), but I cannot
> understand today how exactly should I build in GCCJIT6 the
> gcc_jit_function-s equivalent to my get_atomic_a & put_atomic_a.... So
> please explain if you can!
>
> Regards.
>
> --
> Basile STARYNKEVITCHhttp://starynkevitch.net/Basile/
> email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mine, sont seulement les miennes} ***
>


-- 
Prof. Dr. Marc Nieper-Wißkirchen

Universität Augsburg
Institut für Mathematik
Universitätsstraße 14
86159 Augsburg

Tel: 0821/598-2146
Fax: 0821/598-2090

E-Mail: marc.nieper-wisskirchen@math.uni-augsburg.de
Web: www.math.uni-augsburg.de/alg/mitarbeiter/mnieper/

Re: wish: gcc_jit_type_get_atomic

[David Malcolm]

On Thu, 2016-05-12 at 07:48 +0200, Basile Starynkevitch wrote:
> Hello all,
> 
> GCC JIT has gcc_jit_type_get_volatile to support the volatile
> qualifier.
> 
> But shouldn't it also have a gcc_jit_type_get_atomic to support the
> C11 
> _Atomic qualifier?
> http://en.cppreference.com/w/c/atomic

I looked at how the C frontend handles this, and sadly it's not trivial
to implement.

The flag in question is in tree.h:
  /* Nonzero in a type considered atomic as a whole.  */
  #define TYPE_ATOMIC(NODE) (TYPE_CHECK (NODE)->base.u.bits.atomic_flag)

c-typeck.c has build_atomic_assign, which handles assignments by
generating calls to various builtins (and various other logic).

So it's not just a matter of having the API set the flag on the type;
we would need to duplicate/refactor a lot of this c-typeck.c logic
also.

(also, looking at C's grokdeclarator, there's various validity checking
there, which would need emulating in libgccjit.c).

Client code might be able to implement it without explicit libgccjit support by generating calls to the relevant builtins "by hand".

Dave

Re: wish: gcc_jit_type_get_atomic

[Basile Starynkevitch]

On 05/12/2016 10:06 PM, David Malcolm wrote:
> On Thu, 2016-05-12 at 07:48 +0200, Basile Starynkevitch wrote:
>> Hello all,
>>
>> GCC JIT has gcc_jit_type_get_volatile to support the volatile
>> qualifier.
>>
>> But shouldn't it also have a gcc_jit_type_get_atomic to support the
>> C11
>> _Atomic qualifier?
>> http://en.cppreference.com/w/c/atomic
[...]
>>
>> Client code might be able to implement it without explicit libgccjit support by generating calls to the relevant builtins "by hand".

Then perhaps at least that should be a relevant example in the 
documentation about how to
actually use GCC builtins in GCCJIT. Notice that 
gcc_jit_context_get_builtin_function is barely document, and it would be 
nice to have, in 
https://gcc.gnu.org/onlinedocs/jit/topics/functions.html notably, a 
small example (which could be some atomic thing).

Cheers.


-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***