From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cc-smtpout2.netcologne.de (cc-smtpout2.netcologne.de [89.1.8.212]) by sourceware.org (Postfix) with ESMTPS id 7A0193858D38; Sun, 8 Jan 2023 16:21:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7A0193858D38 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=netcologne.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=netcologne.de Received: from cc-smtpin3.netcologne.de (cc-smtpin3.netcologne.de [89.1.8.203]) by cc-smtpout2.netcologne.de (Postfix) with ESMTP id E54DA12540; Sun, 8 Jan 2023 17:21:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=netcologne.de; s=nc1116a; t=1673194892; bh=f/HHBtTmkOE87BCM0nRj8HEVpFvvbwTBKovMcwgyYAM=; h=Message-ID:Date:Subject:To:References:From:In-Reply-To:From; b=WnPlRH04wMYjgMl+0XTEYE82QL292jitMGm6nYQKB9mnmSb3xUbeBaqyFwOznVDv1 ZXT6OXltpoDVaDul8+6p3A1R0GpaaPeKtP5EYOICj5iouGQDm6MBIIfAbb5wiECmoG wb8vrvlZ5d813T2q8rUEsP/zjWx4XC+lCCN6K7XK2j+vUKFTCTIB/mA3IUXe3AxYgh 4olwwFS1v3bXH9cNeWIKs5o7Ez0C5iveNcqQcYHa2KOcWjZGDVeUBIgP7CyZnnA0Zu oTMeNIKXlEtddcsWgZ2FYvZlXFaLivlx7DcsCDUdVmv892HF/KfBnLsykj2jr+r+xJ frgIqq3FuM1ZQ== Received: from [IPV6:2001:4dd7:6842:0:7285:c2ff:fe6c:992d] (2001-4dd7-6842-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de [IPv6:2001:4dd7:6842:0:7285:c2ff:fe6c:992d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by cc-smtpin3.netcologne.de (Postfix) with ESMTPSA id 1D2D811DE5; Sun, 8 Jan 2023 17:21:30 +0100 (CET) Message-ID: Date: Sun, 8 Jan 2023 17:21:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: [patch, fortran] Fix common subexpression elimination with IEEE rounding (PR108329) Content-Language: en-US To: Richard Biener , "fortran@gcc.gnu.org" , gcc-patches References: <79BE0629-246D-4EB8-A68F-4D9FEA6B013E@gmail.com> From: Thomas Koenig In-Reply-To: <79BE0629-246D-4EB8-A68F-4D9FEA6B013E@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-NetCologne-Spam: L X-Rspamd-Queue-Id: 1D2D811DE5 X-Spamd-Bar: -- X-Rspamd-Action: no action X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Richard, >> Am 08.01.2023 um 14:31 schrieb Paul Richard Thomas via Fortran : >> >> Hi Thomas, >> >> Following your off-line explanation that the seemingly empty looking >> assembly line forces an effective reload from memory, all is now clear. > > It’s not a full fix (for register vars) and it’s ‚superior‘ to the call itself only because asm handling is implemented in a rather stupid way in the Alias oracle. So I don’t think this is a „fix“ at all. There are no register variables in Fortran, this is Fortran FE only, and it is a fix in the sense that correct code is no longer miscompiled. There's a FIXME in the code pointing to the relevant PR precisely because I think that this is less than elegant (as do you, obviously). Do you have other suggestions how to implement this? If PR 34678 is solved, this would probably provide a mechanism that we could simply re-use. Best regards Thomas