On Tue, Jun 7, 2016 at 12:22 PM, Andrew Pinski <pins...@gmail.com> wrote: > On Tue, Jun 7, 2016 at 12:19 PM, Andrew Pinski <pins...@gmail.com> wrote: >> On Mon, May 23, 2016 at 5:26 AM, Basile Starynkevitch >> <bas...@starynkevitch.net> wrote: >>> Hello All, >>> >>> As I explained in https://gcc.gnu.org/ml/jit/2016-q2/msg00042.html it is >>> difficult (or tricky without using dirty tricks involving the GCC plugin >>> headers) to use GCCJIT to emit code equivalent to the following C file: >>> >>> extern int a; >>> int get_atomic_a (void) { >>> return __atomic_load_n (&a, __ATOMIC_SEQ_CST); >>> } >>> >>> The issue is that __ATOMIC_SEQ_CST is a magic preprocessor (but >>> non-standard!) symbol which might not be available >>> (or might have a different value) in the C code for GCCJIT building such an >>> AST. >> >>> >>> So we need a function to retrieve some magic integral value from the GCCJIT >>> compiler. >> >> Huh? Why can't you just use the enum: >> enum memmodel >> { >> MEMMODEL_RELAXED = 0, >> MEMMODEL_CONSUME = 1, >> MEMMODEL_ACQUIRE = 2, >> MEMMODEL_RELEASE = 3, >> MEMMODEL_ACQ_REL = 4, >> MEMMODEL_SEQ_CST = 5, >> MEMMODEL_LAST = 6, >> MEMMODEL_SYNC_ACQUIRE = MEMMODEL_ACQUIRE | MEMMODEL_SYNC, >> MEMMODEL_SYNC_RELEASE = MEMMODEL_RELEASE | MEMMODEL_SYNC, >> MEMMODEL_SYNC_SEQ_CST = MEMMODEL_SEQ_CST | MEMMODEL_SYNC >> }; >> >> >> For the values? I don't understand why you need to have a direct >> relationship to preprocessed macros to these values here. >> Have your own lookup table inside your own JIT rather than a generic >> way of doing it. >> Having a generic way seems more incorrect way of doing it and even >> says that the JIT is supposed to JITting C code but it is not JITing C >> code. > > > That is move enum memmodel to be included in the JIT API too.
Or rather have an API which the __atomic_* for you and all you need to supply is the the "JIT" memory model and the locations. Thanks, Andrew > >> >> Thanks, >> Andrew Pinski >> >>> >>> The attached patch (relative to trunk svn 236583) is a first attempt to >>> solve that issue >>> (and also give ability to query some other magic numbers). >>> >>> Proposed ChangeLog entry (in gcc/jit/) >>> >>> 2016-05-23 Basile Starynkevitch <bas...@starynkevitch.net> >>> * libgccjit.h (LIBGCCJIT_HAVE_gcc_jit_magic_int): New macro. >>> (gcc_jit_magic_int): New public function declaration. >>> >>> * libgccjit.c: Include "cppbuiltin.h", "options.h", "flag-types.h" >>> (gcc_jit_magic_int): New function. >>> >>> * libgccjit.map: Add gcc_jit_magic_int to LIBGCCJIT_ABI_6. >>> >>> Comments (or an ok to commit) are welcome. (I am not sure that >>> __SANITIZE_ADDRESS__ is correctly handled, >>> because I would believe that optimization flags are not globals in GCCJIT) >>> >>> 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} *** >>>
