On 07/24/2018 04:29 AM, tamar.christ...@arm.com wrote: > Hi All, > > This patch is re-spun to handle the configure changes in patch 4 / 6 of the > previous series. > > This patch now changes it so that default parameters are validated during > initialization. This change is needed to ensure parameters set via by the > target specific common initialization routines still keep the parameters > within > the valid range. > > Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu and no > issues. > Both targets were tested with stack clash on and off by default. > > Ok for trunk? > > Thanks, > Tamar > > gcc/ > 2018-07-24 Tamar Christina <tamar.christ...@arm.com> > > * params.c (validate_param): New. > (add_params): Use it. > (set_param_value): Refactor param validation into validate_param. > (diagnostic.h): Include. > * diagnostic.h (diagnostic_ready_p): New. > >> -----Original Message----- >> From: Jeff Law <l...@redhat.com> >> Sent: Wednesday, July 11, 2018 20:24 >> To: Tamar Christina <tamar.christ...@arm.com>; gcc-patches@gcc.gnu.org >> Cc: nd <n...@arm.com>; jos...@codesourcery.com >> Subject: Re: [PATCH][GCC][front-end][opt-framework] Update options >> framework for parameters to properly handle and validate configure time >> params. [Patch (2/3)] >> >> On 07/11/2018 05:24 AM, Tamar Christina wrote: >>> Hi All, >>> >>> This patch builds on a previous patch to pass param options down from >>> configure by adding more expansive validation and correctness checks. >>> >>> These are set very early on and allow the target to validate or reject >>> the values as they see fit. >>> >>> To do this compiler_param has been extended to hold a value set at >>> configure time, this value is used to be able to distinguish between >>> >>> 1) default value >>> 2) configure value >>> 3) back-end default >>> 4) user specific value. >>> >>> The priority of the values should be 4 > 2 > 3 > 1. The compiler will >>> now also validate the values in params.def after setting them. This >>> means invalid values will no longer be accepted. >>> >>> This also changes it so that default parameters are validated during >>> initialization. This change is needed to ensure parameters set via >>> configure or by the target specific common initialization routines >>> still keep the parameters within the valid range. >>> >>> Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu >> and no issues. >>> Both targets were tested with stack clash on and off by default. >>> >>> Ok for trunk? >>> >>> Thanks, >>> Tamar >>> >>> gcc/ >>> 2018-07-11 Tamar Christina <tamar.christ...@arm.com> >>> >>> * params.h (struct param_info): Add configure_value. >>> * params.c (DEFPARAMCONF): New. >>> (DEFPARAM, DEFPARAMENUM5): Set configure_value. >>> (validate_param): New. >>> (add_params): Use it. >>> (set_param_value): Refactor param validation into validate_param. >>> (maybe_set_param_value): Don't override value from configure. >>> (diagnostic.h): Include. >>> * params-enum.h (DEFPARAMCONF): New. >>> * params-list.h: Likewise. >>> * params-options.h: Likewise. >>> * params.def (PARAM_STACK_CLASH_PROTECTION_GUARD_SIZE): >> Use it. >>> * diagnostic.h (diagnostic_ready_p): New. >> Generally OK, though probably should depend on what we decide WRT >> configurability. ie, I'm not convinced we need to be able to set the default >> via a configure time option. And if we don't support that this patch gets >> somewhat simpler. >> >> jeff > > > rb9153-2.patch [ ... ] I think this is fine now.
jeff
