From nobody Thu Jun 20 20:30:03 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 4W4sYk3k0tz5Nh5R for ; Thu, 20 Jun 2024 20:30:18 +0000 (UTC) (envelope-from bakul@iitbombay.org) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 4W4sYk1l1Vz42fP for ; Thu, 20 Jun 2024 20:30:18 +0000 (UTC) (envelope-from bakul@iitbombay.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x52c.google.com with SMTP id 41be03b00d2f7-70df2135426so907009a12.2 for ; Thu, 20 Jun 2024 13:30:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iitbombay-org.20230601.gappssmtp.com; s=20230601; t=1718915415; x=1719520215; darn=freebsd.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=8P970je7akEiClmIfR2fpGd7DRhF4PPe/KFOdbBFLTU=; b=Qn0eRNuqU22Cd/v6G1ALWUSKGwDWKLadTZ2yqZI8GRhuQvcoLbifMpH3Sy7lFv2zLt LH12ET+dlRJ5OFXsqo/Zvl/d74IOXO9cRk1/tvVQJy8W88tLz6UKVVbFosbK8+M070A7 J4kMSmQU1e0+DuGyVUN6OKT3Jv6qJ9O0g7c2HgW2nKhKD28Id5r9ZIMb84Dls8xMJmz6 /WlVKHcy8eJ+1r4/8hCzsYXoJsH6f2jkD6x8PkB/qZ2ypgvdg2YMvHubqM65jA8v2Jaj wSSlTniCPVEAqkJi867EbBXEe0HVwIxXxJolBNCLpzQU2LRsh/PPiGEkkUMm4T3BKBwO kQNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718915415; x=1719520215; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=8P970je7akEiClmIfR2fpGd7DRhF4PPe/KFOdbBFLTU=; b=olHL+8oqL7uhKJzEhJ6F9chOyW+jMPzhQJRGEt5xaI+F1K11rKfzbxt4cRZf/oQHYL do20dpu1sqAzkoChSTvUVVbjKzyH/YByzjgWMjEvpJUFXUjD/PVVkgJ9Ns/blYlhxqxT IIGXaLVwELwyDAtkx7aik+opZbCXwrWxS3tpVfGurTECgkV0L+X1Dxf6AwjH2FdA+5z9 W2DNSOLzbt2zn14p8T/N0GZGa/IFwbOS40wzwBvNFbgZ8qFQzp9a9Fha8YqpyFcy3YyA huE+MVEMeh98/UHsTHN3bhrOfZx7y/NhU7vFAlDfpnonVgq+LnJt7gSsGAjb49kpGZWs 5FzA== X-Forwarded-Encrypted: i=1; AJvYcCUUwFQogemT2OoyRifHHJL5+p76GSQX9yYCeiqRwT/H5ytG5JAUvYhAqWsX2gIWPZtwytYm3XlRFMc1xcxxdyyQ5VoIhMhe7qQ= X-Gm-Message-State: AOJu0YwJpIp+X94PcBOmiZS/Fm/OLu7ebV1OztNthQ3/66LX9DIN+bvF QsSqy4wH0c3fAzphynjmfx23X4xoAVnUL09mPjjk/iYWkSB+crfZm/o6dtrPkg== X-Google-Smtp-Source: AGHT+IFUH8Fsm11XV5PwB5Lwtd001yVBXwT4xGsdPTYn+xniRWhbNmZ2ZxWZahsrxkZTjRMDD0I8Wg== X-Received: by 2002:a17:903:2352:b0:1f9:c0db:a3df with SMTP id d9443c01a7336-1f9c0dbafaamr43817755ad.42.1718915415086; Thu, 20 Jun 2024 13:30:15 -0700 (PDT) Received: from smtpclient.apple (107-215-223-229.lightspeed.sntcca.sbcglobal.net. [107.215.223.229]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1f9eb2f094dsm353975ad.55.2024.06.20.13.30.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jun 2024 13:30:14 -0700 (PDT) From: Bakul Shah Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E3BBA32F-D0A9-458B-8129-03E7E7DCE349" 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 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: Minimum gcc and clang supported to generate FreeBSD binaries Date: Thu, 20 Jun 2024 13:30:03 -0700 In-Reply-To: Cc: Konstantin Belousov , "freebsd-arch@freebsd.org" To: Warner Losh References: <197A5386-1096-4754-BA82-996140B56EAF@iitbombay.org> X-Mailer: Apple Mail (2.3774.600.62) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4W4sYk1l1Vz42fP --Apple-Mail=_E3BBA32F-D0A9-458B-8129-03E7E7DCE349 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jun 20, 2024, at 12:00=E2=80=AFPM, Warner Losh = wrote: >=20 > On Thu, Jun 20, 2024, 11:43=E2=80=AFAM Bakul Shah > wrote: >> On Jun 19, 2024, at 11:49=E2=80=AFPM, Warner Losh > wrote: >> >=20 >> > Yea. We shouldn't. But it's kinda necessary to have the compilers = tested all the time to spot regressions. This stuff is fiddly enough = with 2 main compiles and 2 that kinda emulate these two... comes a = point that you need to say enough unless somebody is really, actively = using it, our kinda support becomes the worst of both worlds: a random = drag on development that isn't actually useful to anybody. >>=20 >> You should'n't have to test with every compiler if the libraries and = headers are standard compliant (by default). >=20 >=20 > Except things don't work that way. They are standard compliant (which = standard do you want?). The standard is the BSD API. In that API, we = have two versions of qsort_r: The old, pre-standard and the new = standardized version (at least for the moment). You can say you want a = different standard, (see _POSIX_C_SOURCE or _XOPEN_SOURCE), but that's = on you. I only meant standard compliant in the sense that a compiler that = conforms to C/C++ language standard in existence for 10 year or so old = should accept it.=20 Who even depends on the old qsort_r? Why can't the fix be in a qsort = specific area bracketed by some backward compatibility flag? Anyway I = will drop this until (& if) I can come up with a cleaner solution. Thanks for your patience! --Apple-Mail=_E3BBA32F-D0A9-458B-8129-03E7E7DCE349 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jun 20, = 2024, at 12:00=E2=80=AFPM, Warner Losh <imp@bsdimp.com> = wrote:

On Thu, Jun = 20, 2024, 11:43=E2=80=AFAM Bakul Shah <bakul@iitbombay.org> = wrote:
On Jun 19, = 2024, at 11:49=E2=80=AFPM, Warner Losh <imp@bsdimp.com> wrote:
> 
> Yea. We shouldn't. = But it's kinda necessary to have the compilers tested all the time to = spot regressions. This stuff is fiddly enough with 2 main compiles and 2 = that kinda emulate these two...  comes a point that you need to say = enough unless somebody is really, actively using it, our kinda support = becomes the worst of both worlds: a random drag on development that = isn't actually useful to = anybody.

You should'n't have to test with every compiler = if the libraries and headers are standard compliant (by = default).

Except things = don't work that way. They are standard compliant (which standard do you = want?). The standard is the BSD API. In that API, we have two versions = of qsort_r: The old, pre-standard and the new standardized version (at = least for the moment). You can say you want a different standard, (see = _POSIX_C_SOURCE or _XOPEN_SOURCE), but that's on = you.

I only meant standard = compliant in the sense that a compiler that conforms to C/C++ language = standard in existence for 10 year or so old should accept = it. 

Who even depends on the old qsort_r? = Why can't the fix be in a qsort specific area bracketed by some backward = compatibility flag? Anyway I will drop this until (& if) I can come = up with a cleaner solution.

Thanks for your = patience!

= --Apple-Mail=_E3BBA32F-D0A9-458B-8129-03E7E7DCE349--