From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12631 invoked by alias); 4 Mar 2020 17:49:31 -0000 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 Received: (qmail 12543 invoked by uid 89); 4 Mar 2020 17:49:30 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_2,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*i:sk:127bebb, H*f:sk:127bebb X-HELO: mail-ot1-f66.google.com Received: from mail-ot1-f66.google.com (HELO mail-ot1-f66.google.com) (209.85.210.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 04 Mar 2020 17:49:27 +0000 Received: by mail-ot1-f66.google.com with SMTP id 66so2865166otd.9 for ; Wed, 04 Mar 2020 09:49:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5lnHLxHwwpxPV9DfWTpZ3/NmGcQ9r32mhMG4mFiBDJs=; b=C9FkIDzEznY/x/if1mI+q6Yk6Z1o6iLPFWCn8gxoaAxdUN8f2ysxQd8+sGIESjgDS8 wXjJATjDuO3Adg/KLQcd0Mg4ngCDS2pWEkJo4z/vSr/JEIEqhoXMQHAg4+v7eVpkJxpG Vuh4f35JvOtYVvnFDMhzVW8f0FFjQyBNawvdUleP2+jsRABP37uCNsxWqqTtAn0EG6tI VLftayKLYj/Oa/oj2MJlQrF9tHYpXmBWjokTB25d/VKdq7Ikjxxqs6vsgZX4fjb5gfHE DhfmYpprxbXBc9ivAXcdvtF0c5uskS4seuyqyzd9CJqfTdlDEPc2ZQUae0pC8OmB7krF fYAg== MIME-Version: 1.0 References: <20200303140920.GA329930@gmail.com> <97ab1ae8-ef86-eb15-68c1-a4a09cccd011@suse.com> <127bebb1-0ae7-593e-695b-13c0cb50e9f6@suse.com> In-Reply-To: <127bebb1-0ae7-593e-695b-13c0cb50e9f6@suse.com> From: "H.J. Lu" Date: Wed, 04 Mar 2020 17:49:00 -0000 Message-ID: Subject: Re: [PATCH] Replace IgnoreSize/DefaultSize with MnemonicSize To: Jan Beulich Cc: Binutils Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2020-03/txt/msg00103.txt On Wed, Mar 4, 2020 at 8:24 AM Jan Beulich wrote: > > On 03.03.2020 20:31, H.J. Lu wrote: > > On Tue, Mar 3, 2020 at 9:26 AM Jan Beulich wrote: > >> > >> On 03.03.2020 18:15, H.J. Lu wrote: > >>> On Tue, Mar 3, 2020 at 6:50 AM Jan Beulich wrote: > >>>> > >>>> On 03.03.2020 15:09, H.J. Lu wrote: > >>>>> I am testing this patch with GCC 8. I will check it in if it fixes > >>>>> regressions in GCC 8 testsuits: > >>>>> > >>>>> https://gcc.gnu.org/ml/gcc-regression/2020-03/msg00008.html > >>>>> > >>>>> H.J. > >>>>> --- > >>>>> According to gas manual, suffix in instruction mnemonics isn't always > >>>>> required: > >>>>> > >>>>> When there is no sizing suffix and no (suitable) register operands to > >>>>> deduce the size of memory operands, with a few exceptions and where long > >>>>> operand size is possible in the first place, operand size will default > >>>>> to long in 32- and 64-bit modes. > >>>> > >>>> Nothing there says that this defaulting is to happen silently. Yet > >>>> _that's_ what my earlier changes altered. The defaulting is still > >>>> the same. And no - SUCH CASES SHOULD NOT GO SILENTLY, neither here > >>>> nor in the MOVSX/MOVZX case. Ambiguities should _always_ be > >>>> pointed out by the assembler. (There may be [and there is] a mode > >>>> in which this goes silently, to be enabled at the programmer's > >>>> risk.) > >>> > >>> It is not going to happen in AT&T syntax. Gas has to support older GCC > >>> without any warnings. > >> > >> Why? What's wrong with pointing out issues even with compiler > >> generated code? In fact iirc gcc used to be buggy in regard of > >> these conversion instructions, and the assembler change helped > >> spot this. > > > > I appreciate your intention. But the primary goal of gas is to serve GCC. > > In this case, there are ino issues with integer conversion in GCC 8 and we > > have to support existing GCC 8. Issue a warning in AT&T syntax is not > > really an option here. > > The initial release of gcc 8 was still buggy, and you can then > extrapolate this to older versions. If code is to be compiled > warning-free with older releases, gcc should get respective > backports. Hiding actual bugs (because of gcc shortcomings) is > not really an option here (to use your wording). I am testing GCC 8.4 release and there are no integer conversion bugs. > Furthermore - if you were to discover more problems with even > older gcc versions, would you then "declare" all those insns > as exceptions too? Such an approach doesn't make any sense to > me. > If you find a GCC codegen bug, please open a GCC bug and I will fix it. -- H.J.