public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Sergei Gavrikov <sg@scanex.ru>
To: Grant Edwards <grant.b.edwards@gmail.com>
Cc: "ecos-discuss@sources.redhat.com" <ecos-discuss@sources.redhat.com>
Subject: Re: [ECOS] Re: eCos arm-eabi GNU tools - test release 4.6.2-20120125
Date: Fri, 24 Feb 2012 20:40:00 -0000	[thread overview]
Message-ID: <alpine.DEB.2.00.1202242206030.2294@vostro> (raw)
In-Reply-To: <ji8gae$63g$1@dough.gmane.org>

On Fri, 24 Feb 2012, Grant Edwards wrote:

> FWIW, I just tried the new tools building a fairly simple eCos kernel
> (based on CVS HEAD from a couple weeks ago) with FreeBSD stack
> enabled.  The kernel build generated 172 compiler warnings.  About
> half of those (89) are aliasing violations in the bsd stack source
> code, so it looks like '-fno-strict-aliasing' needs to be added to the
> compiler flags for the FreeBSD stack to safely use the new toolchain.
> 
> Of the remaining warnings, about half (45) are variables that are set
> but never used.  Most of them are in the FreeBSD stack, but there are
> a smattering of them in other places as well.
> 
> The remaining warnings a variety things like printf format/arg
> mismatches, failed inlines, signed/unsigned mismatches, and so on.
> 
> Personally, I'm not comfortable shipping anything that builds with
> that many warnings.  For my code, the requirement is zero warnings.
> For eCos code, the number of warnings has to be small enough that I
> can anlyze them once and thereafter tell at a glance whether any new
> ones have popped up.
 
Hm. My score is something 1/4 from yours. For the same eCos template
and *arm-eabi* eCos target (one from officially supported *arm-eabi*
targets from eCos AnonCVS):

  % make 2>&1 | tee log && make IGNORE_LINK_ERRORS=y tests 2>&1 | tee -a log
  % grep warning: log | wc -l
  49
  % grep warning: log | grep -v -- unused-but-set | wc -l
  3

So, the most (46) are:

  warning: variable "foo" set but not used [-Wunused-but-set-variable]

And that is new warning from -Wall set
http://gcc.gnu.org/gcc-4.6/porting_to.html

IMHO, those warnings is not big issue. I hope that we will be able to
rid all of them. Also there were a few *notes* that mangling of va_list
has changed in GCC 4.4.

Grant, did you try *arm-eabi* toolchain for your target before?  Of
course, if this is possible. I mean stable arm-eabi (4.3.2) toolchain
from eCosCentric? May be you missed that CFLAGS clean-up step on 4.3.2
migration?

BTW, I have the very few warnings when I use stable arm-eabi (4.3.2)
toolchain from eCosCentric with CFLAGS updated since eCos 3.0.

> Doing the same build with my old 3.2.x toolchain generates 6 warnings
> that I've never gotten around to fixing -- but I'm familiar with them
> and know they're harmless.
 
Ah! So, you used old 'arm-elf' toolchain before.  As far I remember
CFLAGS for all *arm-eabi* targets in eCos AnonCVS were fixed in those
days (pre eCos 3.0 days). Well, there are a few *arm-elf* targets in
eCos AnonCVS.  As I could see *arm-elf* based are sa11x0, pid, aeb, and
ebsa285.

Well, I believe that we will rid all warnings at the end :-) More
warnings means that the newest compiler is more pedantic and IMHO, that
is good for programmers, but not for their elder code :-)

Sergei

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

  parent reply	other threads:[~2012-02-24 20:15 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-13 21:58 [ECOS] " John Dallaway
2012-02-24 19:00 ` [ECOS] " Grant Edwards
2012-02-24 19:37   ` Ilija Kocho
2012-02-24 20:15     ` Grant Edwards
2012-02-24 20:53       ` Ilija Kocho
2012-02-24 21:10         ` Sergei Gavrikov
2012-02-29 20:45       ` Grant Edwards
2012-03-02  0:35       ` Grant Edwards
2012-02-24 20:40   ` Sergei Gavrikov [this message]
2012-02-24 21:38     ` Grant Edwards
2012-02-24 22:05       ` Sergei Gavrikov
2012-02-25  8:39         ` Grant Edwards
2012-02-28  8:23           ` Sergei Gavrikov
2012-02-29 21:59             ` Grant Edwards
2012-03-01  7:25               ` Sergei Gavrikov
2012-03-01 14:32                 ` Grant Edwards

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.00.1202242206030.2294@vostro \
    --to=sg@scanex.ru \
    --cc=ecos-discuss@sources.redhat.com \
    --cc=grant.b.edwards@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).