On Fri, 15 May 2020 at 23:54, Jason Merrill via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> On 5/15/20 2:21 PM, Richard Biener wrote:
> > On May 15, 2020 7:30:38 PM GMT+02:00, Jason Merrill <ja...@redhat.com>
> > wrote:
> >> On Fri, May 15, 2020 at 3:15 AM Richard Biener
> >> <richard.guent...@gmail.com>
> >> wrote:
> >>
> >>>> +# When bootstrapping with GCC, build stage 1 in C++11 mode to
> >> ensure
> >>> that a
> >>>> +# C++11 compiler can still start the bootstrap.
> >>>> if test "$enable_bootstrap:$GXX" = "yes:yes"; then
> >>>> + CXX="$CXX -std=gnu++11"
> >>>
> >>> So I just spotted this - since we're requiring a ISO C++11 compiler
> >>> shouldn't
> >>> we build stage1 with -std=c++11 rather than gnu++11 (whatever the detailed
> >>> differences are here)? Also not sure what level of -pedantic we'd need to
> >>> avoid GNU extensions even with -std=c++11. Of course there are (I hope)
> >>> a lot less GNU extensions for C++ than there were for C and hopefully
> >>> no extra in gnu++11 compared to gnu++98 which we checked previously.
>
> Building stage 1 with -std=c++11 -pedantic-errors works with 8.3.1, but
> fails pretty badly with 4.8.5,
>
> >> When we first moved to C++ I tried using -std=c++98, but there were too
> >> many places where we were assuming that if we're building with GCC, we can
> >> use GNU C extensions.
> >>
> >> I'll see if that's still a problem for -std=c++11.
>
> It doesn't seem to be, so I've made that change.
>
> >>> There also does not seem to be a configure check which may present
> >>> users with a more useful error message than later cryptic fail of build?
> >>> I suppose we cannot simply check __cplusplus for this, can we? Do
> >>> other common host compilers need additional options to enable C++11?
> >>
> >> Good point, I'll add that.
>
> This patch uses a test from the autoconf archive to add any needed
> flags. Tested with GCC 4.8.5 and clang 3.4.2 (with the above stage 1
> -std=c++11 disabled).
>
> >>> Should we try to second guess such flags via configury? For example
> >>> GCC 4.8 defaults to -std=gnu++98 and the above only seems to apply
> >>> to the bootstrap case so GCC 4.8 cannot be used to build cross
> >> compilers
> >>> without adjusting CC and CXX?
> >>
> >> Older GCC is still GCC and will get the flag automatically.
> >
> > But yes:yes suggests that when building a cross compiler this doesn't apply?
>
> True, but the new test should cover that case.
>
> OK for trunk?
Hi,
After recent commits on trunk that make use of c++11 features, I'm now
unable to build cross-compilers (x86_64 host, arm/aarch64 targets)
/gcc/tree-ssa-math-opts.c:124:32: warning: non-static data member
initializers only available with -std=c++11 or -std=gnu++11
basic_block bb = basic_block();
I am using gcc-5.4.0, and this happens because although gcc/configure correctly:
checking whether g++ supports C++11 features by default... no
checking whether g++ supports C++11 features with -std=gnu++11... yes
the actual CXXFLAGS used during the build are set by the toplevel Makefile,
which does not include -std=c++11 or -std=gnu++11
IIUC this patch forces c++11 when during bootstrap to make sure that
even with a compiler with more recent defaults, we can still build
with as low as c++11 requirements.
It is not meant to raise the default level of the build compiler. So
we probably want a proper fix to force/upgrade the minimal CXXFLAGS
required in gcc/configure (to c++11) and have the
top-level configure set it down to the minimal CXXFLAGS we want to
guarantee? Do we really want to make this distinction? Or is it OK to
always force c++11 ?
The immediate problem for me is that all my validations for trunk fail
during the build stage.
FWIW, I removed the check on enable_bootstrap so that -std=c++11 is
used for my non-bootstrap cross-compiler, and the build goes further,
but still fails when compiling arm-common.c:
from
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/common/config/arm/arm-common.c:34:
/usr/lib/gcc/x86_64-linux-gnu/5/include/mm_malloc.h:42:12: error:
attempt to use poisoned "malloc"
return malloc (size);
Christophe
