https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121000
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to qinzhao from comment #1) > with gcc -O1 -fdump-tree-all t.c, in a-t.c.112t.objsz1, we see the object > size is generated as _22: > > sizetype _26(D); > > _12 = &p_18->n; > _23 = MEM <int> [(void *)_12]; > _24 = MAX_EXPR <_23, 0>; > _25 = (sizetype) _24; > _22 = _26(D) * _25; > > In the above, _25 is the # of element of the array, which is loaded from > &p_18->n, the counted_by field of the structure, _26 is the size of each > element, which is the size of A[m], is got as "element_size" in the > following code in gcc/tree-object-size.cc: > > /* The type of the 6th argument type is the pointer TYPE to the original > flexible array type. */ > tree pointer_to_array_type = TREE_TYPE (gimple_call_arg (call, 5)); > gcc_assert (POINTER_TYPE_P (pointer_to_array_type)); > tree element_type = TREE_TYPE (TREE_TYPE (pointer_to_array_type)); > tree element_size = TYPE_SIZE_UNIT (element_type); > > > we can cleanly see that _26 is an uninitialized variable, whose > initialization has been eliminated by the previous optimization already due > to it's not used in IL at all. You indeed cannot use (non-constant) TYPE_SIZE_UNIT in this way. If there is an ARRAY_REF in the IL you can use array_ref_element_size to get at it. But arbitrary VLA type sizes to not survive unless you use them in the original GENERIC IL.
