public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Matthias Kretz <m.kretz@gsi.de>
To: Alexandre Oliva <oliva@adacore.com>,
	Jonathan Wakely <jwakely@redhat.com>
Cc: <libstdc++@gcc.gnu.org>, <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] [libstdc++] add _GLIBCXX_CLANG to workaround predefined __clang__
Date: Fri, 31 May 2024 17:55:57 +0200	[thread overview]
Message-ID: <8316354.LvFx2qVVIh@centauriprime> (raw)
In-Reply-To: <ZlnjsiN8fhIAO2AX@zen.kayari.org>

[-- Attachment #1: Type: text/plain, Size: 2772 bytes --]

So __clang__ is turning into the next __GNUC__ ;)

In essence, inside libstdc++ code, __clang__ is going to mean Clang-compatible 
compiler and _GLIBCXX_CLANG then means it's the actual Clang compiler (or a 
vendor variant like Apple's). Would it make sense to adjust the Apple clang 
major version then so that it matches the LLVM major versions? (e.g. https://
stackoverflow.com/a/78014367)

More inline.

On Friday, 31 May 2024 16:50:26 GMT+2 Jonathan Wakely wrote:
> >diff --git a/libstdc++-v3/include/bits/c++config
> >b/libstdc++-v3/include/bits/c++config index b57e3f338e92a..6dca2d9467aa5
> >100644
> >--- a/libstdc++-v3/include/bits/c++config
> >+++ b/libstdc++-v3/include/bits/c++config
> >@@ -481,9 +481,20 @@ _GLIBCXX_END_NAMESPACE_VERSION
> >
> > // Define if compatibility should be provided for -mlong-double-64.
> > #undef _GLIBCXX_LONG_DOUBLE_COMPAT
> >
> >+// Use an alternate macro to test for clang, so as to provide an easy
> >+// workaround for systems (such as vxworks) whose headers require
> >+// __clang__ to be defined, even when compiling with GCC.
> >+#if !defined _GLIBCXX_CLANG && defined __clang__
> >+# define _GLIBCXX_CLANG __clang__
> >+// Turn -D_GLIBCXX_CLANG=0 into -U_GLIBCXX_CLANG, so that
> >+// _GLIBCXX_CLANG can be tested as defined, just like __clang__.
> >+#elif !_GLIBCXX_CLANG
> >+# undef _GLIBCXX_CLANG
> >+#endif
> >+

So passing -D__clang__=17 -D_GLIBCXX_CLANG=1 is possible? Should it be?

> >diff --git a/libstdc++-v3/include/experimental/bits/simd.h
> >b/libstdc++-v3/include/experimental/bits/simd.h index
> >7c52462571902..ea034138fd720 100644
> >--- a/libstdc++-v3/include/experimental/bits/simd.h
> >+++ b/libstdc++-v3/include/experimental/bits/simd.h
> >@@ -606,7 +606,7 @@ template <size_t _Bytes>
> >
> >     static_assert(_Bytes > 0);
> >     if constexpr (_Bytes == sizeof(int))
> >     
> >       return int();
> >
> >-  #ifdef __clang__
> >+  #ifdef _GLIBCXX_CLANG
> 
> I'd like to hear from Matthias to know he's OK with the simd changes.

Yes, LGTM. There's no maintained upstream copy of simd anymore. And all 
occurrences in the simd code are asking for the actual Clang compiler.

-Matthias


-- 
──────────────────────────────────────────────────────────────────────────
 Dr. Matthias Kretz                           https://mattkretz.github.io
 GSI Helmholtz Center for Heavy Ion Research               https://gsi.de
 std::simd
──────────────────────────────────────────────────────────────────────────

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  parent reply	other threads:[~2024-05-31 15:56 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-31 14:07 Alexandre Oliva
2024-05-31 14:50 ` Jonathan Wakely
2024-05-31 15:52   ` Alexandre Oliva
2024-05-31 17:43     ` [PATCH v2] " Alexandre Oliva
2024-06-01  8:21       ` Jonathan Wakely
2024-06-01 16:07         ` Jakub Jelinek
2024-06-05 19:33           ` Olivier Hainque
2024-06-06  2:08         ` [FYI] [PATCH v3] " Alexandre Oliva
2024-06-01  7:35     ` [PATCH] " Olivier Hainque
2024-06-01  8:18       ` Jonathan Wakely
2024-06-01  8:19     ` Jonathan Wakely
2024-06-07  4:43     ` [PATCH] [libstdc++] drop workaround for clang<=7 (was: [libstdc++] add _GLIBCXX_CLANG to workaround predefined __clang__) Alexandre Oliva
2024-06-07  8:42       ` Jonathan Wakely
2024-05-31 15:55   ` Matthias Kretz [this message]
2024-05-31 17:40     ` [PATCH] [libstdc++] add _GLIBCXX_CLANG to workaround predefined __clang__ Alexandre Oliva

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8316354.LvFx2qVVIh@centauriprime \
    --to=m.kretz@gsi.de \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jwakely@redhat.com \
    --cc=libstdc++@gcc.gnu.org \
    --cc=oliva@adacore.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).