This is the mail archive of the
mailing list for the GCC project.
Re: PATCH partial gcj support for disabling assertion
- From: David Daney <ddaney at avtrex dot com>
- To: Per Bothner <per at bothner dot com>
- Cc: gcc-patches at gcc dot gnu dot org, java-patches at gcc dot gnu dot org
- Date: Wed, 03 Mar 2004 13:25:24 -0800
- Subject: Re: PATCH partial gcj support for disabling assertion
- References: <404630FA.firstname.lastname@example.org>
Per Bothner wrote:
The attached patch provides a compiler hook for disable or
enabling assertion. It does add any new flags or fine-grained
control, yet: assertions are enabled if generating class files
or not optimizing, and disabled if optimizing and generying native
code. I think this is a reasonable default; new options can be
use to override the default - I may add those later.
Note that when assertions are disabled, we still build a tree
that includes the assertion and the asertion value, so the
compiler can check for errors. But because the assertion
is rewritten to 'false && ASSERTION" it will get optimized out.
(It least it does this when optimizing; we should verify this
when we add a flag to disable assertion even when not optimizing.)
Tested in Fedora Core (with Mauve and Jacks); no regressions.
I'll check this into mainline in a few days if I don't hear objections.
I want the enabling and disabling of assertions to be independent of
It could default to this behavior, but there must be a command line flag
to override. Given that this is the case, why not add the command line
It would probably be a code generation flag. How about -fassertions and
-fno-assertions or -fenable-assertions and -fdisable-assertions ?
Of course we also need the ability to turn them off at runtime with a
flag to the runtime.