This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PING #2] [PATCH] enhance -Wrestrict to handle string built-ins (PR 78918)

On 08/01/2017 03:25 AM, Richard Biener wrote:
> On Tue, Aug 1, 2017 at 11:23 AM, Richard Biener
> <> wrote:
>> On Tue, Aug 1, 2017 at 4:27 AM, Martin Sebor <> wrote:
>>> Richard,
>>> in discussing this work Jeff mentioned that your comments on
>>> the tree-ssa-alias.c parts would be helpful.  When you have
>>> a chance could you please give it a once over and let me know
>>> if you have any suggestions or concerns?  There are no visible
>>> changes to existing clients of the pass, just extensions that
>>> are relied on only by the new diagnostics.
>>> I expect to revisit the sprintf %s patch mentioned below and
>>> see how to simplify it by taking advantage of the changes
>>> implemented here.
>> Your ptr_deref_alias_decl_p returns true when must_alias is true
>> but there is no must-alias relationship.
>> The ao_ref_init_from_ptr_and_size doesn't belong there.
>> I dislike all of the changes related to returning an alias "size".
>> Please keep away from the alias machinery.
>> Warning during folding is similarly bad design.  Please don't add
>> more such things.
>> Thanks for putting this on my radar though.
>> Richard.
> Oh, for a constructive comment this all feels like sth for either
> sanitizers or a proper static analysis tool.  As I outlined repeatedly
> I belive GCC could host a static analysis tool but it surely should
> not be interwinded into it's optimization passes or tools.
I disagree strongly here.

Sanitiers catch problems after the fact and only if you've compiled your
code with sanitization and manage to find a way to trigger the problem path.

Other static analysis tools are useful, but they aren't an integral part
of the edit, compile, debug cycle and due to their cost are often run
long after code was committed.

Finding useful warnings that can be issued as part of the compile, edit,
debug cycle is, IMHO, far more useful than sanitizers or independent
static checkers.


I think finding a way to exploit information that our various analyzers
can provide to give precise warnings is a good thing.  So it seemed
natural that if we wanted to ask a must-alias question that we should be
querying the alias oracle rather than implementing that kind of query
within the sprintf warnings.  I'm not sure why you'd say "Please keep
away from the alias machinery".

I'm a little confused here...


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]