From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <jit-return-970-listarch-jit=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 103277 invoked by alias); 27 Mar 2017 17:22:34 -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 103258 invoked by uid 89); 27 Mar 2017 17:22:33 -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=Hence, H*MI:mid, H*r:TLS1.2, 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>
	<1490632719.11099.66.camel@redhat.com>
Date: Sun, 01 Jan 2017 00:00:00 -0000
In-Reply-To: <1490632719.11099.66.camel@redhat.com> (David Malcolm's message
	of "Mon, 27 Mar 2017 12:38:39 -0400")
Message-ID: <87vaqumy7f.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/msg00017.txt.bz2

* David Malcolm:

> Hence all of this pre-existing logic for setting the alignment of a
> type is implemented with the c-family front-end code, which isn't
> available from libgccjit.

Ah, I assumed it was a c-family target.

> Alternatively, it might make more sense to go with this earlier API
> idea:
>
> extern gcc_jit_type *
> gcc_jit_type_set_alignment (gcc_jit_type *type,
>                             int alignment);
>
> or similar ("make_aligned" ?  "add_alignment" ?)
>
> I think I prefer the latter approach, as it makes it explicit in client
> code linkage metadata what functionality it's using,

It's also more type-safe and self-documenting.  Although =E2=80=9Cint=E2=80=
=9D
probably isn't exactly the right type here.