[PATCH 1/7] score: Add RTEMS_DECONST|DEVOLATILE|DEQUALIFY()
joel.sherrill at oarcorp.com
Mon Sep 8 10:34:18 UTC 2014
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
>> warnings. I am in favour of macros, since this makes it easier to
>> 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
>errors. This is especially annoying for distributions — it probably
>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.]
>So, please, no -Werror.
More information about the devel