From nobody Tue Mar 07 11:43:53 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 4PWDB51PT3z3xHjL for ; Tue, 7 Mar 2023 11:44:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-54.consmr.mail.gq1.yahoo.com (sonic315-54.consmr.mail.gq1.yahoo.com [98.137.65.30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PWDB4644Nz3lNc for ; Tue, 7 Mar 2023 11:44:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1678189450; bh=q7AFC9QjN/fIbW1+WII33jLUYJuz76UDWH+bfF5nUKs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ET57OohqrT0UEdNejQC2Vea4kNKeX7wWqx2SWiHs/nXZE8GM+XdErOtlgdXe248D0IRlXEa0FRJrhoNyz10Dl3CMTXPh/U75im6ADV1luy4CxLG078XpyPiMP0+kykMtLlaRPPK3A6KWRhx22rKk7XziDS2kx+RgFskqFmWSKyPQqJcgMKMMPClgEQfvTA+94lEHcTXspJlA7ZkgWOOJ7bHB1QyANgOO3INuhXucZSi/QdRhX+BbcsosHSUL7w+mJuOSKTQSxdl7plIXnHza5Hbb8YKhP6suzlRMj0lNU9GrOzCzIaMNwRRZW12C6KgYmlfOhxenedkjr7/Tyx8LvA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1678189450; bh=6mBV8wxrTfT3DO/K0MbklQviRrBvf0AXIRlDlbaCIjj=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=nHrLEzgibONRDZ+zYXR4DPYtYLJWToqgzXUb7pqBn2mpnryMQQekS681uUMyHZLvHvd/bMhxXlGA10AY+I7UxG3OVPPqaT32Lz4F/xFP9l5HWN8/ATuPsmnx2qy3uYKqg0gYbgmu4R4AHJDe+fflRQ/KazVaJsOTMMHiltEgkuTeQNDYXt9wWQu9qyOD2k1VJazD64IKQVmTPPdryxmY07Nho51Ah/75MrSzmsho+MjUDKtaBMtePhoe4Y9WQSRT29zs78qJQoh9W9yDa+fUfCoK7Zor0wOwiDAG3D26T3C8Y8hiAk77wGcG6oHpW32aFGysIuo6gRfU/nF27m+/wg== X-YMail-OSG: qrYK_nAVM1n9_4h_tCbdBQFpSrJrkhWvYrup67EmXKVpMoQAQw7k8cFOfnEw9NA xSNX74ONz.l.uTiJgs40OspM5H3VoA2X86Yx1i5wFTvArrrMvED_S.gpMMxoxmkRBCyAplIEA0Yl n7w.xnQ9yyslMfXI6RleY1UUqWNld0P7qnLKDWGlZBMj0fIggpIo1kVGEf6O95rOejYQ1nj.q4Zp lauJSz7t4mpxM3x9dmSRPHu4ivUm4UyfNKkO6HVEhnFvz72G4EqFawhogSaYR4nGtdTMNm1mC98q 8WV34SGvLTs2VKtQEsZjaq3ijXJz4Is_N7sMUOgRCo7lGJPBm1c3fDAP3MmQhU77VWCdI.RinUVd LNwX2i9d.2tkD8cPHPliUzqjj9iTORAN45qFIC4XRS5_8KiJdejSWXXIuZjSTzlL38Ub0LIyBzDl cUyEcA_c52gczxdz0Wo0AlWjlpcEjSkTizZzkCl5xQ71YzrYpMYRFNi3AxhTam3tEtJItdcfRN.a Ok_7SOkj011uBBjbMwy0Dv2GHBcUALi.8ZO7.6M2HysyCfbILOmQragzjh8SYWVD7dB0OB3qiz83 g4BQbyRJ29KFY2BLsIWlbbTeyABP9V5fA0tDf52_5gPiZyJLRovgJ6IZYOV_PvMmzHho9km2nFVC dsTI8GBMWgyZ6X11X0oBKP5HMmxSolCix2FpdDJdUmcpiVJMq0GVSWLTrHq9oMVJ8Ou6xRznFkdu FWA5sEPSFw.VP0vjPV2MP3WFFUUUpmBbKcTGaJTIjAQdaaZtTBztFMLbCm3kP2HvpaKNTx6p64bq ZuvPdhNaqZA3CXhzJBavBGgcwFpOsfDL9G6_v4lXHg_c0OJqTzYZOAADkKT5DFTJ0LnrdauppOa3 43M73S.MVfzNW2msjHlTp7nszIEgYixKMuv8fqLjqT0vZnYJjLnvaBBMzr82dYRVuwtjSjVnS5kw vH59jJc5EjHj6l2ghGewGpuxIBx_uBk4RLpzE3k4FRu2DeWgDEbjTUCK3yQAp.SMu2oP5BKEaeot mBkGOdaldir9dmGCO2rkR9MbMZtTY9diHJN0.WZjxn1aPpP.DZGWpvt8GulB.zDSGjTr.s.y8hLZ d5WzoojR9k8JB14SVWCceC_VJkgY2aR1mEUcXYJFlktZqvZBsJZcjq3tLLwfAYxylbm3YAfitDwA .ahAF0gVeea77VuyWDG64f2NW7YSdR7i_BAr7TOTUvsrhlm2I_xrGUIlrzdMHPWCh4Ty_8kz8JEl U4ku.WvySKsa6n5mUEc6hUpUQZ5L_YS6y8ra0Zk1g_28iZD8VwMHs23CtX7jnHzucXF8mPdKz7Gi k48kbLW8yIHoYcy310QAhsk_kRid9PjjLzycuXJDI8kFRA3MG0AbV_k6v9CIr55K5QhgKGh..CDb E28fYVkGBRooDKyD06ZlOXISfnb4BQyI7sNfusQbjvsYcxQOQCBP90DgSc1sMLth6.OeH4Hrt5gB .oiR8RteWRJ8HKDV.LhKWqSKqN3PdenU9uq_DoUWwRfUYlZB7N7rMc6Pox4nOC_RJkulwjN2QDAb 9pwwnUhfaB9zPnRItYKppdG5lD6x294iwyqhuMHa64QJh3ZLTl5scCQugFZb5QUzQrhzkaThVSbd Ixpo5I32i2TFPJOE2joDx8jGoP5KPyVb_Bbfs2ioq4IyLWb5ImkXL3NPnpHrjWmttUn0tsIK5gDe pcxlIwiTf0o16KF75tlGEln5viy6HeYRmJi2PvtyPtnU2lshcQFHHLm50efzNfDI2dq5dNCrp9Ji PDW.imO1rU0CQIHxC7X.5Fa5cNREghawhypJTIccaMdQ3sjxjD7QDJiGicgCqTO2xqqlT.HDZjXX BRcAPV5GKGupH6QE44dy3b7hv8svpfqg8aF83M8aAQJuC_8RU3QTKmHDFGUMoEvpRb4p0IE_L975 4FqjzRgWn8Ny7hihsgrGkftkeOysobcgCWyTUvlD3nhgY0hKWuhmfWEEsk78cUBXe0EJYoapC8k4 pQ5IEiJuC82j6UkIGBOC0694OmjWLGZKM9q7OXM6G7N_t17Pm.RGSZKR_GVVNI7.MmGzouC2X3bQ DLsAfQqjFuFU_w5OqHmztQHDqUiX7gAhyoq3F4W1V8huVcDbdNAhcVhnVRHIBvi8Miy0pESlYW45 9BnDaIRpjAmOc4VsXrxdfzGn7Cj8WeCu9JwZG2qG6mbQB_OBbbS4wHKXcOHiUe4caZxbnNRqshJn F4XC5CbeyC1yC.RfIb8queP1zjtLjE6YbJFXxUMh85X7gsTFrm8WEGWCu0mzgAYlHBBXaO41q2R7 CMp8- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Tue, 7 Mar 2023 11:44:10 +0000 Received: by hermes--production-bf1-777648578f-gg2qh (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 92d9277e883aff853db9c10e0c839ac5; Tue, 07 Mar 2023 11:44:06 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: armv7 lang/gcc12 "no bootstrap" build via system clang 15.0.7 based poudriere build ends up stuck in a small loop From: Mark Millard In-Reply-To: Date: Tue, 7 Mar 2023 03:43:53 -0800 Cc: Brooks Davis , "salvadore@freebsd.org" , FreeBSD Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <5F427A6E-D168-477B-B4DB-1A7346EF615E@yahoo.com> 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> To: Lorenzo Salvadore X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4PWDB4644Nz3lNc X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Mar 7, 2023, at 03:12, Lorenzo Salvadore = wrote: >=20 > ------- Original Message ------- > On Tuesday, March 7th, 2023 at 11:26 AM, Mark Millard = wrote: >=20 >=20 >>=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->elements[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. >=20 > 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. The bootstrap sequence does not build a full, general-purpose C compiler via clang (or whatever), just something simpler that is enough to build the next stage. So more than the just the optimization level likely contributes to why bootstrap builds still work. > 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. Thanks for the Linux tests. While I'm not well set up for building gcc (much less in unusual ways), I do have enough context/knowledge to test my simple test on aarch64 Fedora. You saved me the effort. Although, may be I should check independently, given the below. But on FreeBSD but not for armv7: aarch64 FreeBSD system-clang 15 worked fine: cc -g -O2 partition.c ; ./a.out 0: 0x230d00 : next?: 0x230d00 1: 0x230d10 : next?: 0x230d10 2: 0x230d20 : next?: 0x230d20 3: 0x230d30 : next?: 0x230d30 4: 0x230d40 : next?: 0x230d40 5: 0x230d50 : next?: 0x230d50 6: 0x230d60 : next?: 0x230d60 7: 0x230d70 : next?: 0x230d70 8: 0x230d80 : next?: 0x230d80 9: 0x230d90 : next?: 0x230d90 10: 0x230da0 : next?: 0x230da0 11: 0x230db0 : next?: 0x230db0 12: 0x230dc0 : next?: 0x230dc0 13: 0x230dd0 : next?: 0x230dd0 14: 0x230de0 : next?: 0x230de0 15: 0x230df0 : next?: 0x230df0 16: 0x230e00 : next?: 0x230e00 17: 0x230e10 : next?: 0x230e10 18: 0x230e20 : next?: 0x230e20 19: 0x230e30 : next?: 0x230e30 20: 0x230e40 : next?: 0x230e40 21: 0x230e50 : next?: 0x230e50 22: 0x230e60 : next?: 0x230e60 23: 0x230e70 : next?: 0x230e70 24: 0x230e80 : next?: 0x230e80 25: 0x230e90 : next?: 0x230e90 26: 0x230ea0 : next?: 0x230ea0 27: 0x230eb0 : next?: 0x230eb0 28: 0x230ec0 : next?: 0x230ec0 29: 0x230ed0 : next?: 0x230ed0 30: 0x230ee0 : next?: 0x230ee0 31: 0x230ef0 : next?: 0x230ef0 amd64 FreeBSD system-clang 15 worked fine: # cc -g -O2 partition.c ; ./a.out 0: 0x203ca0 : next?: 0x203ca0 1: 0x203cb0 : next?: 0x203cb0 2: 0x203cc0 : next?: 0x203cc0 3: 0x203cd0 : next?: 0x203cd0 4: 0x203ce0 : next?: 0x203ce0 5: 0x203cf0 : next?: 0x203cf0 6: 0x203d00 : next?: 0x203d00 7: 0x203d10 : next?: 0x203d10 8: 0x203d20 : next?: 0x203d20 9: 0x203d30 : next?: 0x203d30 10: 0x203d40 : next?: 0x203d40 11: 0x203d50 : next?: 0x203d50 12: 0x203d60 : next?: 0x203d60 13: 0x203d70 : next?: 0x203d70 14: 0x203d80 : next?: 0x203d80 15: 0x203d90 : next?: 0x203d90 16: 0x203da0 : next?: 0x203da0 17: 0x203db0 : next?: 0x203db0 18: 0x203dc0 : next?: 0x203dc0 19: 0x203dd0 : next?: 0x203dd0 20: 0x203de0 : next?: 0x203de0 21: 0x203df0 : next?: 0x203df0 22: 0x203e00 : next?: 0x203e00 23: 0x203e10 : next?: 0x203e10 24: 0x203e20 : next?: 0x203e20 25: 0x203e30 : next?: 0x203e30 26: 0x203e40 : next?: 0x203e40 27: 0x203e50 : next?: 0x203e50 28: 0x203e60 : next?: 0x203e60 29: 0x203e70 : next?: 0x203e70 30: 0x203e80 : next?: 0x203e80 31: 0x203e90 : next?: 0x203e90 (The systems were all built from copies of the same FreeBSD source code.) > However, my results have a difference from yours: > in my case tests fail with any level of optimization. I get the same sort of aarach64 and amd64 results for the other optimization levels that I tried: no problems. > At this point, I would say that the issue is in clang. Yep, but I've no evidence of problems but for targeting armv7 via -O2 use --only tested on FreeBSD. You may have more general information than I do at this point. > I think you should file a bug upstream. I'll leave it up to Brooks if he wants to do the initial upstream activity. He should be well recognized and would likely be the one dealing with the later activity tied to getting a fix in place for FreeBSD. =3D=3D=3D Mark Millard marklmi at yahoo.com