From nobody Mon Mar 6 18:13:42 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 4PVmtJ1GzTz3wCJl for ; Mon, 6 Mar 2023 18:14:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-55.consmr.mail.gq1.yahoo.com (sonic308-55.consmr.mail.gq1.yahoo.com [98.137.68.31]) (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 4PVmtH116Qz4CbT for ; Mon, 6 Mar 2023 18:13:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=N15npjtW; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1678126436; bh=7G1MtEEgpUfMC8saN7WG62FMsgikOSp2/4BHWL/tsdE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=N15npjtWXy+AlCW4QVbbbqHIS74VuFD6F0BGYAXGM1eukSXhvUHw3ApwEw5LB1myNFe7aLxhiKyFBbmgqH9DF28bd0iCiiIOpTrQUr0qngMJMzAaq3GzPhjo31zrs3PuRR0fQBBerxI4VANSYwyRZC5bdS3M3Z0WMwzC8DdUMBRYdA1wqRV8VBcgPyxM5oY65SjKJOdl7uno9Bt2DDPe3z2QuuYwickanROaCYBGIVNn7DgHOljXixJoTQ10NU4+Kw0yz2l/cIB+8DmcwW4poANGlyyCAvim57tOXow6xF38dI0BQ4gbKSTMOgD7Cy0ubFbVOi8BwuEm1B8okgP4PQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1678126436; bh=ixfujKO1z1t5URbGmL7nPRKkAMdStlXnIEQg83okmBe=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=R/ZUa1p7EEZhpg5F3hyoBUdHeC7cBGkP3SUpnKIlkSqXhHcfkI0ut1q2+EkkfBqbUmgLNtX/2znR9LXQljIJrMJITFtbBv/gVFVYYFpvX8/TgP3laUYXQCGmim2bacUZyz455a2tXCBa2X4vLaBDC+mpAv+YxFQHQtDZNfTNLSmZXNqB7YLKbD/z9oD6pKLXr0C806HMLer87KooGmVtZY9I2oteCuf8r20/WUFRPC78Gaqhc/EQH9JNG0XcIzzaTl36x7ERhBQ8uNoBy541ADhRg0vf9LigGn75uDb/I1WICyJj6BUQ158ZpiC6uzh/epswzoup42HC5mubgb7jUQ== X-YMail-OSG: 4dYKIzgVM1nShvs45jk1U2WvWCUunCZbl_s51TqmjXyEwWvb0bWd4.nSOcQ9J3P wvOc465Xa3oR_xH4aH2.Ja9smfe0VLJ5AWt44rsNbDYAGvQ7IMHmTKSH8NyR59suIA.TXYYEqoiG bizygQMdtTzEafsE.qw6R8wDrbEoWPkxsjz1HLsGRwB5Ca2HFGfdXcaopV9v7GJ3lD0T4dVteM6u 2yFyTOZZRioAgVi_MHlv9B9zNAZ5MZc5Ot7OSOTp1.At5CupqArgTwAvyNgXy11Fo2yoYtkEkt0k 1FCN2EFdmyqncrcrhCTFVu3t_NBwMRzNt.2.WHvai2UxZvrbVqtFeiHambkEm1BNmbOdRONKC1Yu tsWqfWz7r.p8HfzjeS7CIlWaPyKfGbH66vBFQHzKiYY8kAuL954rwJ_XlVE8RRrMyk2IR_0cQC.p XsyeGr8nGwG6TQidv4gWlXMAbkUHgyvgQwP9jDBanhs0Sw9lv0mQFL0dF2JAGDrBNcrN7Z5XfO_o V8ITTKBAlje.r9jj9BlscBTflyRoccb_SnojfMgOkTkUyJSCZaUyvDbuOsG2GX5f2Rp3y2s3H.Pn NJrajGl7Gdq004VNT0FrjSE1fwF3l.yliHwxkreSH0slFEwE7GI2feohCrTX3p8qmx5lnBr3RO81 R6qpdbxomn9aDmQUM1G9srjCe5rxDNisYIpNmGe_hlxO1haOKavKliCd2xXgHLbmnRqC00jOrJrO 8Uk6jW8BnDn94H4zn3gBsIaa0aI3.O868YyquVj6UUkrGDoutBQWkrQhOfcqO_fu.p2ABeSWfeCm 95eT0TrlkSlbKJKZcr__DvhgYQPxuQbdFktOcpWv4u72w2S3zwpQhi6EGcbzJjaGbCmsgq3KBSqD kcFVW.FAehdFzOWRfgDNUJit4SiDq_oH2xfttNMlX1z1NtrJU_NG.noTWpuX0LFTe3BkdIqn29pL kwiQRR0PeTJEuT9z8GBfAYxtjM7BOA14eC2aFsq.Cw6G66ajBEwo17vvtjtWoCAxsk8mp8t1lYYW vvOzloZWjZtrahhNf01bf4Cb9WgzPXe4FQQFqKidha440pLIjH72Sw.zeHbfTqKmGVag5d.ShxMo uAw6p4T5NvFoAiFokGG1bcoRy54OGOtdf26Ex48Idg4ZkBLt.56t3q5yDGmKw_Q13yAA7.vAb22f OGngk9xO0zbTM6QzXH6lv6ZtLQ_abo8194hmH7RXb9NEoSb0w1SgNwZ_Qx9jdZri3MUBSy8x4M0S VZiXXntNbTuV8xkewt5tvYc.euIcv4lbj5rEa2IfkFgzxMZXVkLwADtWxcMGte56DJeWp_whu.Us sxR.ZwgQgupiyOU3OK4t9RYfqeY6_5654WzSicXqPbSIDChaQ7wbbpxtcTAqJDWQ4wjOO6P_5OlM .0BhzWzYlRZDdaqZqYGnDLDWXWJ6W7XTBN60H3nhsAqzYXI01BDFkF5SkTdQQUM1WUniKrMGloG6 MhpYzgUNWS6R7YzMZJb1YHDouCaFID5T2IUWYNAwJcl68wvIinXmoI7GeDRoGggu1oYoXedRboT9 2_lWfMK36RCgYne1KjQzeBC4_0HpDmk6En.dHj2Z5E1Jn7ueBqBFBb7Yb0sh33uYxZI5vP7Xpegg wFOu.y1mSVet_tyzDl.bqo77r1.ltx4OWUdr8ouiRrTsk4J3S4zCYgZn9syRCUbMxeOPB2DylR95 ITQvzDuYKJ4S7DL5DnFGpqzUpxwJmSfXdqybkX13IKd6wn0fRLdajhD.MDlovpAH_edGioczjKbG UXjTkX9uXFkEIpfmQhFRfpxT5pF4rMaAooo9sPzCDdLoyft1kMR6.B297C850V84HbQgq7OuP9ed GTQELpVdPtmSs3v7fks2f3W.Fm0r2A.kxt8gQPoeiWrgUT7jsRuqG9h8xV5q.K_Trhxxy0LQ.3QR yL5DfqiD.KToMz3QVFDvI381oDEhG9L9IIBcn88mF99pwloK1uYgKuC69045D5nqNt79rfKsPY9E T3NC7WxX2xtslDdKGEQ01KNjP65UovrbhPKcWMQBMYw8GP8pECoI6OEdDBtbY0lyJzwYadYznFVA G6TRDiw5leM5vkzAJhIP1pSEC_0e1yCBZt2kOss8k2_uTNI7F7ZCOMgmzbfWn9wUz3kd1PIkHo0o LUBXkJXAvN95JSnHScnHNSFuFRlbdgQxbapgJnxsLBV0UV4a8Kdoj8PrrJfX.DBaE6g6BA7CMI4V 8JT.52iffLwl1JJxBVP7GTkpbKbH1s6dVNCU1lAMntAW8ireVStsm64Ig.phcuFHaX1fD9cNmQMZ x2kxpK3I- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Mon, 6 Mar 2023 18:13:56 +0000 Received: by hermes--production-gq1-6cf7749bc8-bjcvs (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 53cffe825530be8dc0c79722e9f33a70; Mon, 06 Mar 2023 18:13:53 +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: <7AA0AE73-87CC-4B26-92B2-A0EC4281F429@yahoo.com> Date: Mon, 6 Mar 2023 10:13:42 -0800 Cc: Brooks Davis , "salvadore@freebsd.org" , FreeBSD Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <480C8278-DC30-40D6-AED2-F52F59E78EBC@yahoo.com> References: <2HOLCFE6Z_cOyGycU4ZBU7Lf6kcqohVx7tiLiRLzdjMEc6a8DFeH1IaJqdPNJOqFVTh1MGE7_UUJLcg2gg0UbTZIHZl72NbaNEsqrJwJ3xA=@lorenzosalvadore.it> <93707ED2-F529-49DE-A018-794827F56247@yahoo.com> <7AA0AE73-87CC-4B26-92B2-A0EC4281F429@yahoo.com> To: Lorenzo Salvadore X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spamd-Result: default: False [-2.56 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_SHORT(-0.06)[-0.060]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.31:from]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-ports@freebsd.org] X-Rspamd-Queue-Id: 4PVmtH116Qz4CbT X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N [Backtrace added.] > On Mar 6, 2023, at 09:46, Mark Millard wrote: >=20 > [Some more context notes.] >=20 > On Mar 6, 2023, at 09:12, Mark Millard wrote: >=20 >> On Mar 6, 2023, at 08:37, Lorenzo Salvadore = wrote: >>=20 >>> ------- Original Message ------- >>> On Monday, March 6th, 2023 at 9:46 AM, Mark Millard = wrote: >>>=20 >>>=20 >>>>=20 >>>>=20 >>>> Under main that has clang 15.0.7, I've had to locally >>>> switch to using the likes of: >>>>=20 >>>> OPTIONS_DEFAULT_armv7=3DSTANDARD_BOOTSTRAP >>>>=20 >>>> (to express it in Makefile terms) for lang/gcc12 in order >>>> to avoid the following. >>>>=20 >>>> The no bootstrap build ends up stuck in small loop in = partition_union >>>> (in cc1): >>>>=20 >>>> (gdb) info threads >>>> Id Target Id Frame >>>> * 1 LWP 632886 of process 27787 0x016eb82c in partition_union () >>>> (gdb) bt >>>> #0 0x016eb82c in partition_union () >>>> #1 0x0133e6ec in var_union(_var_map*, tree_node*, tree_node*) () >>>> #2 0x013218e4 in attempt_coalesce(_var_map*, ssa_conflicts*, int, = int, __sFILE*) () >>>> #3 0x013203d0 in coalesce_ssa_name(_var_map*) () >>>> #4 0x012c66b4 in rewrite_out_of_ssa(ssaexpand*) () >>>> #5 0x0082c094 in (anonymous = namespace)::pass_expand::execute(function*) () >>>> #6 0x00fd6ff0 in execute_one_pass(opt_pass*) () >>>> #7 0x00fd8380 in execute_pass_list_1(opt_pass*) () >>>> #8 0x00fc6df0 in execute_pass_list(function*, opt_pass*) () >>>> #9 0x00880c20 in cgraph_node::expand() () >>>> #10 0x00882d10 in symbol_table::compile() () >>>> #11 0x00883454 in symbol_table::finalize_compilation_unit() () >>>> #12 0x0120e204 in compile_file() () >>>> #13 0x0120d9d4 in toplev::main(int, char**) () >>>> #14 0x01646c28 in main () >>>> (gdb) finish >>>> Run till exit from #0 0x016eb82c in partition_union () >>>>=20 >>>> It never exits. I've walked through the short loop that ends >>>> up with data that leads to no progress: bne always taken and >>>> reaches a status of no change in the values involved happens >>>> in the loop. >>>>=20 >>>> truss shows no output and no subroutines are called in the >>>> few instruction long loop. >>>>=20 >>>> I ran multiple tests of "no bootstrap" and all failed the >>>> same way. >>>>=20 >>>> Such would not be a good thing for the FreeBSD armv7 package >>>> build server. >>>>=20 >>>> Also seen via lldb: >>>>=20 >>>> (lldb) bt >>>> * thread #1, name =3D 'cc1', stop reason =3D signal SIGSTOP >>>> * frame #0: 0x016eb82c cc1`partition_union + 152 frame #1: = 0x0133e6ec cc1`var_union(_var_map*, tree_node*, tree_node*) + 104 >>>> frame #2: 0x013218e4 cc1`attempt_coalesce(_var_map*, = ssa_conflicts*, int, int, __sFILE*) + 508 frame #3: 0x013203d0 = cc1`coalesce_ssa_name(_var_map*) + 7240 >>>> frame #4: 0x012c66b4 cc1`rewrite_out_of_ssa(ssaexpand*) + 2020 = frame #5: 0x0082c094 cc1`(anonymous = namespace)::pass_expand::execute(function*) + 68 >>>> frame #6: 0x00fd6ff0 cc1`execute_one_pass(opt_pass*) + 616 frame = #7: 0x00fd8380 cc1`execute_pass_list_1(opt_pass*) + 44 >>>> frame #8: 0x00fc6df0 cc1`execute_pass_list(function*, opt_pass*) + = 40 frame #9: 0x00880c20 cc1`cgraph_node::expand() + 324 >>>> frame #10: 0x00882d10 cc1`symbol_table::compile() + 3860 frame #11: = 0x00883454 cc1`symbol_table::finalize_compilation_unit() + 300 >>>> frame #12: 0x0120e204 cc1`compile_file() + 236 frame #13: = 0x0120d9d4 cc1`toplev::main(int, char**) + 7028 >>>> frame #14: 0x01646c28 cc1`main + 48 frame #15: 0x004ad3f0 = cc1`__start(argc=3D31, argv=3D0xffffadec, env=3D0xffffae6c, = ps_strings=3D, obj=3D0x4181e004, cleanup=3D0x417ed4d8) at = crt1_c.c:92:7 >>>>=20 >>>>=20 >>>>=20 >>>> The armv7 STANDARD_BOOTSTRAP change lead to it reaching completion. >>>>=20 >>>> But the "no bootstrap" issue suggests that system-clang 15.0.7 >>>> has a problem for armv7 targeting. (I've not seen problems for >>>> targeting aarch64 or amd64.) >>>>=20 >>>>=20 >>>> For reference: >>>>=20 >>>> # uname -apKU >>>> FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #88 = main-n261230-e78dc78e517a-dirty: Wed Mar 1 16:17:45 PST 2023 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm armv7 1400081 1400081 >>>>=20 >>>> via: >>>>=20 >>>> # poudriere jail -l >>>> JAILNAME VERSION ARCH METHOD TIMESTAMP PATH >>>> . . . >>>> main-CA7 14.0-CURRENT arm.armv7 null 2021-06-27 17:58:33 = /usr/obj/DESTDIRs/main-CA7-poud >>>> . . . >>>>=20 >>>> on an aarch64 system, no qemu involved (or even installed): >>>>=20 >>>> # uname -apKU >>>> FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #88 = main-n261230-e78dc78e517a-dirty: Wed Mar 1 16:17:45 PST 2023 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400081 1400081 >>>>=20 >>>> (It is a 16 Cortex-A72 HoneyComb.) >>>=20 >>> Thanks Mark. >>>=20 >>> I guess cases like this are one of the reasons for bootstrapping = existence: >>> compilation with clang on armv7 probably is not the tipical case, so = it >>> does not work so easily as using GCC on amd64. Good that it works at = least >>> with bootstraping. >>>=20 >>> Now, I would like to suggest a few more experiments: >>=20 >> Some of the below have a partial answer from the fact that >> the FreeBSD package builder system for armv7 is still >> running system-clang 14 (main) or 13 (13.1-RELEASE) and >> does not yet see the problem. (The build server's actual >> kernel vintage should not be an issue to worry about.) >>=20 >> Nor did it have problems in the past building lang/gcc12. >>=20 >> This is a new issue. >>=20 >>> - does the compilation work without bootstrapping with = lang/gcc13-devel? >=20 > I started a lang/gcc13-devel build attempt. It got stuck > as well while composing this message. I'll recreate and > look at the backtrace later. The rerun reproduced the problem. The backtrace was: (lldb) bt * thread #1, name =3D 'cc1', stop reason =3D signal SIGSTOP * frame #0: 0x01f560cc cc1`partition_union + 152 frame #1: 0x01a17e20 cc1`var_union(_var_map*, tree_node*, = tree_node*) + 104 frame #2: 0x019ecaa4 cc1`attempt_coalesce(_var_map*, ssa_conflicts*, = int, int, __sFILE*) + 624 frame #3: 0x019ea91c cc1`coalesce_ssa_name(_var_map*) + 8100 frame #4: 0x019609ac cc1`rewrite_out_of_ssa(ssaexpand*) + 2052 frame #5: 0x00a1f334 cc1`(anonymous = namespace)::pass_expand::execute(function*) + 68 frame #6: 0x01583044 cc1`execute_one_pass(opt_pass*) + 664 frame #7: 0x015842bc cc1`execute_pass_list_1(opt_pass*) + 44 frame #8: 0x01572368 cc1`execute_pass_list(function*, opt_pass*) + = 40 frame #9: 0x00a8efa8 cc1`cgraph_node::expand() + 364 frame #10: 0x00a91404 cc1`symbol_table::compile() + 3244 frame #11: 0x00a91e20 cc1`symbol_table::finalize_compilation_unit() = + 300 frame #12: 0x0183530c cc1`compile_file() + 236 frame #13: 0x01834acc cc1`toplev::main(int, char**) + 6716 frame #14: 0x01e7c998 cc1`main + 48 frame #15: 0x005a35b0 cc1`__start(argc=3D31, argv=3D0xffffabfc, = env=3D0xffffac7c, ps_strings=3D, obj=3D0x42094004, = cleanup=3D0x420634d8) at crt1_c.c:92:7 confirming the similar context to the hangup building gcc12. >>> - does the compilation work without bootstrapping with a higher = version >>> of clang (we have devel/llvm16 in the ports tree, which tracks a = pre-release)? I'll see about forcing lang/gcc13-devel to use devel/llvm16 instead of system-clang. (Not something I've done before, at least that I remember.) I do already have devel/llvm16 (rc3) built. >>> - does the compilation work without bootstrapping on a release = version of >>> FreeBSD? >>=20 >> That is an example were the 13.1 based package builds on the >> system used for armv7 builds did/does not have problem. >>=20 >> Nor do the main system-clang 14 based builds. >>=20 >>> - does the compilation work without bootstrapping using Linux = instead >>> of FreeBSD? >>=20 >> I'm not well set up for that kind of experiment. >>=20 >>> You might want to open a bug report, but you should try to = understand >>> first what is the component that causes the issue and if replacing = anything >>> with something newer (where the bug might be already fixed) or with >>> something supported (since FreeBSD CURRENT is under development, we >>> might have regressions) solves the problem. >>=20 >> It is already known to be a regression compared to >> system-clang 14 and 13 based builds. No clue yet >> for llvm16 based. (I've separate notes out about >> building llvm16 for aarch64 needing a Makefile >> fix.) >>=20 >>> If you find that the cause is in the FreeBSD GCC port(s), then = please >>> open a bug report on bugzilla so that I can keep track of it and = other >>> users with the same problem can find it there as well. >>>=20 >>=20 >=20 > When I can, I reference FreeBSD package builder results > instead of build attempts from my personal environment. > (But I'd previously used main with system-clang 14 and > still use releng/13.1 with its system-clang 13 and had > no problems, just like the armv7 package builder.) >=20 > I've not been building any lang/gcc* for * < 12 in > a long time. For all I know, gcc11 and before could > run into the problem. At this stage, the armv7 > package builder never uses system-clang 15 and so > gives no evidence for any lang/gcc* . >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com