On Wed, 2024-01-17 at 17:52 -0500, David Malcolm wrote: > On Tue, 2024-01-16 at 15:44 +0100, Pierrick Philippe wrote: > > Hi David, hi all, > > Hi Pierrick. > > > > > I was playing along with APIs from the Static Analyzer and > > encountered a > > segfault in gcc/tree.cc:5068 (i.e. in function build2 and failure > > is > > due > > to a > > gcc_assert call), after a call to > > ana::region_model::get_representative_tree. > > > > From my debugging of the problem, I realized that the svalue which > > I > > built with > > the SA API as the following from an element_region (C sample): > > > > const ana::region *base = elm_reg->get_base_region(); > > // base_ptr is the svalue passed to get_representative_tree > > const ana::svalue *base_ptr = base->get_ptr_svalue( > > > > TYPE_POINTER_TO(base->get_type), > > > > base); > > > > I realized that the SA resulting in the call to get_ptr_svalue has > > NULL_TREE as > > type (return by get_type on base_ptr). And this is because > > TYPE_POINTER_TO > > (base->get_type) is returning a NULL_TREE. I found my way around > > by > > calling > > build_pointer_type(base->get_type()) which is currently building > > the > > expecting > > type. > > I confess that I've been quite sloppy in places with types in the > analyzer, keeping track of them when it's easy, but letting them be > NULL in places where getting a type was hard, or apparently not > possible. > > Sorry about this. > > I think my implementation is a bit muddled about what an svalue > actually is. > > Informally, I think of an svalue as a partial function from bit > offsets > to values of the bits. For example: > * region_svalue: e.g. bit offsets 0-63 are the pointer to REG; > undefined elsewhere > * constant_svalue: e.g. given (int)42, bit offsets 0-31 are the > constant 42, encoded in the target's usual way; undefined elsewhere > * unknown_svalue: undefined everywhere > ...etc, and the above definition doesn't need svalues to have a type. > > The above is rather vague: how should this work for unaryop_svalue > and > binop_svalue; these need to have types, so that we can think of them > as > e.g. > * "bits 0-31 are the result of a signed 32-bit int addition of the > values of bits 0-32 from X and Y when considered as signed 32-bit > int". > * "bits 0-31 are the result of zero-extending bits 0-7 of X and > treating the result as uint32_t". > > In the meantime, you can't rely on an svalue having a non-NULL type, > and hence it's often not possible to get a representative tree from > an > svalue, since tree expressions must have non-NULL types. > > > > > > But from this, two questions raised in my mind: > > > > 1. Is it coherent for the ana::region_model_manager::get_ptr_svalue > > to > > return a sval with a null type? > > It depends what you mean by "coherent"; given the sloppy approach > above, the answer is "yes". > > > > > 2. Can a tree view as a tree_type_common member have an > > uninitialized > > pointer_to member? > > It shouldn't be uninitialized. Perhaps the tree node isn't the right > kind? You should use the TYPE_POINTER_TO macro to access the field, > which will use TYPE_CHECK to check that the node is a type in a debug > build of the compiler.
I think that it *can* be NULL, though (as opposed to uninitialized). I believe that this field is essentially a cache for build_pointer_type and build_pointer_type_for_mode, so that we can lazily create pointers to types on demand. (But I could be wrong here) Dave > > > I think, but definitely not sure) that the member is not > > initialized here by some part of the compiler, because I think that > > the > > inner > > type of regions and svalues are build by the SA by using the > > TREE_TYPE macro > > directly from the GIMPLE. I ask this question to know if this is a > > bug > > and I > > should try to do a minimal example out of it, or if it is a > > intended > > behavior > > for any reason from the compiler. > > Sounds like a bug; please try to construct a minimal example. > > Thanks > Dave > > > > > Thank you for reading me, > > > > Pierrick > > >
