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: [PATCH 1/9] ENABLE_CHECKING refactoring


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


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