This is the mail archive of the
mailing list for the GCC project.
[PATCH 0/4] avoid relying on type information in get_range_strlen
- From: Martin Sebor <msebor at gmail dot com>
- To: Gcc Patch List <gcc-patches at gcc dot gnu dot org>, Jeff Law <law at redhat dot com>
- Date: Tue, 2 Oct 2018 10:36:50 -0600
- Subject: [PATCH 0/4] avoid relying on type information in get_range_strlen
This patch kit changes the get_range_strlen API to a) make its
use more intuitive and less prone to misuse, and b) relax
the strlen range optimization to avoid making use of array type
sizes to constrain the upper bound of the function return value.
I broke up the changes into a series of four in an attempt to
make them easier to review although I'm not sure to what degree
this will have been successful:
[1/4] - Introduce struct strlen_data_t into gimple-fold
[2/4] - Relax strlen range optimization to avoid making assumptions
[3/4] - Change sprintf to use new get_range_strlen overload
[4/4] - Replace uses of old get_range_strlen with the new one.
Some aspects of the API evolve as the series progresses (e.g.,
the function return type changes) but the basic idea/design are
The patch kit applies on top of r264413 and there are going to
be conflicts to resolve with the recent changes in this area.
In particular, the recent addition of a c_strlen_data argument
to c_strlen will need to reconciled with the addition of
the strlen_data_t struct in [1/1]. I think both c_strlen and
get_range_strlen (and perhaps also string_constant) should take
and populate the same data structure.