FWIW, my fix for bug 79062 is only partial (it gets the pass
to run but the warnings are still not issued). I don't quite
understand what prevents the warning flag(s) from getting set
when -flto is used. This seems to be a bigger problem than
just the sprintf pass not doing something just right.
I've never dug deeply in the LTO stuff, but I believe we stream the compiler
flags, so it could be something there.
We do.
Alternately you might be running into a case where in LTO mode we recreate
base types. Look for a type equality tester that goes beyond just testing
pointer equality.
ie, in LTO I think we'll create a type based on the streamed data, but I
also think we'll create various basic types. Thus in LTO mode pointer
equality may not be sufficient.
We make sure that for most basic types we end up re-using them where possible.
char_type_node is an example where that generally doesn't work because it's
value depends on a command-line flag.
That answers the first part of the question of why the sprintf
pass wouldn't run (or do anything) with -flto. With it fixed
(as in fold-const.c or tree-ssa-strlen.c as you suggested in
bug 79602) it runs and the optimization does its job, but no
warnings are issued. The wan_foo_flags for warnings that are
enabled implicitly (e.g., by -Wall or -Wextra on the command
line) are clear. There seem to be dependencies between warnings
in c.opt that ignore LTO (as a language), but even with those
corrected (i.e., with LTO added as a language to -Wformat and
-Wall) the flags are still clear when LTO runs. Does that ring
any bells for you?
Thanks
Martin
