From nobody Mon Mar 6 23:05:27 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 4PVvLv6bxKz3wW9Q for ; Mon, 6 Mar 2023 23:05:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (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 4PVvLt59Qzz3NwQ for ; Mon, 6 Mar 2023 23:05:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=aQ7ueTB+; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 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=1678143940; bh=exOHRk5OgwtIy27nSX552QEiY27lP0z9scv+ULWijr0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=aQ7ueTB+CjoJd9fov5Ngj54oExHyjV9bjec2H2BhYZm7YwB8OJZOn/XnsiOSu+NU+Oab60t1B3WOL2oPjSVVW4VBp12U2yFMcxwM33bWZNmk6rOYJE4m1RXwvpZj6MG/+uDbhfnlZupzmfgMM4kRWQOZSajarxLhn+KRIphO5xzs6lUJ2eGv3tyHiTYwMwyGAEPuLfnAmZ8ASRX7wsJxbHDzs2CHTax2HwCbE77jQWcHZvZnndanoDORLXyc7E1p7EgHZbf0NWGqFy3Xprk7zNMtYuyXSxvXmkLkPqDZdBdvaOiaSD00IG9YvegNH/ECd29rv/+IienUief0IGmFgw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1678143940; bh=zvxgdCpFpWz3BqkBUfIQ2CoN99zZrPsdf0D0H46ayEE=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=NOzeoXZWrRVeD4K0wAnM0RYZDvYfbu1CzEGovqUMt7ZcVCJfxMAweDtoXfW278zxVHaS+sotVEoD1vp673UETFqrVIUWDNFfgGCAxeXX/14Qq/+gFz8ZnXJQ9vEBrcbMXP8s65aOw1dTRjNLckh7aIfQyzXhUgTnyMPioxDvWFYyXzbEa3t5Fooa06gkr6se/LSykhIg/hNfZZ0P8kyuEU+IW5DzRXNn4zKc6Qf2I2EXOugO5yv0P7maX1fuKaxAfBoby+uYolkZYOk7fuc+vgWZ9LlI0iGTcRxRD1PtxceHfEq9GHCjqvrRIyXLddZ6uGiFHv6R6dfEevzfxYc6zw== X-YMail-OSG: 6Nw.WO0VM1nEnWjeFu9D_fiZPCTyG2SscFsgQAc.AuO3spVHXc1Rn9LanAdwSrZ 0L5VR.qaoQFubidfX2OdhZvVud8ckSp1hUX4EG1wEdWYoMrolx_Yl_BmbkkYLALMp.kUL6R_Rm1u oCTO33Zvij_C5ssYw0yHSHYmZm9sUELi_8gBN2ro2Kggm4UevcaXF5iuosvOiYHw4dSOhdhu6zn2 ifQeftR6dg4GY1VeyzroqW2884CfReyK9drZ2w1DCb5wtsD87rZ_ZiR8DYvhwzXKK0JRLfax9OGn wDBLGh1GXVDBr2m8DIuSkJiKmkUq0Q7ghdIeB5TlgFRf.d2z6lM7aP5Z00DWWHjMTQblmUTdwihg 4hRRJAA_y7b8tI8Ga60ohGovtUJxzDxo5hT8dt8w.P_OzwThxYZ0fmAlwCu9JQV4TMMaobE2go9s SQ9WkzmfaoXcxhpigIneYpFdH_oGpV5aZj7NmkuCHuYzibqO8sCKrNqqEoaxhfhmFcLvVg2zabK_ Sxfc3heQzlVCS.ovvWKJprohrcv_f9XQGpk2wX4buD3.g_9sjg.WTwp3FkNkhjaR9HzqG2naURG0 DooMX4DjI.O6.6tS_.nb2Xh7.1CAbRSdFGjr_4eIGz0NP7pQcvUoukCsJNBaDOtEsvrgDQbRGvds te.jkXO9HEr7.mKGnmqVPg.CguJlT7MYBihh.q3TO5MD97LUJahMQWkUxR3o3NvyNhrM0oOIW7NV pxEHwfva23KBTEoQ7ctGIad7CD31n1XeINfDodpVGe2e7N9PwztJrbOcioQ82AbF8ngMlWl4xdao Zih659CgZurj.drYEsNyKni.zpg9CQPRyKub6gakjmVUjOmSCCQXVK2qXaWprVTBG3VzrZTtSyec 52mVNs8r6SveN7hY0Kshsq19SAgdN7v87kUVUGJPuGuHv54z61acQeafNUvqXNnF3OfDuzEJvcQb UBJfjFKNd8DQfk7DT2tccq_qA35qYgJg8Zs6SpztqQAT3ch0OxNWjXe91Dlh6cBkjnQN2pZHq39n fF6Hafhv4MRFiekxIo7Tf_hzS.JBZIvANZGKTzs.ycB2wiRFFln.R1KSWOfzcbgUHpScxjpJHrTX 0p8aRcF52K1t96yb00E8OQSYl3TEmN1ZjCuix92nAN3uKHBfEI.eQ71_tVqOnd3y3swUmHL_IhVt KRbtuFLYO_Mee64MoBp1iNvzMvmkAypyY_I56uNo_yS7QqAFqRU9p56c9sM2_PNldQ7_HAwseStr bGVd9yD7s_1.2v50VEW8ELQKdiJ5kaY52_BnW6rgdJwAhQ5Kel0zi33H1eievrSriuDAok4aAG4V xg1wwB__cOjHB094lIA3B6JTVQk2RscABKZZT87YI75NIH7KriTl5UuxF7a1sqtRYFyKahH8MPEX NOiGc4GoDlwBeXT_GSvIOx2Iw4v0u77MpbTYS3wytahG2vJk9f4hIrKSKo3D1nLVJW9XUaaJlCbi Sx5gjDHK5.5Y2cDnt_CiOSiylIQTrFOqgJQ9bPer6CNSgXW5p2Xha1Q9aLsr4Tdhnq_6BYZddIoy SVVk6Gy0xZ89eDN5HsiCotEqmn2YNHyt7FXSxCH1M1zEr22CZIqpWYVwIn5dYaBi8QjwmIqz73PO KhrEJSBguYwf88yUcmOrNbF53nNr4pGu7O1KwZu2UAspSx3V0TlW.u1PI7wpTeA4xYGmR6h4iTlH d_C3lVyTmDjAR10nqy6usWahLKw0JLg9CSeHPi4yvg5_cATDTAn_OVYNtU7JCmYQk_GEpQhLStJ7 PTe1Bu2Ehd0hF9wQ9Q0ghzjVpyCkzPjQXKMrqpsBtMKOmzcl6VLZ_6IlxEW0TRMWY_zuE960r4Qs zJTDx19gh.xyp6EzTzEWP.PIJq0xcK1naED_JKQq1srnoHuPDwuV9h32NXV2pMOJlQRlS7tDpqqX _oU8DeTpFmPZ85KB7V6MLyu9S7wNDRoox.NlQAGzE3p02zkcOH0eMhxBLWFMgpIDZtpCiTRR5Q9C IfJ8zyPQdM_OGYNZ3VT6mS3_ASQryG4Kn1rxqF3k9VO3WpajsuXnT1VV7utwEVB9QytRBozQA77j .labCfffsI0S4baD9xwMM__83iW01wQbQKLxljjOXKTaVk21rKmzrcBFknMiRV5Fn1cFU.4dUFGj vxL6v6hboZO..jE2tk7g9CLOOVrB.Ip8N.QtwBNVmy8DTWseUxVFa9gBPOHopSitkOaizPNPW5Ws O8sH5IWcPRMn4VIQgDSSxCT5KNF7ErWysKQAK9DJURG5DYcqgrrCb3SlRyuemzN9ugGDWGMTFTVf .oR.c X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Mon, 6 Mar 2023 23:05:40 +0000 Received: by hermes--production-ne1-7688d778d7-77ncm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 123938fcf871652450d59fc9ce669660; Mon, 06 Mar 2023 23:05:39 +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: <480C8278-DC30-40D6-AED2-F52F59E78EBC@yahoo.com> Date: Mon, 6 Mar 2023 15:05:27 -0800 Cc: Brooks Davis , "salvadore@freebsd.org" , FreeBSD Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: 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-Spamd-Result: default: False [-3.49 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.991]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; 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.64.148: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: 4PVvLt59Qzz3NwQ X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N [devel/llvm16 use added: still gets stuck in my context.] On Mar 6, 2023, at 10:13, Mark Millard wrote: > [Backtrace added.] >=20 >> 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. >=20 > The rerun reproduced the problem. The backtrace was: >=20 > (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 >=20 > confirming the similar context to the hangup building gcc12. >=20 >>>> - 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)? >=20 > 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. I used devel/llvm13-devel for this, adding (partial patch notation, whitespace details possibly not preserved in the Email result): +BUILD_DEPENDS+=3D = ${LOCALBASE}/bin/clang${LLVM_DEFAULT}:devel/llvm${LLVM_DEFAULT} +CPP=3D ${LOCALBASE}/bin/clang-cpp${LLVM_DEFAULT} +CC=3D ${LOCALBASE}/bin/clang${LLVM_DEFAULT} +CXX=3D ${LOCALBASE}/bin/clang++${LLVM_DEFAULT} to the Makefile to control the clang toolchain used. (In my context, LLVM_DEFAULT is 16. I watch commands in top as well.) Still it got stuck looping in a small loop in the same routine in cc1: (lldb) bt * thread #1, name =3D 'cc1', stop reason =3D signal SIGSTOP * frame #0: 0x01f2972c cc1`partition_union + 152 frame #1: 0x019eddf0 cc1`var_union(_var_map*, tree_node*, = tree_node*) + 104 frame #2: 0x019c2ebc cc1`attempt_coalesce(_var_map*, ssa_conflicts*, = int, int, __sFILE*) + 624 frame #3: 0x019c0cdc cc1`coalesce_ssa_name(_var_map*) + 8108 frame #4: 0x01938b34 cc1`rewrite_out_of_ssa(ssaexpand*) + 2052 frame #5: 0x00a0f670 cc1`(anonymous = namespace)::pass_expand::execute(function*) + 64 frame #6: 0x01560cec cc1`execute_one_pass(opt_pass*) + 664 frame #7: 0x01561f58 cc1`execute_pass_list_1(opt_pass*) + 44 frame #8: 0x0154fff8 cc1`execute_pass_list(function*, opt_pass*) + = 40 frame #9: 0x00a7ebc4 cc1`cgraph_node::expand() + 364 frame #10: 0x00a80fe0 cc1`symbol_table::compile() + 3236 frame #11: 0x00a81a40 cc1`symbol_table::finalize_compilation_unit() = + 296 frame #12: 0x01810ef0 cc1`compile_file() + 236 frame #13: 0x018106b8 cc1`toplev::main(int, char**) + 6728 frame #14: 0x01e51064 cc1`main + 48 frame #15: 0x005a36c0 cc1`__start(argc=3D31, argv=3D0xffffabbc, = env=3D0xffffac3c, ps_strings=3D, obj=3D0x42067004, = cleanup=3D0x420364d8) at crt1_c.c:92:7 This suggests that using devel/llvm15 instead of system-clang 15 would also get the problem: it is not just a system-clang oddity. >>>> - 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. [. . .] >>>=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. As stands, the problem follows use of clang 15+ vs. not for the non-bootstrap form of building lang/gcc12+ for armv7. Nothing looks to be lang/gcc12+ themselves as the source of the problem: clang 15+ instead in my context (system-clang15+ and devel/llvm15+). But lang/gcc12+ does provide what turns out to be a workaround: STANDARD_BOOTSTRAP use for armv7 (with the unfortunate time/resource-use consequences). Of course, the evidence that I've got is far from being a small test case showing the problem. Finding such looks to be non-trivial and no small test case is likely to be produced anytime soon. >> 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