From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.axis.com (smtp1.axis.com [195.60.68.17]) by sourceware.org (Postfix) with ESMTPS id 086DB3858407 for ; Fri, 6 May 2022 02:35:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 086DB3858407 From: Hans-Peter Nilsson To: Alan Modra CC: , In-Reply-To: (message from Alan Modra on Fri, 6 May 2022 02:56:46 +0200) Subject: Re: [PATCH] Don't define ARCH_cris for BFD64 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT References: <20220504075628.81292-1-luis.machado@arm.com> <88ada15d-c371-df10-368e-f1c9fb91c289@arm.com> <20220504143703.58AD620462@pchp3.se.axis.com> Message-ID: <20220506023524.A006820448@pchp3.se.axis.com> Date: Fri, 6 May 2022 04:35:24 +0200 X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_NUMSUBJECT, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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, 06 May 2022 02:35:27 -0000 > From: Alan Modra > Date: Fri, 6 May 2022 02:56:46 +0200 > As is often the case the truth is more complicated than it would > appear on the surface. While aiming for the bigger picture is a good thing, you're here letting the perfect be the enemy of the good. A reasonable step would be to get all targets want64=true, to avoid this annoying host-32/64-bit difference. > I think the cris support works fine with a > 32-bit bfd. It's just that the cris testsuite has expressions > that overflow 32 bits. > > gas/testsuite/gas/cris/shexpr-1.s has this expression: > > ((0x17<<23)+((0xfede4194/8192)<<4)+8) > > It evaluates to 0x0bff6f28 when calculating in 64 bits, but to > 0x0b7f6f38 when calculating in 32 bits But seeing it as "calculating in 32 bits" is just So Wrong! I admit I worked around this missing tracking of subexpression signeness and papering over the gas bug by just making the problem go away for *this* port. Now 20 years down the line, when 64-bit is the norm, IMHO that's a preferred solution (while waiting for Someone to rewrite the expression bits, but it also happens to get host-size-uniform address output). brgds, H-P