Re: minimum required -std=c++NN?

Christoph Badura <[email protected]> writes:

> While dealing with cross-builing -current w/gcc-12 on macOS I've noticed
> that we have different settings for HOST_CXXFLAGS/CXX_FLAGS in various
> parts of the source tree:
>
> src/external/mit/xorg/lib/gallium.old/Makefile:CXXFLAGS+=	-std=c++14
> src/external/mit/xorg/lib/gallium/Makefile:CXXFLAGS+=	-std=c++14
> src/external/apache2/llvm/Makefile.inc:HOST_CXXFLAGS+=	-std=c++14
> src/external/apache2/llvm/Makefile.inc:CXXFLAGS+=	-std=c++14
> src/external/gpl3/gcc/usr.bin/host-libcpp/Makefile:HOST_CXXFLAGS+=	-std=c++11
> src/tests/lib/libc/sync/Makefile:CXXFLAGS+= -std=c++11
> src/tests/libexec/ld.elf_so/helper_dso3/Makefile:CXXFLAGS+=	-std=c++11
> src/tools/gcc/Makefile:HOST_CXXFLAGS+=		-std=c++11
>
> I guess gallium, libc/sync and ld.elf_so aren't build as a tool.  But
> the compilers are
>
> Would it be desirable to set these to consistent values (i.e.
> -stdt=c++14)?  If so, should we centralize that in a variable in
> bsd.own.mk?

I would say no.  I know I'm a crank about this, but:

  (I will say that C++ is a language family (calling it a language is
  unhelpful in these discussions as there is no single specification).

  (I will say that C++11 and C++17 are "language family members" (LFM), because
  calling them languages is confusing to some people.)

  Often a program in one LFM is also a legitimate program in a higher
  LFM, and often it has the same semantics.

  Any particular compiler supports some set of LFMs, allows selecting
  one by --std= and further has a default, what you get without --std.

  Each program is written in a LFM, and needs to compiled as that LFM.
  It usually works to build it as a higher LFM.

So that leads to:

  Each program should probe for and pass --std=foo to match the declared
  LFM in that program's INSTALL or whatever, and may not assume what the
  default LFM is.  Unless maybe if it's simple C++03 and the same valid
  program in all higher LFMs.

  I find it unsurprising that there is a lot of c++11 and c++14.

> Also, while looking at the build logs I see during "dependall-gcc":
>
> src/tools/gcc/../../external/gpl3/gcc/dist/libcpp/lex.cc:1289:7: warning: use of the 'likely' attribute is a C++20 extension [-Wc++20-extensions]
> src/tools/gcc/../../external/gpl3/gcc/dist/libcpp/lex.cc:1289:7: warning: use of the 'likely' attribute is a C++20 extension [-Wc++20-extensions]
> src/tools/gcc/../../external/gpl3/gcc/dist/libcpp/lex.cc:1289:7: warning: use of the 'likely' attribute is a C++20 extension [-Wc++20-extensions]
> src/tools/gcc/../../external/gpl3/gcc/dist/libcpp/lex.cc:1289:7: warning: use of the 'likely' attribute is a C++20 extension [-Wc++20-extensions]
> src/external/gpl3/gcc/dist/libcpp/lex.cc:1289:7: warning: use of the 'likely' attribute is a C++20 extension [-Wc++20-extensions]
>
> Does that suggest we would want to set {HOST_,}CXXFLAGS to -std=c++20 for
> that file or all of gcc?  (I don't see these warning during the tools
> build of gcc.)

  C++20 is new, but that's how it is.  As for that file vs all of gcc,
  what does gcc's build instructions say?  If they don't, they are
  buggy.

  If it really needs C++20, that's a little surprising, and I
  wonder how the bootstrapping story goes, from a host compiler that is
  less bleeding edge.  Can the bootstrap gcc built with a host compiler
  do without?  Or does it not really need and they are ok with warnings,
  on purpose.  Again they should be documenting -- and maybe they are.