On 6/7/20 12:56 PM, Christophe Lyon wrote:
On Fri, 5 Jun 2020 at 19:58, Jason Merrill <ja...@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.l...@linaro.org <mailto:christophe.l...@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
<ja...@redhat.com <mailto:ja...@redhat.com>> wrote:
> >> On Fri, May 15, 2020 at 3:15 AM Richard Biener
> >> <richard.guent...@gmail.com <mailto: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.
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
