On 10/3/19 5:54 AM, Vladislav Ivanishin wrote: > Hi! > > This series implements the -Wclobbered warning on GIMPLE in place of the > old RTL implementation. > > This cover letter contains a high-level explanation of what is going on > and why. The new implementation itself is in the patch 3. I will post > the details in the accompanying blurb. > > The most obvious benefit of doing it on GIMPLE is making this warning > independent of the specific register allocation decisions the RA makes. > I.e. if there is a possibility of a different compiler allocating a > variable to a register live through the setjmp call, but in the current > compilation it got spilled, the existing implementation does not give a > warning. > > So the new implementation strives to indicate as many potential errors > in the code as it can, not limited to the problems pertinent to this > compilation with this particular compiler. This is in line with > e.g. what Tom Lane (of PostgreSQL) expressed interest in seeing [1]. > > Also, in order to suppress spurious warnings, it is sometimes useful to > distinguish paths realizable after the second (and subsequent) returns > from setjmp vs. realizable only after the first return (see PR 21161). > The new implementation does that using a simple heuristic. > > All comments are appreciated. Is this OK for trunk? I'll take a look at this. I'm intimately familiar with pr21161 and the pain of trying to fix the CFG at the RTL level.
We had a fairly length discussion on some of the issues related to tackling this at the gimple level a year or so ago as well. jeff
