From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id 80FAA3891C19 for ; Tue, 22 Jun 2021 13:22:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 80FAA3891C19 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 9378721964; Tue, 22 Jun 2021 13:22:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1624368177; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Q+z6pre9ChCcJsNlxvFka8a50OIO5lpqOZHMYnoBE3o=; b=mt+YyWIMwyqNFT35lQ4zN1p403C9nL/za5U4cP5mmFaAjHkFwYbYjSBBgaJFddB4oJBk8U d724tT/VL8zOcJ+QoSInnaFiagEy/xRnerLJnyXukMVORxYWVaN09y7fGFGOhnX91mQdnY 3CWxdf36U+XAbKznu8lzToPK2Iizu50= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1624368177; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Q+z6pre9ChCcJsNlxvFka8a50OIO5lpqOZHMYnoBE3o=; b=TbhSBIeQ6sdgKH+0gwFHfdTb5e3TLQTGBHAAQme1uwb6WRa+4Lh7mOrUSFgtezo+E/J+m8 svnKw03YECCX9PBg== Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 8CA35A3B84; Tue, 22 Jun 2021 13:22:57 +0000 (UTC) Received: by wotan.suse.de (Postfix, from userid 10510) id 84B796537; Tue, 22 Jun 2021 13:22:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by wotan.suse.de (Postfix) with ESMTP id 828FC622D; Tue, 22 Jun 2021 13:22:57 +0000 (UTC) Date: Tue, 22 Jun 2021 13:22:57 +0000 (UTC) From: Michael Matz To: "H.J. Lu" cc: Jan Beulich , Binutils Subject: Re: [PATCH 3/6] x86: harmonize disp with imm handling In-Reply-To: Message-ID: References: <0babbec4-06ae-f980-18a9-20608046891b@suse.com> <34a3a825-8c9f-d52b-9a1d-6cd45e051332@suse.com> <803f03a4-bb6d-5580-b2ff-b1df2d5152f3@suse.com> <9212df8b-01cf-0c0c-45c3-39de3dcf1bd9@suse.com> User-Agent: Alpine 2.22 (LSU 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Tue, 22 Jun 2021 13:22:59 -0000 Hello, On Fri, 18 Jun 2021, H.J. Lu via Binutils wrote: > > You realize that for the purpose of the test case the -0xffffffff is > > an over-simplification of what might appear in "real" code, don't > > you? It also feels as if you didn't really read my earlier remark: > > I don't think treating -0xffffffff as 1 here helps anyone. The assembler should not be too much in the business of constraining users with well-intended but badly implemented rules. The -0xffffffff isn't actually a literal, it's an (assembler) operation applied to a literal. The wraparound that does or doesn't happen is _internal_ to the assembler, the hardware doesn't enter the picture. -0xffffffff only means '1' because the assembler internally represents this as 32bit entity, again without the hardware mattering. (And if it were using a different-sized internal field it would or wouldn't warn on different input ranges, and if that size then depends on how BFD is configured that would be very bad). Further it's quite probable that the '-' actually comes from e.g. a macro expansion, it's for instance feasible to write a macro that offsets something by a constant in both directions: #define sub2(reg, B, D) \ movq D(B), reg \ addq -D(B), reg Now it's completely opaque why the user should be warned about this: sub2(%rax, %rdi, 0xffffffff) but not about this: sub2(%rax, %rdi, 1) What you are saying is equivalent to say to also warn about uses of '--1', after all the user "should have simply used "1"'. Extended such makes it obvious that the warning is unwarranted, because then there wouldn't even be a work-around for the above situation anymore, you can't write sub2(%rax,%rdi,0xffffffff) and you can't write sub2(%rax,%rdi,-1). I would perhaps agree that if a user literally would write '-0xffffffff' except in a testcase that a warning might be appropriate, in something that's designed to teach good style to assembler programmers perhaps. But not in GNU as. It would be a warning that can't be silenced and happens in perfectly valid code, so, no. All in all: I think the assembler should be entirely silent about any of these literals modified by assembler operations. Ciao, Michael.