On Wed, 21 Oct 2015, Jeff Law wrote:
> I might even claim it's already helping. While we're still seeing
> syntax errors in the conditionally compiled code, it doesn't feel like
> we're seeing it as often as in the past. That's purely anecdotal based
> on what I've seen fly by over the last co
On Wed, Oct 21, 2015 at 6:27 PM, Jakub Jelinek wrote:
> On Wed, Oct 21, 2015 at 06:22:37PM +0200, Bernd Schmidt wrote:
>> On 10/21/2015 06:18 PM, Jeff Law wrote:
>> >To avoid conditionally compiled code. I'm of the opinion we should be
>> >stomping out as much as we reasonably can.
>>
>> Yeah, I
On 10/18/2015 12:17 AM, Mikhail Maltsev wrote:
Also, gcc_checking_assert in libcpp requires gcc_assert to be defined. That was
missing in my original patch (and was added in patch 2/9), but I think it would
be better to fix it here, as Bernd noticed (in the last paragraph of [1]).
Besides, I li
On 10/21/2015 10:22 AM, Bernd Schmidt wrote:
On 10/21/2015 06:18 PM, Jeff Law wrote:
To avoid conditionally compiled code. I'm of the opinion we should be
stomping out as much as we reasonably can.
Yeah, I get that, but the point I'm trying to make is that if you get
rid of all conditional co
On Wed, Oct 21, 2015 at 06:22:37PM +0200, Bernd Schmidt wrote:
> On 10/21/2015 06:18 PM, Jeff Law wrote:
> >To avoid conditionally compiled code. I'm of the opinion we should be
> >stomping out as much as we reasonably can.
>
> Yeah, I get that, but the point I'm trying to make is that if you get
On 10/21/2015 10:18 AM, Richard Biener wrote:
On October 21, 2015 6:04:38 PM GMT+02:00, Bernd Schmidt
wrote:
On 10/21/2015 05:56 PM, Jeff Law wrote:
The problem is the existing ENABLE_CHECKING conditions.
Anything which is #ifdef ENABLE_CHECKING will have its behavior
changed
if we change
On 10/21/2015 06:18 PM, Jeff Law wrote:
To avoid conditionally compiled code. I'm of the opinion we should be
stomping out as much as we reasonably can.
Yeah, I get that, but the point I'm trying to make is that if you get
rid of all conditional compilation, you don't need either
ENABLE_CHEC
On 10/21/2015 10:04 AM, Bernd Schmidt wrote:
On 10/21/2015 05:56 PM, Jeff Law wrote:
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
On October 21, 2015 6:04:38 PM GMT+02:00, Bernd Schmidt
wrote:
>On 10/21/2015 05:56 PM, Jeff Law wrote:
>> 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 alway
On 10/21/2015 05:56 PM, Jeff Law wrote:
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,
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
(
On 10/18/2015 12:17 AM, Mikhail Maltsev wrote:
On 10/12/2015 11:57 PM, Jeff Law wrote:
-#ifdef ENABLE_CHECKING
+#if CHECKING_P
I fail to see the point of this change.
I'm guessing (and Mikhail, please correct me if I'm wrong), but I think he's
trying to get away from ENABLE_CHECKING and inste
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 a
On 10/18/2015 08:17 AM, Mikhail Maltsev wrote:
On 10/12/2015 11:57 PM, Jeff Law wrote:
-#ifdef ENABLE_CHECKING
+#if CHECKING_P
I fail to see the point of this change.
I'm guessing (and Mikhail, please correct me if I'm wrong), but I think he's
trying to get away from ENABLE_CHECKING and inste
On 10/12/2015 11:57 PM, Jeff Law wrote:
>>> -#ifdef ENABLE_CHECKING
>>> +#if CHECKING_P
>>
>> I fail to see the point of this change.
> I'm guessing (and Mikhail, please correct me if I'm wrong), but I think he's
> trying to get away from ENABLE_CHECKING and instead use a macro which is
> always de
On 10/05/2015 05:27 PM, Mikhail Maltsev wrote:
Hi!
This is an updated series of patches which converts 'ENABLE_CHECKING' macro into
a flag, 'flag_checking' (and 'CHECKING_P' macro in several cases). For now
flag_checking is always initialized with the value of 'CHECKING_P', but later it
can be t
On 10/05/2015 05:27 PM, Mikhail Maltsev wrote:
3. Another one: gcc.c-torture/compile/pr52073.c which is, I guess, caused by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67816 (the backtrace is the same,
at least).
FYI, this is fixed on the trunk.
jeff
On Tue, Oct 6, 2015 at 1:27 AM, Mikhail Maltsev wrote:
> Hi!
>
> This is an updated series of patches which converts 'ENABLE_CHECKING' macro
> into
> a flag, 'flag_checking' (and 'CHECKING_P' macro in several cases). For now
> flag_checking is always initialized with the value of 'CHECKING_P', bu
Hi!
This is an updated series of patches which converts 'ENABLE_CHECKING' macro into
a flag, 'flag_checking' (and 'CHECKING_P' macro in several cases). For now
flag_checking is always initialized with the value of 'CHECKING_P', but later it
can be turned into a proper command-line flag and probabl
19 matches
Mail list logo
