[PATCH 10/9] ENABLE_CHECKING refactoring: remove remaining occurrences

[Richard Biener]

On Wed, Feb 24, 2016 at 4:43 PM, Pierre-Marie de Rodat
<derodat@adacore.com> wrote:
> On 02/24/2016 03:53 PM, Martin Liška wrote:
>>
>> On 02/24/2016 03:27 PM, Michael Matz wrote:
>>>
>>> But nothing can set ENABLE_CHECKING anymore (the macro is meanwhile
>>> called
>>> CHECKING_P), so all that code is dead anyway.  So either the new macro
>>> should be used or that code should be removed.
>>
>>
>> Good point, well the change is quite recent (12-2015). I'm adding
>> the author of the code to make a decision about it.
>
>
> Thanks for the heads up! That’s kind of funny: the check associated with
> this dw_loc_frame_offset field revealed a bug to us (at AdaCore) very
> recently, so I think we should keep it in one form or another.
>
> This field takes one int slot in the dw_loc_descr_node structure, so I guess
> not having it in release mode is important (that’s what Jason said in
> <https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02267.html>). Here’s what I
> think:
>
>   * This field is used only in the resolve_args_picking graph traversal
>     for a consistency check in already visited nodes.
>
>   * resolve_args_picking has a hash set to remember the already visited
>     nodes.
>
>   * The consistency check itself has almost no runtime cost: we’re
>     doing the graph traversal in release mode anyway.
>
> So what about removing the field (in struct dw_loc_descr_node) and replacing
> the visited hash set with a frame_offset hash map (in resolve_args_picking)?
> This hash map would remember the information we currently store in the
> field.

Sounds reasonable.

> This is a little change, but I can take care of this if you want. I’m a
> little bit desynchronized with the development pace these days: would this
> be for stage 4 or GCC 7?

Technically it's GCC 7 material.  Can you either change the ENABLE_CHECKING
use to CHECKING_P for GCC 6 or remove the guarded code/fields?

Thanks,
Richard.

> --
> Pierre-Marie de Rodat