From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sender4-pp-o90.zoho.com (sender4-pp-o90.zoho.com [136.143.188.90]) by sourceware.org (Postfix) with ESMTPS id 562A3385843E for ; Sun, 17 Apr 2022 02:29:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 562A3385843E ARC-Seal: i=1; a=rsa-sha256; t=1650162538; cv=none; d=zohomail.com; s=zohoarc; b=cnwPijsty4JZbXdRNqHHDaUX5VuZ5R6B0ROQwivjh/WvFn7pK9Y2tcRaWfjtjUw2OjpC3ZJShSaPTmXrSrwbJFeOD3KBdWojAmNChqGeBvprNBIarDF5YKAAi388YGgJgSYx2aFLUVRvoOKbV3dbt9BfJ9vhO+d/C2X3Nsvm+is= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1650162538; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=1nkNgXX5bSMAEQH7CqgdX4E7y7cvTecL6el8b2aZc+c=; b=CCvht6i1XfXrVf3+KaI54fW5NhSTYIkcttgjnxex1OaPR2QiJlLD1m5mX68Zq5BrnIVpj3pHHyJGCOBD+V4ymq91Xe/cb/ATF+57HxG9u281ZEL3nPNXNIlGotP4SzGXp9EW9JkS+yMIEzzlbuZtSMhCGcRwaP0otNqNsDEEkAc= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=zoho.com; spf=pass smtp.mailfrom=bouanto@zoho.com; dmarc=pass header.from= Received: from [192.168.1.174] (38.87.11.6 [38.87.11.6]) by mx.zohomail.com with SMTPS id 1650162536334410.5036622215215; Sat, 16 Apr 2022 19:28:56 -0700 (PDT) Message-ID: Subject: Re: [PATCH] libgccjit: Add support for setting the alignment [PR104293] From: Antoni Boucher To: Marc =?ISO-8859-1?Q?Nieper-Wi=DFkirchen?= , David Malcolm , Petter Tomner Cc: Marc =?ISO-8859-1?Q?Nieper-Wi=DFkirchen?= via Jit Date: Sat, 16 Apr 2022 22:28:54 -0400 In-Reply-To: References: <7f32bff12738484e3f5d97cfc481996fd7570b01.camel@zoho.com> <1a077e6549786d9aedb1cf353f176b0207520c6e.camel@redhat.com> <7c11cc644be07afa0753dbabc2fb607c8af48af6.camel@zoho.com> <0daad6110a15a9aab4e924c415405547248cd873.camel@redhat.com> <8BB230BB-AC78-4B79-8B01-44714A53B8DF@gmail.com> Content-Type: multipart/mixed; boundary="=-pL517DMO39TZpJqb3+ni" User-Agent: Evolution 3.44.0 MIME-Version: 1.0 X-Zoho-Virus-Status: 1 X-ZohoMailClient: External X-Spam-Status: No, score=-10.7 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, 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: Sun, 17 Apr 2022 02:29:12 -0000 --=-pL517DMO39TZpJqb3+ni Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It seems there are some errors in the struct constructor code. The attached patch seems to fix the issue. The code from this bug report doesn't use the new API for alignment (gcc_jit_lvalue_set_alignment); it uses the former one (gcc_jit_type_get_aligned). Perhaps it would be worth testing with the new API. On Sat, 2022-04-16 at 22:26 +0200, Marc Nieper-Wi=C3=9Fkirchen wrote: > I haven't checked the cause of the bug reported here [1]. It may > either be in the struct constructor code or in the new code for > alignments, so this email goes to both Antoni and Petter. Speaking of > struct constructors, I have found another bug [2] >=20 > Thanks, >=20 > Marc >=20 > -- >=20 > [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D105296 > [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D105286 >=20 > Am Mi., 13. Apr. 2022 um 13:47 Uhr schrieb Bernhard Reutner-Fischer > via Jit : > >=20 > > 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. > > > >=20 > >=20 > > > I've pushed the patch to trunk for GCC 12 as r12-8120- > > > g6e5ad1cc24a315. > > >=20 > > > https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dcommitdiff;h=3D6e5ad1cc24a31= 5d07f24c95d76c269cafe2a8182 > >=20 > >=20 > > > > > > +=C2=A0=C2=A0 in C, but in bits instead of bytes. > > > > >=20 > > > > > If we're doing it in bytes, this will need updating, of > > > > > course. > > > > >=20 > > > > > Maybe rename the int param from "alignment" to "bytes" to > > > > > make this > > > > > clearer. > > > > >=20 > > > > > Probably should be unsigned as well. > >=20 > > > > > > +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 i= n > > > > > negative? > > > > >=20 > > > > > Does it have to be a power of two?=C2=A0 If so, ideally we should > > > > > reject > > > > > non-power-of-two here. > >=20 > > The wrapper was changed to unsigned bytes. > > set_alignment still takes int bytes AFAICS? > >=20 > > Now I think there are or may be machine dependent max alignment, > > aren't there? If there are, they are enforced later in the pipeline > > I assume? > >=20 > > thanks, --=-pL517DMO39TZpJqb3+ni Content-Disposition: attachment; filename="0001-Fix-usage-of-aligned-type-in-struct-constructor.patch" Content-Type: text/x-patch; name="0001-Fix-usage-of-aligned-type-in-struct-constructor.patch"; charset="UTF-8" Content-Transfer-Encoding: base64 RnJvbSAwYmJhYjUzNzZjYjg4NTY0YjMzYTZiYmRlYWYzMTg3ZjgwMmMyNGM4IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBBbnRvbmkgQm91Y2hlciA8Ym91YW50b0B6b2hvLmNvbT4KRGF0 ZTogU2F0LCAxNiBBcHIgMjAyMiAyMjoyNTo0MSAtMDQwMApTdWJqZWN0OiBbUEFUQ0hdIEZpeCB1 c2FnZSBvZiBhbGlnbmVkIHR5cGUgaW4gc3RydWN0IGNvbnN0cnVjdG9yCgotLS0KIGdjYy9qaXQv bGliZ2Njaml0LmNjIHwgMTAgKysrKystLS0tLQogMSBmaWxlIGNoYW5nZWQsIDUgaW5zZXJ0aW9u cygrKSwgNSBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9nY2Mvaml0L2xpYmdjY2ppdC5jYyBi L2djYy9qaXQvbGliZ2Njaml0LmNjCmluZGV4IGNlNTRjYzgyYTdhLi5hNDE3ZTQwZDcyOCAxMDA2 NDQKLS0tIGEvZ2NjL2ppdC9saWJnY2NqaXQuY2MKKysrIGIvZ2NjL2ppdC9saWJnY2NqaXQuY2MK QEAgLTE0MTQsMTYgKzE0MTQsMTYgQEAgZ2NjX2ppdF9jb250ZXh0X25ld19zdHJ1Y3RfY29uc3Ry dWN0b3IgKGdjY19qaXRfY29udGV4dCAqY3R4dCwKICAgSklUX0xPR19GVU5DIChjdHh0LT5nZXRf bG9nZ2VyICgpKTsKICAgUkVUVVJOX05VTExfSUZfRkFJTCAodHlwZSwgY3R4dCwgbG9jLCAiTlVM TCB0eXBlIik7CiAKLSAgUkVUVVJOX05VTExfSUZfRkFJTF9QUklOVEYxICh0eXBlLT5pc19zdHJ1 Y3QgKCksCisgIHN0cnVjdF8qIHN0cnVjdF90eXBlID0gdHlwZS0+aXNfc3RydWN0ICgpOworICBS RVRVUk5fTlVMTF9JRl9GQUlMX1BSSU5URjEgKHN0cnVjdF90eXBlLAogCQkJICAgICAgIGN0eHQs IGxvYywKIAkJCSAgICAgICAiY29uc3RydWN0b3IgdHlwZSBpcyBub3QgYSBzdHJ1Y3Q6ICVzIiwK IAkJCSAgICAgICB0eXBlLT5nZXRfZGVidWdfc3RyaW5nICgpKTsKIAotICBjb21wb3VuZF90eXBl ICpjdCA9IHJlaW50ZXJwcmV0X2Nhc3Q8Y29tcG91bmRfdHlwZSAqPih0eXBlKTsKLSAgZ2NjOjpq aXQ6OnJlY29yZGluZzo6ZmllbGRzICpmaWVsZHNfc3RydWN0ID0gY3QtPmdldF9maWVsZHMgKCk7 CisgIGdjYzo6aml0OjpyZWNvcmRpbmc6OmZpZWxkcyAqZmllbGRzX3N0cnVjdCA9IHN0cnVjdF90 eXBlLT5nZXRfZmllbGRzICgpOwogICBzaXplX3Qgbl9maWVsZHMgPSBmaWVsZHNfc3RydWN0LT5s ZW5ndGggKCk7CiAKLSAgUkVUVVJOX05VTExfSUZfRkFJTF9QUklOVEYxIChjdC0+aGFzX2tub3du X3NpemUgKCksCisgIFJFVFVSTl9OVUxMX0lGX0ZBSUxfUFJJTlRGMSAoc3RydWN0X3R5cGUtPmhh c19rbm93bl9zaXplICgpLAogCQkJICAgICAgIGN0eHQsIGxvYywKIAkJCSAgICAgICAic3RydWN0 IGNhbid0IGJlIG9wYXF1ZTogJXMiLAogCQkJICAgICAgIHR5cGUtPmdldF9kZWJ1Z19zdHJpbmcg KCkpOwpAQCAtMTQ3Miw3ICsxNDcyLDcgQEAgZ2NjX2ppdF9jb250ZXh0X25ld19zdHJ1Y3RfY29u c3RydWN0b3IgKGdjY19qaXRfY29udGV4dCAqY3R4dCwKIAogCSAgUkVUVVJOX05VTExfSUZfRkFJ TF9QUklOVEYzICgKIAkgICAgZi0+Z2V0X2NvbnRhaW5lciAoKSA9PQotCSAgICBzdGF0aWNfY2Fz dDxnY2M6OmppdDo6cmVjb3JkaW5nOjp0eXBlKj4odHlwZSksCisJICAgIHN0YXRpY19jYXN0PGdj Yzo6aml0OjpyZWNvcmRpbmc6OnR5cGUqPihzdHJ1Y3RfdHlwZSksCiAJICAgIGN0eHQsIGxvYywK IAkgICAgImZpZWxkIG9iamVjdCBhdCBpbmRleCAlenUgKCVzKSwgd2FzIG5vdCB1c2VkIHdoZW4g Y3JlYXRpbmcgIgogCSAgICAidGhlICVzIiwKLS0gCjIuMjYuMi43LmcxOWRiOWNmYjY4LmRpcnR5 Cgo= --=-pL517DMO39TZpJqb3+ni--