This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: PATCH partial gcj support for disabling assertion
- From: Per Bothner <per at bothner dot com>
- To: David Daney <ddaney at avtrex 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:56:59 -0800
- Subject: Re: PATCH partial gcj support for disabling assertion
- References: <404630FA.2090306@bothner.com> <40464D44.3030709@avtrex.com>
David Daney wrote:
I'll check this into mainline in a few days if I don't hear objections.
I object!
Overruled ...
I want the enabling and disabling of assertions to be independent of
optimization settings.
I.e. you're not objecting to the patch or what it does, but you want
enhanced functionality. Fair enough.
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
flag now?
Why don't *you* add the command line flag after I check in my patch?
The patch clearly shows where add the extra logic in enable_assertions.
My patch is an improvement over the current situation, and is designed
to support for a future flag can just plug. I might do that, if I feel
like it.
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.
I guess you don't read java@gcc.gnu.org. See:
http://gcc.gnu.org/ml/java/2004-03/msg00031.html
--
--Per Bothner
per@bothner.com http://per.bothner.com/