https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117262
--- Comment #4 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #2)
> Sure, it is trunk only, introduced in r15-4375.
> Would be nice if it could be handled similarly to apply_ctor_val_to_range by
> creating just a single record for the whole range, just with slightly
> different meaning (in that
> for RANGE_EXPR all elements in the range have the same value, while for
> RAW_DATA_CST
> each element in the range has a specific RAW_DATA_POINTER (elt)[i - idx]
> value.
I tried this patch so that it tries to handle raw_data_cst using
constant_svalue (which would minimize the number of entities created):
--- a/gcc/analyzer/region-model.cc
+++ b/gcc/analyzer/region-model.cc
@@ -2755,6 +2755,7 @@ region_model::get_rvalue_1 (path_var pv,
region_model_context *ctxt) const
case COMPLEX_CST:
case VECTOR_CST:
case STRING_CST:
+ case RAW_DATA_CST:
return m_mgr->get_or_create_constant_svalue (pv.m_tree);
case POINTER_PLUS_EXPR:
and I get e.g:
(gdb) call cst_sval->dump()
(40): ‘unsigned char’: constant_svalue (‘105, 110, 116, 10, 109, 97, 105, 110,
32, 40, ..., 10, 32, 32, 115, 104, 111, 114, 116, 32, 109’)
where arguably the type of the symbolic value should be
unsigned char[72]
rather than:
unsigned char
This is because the analyzer is just using TREE_TYPE of the cst, and TREE_TYPE
of RAW_DATA_CST is the type of each of the elements, rather than of the data as
a whole. Is that design decision set in stone?
