This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[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
        about types
[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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]