[PATCH RFC] bootstrap: Update requirement to C++11.

Jason Merrill jason@redhat.com
Mon Jun 8 02:10:05 GMT 2020


On 6/7/20 12:56 PM, Christophe Lyon wrote:
> On Fri, 5 Jun 2020 at 19:58, Jason Merrill <jason@redhat.com> wrote:
>>
>> On 6/5/20 12:39 PM, Jason Merrill wrote:
>>> On Fri, Jun 5, 2020 at 12:01 PM Christophe Lyon
>>> <christophe.lyon@linaro.org <mailto:christophe.lyon@linaro.org>> wrote:
>>>
>>>      On Fri, 15 May 2020 at 23:54, Jason Merrill via Gcc-patches
>>>      <gcc-patches@gcc.gnu.org <mailto: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
>>>      <jason@redhat.com <mailto:jason@redhat.com>> wrote:
>>>       > >> On Fri, May 15, 2020 at 3:15 AM Richard Biener
>>>       > >> <richard.guenther@gmail.com <mailto:richard.guenther@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.
>>
>> Like so.  OK for trunk?
>>
> 
> Yes it works for me (I thought we needed more subtle logic for
> configurations I couldn't think of).
> 
> As I mentioned earlier, the build of the arm port is broken after this
> upgrade, and the attached patch fixes it. OK?

OK.

Jason



More information about the Gcc-patches mailing list