I've been playing around with the ARM C compiler 6.6 and 6.7 for cortex m3 and I was wondering what is the best practice for the enabling of compiler warnings? What level of warnings should be a minimum? Would flagging missing noreturn and unused parameters actually help produce more efficient code? It was quite a bit of a change to go from 6.6 that had a lot of warnings on by default to 6.7 that has turned a lot of the warnings off. I prefer having the warnings off by default but it did make me wonder how many of them I should turn back on.
I guess "best practice" is, at least somewhat, subjective.
The consensus so far seems to favour enabling as many warnings as possible.
Yes, some compilers can be annoying with their warnings.
"-Wswitch-enum for example doesn't take into account the default statement"
That does sound annoying!
"would flagging that the function doesn't return and doesn't use the parameter produce more efficient code than just keeping the warning disabled and ignoring it?"
Again, warnings don't tend to be about efficiency, and writing the code so that they don't arise doesn't tend to cost anything at runtime.
Although, in these particular cases, I guess knowing that a function doesn't return or that a parameter isn't used might open up some opportunity for optimisation ...
If you're concerned, try it and see.
"Having established that not all warnings are that helpful"
I'm not really sure that we have established that.
As is the case with most things in Engineering, I think you just have to do a cost-benefit analysis to see what makes sense for your particular case.
But I would still start from having everything enabled, and then only disable the ones that don't help your particular case.
Do you have a Coding Standard? What does it say?
My coding standard can allow warnings if there is a proper justification for it being there. This situation is quite rare though. It kind of changes when you can pick and chose which warnings to allow, and there is nothing about specifying warnings.
The consensus so far seems to favour enabling as many warnings as possible. This does seem like the best approach.
Again, warnings don't tend to be about efficiency I should be using the terminology "optimised" rather the "efficient". Is it easier for the compiler to optimise the written code if these attributes (and similar) are added?
I am disappointed that ARM does not have a definitive guide to it's own compiler. Trying to find out what each of the command line options actually do has been really difficult. The reference guide (static.docs.arm.com/.../armclang_reference_guide_100067_0607_00_en.pdf) and user guide (static.docs.arm.com/.../compiler_user_guide_100748_0607_00_en.pdf) sends you to the Clang documentation (clang.llvm.org/.../UsersManual.html) which doesn't actually tell you much. The best guide I found was a GCC guide (www.chiark.greenend.org.uk/.../gcc.html). It is a bit difficult to make informed decisions if the compiler vendor isn't going to tell you how the compiler works.