On 12/2/22 00:26, Eric Gallager via Gcc-patches wrote:
I tried turning -Wnarrowing back on earlier this year, but
unfortunately it didn't work due to triggering a bunch of new errors.
This patch silences at least some of them, but there will still be
more left even after applying it. (When compiling with clang,
technically the warning flag is -Wc++11-narrowing, but it's pretty
much the same thing as gcc's -Wnarrowing, albeit with fixit hints,
which I made use of to insert the casts here.)
gcc/ChangeLog:
* ipa-modref.cc (modref_lattice::add_escape_point): Use a
static_cast to silence -Wnarrowing.
(modref_eaf_analysis::record_escape_points): Likewise.
(update_escape_summary_1): Likewise.
* rtl-ssa/changes.cc (function_info::temp_access_array): Likewise.
* rtl-ssa/member-fns.inl: Likewise.
* tree-ssa-structalias.cc (push_fields_onto_fieldstack): Likewise.
* tree-vect-slp.cc (vect_prologue_cost_for_slp): Likewise.
* tree-vect-stmts.cc (vect_truncate_gather_scatter_offset): Likewise.
(vectorizable_operation): Likewise.
Would it make sense to instead fix the APIs so that instead of passing
an "int" they instead pass a suitable enum type?
So for example, modref_lattice::add_escape_point passes "min_flags" as
an int. It probably should be an eaf_flags_t. That may (of course)
bleed out into other places. So I'd probably suggest you pick one case
such as this add_escape_point, make it's API change, fix the fallout and
submit that as a patch.
Then proceed to the next case where you added a static_cast and do the
same thing there.
In addition to fixing the warnings, this should make the codebase
cleaner and catch more errors using the typesystem.
jeff
