From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <jit-return-968-listarch-jit=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 69092 invoked by alias); 27 Mar 2017 16:16:13 -0000
Mailing-List: contact jit-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Post: <mailto:jit@gcc.gnu.org>
List-Help: <mailto:jit-help@gcc.gnu.org>
List-Subscribe: <mailto:jit-subscribe@gcc.gnu.org>
Sender: jit-owner@gcc.gnu.org
Received: (qmail 69080 invoked by uid 89); 27 Mar 2017 16:16:12 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Checked: by ClamAV 0.99.2 on sourceware.org
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=H*MI:mid, H*r:TLS1.2, H*M:mid, H*r:sk:ECDHE_R
X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD autolearn=no version=3.3.2
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org
X-Spam-Level: 
X-HELO: albireo.enyo.de
From: Florian Weimer <fw@deneb.enyo.de>
To: David Malcolm <dmalcolm@redhat.com>
Cc: =?utf-8?B?7KCV7J2467CwKEluYmFl?= "Jeong\)" <kukyakya@gmail.com>,
  jit@gcc.gnu.org
Subject: Re: Alignment not supported?
References: <CAMMwVi1ssF1woTwnCbuq-BQ52_R6kULtvTf-3OtkD_QCdF6=Hg@mail.gmail.com>
	<87fui1pj74.fsf@mid.deneb.enyo.de>
	<CAMMwVi14eZ3sNr6RERkt_gpu0O5uu0Zwn-D_mwR9dRPoOafgvg@mail.gmail.com>
	<1490622483.11099.31.camel@redhat.com>
	<87wpbaojxb.fsf@mid.deneb.enyo.de>
	<1490630429.11099.60.camel@redhat.com>
Date: Sun, 01 Jan 2017 00:00:00 -0000
In-Reply-To: <1490630429.11099.60.camel@redhat.com> (David Malcolm's message
	of "Mon, 27 Mar 2017 12:00:29 -0400")
Message-ID: <87h92eofuf.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SW-Source: 2017-q1/txt/msg00015.txt.bz2

* David Malcolm:

>> I would suggest to model the interface after gcc_jit_context_new_call
>> (but still keep it separate because even though attributes with
>> arguments are syntactically pretty much like function calls in the C
>> front end, semantically, they are not).=20
>
> If I understand you right, this would give something like:
>
> extern gcc_jit_type *
> gcc_jit_type_add_attribute (gcc_jit_type *type
>                             const char *attribute_name,
>                             int numargs, gcc_jit_rvalue **args);

Right.

> Is every attribute arg an rvalue though?  Can some of them be types?

Not sure about that, but the =E2=80=9Cmode=E2=80=9D attribute appears to be=
 special in
this regard.  There could be others.