On Thu, Nov 24, 2016 at 5:14 PM, Segher Boessenkool <seg...@kernel.crashing.org> wrote: > On Thu, Nov 24, 2016 at 08:48:04AM -0700, Jeff Law wrote: >> On 11/24/2016 07:53 AM, Segher Boessenkool wrote: >> > >> >That we compare different kinds of costs (which really has no meaning at >> >all, it's a heuristic at best) in various places is a known problem, not >> >a regression. >> But the problems with the costing system exhibit themselves as a code >> quality regression. In the end that's what the end-users see -- a >> regression in the quality of the code GCC generates. > > Yes, exactly -- and I fear this all-encompassing change will cause just > such a regression for many users. Tests are running, will know more > later today (or tomorrow). > > The PR is about a very specific problem; the patch is not. The patch > is not a bug fix. If we allow anything that "makes things better" in > stage 3, what make it different from stage 1 then?
That's a good question ;) The stage 3 definition has a loophole via "go file a bug about feature X, then it's a bugfix!". I'm all open for a more sensible definition, like constraining the kind of non-regression fixes that we want to allow, but I fear the most sensible option would be to simply ditch the notion of different "stages" and make it "general development" and "regression fixing". (though if you try hard enough and go back in time you'll find that almost all non-enhancement bugs are regressions in some sense) And yes, current stage3 still feels too much like stage1 ;) Richard.
