From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) by sourceware.org (Postfix) with ESMTPS id 64B03386545E for ; Fri, 31 May 2024 15:52:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 64B03386545E Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=adacore.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 64B03386545E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::435 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1717170757; cv=none; b=m7HdmyImhrGPmWwP2i/bjoi8ZFcWMeprkYTnV60NqtzQqM6UAT8cLCoVD5jbnr+A6bPr+y2Fvo1s5NvcVbIBBzdi93kFbo9MIlgt//WQ2hk51ZuGi2Y77vwBa8QylluQlIcO1ikqACwyhgA6TYcQpjJw6clvKJy8ZaIZYuINq2g= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1717170757; c=relaxed/simple; bh=NJS4TdwyFtcpyUFE9c1g/XYFaZZHJgiR6jY5jyhu7JM=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=J97aewbaWtm5p/DwxTn7xywiUvg/iG5Fes1tSwUw/bNMfkPFcWqcmbrCd7qSTbdflfxJ1s8soC9vsp75j9k9/YyMG59j6R0xwYjmscuufOuZSWGAhxjsKJxsWXqGdeT7F/iA/HOtzIA0pO+14hPYMcOd2ypiHqFnUE9SGLJB8cQ= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pf1-x435.google.com with SMTP id d2e1a72fcca58-701b0b0be38so2074174b3a.0 for ; Fri, 31 May 2024 08:52:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore.com; s=google; t=1717170750; x=1717775550; darn=gcc.gnu.org; h=mime-version:user-agent:message-id:in-reply-to:date:references :organization:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=hJaBbxGITe3DMw5c3Mu3deiIJuqvqfPK1b3ha90/+to=; b=KciWCQ6qUTte0m48nyiNSV5nAKV9rNfIi56dR9K/j7H+uLgQ7ZeLyZCtNSh30GGDVS X3n4X0/IY3jiYpbjLT2d1wSUGByThCYsSMIkb8oddigjSCe1RNi5eVtK4l8UlceApzYG TXGj5Kih3oCiIErI+8tRpVHo6Nv+NK2fpUWCYGzgIbNXmm00N4GcRncn8rdYCuVRf+47 MwBD64t4Qa0YV8m6OCxhqV/Xl7YMrL3cVDz9gVwn6fWqJgu5rXWEdDHAErZ5OT+zskLG +bKg1BJqf3owGrPS7mOu8qUmu7D/BS4rXPKeNU2NGldxLw+RRDAQGwj2lBlwF4wR9f3K UBbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717170750; x=1717775550; h=mime-version:user-agent:message-id:in-reply-to:date:references :organization:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=hJaBbxGITe3DMw5c3Mu3deiIJuqvqfPK1b3ha90/+to=; b=CPP+3bc93/2odliMsQYKvbgdQx7c6z2TfnFzLyzUCie7Uu27pAo/Yn/OVdiodNWH9N Vyjkkur+fSKtmN7e+T/7gHBikFNR3CXfAgI4YgRmwe5VOTNOUGt4hl1LiCvx+SKTZM73 afeVqPwpQI9bLtblmWNDGA2RDsgIBE1PL7wOyeg/k4SnB4QSzr48NfBxKzNtxFGM7jsC CFO4PVyXeO9wd4B0oL/VTfqzE/+FX8dn4cknIo+fgPiHk2xzEwYgLUr6ZHS0RSAPDkVI YK8JcsDR3uVu+vdMIk0Wonx8xnzMOFYe7PqNvFE1hoeryEmvAnPRAHI1dDaWnqcZYSsj 3mSg== X-Forwarded-Encrypted: i=1; AJvYcCWkgVz77KNGpeKRpVvFL/BbgR7X2J6FoicI2tZ0YoIsLmEyfOCgcTu3M3KJyuGllwavK5YHM5zgC+9MOSFpxlKGivad+RkeIA== X-Gm-Message-State: AOJu0Yx/4ZWaYggvCz/8T3xLbd/rA1XaWiH3nDQ6dcDlU9OhkG3Rvhwy 42PTfw1wMb3rVZ0Xp0FzQiJeaevaAFpYNDHpLeBjw7tsPuSqylnC+tHDOE2vOg== X-Google-Smtp-Source: AGHT+IF4Oq095mA66VkN4FIYo0EO99OYvNTxIgd1b5Fy6M8D4NqrZaixqAxyTeRrn6RMZmPOH9Cuxg== X-Received: by 2002:a05:6a20:3c9f:b0:1b0:1ce1:e7b1 with SMTP id adf61e73a8af0-1b26f1adf31mr2781913637.20.1717170750186; Fri, 31 May 2024 08:52:30 -0700 (PDT) Received: from free.home ([2804:7f1:218b:1961:ef8:d680:5399:8b1a]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-70242b0518csm1589743b3a.147.2024.05.31.08.52.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 31 May 2024 08:52:29 -0700 (PDT) Received: from livre (livre.home [172.31.160.2]) by free.home (8.15.2/8.15.2) with ESMTPS id 44VFqC4n530299 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 31 May 2024 12:52:12 -0300 From: Alexandre Oliva To: Jonathan Wakely , hainque@adacore.com Cc: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org, Matthias Kretz Subject: Re: [PATCH] [libstdc++] add _GLIBCXX_CLANG to workaround predefined __clang__ Organization: Free thinker, does not speak for AdaCore References: Date: Fri, 31 May 2024 12:52:12 -0300 In-Reply-To: (Jonathan Wakely's message of "Fri, 31 May 2024 15:50:26 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.84 X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,WEIRD_QUOTING autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On May 31, 2024, Jonathan Wakely wrote: > On 31/05/24 11:07 -0300, Alexandre Oliva wrote: >> --- a/libstdc++-v3/include/pstl/pstl_config.h [...] >> -#if defined(__clang__) >> +#if defined(__GLIBCXX__) ? defined(_GLIBCXX_CLANG) : defined(__clang__) > This file is also imported from upstream, like Ryu and fast_float. Oh, yeah, I should have mentioned this one in the proposed commit message. The problem here was that it wasn't clear c++config would always be included, so I figured I'd better be conservative. > I don't think having a "spurious" definition of _PSTL_CLANG_VERSION > here actually matters. Yeah, no, it's the other macros guarded by __clang__ that I'm concerned about, and since the version macro could replace it, I went for it. > So either don't change this line at all, or just do a simple > s/__clang__/_GLIBCXX_CLANG/ If c++config can be counted on, I'd be happy to do that, but I couldn't tell that it could. > Does the vxworks toolchain need to support the PSTL headers? Maybe we can do without them. I really don't know. Olivier? > If not, we could just ignore this file, so the local changes don't > need to be re-applied when we import a new version of the header from > upstream. That sounds desirable indeed. This change is supposed to spare us (AdaCore) from precisely this sort of trouble, so it wouldn't be fair if it made this very kind of trouble for our upstream. >> --- a/libstdc++-v3/include/std/ranges >> -#ifdef __clang__ // LLVM-61763 workaround >> +#ifdef _GLIBCXX_CLANG // LLVM-61763 workaround > This one doesn't matter, since making these members public for a "fake > clang" doesn't really hurt anything. For consistency maybe it makes > sense to use _GLIBCXX_CLANG anyway. Yeah, uniformity would be good to simplify checking for no new appearances of __clang__, and to set the example to avoid accidental additions thereof. >> --- a/libstdc++-v3/include/std/variant >> -#if defined(__clang__) && __clang_major__ <= 7 >> +#if defined(_GLIBCXX_CLANG) && __clang_major__ <= 7 > I think we could drop this kluge entirely, clang 7 is old now, we > generally only support the most recent 3 or 4 clang versions. Fine with me, but I'd do that in a separate later patch, so that this goes in, and if it gets backported, it will cover this change, rather than miss it. Though, as you say, it doesn't matter much either way. -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive