From nobody Thu Jun 20 01:01:28 2024 X-Original-To: freebsd-arch@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 4W4MdK5g6Vz5Ng7D for ; Thu, 20 Jun 2024 01:01:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4W4MdK1Wwyz4DHp for ; Thu, 20 Jun 2024 01:01:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20230601.gappssmtp.com header.s=20230601 header.b="d7R/HPqN"; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::530) smtp.mailfrom=wlosh@bsdimp.com Received: by mail-pg1-x530.google.com with SMTP id 41be03b00d2f7-60585faa69fso298825a12.1 for ; Wed, 19 Jun 2024 18:01:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1718845299; x=1719450099; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=7YVqffI2TdRzj+DY8irf8uy0hTbL8gvJ8zY6+cIjOKE=; b=d7R/HPqNuKUNgCazvvwn5TZM2VgKZfFIMQoUFtGGmfROSP7bTH8OoyR5ktZp2Zq0ip M2Sd/CvajR3ivSPD6V7DKKTl0D5xXmcfbsHTvllZ4HDh3jBM3Gs74OEuAfothyd9Kvze NcojseIwX3H5AXAR357ChcnlASoIoNy5H6evXByHq72/AGw3ev6aJKFO5moMHcAU183f ziEr0ITa9B0JHIISwXWb3Xu/Ue8ZrX2S6zpWQOq5jPg+yWBe4DcbuuvzKXHihXIrh8cx fjH5n5d9KjwlCPamiW3Tf8HhXWWHFIpxp0t1lfJJid+A8RSRxQgfG2j5R66nZ7Q+kRfF +CPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718845299; x=1719450099; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=7YVqffI2TdRzj+DY8irf8uy0hTbL8gvJ8zY6+cIjOKE=; b=g1yugx8xv6aqF54z5PieZfJQwvN0HP7RB6TZRcu2qrUoWyxw00/0pHl0IsgNodJFDi BIAwezCYG0c/Lyqoe/NCcnin9H6x1mGpiKMA3kv8YhCfC85wKvKKpDX1Rm2Y2R8pYUs5 VqZ3G42ADknpGIedY/cu57F82pgV5z6anhCNpTxLPpz7EekbR5Bf7jlzh/0XSUDUhqbs 9Uth93GbX0/orzDIRMQan03jIzcuCWUxPo+27wSQ0jCWeAMmH0NKyjzWB8xPyFmzVOD2 Y1FlUtArHSe+6ZWjMJLLPX026elhDLgYDeHnaeh8VGicvpsHOEMxEyzxW0/ecPYuOJhY uyyg== X-Gm-Message-State: AOJu0YygeUwoHx4HDHtE6wXhaQBFkgZrQ+xjt/gcsZwA4LJtX+9t+dlk 5+kMYPiprhNWNekS8OwMc9AGm+p+cEqpvIFZCqkbxk5WPtv4og5/6IAP8nRHs+LrZQzXtTAta/J BgiptNTwmhPtFzpNrSFi6c7yRDl9W5JUgffs7pFKRHdTh2YM5ZL8= X-Google-Smtp-Source: AGHT+IF+abnNr6loScD8mrrbMnlq4NO26oiJFygVNS+jb0RGZukjnhnVo/pCjpHuN+EwhDC/EZizkVPvxZoIoEUHPkg= X-Received: by 2002:a17:90a:c7cb:b0:2c7:ad72:f3ea with SMTP id 98e67ed59e1d1-2c7b3b08bf5mr5922105a91.11.1718845299024; Wed, 19 Jun 2024 18:01:39 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 From: Warner Losh Date: Wed, 19 Jun 2024 19:01:28 -0600 Message-ID: Subject: Minimum gcc and clang supported to generate FreeBSD binaries To: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000790ce2061b47dba4" X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20230601.gappssmtp.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; R_SPF_NA(0.00)[no SPF record]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MISSING_XM_UA(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; RCVD_TLS_LAST(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::530:from]; TO_DN_EQ_ADDR_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DKIM_TRACE(0.00)[bsdimp-com.20230601.gappssmtp.com:+] X-Rspamd-Queue-Id: 4W4MdK1Wwyz4DHp --000000000000790ce2061b47dba4 Content-Type: text/plain; charset="UTF-8" Greetings, I've been having a go at cleaning up sys/cdefs.h for going on 5 years now. One big problem is that it's chock-o-block of special cases and hacks going back to the early 1990s (before some people on this list were even born). I'd like to remove a lot of that, while still retaining useful versions of gcc and clang to work (plus preserving what support that we have for pcc and tcc (including fixing the latter). Note: this is "building binaries on FreeBSD" not "building FreeBSD" which has much much tighter requirements for compilers. This won't affect that at all. To that end, I'd like to draw a line in the sand. If you are building FreeBSD binaries for FreeBSD 15 and newer, you need to use gcc9 (or newer) or llvm/clang 11 (or newer). Stable/12 has clang 13 at its tip. These compilers are 5 years old or so. And are the oldest compilers in the ports tree that we use to generate FreeBSD binaries (there's three older ones: gcc 6 for ada, gcc 4.2 for TI calculators (but it doesn't use system headers) and gcc 2.7.2 for hp48 calculators (same). So from a ports perspective, From a looking at changes perspective, there's about 30 instances of GNU_PREREQU in the tree. The newest one is for gcc 5.1. So nominally supporting just gcc9 and newer means assuming that these are all true (which is true for gcc and clang) and removing specific support for them. clang and gcc easily clears these bars. Ah, but what do you say about tcc and pcc which are't gcc? Well, tcc lies, and says it supports gcc (version 9 I think, but it's been a while since I checked). tcc can't work today because we have qsort.h using versioned symbols unconditionally, and it doesn't support versioned symbols.... And patches to do that have been stalled for reasons unrelated to this desire. pcc doesn't support gnuc symbols at all last I checked. But it has real issues building some things in the tree, so I'll not gate things by it unless somebody steps up to actually do the work to make it work. The pcc upstream has been weird lately too. ICC used to be supported, but unless someone turns up with patches for the latest icc, it will remain supported only to the extent it pretends to be gcc. I've had reports that it works, to this extent and nothing special is needed to build FreeBSD binaries. There are a couple of touch ups required to build FreeBSD itself with icc I'm told, but I've not seen patches and have little desire to chase this windmill. In practical sense, this will just be writing down what's the reality on the ground today: old compiler versions haven't been tested and there's a lot of known issues we've introduced since moving to clang that will preclude even our old gcc 4.2 from working with system headers. Of course, I'll do an exp run with all these changes. But I wanted to give people a heads up that I'll be doing this before 15.0 is branched. For the vast majority (all?) users, I expect you'll not notice. Warner --000000000000790ce2061b47dba4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings,

I've been hav= ing a go at cleaning up sys/cdefs.h for going on 5 years now. One big probl= em is that it's chock-o-block of special cases and hacks going back to = the early 1990s (before some people on this list were even born).

I'd like to remove a lot of that, while still retaining= useful versions of gcc and clang to work (plus preserving what support tha= t we have for pcc and tcc (including fixing the latter). Note: this = is "building binaries on FreeBSD" not "building FreeBSD"= ; which has much much tighter requirements for compilers. This won't af= fect that at all.

To that end, I'd like to= draw a line in the sand. If you are building FreeBSD binaries for FreeBSD = 15 and newer, you need to use gcc9 (or newer) or llvm/clang 11 (or newer). = Stable/12 has clang 13 at its tip. These compilers are 5 years old or so. A= nd are the oldest compilers in the ports tree that we use to generate FreeB= SD binaries (there's three older ones: gcc 6 for ada, gcc 4.2 for TI ca= lculators (but it doesn't use system headers) and gcc 2.7.2 for hp48 ca= lculators (same). So from a ports perspective,

From a looking at changes perspective, there's about 30 instances of = GNU_PREREQU in the tree. The newest one is for gcc 5.1. So nominally suppor= ting just gcc9 and newer means assuming that these are all true (which is t= rue for gcc and clang) and removing specific support for them. clang and gc= c easily clears these bars.

Ah, but what do yo= u say about tcc and pcc which are't gcc? Well, tcc lies, and says it su= pports gcc (version 9 I think, but it's been a while since I checked). = tcc can't work today because we have qsort.h using versioned symbols un= conditionally, and it doesn't support versioned symbols.... And patches= to do that have been stalled for reasons unrelated to this desire. pcc doe= sn't support gnuc symbols at all last I checked. But it has real issues= building some things in the tree, so I'll not gate things by it unless= somebody steps up to actually do the work to make it work. The pcc upstrea= m has been weird lately too.

ICC used to be suppor= ted, but unless someone turns up with patches for the latest icc, it will r= emain supported only to the extent it pretends to be gcc. I've had repo= rts that it works, to this extent and nothing special is needed to build Fr= eeBSD binaries. There are a couple of touch ups required to build FreeBSD i= tself with icc I'm told, but I've not seen patches and have little = desire to chase this windmill.

In practical se= nse, this will just be writing down what's the reality on the ground to= day: old compiler versions haven't been tested and there's a lot of= known issues we've introduced since moving to clang that will preclude= even our old gcc 4.2 from working with system headers.

Of course, I'll do an exp run with all these changes. But I wante= d to give people a heads up that I'll be doing this before 15.0 is bran= ched.

For the vast majority (all?) users, I expect= you'll not notice.

Warner
--000000000000790ce2061b47dba4--