On Wed, Jan 08, 2025 at 07:47:27PM -0500, David Malcolm wrote: > On Wed, 2025-01-08 at 07:48 -0800, Andi Kleen wrote: > > > > I wanted to ping this patch series. Thanks. > > > > -Andi > > > > Thanks for tha patches, and sorry about not getting back to you earlier > (I've been focusing on analyzing many 100s of build failures with GCC > 15 relative to GCC 14) > > Overall, the patches look like they *might* be OK, but: > > * were these tested these on top of r15-6284-g778336e0e4f257? (in which > I added a new feature to file_cache to help with sarif-replay)
Yes they were. > > * I haven't yet fully grokked the patches, especially the one that > changes the line cache eviction mechanism (so maybe the following is > overly paranoid...) I think it is because the code is self-checking because it always checks the final line numbers: if anything goes wrong either the cache doesn't hit or an assert fires. Could just add a dejagnu test that makes the cache sizes very small and checks if some warnings like undefined variables that are triggered after initial parsing match > > * I'm nervous about landing a big change to this at this point in the > GCC 15 cycle; is there a way to add test coverage e.g. with more > selftests in input.cc to try to exercise the various cases in the code > (or to just brute force it!); see e.g. test_reading_source_line; we > could have a selftest write out files with various numbers of lines and > try various patterns of line number access, perhaps. If it's too big can do only 1-3. It doesn't completely fix the problem, but improves it, and it can be fixed with --param. 3 is technically not needed but it just removes dead code. > > * I've been working to reduce global state in the diagnostics > subsystem: e.g. in libgdiagnostics there can be multiple diagnostic > contexts, each with their own file cache. Is there a way to make the But they should all use the same tuning? The globals are just for storing the tuned values from --param, they are read-only at runtime. -Andi
