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?
Thanks,
Christophe
[arm] (header usage fix) include c++ algorithm header via system.h
After the recent commit that forces uses of c++11, the arm part failed
to build because it does not include <algorithm> via system.h as
should be done.
This results in:
from /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);
This patch fixes the problem by defining INCLUDE_ALGORITHM before
including system.h and no longer includes <algorithm> directly.
diff --git a/gcc/common/config/arm/arm-common.c b/gcc/common/config/arm/arm-common.c
index 78a779c..8e986e4 100644
--- a/gcc/common/config/arm/arm-common.c
+++ b/gcc/common/config/arm/arm-common.c
@@ -19,6 +19,7 @@
#define INCLUDE_LIST
#define INCLUDE_VECTOR
+#define INCLUDE_ALGORITHM
#include "config.h"
#include "system.h"
#include "coretypes.h"
@@ -31,7 +32,6 @@
#include "flags.h"
#include "sbitmap.h"
#include "diagnostic.h"
-#include <algorithm>
/* Set default optimization options. */
static const struct default_options arm_option_optimization_table[] =
