This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: fix -fcompare-debug regression in free_lang_data
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Sun, 8 Nov 2009 10:40:59 +0100
- Subject: Re: fix -fcompare-debug regression in free_lang_data
- References: <orhbtzg4y5.fsf@livre.localdomain> <84fc9c000910160255o79c92bb8rfcf5d9a2be2eca86@mail.gmail.com> <or8wfacx8v.fsf@livre.localdomain> <84fc9c000910170420u32b61c0ag3b2c13446a763f6e@mail.gmail.com> <orws21hd89.fsf@livre.localdomain>
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.