On Wed, Aug 28, 2019 at 11:45 AM Nathan Chancellor <natechancellor@xxxxxxxxx> wrote: > > On Wed, Aug 28, 2019 at 11:01:14AM -0700, Nick Desaulniers wrote: > > On Wed, Aug 28, 2019 at 10:53 AM Nathan Chancellor > > <natechancellor@xxxxxxxxx> wrote: > > > > > > Yes, I don't think this would be unreasonable. Are you referring to the > > > cc-disable-warning flags or the -fno-builtin flags? I personally think > > > the -fno-builtin flags convey to clang what the kernel is intending to > > > do better than disabling the warnings outright. > > > > The `-f` family of flags have dire implications for codegen, I'd > > really prefer we think long and hard before adding/removing them to > > suppress warnings. I don't think it's a solution for this particular > > problem. > > I am fine with whatever approach gets this warning fixed to the > maintainer's satisfaction... > > However, I think that -fno-builtin-* would be appropriate here because > we are providing our own setjmp implementation, meaning clang should not > be trying to do anything with the builtin implementation like building a > declaration for it. That's a good reason IMO. IIRC, the -fno-builtin-* flags don't warn if * is some unrecognized value, so -fno-builtin-setjmp may not actually do anything, and you may need to scan the source (of clang or llvm). -- Thanks, ~Nick Desaulniers
