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.
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.