From nobody Thu Jan 19 23:50:06 2023 X-Original-To: dev-commits-src-all@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 4NyfWM4YS1z2t3Kk; Thu, 19 Jan 2023 23:50:07 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NyfWM43fPz3GFn; Thu, 19 Jan 2023 23:50:07 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1674172207; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yOdS/3pe1JMneN6kDKnXBxqPe2bAulXPrwv853sHWmo=; b=yFJ90uCAPmj+vdQWFKr9iYtgvwMZzkchGsgeAOc1qNw1gEqd4Mz4Q2oQSS1HA5D3ji9K/Q Vehcj9BGRmmz7kK4xcEiIlOYogpietny+HfeOLbb24twucQDNRD6DW+kiag1BDoXEYCBCl 5kLFrYytrDfguai0+Jp42+f5zJrkrlkugDQihcF8SHLUbKX4H6ezFTvn0kAMHgTafaTyvC svFKOEL4ZWGwFn18F48IzhtCfa0jm1Q5u8CCMn4xgrJgl6cv/RWIq/EfEGoLIJQYNXUDpI nbF4ib9WNP8doq2BdYJH2SSayw2UhOhXnlyHiyyPdIi6N4YPjh8wsqovi01MsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1674172207; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yOdS/3pe1JMneN6kDKnXBxqPe2bAulXPrwv853sHWmo=; b=sSzQ3YJTIrX5dzs/jjFeZpvYPmYT1buBUJL7fbY3MoVvfz042rDp+vdSWk3Zy6x3qlg5sD XEaUYK/0GqVb5BEebr4MzhTOFQXrmzeeRBW+V/4lXy9nvxLJOl7YrENsIBmBF3kAsLKGnD Aks3AfuppNFs9FjOSIKc26AHLwZCVeudcmpe4Ms2YZyPLa/Y66iCS6QbaSBZpvlRhrTt/c AubEMzaZqAEYGtT6f2BH8mfWGlmn9to8J12tpATV9zuckNgVyTr0jmXhjlmSixCKctmmvp tIrGscqAH+V0aW+j8a72x3o6TndHP7398MOos5Rw/i6fmK4WzN4HFf2j+SBkvg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1674172207; a=rsa-sha256; cv=none; b=nuDcGKXFozYk95Mdly/3OIuEozd03+NUtcXk+SH76QjHZUNVeBZW71QoAymNB5g+NH5+jP tCqwE/refEYL79ofniJlMt7EinuuIYWGuzIbjCnnEhhl3ek5oyuBFBO8O7yfXk1NHQCE5w OfL8WhoByy3+tpU77vhsMRaBHVKCXo0mtESWK2ipLwj4Twrvkk/BRxVfOYqG8mzt9P5mi3 sOj5+29QFAUk/18eNVgW0VQ0yVU4FgITvORaZdD1Fggcu9CbRso3C7yvu1dgfL36MsRen1 1xrqn+DU1jaTuygjV7KDeehIY6W76WjdDl7WVKbRAW15Bp3rP7O70GxKTq6XpQ== Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4NyfWL6sfkzxpZ; Thu, 19 Jan 2023 23:50:06 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <343ea0b5-28fa-efa6-b3d3-4126570e40f2@FreeBSD.org> Date: Thu, 19 Jan 2023 15:50:06 -0800 List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: git: 43703bc489ec - main - stdlib.h: Fix qsort_r compatibility with GCC 12. Content-Language: en-US To: Jessica Clarke Cc: "src-committers@freebsd.org" , "dev-commits-src-all@freebsd.org" , "dev-commits-src-main@freebsd.org" References: <202301192249.30JMnCXf040410@gitrepo.freebsd.org> <8C902ED3-D9F8-4F88-8D43-F8E4809C9D44@freebsd.org> <0F50986C-BC29-4A7A-89F0-DAB3863BF51B@freebsd.org> From: John Baldwin In-Reply-To: <0F50986C-BC29-4A7A-89F0-DAB3863BF51B@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N On 1/19/23 3:36 PM, Jessica Clarke wrote: > On 19 Jan 2023, at 23:31, Jessica Clarke wrote: >> >> On 19 Jan 2023, at 23:11, Jessica Clarke wrote: >>> >>> On 19 Jan 2023, at 22:49, John Baldwin wrote: >>>> >>>> The branch main has been updated by jhb: >>>> >>>> URL: https://cgit.FreeBSD.org/src/commit/?id=43703bc489ec504b947b869045c492ed38c1a69c >>>> >>>> commit 43703bc489ec504b947b869045c492ed38c1a69c >>>> Author: John Baldwin >>>> AuthorDate: 2023-01-19 22:48:52 +0000 >>>> Commit: John Baldwin >>>> CommitDate: 2023-01-19 22:48:52 +0000 >>>> >>>> stdlib.h: Fix qsort_r compatibility with GCC 12. >>>> >>>> GCC 12 (unlike GCC 9) does not match a function argument passed to the >>>> old qsort_r() API (as is used in the qsort_r_compat test) to a >>>> function pointer type via __generic. It treats the function type as a >>>> distinct type from a function pointer. As a workaround, add a second >>>> definition of qsort_r for GCC 12 which uses the bare function type. >>> >>> As far as I can tell both versions of GCC behave the same. The >>> difference is whether __generic is using _Generic or >>> __builtin_choose_expr with __builtin_types_compatible_p, since function >>> and function pointer types are not compatible. Clang will take the >>> __has_extension path, but GCC will take the builtins path, and so Clang >>> works but GCC doesn’t. >>> >>> As a result of this change you’ve likely broken code that does >>> qsort_r(..., &f) as that will have the opposite problem. The right fix >>> is to force arg5 to decay, such as by (ab)using the comma operator with >>> __generic((0, arg5), ...). I guess that probably belongs in the >>> fallback implementation of __generic though, not here, which would give >>> the following real fix: >>> >>> diff --git a/sys/sys/cdefs.h b/sys/sys/cdefs.h >>> index 83ba7584e5b9..f7eff4768151 100644 >>> --- a/sys/sys/cdefs.h >>> +++ b/sys/sys/cdefs.h >>> @@ -312,6 +312,9 @@ >>> * __generic(). Unlike _Generic(), this macro can only distinguish >>> * between a single type, so it requires nested invocations to >>> * distinguish multiple cases. >>> + * >>> + * Note that the comma operator is used to force expr to decay in order to >>> + * match _Generic. >>> */ >>> >>> #if (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112L) || \ >>> @@ -321,7 +324,7 @@ >>> #elif __GNUC_PREREQ__(3, 1) && !defined(__cplusplus) >>> #define __generic(expr, t, yes, no) \ >>> __builtin_choose_expr( \ >>> - __builtin_types_compatible_p(__typeof(expr), t), yes, no) >>> + __builtin_types_compatible_p(__typeof((0, expr)), t), yes, no) >> >> With (expr) instead of expr, of course... > > And as for why GCC 9 works: > > It doesn’t. The tests just aren’t built because MK_CXX=no disables > MK_TESTS. GCC 12 only hits it because it’s new enough to be able to > build libc++ and not force MK_CXX=no. > > It would be nice to unpick that... Hmm, ok I thought I had managed to build this test with GCC 9 previously, but perhaps not. I will give the cdefs.h change a go locally though and see what happens. -- John Baldwin