This is the mail archive of the gcc-patches@gcc.gnu.org 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: [PATCH] enhance -Warray-bounds to detect out-of-bounds offsets (PR 82455)


On 11/13/2017 06:21 PM, Martin Sebor wrote:
> I have a different concern with the general idea of moving these
> kinds of warnings into passes of their own.  It would unavoidably
> result in duplicating some code from the optimization passes (at
> a minimum, the GIMPLE traversal, but likely more than that).  It
> would also require pretty tight coupling between the warning pass
> and the optimization passes as the latter can defeat the work of
> the former (as happens in this case).  But most significantly,
> the separation isn't feasible in cases where the optimization
> pass computes and maintains non-trivial internal state (like,
> say, tree-object-size or tree-ssa-strlen).
Something like object-size, string lengths, value data, etc should be
independent analysis modules.  You then build an optimizer on top of the
module and/or a warning pass on top of the module.  The optimizer and
warning pass might in fact share analysis and just do different things
with the underlying data produced.

It's not perfect and we're not likely to ever be perfect, but it's a
hell of a lot better than what we're doing now.   Yes there'll be phase
ordering problems, problems with other passes hiding or exposing
questionable code, possibly duplication between the optimization client
and warning client, etc, etc.  We have to look at each problem and
decide how best to proceed.

I do think that the frameworks we build should have mechanisms to allow
transformation of code that is clearly wrong and exhibits undefined
behavior.

> 
> That said, it would make perfect sense to me to have the warning
> code live in separate files from the optimization code, and keep
> the separation of concerns and responsibilities crisp and well
> defined by their APIs.
Where that's feasible it seems reasonable to me.  I'm obviously biased
based on recent experiences within VRP which has grown over time into a
horrid mess my forays into tree-ssa-uninit.c which has a damn cool
little predicate analysis engine just waiting for someone extract and
re-use.

Jeff


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