| Message ID | 87tvyqw1ki.fsf@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | [09/nn] Add a fixed_size_mode_pod class | expand |
On Mon, Oct 23, 2017 at 1:22 PM, Richard Sandiford <richard.sandiford@linaro.org> wrote: > This patch adds a POD version of fixed_size_mode. The only current use > is for storing the __builtin_apply and __builtin_result register modes, > which were made fixed_size_modes by the previous patch. Bah - can we update our host compiler to C++11/14 please ...? (maybe requiring that build with GCC 4.8 as host compiler works, GCC 4.3 has -std=c++0x, but I'm quite sure that's not enough). Ok. Thanks, Richard. > > 2017-10-23 Richard Sandiford <richard.sandiford@linaro.org> > Alan Hayward <alan.hayward@arm.com> > David Sherwood <david.sherwood@arm.com> > > gcc/ > * coretypes.h (fixed_size_mode): Declare. > (fixed_size_mode_pod): New typedef. > * builtins.h (target_builtins::x_apply_args_mode) > (target_builtins::x_apply_result_mode): Change type to > fixed_size_mode_pod. > * builtins.c (apply_args_size, apply_result_size, result_vector) > (expand_builtin_apply_args_1, expand_builtin_apply) > (expand_builtin_return): Update accordingly. > > Index: gcc/coretypes.h > =================================================================== > --- gcc/coretypes.h 2017-09-11 17:10:58.656085547 +0100 > +++ gcc/coretypes.h 2017-10-23 11:42:57.592545063 +0100 > @@ -59,6 +59,7 @@ typedef const struct rtx_def *const_rtx; > class scalar_int_mode; > class scalar_float_mode; > class complex_mode; > +class fixed_size_mode; > template<typename> class opt_mode; > typedef opt_mode<scalar_mode> opt_scalar_mode; > typedef opt_mode<scalar_int_mode> opt_scalar_int_mode; > @@ -66,6 +67,7 @@ typedef opt_mode<scalar_float_mode> opt_ > template<typename> class pod_mode; > typedef pod_mode<scalar_mode> scalar_mode_pod; > typedef pod_mode<scalar_int_mode> scalar_int_mode_pod; > +typedef pod_mode<fixed_size_mode> fixed_size_mode_pod; > > /* Subclasses of rtx_def, using indentation to show the class > hierarchy, along with the relevant invariant. > Index: gcc/builtins.h > =================================================================== > --- gcc/builtins.h 2017-08-30 12:18:46.602740973 +0100 > +++ gcc/builtins.h 2017-10-23 11:42:57.592545063 +0100 > @@ -29,14 +29,14 @@ struct target_builtins { > the register is not used for calling a function. If the machine > has register windows, this gives only the outbound registers. > INCOMING_REGNO gives the corresponding inbound register. */ > - machine_mode x_apply_args_mode[FIRST_PSEUDO_REGISTER]; > + fixed_size_mode_pod x_apply_args_mode[FIRST_PSEUDO_REGISTER]; > > /* For each register that may be used for returning values, this gives > a mode used to copy the register's value. VOIDmode indicates the > register is not used for returning values. If the machine has > register windows, this gives only the outbound registers. > INCOMING_REGNO gives the corresponding inbound register. */ > - machine_mode x_apply_result_mode[FIRST_PSEUDO_REGISTER]; > + fixed_size_mode_pod x_apply_result_mode[FIRST_PSEUDO_REGISTER]; > }; > > extern struct target_builtins default_target_builtins; > Index: gcc/builtins.c > =================================================================== > --- gcc/builtins.c 2017-10-23 11:41:23.140260335 +0100 > +++ gcc/builtins.c 2017-10-23 11:42:57.592545063 +0100 > @@ -1358,7 +1358,6 @@ apply_args_size (void) > static int size = -1; > int align; > unsigned int regno; > - machine_mode mode; > > /* The values computed by this function never change. */ > if (size < 0) > @@ -1374,7 +1373,7 @@ apply_args_size (void) > for (regno = 0; regno < FIRST_PSEUDO_REGISTER; regno++) > if (FUNCTION_ARG_REGNO_P (regno)) > { > - mode = targetm.calls.get_raw_arg_mode (regno); > + fixed_size_mode mode = targetm.calls.get_raw_arg_mode (regno); > > gcc_assert (mode != VOIDmode); > > @@ -1386,7 +1385,7 @@ apply_args_size (void) > } > else > { > - apply_args_mode[regno] = VOIDmode; > + apply_args_mode[regno] = as_a <fixed_size_mode> (VOIDmode); > } > } > return size; > @@ -1400,7 +1399,6 @@ apply_result_size (void) > { > static int size = -1; > int align, regno; > - machine_mode mode; > > /* The values computed by this function never change. */ > if (size < 0) > @@ -1410,7 +1408,7 @@ apply_result_size (void) > for (regno = 0; regno < FIRST_PSEUDO_REGISTER; regno++) > if (targetm.calls.function_value_regno_p (regno)) > { > - mode = targetm.calls.get_raw_result_mode (regno); > + fixed_size_mode mode = targetm.calls.get_raw_result_mode (regno); > > gcc_assert (mode != VOIDmode); > > @@ -1421,7 +1419,7 @@ apply_result_size (void) > apply_result_mode[regno] = mode; > } > else > - apply_result_mode[regno] = VOIDmode; > + apply_result_mode[regno] = as_a <fixed_size_mode> (VOIDmode); > > /* Allow targets that use untyped_call and untyped_return to override > the size so that machine-specific information can be stored here. */ > @@ -1440,7 +1438,7 @@ apply_result_size (void) > result_vector (int savep, rtx result) > { > int regno, size, align, nelts; > - machine_mode mode; > + fixed_size_mode mode; > rtx reg, mem; > rtx *savevec = XALLOCAVEC (rtx, FIRST_PSEUDO_REGISTER); > > @@ -1469,7 +1467,7 @@ expand_builtin_apply_args_1 (void) > { > rtx registers, tem; > int size, align, regno; > - machine_mode mode; > + fixed_size_mode mode; > rtx struct_incoming_value = targetm.calls.struct_value_rtx (cfun ? TREE_TYPE (cfun->decl) : 0, 1); > > /* Create a block where the arg-pointer, structure value address, > @@ -1573,7 +1571,7 @@ expand_builtin_apply_args (void) > expand_builtin_apply (rtx function, rtx arguments, rtx argsize) > { > int size, align, regno; > - machine_mode mode; > + fixed_size_mode mode; > rtx incoming_args, result, reg, dest, src; > rtx_call_insn *call_insn; > rtx old_stack_level = 0; > @@ -1734,7 +1732,7 @@ expand_builtin_apply (rtx function, rtx > expand_builtin_return (rtx result) > { > int size, align, regno; > - machine_mode mode; > + fixed_size_mode mode; > rtx reg; > rtx_insn *call_fusage = 0; >
Richard Biener <richard.guenther@gmail.com> writes: > On Mon, Oct 23, 2017 at 1:22 PM, Richard Sandiford > <richard.sandiford@linaro.org> wrote: >> This patch adds a POD version of fixed_size_mode. The only current use >> is for storing the __builtin_apply and __builtin_result register modes, >> which were made fixed_size_modes by the previous patch. > > Bah - can we update our host compiler to C++11/14 please ...? > (maybe requiring that build with GCC 4.8 as host compiler works, > GCC 4.3 has -std=c++0x, but I'm quite sure that's not enough). That'd be great :-) It would avoid all the poly_int_pod stuff too, and allow some clean-up of wide-int.h. Thanks for the reviews, Richard > > Ok. > > Thanks, > Richard. > >> >> 2017-10-23 Richard Sandiford <richard.sandiford@linaro.org> >> Alan Hayward <alan.hayward@arm.com> >> David Sherwood <david.sherwood@arm.com> >> >> gcc/ >> * coretypes.h (fixed_size_mode): Declare. >> (fixed_size_mode_pod): New typedef. >> * builtins.h (target_builtins::x_apply_args_mode) >> (target_builtins::x_apply_result_mode): Change type to >> fixed_size_mode_pod. >> * builtins.c (apply_args_size, apply_result_size, result_vector) >> (expand_builtin_apply_args_1, expand_builtin_apply) >> (expand_builtin_return): Update accordingly. >> >> Index: gcc/coretypes.h >> =================================================================== >> --- gcc/coretypes.h 2017-09-11 17:10:58.656085547 +0100 >> +++ gcc/coretypes.h 2017-10-23 11:42:57.592545063 +0100 >> @@ -59,6 +59,7 @@ typedef const struct rtx_def *const_rtx; >> class scalar_int_mode; >> class scalar_float_mode; >> class complex_mode; >> +class fixed_size_mode; >> template<typename> class opt_mode; >> typedef opt_mode<scalar_mode> opt_scalar_mode; >> typedef opt_mode<scalar_int_mode> opt_scalar_int_mode; >> @@ -66,6 +67,7 @@ typedef opt_mode<scalar_float_mode> opt_ >> template<typename> class pod_mode; >> typedef pod_mode<scalar_mode> scalar_mode_pod; >> typedef pod_mode<scalar_int_mode> scalar_int_mode_pod; >> +typedef pod_mode<fixed_size_mode> fixed_size_mode_pod; >> >> /* Subclasses of rtx_def, using indentation to show the class >> hierarchy, along with the relevant invariant. >> Index: gcc/builtins.h >> =================================================================== >> --- gcc/builtins.h 2017-08-30 12:18:46.602740973 +0100 >> +++ gcc/builtins.h 2017-10-23 11:42:57.592545063 +0100 >> @@ -29,14 +29,14 @@ struct target_builtins { >> the register is not used for calling a function. If the machine >> has register windows, this gives only the outbound registers. >> INCOMING_REGNO gives the corresponding inbound register. */ >> - machine_mode x_apply_args_mode[FIRST_PSEUDO_REGISTER]; >> + fixed_size_mode_pod x_apply_args_mode[FIRST_PSEUDO_REGISTER]; >> >> /* For each register that may be used for returning values, this gives >> a mode used to copy the register's value. VOIDmode indicates the >> register is not used for returning values. If the machine has >> register windows, this gives only the outbound registers. >> INCOMING_REGNO gives the corresponding inbound register. */ >> - machine_mode x_apply_result_mode[FIRST_PSEUDO_REGISTER]; >> + fixed_size_mode_pod x_apply_result_mode[FIRST_PSEUDO_REGISTER]; >> }; >> >> extern struct target_builtins default_target_builtins; >> Index: gcc/builtins.c >> =================================================================== >> --- gcc/builtins.c 2017-10-23 11:41:23.140260335 +0100 >> +++ gcc/builtins.c 2017-10-23 11:42:57.592545063 +0100 >> @@ -1358,7 +1358,6 @@ apply_args_size (void) >> static int size = -1; >> int align; >> unsigned int regno; >> - machine_mode mode; >> >> /* The values computed by this function never change. */ >> if (size < 0) >> @@ -1374,7 +1373,7 @@ apply_args_size (void) >> for (regno = 0; regno < FIRST_PSEUDO_REGISTER; regno++) >> if (FUNCTION_ARG_REGNO_P (regno)) >> { >> - mode = targetm.calls.get_raw_arg_mode (regno); >> + fixed_size_mode mode = targetm.calls.get_raw_arg_mode (regno); >> >> gcc_assert (mode != VOIDmode); >> >> @@ -1386,7 +1385,7 @@ apply_args_size (void) >> } >> else >> { >> - apply_args_mode[regno] = VOIDmode; >> + apply_args_mode[regno] = as_a <fixed_size_mode> (VOIDmode); >> } >> } >> return size; >> @@ -1400,7 +1399,6 @@ apply_result_size (void) >> { >> static int size = -1; >> int align, regno; >> - machine_mode mode; >> >> /* The values computed by this function never change. */ >> if (size < 0) >> @@ -1410,7 +1408,7 @@ apply_result_size (void) >> for (regno = 0; regno < FIRST_PSEUDO_REGISTER; regno++) >> if (targetm.calls.function_value_regno_p (regno)) >> { >> - mode = targetm.calls.get_raw_result_mode (regno); >> + fixed_size_mode mode = targetm.calls.get_raw_result_mode (regno); >> >> gcc_assert (mode != VOIDmode); >> >> @@ -1421,7 +1419,7 @@ apply_result_size (void) >> apply_result_mode[regno] = mode; >> } >> else >> - apply_result_mode[regno] = VOIDmode; >> + apply_result_mode[regno] = as_a <fixed_size_mode> (VOIDmode); >> >> /* Allow targets that use untyped_call and untyped_return to override >> the size so that machine-specific information can be stored here. */ >> @@ -1440,7 +1438,7 @@ apply_result_size (void) >> result_vector (int savep, rtx result) >> { >> int regno, size, align, nelts; >> - machine_mode mode; >> + fixed_size_mode mode; >> rtx reg, mem; >> rtx *savevec = XALLOCAVEC (rtx, FIRST_PSEUDO_REGISTER); >> >> @@ -1469,7 +1467,7 @@ expand_builtin_apply_args_1 (void) >> { >> rtx registers, tem; >> int size, align, regno; >> - machine_mode mode; >> + fixed_size_mode mode; >> rtx struct_incoming_value = targetm.calls.struct_value_rtx (cfun ? TREE_TYPE (cfun->decl) : 0, 1); >> >> /* Create a block where the arg-pointer, structure value address, >> @@ -1573,7 +1571,7 @@ expand_builtin_apply_args (void) >> expand_builtin_apply (rtx function, rtx arguments, rtx argsize) >> { >> int size, align, regno; >> - machine_mode mode; >> + fixed_size_mode mode; >> rtx incoming_args, result, reg, dest, src; >> rtx_call_insn *call_insn; >> rtx old_stack_level = 0; >> @@ -1734,7 +1732,7 @@ expand_builtin_apply (rtx function, rtx >> expand_builtin_return (rtx result) >> { >> int size, align, regno; >> - machine_mode mode; >> + fixed_size_mode mode; >> rtx reg; >> rtx_insn *call_fusage = 0; >>
On Thu, Oct 26, 2017 at 2:18 PM, Richard Sandiford <richard.sandiford@linaro.org> wrote: > Richard Biener <richard.guenther@gmail.com> writes: >> On Mon, Oct 23, 2017 at 1:22 PM, Richard Sandiford >> <richard.sandiford@linaro.org> wrote: >>> This patch adds a POD version of fixed_size_mode. The only current use >>> is for storing the __builtin_apply and __builtin_result register modes, >>> which were made fixed_size_modes by the previous patch. >> >> Bah - can we update our host compiler to C++11/14 please ...? >> (maybe requiring that build with GCC 4.8 as host compiler works, >> GCC 4.3 has -std=c++0x, but I'm quite sure that's not enough). > > That'd be great :-) It would avoid all the poly_int_pod stuff too, > and allow some clean-up of wide-int.h. Can you figure what oldest GCC release supports the C++11/14 POD handling that would be required? Richard. > Thanks for the reviews, > Richard > > >> >> Ok. >> >> Thanks, >> Richard. >> >>> >>> 2017-10-23 Richard Sandiford <richard.sandiford@linaro.org> >>> Alan Hayward <alan.hayward@arm.com> >>> David Sherwood <david.sherwood@arm.com> >>> >>> gcc/ >>> * coretypes.h (fixed_size_mode): Declare. >>> (fixed_size_mode_pod): New typedef. >>> * builtins.h (target_builtins::x_apply_args_mode) >>> (target_builtins::x_apply_result_mode): Change type to >>> fixed_size_mode_pod. >>> * builtins.c (apply_args_size, apply_result_size, result_vector) >>> (expand_builtin_apply_args_1, expand_builtin_apply) >>> (expand_builtin_return): Update accordingly. >>> >>> Index: gcc/coretypes.h >>> =================================================================== >>> --- gcc/coretypes.h 2017-09-11 17:10:58.656085547 +0100 >>> +++ gcc/coretypes.h 2017-10-23 11:42:57.592545063 +0100 >>> @@ -59,6 +59,7 @@ typedef const struct rtx_def *const_rtx; >>> class scalar_int_mode; >>> class scalar_float_mode; >>> class complex_mode; >>> +class fixed_size_mode; >>> template<typename> class opt_mode; >>> typedef opt_mode<scalar_mode> opt_scalar_mode; >>> typedef opt_mode<scalar_int_mode> opt_scalar_int_mode; >>> @@ -66,6 +67,7 @@ typedef opt_mode<scalar_float_mode> opt_ >>> template<typename> class pod_mode; >>> typedef pod_mode<scalar_mode> scalar_mode_pod; >>> typedef pod_mode<scalar_int_mode> scalar_int_mode_pod; >>> +typedef pod_mode<fixed_size_mode> fixed_size_mode_pod; >>> >>> /* Subclasses of rtx_def, using indentation to show the class >>> hierarchy, along with the relevant invariant. >>> Index: gcc/builtins.h >>> =================================================================== >>> --- gcc/builtins.h 2017-08-30 12:18:46.602740973 +0100 >>> +++ gcc/builtins.h 2017-10-23 11:42:57.592545063 +0100 >>> @@ -29,14 +29,14 @@ struct target_builtins { >>> the register is not used for calling a function. If the machine >>> has register windows, this gives only the outbound registers. >>> INCOMING_REGNO gives the corresponding inbound register. */ >>> - machine_mode x_apply_args_mode[FIRST_PSEUDO_REGISTER]; >>> + fixed_size_mode_pod x_apply_args_mode[FIRST_PSEUDO_REGISTER]; >>> >>> /* For each register that may be used for returning values, this gives >>> a mode used to copy the register's value. VOIDmode indicates the >>> register is not used for returning values. If the machine has >>> register windows, this gives only the outbound registers. >>> INCOMING_REGNO gives the corresponding inbound register. */ >>> - machine_mode x_apply_result_mode[FIRST_PSEUDO_REGISTER]; >>> + fixed_size_mode_pod x_apply_result_mode[FIRST_PSEUDO_REGISTER]; >>> }; >>> >>> extern struct target_builtins default_target_builtins; >>> Index: gcc/builtins.c >>> =================================================================== >>> --- gcc/builtins.c 2017-10-23 11:41:23.140260335 +0100 >>> +++ gcc/builtins.c 2017-10-23 11:42:57.592545063 +0100 >>> @@ -1358,7 +1358,6 @@ apply_args_size (void) >>> static int size = -1; >>> int align; >>> unsigned int regno; >>> - machine_mode mode; >>> >>> /* The values computed by this function never change. */ >>> if (size < 0) >>> @@ -1374,7 +1373,7 @@ apply_args_size (void) >>> for (regno = 0; regno < FIRST_PSEUDO_REGISTER; regno++) >>> if (FUNCTION_ARG_REGNO_P (regno)) >>> { >>> - mode = targetm.calls.get_raw_arg_mode (regno); >>> + fixed_size_mode mode = targetm.calls.get_raw_arg_mode (regno); >>> >>> gcc_assert (mode != VOIDmode); >>> >>> @@ -1386,7 +1385,7 @@ apply_args_size (void) >>> } >>> else >>> { >>> - apply_args_mode[regno] = VOIDmode; >>> + apply_args_mode[regno] = as_a <fixed_size_mode> (VOIDmode); >>> } >>> } >>> return size; >>> @@ -1400,7 +1399,6 @@ apply_result_size (void) >>> { >>> static int size = -1; >>> int align, regno; >>> - machine_mode mode; >>> >>> /* The values computed by this function never change. */ >>> if (size < 0) >>> @@ -1410,7 +1408,7 @@ apply_result_size (void) >>> for (regno = 0; regno < FIRST_PSEUDO_REGISTER; regno++) >>> if (targetm.calls.function_value_regno_p (regno)) >>> { >>> - mode = targetm.calls.get_raw_result_mode (regno); >>> + fixed_size_mode mode = targetm.calls.get_raw_result_mode (regno); >>> >>> gcc_assert (mode != VOIDmode); >>> >>> @@ -1421,7 +1419,7 @@ apply_result_size (void) >>> apply_result_mode[regno] = mode; >>> } >>> else >>> - apply_result_mode[regno] = VOIDmode; >>> + apply_result_mode[regno] = as_a <fixed_size_mode> (VOIDmode); >>> >>> /* Allow targets that use untyped_call and untyped_return to override >>> the size so that machine-specific information can be stored here. */ >>> @@ -1440,7 +1438,7 @@ apply_result_size (void) >>> result_vector (int savep, rtx result) >>> { >>> int regno, size, align, nelts; >>> - machine_mode mode; >>> + fixed_size_mode mode; >>> rtx reg, mem; >>> rtx *savevec = XALLOCAVEC (rtx, FIRST_PSEUDO_REGISTER); >>> >>> @@ -1469,7 +1467,7 @@ expand_builtin_apply_args_1 (void) >>> { >>> rtx registers, tem; >>> int size, align, regno; >>> - machine_mode mode; >>> + fixed_size_mode mode; >>> rtx struct_incoming_value = targetm.calls.struct_value_rtx (cfun ? TREE_TYPE (cfun->decl) : 0, 1); >>> >>> /* Create a block where the arg-pointer, structure value address, >>> @@ -1573,7 +1571,7 @@ expand_builtin_apply_args (void) >>> expand_builtin_apply (rtx function, rtx arguments, rtx argsize) >>> { >>> int size, align, regno; >>> - machine_mode mode; >>> + fixed_size_mode mode; >>> rtx incoming_args, result, reg, dest, src; >>> rtx_call_insn *call_insn; >>> rtx old_stack_level = 0; >>> @@ -1734,7 +1732,7 @@ expand_builtin_apply (rtx function, rtx >>> expand_builtin_return (rtx result) >>> { >>> int size, align, regno; >>> - machine_mode mode; >>> + fixed_size_mode mode; >>> rtx reg; >>> rtx_insn *call_fusage = 0; >>>
> Can you figure what oldest GCC release supports the C++11/14 POD handling > that would be required? GCC needs to be buildable by other compilers than itself though. -- Eric Botcazou
Richard Biener <richard.guenther@gmail.com> writes: > On Thu, Oct 26, 2017 at 2:18 PM, Richard Sandiford > <richard.sandiford@linaro.org> wrote: >> Richard Biener <richard.guenther@gmail.com> writes: >>> On Mon, Oct 23, 2017 at 1:22 PM, Richard Sandiford >>> <richard.sandiford@linaro.org> wrote: >>>> This patch adds a POD version of fixed_size_mode. The only current use >>>> is for storing the __builtin_apply and __builtin_result register modes, >>>> which were made fixed_size_modes by the previous patch. >>> >>> Bah - can we update our host compiler to C++11/14 please ...? >>> (maybe requiring that build with GCC 4.8 as host compiler works, >>> GCC 4.3 has -std=c++0x, but I'm quite sure that's not enough). >> >> That'd be great :-) It would avoid all the poly_int_pod stuff too, >> and allow some clean-up of wide-int.h. > > Can you figure what oldest GCC release supports the C++11/14 POD handling > that would be required? Looks like GCC 4.7, which was also the first to support -std=c++11 as an option. I could bootstrap with that (after s/std=gnu..98/std=c++11/ in configure) without all the POD types. It also supports "= default" and template using, which would get rid of some wide-int.h ugliness. Being able to construct poly_int::coeffs directly might also allow some optimisations, and should help avoid the POLY_SET_COEFF bug that Martin found, but I haven't looked at that yet. Thanks, Richard
On Thu, Oct 26, 2017 at 02:43:55PM +0200, Richard Biener wrote: > On Thu, Oct 26, 2017 at 2:18 PM, Richard Sandiford > <richard.sandiford@linaro.org> wrote: > > Richard Biener <richard.guenther@gmail.com> writes: > >> On Mon, Oct 23, 2017 at 1:22 PM, Richard Sandiford > >> <richard.sandiford@linaro.org> wrote: > >>> This patch adds a POD version of fixed_size_mode. The only current use > >>> is for storing the __builtin_apply and __builtin_result register modes, > >>> which were made fixed_size_modes by the previous patch. > >> > >> Bah - can we update our host compiler to C++11/14 please ...? > >> (maybe requiring that build with GCC 4.8 as host compiler works, > >> GCC 4.3 has -std=c++0x, but I'm quite sure that's not enough). > > > > That'd be great :-) It would avoid all the poly_int_pod stuff too, > > and allow some clean-up of wide-int.h. > > Can you figure what oldest GCC release supports the C++11/14 POD handling > that would be required? I think it is too early for that, we aren't LLVM or Rust that don't really care about what build requirements they impose on users. Jakub
On Thu, Oct 26, 2017 at 9:37 PM, Eric Botcazou <ebotcazou@adacore.com> wrote: >> Can you figure what oldest GCC release supports the C++11/14 POD handling >> that would be required? > > GCC needs to be buildable by other compilers than itself though. There's always the possibility of building GCC 4.8 with the other compiler and then GCC 9+ (?) with GCC 4.8. What's the list of other compilers people routinely use? I see various comments on other compilers in install.texi but those are already saying those cannot be used to build GCC but you need to build an older GCC first (like xlc or the HP compiler). Richard. > -- > Eric Botcazou
On Thu, Oct 26, 2017 at 9:43 PM, Jakub Jelinek <jakub@redhat.com> wrote: > On Thu, Oct 26, 2017 at 02:43:55PM +0200, Richard Biener wrote: >> On Thu, Oct 26, 2017 at 2:18 PM, Richard Sandiford >> <richard.sandiford@linaro.org> wrote: >> > Richard Biener <richard.guenther@gmail.com> writes: >> >> On Mon, Oct 23, 2017 at 1:22 PM, Richard Sandiford >> >> <richard.sandiford@linaro.org> wrote: >> >>> This patch adds a POD version of fixed_size_mode. The only current use >> >>> is for storing the __builtin_apply and __builtin_result register modes, >> >>> which were made fixed_size_modes by the previous patch. >> >> >> >> Bah - can we update our host compiler to C++11/14 please ...? >> >> (maybe requiring that build with GCC 4.8 as host compiler works, >> >> GCC 4.3 has -std=c++0x, but I'm quite sure that's not enough). >> > >> > That'd be great :-) It would avoid all the poly_int_pod stuff too, >> > and allow some clean-up of wide-int.h. >> >> Can you figure what oldest GCC release supports the C++11/14 POD handling >> that would be required? > > I think it is too early for that, we aren't LLVM or Rust that don't really > care about what build requirements they impose on users. That's true, which is why I asked. For me requiring sth newer than GCC 4.8 would be a blocker given that's the system compiler on our latest server (and "stable" OSS) product. I guess it depends on the amount of pain we have going forward with C++ use in GCC. Given that gdb already requires C++11 people building GCC are likely already experiencing the "issue". Richard. > Jakub
On Fri, Oct 27, 2017 at 10:35:56AM +0200, Richard Biener wrote: > > I think it is too early for that, we aren't LLVM or Rust that don't really > > care about what build requirements they impose on users. > > That's true, which is why I asked. For me requiring sth newer than GCC 4.8 > would be a blocker given that's the system compiler on our latest server > (and "stable" OSS) product. > > I guess it depends on the amount of pain we have going forward with C++ > use in GCC. Given that gdb already requires C++11 people building > GCC are likely already experiencing the "issue". Well, they can always start by building a new GCC and then build GDB with it. If they'd need to build an intermediate, already unsupported, GCC in between as well, it might be bigger pain. GCC 4.8 as system compiler certainly needs to be supported, it is still heavily used in the wild, but I'd say even e.g. GCC 4.4 or 4.3 isn't something that can be ignored. And there are also non-GCC system compilers we need to cope with. Jakub
> There's always the possibility of building GCC 4.8 with the other compiler > and then GCC 9+ (?) with GCC 4.8. What an user-friendly solution... > What's the list of other compilers people routinely use? I see various > comments on other compilers in install.texi but those are already saying > those cannot be used to build GCC but you need to build an older GCC first > (like xlc or the HP compiler). I read the opposite for XLC: "GCC can bootstrap with recent versions of IBM XLC, but bootstrapping with an earlier release of GCC is recommended." I think that the major supported compilers are IBM, Sun/Oracle and LLVM. -- Eric Botcazou
On 10/27/2017 09:35 AM, Richard Biener wrote: > On Thu, Oct 26, 2017 at 9:43 PM, Jakub Jelinek <jakub@redhat.com> wrote: >> On Thu, Oct 26, 2017 at 02:43:55PM +0200, Richard Biener wrote: >>> Can you figure what oldest GCC release supports the C++11/14 POD handling >>> that would be required? >> >> I think it is too early for that, we aren't LLVM or Rust that don't really >> care about what build requirements they impose on users. > > That's true, which is why I asked. For me requiring sth newer than GCC 4.8 > would be a blocker given that's the system compiler on our latest server > (and "stable" OSS) product. > > I guess it depends on the amount of pain we have going forward with C++ > use in GCC. Given that gdb already requires C++11 people building > GCC are likely already experiencing the "issue". Right, GDB's baseline is GCC 4.8 too. When GDB was deciding whether to start requiring full C++11 (about a year ago), we looked at the latest stable release of all the "big" distros to see whether: #1 - the system compiler was new enough (gcc >= 4.8), or failing that, #2 - whether there's an easy to install package providing a new-enough compiler. and it turns out that that was true for all. Meanwhile another year has passed and there have been no complaints. Thanks, Pedro Alves
On 10/27/2017 02:35 AM, Richard Biener wrote: > On Thu, Oct 26, 2017 at 9:43 PM, Jakub Jelinek <jakub@redhat.com> wrote: >> On Thu, Oct 26, 2017 at 02:43:55PM +0200, Richard Biener wrote: >>> On Thu, Oct 26, 2017 at 2:18 PM, Richard Sandiford >>> <richard.sandiford@linaro.org> wrote: >>>> Richard Biener <richard.guenther@gmail.com> writes: >>>>> On Mon, Oct 23, 2017 at 1:22 PM, Richard Sandiford >>>>> <richard.sandiford@linaro.org> wrote: >>>>>> This patch adds a POD version of fixed_size_mode. The only current use >>>>>> is for storing the __builtin_apply and __builtin_result register modes, >>>>>> which were made fixed_size_modes by the previous patch. >>>>> >>>>> Bah - can we update our host compiler to C++11/14 please ...? >>>>> (maybe requiring that build with GCC 4.8 as host compiler works, >>>>> GCC 4.3 has -std=c++0x, but I'm quite sure that's not enough). >>>> >>>> That'd be great :-) It would avoid all the poly_int_pod stuff too, >>>> and allow some clean-up of wide-int.h. >>> >>> Can you figure what oldest GCC release supports the C++11/14 POD handling >>> that would be required? >> >> I think it is too early for that, we aren't LLVM or Rust that don't really >> care about what build requirements they impose on users. > > That's true, which is why I asked. For me requiring sth newer than GCC 4.8 > would be a blocker given that's the system compiler on our latest server > (and "stable" OSS) product. > > I guess it depends on the amount of pain we have going forward with C++ > use in GCC. Given that gdb already requires C++11 people building > GCC are likely already experiencing the "issue". It's always going to be a balancing act. Clearly we don't want to go to something like the Rust model. But we also don't want to limit ourselves to such old tools that we end up hacking around compiler bugs or avoiding features that can make the codebase easier to maintain and improve or end up depending on dusty corners of C++98/C++03 implementations that nobody else uses/tests anymore because they've moved on to C++11. To be more concrete, if I had to put a stake in the ground. I'd want to pick a semi- recent version of Sun, IBM and Clang/LLVM as well as GCC. Ideally it'd be something that supports C++11 as a language, even if the runtime isn't fully compliant. I suspect anything older than GCC 4.8 wouldn't have enough C++11 and anything newer to not work well for the distros (Red Hat included). Jeff
On Thu, Oct 26, 2017 at 09:37:31PM +0200, Eric Botcazou wrote: > > Can you figure what oldest GCC release supports the C++11/14 POD handling > > that would be required? > > GCC needs to be buildable by other compilers than itself though. It sounds like people are mostly concerned about sun studio and xlc? It doesn't seem that hard to provide precompiled binaries for those two platforms, and maybe 4.8 binaries for people who want to compile theire own gcc from source. If that would be enough to deal with people concerns it seems doable by next stage 1? Trev > > -- > Eric Botcazou
Trevor Saunders <tbsaunde@tbsaunde.org> writes: > On Thu, Oct 26, 2017 at 09:37:31PM +0200, Eric Botcazou wrote: >> > Can you figure what oldest GCC release supports the C++11/14 POD handling >> > that would be required? >> >> GCC needs to be buildable by other compilers than itself though. > > It sounds like people are mostly concerned about sun studio and xlc? It > doesn't seem that hard to provide precompiled binaries for those two > platforms, and maybe 4.8 binaries for people who want to compile theire > own gcc from source. If that would be enough to deal with people > concerns it seems doable by next stage 1? Would it be worth supporting a 4-stage bootstrap, with stage 0 being built from older gcc sources? We could include a contrib/ script that downloads sources for gcc-4.7 or whatever and patches it to build with modern as well as old compilers. (When I tried gcc-4.7 last week, I needed a couple of tweaks to get it to build.) Not that I'd have time try that before GCC 9... Thanks, Richard
> It sounds like people are mostly concerned about sun studio and xlc? It > doesn't seem that hard to provide precompiled binaries for those two > platforms, and maybe 4.8 binaries for people who want to compile theire > own gcc from source. I'm not sure that we want to enter the business of precompiled binaries. Moreover, if we want people to contribute to GCC's development, especially occasionally to fix a couple of bugs, we need to make it easier to build the compiler, not the other way around. -- Eric Botcazou
On Mon, Oct 30, 2017 at 11:11:12AM +0100, Eric Botcazou wrote: > > It sounds like people are mostly concerned about sun studio and xlc? It > > doesn't seem that hard to provide precompiled binaries for those two > > platforms, and maybe 4.8 binaries for people who want to compile theire > > own gcc from source. > > I'm not sure that we want to enter the business of precompiled binaries. I don't see a reason not to other than a pretty small amount of work each time we make a release. > Moreover, if we want people to contribute to GCC's development, especially > occasionally to fix a couple of bugs, we need to make it easier to build the > compiler, not the other way around. Well first this would only matter to the 0.01% of people who want to do that on AIX or Solaris machines, not the vast majority of possible contributors who already use clang or gcc as there system compiler. Secondly downloading a tarball isn't very difficult and arguably providing them makes it easier for people to test gcc on those systems without having to build it themselves. Thirdly making it easier to work on the compiler and understand it makes things easier for those possible contributors, so if being able to use C++11 advances that goalthings could be better over all for possible contributors with different system compilers. Trev > > -- > Eric Botcazou
> I don't see a reason not to other than a pretty small amount of work > each time we make a release. I'm not sure it would be so small an amount of work, especially on non-Linux platforms, so this would IMO divert our resources for little benefit. > Well first this would only matter to the 0.01% of people who want to do > that on AIX or Solaris machines, not the vast majority of possible > contributors who already use clang or gcc as there system compiler. Yes, but we're GCC, not Clang, and we support more than Linux and Darwin. > Thirdly making it easier to work on the compiler and understand it makes > things easier for those possible contributors, so if being able to use > C++11 advances that goalthings could be better over all for possible > contributors with different system compilers. I don't buy this at all. You don't need bleeding edge C++ features to build a compiler and people don't work on compilers to use bleeding edge C++. Using a narrow and sensible set of C++ features was one of the conditions under which the switch to C++ as implementation language was accepted at the time. -- Eric Botcazou
On 10/31/2017 11:22 AM, Eric Botcazou wrote: >> I don't see a reason not to other than a pretty small amount of work >> each time we make a release. > > I'm not sure it would be so small an amount of work, especially on non-Linux > platforms, so this would IMO divert our resources for little benefit. Having done this for years on HPUX, yes, it takes more time than one could imagine. THen I went to work for a company that did this for hpux, solaris, aix, irix and others and well, it was very painful. > >> Well first this would only matter to the 0.01% of people who want to do >> that on AIX or Solaris machines, not the vast majority of possible >> contributors who already use clang or gcc as there system compiler. > > Yes, but we're GCC, not Clang, and we support more than Linux and Darwin. Very true. > >> Thirdly making it easier to work on the compiler and understand it makes >> things easier for those possible contributors, so if being able to use >> C++11 advances that goalthings could be better over all for possible >> contributors with different system compilers. > > I don't buy this at all. You don't need bleeding edge C++ features to build a > compiler and people don't work on compilers to use bleeding edge C++. Using a > narrow and sensible set of C++ features was one of the conditions under which > the switch to C++ as implementation language was accepted at the time. Agreed that we need to stick with a sensible set of features. But the sensible set isn't necessarily fixed forever. Jeff
On Tue, Oct 31, 2017 at 11:38:48AM -0600, Jeff Law wrote: > On 10/31/2017 11:22 AM, Eric Botcazou wrote: > >> I don't see a reason not to other than a pretty small amount of work > >> each time we make a release. > > > > I'm not sure it would be so small an amount of work, especially on non-Linux > > platforms, so this would IMO divert our resources for little benefit. > Having done this for years on HPUX, yes, it takes more time than one > could imagine. THen I went to work for a company that did this for > hpux, solaris, aix, irix and others and well, it was very painful. I'm sure its a project one can spend arbitrary amounts of time on if one wishes or is payed to do so. That said I'm considering the scope here limitted to running configure / make / make install with the defaults and taring up the result. I'll admitt I've only done that on linux where it was easy, but people do keep AIX and Solaris building and they really are supposed to be buildable in a release. However at some point it can be less work to do this than to beat C++98 into doing what is desired. > >> Well first this would only matter to the 0.01% of people who want to do > >> that on AIX or Solaris machines, not the vast majority of possible > >> contributors who already use clang or gcc as there system compiler. > > > > Yes, but we're GCC, not Clang, and we support more than Linux and Darwin. > Very true. certainly, but I think it makes sense to understand how many people might be negatively effected by a change, and to what degree before making that decision. > >> Thirdly making it easier to work on the compiler and understand it makes > >> things easier for those possible contributors, so if being able to use > >> C++11 advances that goalthings could be better over all for possible > >> contributors with different system compilers. > > > > I don't buy this at all. You don't need bleeding edge C++ features to build a > > compiler and people don't work on compilers to use bleeding edge C++. Using a > > narrow and sensible set of C++ features was one of the conditions under which > > the switch to C++ as implementation language was accepted at the time. > Agreed that we need to stick with a sensible set of features. But the > sensible set isn't necessarily fixed forever. Also as a counter example what brought this thread up is Richard wanting to use something from C++11. So in that particular case it probably would make something better. thanks Trev > > Jeff
On 10/31/2017 08:47 PM, Trevor Saunders wrote: > On Tue, Oct 31, 2017 at 11:38:48AM -0600, Jeff Law wrote: >> On 10/31/2017 11:22 AM, Eric Botcazou wrote: >>>> I don't see a reason not to other than a pretty small amount of work >>>> each time we make a release. >>> >>> I'm not sure it would be so small an amount of work, especially on non-Linux >>> platforms, so this would IMO divert our resources for little benefit. >> Having done this for years on HPUX, yes, it takes more time than one >> could imagine. THen I went to work for a company that did this for >> hpux, solaris, aix, irix and others and well, it was very painful. > > I'm sure its a project one can spend arbitrary amounts of time on if one > wishes or is payed to do so. That said I'm considering the scope here > limitted to running configure / make / make install with the defaults > and taring up the result. I'll admitt I've only done that on linux > where it was easy, but people do keep AIX and Solaris building and they > really are supposed to be buildable in a release. However at some point > it can be less work to do this than to beat C++98 into doing what is > desired. It sounds so easy, but it does get more complex than just build and tar the result up. How (for example) do you handle DSOs that may or may not be on the system where the bits get installed. Do you embed them or tell the user to go get them? That's just one example of a gotcha, there's many. It's really not something I'd suggest we pursue all that deeply. Been there, done that wouldn't want to do it again. >>>> Thirdly making it easier to work on the compiler and understand it makes >>>> things easier for those possible contributors, so if being able to use >>>> C++11 advances that goalthings could be better over all for possible >>>> contributors with different system compilers. >>> >>> I don't buy this at all. You don't need bleeding edge C++ features to build a >>> compiler and people don't work on compilers to use bleeding edge C++. Using a >>> narrow and sensible set of C++ features was one of the conditions under which >>> the switch to C++ as implementation language was accepted at the time. >> Agreed that we need to stick with a sensible set of features. But the >> sensible set isn't necessarily fixed forever. > > Also as a counter example what brought this thread up is Richard wanting > to use something from C++11. So in that particular case it probably > would make something better. In my particular case I could use certain C++11 features to make the code cleaner/easier to prove right -- particularly rvalue references and move semantics. I've got an object with a chunk of allocated memory. I want to move ownership of the memory to another object. C++11 handles this cleanly and gracefully and in doing so makes it very hard to get it wrong. However, I don't think my case, in and of itself, is enough to push us into the C++11 world. Nor am I convinced that the aggregate of these things is enough to push us into the C++11 world. But I do think we'll be there at some point. jeff
On Wed, Nov 01, 2017 at 10:30:29AM -0600, Jeff Law wrote: > On 10/31/2017 08:47 PM, Trevor Saunders wrote: > > On Tue, Oct 31, 2017 at 11:38:48AM -0600, Jeff Law wrote: > > > On 10/31/2017 11:22 AM, Eric Botcazou wrote: > > > > > I don't see a reason not to other than a pretty small amount of work > > > > > each time we make a release. > > > > > > > > I'm not sure it would be so small an amount of work, especially on non-Linux > > > > platforms, so this would IMO divert our resources for little benefit. > > > Having done this for years on HPUX, yes, it takes more time than one > > > could imagine. THen I went to work for a company that did this for > > > hpux, solaris, aix, irix and others and well, it was very painful. > > > > I'm sure its a project one can spend arbitrary amounts of time on if one > > wishes or is payed to do so. That said I'm considering the scope here > > limitted to running configure / make / make install with the defaults > > and taring up the result. I'll admitt I've only done that on linux > > where it was easy, but people do keep AIX and Solaris building and they > > really are supposed to be buildable in a release. However at some point > > it can be less work to do this than to beat C++98 into doing what is > > desired. > It sounds so easy, but it does get more complex than just build and tar the > result up. How (for example) do you handle DSOs that may or may not be on > the system where the bits get installed. Do you embed them or tell the user > to go get them? That's just one example of a gotcha, there's many. > > It's really not something I'd suggest we pursue all that deeply. Been > there, done that wouldn't want to do it again. > > > > > > Thirdly making it easier to work on the compiler and understand it makes > > > > > things easier for those possible contributors, so if being able to use > > > > > C++11 advances that goalthings could be better over all for possible > > > > > contributors with different system compilers. > > > > > > > > I don't buy this at all. You don't need bleeding edge C++ features to build a > > > > compiler and people don't work on compilers to use bleeding edge C++. Using a > > > > narrow and sensible set of C++ features was one of the conditions under which > > > > the switch to C++ as implementation language was accepted at the time. > > > Agreed that we need to stick with a sensible set of features. But the > > > sensible set isn't necessarily fixed forever. > > > > Also as a counter example what brought this thread up is Richard wanting > > to use something from C++11. So in that particular case it probably > > would make something better. > In my particular case I could use certain C++11 features to make the code > cleaner/easier to prove right -- particularly rvalue references and move > semantics. I've got an object with a chunk of allocated memory. I want to > move ownership of the memory to another object. > > C++11 handles this cleanly and gracefully and in doing so makes it very hard > to get it wrong. You may want to look at how the unique_ptr shim deals with that, though maybe you don't want to copy the ifdef hackery to actually use rval refs when possible. Trev > > However, I don't think my case, in and of itself, is enough to push us into > the C++11 world. Nor am I convinced that the aggregate of these things is > enough to push us into the C++11 world. But I do think we'll be there at > some point. > > jeff
Index: gcc/coretypes.h =================================================================== --- gcc/coretypes.h 2017-09-11 17:10:58.656085547 +0100 +++ gcc/coretypes.h 2017-10-23 11:42:57.592545063 +0100 @@ -59,6 +59,7 @@ typedef const struct rtx_def *const_rtx; class scalar_int_mode; class scalar_float_mode; class complex_mode; +class fixed_size_mode; template<typename> class opt_mode; typedef opt_mode<scalar_mode> opt_scalar_mode; typedef opt_mode<scalar_int_mode> opt_scalar_int_mode; @@ -66,6 +67,7 @@ typedef opt_mode<scalar_float_mode> opt_ template<typename> class pod_mode; typedef pod_mode<scalar_mode> scalar_mode_pod; typedef pod_mode<scalar_int_mode> scalar_int_mode_pod; +typedef pod_mode<fixed_size_mode> fixed_size_mode_pod; /* Subclasses of rtx_def, using indentation to show the class hierarchy, along with the relevant invariant. Index: gcc/builtins.h =================================================================== --- gcc/builtins.h 2017-08-30 12:18:46.602740973 +0100 +++ gcc/builtins.h 2017-10-23 11:42:57.592545063 +0100 @@ -29,14 +29,14 @@ struct target_builtins { the register is not used for calling a function. If the machine has register windows, this gives only the outbound registers. INCOMING_REGNO gives the corresponding inbound register. */ - machine_mode x_apply_args_mode[FIRST_PSEUDO_REGISTER]; + fixed_size_mode_pod x_apply_args_mode[FIRST_PSEUDO_REGISTER]; /* For each register that may be used for returning values, this gives a mode used to copy the register's value. VOIDmode indicates the register is not used for returning values. If the machine has register windows, this gives only the outbound registers. INCOMING_REGNO gives the corresponding inbound register. */ - machine_mode x_apply_result_mode[FIRST_PSEUDO_REGISTER]; + fixed_size_mode_pod x_apply_result_mode[FIRST_PSEUDO_REGISTER]; }; extern struct target_builtins default_target_builtins; Index: gcc/builtins.c =================================================================== --- gcc/builtins.c 2017-10-23 11:41:23.140260335 +0100 +++ gcc/builtins.c 2017-10-23 11:42:57.592545063 +0100 @@ -1358,7 +1358,6 @@ apply_args_size (void) static int size = -1; int align; unsigned int regno; - machine_mode mode; /* The values computed by this function never change. */ if (size < 0) @@ -1374,7 +1373,7 @@ apply_args_size (void) for (regno = 0; regno < FIRST_PSEUDO_REGISTER; regno++) if (FUNCTION_ARG_REGNO_P (regno)) { - mode = targetm.calls.get_raw_arg_mode (regno); + fixed_size_mode mode = targetm.calls.get_raw_arg_mode (regno); gcc_assert (mode != VOIDmode); @@ -1386,7 +1385,7 @@ apply_args_size (void) } else { - apply_args_mode[regno] = VOIDmode; + apply_args_mode[regno] = as_a <fixed_size_mode> (VOIDmode); } } return size; @@ -1400,7 +1399,6 @@ apply_result_size (void) { static int size = -1; int align, regno; - machine_mode mode; /* The values computed by this function never change. */ if (size < 0) @@ -1410,7 +1408,7 @@ apply_result_size (void) for (regno = 0; regno < FIRST_PSEUDO_REGISTER; regno++) if (targetm.calls.function_value_regno_p (regno)) { - mode = targetm.calls.get_raw_result_mode (regno); + fixed_size_mode mode = targetm.calls.get_raw_result_mode (regno); gcc_assert (mode != VOIDmode); @@ -1421,7 +1419,7 @@ apply_result_size (void) apply_result_mode[regno] = mode; } else - apply_result_mode[regno] = VOIDmode; + apply_result_mode[regno] = as_a <fixed_size_mode> (VOIDmode); /* Allow targets that use untyped_call and untyped_return to override the size so that machine-specific information can be stored here. */ @@ -1440,7 +1438,7 @@ apply_result_size (void) result_vector (int savep, rtx result) { int regno, size, align, nelts; - machine_mode mode; + fixed_size_mode mode; rtx reg, mem; rtx *savevec = XALLOCAVEC (rtx, FIRST_PSEUDO_REGISTER); @@ -1469,7 +1467,7 @@ expand_builtin_apply_args_1 (void) { rtx registers, tem; int size, align, regno; - machine_mode mode; + fixed_size_mode mode; rtx struct_incoming_value = targetm.calls.struct_value_rtx (cfun ? TREE_TYPE (cfun->decl) : 0, 1); /* Create a block where the arg-pointer, structure value address, @@ -1573,7 +1571,7 @@ expand_builtin_apply_args (void) expand_builtin_apply (rtx function, rtx arguments, rtx argsize) { int size, align, regno; - machine_mode mode; + fixed_size_mode mode; rtx incoming_args, result, reg, dest, src; rtx_call_insn *call_insn; rtx old_stack_level = 0; @@ -1734,7 +1732,7 @@ expand_builtin_apply (rtx function, rtx expand_builtin_return (rtx result) { int size, align, regno; - machine_mode mode; + fixed_size_mode mode; rtx reg; rtx_insn *call_fusage = 0;