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 087AF3857C7E
 for <gcc@gcc.gnu.org>; Thu,  5 Nov 2020 09:36:03 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 087AF3857C7E
Received: from monopod.intra.ispras.ru (unknown [10.10.3.121])
 by mail.ispras.ru (Postfix) with ESMTPS id 3A9D640A1DD8;
 Thu,  5 Nov 2020 09:36:01 +0000 (UTC)
Date: Thu, 5 Nov 2020 12:36:01 +0300 (MSK)
From: Alexander Monakov <amonakov@ispras.ru>
To: Uros Bizjak <ubizjak@gmail.com>
cc: Richard Biener <richard.guenther@gmail.com>, 
 Jakub Jelinek <jakub@redhat.com>, GCC Development <gcc@gcc.gnu.org>, 
 X86 ML <x86@kernel.org>, Andy Lutomirski <luto@amacapital.net>
Subject: Re: typeof and operands in named address spaces
In-Reply-To: <CAFULd4aoEG4b3AHKMcj-xK6OG0R-wH0HsjUoVyM6WnUB00gAtw@mail.gmail.com>
Message-ID: <alpine.LNX.2.20.13.2011051224220.9902@monopod.intra.ispras.ru>
References: <CAFULd4aOca3k-AZ+ocMBqDRpH_kNisBQwfK0F4Jf7znsPxsrBw@mail.gmail.com>
 <CAFiYyc2a2ZY082MSjZiQNHo51ReYGAjyYB24hMhRQvbMY898vw@mail.gmail.com>
 <CAFULd4aoEG4b3AHKMcj-xK6OG0R-wH0HsjUoVyM6WnUB00gAtw@mail.gmail.com>
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=-3.3 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@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc mailing list <gcc.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc>,
 <mailto:gcc-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <mailto:gcc-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc>,
 <mailto:gcc-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Nov 2020 09:36:07 -0000

On Thu, 5 Nov 2020, Uros Bizjak via Gcc wrote:

> > Looks like writing
> >
> >     typeof((typeof(_var))0) tmp__;
> >
> > makes it work.  Assumes there's a literal zero for the type of course.
> 
> This is very limiting assumption, which already breaks for the following test:

To elaborate Richard's idea, you need a way to decay lvalue to rvalue inside
the typeof to strip the address space; if you need the macro to work for
more types than just scalar types, the following expression may be useful:

  typeof(0?(_var):(_var))

(though there's a bug: +(_var) should also suffice for scalar types, but
 somehow GCC keeps the address space on the resulting rvalue)

But I wonder if you actually need this at all:

> > works around the warning.  I think the wording you cite
> > suggests (uintptr_t) &y here, not sure if there's a reliable
> > way to get the lea with just a uintptr_t operand though.
> 
> No, because we have to use the "m" constraint for the LEA. We get the
> following error:

What is the usecase for stripping the address space for asm operands?
>From reading the patch I understand the kernel wants to pass qualified
lvalues to inline assembly to get

  lea <reg>, %fs:<mem>

LEA without the %fs will produce the offset within the segment, which
you can obtain simply by casting the pointer to intptr_t in the first place.

Alexander