From nobody Mon Mar 06 17:46:05 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 4PVmGR48lWz3wBCP for ; Mon, 6 Mar 2023 17:46:23 +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 4PVmGQ0z6rz46DV for ; Mon, 6 Mar 2023 17:46:21 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Y7nZXRgv; 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=1678124780; bh=WvdC1TTZUxn7vhvc38ZlZaDu6aYRqpYbmiu8msZbe7k=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Y7nZXRgvM/HB84gwE5jY8Am9ruqRYzQZNXn5/XAIYfbCVDNrA6/szmMv3mEdw25/AuULO7/SG0MC9ZZ6QeO9G8DtDTmWNT2qlIDVbawxtFrdeAtMalyoTnuqdBSQZHBYv53iIjWU+JR52Q2wk/xf1wj0j5r7Ei6/sf0qEoguRtw14W9CeWuehLsQZXoHcJD5lxRbV5BS38ohPuW3JpGlUlfoOdrZLsn00zu0e8AX4m6xIZQBtkLzEk1TIdhDUjOJlLfRjddfWZAiQhJHiz9aan1VqD2dKfIBVFbBhqfOj1EbkRkZqn82cPSooBXbBHkT3qg0uM4qDXz5KL6XW42DyA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1678124780; bh=8e/5DvJ6ix+f0ZsF1pnM3zDau88CvvhG9rfhL8nWpiV=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=I1L38qo+wAYjX11Ub9IMt0EsyXVX6dsRtumnn4DroE7fZOUR01rzXczJb7RYR+NioiHsT6PdvczdLvjRylW9Y9iR+px8q5HqYs9ulXIK/dYci6Xdop/JZBUUxOZqw2iaOZruE7/PigCJtricZYSaYlR16PM3ah0LvDTJPDa+Q6b5IbPK2mLcqGVsPX51qlLD1LVNExRjQpH23tjyz78+Io9y9nEpJhyV3F5pA/vJLK/Hft+uBuQ9BX7Q+yTpGdqi+sycSez1NyoY5OerBvHw/fEpaYySdZbun+5csoirJVsahFXAZUihELEiEQgPcptDT7TNXXBykj2NVc51LYDbhQ== X-YMail-OSG: mBVDUhcVM1mhszWBKEhBiUpe3cwff13YmoR5Hl_OFXhBaKiAtXSAXdRQsI34RGc Ogmc0dHc31aZC95bEZwAEyRfM0RCfuM1McgklLYiutowxmSR816N_pnb9i1GQYuquy7h7JamWTMr p_igb.l5JdBDEWakDSzJSE6jKk2Wx.nz7CFjf3TGTsIYe1VipeUODK0OuZMnHklSIpwm1wMYGwv7 HB3ysEWZZLgVOWlIkSwXm0krDFY21cuuxX0xzkMx92XDY2qcLtbXU06flI_XL_YPIg2rLGuvmtDj Zredy_yeODR6vwmN5zO3RYFlYWgDBG.7CwA4CW3WacVhfWRHLzRIRLWG0oyOnOTR5jbEGs8t78gH CsL3R6Ask2bKddjFcoevl.4K6brqNMmCM78qyQI8yCuz0mcuLb1K2URhyPkNvZzGexGuoMZGTkaq QxCTKR2HXnC4n6fpbTuEXLq.bVR279FRa2wSGjKvENk5YYWFRUwQHRAYbw7W3qp9PDejuk.o5chZ CBEHHYkluLr.gE37WA_b_vT1Trwk_9g93lFpTJuARqkgRrxFwZcA25.SwhdBZHdsQtFThtjB3KEY DpVQW0l5Az1fjt5gEDXTwrYUdufl1.Mgv5qmMEqCiNHdHLgdvUiDLi36hKV6A6SEleHcJBXE8q9k lpuhdif73dNsbr.tVjYHQzxmQglzAXNMbxykgsvOJYuIi_qv9Whu8ZB.FT1WtEB47HKlCBu3mNzg fmF117KJesDUW8EpfPU3yEglS8wliDTHMQq7dBIZwxfI.VtTcYh_E9W8Gs9b08NDhXD6z2zlg8nm pRuB8JphLsP1gHwpPEyjYLbRkwZGR8f5jesDfzpaS9X1Qcn1SPCyB756ZBqIncJh7IF2FJ6H5uo1 V7mJauHKvc436CobdEWxwCIl7UiKJcQEuasfZtu4iHqE_PKFdkcjpQ13XfOhDz957.YuO5x.cEcp 5CIZtf5GoqFEkrB46cK3HDd_rfxxwvdvI.jhWsa568gbk2vDXh_.lVHVHfEzmg.dNYBhSWFv9uh3 NdN_m8r8zdfQj8CRcU_R3vxZ3bUL5kYWdOiWgNY3XtbuQ4.1WFLcrr1QWrJgXt2P7xv.hiBuHKm2 JZhXzVBgnsSx566BHKJRMjX4mw5D3SoIXa9trNSIN43txnIMJ1pJ6lbDDNAad.sZQNU95WTtTT8r Xun5wJs6rSOGWkCokNIq6mdrWq2c8ouYe6bzl5X8mSR84H.z0iaXGR9YENo1OCC1IW2oTGsAbMNL UB2Pp9DbQRWXkQS7KL8FRHGRnk7cB8rh3dyhOXRRY176Z287jmKI.B9AJm1tXg3jNjSJbu61gXdA WoC2Z1xjZRDfkf7ZJ5XQMvHOp3FoD_Gwtl5u6iBEMzAmN6KB3hHd25ImtaPWmRx4qMjETWHj1cw_ pA7H0g0n6KBTG0Q1dmU28r4x64tFfAKzNV1i5zDb9AhvV9UYUCkOHBV_dCsW0fY_mvgnwnnzu7xF cd3uEm404xhGEUpSskTapn9_XUXZmcTp4xtTQPSNObfeq8S7AKN_7huXZjmIG6jH2Ik0Szt5PI9. Pt4p5IopuxCy2wqOZO8om9M5HgaNwGCfyX49V7JtMa0XGuQIMbWXhfaBVEr69Z_UxWVjBwgJe_mR tGS3NmCp2GXVaS8BzNu3yaBdVdPAgmCnKry7DRC6kfepBNdz.W68CRgCqYB5SHTS1_Bj4BrSzN_y Fts8WJBLAvuHFek0AMWNqpTnSl6GlbsqFZ75lBz5f.r5sUAHKlJfe0Cs8gw97LQNYKjmlAFZRGLh kvLbfuFbB6XcY61AkDda5CuZAayevsoiQrA21AgfOildac7CmXBfm5vaZv1qsHP1CxPyXedZa.dO a0RJWG3_XRIm2iPv2RX6Q2URi.Zkk8ovCUbUcix6i8I9YBq8_KoHndZ67_yl_RHCl031p4.S7Iwy JLXaAvfi68PnCVJe9x0jeMQSbeK4TC_rrDkE4AQ1Dwx69KASW_cRr_RqxSzEjsrVhfDcSOGfsPXV KiiIWCPxDbjwkdEXTq7jblszO9ziHWA_sDb.2p4vg1ZeOtnH24IF1Tf_8HVUG5UD_M4AFXU4zJQg dJf674m5.yJD2MK1mCyFhmkPZKb6bwq9IjcfJaOQhOKRmhqRXwhyBJWEDh454LT9EZj_F4hqNZZs SO6YIgTxjjEQZyC35ZJNnAvZiqndb0Yfelo6xVib_5VXpzzgahU.W2SgsAy_w6QfIDecrO6UM0p7 lLKIcRICYhy.g1rKtFtBRJ89PW41njiczjjXisKejqQvll3Ln3p2bO_R7Tu70uz9TsbsJoDqMSsP YNA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Mon, 6 Mar 2023 17:46:20 +0000 Received: by hermes--production-gq1-6cf7749bc8-sm5v9 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID bb6e3b78a31aa9436ecc62e6585b054d; Mon, 06 Mar 2023 17:46:16 +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: <93707ED2-F529-49DE-A018-794827F56247@yahoo.com> Date: Mon, 6 Mar 2023 09:46:05 -0800 Cc: Brooks Davis , "salvadore@freebsd.org" , FreeBSD Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <7AA0AE73-87CC-4B26-92B2-A0EC4281F429@yahoo.com> References: <2HOLCFE6Z_cOyGycU4ZBU7Lf6kcqohVx7tiLiRLzdjMEc6a8DFeH1IaJqdPNJOqFVTh1MGE7_UUJLcg2gg0UbTZIHZl72NbaNEsqrJwJ3xA=@lorenzosalvadore.it> <93707ED2-F529-49DE-A018-794827F56247@yahoo.com> To: Lorenzo Salvadore X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spamd-Result: default: False [-2.61 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_SHORT(-0.11)[-0.112]; 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: 4PVmGQ0z6rz46DV X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N [Some more context notes.] On Mar 6, 2023, at 09:12, Mark Millard wrote: > 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? 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. >> - 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 >> - 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 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.) 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* . =3D=3D=3D Mark Millard marklmi at yahoo.com