From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id C3B5D385041D for ; Tue, 4 Aug 2020 15:33:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C3B5D385041D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=segher@kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 074FXCBS014152; Tue, 4 Aug 2020 10:33:12 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 074FXBGK014139; Tue, 4 Aug 2020 10:33:11 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Tue, 4 Aug 2020 10:33:10 -0500 From: Segher Boessenkool To: Alexander Monakov Cc: Stefan Franke , gcc-help@gcc.gnu.org Subject: Re: AW: C and C++ parser performing optimizations Message-ID: <20200804153310.GH6753@gate.crashing.org> References: <00cd01d668f8$eb26b950$c1742bf0$@franke.ms> <000301d66a2a$ad8dcb50$08a961f0$@franke.ms> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-9.2 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, TXREP, T_SPF_HELO_PERMERROR, T_SPF_PERMERROR autolearn=no 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 15:33:19 -0000 Hi! On Tue, Aug 04, 2020 at 10:13:12AM +0300, Alexander Monakov via Gcc-help wrote: > 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)); return dx; // and then it is valid code, even > > } > > > > 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. I don't think so? That would be separate extra bugs. > 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. Either we should warn for this, or we should fix this to behave as expected for "const". "volatile" otoh, well, what would that even mean here, maytbe we should just error for that. (Global register vars are different still... together with -ffixed-* that should be pretty easy, but *without* -ffixed-*, global register vars aren't very well defined anyway). Segher