Re: [PATCH RFC] bootstrap: Update requirement to C++11.
On Mon, Jun 8, 2020 at 6:54 AM Martin Jambor wrote:
> Hi,
>
> On Fri, May 15 2020, Jason Merrill via Gcc-patches wrote:
> > commit f466a9f3f121f16b97071162806255fb464718f2
> > Author: Jason Merrill
> > Date: Fri May 15 17:15:38 2020 -0400
> >
> > bootstrap: Update requirement to C++11.
> >
> > There was general agreement last November that we would move to
> allowing
> > C++11 features to be used in GCC 11; this patch implements that
> direction.
> >
>
> since this commit (gcc-11-462-g5329b59a2e1) I cannot bootstrap GCC on
> gcc45.fsffrance.org compile farm machine which is an i586-linux-gnu box
> where the system compiler is GCC 4.9.2 which I believe should be new
> enough. Still, stage 1 fails with the errors below.
>
> What baffles me is that only bootstrap fails on the old machine. If I
> configure with --disable-bootstrap, make finishes fine. For the record,
> I configure gcc there with:
>
> /home/jamborm/gcc/trunk/src/configure
> --prefix=/home/jamborm/gcc/trunk/inst --enable-languages=c,c++
> --enable-checking=yes --disable-libsanitizer --disable-multilib
> --disable-libcilkrts --with-gmp=/opt/cfarm/gmp-latest
> --with-mpfr=/opt/cfarm/mpfr-latest --with-mpc=/opt/cfarm/mpc-latest
>
> In my other i686 testing environment, which is a chroot with gcc 8.3.0
> as the system compiler, I can bootstrap without any issues.
>
> I can open a PR if you want me to.
>
> Thanks,
>
> Martin
>
>
> g++ -std=c++11 -fno-PIE -c -g -DIN_GCC -fno-exceptions -fno-rtti
> -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
> -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual
> -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
> -fno-common -DHAVE_CONFIG_H -I. -I. -I/home/jamborm/gcc/trunk/src/gcc
> -I/home/jamborm/gcc/trunk/src/gcc/.
> -I/home/jamborm/gcc/trunk/src/gcc/../include
> -I/home/jamborm/gcc/trunk/src/gcc/../libcpp/include
> -I/opt/cfarm/gmp-latest/include -I/opt/cfarm/mpfr-latest/include
> -I/opt/cfarm/mpc-latest/include
> -I/home/jamborm/gcc/trunk/src/gcc/../libdecnumber
> -I/home/jamborm/gcc/trunk/src/gcc/../libdecnumber/bid -I../libdecnumber
> -I/home/jamborm/gcc/trunk/src/gcc/../libbacktrace -o i386-options.o -MT
> i386-options.o -MMD -MP -MF ./.deps/i386-options.TPo
> /home/jamborm/gcc/trunk/src/gcc/config/i386/i386-options.c
> In file included from
> /home/jamborm/gcc/trunk/src/gcc/config/i386/i386-options.c:94:0:
> /home/jamborm/gcc/trunk/src/gcc/config/i386/x86-tune-costs.h:32:56: error:
> uninitialized const member ‘stringop_algs::stringop_strategy::max’
>{rep_prefix_1_byte, {{-1, rep_prefix_1_byte, false;
> ^
> /home/jamborm/gcc/trunk/src/gcc/config/i386/x86-tune-costs.h:32:56:
> warning: missing initializer for member
> ‘stringop_algs::stringop_strategy::max’ [-Wmissing-field-initializers]
>
Hmm, yes, this was PR 49132, fixed in GCC 5. I think we will want to work
around it by removing the 'const's from stringop_strategy.
Jason
Re: [PATCH RFC] bootstrap: Update requirement to C++11.
Hi,
On Fri, May 15 2020, Jason Merrill via Gcc-patches wrote:
> commit f466a9f3f121f16b97071162806255fb464718f2
> Author: Jason Merrill
> Date: Fri May 15 17:15:38 2020 -0400
>
> bootstrap: Update requirement to C++11.
>
> There was general agreement last November that we would move to allowing
> C++11 features to be used in GCC 11; this patch implements that direction.
>
since this commit (gcc-11-462-g5329b59a2e1) I cannot bootstrap GCC on
gcc45.fsffrance.org compile farm machine which is an i586-linux-gnu box
where the system compiler is GCC 4.9.2 which I believe should be new
enough. Still, stage 1 fails with the errors below.
What baffles me is that only bootstrap fails on the old machine. If I
configure with --disable-bootstrap, make finishes fine. For the record,
I configure gcc there with:
/home/jamborm/gcc/trunk/src/configure --prefix=/home/jamborm/gcc/trunk/inst
--enable-languages=c,c++ --enable-checking=yes --disable-libsanitizer
--disable-multilib --disable-libcilkrts --with-gmp=/opt/cfarm/gmp-latest
--with-mpfr=/opt/cfarm/mpfr-latest --with-mpc=/opt/cfarm/mpc-latest
In my other i686 testing environment, which is a chroot with gcc 8.3.0
as the system compiler, I can bootstrap without any issues.
I can open a PR if you want me to.
Thanks,
Martin
g++ -std=c++11 -fno-PIE -c -g -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-fno-common -DHAVE_CONFIG_H -I. -I. -I/home/jamborm/gcc/trunk/src/gcc
-I/home/jamborm/gcc/trunk/src/gcc/.
-I/home/jamborm/gcc/trunk/src/gcc/../include
-I/home/jamborm/gcc/trunk/src/gcc/../libcpp/include
-I/opt/cfarm/gmp-latest/include -I/opt/cfarm/mpfr-latest/include
-I/opt/cfarm/mpc-latest/include
-I/home/jamborm/gcc/trunk/src/gcc/../libdecnumber
-I/home/jamborm/gcc/trunk/src/gcc/../libdecnumber/bid -I../libdecnumber
-I/home/jamborm/gcc/trunk/src/gcc/../libbacktrace -o i386-options.o -MT
i386-options.o -MMD -MP -MF ./.deps/i386-options.TPo
/home/jamborm/gcc/trunk/src/gcc/config/i386/i386-options.c
In file included from
/home/jamborm/gcc/trunk/src/gcc/config/i386/i386-options.c:94:0:
/home/jamborm/gcc/trunk/src/gcc/config/i386/x86-tune-costs.h:32:56: error:
uninitialized const member ‘stringop_algs::stringop_strategy::max’
{rep_prefix_1_byte, {{-1, rep_prefix_1_byte, false;
^
/home/jamborm/gcc/trunk/src/gcc/config/i386/x86-tune-costs.h:32:56: warning:
missing initializer for member ‘stringop_algs::stringop_strategy::max’
[-Wmissing-field-initializers]
/home/jamborm/gcc/trunk/src/gcc/config/i386/x86-tune-costs.h:32:56: error:
uninitialized const member ‘stringop_algs::stringop_strategy::alg’
/home/jamborm/gcc/trunk/src/gcc/config/i386/x86-tune-costs.h:32:56: warning:
missing initializer for member ‘stringop_algs::stringop_strategy::alg’
[-Wmissing-field-initializers]
/home/jamborm/gcc/trunk/src/gcc/config/i386/x86-tune-costs.h:32:56: warning:
missing initializer for member ‘stringop_algs::stringop_strategy::noalign’
[-Wmissing-field-initializers]
/home/jamborm/gcc/trunk/src/gcc/config/i386/x86-tune-costs.h:32:56: error:
uninitialized const member ‘stringop_algs::stringop_strategy::max’
/home/jamborm/gcc/trunk/src/gcc/config/i386/x86-tune-costs.h:32:56: warning:
missing initializer for member ‘stringop_algs::stringop_strategy::max’
[-Wmissing-field-initializers]
/home/jamborm/gcc/trunk/src/gcc/config/i386/x86-tune-costs.h:32:56: error:
uninitialized const member ‘stringop_algs::stringop_strategy::alg’
/home/jamborm/gcc/trunk/src/gcc/config/i386/x86-tune-costs.h:32:56: warning:
missing initializer for member ‘stringop_algs::stringop_strategy::alg’
[-Wmissing-field-initializers]
/home/jamborm/gcc/trunk/src/gcc/config/i386/x86-tune-costs.h:32:56: warning:
missing initializer for member ‘stringop_algs::stringop_strategy::noalign’
[-Wmissing-field-initializers]
/home/jamborm/gcc/trunk/src/gcc/config/i386/x86-tune-costs.h:32:56: error:
uninitialized const member ‘stringop_algs::stringop_strategy::max’
/home/jamborm/gcc/trunk/src/gcc/config/i386/x86-tune-costs.h:32:56: warning:
missing initializer for member ‘stringop_algs::stringop_strategy::max’
[-Wmissing-field-initializers]
/home/jamborm/gcc/trunk/src/gcc/config/i386/x86-tune-costs.h:32:56: error:
uninitialized const member ‘stringop_algs::stringop_strategy::alg’
/home/jamborm/gcc/trunk/src/gcc/config/i386/x86-tune-costs.h:32:56: warning:
missing initializer for member ‘stringop_algs::stringop_strategy::alg’
[-Wmissing-field-initializers]
/home/jamborm/gcc/trunk/src/gcc/config/i386/x86-tune-costs.h:32:56: warning:
missing initializer for member ‘stringop_algs::stringop_strategy::noalign’
[-Wmissing-field-initializers]
/home/jamborm/gcc/trunk/src/gcc/config/i386/x86-tune-costs.h:32:56:
Re: [PATCH RFC] bootstrap: Update requirement to C++11.
On 6/7/20 12:56 PM, Christophe Lyon wrote: On Fri, 5 Jun 2020 at 19:58, Jason Merrill wrote: On 6/5/20 12:39 PM, Jason Merrill wrote: On Fri, Jun 5, 2020 at 12:01 PM Christophe Lyon mailto:christophe.l...@linaro.org>> wrote: On Fri, 15 May 2020 at 23:54, Jason Merrill via Gcc-patches 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 mailto:ja...@redhat.com>> wrote: > >> On Fri, May 15, 2020 at 3:15 AM Richard Biener > >> 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
Re: [PATCH RFC] bootstrap: Update requirement to C++11.
On Fri, 5 Jun 2020 at 19:58, Jason Merrill wrote: > > On 6/5/20 12:39 PM, Jason Merrill wrote: > > On Fri, Jun 5, 2020 at 12:01 PM Christophe Lyon > > mailto:christophe.l...@linaro.org>> wrote: > > > > On Fri, 15 May 2020 at 23:54, Jason Merrill via Gcc-patches > > 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 > > mailto:ja...@redhat.com>> wrote: > > > >> On Fri, May 15, 2020 at 3:15 AM Richard Biener > > > >> 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 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
Re: [PATCH RFC] bootstrap: Update requirement to C++11.
On 6/5/20 12:39 PM, Jason Merrill wrote: On Fri, Jun 5, 2020 at 12:01 PM Christophe Lyon mailto:christophe.l...@linaro.org>> wrote: On Fri, 15 May 2020 at 23:54, Jason Merrill via Gcc-patches 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 mailto:ja...@redhat.com>> wrote: > >> On Fri, May 15, 2020 at 3:15 AM Richard Biener > >> 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? commit e9a1dcaf78f7316a771cc6c3a4800784bb18d8e2 Author: Jason Merrill Date: Fri Jun 5 12:45:11 2020 -0400 c++: Fix --disable-bootstrap with older g++. Previously I had AX_CXX_COMPILE_STDCXX in the gcc directory configure, which added -std=c++11 to CXX if needed, but then CXX is overridden from the toplevel directory, so it didn't have the desired effect. Fixed by moving the check to the toplevel. Currently it is only used when building GCC without bootstrapping; other packages that share the toplevel directory can adjust the condition if they also want to require C++11 support. ChangeLog: * configure.ac: Check AX_CXX_COMPILE_STDCXX if not bootstrapping. * configure: Regenerate. gcc/ChangeLog: * aclocal.m4: Remove ax_cxx_compile_stdcxx.m4. * configure.ac: Remove AX_CXX_COMPILE_STDCXX. * configure: Regenerate. diff --git a/configure.ac b/configure.ac index 59bd92a3e53..1a53ed418e4 100644 --- a/configure.ac +++ b/configure.ac @@ -23,6 +23,7 @@
Re: [PATCH RFC] bootstrap: Update requirement to C++11.
On Fri, Jun 5, 2020 at 12:01 PM Christophe Lyon wrote: > On Fri, 15 May 2020 at 23:54, Jason Merrill via Gcc-patches > wrote: > > > > On 5/15/20 2:21 PM, Richard Biener wrote: > > > On May 15, 2020 7:30:38 PM GMT+02:00, Jason Merrill > wrote: > > >> On Fri, May 15, 2020 at 3:15 AM Richard Biener > > >> > > >> 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
Re: [PATCH RFC] bootstrap: Update requirement to C++11.
On Fri, 15 May 2020 at 23:54, Jason Merrill via Gcc-patches wrote: > > On 5/15/20 2:21 PM, Richard Biener wrote: > > On May 15, 2020 7:30:38 PM GMT+02:00, Jason Merrill > > wrote: > >> On Fri, May 15, 2020 at 3:15 AM Richard Biener > >> > >> 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
Re: [PATCH RFC] bootstrap: Update requirement to C++11.
On May 15, 2020 11:53:42 PM GMT+02:00, Jason Merrill wrote: >On 5/15/20 2:21 PM, Richard Biener wrote: >> On May 15, 2020 7:30:38 PM GMT+02:00, Jason Merrill > wrote: >>> On Fri, May 15, 2020 at 3:15 AM Richard Biener >>> >>> 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? OK if there are no further comments over the weekend. Thanks, Richard.
Re: [PATCH RFC] bootstrap: Update requirement to C++11.
On 5/15/20 2:21 PM, Richard Biener wrote:
On May 15, 2020 7:30:38 PM GMT+02:00, Jason Merrill wrote:
On Fri, May 15, 2020 at 3:15 AM Richard Biener
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?
commit f466a9f3f121f16b97071162806255fb464718f2
Author: Jason Merrill
Date: Fri May 15 17:15:38 2020 -0400
bootstrap: Update requirement to C++11.
There was general agreement last November that we would move to allowing
C++11 features to be used in GCC 11; this patch implements that direction.
ChangeLog
2020-05-15 Jason Merrill
* configure.ac: Update bootstrap dialect to -std=c++11.
config/ChangeLog
2020-05-15 Jason Merrill
* ax_cxx_compile_stdcxx.m4: Import from autoconf archive with
an adjustment to try the default mode.
gcc/ChangeLog
2020-05-15 Jason Merrill
* aclocal.m4: Add ax_cxx_compile_stdcxx.m4.
* configure.ac: Use AX_CXX_COMPILE_STDCXX(11).
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 876b04f9c45..c367f4f66e3 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -238,18 +238,20 @@ described below.
@heading Tools/packages necessary for building GCC
@table @asis
-@item ISO C++98 compiler
-Necessary to bootstrap GCC, although versions of GCC prior
-to 4.8 also allow bootstrapping with a ISO C89 compiler and versions
-of GCC prior to 3.4 also allow bootstrapping with a traditional
-(K) C compiler.
+@item ISO C++11 compiler
+Necessary to bootstrap GCC.
+
+Versions of GCC prior to 11 also allow bootstrapping with an ISO C++98
+compiler, versions of GCC prior to 4.8 also allow bootstrapping with a
+ISO C89 compiler, and versions of GCC prior to 3.4 also allow
+bootstrapping with a traditional (K) C compiler.
To build all languages in a cross-compiler or other configuration where
3-stage bootstrap is not performed, you need to start with an existing
-GCC binary (version 3.4 or later) because source code for language
+GCC binary (version 4.8 or later) because source code for language
frontends other than C might use GCC extensions.
-Note that to bootstrap GCC with versions of GCC earlier than 3.4, you
+Note that to bootstrap GCC with versions of GCC earlier than 4.8, you
may need to use @option{--disable-stage1-checking}, though
bootstrapping the compiler with such earlier compilers is strongly
discouraged.
diff --git a/config/ax_cxx_compile_stdcxx.m4 b/config/ax_cxx_compile_stdcxx.m4
new file mode 100644
index 000..9413da624d2
--- /dev/null
+++ b/config/ax_cxx_compile_stdcxx.m4
@@ -0,0 +1,962 @@
+# ===
+# https://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx.html
+# ===
+#
+# SYNOPSIS
+#
+# AX_CXX_COMPILE_STDCXX(VERSION, [ext|noext], [mandatory|optional])
+#
+# DESCRIPTION
+#
+# Check for baseline language coverage in the compiler for the specified
+# version of the C++
Re: [PATCH RFC] bootstrap: Update requirement to C++11.
On May 15, 2020 7:30:38 PM GMT+02:00, Jason Merrill wrote: >On Fri, May 15, 2020 at 3:15 AM Richard Biener > >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. >> > >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. > >Note I think what's missing is some general blurb in our coding >conventions >> as to how much of C++11 we are supposed to use in non-infrastructure >parts >> of GCC (I expect things like hash-table.h to use more C++ features >than, >> say, tree-ssa-alias.c). >> >> 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. > > >> 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? Richard. >Jason
Re: [PATCH RFC] bootstrap: Update requirement to C++11.
On Fri, May 15, 2020 at 5:58 AM Richard Sandiford
wrote:
> Richard Biener writes:
> > On Fri, May 15, 2020 at 10:30 AM Richard Sandiford
> > wrote:
> >>
> >> Richard Biener via Gcc-patches writes:
> >> > Note I think what's missing is some general blurb in our coding
> conventions
> >> > as to how much of C++11 we are supposed to use in non-infrastructure
> parts
> >> > of GCC (I expect things like hash-table.h to use more C++ features
> than,
> >> > say, tree-ssa-alias.c).
> >>
> >> I guess there are two aspects to that:
> >>
> >> - Are there any specific features we should avoid using at all?
> >> TBH I hope not. Trying to police this based on C++ feature sounds
> >> difficulty and might be counterproductive.
> >>
> >> IMO it should just (continue to) be based on principles like avoiding
> >> abstraction for abstraction's sake, and keeping compiler performance
> >> and code size in mind. Even tree-ssa-alias.c should be able to use
> >> any C++ feature if there's a justification.
> >>
> >> - Coding conventions for when features should be used. "auto" is an
> >> obvious one. Maybe also lambdas (which should help avoid the horrible
> >> "void *" callback parameters we have all over the place now).
> >>
> >> Maybe also guidelines to actively use certain features, e.g.
> >>
> >> - use "= default" where possible
> >>
> >> - prefer range-based for loops to macros
> >>
> >> - mark "operator bool()" conversions as explicit
> >>
> >> - use "override" where applicable
> >>
> >> (all obvious I guess), etc.
> >
> > I think the most important thing is that refactoring for the sake
> > of refactoring is bad iff it does not improve on consistency
> > throughout the code base. We should really try hard to use
> > C++ features consistently - this makes the code base easier
> > to understand.
>
> Agreed. One of the reasons I'm keen to have something in the
> coding standards is that things became less consistent after
> the C->C++ switch.
>
> Maybe we should reconsider some of the existing coding standards too.
> E.g.:
>
> Define all members outside the class definition.
> That is, there are no function bodies or member initializers
> inside the class definition.
>
> isn't widely followed. That's a bit of a tangent though.
> (FTR, I've no attachment to the current conventions and didn't
> contribute anything to them. More consistency would be good though.)
>
> > We've moved more and more to stronly-typed data structures
> > so I'd not like to see 'auto' everywhere - it should be still
> > obvious what kind of objects we're working with where they
> > matter. IMHO they do not matter for example for iterators.
> > I don't care about the iterator type but about the type of
> > the object and the container.
>
> Also agreed. :-) How about this as a starting point:
>
> ---
> Use auto for:
>
> - the result of casts or other expressions that give the type
> explicitly. E.g.:
>
> if (auto *table = dyn_cast (insn))
>
> instead of:
>
> if (rtx_jump_table_data *table = dyn_cast
> (insn))
>
> - iterator types. E.g.:
>
> auto it = foo.begin ();
>
> instead of:
>
> foo_type::iterator it = foo.begin ();
>
> - expressions that provide an alternative view of something,
> when the expression is bound to a read-only temporary. E.g.:
>
> auto val1 = wi::to_wide (...);
> auto val2 = wi::uhwi (12, 16);
>
> instead of:
>
> wide_int val1 = wi::to_wide (...);
> wide_int val2 = wi::uhwi (12, 16);
>
> (Using "wide_int" is less efficient than using the natural type of
> the expression.)
>
> - the type of a lambda expression. E.g.:
>
> auto f = [] (int x) { return x + 1; };
>
> Do not use auto otherwise.
>
We probably also want to use auto for local variables in templates where
the initializer is type-dependent.
Jason
Re: [PATCH RFC] bootstrap: Update requirement to C++11.
On Fri, May 15, 2020 at 3:15 AM Richard Biener 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. > 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. Note I think what's missing is some general blurb in our coding conventions > as to how much of C++11 we are supposed to use in non-infrastructure parts > of GCC (I expect things like hash-table.h to use more C++ features than, > say, tree-ssa-alias.c). > > 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. > 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. Jason
Re: [PATCH RFC] bootstrap: Update requirement to C++11.
On Fri, May 15, 2020 at 11:58 AM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Fri, May 15, 2020 at 10:30 AM Richard Sandiford
> > wrote:
> >>
> >> Richard Biener via Gcc-patches writes:
> >> > Note I think what's missing is some general blurb in our coding
> >> > conventions
> >> > as to how much of C++11 we are supposed to use in non-infrastructure
> >> > parts
> >> > of GCC (I expect things like hash-table.h to use more C++ features than,
> >> > say, tree-ssa-alias.c).
> >>
> >> I guess there are two aspects to that:
> >>
> >> - Are there any specific features we should avoid using at all?
> >> TBH I hope not. Trying to police this based on C++ feature sounds
> >> difficulty and might be counterproductive.
> >>
> >> IMO it should just (continue to) be based on principles like avoiding
> >> abstraction for abstraction's sake, and keeping compiler performance
> >> and code size in mind. Even tree-ssa-alias.c should be able to use
> >> any C++ feature if there's a justification.
> >>
> >> - Coding conventions for when features should be used. "auto" is an
> >> obvious one. Maybe also lambdas (which should help avoid the horrible
> >> "void *" callback parameters we have all over the place now).
> >>
> >> Maybe also guidelines to actively use certain features, e.g.
> >>
> >> - use "= default" where possible
> >>
> >> - prefer range-based for loops to macros
> >>
> >> - mark "operator bool()" conversions as explicit
> >>
> >> - use "override" where applicable
> >>
> >> (all obvious I guess), etc.
> >
> > I think the most important thing is that refactoring for the sake
> > of refactoring is bad iff it does not improve on consistency
> > throughout the code base. We should really try hard to use
> > C++ features consistently - this makes the code base easier
> > to understand.
>
> Agreed. One of the reasons I'm keen to have something in the
> coding standards is that things became less consistent after
> the C->C++ switch.
Yeah. I'm really hoping that we can unify all of the various iteration
styles used. In general, even if I don't like it too much personally,
I'm leaning towards STL style of thing because of the idea
"C++ attracts more developers". Now C++ range-for makes me
like it much more so that's one good reason for adopting C++11,
turn all of them over to range-for style (only!).
> Maybe we should reconsider some of the existing coding standards too.
> E.g.:
>
> Define all members outside the class definition.
> That is, there are no function bodies or member initializers
> inside the class definition.
>
> isn't widely followed. That's a bit of a tangent though.
> (FTR, I've no attachment to the current conventions and didn't
> contribute anything to them. More consistency would be good though.)
>
> > We've moved more and more to stronly-typed data structures
> > so I'd not like to see 'auto' everywhere - it should be still
> > obvious what kind of objects we're working with where they
> > matter. IMHO they do not matter for example for iterators.
> > I don't care about the iterator type but about the type of
> > the object and the container.
>
> Also agreed. :-) How about this as a starting point:
>
> ---
> Use auto for:
>
> - the result of casts or other expressions that give the type
> explicitly. E.g.:
>
> if (auto *table = dyn_cast (insn))
>
> instead of:
>
> if (rtx_jump_table_data *table = dyn_cast (insn))
>
> - iterator types. E.g.:
>
> auto it = foo.begin ();
>
> instead of:
>
> foo_type::iterator it = foo.begin ();
>
> - expressions that provide an alternative view of something,
> when the expression is bound to a read-only temporary. E.g.:
>
> auto val1 = wi::to_wide (...);
> auto val2 = wi::uhwi (12, 16);
>
> instead of:
>
> wide_int val1 = wi::to_wide (...);
> wide_int val2 = wi::uhwi (12, 16);
>
> (Using "wide_int" is less efficient than using the natural type of
> the expression.)
>
> - the type of a lambda expression. E.g.:
>
> auto f = [] (int x) { return x + 1; };
Those are all good examples. Mind putting that into a patch
for the coding conventions?
> Do not use auto otherwise.
> ---
>
> One thing I wondered about is whether we should encourage auto
> for normal integer results. It would avoid problems with values
> being silently truncated to a narrower type (e.g. HOST_WIDE_INT->int).
> On the other hand, that kind of truncation will still happen in things
> like function calls and member variable assignments. Using "auto" could
> also hide important signedness choices. So not using "auto" is probably
> better there...
Agreed.
Richard.
> Richard
Re: [PATCH RFC] bootstrap: Update requirement to C++11.
Richard Biener writes:
> On Fri, May 15, 2020 at 10:30 AM Richard Sandiford
> wrote:
>>
>> Richard Biener via Gcc-patches writes:
>> > Note I think what's missing is some general blurb in our coding conventions
>> > as to how much of C++11 we are supposed to use in non-infrastructure parts
>> > of GCC (I expect things like hash-table.h to use more C++ features than,
>> > say, tree-ssa-alias.c).
>>
>> I guess there are two aspects to that:
>>
>> - Are there any specific features we should avoid using at all?
>> TBH I hope not. Trying to police this based on C++ feature sounds
>> difficulty and might be counterproductive.
>>
>> IMO it should just (continue to) be based on principles like avoiding
>> abstraction for abstraction's sake, and keeping compiler performance
>> and code size in mind. Even tree-ssa-alias.c should be able to use
>> any C++ feature if there's a justification.
>>
>> - Coding conventions for when features should be used. "auto" is an
>> obvious one. Maybe also lambdas (which should help avoid the horrible
>> "void *" callback parameters we have all over the place now).
>>
>> Maybe also guidelines to actively use certain features, e.g.
>>
>> - use "= default" where possible
>>
>> - prefer range-based for loops to macros
>>
>> - mark "operator bool()" conversions as explicit
>>
>> - use "override" where applicable
>>
>> (all obvious I guess), etc.
>
> I think the most important thing is that refactoring for the sake
> of refactoring is bad iff it does not improve on consistency
> throughout the code base. We should really try hard to use
> C++ features consistently - this makes the code base easier
> to understand.
Agreed. One of the reasons I'm keen to have something in the
coding standards is that things became less consistent after
the C->C++ switch.
Maybe we should reconsider some of the existing coding standards too.
E.g.:
Define all members outside the class definition.
That is, there are no function bodies or member initializers
inside the class definition.
isn't widely followed. That's a bit of a tangent though.
(FTR, I've no attachment to the current conventions and didn't
contribute anything to them. More consistency would be good though.)
> We've moved more and more to stronly-typed data structures
> so I'd not like to see 'auto' everywhere - it should be still
> obvious what kind of objects we're working with where they
> matter. IMHO they do not matter for example for iterators.
> I don't care about the iterator type but about the type of
> the object and the container.
Also agreed. :-) How about this as a starting point:
---
Use auto for:
- the result of casts or other expressions that give the type
explicitly. E.g.:
if (auto *table = dyn_cast (insn))
instead of:
if (rtx_jump_table_data *table = dyn_cast (insn))
- iterator types. E.g.:
auto it = foo.begin ();
instead of:
foo_type::iterator it = foo.begin ();
- expressions that provide an alternative view of something,
when the expression is bound to a read-only temporary. E.g.:
auto val1 = wi::to_wide (...);
auto val2 = wi::uhwi (12, 16);
instead of:
wide_int val1 = wi::to_wide (...);
wide_int val2 = wi::uhwi (12, 16);
(Using "wide_int" is less efficient than using the natural type of
the expression.)
- the type of a lambda expression. E.g.:
auto f = [] (int x) { return x + 1; };
Do not use auto otherwise.
---
One thing I wondered about is whether we should encourage auto
for normal integer results. It would avoid problems with values
being silently truncated to a narrower type (e.g. HOST_WIDE_INT->int).
On the other hand, that kind of truncation will still happen in things
like function calls and member variable assignments. Using "auto" could
also hide important signedness choices. So not using "auto" is probably
better there...
Richard
Re: [PATCH RFC] bootstrap: Update requirement to C++11.
On Fri, May 15, 2020 at 10:30 AM Richard Sandiford wrote: > > Richard Biener via Gcc-patches writes: > > Note I think what's missing is some general blurb in our coding conventions > > as to how much of C++11 we are supposed to use in non-infrastructure parts > > of GCC (I expect things like hash-table.h to use more C++ features than, > > say, tree-ssa-alias.c). > > I guess there are two aspects to that: > > - Are there any specific features we should avoid using at all? > TBH I hope not. Trying to police this based on C++ feature sounds > difficulty and might be counterproductive. > > IMO it should just (continue to) be based on principles like avoiding > abstraction for abstraction's sake, and keeping compiler performance > and code size in mind. Even tree-ssa-alias.c should be able to use > any C++ feature if there's a justification. > > - Coding conventions for when features should be used. "auto" is an > obvious one. Maybe also lambdas (which should help avoid the horrible > "void *" callback parameters we have all over the place now). > > Maybe also guidelines to actively use certain features, e.g. > > - use "= default" where possible > > - prefer range-based for loops to macros > > - mark "operator bool()" conversions as explicit > > - use "override" where applicable > > (all obvious I guess), etc. I think the most important thing is that refactoring for the sake of refactoring is bad iff it does not improve on consistency throughout the code base. We should really try hard to use C++ features consistently - this makes the code base easier to understand. We've moved more and more to stronly-typed data structures so I'd not like to see 'auto' everywhere - it should be still obvious what kind of objects we're working with where they matter. IMHO they do not matter for example for iterators. I don't care about the iterator type but about the type of the object and the container. Richard. > Thanks, > Richard
Re: [PATCH RFC] bootstrap: Update requirement to C++11.
Richard Biener via Gcc-patches writes: > Note I think what's missing is some general blurb in our coding conventions > as to how much of C++11 we are supposed to use in non-infrastructure parts > of GCC (I expect things like hash-table.h to use more C++ features than, > say, tree-ssa-alias.c). I guess there are two aspects to that: - Are there any specific features we should avoid using at all? TBH I hope not. Trying to police this based on C++ feature sounds difficulty and might be counterproductive. IMO it should just (continue to) be based on principles like avoiding abstraction for abstraction's sake, and keeping compiler performance and code size in mind. Even tree-ssa-alias.c should be able to use any C++ feature if there's a justification. - Coding conventions for when features should be used. "auto" is an obvious one. Maybe also lambdas (which should help avoid the horrible "void *" callback parameters we have all over the place now). Maybe also guidelines to actively use certain features, e.g. - use "= default" where possible - prefer range-based for loops to macros - mark "operator bool()" conversions as explicit - use "override" where applicable (all obvious I guess), etc. Thanks, Richard
Re: [PATCH RFC] bootstrap: Update requirement to C++11.
On Thu, May 14, 2020 at 11:53 PM Jason Merrill via Gcc-patches wrote: > > There seemed to be general agreement last November that we would move to > allowing C++11 features to be used in GCC 11; this patch implements that > direction. Are changes needed anywhere else? > > ChangeLog > 2020-05-14 Jason Merrill > > * configure.ac: Update bootstrap dialect to -std=gnu++11. > > gcc/ChangeLog > 2020-05-14 Jason Merrill > > * doc/install.texi (Prerequisites): Update boostrap compiler > requirement to C++11/GCC 4.8. > --- > gcc/doc/install.texi | 14 -- > configure.ac | 6 +++--- > ChangeLog| 4 > configure| 6 +++--- > 4 files changed, 18 insertions(+), 12 deletions(-) > > diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi > index 876b04f9c45..f47e3c76f73 100644 > --- a/gcc/doc/install.texi > +++ b/gcc/doc/install.texi > @@ -238,15 +238,17 @@ described below. > > @heading Tools/packages necessary for building GCC > @table @asis > -@item ISO C++98 compiler > -Necessary to bootstrap GCC, although versions of GCC prior > -to 4.8 also allow bootstrapping with a ISO C89 compiler and versions > -of GCC prior to 3.4 also allow bootstrapping with a traditional > -(K) C compiler. > +@item ISO C++11 compiler > +Necessary to bootstrap GCC. > + > +Versions of GCC prior to 11 also allow bootstrapping with an ISO C++98 > +compiler, versions of GCC prior to 4.8 also allow bootstrapping with a > +ISO C89 compiler, and versions of GCC prior to 3.4 also allow > +bootstrapping with a traditional (K) C compiler. > > To build all languages in a cross-compiler or other configuration where > 3-stage bootstrap is not performed, you need to start with an existing > -GCC binary (version 3.4 or later) because source code for language > +GCC binary (version 4.8 or later) because source code for language > frontends other than C might use GCC extensions. > > Note that to bootstrap GCC with versions of GCC earlier than 3.4, you > diff --git a/configure.ac b/configure.ac > index c78d9cbea62..63d92b73061 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -1462,10 +1462,10 @@ case "$have_compiler:$host:$target:$enable_bootstrap" > in > ;; > esac > > -# When bootstrapping with GCC, build stage 1 in C++98 mode to ensure that a > -# C++98 compiler can still start the bootstrap. > +# 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++98" > + 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. Note I think what's missing is some general blurb in our coding conventions as to how much of C++11 we are supposed to use in non-infrastructure parts of GCC (I expect things like hash-table.h to use more C++ features than, say, tree-ssa-alias.c). 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? 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? Thanks, Richard. > fi > > # Used for setting $lt_cv_objdir > diff --git a/ChangeLog b/ChangeLog > index a7fcf77b9b2..1d281855a3e 100644 > --- a/ChangeLog > +++ b/ChangeLog > @@ -1,3 +1,7 @@ > +2020-05-14 Jason Merrill > + > + * configure.ac: Update bootstrap dialect to -std=gnu++11. > + > 2020-04-29 Thomas Schwinge > > PR target/92713 > diff --git a/configure b/configure > index 4cc938ebb7d..9b39035bbcc 100755 > --- a/configure > +++ b/configure > @@ -5523,10 +5523,10 @@ $as_echo "$as_me: WARNING: trying to bootstrap a > cross compiler" >&2;} > ;; > esac > > -# When bootstrapping with GCC, build stage 1 in C++98 mode to ensure that a > -# C++98 compiler can still start the bootstrap. > +# 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++98" > + CXX="$CXX -std=gnu++11" > fi > > # Used for setting $lt_cv_objdir > > base-commit: 4e1592f8e1d6366699e05c0824fc3dc39ca7314b > -- > 2.18.1 >
Re: [PATCH RFC] bootstrap: Update requirement to C++11.
On Thu, May 14, 2020 at 05:05:59PM -0400, Jason Merrill via Gcc-patches wrote: > +Versions of GCC prior to 11 also allow bootstrapping with an ISO C++98 > +compiler, versions of GCC prior to 4.8 also allow bootstrapping with a > +ISO C89 compiler, and versions of GCC prior to 3.4 also allow > +bootstrapping with a traditional (K) C compiler. > > To build all languages in a cross-compiler or other configuration where > 3-stage bootstrap is not performed, you need to start with an existing > -GCC binary (version 3.4 or later) because source code for language > +GCC binary (version 4.8 or later) because source code for language > frontends other than C might use GCC extensions. > > Note that to bootstrap GCC with versions of GCC earlier than 3.4, you Probably this paragraph needs adjustments too. Jakub
[PATCH RFC] bootstrap: Update requirement to C++11.
There seemed to be general agreement last November that we would move to allowing C++11 features to be used in GCC 11; this patch implements that direction. Are changes needed anywhere else? ChangeLog 2020-05-14 Jason Merrill * configure.ac: Update bootstrap dialect to -std=gnu++11. gcc/ChangeLog 2020-05-14 Jason Merrill * doc/install.texi (Prerequisites): Update boostrap compiler requirement to C++11/GCC 4.8. --- gcc/doc/install.texi | 14 -- configure.ac | 6 +++--- ChangeLog| 4 configure| 6 +++--- 4 files changed, 18 insertions(+), 12 deletions(-) diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi index 876b04f9c45..f47e3c76f73 100644 --- a/gcc/doc/install.texi +++ b/gcc/doc/install.texi @@ -238,15 +238,17 @@ described below. @heading Tools/packages necessary for building GCC @table @asis -@item ISO C++98 compiler -Necessary to bootstrap GCC, although versions of GCC prior -to 4.8 also allow bootstrapping with a ISO C89 compiler and versions -of GCC prior to 3.4 also allow bootstrapping with a traditional -(K) C compiler. +@item ISO C++11 compiler +Necessary to bootstrap GCC. + +Versions of GCC prior to 11 also allow bootstrapping with an ISO C++98 +compiler, versions of GCC prior to 4.8 also allow bootstrapping with a +ISO C89 compiler, and versions of GCC prior to 3.4 also allow +bootstrapping with a traditional (K) C compiler. To build all languages in a cross-compiler or other configuration where 3-stage bootstrap is not performed, you need to start with an existing -GCC binary (version 3.4 or later) because source code for language +GCC binary (version 4.8 or later) because source code for language frontends other than C might use GCC extensions. Note that to bootstrap GCC with versions of GCC earlier than 3.4, you diff --git a/configure.ac b/configure.ac index c78d9cbea62..63d92b73061 100644 --- a/configure.ac +++ b/configure.ac @@ -1462,10 +1462,10 @@ case "$have_compiler:$host:$target:$enable_bootstrap" in ;; esac -# When bootstrapping with GCC, build stage 1 in C++98 mode to ensure that a -# C++98 compiler can still start the bootstrap. +# 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++98" + CXX="$CXX -std=gnu++11" fi # Used for setting $lt_cv_objdir diff --git a/ChangeLog b/ChangeLog index a7fcf77b9b2..1d281855a3e 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,7 @@ +2020-05-14 Jason Merrill + + * configure.ac: Update bootstrap dialect to -std=gnu++11. + 2020-04-29 Thomas Schwinge PR target/92713 diff --git a/configure b/configure index 4cc938ebb7d..9b39035bbcc 100755 --- a/configure +++ b/configure @@ -5523,10 +5523,10 @@ $as_echo "$as_me: WARNING: trying to bootstrap a cross compiler" >&2;} ;; esac -# When bootstrapping with GCC, build stage 1 in C++98 mode to ensure that a -# C++98 compiler can still start the bootstrap. +# 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++98" + CXX="$CXX -std=gnu++11" fi # Used for setting $lt_cv_objdir base-commit: 4e1592f8e1d6366699e05c0824fc3dc39ca7314b -- 2.18.1
