On Sun, Nov 27, 2022 at 09:21:00AM -0500, David Malcolm via Gcc-patches wrote: > We're currently in "stage 3" of GCC 13 development, which means that > we're focusing on bug-fixing, rather than cleanups and feature work. > Though exceptions can be made for low-risk work, at the discretion of > the release managers; I've taken the liberty of CCing them.
Such global changes are incomnvenient for people who have touched any of that code in their own patches. If we really want to do that it should be done early in stage 1 (when everything is broken for everyone anyway), and should be agreed on beforehand, or really, should only be done for obvious improvements. This is not an obvious improvement. > > All existings tests did pass. I have never seen a single target where all existing tests passed. What we usually do is "same failures before and after the patch" :-) > RTL is an aspect of the compiler that tends to have the most per-target > differences, so it's especially important to be precise about which > target(s) you built and tested on. Not that that should matter at all for patches that do not actually change anything, like this one should be: it should only change notation. That is in the nature of helper functions and helper macros. > > Like I said, this is my first patch. > > We're sometimes not as welcoming to newcomers as we could be, so please > bear with us. Let me know if anything in this email is unclear. x2 from me! > As noted in another reply, there are lots of places in the code where > the patch touches lines that it doesn't need to: generally formatting > and whitespace changes. > > We have over 30 years of source history which we sometimes need to look > back on, and RTL is some of the oldest code in the compiler, so we want > to minimize "churn" to keep tools like "git blame" useful. Not to mention that many of those changes violated our coding style, or even look like an automated formatter going haywire. And, of course, such changes should be separate patches, if done at all! Segher
