From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-409792-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 54660 invoked by alias); 9 Oct 2015 18:34:26 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 54648 invoked by uid 89); 9 Oct 2015 18:34:25 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD autolearn=no version=3.3.2
X-HELO: nikam.ms.mff.cuni.cz
Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 09 Oct 2015 18:34:24 +0000
Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202)	id 916DD543F56; Fri,  9 Oct 2015 20:34:20 +0200 (CEST)
Date: Fri, 09 Oct 2015 18:34:00 -0000
From: Jan Hubicka <hubicka@ucw.cz>
To: Andreas Schwab <schwab@suse.de>
Cc: Jan Hubicka <hubicka@ucw.cz>, Eric Botcazou <ebotcazou@adacore.com>,	gcc-patches@gcc.gnu.org, Richard Biener <rguenther@suse.de>,	Bernd Schmidt <bschmidt@redhat.com>, law@redhat.com
Subject: Re: Do not use TYPE_CANONICAL in useless_type_conversion
Message-ID: <20151009183420.GB7750@kam.mff.cuni.cz>
References: <20151002180022.GA32564@kam.mff.cuni.cz> <alpine.LSU.2.11.1510071050390.6516@zhemvz.fhfr.qr> <20151008034934.GB47818@kam.mff.cuni.cz> <3499233.dG6t8mJFET@polaris> <mvm37xl1gtw.fsf@hawking.suse.de> <20151008230518.GE90964@kam.mff.cuni.cz> <877fmwbdth.fsf@igel.home>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <877fmwbdth.fsf@igel.home>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-SW-Source: 2015-10/txt/msg01013.txt.bz2

> Jan Hubicka <hubicka@ucw.cz> writes:
> 
> > Does the patch in https://gcc.gnu.org/ml/gcc-patches/2015-10/msg00902.html help?
> 
> No, it doesn't.
> 
> #0  fancy_abort (file=0x4000000003f1ce48 "../../gcc/expr.c", line=282, 
>     function=0x4000000003f1ec38 <convert_move(rtx_def*, rtx_def*, int)::__FUNCTION__> "convert_move") at ../../gcc/diagnostic.c:1209
> #1  0x4000000001a816e0 in convert_move (to=0x200000000101b0a0, 
>     from=0x200000000101b088, unsignedp=1) at ../../gcc/expr.c:282
> #2  0x4000000001a87580 in convert_modes (mode=DImode, oldmode=BLKmode, 
>     x=0x200000000101b088, unsignedp=1) at ../../gcc/expr.c:736
> #3  0x4000000001a60e10 in store_field (target=0x20000000010196d8, bitsize=64, 
> Python Exception <type 'exceptions.AttributeError'> 'tuple' object has no attribute 'major': 
>     bitpos=0, bitregion_start=0, bitregion_end=63, mode=DImode, exp=, 
>     alias_set=12, nontemporal=false) at ../../gcc/expr.c:6668

I see, here we dispatch to convert_mode early converting from BLKmode to SImode
      /* Unless MODE is VOIDmode or BLKmode, convert TEMP to MODE.  */
      if (mode != VOIDmode && mode != BLKmode
          && mode != TYPE_MODE (TREE_TYPE (exp)))
        temp = convert_modes (mode, TYPE_MODE (TREE_TYPE (exp)), temp, 1);
I suppose we need imilar treatment as I did in store_field:
  /* We allow move between structures of same size but different mode.
     If source is in memory and the mode differs, simply change the memory.  */
  if (GET_MODE (temp) == BLKmode && GET_MODE (target) != BLKmode)
    { 
      gcc_assert (MEM_P (temp));
      temp = adjust_address_nv (temp, GET_MODE (target), 0);
    }

I wonder if it would make sense to add this into convert_mode itself? or shall we do that
in the conditional above prior dispatching to convert_modes?

Honza