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: [PATCH, Pointer Bounds Checker 14/x] Passes [4/n] Memory accesses instrumentation

On 10/14/14 04:08, Ilya Enkovich wrote:
Are you just looking for the parameter in which we pass the static
chain?   Look at get_chain_decl for how we set it up.  You may
actually have to peek at more fields.  I don't think there's a
single magic bit that says "this is the static chain".  Though it
may always appear in the same location on the parameter list.
Nested functions aren't something I'd poked with much.  Richard
Henderson might know more since he wrote tree-nested a while back.

Looking through tree-nested.c I found there is a static_chain_decl in
function structure holding created decl.

Ugh.  Note how this introduces another place that anyone who might
add a new RHS gimple statement needs to edit.  We need a pointer
back to this code so that folks will know it needs updating.  The
question is where to put it.

Basically we want a place where anyone adding a new code that can
appear on the RHS of an assignment must change already.  Thoughts
on a good location?

I realize there's probably many other places that probably need
these kinds of documentation back links, I'm not asking you to
address all of them.

Actually it shouldn't be so critical to meet some new RHS code in
this switch.  We may always say that we cannot find proper bounds and
use default ones.  I replaced gcc_uneachable with a warning about
lost bounds and added a comment into tree.def.  Would it be enough?
It'd be better than hitting the gcc_unreachable :-) It's not perfect, but probably good enough.


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