This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] PR middle-end/19874: TweakSTRIP_USELESS_TYPE_CONVERSION
- From: Jeffrey A Law <law at redhat dot com>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 28 Feb 2005 10:09:39 -0700
- Subject: Re: [PATCH] PR middle-end/19874: TweakSTRIP_USELESS_TYPE_CONVERSION
- Organization: Red Hat, Inc
- References: <Pine.LNX.email@example.com>
- Reply-to: law at redhat dot com
On Thu, 2005-02-24 at 21:30 -0700, Roger Sayle wrote:
> The following patch is my proposed change to resolve PR middle-end/19874
> which is an ICE-on-valid regression on mainline caused by emit_move_insn
> being passed incompatible modes for source and destination. The problem,
> analaysed by Jakub Jelinek was that STRIP_USELESS_TYPE_CONVERSION was
> stripping a mode changing conversion due to lang_hooks.types_compatible_p
> for the C/C++ front-ends claiming that two types were compatible as they
> have the same TYPE_MAIN_VARIANT.
> Jakub's suggested fix, described in the bugzilla PR, was to tweak the
> handle_mode_attribute function in c-common.c and comptypes function in
> c-typeck.c, to change "types_compatible_p", which unfortunately breaks
> the C++ front-end.
> The alternate solution below is to tweak tree_ssa_useless_type_conversion
> such that no conversion that changes the mode of it's operand is
> considered "useless". This intuitive approach also simplifies the code
> in that function, which guarantees the modes match in every case except
> for the front-end's notion of type compatability. Indeed, I'm not sure
> the front-end's type system should be affecting the optimizations
> performed at this point in tree-ssa.
> This approach is probably contentious, so I'll check with folks whether
> they feel this fix is too conservative and potentially misses useful
> The following patch has been tested on i686-pc-linux-gnu with a full "make
> bootstrap", all default languages, and regression tested with a top-level
> "make -k check" with no new failures. Jakub's testcase passes with this
> patch but fails without it.
> Ok for mainline?
A conversion between types with different underlying modes definitely
is not useless. I thought we were explicitly checking for that at one
time, either my memory is failing or we lost those explicit checks.
Regardless of what's happened in the past, I absolutely agree with
explicitly rejecting any type conversion with different modes.