On Fri, Jun 5, 2020 at 12:01 PM Christophe Lyon <christophe.l...@linaro.org> wrote:
> 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 > Configure adds the -std=gnu++11 to CXX, not CXXFLAGS, but the problem is the same; we only actually get the flag if you run 'make' in the gcc subdirectory. I guess I need to move that test to toplevel. Jason
