[PATCH 1/7] score: Add RTEMS_DECONST|DEVOLATILE|DEQUALIFY()

[Joel Sherrill]

On September 8, 2014 2:44:39 AM CDT, Jan Engelhardt <jengelh at inai.de> wrote:
>
>On Monday 2014-09-08 08:08, Sebastian Huber wrote:
>>
>> I think we should eventually use -Werror, so it is important to get
>rid of
>> warnings.  I am in favour of macros, since this makes it easier to
>deal with
>> compiler dependencies.
>
>-Werror is a bad idea. Your users may be using a different compiler 
>and/or compiler version which emits new warnings, and then they run
>into 
>errors. This is especially annoying for distributions — it probably
>does 
>not matter for RTEMS, but it does with respect to general software — as
>
>the most often encountered warnings are petty things like (a) unused 
>variables that stem from conditional #if/#endif pairs, (b) comparing 
>sign-different types, (c) conversion losing precision/narrowing types, 
>which are not nearly as important as crashes due to (d) whacky 
>type-punning and integral_type<->pointer_type conversions, (e) use of 
>implicitly declared things.

I would like to see -Werror on a subset of critical directories. But from a practical viewpoint, it is nearly impossible to get and keep the tree warning free on 18 target architectures.

Right now there are about 2000 unique warnings when I crunch the build logs. Some BSPs only have a handful, others have up to 100. Some of these are easy to fix bit others are involved. The printf format warning I fixed and Gedare questioned the patch is turning into a delicate bug in inttypes.h which may end up requiring a new CPP predefine in GCC. 

I want to do a little more clean up myself and then plan a community beautification week where (hopefully) users take some time to help clean up warnings. 

>If warnings get lost in your compile logs, perhaps using 
>automake's "silent-rules" option can be of help. [Similar 
>tunables may exist in cmake, etc.]

Autoconf.. :(

>So, please, no -Werror.