From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) by sourceware.org (Postfix) with ESMTPS id 873E43858C83 for ; Fri, 19 Aug 2022 14:19:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 873E43858C83 Received: by mail-qt1-x82b.google.com with SMTP id h22so3418702qtu.2 for ; Fri, 19 Aug 2022 07:19:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=KTvau2M5e6MQoXlUOe1MlvY/ROBB3uy9I5AZ+U9tFOc=; b=tzpibuLDFv7GqbonzzXQqO4boF4X3Lnk7ihYMaOuDPNJt/Q6jm3Zi0G6K9wka7d/ac OM169was0mMBAU5p9EoiAM0dPQjJ0J97zKci615yeKy5gK/Md5ZDfA3Py1ctVFOSJF0U eWeYeqfw+Yy49oGaqvs8xAoAZ1ygrAqng6JAMxuQ8qwD9dSRpBSzxlgxBczK6b7JM0Ri On7dBGyfOxy6r8j2PfwQ1Jcxaz9ta8ItbsOAXNS1yW3QOJhsCweBT+kQc3eIXXAygBBE jEW1hWuMqoybMye+C5O4dm7OvFGXm/G6amQr5u4HCPabjp6eznJqnpeGyhkXX84Xc+9F 750Q== X-Gm-Message-State: ACgBeo0VkdqqFPIes1G8F1/IBfZ8UoJF3wdxjQfd4I/Y9iZNFO2Xw6v/ YXxUTE5565QkdW96Gk7P/GBSHNskiljf4idxoXo= X-Google-Smtp-Source: AA6agR4mtLdgz9WF7xKZFX9/5jdleiu3jZJAtVy15Fg2SFlY3DtaGbEwDI7mEhV4VS/ED+Ffy84deyDmpIFdrBZd6ss= X-Received: by 2002:ac8:7f04:0:b0:343:36d:9a1f with SMTP id f4-20020ac87f04000000b00343036d9a1fmr6623939qtk.566.1660918743758; Fri, 19 Aug 2022 07:19:03 -0700 (PDT) MIME-Version: 1.0 References: <32216291-fd1f-4579-87de-d24cb7190894@suse.com> <8e4dc724-3516-6ec7-5a6b-70ed70e3e237@suse.com> <6db15eed-88f1-cfaa-9650-bc15b18f665d@suse.com> <0340bbbf-7177-5404-b078-f1c6be287a39@suse.com> In-Reply-To: <0340bbbf-7177-5404-b078-f1c6be287a39@suse.com> From: "H.J. Lu" Date: Fri, 19 Aug 2022 07:18:27 -0700 Message-ID: Subject: Re: [PATCH 3/7] x86: move / quiesce pre-386 non-16-bit warning To: Jan Beulich Cc: Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3018.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2022 14:19:06 -0000 On Thu, Aug 18, 2022 at 11:13 PM Jan Beulich wrote: > > On 18.08.2022 17:30, H.J. Lu wrote: > > On Thu, Aug 18, 2022 at 12:21 AM Jan Beulich wrote: > >> > >> On 17.08.2022 21:21, H.J. Lu wrote: > >>> On Tue, Aug 16, 2022 at 12:31 AM Jan Beulich wrote: > >>>> > >>>> Emitting this warning for every insn, including ones having actual > >>>> errors, is annoying. Introduce a boolean variable to emit the warning > >>>> just once on the first insn after .arch may have changed the things, and > >>>> move the warning to output_insn(). (I didn't want to go as far as > >>>> checking whether the .arch actually turned off the i386 bit, but doing > >>>> so would be an option.) > >>>> --- > >>>> Otoh I wonder whether switching to a pre-386 architecture shouldn't > >>>> automatically move to CODE_16BIT: Us emitting operand- or address-size > >>>> prefixes violates the architecture specification. Alternatively we > >>>> could outright reject such .arch directives when not already in 16-bit > >>>> mode. > >> > >> Mind me asking - no opinion here? > > > > We shouldn't change the current behavior to avoid any surprises. > > And continue to emit non-working code. Recall that the warning message > talks of only "addressing mode", which even I initially took to mean > what it say, and hence being entirely bogus to emit for insns without > memory operand (or anything else susceptible to address size setting). If it is a real error, we should issue an error. > I did actually try to find better wording for the warning, but > couldn't come up with anything halfway sensible and not overly long. > > Jan -- H.J.