From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-490258-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 89775 invoked by alias); 16 Nov 2018 15:21:53 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 89765 invoked by uid 89); 16 Nov 2018 15:21:52 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=Every, Reading, claim, letter
X-HELO: mx1.suse.de
Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 16 Nov 2018 15:21:51 +0000
Received: from relay2.suse.de (unknown [195.135.220.254])	by mx1.suse.de (Postfix) with ESMTP id 7FD58AB7D;	Fri, 16 Nov 2018 15:21:49 +0000 (UTC)
Date: Fri, 16 Nov 2018 15:21:00 -0000
From: Michael Matz <matz@suse.de>
To: Alexander Monakov <amonakov@ispras.ru>
cc: Segher Boessenkool <segher@kernel.crashing.org>,     Jakub Jelinek <jakub@redhat.com>, Martin Sebor <msebor@gmail.com>,     Gcc Patch List <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] diagnose unsupported uses of hardware register variables (PR 88000)
In-Reply-To: <alpine.LNX.2.20.13.1811151858010.10221@monopod.intra.ispras.ru>
Message-ID: <alpine.LSU.2.21.1811161515200.18790@wotan.suse.de>
References: <20181114122250.GZ23873@gate.crashing.org> <20181114122726.GW11625@tucnak> <alpine.LNX.2.20.13.1811141531160.10221@monopod.intra.ispras.ru> <20181114135305.GB23873@gate.crashing.org> <alpine.LNX.2.20.13.1811141658570.10221@monopod.intra.ispras.ru> <20181114174723.GD23873@gate.crashing.org> <alpine.LNX.2.20.13.1811142053100.10221@monopod.intra.ispras.ru> <alpine.LSU.2.21.1811151544332.18790@wotan.suse.de> <alpine.LNX.2.20.13.1811151858010.10221@monopod.intra.ispras.ru>
User-Agent: Alpine 2.21 (LSU 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-IsSubscribed: yes
X-SW-Source: 2018-11/txt/msg01460.txt.bz2

Hi,

On Thu, 15 Nov 2018, Alexander Monakov wrote:

> Reading the documentation certainly does not make that impression to me. 
> In any case, can you elaborate a bit further please:
> 
> 1. Regarding the comparison to 'volatile' qualifier.  Suppose you have an
> automatic variable 'int v;' in a correct program.  The variable is only used
> for some arithmetic, never passed to asms, does not have its address taken.

I should have been more precise, I meant volatile and mapped to some 
device memory.  I.e. a register variable is never automatic in that sense.  
Every read can return different values even without intervening changes in 
source code.

> 2. Are testcases given in PR 87984 valid? Quoting the latest example:
> 
> int f(void)
> {
>     int o=0, i;
>     for (i=0; i<3; i++) {
>         register int a asm("eax");
>         a = 1;
>         asm("add %1, %0" : "+r"(o) : "r"(a));
>         asm("xor %%eax, %%eax" ::: "eax");
>     }
>     return o;
> }

Which is indeed what happens here.

> This follows both your model

Not really, it ignores the fact that 'a' can change at any time, which is 
what happens.

> and the documentation to the letter, and yet will return 1 rather than 
> 3.
> 
> I disagree that it is practical to implement your model on GIMPLE.

I claim that that is what is implemented right now.


Ciao,
Michael.