* wish: gcc_jit_type_get_atomic
@ 2016-01-01 0:00 Basile Starynkevitch
2016-01-01 0:00 ` Basile Starynkevitch
2016-01-01 0:00 ` David Malcolm
0 siblings, 2 replies; 6+ messages in thread
From: Basile Starynkevitch @ 2016-01-01 0:00 UTC (permalink / raw)
To: jit
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} ***
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: wish: gcc_jit_type_get_atomic
2016-01-01 0:00 wish: gcc_jit_type_get_atomic Basile Starynkevitch
2016-01-01 0:00 ` Basile Starynkevitch
@ 2016-01-01 0:00 ` David Malcolm
2016-01-01 0:00 ` Basile Starynkevitch
1 sibling, 1 reply; 6+ messages in thread
From: David Malcolm @ 2016-01-01 0:00 UTC (permalink / raw)
To: Basile Starynkevitch, jit
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: wish: gcc_jit_type_get_atomic
2016-01-01 0:00 wish: gcc_jit_type_get_atomic Basile Starynkevitch
@ 2016-01-01 0:00 ` Basile Starynkevitch
2016-01-01 0:00 ` Basile Starynkevitch
2019-01-01 0:00 ` Marc Nieper-Wißkirchen
2016-01-01 0:00 ` David Malcolm
1 sibling, 2 replies; 6+ messages in thread
From: Basile Starynkevitch @ 2016-01-01 0:00 UTC (permalink / raw)
To: jit, David Malcolm
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} ***
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: wish: gcc_jit_type_get_atomic
2016-01-01 0:00 ` Basile Starynkevitch
@ 2016-01-01 0:00 ` Basile Starynkevitch
2019-01-01 0:00 ` Marc Nieper-Wißkirchen
1 sibling, 0 replies; 6+ messages in thread
From: Basile Starynkevitch @ 2016-01-01 0:00 UTC (permalink / raw)
To: jit, David Malcolm
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} ***
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: wish: gcc_jit_type_get_atomic
2016-01-01 0:00 ` David Malcolm
@ 2016-01-01 0:00 ` Basile Starynkevitch
0 siblings, 0 replies; 6+ messages in thread
From: Basile Starynkevitch @ 2016-01-01 0:00 UTC (permalink / raw)
To: David Malcolm, jit
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} ***
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: wish: gcc_jit_type_get_atomic
2016-01-01 0:00 ` Basile Starynkevitch
2016-01-01 0:00 ` Basile Starynkevitch
@ 2019-01-01 0:00 ` Marc Nieper-Wißkirchen
1 sibling, 0 replies; 6+ messages in thread
From: Marc Nieper-Wißkirchen @ 2019-01-01 0:00 UTC (permalink / raw)
To: Basile Starynkevitch; +Cc: jit, David Malcolm
)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/
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-01-16 10:55 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-01 0:00 wish: gcc_jit_type_get_atomic Basile Starynkevitch
2016-01-01 0:00 ` Basile Starynkevitch
2016-01-01 0:00 ` Basile Starynkevitch
2019-01-01 0:00 ` Marc Nieper-Wißkirchen
2016-01-01 0:00 ` David Malcolm
2016-01-01 0:00 ` Basile Starynkevitch
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).