From nobody Tue Mar 07 11:12:34 2023 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PWCTp6h19z3xG5b for ; Tue, 7 Mar 2023 11:12:46 +0000 (UTC) (envelope-from developer@lorenzosalvadore.it) Received: from mail-4317.proton.ch (mail-4317.proton.ch [185.70.43.17]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PWCTp3lW1z3jLT for ; Tue, 7 Mar 2023 11:12:46 +0000 (UTC) (envelope-from developer@lorenzosalvadore.it) Authentication-Results: mx1.freebsd.org; none Date: Tue, 07 Mar 2023 11:12:34 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lorenzosalvadore.it; s=protonmail2; t=1678187562; x=1678446762; bh=z7hjGsV4i/20AewWT6sI4F8ukHm6ypANmD7EJEPAwW8=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=GRxZWny4bTHzyl3KUZuv4hzSqZoDYA55QyaFmFfw2ZX5zJgEibL5U0PVQHunLoDjp AK0NWYN7G3L9aa1klikrEEVCHIkXDFU3vu7Swy4JhEZB/L0BkPV5bUuxXC8qPMTeOE fQuNYgEecGAV2ycvIYwf+NUp7JBwZh2iDJTWwJPohyCW3Qpd67LrCY/btXideyFjVT 1MXlbWWAMAuXSdlk7IEYMaJDnawHKmuXR3CsozoSI+REWbGugHVRxT1FC0JNuJjTut 4P9s6T8mMkaiAb+Tjt/wDbhXHks8YX62CQSTnQzvT6gw4TkQlCGxG/VUwtlTQIR4dC zBi8OfZ831rEw== To: Mark Millard From: Lorenzo Salvadore Cc: Brooks Davis , "salvadore@freebsd.org" , FreeBSD Mailing List Subject: Re: armv7 lang/gcc12 "no bootstrap" build via system clang 15.0.7 based poudriere build ends up stuck in a small loop Message-ID: In-Reply-To: References: <2HOLCFE6Z_cOyGycU4ZBU7Lf6kcqohVx7tiLiRLzdjMEc6a8DFeH1IaJqdPNJOqFVTh1MGE7_UUJLcg2gg0UbTZIHZl72NbaNEsqrJwJ3xA=@lorenzosalvadore.it> <93707ED2-F529-49DE-A018-794827F56247@yahoo.com> <7AA0AE73-87CC-4B26-92B2-A0EC4281F429@yahoo.com> <480C8278-DC30-40D6-AED2-F52F59E78EBC@yahoo.com> Feedback-ID: 53711648:user:proton List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4PWCTp3lW1z3jLT X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:62371, ipnet:185.70.43.0/24, country:CH] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N ------- Original Message ------- On Tuesday, March 7th, 2023 at 11:26 AM, Mark Millard w= rote: >=20 >=20 > Below is a small example C source showing the clang 15+ armv7 > problem that leads to the unbounded looping in later code in > the lang/gcc12+ builds: a data structure is mis-initialized, > breaking its invariant properties used by the later code > structure. >=20 > # more partition.c > // Minor varation of part of some gcc source code! >=20 > // For system-clang 15: cc -g -O2 partition.c ; ./a.out > // For devel/llvm16: clang16 -g -O2 partition.c ; ./a.out >=20 > #include >=20 >=20 > #define NUM_ELEMENTS 32 >=20 > struct partition_elem > { > struct partition_elem* next; > int class_element; > unsigned class_count; > }; >=20 > typedef struct partition_def > { > int num_elements; > struct partition_elem elements[NUM_ELEMENTS]; > } *partition; >=20 > struct partition_def partition_storage; >=20 > partition > partition_new (int num_elements) > { > int e; >=20 > if (NUM_ELEMENTS < num_elements) num_elements =3D NUM_ELEMENTS; >=20 > partition part=3D &partition_storage; > part->num_elements =3D num_elements; >=20 > for (e =3D 0; e < num_elements; ++e) > { > part->elements[e].class_element =3D e; >=20 > part->elements[e].next =3D &(part->elements[e]); >=20 > part->elements[e].class_count =3D 1; >=20 > } >=20 > for (e =3D 0; e < num_elements; ++e) > printf("%d: %p : next?: %p\n",e,(void*)&part->elements[e],(void*)part->el= ements[e].next); >=20 >=20 > return part; > } >=20 > int main(void) > { > partition part; > part=3D partition_new(NUM_ELEMENTS); >=20 > return !part; > } >=20 > In the output below, note the blocks of 4 "next" > values that do not change. Each should match the > earlier hexadecimal value on the same line: point > back to same element of the array. 3 of 4 do not. >=20 > # cc -g -O2 partition.c > # ./a.out > 0: 0x40a84 : next?: 0x40a84 > 1: 0x40a90 : next?: 0x40a84 > 2: 0x40a9c : next?: 0x40a84 > 3: 0x40aa8 : next?: 0x40a84 > 4: 0x40ab4 : next?: 0x40ab4 > 5: 0x40ac0 : next?: 0x40ab4 > 6: 0x40acc : next?: 0x40ab4 > 7: 0x40ad8 : next?: 0x40ab4 > 8: 0x40ae4 : next?: 0x40ae4 > 9: 0x40af0 : next?: 0x40ae4 > 10: 0x40afc : next?: 0x40ae4 > 11: 0x40b08 : next?: 0x40ae4 > 12: 0x40b14 : next?: 0x40b14 > 13: 0x40b20 : next?: 0x40b14 > 14: 0x40b2c : next?: 0x40b14 > 15: 0x40b38 : next?: 0x40b14 > 16: 0x40b44 : next?: 0x40b44 > 17: 0x40b50 : next?: 0x40b44 > 18: 0x40b5c : next?: 0x40b44 > 19: 0x40b68 : next?: 0x40b44 > 20: 0x40b74 : next?: 0x40b74 > 21: 0x40b80 : next?: 0x40b74 > 22: 0x40b8c : next?: 0x40b74 > 23: 0x40b98 : next?: 0x40b74 > 24: 0x40ba4 : next?: 0x40ba4 > 25: 0x40bb0 : next?: 0x40ba4 > 26: 0x40bbc : next?: 0x40ba4 > 27: 0x40bc8 : next?: 0x40ba4 > 28: 0x40bd4 : next?: 0x40bd4 > 29: 0x40be0 : next?: 0x40bd4 > 30: 0x40bec : next?: 0x40bd4 > 31: 0x40bf8 : next?: 0x40bd4 >=20 > Turns out that the -O2 is important: no other that I > tried got the problem, including -O3 not getting the > problem. lang/gcc12+ builds happen to use -O2 , at > least in my environment. >=20 > -g is not required for the problem. This last point about optimization is interesting. It is just a guess, but maybe when you enable bootstrap in lang/gcc12 you build the first compiler without optimization, while if you disable it you do use -O2. I have taken your example C code and tested it in FreeBSD amd64 and in a virtual machine running Linux (OpenSuse) amd64: I have got the same failure in both cases. I used clang15. So the bug does not depend on the OS nor on the architecture. However, my results have a difference from yours: in my case tests fail with any level of optimization. At this point, I would say that the issue is in clang. I think you should file a bug upstream. Thanks, Lorenzo Salvadore