This is the mail archive of the gcc-patches@gcc.gnu.org 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] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |