Re: [PATCH] handle sprintf(d, "%s", ...) in gimple-ssa-sprintf.c

[Martin Sebor <msebor@gmail.com>]

>>> 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