From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26869 invoked by alias); 30 Jul 2012 16:05:13 -0000 Received: (qmail 26855 invoked by uid 22791); 30 Jul 2012 16:05:12 -0000 X-SWARE-Spam-Status: No, hits=-5.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-vc0-f169.google.com (HELO mail-vc0-f169.google.com) (209.85.220.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 30 Jul 2012 16:04:58 +0000 Received: by vcbfl10 with SMTP id fl10so5454474vcb.0 for ; Mon, 30 Jul 2012 09:04:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.156.47 with SMTP id wb15mr10538806vdb.53.1343664297922; Mon, 30 Jul 2012 09:04:57 -0700 (PDT) Received: by 10.58.179.79 with HTTP; Mon, 30 Jul 2012 09:04:57 -0700 (PDT) In-Reply-To: <500FB4C4020000780009058B@nat28.tlf.novell.com> References: <500EC9B00200007800090382@nat28.tlf.novell.com> <500FB4C4020000780009058B@nat28.tlf.novell.com> Date: Mon, 30 Jul 2012 16:05:00 -0000 Message-ID: Subject: Re: [PATCH] gas/x86-64: properly distinguish low and high register ranges From: "H.J. Lu" To: Jan Beulich Cc: binutils@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2012-07/txt/msg00287.txt.bz2 On Tue, Jul 24, 2012 at 11:56 PM, Jan Beulich wrote: >>>> On 24.07.12 at 16:16, "H.J. Lu" wrote: >> Can you add some testcases? > > I knew you would ask this, but sorry, this makes no sense - if test > cases would are desirable here, they shouldn't be testing just the > things that this patch fixes, but also any other invalid operand > combinations. As an example - why would testing that "xlat [r11]" > isn't accepted be needed, but not e.g. "xlat [ecx]"? > > Furthermore, this fixes actually broken behavior, so accepting > the change shouldn't be dependent upon test case availability. > What broken behavior does this change fix? Why hasn't it been tested in the testsuite? -- H.J.