From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) by sourceware.org (Postfix) with ESMTPS id 9DA6E3858C53 for ; Wed, 13 Apr 2022 11:47:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9DA6E3858C53 Received: by mail-ej1-x62b.google.com with SMTP id ks6so3428723ejb.1 for ; Wed, 13 Apr 2022 04:47:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:references :message-id:mime-version:content-transfer-encoding; bh=MppJN9ID6yG+h6UF6MejtRyQaKIhEtMwjeNS3WBXcxE=; b=UBBbndq8x1AJAUz5tIhmx7VU5pa9K+y+d/RFVouh0wG2o6D/HkSEwEKyRnk0xgQP43 DUcZY6O8cscmBW7DcDvrbwAtaEqZBRvqYfkKEUOSmplkwd14MBOyCyGqhtENS+v4dlJv XZHJyNznSUX/oQiJuak0NUnzx37FJa+KeuxU3i423kvS0YjaVIj1culVCW7R6wGNoDCk /9BE3p7F7d0TeDxFZ/io0JZizn+Jyy46JnzKW00BCJy6yWDEK6QBHTEII+XVQMyLeRVp 3O9IN9rBpaT+xY9P7lXuvrSQqFZxqUdkiblH+Bo6hCW+s+HUZTVfzboihMs0lHso5jyI fyjg== X-Gm-Message-State: AOAM531KAfsPU9VAWUs8csi/mSme97XknJkVle7VRhynXERzAnEjzkC6 naYJvJa8zm0BHXGLtPR2dZg= X-Google-Smtp-Source: ABdhPJy7aznsiqdPjdC6lJxU6BPTZCP0j31F4ZgFCLraJY/7i0RdSdn+uM8Bmz5D2TmSzhx/anqDcA== X-Received: by 2002:a17:907:1b27:b0:6d9:ceb6:7967 with SMTP id mp39-20020a1709071b2700b006d9ceb67967mr39824213ejc.186.1649850469275; Wed, 13 Apr 2022 04:47:49 -0700 (PDT) Received: from ?IPv6:::1? ([2001:871:227:33a8:2d7f:3a24:4b2c:c797]) by smtp.gmail.com with ESMTPSA id l17-20020a056402231100b0041d98ed7ad8sm1092519eda.46.2022.04.13.04.47.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Apr 2022 04:47:48 -0700 (PDT) Date: Wed, 13 Apr 2022 13:47:46 +0200 From: Bernhard Reutner-Fischer To: David Malcolm , Antoni Boucher CC: jit@gcc.gnu.org Subject: =?US-ASCII?Q?Re=3A_=5BPATCH=5D_libgccjit=3A_Add_support_?= =?US-ASCII?Q?for_setting_the_alignment_=5BPR104293=5D?= In-Reply-To: <0daad6110a15a9aab4e924c415405547248cd873.camel@redhat.com> References: <7f32bff12738484e3f5d97cfc481996fd7570b01.camel@zoho.com> <1a077e6549786d9aedb1cf353f176b0207520c6e.camel@redhat.com> <7c11cc644be07afa0753dbabc2fb607c8af48af6.camel@zoho.com> <0daad6110a15a9aab4e924c415405547248cd873.camel@redhat.com> Message-ID: <8BB230BB-AC78-4B79-8B01-44714A53B8DF@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: jit@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Jit mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2022 11:47:53 -0000 On 12 April 2022 23:51:34 CEST, David Malcolm via Gcc-patches wrote: >On Sat, 2022-04-09 at 13:50 -0400, Antoni Boucher wrote: >> Here's the updated patch=2E >>=20 >I've pushed the patch to trunk for GCC 12 as r12-8120-g6e5ad1cc24a315=2E > >https://gcc=2Egnu=2Eorg/git/?p=3Dgcc=2Egit;a=3Dcommitdiff;h=3D6e5ad1cc24a= 315d07f24c95d76c269cafe2a8182 >> > > +=C2=A0=C2=A0 in C, but in bits instead of bytes=2E >> >=20 >> > If we're doing it in bytes, this will need updating, of course=2E >> >=20 >> > Maybe rename the int param from "alignment" to "bytes" to make this >> > clearer=2E >> >=20 >> > Probably should be unsigned as well=2E >> > > +void >> > > +gcc_jit_lvalue_set_alignment (gcc_jit_lvalue *lvalue, >> > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 int alignment) >> > > +{ >> > > +=C2=A0 RETURN_IF_FAIL (lvalue, NULL, NULL, "NULL lvalue"); >> >=20 >> > Should the alignment be unsigned?=C2=A0 What if the user passes in >> > negative? >> >=20 >> > Does it have to be a power of two?=C2=A0 If so, ideally we should rej= ect >> > non-power-of-two here=2E The wrapper was changed to unsigned bytes=2E set_alignment still takes int bytes AFAICS? Now I think there are or may be machine dependent max alignment, aren't th= ere? If there are, they are enforced later in the pipeline I assume? thanks,