On 05/31/2017 01:46 PM, Richard Biener wrote:
> On Wed, May 31, 2017 at 1:33 PM, Jakub Jelinek <ja...@redhat.com> wrote:
>> On Wed, May 31, 2017 at 01:24:47PM +0200, Martin Liška wrote:
>>> On 05/31/2017 10:35 AM, Jakub Jelinek wrote:
>>>> On Wed, May 31, 2017 at 10:04:53AM +0200, Martin Liška wrote:
>>>>> diff --git a/gcc/common.opt b/gcc/common.opt
>>>>> index 13305558d2d..5e9942d5100 100644
>>>>> --- a/gcc/common.opt
>>>>> +++ b/gcc/common.opt
>>>>> @@ -222,9 +222,13 @@ bool flag_opts_finished
>>>>>  Variable
>>>>>  unsigned int flag_sanitize
>>>>>
>>>>> +###
>>>>> +Common RejectNegative Joined UInteger Var(flag_no_sanitize_fn) 
>>>>> PerFunction
>>>>> +No sanitize flags for a function
>>>>
>>>> This looks weird, you are redefining the -### option which is normally
>>>> a driver option.
>>>
>>> I know. I was thinking that it's also a 'dummy' value.
>>
>> It is not.
>>
>>>> I would have thought you just want a Variable, like the one right below
>>>> this.  Aren't all "Variable"s per-function?
>>>
>>> Unfortunately not. Well, probably adding new type 'PerFunctionVariable' 
>>> would be
>>> solution. Then optc-save-gen.awk needs to be learned how to save/restore 
>>> these variables.
>>>
>>> Is it the way we want to go?
>>
>> Yes.  We already have TargetVariable.  Or allow specifying
>> Variable PerFunction
>>
>> CCing Joseph as option handling maintainer.
> 
> Just wanting to add that "ab-"using options/variables to implement
> what are really
> function attributes doesn't look very clean.  Unless the plan is to get rid of
> function attributes in favor of per-function options.

Well, that was what I did in my original version of the patch. I basically 
transformed
all no_sanitize_address, no_sanitize_undefined and others to a single 
DECL_ATTRIBUTE
called 'no_sanitize' where I masked in integer all these. Feedback I was given 
by Jakub
recommended me to not to do it.

> 
> I'll also note that eventually global variables may want to be no-sanitized
> (for asan maybe).  And we don't (yet) have per-variable options.

Good remark.

Martin

> 
> Richard.
> 
>>         Jakub

Reply via email to