Re: configure adds -std=gnu++11 to CXX variable

Re: configure adds -std=gnu++11 to CXX variable

[Florian Weimer]

* Paul Eggert:

> diff --git a/NEWS b/NEWS
> index 20dbc173..4ba8f3fe 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -16,6 +16,10 @@ GNU Autoconf NEWS - User visible changes.
>    C11 and later.  Programs can use AC_C_VARARRAYS and __STDC_NO_VLA__
>    to use VLAs if available.
>  
> +*** AC_PROG_CXX now prefers C++23, C++20, C++17, C++14 if available.
> +  Older code may need to be updated, as some older features of C++ are
> +  removed in later standards.
> +

Does this turn on experimental language modes by default?  That's
probably not what we want.

It would be better to have an option to raise the C++ mode to at least a
certain revision, and otherwise use the default.  The default is more
likely to be supported by system libraries, and it's a bit less likely
that programmers use experimental, known-to-be-buggy features (language
and library) by accident.

Thanks,
Florian

Re: configure adds -std=gnu++11 to CXX variable

[Paul Eggert]

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

On 2024-05-27 03:35, Florian Weimer wrote:
> Does this turn on experimental language modes by default?  That's
> probably not what we want.

What do C++ developers want these days? Autoconf should have a 
reasonable default, and C++11 is surely not a good default anymore.

It would be easy to discourage use of C++23 in the near future by using 
a stricter test, such as the attached patch (which I've not installed). 
Even GCC 14.1 fails the test in the new patch, so 'configure' will fall 
back on C++20. I hope GCC 15 will succeed on it but of course there's no 
guarantee. Although this new test covers a DR and is not specific to 
C++23 (and there seems to be some reluctance to implement the DR, I 
assume because it invalidates some older code), I expect any compiler 
passing both this and the __cplusplus>=202302 check would be good enough.

Would this patch be preferable to the current Autoconf master?


> It would be better to have an option to raise the C++ mode to at least a
> certain revision, and otherwise use the default.

That option is already available. For example, a builder who doesn't 
want C++23 can use './configure ac_cv_prog_cxx_cxx23=no', and a 
developer can discourage C++23 by putting ': ${ac_cv_prog_cxx_cxx23=no}' 
early in configure.ac.

As I mentioned earlier, I volunteered to document this sort of thing if 
Zack doesn't come up with something nicer soon.

[-- Attachment #2: 0001-Add-P1787R6-test-to-AC_PROG_CXX-C-23-check.patch --]
[-- Type: text/x-patch, Size: 1223 bytes --]

From b2f28ce66ea1618b50e14085059ce512d7245300 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Mon, 27 May 2024 11:56:06 -0700
Subject: [PATCH] Add P1787R6 test to AC_PROG_CXX C++23 check

* lib/autoconf/c.m4 (_AC_CXX_CXX23_TEST_PROGRAM): Check more
carefully for C++23 support, by checking for P1787R6, which even
GCC 14.1 and Clang 18.1 have not implemented.
---
 lib/autoconf/c.m4 | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/lib/autoconf/c.m4 b/lib/autoconf/c.m4
index a0a2b487..157dcb12 100644
--- a/lib/autoconf/c.m4
+++ b/lib/autoconf/c.m4
@@ -2856,6 +2856,19 @@ AC_DEFUN([_AC_CXX_CXX23_TEST_PROGRAM],
 # error "Compiler does not advertise C++23 conformance"
 #endif
 
+/* Check support for P1787R6: Declarations and where to find them
+   <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1787r6.html>.
+   See <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98939#c9>.  */
+template <typename T> struct A {
+  void f(int);
+  template <typename U> void f(U);
+};
+template <typename T> struct B {
+  template <typename T2> struct C { };
+};
+template <typename T, template <typename X> class TT = T::C> struct E { };
+E<B<int> > db;
+
 int
 main ()
 {
-- 
2.45.1

Re: configure adds -std=gnu++11 to CXX variable

[Jakub Jelinek]

On Mon, May 27, 2024 at 12:04:40PM -0700, Paul Eggert wrote:
> On 2024-05-27 03:35, Florian Weimer wrote:
> > Does this turn on experimental language modes by default?  That's
> > probably not what we want.
> 
> What do C++ developers want these days? Autoconf should have a reasonable
> default, and C++11 is surely not a good default anymore.

Maybe respect the carefully chosen compiler default (unless explicitly
overridden in configure.ac)?

	Jakub

Re: configure adds -std=gnu++11 to CXX variable

[Paul Eggert]

On 2024-05-27 12:18, Jakub Jelinek wrote:
> Maybe respect the carefully chosen compiler default (unless explicitly
> overridden in configure.ac)?

Autoconf gave up on that idea long ago, as we had bad experiences with 
compiler defaults being chosen for the convenience of distro maintainers 
rather than for application developers and builders. Compilers were 
still defaulting to K&R long after that made little sense. It was a bit 
like what we're still experiencing with _FILE_OFFSET_BITS defaulting to 
32 on x86 GNU/Linux.

Using the compiler default puts you at the mercy of the distro. It's not 
always wrong to do that - which is why developers and builders should 
have an option - but it's not always right either.

Re: configure adds -std=gnu++11 to CXX variable

[Jonathan Wakely]

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

On Tue, 28 May 2024, 02:51 Paul Eggert, <eggert@cs.ucla.edu> wrote:

> On 2024-05-27 12:18, Jakub Jelinek wrote:
> > Maybe respect the carefully chosen compiler default (unless explicitly
> > overridden in configure.ac)?
>
> Autoconf gave up on that idea long ago, as we had bad experiences with
> compiler defaults being chosen for the convenience of distro maintainers
> rather than for application developers and builders. Compilers were
> still defaulting to K&R long after that made little sense.



What has that got to do with C++ dialects?

GCC defaults to C++17 in versions that have good, stable C++17 support. So
does Clang these days. So what problem are you trying to solve for C++ here?


It was a bit
> like what we're still experiencing with _FILE_OFFSET_BITS defaulting to
> 32 on x86 GNU/Linux.
>
> Using the compiler default puts you at the mercy of the distro. It's not
> always wrong to do that - which is why developers and builders should
> have an option - but it's not always right either.
>

I am not aware of any distro ever changing the default -std setting for g++
or clang++. Are you attempting to solve a non-problem, but introducing new
ones?

Re: configure adds -std=gnu++11 to CXX variable

[Paul Eggert]

On 2024-05-28 01:20, Jonathan Wakely wrote:
> I am not aware of any distro ever changing the default -std setting for g++
> or clang++. Are you attempting to solve a non-problem, but introducing new
> ones?

If it's a non-problem for C++, why does Autoconf upgrade to C++11 when 
the default is C++98? Autoconf has done so since Autoconf 2.70 (2020), 
with nobody complaining as far as I know.

Was the Autoconf 2.70 change done so late that it had no practical 
effect, because no distro was defaulting to C++98 any more? If so, it 
sounds like Autoconf should go back to its 2.69 behavior and not mess 
with the C++ version as that's more likely to hurt than help.

For background on that Autoconf 2.70 change, see this 2013 thread:

https://lists.gnu.org/r/autoconf/2013-01/msg00016.html

Re: configure adds -std=gnu++11 to CXX variable

[Jason Merrill]

On Tue, May 28, 2024 at 10:36 AM Paul Eggert <eggert@cs.ucla.edu> wrote:
>
> On 2024-05-28 01:20, Jonathan Wakely wrote:
> > I am not aware of any distro ever changing the default -std setting for g++
> > or clang++. Are you attempting to solve a non-problem, but introducing new
> > ones?
>
> If it's a non-problem for C++, why does Autoconf upgrade to C++11 when
> the default is C++98? Autoconf has done so since Autoconf 2.70 (2020),
> with nobody complaining as far as I know.
>
> Was the Autoconf 2.70 change done so late that it had no practical
> effect, because no distro was defaulting to C++98 any more?

Yes, the GCC default changed from C++98 to C++14 in GCC 6 (2016).

> If so, it sounds like Autoconf should go back to its 2.69 behavior and not mess
> with the C++ version as that's more likely to hurt than help.

Not by default, certainly.

> For background on that Autoconf 2.70 change, see this 2013 thread:
>
> https://lists.gnu.org/r/autoconf/2013-01/msg00016.html
>

Re: configure adds -std=gnu++11 to CXX variable

[Jakub Jelinek]

On Tue, May 28, 2024 at 07:35:43AM -0700, Paul Eggert wrote:
> On 2024-05-28 01:20, Jonathan Wakely wrote:
> > I am not aware of any distro ever changing the default -std setting for g++
> > or clang++. Are you attempting to solve a non-problem, but introducing new
> > ones?
> 
> If it's a non-problem for C++, why does Autoconf upgrade to C++11 when the
> default is C++98? Autoconf has done so since Autoconf 2.70 (2020), with
> nobody complaining as far as I know.
> 
> Was the Autoconf 2.70 change done so late that it had no practical effect,
> because no distro was defaulting to C++98 any more? If so, it sounds like

That seems to be the case.
Dunno about clang++ defaults, but GCC defaults to
-std=gnu++98 (before GCC 6), or
-std=gnu++14 starting with GCC 6 (April 2016), or
-std=gnu++17 starting with GCC 11 (April 2021).
So, if autoconf in 2020 c++98 default to c++11, bet it didn't affect almost
anything.  RHEL 7 uses GCC 4.8, which partially but not fully supports c++11
(e.g. GCC which is written in C++11 these days can build using GCC 4.8.5
as oldest compiler, has to use some workarounds because the C++11 support
isn't finished there, the library side even further from that).  And trying
to enable C++11 on GCC 4.4 (RHEL 6) wouldn't be a good idea, too much was
missing there.
With C++20 in GCC 14, from core most of the features are in except that
modules still need further work, for library side at least cppreference
says it is complete too but I think the ABI hasn't been declared stable yet,
so C++17 is still the default, dunno if it will change in GCC 15 or not.

> Autoconf should go back to its 2.69 behavior and not mess with the C++
> version as that's more likely to hurt than help.

Yes.

> For background on that Autoconf 2.70 change, see this 2013 thread:
> 
> https://lists.gnu.org/r/autoconf/2013-01/msg00016.html

From what I can see, the change was proposed when the C++11 support wasn't
complete and didn't expect compilers will actually change their defaults
when the support is sufficiently stable.
Note, even for C GCC updates the default, -std=gnu99 default was changed to
-std=gnu11 in GCC 5 (April 2015) and -std=gnu17 in GCC 8 (May 2018).
-std=gnu23 support is still incomplete even in GCC 14.

	Jakub

Re: configure adds -std=gnu++11 to CXX variable

[Joseph Myers]

On Tue, 28 May 2024, Jakub Jelinek via Gcc wrote:

> -std=gnu23 support is still incomplete even in GCC 14.

It doesn't involve ABI issues, however, unlike C++, so using the option 
with GCC 14 is comparatively safe.  (It might run into a few aliasing bugs 
related to tag compatibility right now, but hopefully we'll have fixes for 
those backported for 14.2 as wrong-code issues.  And of course code 
testing __STDC_VERSION__ with GCC 14 or before needs to handle 
incompleteness of the implementation.)  Once we have #embed implemented 
(and so are substantially feature-complete, modulo the optional standard 
function attributes [[unsequenced]] and [[reproducible]]) it should be 
reasonable to change the default to -std=gnu23 (though we'll need to see 
what the distribution build impact from such a change is, especially 
regarding bool, true and false becoming keywords).

This certainly doesn't guarantee there won't be future C features with ABI 
issues from using an unstable version, however (if some C2y draft adds a 
new feature, then it's implemented, then the specification changes in an 
ABI-incompatible way - for an old example, consider how early C9x drafts 
had an enum-based definition of _Bool, which changed later to a built-in 
type like in C++, thereby changing from the size of int to a single byte).  
Indeed the API for some library functions in TS 18661-1 changed for the 
versions in C23, but that can be handled in glibc through symbol 
versioning (done some time ago for the totalorder functions, not yet done 
for fromfp functions).

-- 
Joseph S. Myers
josmyers@redhat.com

Re: configure adds -std=gnu++11 to CXX variable

[Paul Eggert]

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

On 2024-05-28 08:02, Jakub Jelinek wrote:
> even for C GCC updates the default

True, but C seems to be different, in that using a later-than-default 
-std=whatever is more likely to help than hurt, because the C 
standardization folks are more careful about compatibility. That's what 
I've been experiencing with -std=gnu23, for example, even though C23 has 
lots of changes from C17.


>> > Autoconf should go back to its 2.69 behavior and not mess with the C++
>> > version as that's more likely to hurt than help.
> 
> Yes.

OK, thanks, I installed the attached.

[-- Attachment #2: 0001-AC_PROG_CXX-no-longer-adjusts-C-language-version.patch --]
[-- Type: text/x-patch, Size: 17345 bytes --]

From 056518b94ecd487bcbefdb69046b3f52c4168222 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Tue, 28 May 2024 09:31:11 -0700
Subject: [PATCH] AC_PROG_CXX no longer adjusts C++ language version

* lib/autoconf/c.m4 (_AC_CXX_CXX98_TEST_GLOBALS)
(_AC_CXX_CXX98_TEST_MAIN, _AC_CXX_CXX11_TEST_GLOBALS)
(_AC_CXX_CXX11_TEST_MAIN, _AC_CXX_CXX98_TEST_PROGRAM)
(_AC_CXX_CXX11_TEST_PROGRAM, _AC_CXX_CXX14_TEST_PROGRAM)
(_AC_CXX_CXX17_TEST_PROGRAM, _AC_CXX_CXX20_TEST_PROGRAM)
(_AC_CXX_CXX23_TEST_PROGRAM, _AC_CXX_CXX98_OPTIONS)
(_AC_CXX_CXX11_OPTIONS, _AC_CXX_CXX14_OPTIONS)
(_AC_CXX_CXX17_OPTIONS, _AC_CXX_CXX20_OPTIONS)
(_AC_CXX_CXX23_OPTIONS, _AC_PROG_CXX_STDCXX_EDITION_TRY)
(_AC_PROG_CXX_STDCXX_EDITION_TRY): Remove.  All uses removed.
---
 NEWS              |  13 +-
 doc/autoconf.texi |  29 ---
 lib/autoconf/c.m4 | 439 ----------------------------------------------
 3 files changed, 5 insertions(+), 476 deletions(-)

diff --git a/NEWS b/NEWS
index 4ba8f3fe..521bbd3a 100644
--- a/NEWS
+++ b/NEWS
@@ -16,14 +16,11 @@ GNU Autoconf NEWS - User visible changes.
   C11 and later.  Programs can use AC_C_VARARRAYS and __STDC_NO_VLA__
   to use VLAs if available.
 
-*** AC_PROG_CXX now prefers C++23, C++20, C++17, C++14 if available.
-  Older code may need to be updated, as some older features of C++ are
-  removed in later standards.
-
-** Notable bug fixes
-
-*** AC_PROG_CXX no longer rejects C++20 compilers
-merely because C++20 is not upward-compatible with C++11.
+*** AC_PROG_CXX no longer attempts to switch to C++98 or C++11.
+  Instead, it uses the compiler's default, which you can override
+  by configuring with something like CXX='g++ -std=gnu++11'.
+  This reverts to Autoconf 2.69 behavior, and also fixes a bug where
+  AC_PROG_CXX rejected C++20 compilers.
 
 * Noteworthy changes in release 2.72 (2023-12-22) [release]
 
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 37e0ae01..c36eefdb 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -7821,33 +7821,6 @@ where @var{options} are the appropriate set of options to use by
 default.  (It is important to use this construct rather than a normal
 assignment, so that @code{CXXFLAGS} can still be overridden by the
 person building the package.  @xref{Preset Output Variables}.)
-
-If necessary, options are added to @code{CXX} to enable support for
-ISO Standard C++ features with extensions, preferring the newest edition
-of the C++ standard that is supported.  Currently the newest edition
-Autoconf knows how to detect support for is C++23.  After calling
-this macro, you can check whether the C++ compiler has been set to
-accept standard C++ by inspecting the shell variable @code{ac_prog_cxx_stdcxx}.
-Its value will be @samp{cxx23}, @samp{cxx20}, @samp{cxx17},
-@samp{cxx14}, @samp{cxx11} or @samp{cxx98},
-if the C++ compiler has been set to use the corresponding edition of the
-C++ standard, and @samp{no} if the compiler does not support compiling
-standard C++ at all.
-
-The tests for standard conformance are not comprehensive.  They test
-the value of @code{__cplusplus} and a representative sample of the
-language features added in each version of the C++ standard.  They
-do not test the C++ standard library, because this can be extremely
-slow, and because the C++ compiler might be generating code for a
-``freestanding environment'' (in which most of the C++ standard library
-is optional).  If you need to know whether a particular C++ standard
-header exists, use @code{AC_CHECK_HEADER}.
-
-None of the options that may be added to @code{CXX} by this macro
-enable @emph{strict} conformance to the C++ standard.  In particular,
-system-specific extensions are not disabled.  (For example, for GNU
-C++, the @option{-std=gnu++@var{nn}} options may be used, but not the
-@option{-std=c++@var{nn}} options.)
 @end defmac
 
 @defmac AC_PROG_CXXCPP
@@ -21715,8 +21688,6 @@ standard.  K&R C compilers are no longer of practical interest, though,
 and Autoconf assumes at least C89, the first C standard,
 which is sometimes called ``C90'' due to a delay in standardization.
 C has since gone through the standards C99, C11, C17, and C23, and
-C++ has evolved in a similar way, with the standards
-C++98, C++11, C++14, C++17, C++20, and C++23.
 Autoconf is compatible with all these standards.
 
 Program portability is a huge topic, and this section can only briefly
diff --git a/lib/autoconf/c.m4 b/lib/autoconf/c.m4
index a0a2b487..456a6ba7 100644
--- a/lib/autoconf/c.m4
+++ b/lib/autoconf/c.m4
@@ -719,7 +719,6 @@ else
   GXX=
 fi
 _AC_PROG_CXX_G
-_AC_PROG_CXX_STDCXX_EDITION
 AC_LANG_POP(C++)dnl
 ])# AC_PROG_CXX
 
@@ -2542,441 +2541,3 @@ AC_DEFUN([_AC_OPENMP_SAFE_WD],
     [AC@&t@_OPENMP clobbers files named 'mp' and 'penmp'.
      Aborting configure because one of these files already exists.]))
 fi])
-
-
-
-# ---------------------------------- #
-# 4b. C++ compiler characteristics.  #
-# ---------------------------------- #
-
-# See the long comment at the beginning of section 4a for rationale
-# for these macros, and constraints on how the test programs should
-# be written.
-#
-# The C++98 freestanding headers are:
-#     <cstdarg> <cstddef> <cstdlib> <exception> <limits> <new> <typeinfo>
-# C++11 adds:
-#    <atomic> <cfloat> <ciso646> <climits> <cstdalign> <cstdbool>
-#    <cstdint> <initializer_list> <type_traits>
-#
-# No other headers can safely be included.  Therefore, almost no C++
-# standard library features are tested for.  Use AC_CHECK_HEADER, etc.
-# if you need that.
-
-AC_DEFUN([_AC_CXX_CXX98_TEST_GLOBALS],
-[m4_divert_text([INIT_PREPARE],
-[[# Test code for whether the C++ compiler supports C++98 (global declarations)
-ac_cxx_conftest_cxx98_globals='
-// Does the compiler advertise C++98 conformance?
-#if !defined __cplusplus || __cplusplus < 199711L
-# error "Compiler does not advertise C++98 conformance"
-#endif
-
-// These inclusions are to reject old compilers that
-// lack the unsuffixed header files.
-#include <cstdlib>
-#include <exception>
-
-// <cassert> and <cstring> are *not* freestanding headers in C++98.
-extern void assert (int);
-namespace std {
-  extern int strcmp (const char *, const char *);
-}
-
-// Namespaces, exceptions, and templates were all added after "C++ 2.0".
-using std::exception;
-using std::strcmp;
-
-namespace {
-
-void test_exception_syntax()
-{
-  try {
-    throw "test";
-  } catch (const char *s) {
-    // Extra parentheses suppress a warning when building autoconf itself,
-    // due to lint rules shared with more typical C programs.
-    assert (!(strcmp) (s, "test"));
-  }
-}
-
-template <typename T> struct test_template
-{
-  T const val;
-  explicit test_template(T t) : val(t) {}
-  template <typename U> T add(U u) { return static_cast<T>(u) + val; }
-};
-
-} // anonymous namespace
-'
-]])])
-
-AC_DEFUN([_AC_CXX_CXX98_TEST_MAIN],
-[m4_divert_text([INIT_PREPARE],
-[[# Test code for whether the C++ compiler supports C++98 (body of main)
-ac_cxx_conftest_cxx98_main='
-  assert (argc);
-  assert (! argv[0]);
-{
-  test_exception_syntax ();
-  test_template<double> tt (2.0);
-  assert (tt.add (4) == 6.0);
-  assert (true && !false);
-}
-'
-]])])
-
-AC_DEFUN([_AC_CXX_CXX11_TEST_GLOBALS],
-[m4_divert_text([INIT_PREPARE],
-[[# Test code for whether the C++ compiler supports C++11 (global declarations)
-ac_cxx_conftest_cxx11_globals='
-// Does the compiler advertise C++ 2011 conformance?
-#if !defined __cplusplus || __cplusplus < 201103L
-# error "Compiler does not advertise C++11 conformance"
-#endif
-
-namespace cxx11test
-{
-  constexpr int get_val() { return 20; }
-
-  struct testinit
-  {
-    int i;
-    double d;
-  };
-
-  class delegate
-  {
-  public:
-    delegate(int n) : n(n) {}
-    delegate(): delegate(2354) {}
-
-    virtual int getval() { return this->n; };
-  protected:
-    int n;
-  };
-
-  class overridden : public delegate
-  {
-  public:
-    overridden(int n): delegate(n) {}
-    virtual int getval() override final { return this->n * 2; }
-  };
-
-  class nocopy
-  {
-  public:
-    nocopy(int i): i(i) {}
-    nocopy() = default;
-    nocopy(const nocopy&) = delete;
-    nocopy & operator=(const nocopy&) = delete;
-  private:
-    int i;
-  };
-
-  // for testing lambda expressions
-  template <typename Ret, typename Fn> Ret eval(Fn f, Ret v)
-  {
-    return f(v);
-  }
-
-  // for testing variadic templates and trailing return types
-  template <typename V> auto sum(V first) -> V
-  {
-    return first;
-  }
-  template <typename V, typename... Args> auto sum(V first, Args... rest) -> V
-  {
-    return first + sum(rest...);
-  }
-}
-'
-]])])
-
-AC_DEFUN([_AC_CXX_CXX11_TEST_MAIN],
-[m4_divert_text([INIT_PREPARE],
-[[# Test code for whether the C++ compiler supports C++11 (body of main)
-ac_cxx_conftest_cxx11_main='
-{
-  // Test auto and decltype
-  auto a1 = 6538;
-  auto a2 = 48573953.4;
-  auto a3 = "String literal";
-
-  int total = 0;
-  for (auto i = a3; *i; ++i) { total += *i; }
-
-  decltype(a2) a4 = 34895.034;
-}
-{
-  // Test constexpr
-  short sa[cxx11test::get_val()] = { 0 };
-}
-{
-  // Test initializer lists
-  cxx11test::testinit il = { 4323, 435234.23544 };
-}
-{
-  // Test range-based for
-  int array[] = {9, 7, 13, 15, 4, 18, 12, 10, 5, 3,
-                 14, 19, 17, 8, 6, 20, 16, 2, 11, 1};
-  for (auto &x : array) { x += 23; }
-}
-{
-  // Test lambda expressions
-  using cxx11test::eval;
-  assert (eval ([](int x) { return x*2; }, 21) == 42);
-  double d = 2.0;
-  assert (eval ([&](double x) { return d += x; }, 3.0) == 5.0);
-  assert (d == 5.0);
-  assert (eval ([=](double x) mutable { return d += x; }, 4.0) == 9.0);
-  assert (d == 5.0);
-}
-{
-  // Test use of variadic templates
-  using cxx11test::sum;
-  auto a = sum(1);
-  auto b = sum(1, 2);
-  auto c = sum(1.0, 2.0, 3.0);
-}
-{
-  // Test constructor delegation
-  cxx11test::delegate d1;
-  cxx11test::delegate d2();
-  cxx11test::delegate d3(45);
-}
-{
-  // Test override and final
-  cxx11test::overridden o1(55464);
-}
-{
-  // Test nullptr
-  char *c = nullptr;
-}
-{
-  // Test template brackets
-  test_template<::test_template<int>> v(test_template<int>(12));
-}
-{
-  // Unicode literals.  Do not test u8"..." as C++20 would reject it.
-  char16_t const *utf16 = u"UTF-8 string \u2500";
-  char32_t const *utf32 = U"UTF-32 string \u2500";
-}
-'
-]])])
-
-AC_DEFUN([_AC_CXX_CXX98_TEST_PROGRAM],
-[AC_REQUIRE([_AC_CXX_CXX98_TEST_GLOBALS])dnl
-AC_REQUIRE([_AC_CXX_CXX98_TEST_MAIN])dnl
-m4_divert_text([INIT_PREPARE],
-[[# Test code for whether the C compiler supports C++98 (complete).
-ac_cxx_conftest_cxx98_program="${ac_cxx_conftest_cxx98_globals}
-int
-main (int argc, char **argv)
-{
-  int ok = 0;
-  ${ac_cxx_conftest_cxx98_main}
-  return ok;
-}
-"
-]])])
-
-AC_DEFUN([_AC_CXX_CXX11_TEST_PROGRAM],
-[AC_REQUIRE([_AC_CXX_CXX98_TEST_GLOBALS])dnl
-AC_REQUIRE([_AC_CXX_CXX98_TEST_MAIN])dnl
-AC_REQUIRE([_AC_CXX_CXX11_TEST_GLOBALS])dnl
-AC_REQUIRE([_AC_CXX_CXX11_TEST_MAIN])dnl
-m4_divert_text([INIT_PREPARE],
-[[# Test code for whether the C compiler supports C++11 (complete).
-ac_cxx_conftest_cxx11_program="${ac_cxx_conftest_cxx98_globals}
-${ac_cxx_conftest_cxx11_globals}
-
-int
-main (int argc, char **argv)
-{
-  int ok = 0;
-  ${ac_cxx_conftest_cxx98_main}
-  ${ac_cxx_conftest_cxx11_main}
-  return ok;
-}
-"
-]])])
-
-AC_DEFUN([_AC_CXX_CXX14_TEST_PROGRAM],
-[m4_divert_text([INIT_PREPARE],
-[[ac_cxx_conftest_cxx14_program='
-#if __cplusplus < 201402
-# error "Compiler does not advertise C++14 conformance"
-#endif
-
-int
-main ()
-{
-  auto floating_point_literal_with_single_quotes = 0.123'\''456;
-}
-'
-]])])
-
-AC_DEFUN([_AC_CXX_CXX17_TEST_PROGRAM],
-[m4_divert_text([INIT_PREPARE],
-[[ac_cxx_conftest_cxx17_program='
-#if __cplusplus < 201707
-# error "Compiler does not advertise C++17 conformance"
-#endif
-
-int
-main ()
-{
-  auto u8_expression_with_u8_character_literals = u8'\''x'\'' == u8'\''x'\'';
-}
-'
-]])])
-
-AC_DEFUN([_AC_CXX_CXX20_TEST_PROGRAM],
-[m4_divert_text([INIT_PREPARE],
-[[ac_cxx_conftest_cxx20_program='
-#if __cplusplus < 202002
-# error "Compiler does not advertise C++20 conformance"
-#endif
-
-#include <compare>
-
-int
-main ()
-{
-  auto expression_with_three_way_comparison = 1 <=> 2;
-}
-'
-]])])
-
-AC_DEFUN([_AC_CXX_CXX23_TEST_PROGRAM],
-[m4_divert_text([INIT_PREPARE],
-[[ac_cxx_conftest_cxx23_program='
-#if __cplusplus < 202302
-# error "Compiler does not advertise C++23 conformance"
-#endif
-
-int
-main ()
-{
-  auto expression_with_signed_size_literal = -1z < 0;
-}
-'
-]])])
-
-# _AC_CXX_CXX98_OPTIONS
-# ---------------------
-# Whitespace-separated list of options that might put the C++ compiler
-# into a mode conforming to ISO C++ 1998 with extensions.  Do not try
-# "strictly conforming" modes (e.g. gcc's -std=c++98); they break some
-# systems' header files.  If more than one option is needed, put
-# shell quotes around the group.
-#
-# GCC           -std=gnu++98
-# Intel ICC     -std=c++98
-#   Note: because -std=c++98 puts GCC in strictly conforming mode,
-#   this option must be tested *after* -std=gnu++98.
-# IBM XL C      -qlanglvl=extended
-# HP aC++       -AA
-# Solaris       N/A (default)
-# Tru64         N/A (default, but -std gnu could be used)
-m4_define([_AC_CXX_CXX98_OPTIONS], [
-    -std=gnu++98
-    -std=c++98
-    -qlanglvl=extended
-    -AA
-])
-
-# _AC_CXX_CXX11_OPTIONS
-# ---------------------
-# Whitespace-separated list of options that might put the C++ compiler
-# into a mode conforming to ISO C++ 2011 with extensions.  Do not try
-# "strictly conforming" modes (e.g. gcc's -std=c++11); they break some
-# systems' header files.  If more than one option is needed, put
-# shell quotes around the group.
-#
-# GCC           -std=gnu++11, -std=gnu++0x
-# Intel ICC     -std=c++11, -std=c++0x
-#   Note: because -std=c++11 puts GCC in strictly conforming mode,
-#   these options must be tested *after* -std=gnu++11.
-# IBM XL C      -qlanglvl=extended0x (pre-V12.1)
-# HP aC++       -AA
-# Solaris       N/A (no support)
-# Tru64         N/A (no support)
-m4_define([_AC_CXX_CXX11_OPTIONS], [
-    -std=gnu++11
-    -std=gnu++0x
-    -std=c++11
-    -std=c++0x
-    -qlanglvl=extended0x
-    -AA
-])
-
-# Similarly for C++14, C++17, C++20, C++23,
-# where -std=gnu++XX should be good enough.
-m4_define([_AC_CXX_CXX14_OPTIONS], [-std=gnu++14])
-m4_define([_AC_CXX_CXX17_OPTIONS], [-std=gnu++17])
-m4_define([_AC_CXX_CXX20_OPTIONS], [-std=gnu++20])
-m4_define([_AC_CXX_CXX23_OPTIONS], [-std=gnu++23])
-
-# _AC_PROG_CXX_STDCXX_EDITION_TRY(EDITION)
-# ----------------------------------------
-# Subroutine of _AC_PROG_CXX_STDCXX_EDITION.  Not to be called directly.
-#
-# Check whether the C++ compiler accepts features of EDITION of the
-# C++ standard.  EDITION should be a two-digit year (e.g. 98, 11).
-# (FIXME: Switch to four-digit years for futureproofing.)
-# This is done by compiling the test program defined by
-# _AC_C_CXX{EDITION}_TEST_PROGRAM, first with no additional
-# command-line options, and then with each of the options
-# in the space-separated list defined by _AC_C_CXX{EDITION}_OPTIONS.
-#
-# If we find a way to make the test program compile, set cache variable
-# ac_cv_prog_cxx_cxxEDITION to the options required (if any), and add those
-# options to $CXX.  Set shell variable ac_prog_cxx_stdcxx to 'cxxEDITION',
-# and set shell variable ac_cv_prog_cxx_stdcxx to the options required.
-# (Neither of these variables is AC_SUBSTed.  ac_cv_prog_cxx_stdcxx used
-# to be a cache variable and is preserved with this name for backward
-# compatibility.)  Otherwise, ac_cv_prog_cxx_cxxEDITION is set to 'no'
-# and the other variables are not changed.
-#
-# If ac_prog_cxx_stdcxx is already set to a value other than 'no',
-# the shell code produced by this macro does nothing.  This is so
-# _AC_PROG_CXX_STDCXX_EDITION can use m4_map to iterate through
-# all the editions.
-AC_DEFUN([_AC_PROG_CXX_STDCXX_EDITION_TRY],
-[AC_LANG_ASSERT([C++])]dnl
-[AC_REQUIRE([_AC_CXX_CXX$1_TEST_PROGRAM])]dnl
-[AS_IF([test x$ac_prog_cxx_stdcxx = xno],
-[AC_MSG_CHECKING([for $CXX option to enable C++$1 features])
-AC_CACHE_VAL(ac_cv_prog_cxx_cxx$1,
-[ac_cv_prog_cxx_cxx$1=no
-ac_save_CXX=$CXX
-AC_LANG_CONFTEST([AC_LANG_DEFINES_PROVIDED][$][ac_cxx_conftest_cxx$1_program])
-for ac_arg in '' m4_normalize(m4_defn([_AC_CXX_CXX$1_OPTIONS]))
-do
-  CXX="$ac_save_CXX $ac_arg"
-  _AC_COMPILE_IFELSE([], [ac_cv_prog_cxx_cxx$1=$ac_arg])
-  test "x$ac_cv_prog_cxx_cxx$1" != "xno" && break
-done
-rm -f conftest.$ac_ext
-CXX=$ac_save_CXX])
-AS_IF([test "x$ac_cv_prog_cxx_cxx$1" = xno],
-  [AC_MSG_RESULT([unsupported])],
-  [AS_IF([test "x$ac_cv_prog_cxx_cxx$1" = x],
-    [AC_MSG_RESULT([none needed])],
-    [AC_MSG_RESULT([$ac_cv_prog_cxx_cxx$1])
-     CXX="$CXX $ac_cv_prog_cxx_cxx$1"])
-  ac_cv_prog_cxx_stdcxx=$ac_cv_prog_cxx_cxx$1
-  ac_prog_cxx_stdcxx=cxx$1])])
-])
-
-# _AC_PROG_CXX_STDCXX_EDITION
-# ---------------------------
-# Detect the most recent edition of the ISO C++ standard that is
-# supported by the C++ compiler.  Add command-line options to $CXX,
-# if necessary, to enable support for this edition.  Set the shell
-# variable ac_prog_cxx_stdcxx to indicate the edition.
-AC_DEFUN([_AC_PROG_CXX_STDCXX_EDITION],
-[ac_prog_cxx_stdcxx=no
-m4_map([_AC_PROG_CXX_STDCXX_EDITION_TRY], [23, 20, 17, 14, 11, 98])])
-- 
2.43.0

Re: configure adds -std=gnu++11 to CXX variable

[Jason Merrill]

On Tue, May 28, 2024 at 12:49 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
>
> On 2024-05-28 08:02, Jakub Jelinek wrote:
> > even for C GCC updates the default
>
> True, but C seems to be different, in that using a later-than-default
> -std=whatever is more likely to help than hurt, because the C
> standardization folks are more careful about compatibility. That's what
> I've been experiencing with -std=gnu23, for example, even though C23 has
> lots of changes from C17.
>
>
> >> > Autoconf should go back to its 2.69 behavior and not mess with the C++
> >> > version as that's more likely to hurt than help.
> >
> > Yes.
>
> OK, thanks, I installed the attached.

Thanks, though I don't think all that code needs to go;
AC_PROG_CXX_STDCXX_EDITION_TRY still looks useful for a project that
relies on features from a particular standard.  We just don't want
AC_PROG_CXX to invoke it.

Jason

Re: configure adds -std=gnu++11 to CXX variable

[Paul Eggert]

On 5/28/24 11:27, Jason Merrill wrote:
> AC_PROG_CXX_STDCXX_EDITION_TRY still looks useful for a project that
> relies on features from a particular standard.

It's called "_AC_PROG_CXX_STDCXX_EDITION_TRY" with a leading underscore, 
which means it's private to Autoconf and apps shouldn't (and I think 
don't) use it.

If we want to publish that macro without a leading underscore we can 
bring back the code and add something to the manual.

Re: configure adds -std=gnu++11 to CXX variable

[Tom Tromey]

>>>>> "Jason" == Jason Merrill <jason@redhat.com> writes:

Jason> Thanks, though I don't think all that code needs to go;
Jason> AC_PROG_CXX_STDCXX_EDITION_TRY still looks useful for a project that
Jason> relies on features from a particular standard.  We just don't want
Jason> AC_PROG_CXX to invoke it.

I didn't read the macro but there's also config/ax_cxx_compile_stdcxx.m4.
gdb uses this to make sure C++17 is available.

Tom

Re: configure adds -std=gnu++11 to CXX variable

[Jason Merrill]

On Wed, May 29, 2024 at 1:34 PM Tom Tromey <tom@tromey.com> wrote:
> >>>>> "Jason" == Jason Merrill <jason@redhat.com> writes:
>
> Jason> Thanks, though I don't think all that code needs to go;
> Jason> AC_PROG_CXX_STDCXX_EDITION_TRY still looks useful for a project that
> Jason> relies on features from a particular standard.  We just don't want
> Jason> AC_PROG_CXX to invoke it.
>
> I didn't read the macro but there's also config/ax_cxx_compile_stdcxx.m4.
> gdb uses this to make sure C++17 is available.

Good point, that's what GCC uses as well.

Jason

Re: configure adds -std=gnu++11 to CXX variable

[Florian Weimer]

* Paul Eggert:

> On 2024-05-27 03:35, Florian Weimer wrote:
>> Does this turn on experimental language modes by default?  That's
>> probably not what we want.
>
> What do C++ developers want these days? Autoconf should have a
> reasonable default, and C++11 is surely not a good default anymore.

It's still a good default for GCC 5.

GCC developers will correct me, but I think the default C++ dialect is
updated to a newer version once the implementation is reasonably
complete and bugs have been ironed out.

This is different from the C front end, where it took close to 40 years
(from the introduction of void * into C) to activate type checking for
pointer types by default.

>> It would be better to have an option to raise the C++ mode to at least a
>> certain revision, and otherwise use the default.
>
> That option is already available. For example, a builder who doesn't
> want C++23 can use './configure ac_cv_prog_cxx_cxx23=no', and a
> developer can discourage C++23 by putting ':
> ${ac_cv_prog_cxx_cxx23=no}' early in configure.ac.

But that is not the same thing.  If a project uses C++14 constructs,
wouldn't it make sense to tell configure to try to get (likely
experimental) support for it if the compiler does not enable C++14 by
default?  And if the system is already at C++17, leave it at that?

Setting C++14 unconditionally could be incompatible with used system
libraries, which assume C++17 support because the distribution is aware
that the system compiler supports C++17.

Thanks,
Florian

Re: configure adds -std=gnu++11 to CXX variable

[Jonathan Wakely]

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

On Tue, 28 May 2024, 07:24 Florian Weimer via Gcc, <gcc@gcc.gnu.org> wrote:

> * Paul Eggert:
>
> > On 2024-05-27 03:35, Florian Weimer wrote:
> >> Does this turn on experimental language modes by default?  That's
> >> probably not what we want.
> >
> > What do C++ developers want these days? Autoconf should have a
> > reasonable default, and C++11 is surely not a good default anymore.
>
> It's still a good default for GCC 5.
>
> GCC developers will correct me, but I think the default C++ dialect is
> updated to a newer version once the implementation is reasonably
> complete and bugs have been ironed out.
>

Correct.

Please DO NOT default to C++20 for any current version of GCC, that's an
ABI disaster waiting to happen. There is no version of GCC with stable
C++20 support.



> This is different from the C front end, where it took close to 40 years
> (from the introduction of void * into C) to activate type checking for
> pointer types by default.
>
> >> It would be better to have an option to raise the C++ mode to at least a
> >> certain revision, and otherwise use the default.
> >
> > That option is already available. For example, a builder who doesn't
> > want C++23 can use './configure ac_cv_prog_cxx_cxx23=no', and a
> > developer can discourage C++23 by putting ':
> > ${ac_cv_prog_cxx_cxx23=no}' early in configure.ac.
>

It should not be opt out.

But if you make this change I'll very loudly suggest that everybody use
that in every autoconf-based C++ program. Then you'll probably need some
other solution in 5 years to workaround the fact that that option is
ubiquitous and needs to be ignored or overridden because people want C++20
to be used




> But that is not the same thing.  If a project uses C++14 constructs,
> wouldn't it make sense to tell configure to try to get (likely
> experimental) support for it if the compiler does not enable C++14 by
> default?  And if the system is already at C++17, leave it at that?
>
> Setting C++14 unconditionally could be incompatible with used system
> libraries, which assume C++17 support because the distribution is aware
> that the system compiler supports C++17.
>
> Thanks,
> Florian
>
>