From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 77300 invoked by alias); 12 May 2016 20:07:03 -0000 Mailing-List: contact jit-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Subscribe: Sender: jit-owner@gcc.gnu.org Received: (qmail 77285 invoked by uid 89); 12 May 2016 20:07:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.1 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Starynkevitch, Hx-languages-length:1115, wish X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mx1.redhat.com Message-ID: <1463083609.11310.81.camel@redhat.com> Subject: Re: wish: gcc_jit_type_get_atomic From: David Malcolm To: Basile Starynkevitch , jit@gcc.gnu.org Date: Fri, 01 Jan 2016 00:00:00 -0000 In-Reply-To: <5734193A.2040903@starynkevitch.net> References: <5734193A.2040903@starynkevitch.net> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Thu, 12 May 2016 20:06:51 +0000 (UTC) X-SW-Source: 2016-q2/txt/msg00013.txt.bz2 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