From nobody Sat Jul 13 10:33:20 2024 X-Original-To: freebsd-toolchain@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 4WLlDc56F9z5QVNt for ; Sat, 13 Jul 2024 10:33:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-54.consmr.mail.gq1.yahoo.com (sonic308-54.consmr.mail.gq1.yahoo.com [98.137.68.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 4WLlDb5dr4z45ld for ; Sat, 13 Jul 2024 10:33:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=VcnuVnzh; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1720866812; bh=6T37k4z7hSxuWGGCB+X9+AhWmSArx+YCxSVoKXMyZIQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=VcnuVnzhqhqx+tkkWBlqW7jAaJEaCehskYaXs/Ooy40g2vyBgQN8hLPf45vS1EnQWq70jJ1lDu9ZWVYH0n0l+yoUB+a4KXeeNJs9QhF1ilVesvyCwSJ3M6zhRAscrNfvO6NUQyKbdm1z3YJvZnn9zvfENfbcYnXV9BwrZFD2QW85geXBirF74wCxhY99jslhwDMB6WCzmZVSMrZERcuqFEVN3wz2IMK5Ocqv+JwV62bTce8fS/LdwvkqZNnI4GjjkzvGGYJq7tQRGwHqXFeiCBUHTtDAtW/aAv2kqlo27dxSPihlBQyGYFO1cS9/kLW6L6PNCSReVbO0h95GvMvDTg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1720866812; bh=0xE96rlJP19f4RO97TJyB+FL/MQfFM0s3ux3jjkeSc1=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=LGUzB34cpmAxbAmR7PO/TGJuJjTniFqBUtve8F/0MuWuECZ31EsYu/ZsNhDIyGq6vJxpwvT3G4FrqmKw3Aw3mdM8Z6SkSj71Eu/x6/JEf7MzcuXpGnTjAMN6Ha8NmMVIWCDAxZZH0mnIVwKv3JlZ7jKJh1cYivIRlT75+Fs1Rlx3/K0K0l4o6xqmo1oUMZGibSazy7rFkhLiCsG6h2gM70NA6tW9R492Vmiv6HniO0HNbjzf+oYqvSwhDWJaKuoNlzXuDQjnF2x6soA0Wz0JNXQicTLpbxtfwR4e5V2IINHCym8jeAalumV4q8Rvq0MAJil0XJLLqpvdHsXz4+jywA== X-YMail-OSG: 5rnxiZEVM1mvIHA5Sq22EWVEpU63UJGJILFJjfZrUJHzlVBJbt29YnlZq35fr.n _Wr5_9p.AccfWjUWQ.n_uN7fUZO4dj1YSnOxw.iKS14KoWhDgsD9U7kQsZY42M3B789KIkiCYJyB e2ATKqkA1_VbR3M.PKGpGXMmaMT4IDNMicJqe6WicfBOpsS3U9vCSnLO9E2H8zyPGQWv5qkdEuKQ D76pr_EyQWb_jc2iH2LgQyaeEy.P10Qkk.ntfbRoSE3VAfoKJHw7YvnzfgEsEcxg0tphdFeRkYRV Zww8AIPCF8MKHUcU_jgGxPwbw_JT8NL_U_rDE9LmUZ2.QXHcxNLe.frmzyBVOUizWJk0FdDNbsbk uXL692_kP0qPaTKDUAxzk9OWHqlrWQtwgdf_DduIrNw0oFtw.zaeRFIlJwGk3Vo3Fe1AvSkeUvID zRl4mrMazJ8MVTVyjC4choLObd_vfA16zT4n8Xiwd.jr_sejtFsu6lHYVomy1uTCJQxJt3OMiHpD sqOnND2B6Z5urhbYFFUS.rTaChhZvnoL3OqYEk0ehmQmXKlAVkoR6UQ6Zzv01aiLae9HAqm6fD.p v0F3iNJlryelnquU1wO3UlavlQ2Fu7t7laDvCcRXDoa62QtXUDOnTtHgk4PHLmBts3Mygz04E.XA v4ZRwc2V5OGJXLNoIgOkZEnj.e0UpRR2JNGKBS89_co9LM8xEIO7OuMZGK72tDhxkDUmmrHD5Tg6 7PiTrIlU0RG_oYPDhUE4v8aFQyyZUtU59Dl70Hn5DKO372gbBfxYcbAjY0DUZ_D8nSiQGmsF5f5f arY6kfTHOo5WwUsVtu1bRu_o_S2ZRGdynS4EAzojkL9E3tW6_m7vR2X7Ptk85qFgb9k5k_l9p42x Lxwq_yh8yk48H4uSI4PXw_EfRuD17HwdpJRuGUTgF5nVdIORHe4f8_0ImJKHB1evJHE3HKAqPw33 ppw1O_DgiMRCUEoqlwVb1h7Ujm6mpmj9p1r2WFfoLcRfdv53MlvYjdUzzg44n8PTJVnkpkhiFVlw 69ldPSk1rQWDqTlpH.XkNe4Czt.EJmoCXyn1CkyhTqKhNYluEFPPVO.o6g31bVp8fmvR2svmHDOj 7PgVkvnCSQTHVduUSR3GGiw3Wxhq4oBSc68Mi39PyeXi9M6I5ZyUF64zRd5LHNzXGH5BiBotHOvi oSn.By6YXanJ_jNrbGRijJrsUtXaIdf_i.K2rsex8IUnqbu_7KldU941FftUTIhmwDlL9247gqTT HQGnvI7jKZcp_XoofVoe98Jvs8g4AYKdHCNee_F2sxfj4l7TrgDse7orhfYhHLXSTWLmWOmfje2y iVUe8m2JoS9K6K3qvUEGUCXygoqCbfdICq80.twAzP_f3fenGIMdJluvQ__X7jFdYUKVqMQSisb5 pbd3NqDyGvSg4lKmO.DuN.4_lHrl33z1j1LBr_r.VDGNbCAYw3QBn71djrGFq3lXIfVws.N55WJp tLY3K1WvEWXb1J27OGFYKvHhiHf21..dN0WOj.6JmDQ4byP_ClkeZ4D.sN0tZrygKjN0NjwGgFxt wYRRfvH1Mi5Bm_MInyCDYB7TTa_.ouZ4TfOcZGFOgnGN.VmYTI8MCvfWqMRfo7O0aZ14b0w_mr72 TVQhVPwgKIO6EypLMPk.g5z8OHmkghXLxJdtI82xUgyndmb0BRbGTwEKT1mUsgYFzR0bmVzkHANJ jcOIRNcf0yGQHVOPg_ajKrAv0t81u6vtopABxGH4zj2oTSrjcWN0vMW_kUnVeF7KjVlhA_TMC7M_ 0cHFGoc8nk2WkeXTN87PdrWQeTFcUm27l1pa1rOpQev0Jjzd5.JpP3kcf7KZejMTo6x_i49A7AE7 _iFsUlztJbHaOq84_V.vHPqWxxFzo9_SDINqrv9f8Dyg4k5c_ODeStAQYRV9YWiWptnsATdTTSfD ck4kQLuuW9EctoMeul60iMDMjDtPv0TDCNIGZAvbLTvH86mJPLHerRzQnL6NE0Ql3zaUF5x6V94L YrB46KOuSbWh9QZJ7GizikrAPIbFW2UiPsHujpAzNq6IrmEUrUui39W2MD4cjftYA6Dx8fAwfv1a MES_WZlSKLl6QLCr4FRNkyy6WPacnghbt3JuRBAFzFKlxBctAWmglTNzZ2zRDcXDrkFK7LVjVWXe Z3pB3hFBW_7HmHVupnzCcZPLR.S1S3Sb.NCc.2gt43tKh908gLOT3TzeYxTAMog3pzNFBeyzkmsv FaTZp..sUNI3_8kJegfErg7o3hh_Iy.sa69Kg0vtKYShFOrGq_6tf6srls5DYpXdaeJs6YxzUOPo m X-Sonic-MF: X-Sonic-ID: 52924941-cd0d-490e-a2e9-bf1abc3f7757 Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Sat, 13 Jul 2024 10:33:32 +0000 Received: by hermes--production-gq1-799bb7c8cf-hxpdl (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f9d459581298cc58911b2582e474e4df; Sat, 13 Jul 2024 10:33:32 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: lang/gcc* built via --disable-bootstrap via using just-clang instead of a gcc* vs. armv7 and armv6 using --disable-bootstrap by default From: Mark Millard In-Reply-To: <47LFikjUoSMBdRIDxX2x8zXJM8_q9zapM7wQXCArMOcjplk1ZKrVZ6aSsAqvMcK9FHmETVq6h2y3TLSHU7RQHDzaMjZREAIRblEgLRZZLZg=@lorenzosalvadore.it> Date: Sat, 13 Jul 2024 03:33:20 -0700 Cc: Robert Clausecker , "dim@freebsd.org" , FreeBSD Toolchain , Gerald Pfeifer Content-Transfer-Encoding: quoted-printable Message-Id: References: <47LFikjUoSMBdRIDxX2x8zXJM8_q9zapM7wQXCArMOcjplk1ZKrVZ6aSsAqvMcK9FHmETVq6h2y3TLSHU7RQHDzaMjZREAIRblEgLRZZLZg=@lorenzosalvadore.it> To: Lorenzo Salvadore X-Mailer: Apple Mail (2.3774.600.62) X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; 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]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.30:from]; TO_DN_EQ_ADDR_SOME(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-toolchain@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.30:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-Rspamd-Queue-Id: 4WLlDb5dr4z45ld On Feb 26, 2024, at 05:39, Lorenzo Salvadore = wrote: > On Monday, February 26th, 2024 at 03:33, Mark Millard = wrote: >=20 >>=20 >>=20 >> I learned some about the technical criteria for use of = --disable-bootstrap as >> part of an exchange for a submittal that I made. >>=20 >> There are 2 quotes that are relevant. One explains a relationship not >> explicitly in the wording that is explicit about --disable-boostrap . >> The other is more general (and not explicit about command line = options) >> but that the --disable-boostrap fits in. >>=20 >> First QUOTE ( specific to --disable-boostrap ) >> This should not be done unless you are building with GCC itself. The >> reason is only the C, C++ front-ends are supposed to be able to = compile >> with a (non-GCC) C++11 compiler. >> END QUOTE >>=20 >> In other words: all other stages/parts are allowed to do things that >> clang/libc++ does not provide compatibility for. >>=20 >> Turns out that internal name-poisoning to validate some gcc internal >> scope-of-use criteria are an example of the issue that can make = libc++'s >> lack of design for the poisoning a problem. Such has been hit in new >> contexts in lang/gcc14-devel porting. It was also involved in the >> older a4831f4933d0 ( "lang/gcc12 lang/gcc12-devel lang/gcc13 >> lang/gcc13-devel lang/gcc14-devel: fix build without bootstrap" ). >>=20 >> The above QUOTE can make it messy to determine if one has hit a >> front-end problem vs. not for making upstream bugzilla submittals. >> If not viewed by GCC as a front-end issue but from/for code from >> other stages/parts, support for changing things may be unlikely. >> In lang/gcc* terms, if STANDARD_BOOTSTRAP works, effectively the >> response to a submittal may be saying: "so use STANDARD_BOOTSTRAP". >>=20 >>=20 >>=20 >> The following quote is from: >>=20 >> https://gcc.gnu.org/install/prerequisites.html >>=20 >> and so is explicitly official GCC material: >>=20 >> Second QUOTE ( more general than --disable-boostrap ) >> To build all languages in a cross-compiler or other configuration = where >> 3-stage bootstrap is not performed, you need to start with an = existing >> GCC binary (version 4.8.3 or later) because source code for language >> frontends other than C might use GCC extensions. >> END QUOTE >>=20 >> (There is a missing /C++ in the wording. Also, not wording explicitly >> inicating which option syntaxes have which implications.) >>=20 >> One has to read into that that the name-poisoning imposition of >> scope-of-use design rules is an example of a GCC extension, one >> that libc++ does not follow (i.e., does not support). Various >> parts of the code make no claim to support a context that does >> not follow the design rule. (The front-end's code must not impose >> the design rule for its build.) In general, gcc producing gcc >> has to be involved for some stages in order to be supported >> and those stages can use the scope-of-rule rule imposed by >> name poisoning, as an example. >>=20 >>=20 >> Ultimately these may lead to the need to avoiding --disable-bootstrap >> ever being a default for some lang/gcc* examples. A contrinbuting >> issue is getting support from upstream. Another could be how >> complicated things get as gcc progresses. >=20 > Thanks a lot Mark for your analysis, both in this email and in the = other > email thread. >=20 > I am proceeding to slowly dump the possibility to build GCC ports = without > bootstrap: indeed, building lang/gcc14-devel port without bootstrap is = broken > at the moment (which is the starting poing of the whole discussion) = and it will > not be fixed. > I am keeping this possibility for older GCC versions for now: they = build, they > are not broken, even without bootstrap. If future updates break them = too, I > will require bootstrap for them too. > But starting from GCC 14 ports, all GCC ports will require to select a = bootstrap > option (STANDARD_BOOTSTRAP being the default). FYI: lang/gcc14 is not using STANDARD_BOOTSTRAP for armv7 . > This also means that I need to make some changes to my testing = environment... > I am already working on it and I am fairly confident that I can find a = decent > solution. >=20 > Thanks, >=20 > Lorenzo Salvadore =3D=3D=3D Mark Millard marklmi at yahoo.com