From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 125814 invoked by alias); 9 Jun 2015 16:21:39 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 125759 invoked by uid 89); 9 Jun 2015 16:21:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 09 Jun 2015 16:21:38 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 8F40D2B6485; Tue, 9 Jun 2015 16:21:36 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-89.ams2.redhat.com [10.36.116.89]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t59GLYqM030019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 9 Jun 2015 12:21:36 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.9/8.14.9) with ESMTP id t59GLX33025328; Tue, 9 Jun 2015 18:21:34 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.9/8.14.9/Submit) id t59GLWu4025327; Tue, 9 Jun 2015 18:21:32 +0200 Date: Tue, 09 Jun 2015 16:57:00 -0000 From: Jakub Jelinek To: Uros Bizjak Cc: "H.J. Lu" , "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH] Fix ix86_split_long_move collision handling with TLS (PR target/66470) Message-ID: <20150609162132.GE10247@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20150609115739.GZ10247@tucnak.redhat.com> <20150609125703.GA10247@tucnak.redhat.com> <20150609133905.GB10247@tucnak.redhat.com> <20150609142638.GC10247@tucnak.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00692.txt.bz2 On Tue, Jun 09, 2015 at 06:16:32PM +0200, Uros Bizjak wrote: > > something? Would it be acceptable to just guard the changes in the patch > > with !TARGET_X32 and let H.J. deal with that target? I'm afraid I'm lost > > when to ZERO_EXTEND addr (if needed at all), etc. > > If you wish, I can take your patch and take if further. -mx32 is a > delicate beast... If you could, it would be appreciated, I'm quite busy with OpenMP 4.1 stuff now. Note that for -m64/-mx32 it will be much harder to create a reproducer, because to trigger the bug one has to convince the register allocator to allocate the lhs of the load in certain registers (not that hard), but also the index register (to be scaled, also not that hard) and also the register holding the tls symbol immediate. Wonder if one has to keep all but the two registers live across the load or something similar. Jakub