On Wed, 2020-02-05 at 16:18 +0100, Jakub Jelinek wrote: > On Wed, Feb 05, 2020 at 09:59:19AM -0500, David Malcolm wrote: > > Although the analyzer works on GIMPLE SSA and therefore in theory > > ought > > to support all languages supported by GCC, the code currently only > > supports the subset of GIMPLE SSA expressible via the C frontend. > > > > For GCC 10 I want to explicitly restrict the scope of the analyzer > > to > > C code, to keep the initial scope of the feature sane. > > > > For example, various C++ things aren't yet supported by the > > analyzer and > > won't be in GCC 10 (exceptions, new/delete diagnostics, ctors that > > run > > before main, etc) > > C has ctors before main too, look for attribute constructor.
Thanks. > I must say I don't really like this, if you encounter something in > the IL > that the analyzer can't handle yet, punt, that is fine, Fair enough. FWIW I managed to get double-free detection working in gfortran earlier today, and in doing so discovered and fixed an issue affecting C, proving your point, I think. > but you could > write code in C++ that doesn't use exceptions nor new/delete, there > is > no reason not to analyze that, etc. And teaching it to handle > new/delete > operator like malloc/free shouldn't be that hard, but even if you > don't, > you still need some way how to deal with other allocators in C, say > for > stuff allocated with mmap etc. Right. I want to generalize the malloc/free stuff to deal with arbitrary families of acquire/release APIs, but at this point we're deep in stage 4, and so I want to try to set some expectations about what's likely to work, and what isn't, and it seems prudent to leave that generalization work to gcc 11. My plan for gcc 10 is to focus on C code that uses malloc and free, possibly with a simple wrapper around them. I think the highest priority item is ensuring that the analyzer scales up to handle real- world C code rather than just the reduced examples in the testsuite. I'm working on a fix for a rather convoluted set of issues in state- merging that would otherwise lead to the analyzer burning CPU cycles w/o properly exploring the user's code. But I'm also fixing ICEs as I go. > Mentioning in the documentation that it is for now primarily intended > for C > is one thing (that is fine), but stopping analyzing something is > another. I'll do this in release notes and docs then. Hope the above sounds like a reasonable plan. Thanks Dave
