https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78174
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
No, I've also explained what to do about the u.fld thing.
sed -n '/^DEF_RTL_EXPR/{s/DEF_RTL_EXPR([^,]*,[^,]*, "//;s/".*$//;p}' rtl.def |
sort -u
shows we have at most 8 fields right now, so we could define some macro to 8
and replace
rtunion fld[1];
with
rtunion fld[RTL_FLD_MAX_COUNT];
plus some verification (selftest) that no RTL format not containing w is longer
than that.
Similarly for
HOST_WIDE_INT hwint[1];
We probably can't use real.h here, so again we have to live with some maximum,
real.h shows
the longest supported REAL_WIDTH is 6.
Then in struct tree_exp we have:
tree GTY ((special ("tree_exp"),
desc ("TREE_CODE ((tree) &%0)")))
operands[1];
which have I think maximum of 7 right now (again, we'd need macro and self test
verification).
Then struct tree_omp_clause has:
tree GTY ((length ("omp_clause_num_ops[OMP_CLAUSE_CODE ((tree)&%h)]")))
ops[1];
and in that case the maximum is 5.
The question is if we ever just have a struct rtx_def, struct tree_exp etc. or
some struct
that contains those as a field or class that has those as a base as a global
variable or
automatic variable, such changes would change it obviously. Most of it is
allocated
through corresponding tree or rtl allocators and allocates offsetof (...,
field) + length.
We'd be trading one kind of pedantic undefined behavior for another one I bet,
right now
we often have larger objects than what the compiler can see and thus use the
"flexible-array-like"
extension we probably don't document very well, but support nevertheless - too
much code
in the wild would break otherwise. And with the above proposed changes we'd
turn it into something
different, the compiler would be told the structures are large, but in reality
they would be shorter,
the compiler couldn't rely in all of the structure to be readable etc. (that
actually is the case
now too, e.g. for RTLs with zero operands or OpenMP clauses with zero
operands).
But it would shut up coverity and other static analyzers. Perhaps we should do
it only
conditionally (in some compilation modes) that would be enabled for those
static analyzers.
GCC isn't alone that uses techniques like this and so warning about it is not
really useful.
