This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: assertify cris


Hans-Peter Nilsson wrote:
Date: Fri, 29 Apr 2005 14:09:56 +0100
From: Nathan Sidwell <nathan@codesourcery.com>


This patch assertifies the cris target files.  I built an i86 hosted
cris-none-elf cross compiler and used that to build newlib (this time
it didn't ICE :).


Where did it ICE for you?  The combined tree is healthy.  I
built and simulated as late as with LAST_UPDATED "Fri Apr 29
08:46:21 UTC 2005".

I was unclear -- some of the other backends I've been assertifying have ICED for non-assert related reasons. Cris is ok in this regard.


Yes there is, in the canonical location, sim/cris.  (Where did
you look?)  Google for the cris-sim.exp baseboard file or get
one from the master dejagnu CVS.

I looked for a cris-sim.exp file in dejagnu/baseboards and couldn't see one. I see there is a sim/cris directory as you say. I don't understand why I didn't get a cris-sim baseboard in my recent dejagnu checkout. I shall investigate.

I'm not too keen on you changing the word "abort" to "die"
everywhere in comments.  It's highly spurious.  What's next, the
word "gets" because the function gets() is deprecated?
maybe I'm being over keen.  What those comments really mean is
'we'll violate an input constraint on OTHERROUTINE'.  'abort' is
a specific mechanism for failure, one that won't necessarily occur.
The other reason for changing is it makes my life easier grepping :)
<haha-only-serious> 'gets' is not currently a problem in gcc, in
that we don't have code using it :)

Don't these gcc_unreachable and gcc_assert get #defined out with
--disable-checking?  That would cause maintenance problems.

Correct, they are disabled, that's the whole point of --disable-checking. If you want assert checking, then you should say --enable-checking=assert (or some more inclusive flag). Notice that --enable-checking=release does NOT disable asserts. There is a not insignificant cost with using asserts.

The current --disable-checking behaviour is to remove the asserts,
but leave the unreachables in place.  This is necessary so that
the compiler understands the control flow, and doesn't get all
pissy about variables that do not get initialized though an
unreachable control path.  In theory, there's no reason why we
couldn't make a smarter compiler and tell it that 'any flow
ending in gcc_unreachable, is unreachable, so the branch which
brought you down this path can be deleted'.

I'll take this on a test-run with cross to cris-axis-linux-gnu
and check it in myself when I find out the answer.

Many thanks!


nathan

--
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]