Re: fix -fcompare-debug regression in free_lang_data

[Richard Guenther <richard dot guenther at gmail dot com>]

On Sun, Nov 8, 2009 at 5:06 AM, Alexandre Oliva <aoliva@redhat.com> wrote:
> On Oct 17, 2009, Richard Guenther <richard.guenther@gmail.com> wrote:
>
>> Well - unconditionally (also with -g) run free-lang-data but do not
>> free things (or redirect langhooks), only do the get_alias_set thing.
>> I can try to properly cook up a nice patch, but you might be able to
>> tell if that would fix your problem.
>
> I see you implemented this. ?Thanks.
>
> I see still a problem in Ada. ?Maybe it's not visible with the default
> bootstrap-debug BUILD_CONFIG, because the incorrect use of flag_gtoggle
> hides it, but it's noticeable if you compile with say ada/einfo.adb
> (among tens of others) with '-O2 -fcompare-debug=-g' (without any other
> -g).
>
> The problem is that the Ada boolean_type is overridden by the different
> type set up in free_lang_data(), and then various simplifications that
> succeed when the boolean_type remains the same fail because of a type
> cast.
>
> For example, in ada/einfo.adb, various compares such as this in
> einfo__Dependent_Instances:
>
> ?D.#_3 = !D.#_2;
> ?if (D.#_3 != 0)
>
> are simplified in forwprop1 to
>
> ?if (D.#_2 == 0)
>
> if boolean_type_node is unchanged, but if
> forward_propagate_into_gimple_cond() calls combine_cond_expr_cond() with
> a modified boolean_type_node (e.g. the one set up in free_lang_data()),
> the fold_binary_loc() call will return a NOP_EXPR node to convert an
> Ada-boolean result to the free_lang_data-set boolean_type_node, and
> canonicalize_cond_expr_cond() turns that into a negate and compare that
> does not satisfy is_gimple_condexpr().
>
> Now, it would be possible to tweak canonicalize_cond_expr_cond() to
> handle a NOP_EXPR of a TRUTH_NOT_EXPR and return an EQ_EXPR, rather than
> a NE_EXPR with a TRUTH_NOT_EXPR operand, or perhaps even to get
> fold_binary_loc() to avoid the explicit type-cast, but the result would
> still have a different type from that of a compilation in which
> boolean_type_node is not overridden, so a potential for codegen
> differences would remain.

Can you open a bugreport for this?  I'd like to have a look (but I'll be
unavailable the next week, so I'll likely forget).

> Thoughts?
>
>
> Regardless, the flag_gtoggle in free_lang_data() must go, it doesn't
> make any sense whatsoever, it's doing nothing but papering over this
> problem.

Hm, no idea why it was there in the first place.  A patch to remove it
is pre-approved (if that passes bootstrap & regtest of course).

Thanks,
Richard.