Here is an updated patch (version #2). The main differences are: - Change attribute and option names; - Add additional parameter to gimple_build_call_from_tree by adding a type parameter and use it 'nocf_check' attribute propagation; - Reimplement fixes in expand_call_stmt to propagate 'nocf_check' attribute; - Consider 'nocf_check' attribute in Identical Code Folding (ICF) optimization; - Add warning for type inconsistency regarding 'nocf_check' attribute; - Many small fixes; gcc/c-family/ * c-attribs.c (handle_nocf_check_attribute): New function. (c_common_attribute_table): Add 'nocf_check' handling. * c-common.c (check_missing_format_attribute): New function. * c-common.h: Likewise. gcc/c/ * c-typeck.c (convert_for_assignment): Add check for nocf_check attribute. * gimple-parser.c: Add second argument NULL to gimple_build_call_from_tree. gcc/cp/ * typeck.c (convert_for_assignment): Add check for nocf_check attribute. gcc/ * cfgexpand.c (expand_call_stmt): Set REG_CALL_NOCF_CHECK for call insn. * combine.c (distribute_notes): Add REG_CALL_NOCF_CHECK handling. * common.opt: Add fcf-protection flag. * emit-rtl.c (try_split): Add REG_CALL_NOCF_CHECK handling. * flag-types.h: Add enum cf_protection_level. * gimple.c (gimple_build_call_from_tree): Add second parameter. Add 'nocf_check' attribute propagation to gimple call. * gimple.h (gf_mask): Add GF_CALL_NOCF_CHECK. (gimple_call_nocf_check_p): New function. (gimple_call_set_nocf_check): Likewise. * gimplify.c: Add second argument to gimple_build_call_from_tree. * ipa-icf.c: Add nocf_check attribute in statement hash. * recog.c (peep2_attempt): Add REG_CALL_NOCF_CHECK handling. * reg-notes.def: Add REG_NOTE (CALL_NOCF_CHECK). * toplev.c (process_options): Add flag_cf_protection handling. Is it ok for trunk? Thanks, Igor > -----Original Message----- > From: Richard Biener [mailto:richard.guenther@gmail.com] > Sent: Friday, September 15, 2017 2:14 PM > To: Tsimbalist, Igor V > Cc: gcc-patches@gcc.gnu.org > Subject: Re: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling > > On Fri, Sep 15, 2017 at 1:12 PM, Tsimbalist, Igor V > wrote: > >> -----Original Message----- > >> From: Tsimbalist, Igor V > >> Sent: Tuesday, September 12, 2017 5:35 PM > >> To: 'Richard Biener' > >> Cc: 'gcc-patches@gcc.gnu.org' ; Tsimbalist, > >> Igor V > >> Subject: RE: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling > >> > >> > -----Original Message----- > >> > From: Tsimbalist, Igor V > >> > Sent: Friday, August 18, 2017 4:43 PM > >> > To: 'Richard Biener' > >> > Cc: gcc-patches@gcc.gnu.org; Tsimbalist, Igor V > >> > > >> > Subject: RE: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling > >> > > >> > > -----Original Message----- > >> > > From: Richard Biener [mailto:richard.guenther@gmail.com] > >> > > Sent: Friday, August 18, 2017 3:53 PM > >> > > To: Tsimbalist, Igor V > >> > > Cc: gcc-patches@gcc.gnu.org > >> > > Subject: Re: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling > >> > > > >> > > On Fri, Aug 18, 2017 at 3:11 PM, Tsimbalist, Igor V > >> > > wrote: > >> > > >> -----Original Message----- > >> > > >> From: Richard Biener [mailto:richard.guenther@gmail.com] > >> > > >> Sent: Tuesday, August 15, 2017 3:43 PM > >> > > >> To: Tsimbalist, Igor V > >> > > >> Cc: gcc-patches@gcc.gnu.org > >> > > >> Subject: Re: > >> > > >> 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling > >> > > >> > >> > > >> On Tue, Aug 1, 2017 at 10:56 AM, Tsimbalist, Igor V > >> > > >> wrote: > >> > > >> > Part#1. Add generic part for Intel CET enabling. > >> > > >> > > >> > > >> > The spec is available at > >> > > >> > > >> > > >> > https://software.intel.com/sites/default/files/managed/4d/2a > >> > > >> > /co nt ro l-f low-enforcement-technology-preview.pdf > > > > <..skipped..> > > > >> > > >> I think 'notrack' is somewhat unspecific of a name, what > >> > > >> prevented you to use 'nocet'? > >> > > > > >> > > > Actually it's specific. The HW will have a prefix with exactly > >> > > > this name and > >> > > the same meaning. And I think, what is more important, > 'track/notrack' > >> > > gives better semantic for a user. CET is a name bound with Intel > >> > > specific technology. > >> > > > >> > > But 'tracking' something is quite unspecific. Tracking for what? > >> > > 'no_verify_cf' (aka do not verify control flow) maybe? > >> > > >> > The name just has to suggest the right semantic. 'no_verify_cf' is > >> > good, let's use it unless different name appears. > >> I have renamed all newly introduced function and macro names to use > >> 'noverify_cf'. But I still keep the attribute name as 'notrack'. > >> Historically the attribute name follows the public CET specification, > >> which uses 'no-track prefix' wording. Is it ok to keep such attribute name? > > > > Here is an updated proposal about option name and attribute name. > > > > The new option has values to let a user to choose what control-flow > protection to activate. > > > > -fcf-protection=[full|branch|return|none] > > branch - do control-flow protection for indirect jumps and calls > > return - do control-flow protection for function returns > > full - alias to specify both branch + return > > none - turn off protection. This value is needed when/if > > cf-protection is turned on by default by driver in future > > > > Attribute name is the most tough one. Here are several names to evaluate: > 'nocf_verify' or 'nocf_check', or to be more specific and to mimic option > name 'nocf_branch_verify' or 'nocf_branch_check'. I would prefer > 'nocf_check' as it applies to functions and function pointers so it's definitely > related to a branch and it's a smaller one. > > > > If you ok with the new proposal I'll implement it in a general parts (code, > documentation and tests) and resend these patches for review. > > nocf_check sounds fine to me. > > Richard. > > > Thanks, > > Igor > >