bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
From: Paul Eggert <eggert@cs.ucla.edu>
To: Bruno Haible <bruno@clisp.org>
Cc: bug-gnulib@gnu.org, Alexandre Duret-Lutz <adl@lrde.epita.fr>
Subject: Re: clang++ 11 compilation issues
Date: Wed, 13 Jan 2021 16:37:58 -0800	[thread overview]
Message-ID: <1a11d0b0-36d5-cec2-c4c3-dc6003aa22d3@cs.ucla.edu> (raw)
In-Reply-To: <2634507.PNdPYx674J@omega>

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

On 1/12/21 12:19 PM, Bruno Haible wrote:
>> Those macros check for
>> __cpp_static_assert to assume something about _Static_assert, which
>> seems dubious.
> Paul can tell more about this one.

I agree it's dubious.

Also, looking over the current verify.h, it's a little complicated and I 
doubt whether the complexity is worth it nowadays. How about if we 
simplify the C++ case, by simply relying on __cpp_static_assert there? 
Although this could miss opportunities for generating diagnostics via 
older C++ compilers, I doubt whether they're worth the trouble any more.

Proposed Gnulib patch attached (I haven't installed it).

[-- Attachment #2: 0001-verify-rely-more-on-__cpp_static_assert.patch --]
[-- Type: text/x-patch, Size: 4765 bytes --]

From ce90a689fc388c4c612861054adcb09bd3658b1c Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Wed, 13 Jan 2021 15:46:33 -0800
Subject: [PATCH] verify: rely more on __cpp_static_assert

* lib/verify.h (_GL_HAVE__STATIC_ASSERT, _GL_HAVE__STATIC_ASSERT1):
Simplify for the C++ case, by relying only on __cpp_static_assert.
That should be good enough nowadays for C++.
(_GL_HAVE_STATIC_ASSERT_CXX11, _GL_HAVE_STATIC_ASSERT_CXX17):
Remove.  All uses replaced by simply checking __cpp_static_assert.
---
 ChangeLog    |  9 +++++++++
 lib/verify.h | 53 ++++++++++++----------------------------------------
 2 files changed, 21 insertions(+), 41 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 2123974c8..8991d6a35 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2021-01-13  Paul Eggert  <eggert@cs.ucla.edu>
+
+	verify: simplify static_assert configuration
+	* lib/verify.h (_GL_HAVE__STATIC_ASSERT, _GL_HAVE__STATIC_ASSERT1):
+	Do not define for C++.  This should be good enough nowadays,
+	since recent-enough C++ compilers have static_assert.
+	(_GL_HAVE_STATIC_ASSERT_CXX11, _GL_HAVE_STATIC_ASSERT_CXX17):
+	Remove.  All uses replaced by simply checking __cpp_static_assert.
+
 2021-01-13  Simon Josefsson  <simon@josefsson.org>
 
 	lib-msvc-compat: Update libtool usage recommendation.
diff --git a/lib/verify.h b/lib/verify.h
index a9e75890f..a62a47087 100644
--- a/lib/verify.h
+++ b/lib/verify.h
@@ -22,52 +22,23 @@
 
 
 /* Define _GL_HAVE__STATIC_ASSERT to 1 if _Static_assert (R, DIAGNOSTIC)
-   works as per C11.  This is supported by GCC 4.6.0 and later, in C
-   mode, and by clang (also in C++ mode).
+   works as per C11.  This is supported by GCC 4.6.0+ and by clang 4+.
 
    Define _GL_HAVE__STATIC_ASSERT1 to 1 if _Static_assert (R) works as
-   per C2X.  This is supported by GCC 9.1 and later, and by clang in
-   C++1z mode.
-
-   Define _GL_HAVE_STATIC_ASSERT_CXX11 if static_assert (R, DIAGNOSTIC)
-   works as per C++11.  This is supported by GCC 6.1 and later, and by
-   clang in C++11 mode.
-
-   Define _GL_HAVE_STATIC_ASSERT_CXX17 if static_assert (R) works as per
-   C++17.  This is supported by GCC 9.1 and later, and by clang in
-   C++1z mode.
+   per C2X.  This is supported by GCC 9.1+.
 
    Support compilers claiming conformance to the relevant standard,
    and also support GCC when not pedantic.  If we were willing to slow
    'configure' down we could also use it with other compilers, but
    since this affects only the quality of diagnostics, why bother?  */
-#ifndef __cplusplus
-# if (201112L <= __STDC_VERSION__ \
-      || (!defined __STRICT_ANSI__ \
-          && (4 < __GNUC__ + (6 <= __GNUC_MINOR__) || 4 <= __clang_major__)))
-#  define _GL_HAVE__STATIC_ASSERT 1
-# endif
-# if (202000L <= __STDC_VERSION__ \
-      || (!defined __STRICT_ANSI__ && 9 <= __GNUC__))
-#  define _GL_HAVE__STATIC_ASSERT1 1
-# endif
-#else
-# if 4 <= __clang_major__
-#  define _GL_HAVE__STATIC_ASSERT 1
-# endif
-# if 4 <= __clang_major__ && 201411 <= __cpp_static_assert
-#  define _GL_HAVE__STATIC_ASSERT1 1
-# endif
-# if 201103L <= __cplusplus \
-     || 6 <= __GNUC__ \
-     || (4 <= __clang_major__ && 200410 <= __cpp_static_assert)
-#  define _GL_HAVE_STATIC_ASSERT_CXX11 1
-# endif
-# if 201703L <= __cplusplus \
-     || 9 <= __GNUC__ \
-     || (4 <= __clang_major__ && 201411 <= __cpp_static_assert)
-#  define _GL_HAVE_STATIC_ASSERT_CXX17 1
-# endif
+#if (201112L <= __STDC_VERSION__ \
+     || (!defined __STRICT_ANSI__ \
+         && (4 < __GNUC__ + (6 <= __GNUC_MINOR__) || 4 <= __clang_major__)))
+# define _GL_HAVE__STATIC_ASSERT 1
+#endif
+#if (202000L <= __STDC_VERSION__ \
+     || (!defined __STRICT_ANSI__ && 9 <= __GNUC__))
+# define _GL_HAVE__STATIC_ASSERT1 1
 #endif
 
 /* FreeBSD 9.1 <sys/cdefs.h>, included by <stddef.h> and lots of other
@@ -234,7 +205,7 @@ template <int w>
    Unfortunately, unlike C11, this implementation must appear as an
    ordinary declaration, and cannot appear inside struct { ... }.  */
 
-#if defined _GL_HAVE_STATIC_ASSERT_CXX11
+#if 200410 <= __cpp_static_assert
 # define _GL_VERIFY(R, DIAGNOSTIC, ...) static_assert (R, DIAGNOSTIC)
 #elif defined _GL_HAVE__STATIC_ASSERT
 # define _GL_VERIFY(R, DIAGNOSTIC, ...) _Static_assert (R, DIAGNOSTIC)
@@ -250,7 +221,7 @@ template <int w>
 #  define _Static_assert(...) \
      _GL_VERIFY (__VA_ARGS__, "static assertion failed", -)
 # endif
-# if !defined _GL_HAVE_STATIC_ASSERT_CXX17 && !defined static_assert
+# if __cpp_static_assert < 201411 && !defined static_assert
 #  define static_assert _Static_assert /* C11 requires this #define.  */
 # endif
 #endif
-- 
2.27.0


  parent reply	other threads:[~2021-01-14  0:38 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-12 10:37 clang++ 11 compilation issues Alexandre Duret-Lutz
2021-01-12 18:23 ` Florian Weimer
2021-01-13 11:31   ` Alexandre Duret-Lutz
2021-01-12 20:19 ` Bruno Haible
2021-01-13 21:04   ` Jeffrey Walton
2021-01-15  8:55     ` different CFLAGS for gnulib code? Bruno Haible
2021-01-15  9:20       ` Alexandre Duret-Lutz
2021-01-15 11:11       ` Paul Eggert
2021-01-15 16:36         ` Darshit Shah
2021-01-15 11:17       ` Simon Josefsson via Gnulib discussion list
2021-01-15 16:08       ` Jim Meyering
2021-01-17 12:55       ` Pádraig Brady
2021-01-14  0:37   ` Paul Eggert [this message]
2021-01-14  1:21     ` clang++ 11 compilation issues Bruno Haible
2021-01-14  1:55       ` Paul Eggert
2021-01-14  2:09         ` Bruno Haible
2021-01-14 18:21   ` Alexandre Duret-Lutz

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

  List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib

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

  git send-email \
    --in-reply-to=1a11d0b0-36d5-cec2-c4c3-dc6003aa22d3@cs.ucla.edu \
    --to=eggert@cs.ucla.edu \
    --cc=adl@lrde.epita.fr \
    --cc=bruno@clisp.org \
    --cc=bug-gnulib@gnu.org \
    /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).