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, 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 >
