On Wed, Aug 28, 2019 at 11:45 AM Nathan Chancellor natechancellor@gmail.com 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@gmail.com 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).