On Mon, Mar 20, 2023 at 11:26:17AM -0700, Linus Torvalds wrote: > On Mon, Mar 20, 2023 at 11:05 AM Nathan Chancellor <nathan@xxxxxxxxxx> wrote: > > > > On the clang front, I am still seeing the following warning turned error > > for arm64 allmodconfig at least: > > > > drivers/gpu/host1x/dev.c:520:6: error: variable 'syncpt_irq' is uninitialized when used here [-Werror,-Wuninitialized] > > if (syncpt_irq < 0) > > ^~~~~~~~~~ > > Hmm. I do my arm64 allmodconfig builds with gcc, and I'm surprised > that gcc doesn't warn about this. > > That syncpt_irq thing isn't written to anywhere, so that's pretty egregious. > > We use -Wno-maybe-uninitialized because gcc gets it so wrong, but > that's different from the "-Wuninitialized" thing (without the > "maybe"). > > I've seen gcc mess this up when there is one single assignment, > because then the SSA format makes it *so* easy to just use that > assignment out-of-order (or unconditionally), but this case looks > unusually clear-cut. > > So the fact that gcc doesn't warn about it is outright odd. > > > If that does not come to you through other means before -rc4, could you > > just apply it directly so that I can stop applying it to our CI? :) > > Bah. I took it now, there's no excuse for that thing. > > Do we have any gcc people around that could explain why gcc failed so > miserably at this trivial case? > I have noticed that gcc doesn't always warn about uninitialized variables in most architectures. The conditional btrfs build failure (only seen on sparc and parisc) is similar: gcc is silent even if I on purpose create and use uninitialized variables. Since the gcc version I use is the same for all architectures, I thought it must have something to do with compile options (like maybe the option to always initialize stack variables, or with some gcc plugin), but I have been unable to track it down. Guenter
