From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <amonakov@ispras.ru>
Received: from mail.ispras.ru (mail.ispras.ru [83.149.199.84])
 by sourceware.org (Postfix) with ESMTPS id E322E3857C7C
 for <gcc-help@gcc.gnu.org>; Tue,  4 Aug 2020 07:13:14 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E322E3857C7C
Received: from monopod.intra.ispras.ru (unknown [10.10.3.121])
 by mail.ispras.ru (Postfix) with ESMTPS id 0ACC740A2045;
 Tue,  4 Aug 2020 07:13:13 +0000 (UTC)
Date: Tue, 4 Aug 2020 10:13:12 +0300 (MSK)
From: Alexander Monakov <amonakov@ispras.ru>
To: Stefan Franke <stefan@franke.ms>
cc: gcc-help@gcc.gnu.org
Subject: Re: AW: C and C++ parser performing optimizations
In-Reply-To: <000301d66a2a$ad8dcb50$08a961f0$@franke.ms>
Message-ID: <alpine.LNX.2.20.13.2008041009540.2454@monopod.intra.ispras.ru>
References: <00cd01d668f8$eb26b950$c1742bf0$@franke.ms>
 <alpine.LNX.2.20.13.2008022131370.2454@monopod.intra.ispras.ru>
 <000301d66a2a$ad8dcb50$08a961f0$@franke.ms>
User-Agent: Alpine 2.20.13 (LNX 116 2015-12-14)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
 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: gcc-help@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-help mailing list <gcc-help.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-help>,
 <mailto:gcc-help-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-help/>
List-Post: <mailto:gcc-help@gcc.gnu.org>
List-Help: <mailto:gcc-help-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-help>,
 <mailto:gcc-help-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Aug 2020 07:13:16 -0000

On Tue, 4 Aug 2020, Stefan Franke wrote:

> Here is an example where gcc creates wrong code:
> 
> test.c:
> int foo() {
>   const char * const txt = "hello";
>   register const char * const p asm("ecx") = txt;
>   register int dx asm("edx");
>   asm(" call _faa" :"=r" (dx) :"rf" (p));
> }
> 
> gcc -O1 -S test.c -fdump-tree-original
> 
> The variable p gets replaced and the asm input parameters are wrong:
> 
> __asm__(" call _faa":"=r" dx:"rf" (const char * const) "hello");

I think it's a separate issue: even if the frontend wouldn't do such
propagation, I'm pretty sure later passes would. const and volatile
qualifiers just do not work as expected with register variables, and
since recently the documentation mentions that:

6.47.5.2 Specifying Registers for Local Variables

Do not use type qualifiers such as const and volatile, as the outcome may be
contrary to expectations. In particular, when the const qualifier is used, the
compiler may substitute the variable with its initializer in asm statements,
which may cause the corresponding operand to appear in a different register. 


6.47.5.1 Defining Global Register Variables

Do not use type qualifiers such as const and volatile, as the outcome may be
contrary to expectations. In particular, using the volatile qualifier does not
fully prevent the compiler from optimizing accesses to the register.