This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 1/9] ENABLE_CHECKING refactoring
- From: Jeff Law <law at redhat dot com>
- To: Mikhail Maltsev <maltsevm at gmail dot com>, Bernd Schmidt <bschmidt at redhat dot com>, gcc-patches mailing list <gcc-patches at gcc dot gnu dot org>, Richard Biener <richard dot guenther at gmail dot com>
- Date: Wed, 21 Oct 2015 09:56:17 -0600
- Subject: Re: [PATCH 1/9] ENABLE_CHECKING refactoring
- Authentication-results: sourceware.org; auth=none
- References: <56130763 dot 4070206 at gmail dot com> <561D7899 dot 9080401 at redhat dot com> <5623398D dot 7040809 at gmail dot com> <5624D05F dot 8080203 at redhat dot com> <5624EED7 dot 2070401 at gmail dot com>
On 10/19/2015 07:23 AM, Mikhail Maltsev wrote:
On 10/19/2015 02:13 PM, Bernd Schmidt wrote:
But for normal C conditions the patches end up using flag_checking, so
the CHECKING_P macro buys us nothing over ENABLE_CHECKING.
Presumably 'if (CHECKING_P)' can be used for performance-critical parts
(in this case the condition will be DCE-d) and also for those parts of
the compiler which we want to decouple from 'options.h'.
IIRC, Jeff's idea was get rid of 'ENABLE_CHECKING' completely and use
either 'flag_checking' or 'CHECKING_P'. But I don't know what is the
consensus on it (I would like to hear Jeff's and Richard's opinion).
Of course it will be easy for me to adjust the patch to whatever the
final decision will be.
Bernd,
The problem is the existing ENABLE_CHECKING conditions.
Anything which is #ifdef ENABLE_CHECKING will have its behavior changed
if we change things so that ENABLE_CHECKING is always defined with a value.
So if we wanted to continue to use ENABLE_CHECKING, but with a value,
then every #ifdef has to be fixed all-at-once.
By using CHECKING_P we can incrementally work our way through uses of
ENABLE_CHECKING, converting them as we go as we're not changing the
meaning of ENABLE_CHECKING.
Once everything is converted, we just drop ENABLE_CHECKING completely.
Does using CHECKING_P make more churn? Perhaps, but it allows us the
freedom to incrementally fix the existing code rather than having to do
everything at once.
jeff