From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <ubizjak@gmail.com>
Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com
 [IPv6:2607:f8b0:4864:20::834])
 by sourceware.org (Postfix) with ESMTPS id 468FC39D1C37
 for <gcc@gcc.gnu.org>; Thu,  5 Nov 2020 12:36:06 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 468FC39D1C37
Received: by mail-qt1-x834.google.com with SMTP id h12so915964qtu.1
 for <gcc@gcc.gnu.org>; Thu, 05 Nov 2020 04:36:06 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=IW11Za5mc4bLLbmSIVzZ70N9dLhUK1QinVu9HBo82IE=;
 b=QlPVXPxjNIJHW+hAbwvv8ueEvYks0mAl+UcMOfsx6gk6UKAMKn//YNAqnk/U80CwCf
 y+NfVP6Ne5yOFoExggzxgd9X5AR+X361hdCWdmJkPezZBfQGHEu0cngse7VEUsCbQUs7
 dAEov618tUnUdrLQJXC10KbxnXSjnl1TcD+iym2gctsvn52oRhjZ5yKo45P61jbm8GLC
 QN7Ry1yMHKVpduxEbTKAiiQyuZ+o/9wDipUtAGpjOh/KCddqARfK1lPR/GVz/jQmOIV4
 6ogqYYwC1V8LMViuiz/cgTaXQwq+sdNUbRdaP9Ca6OZSGXBXjnHzQHBPLu7bAlIEJVY1
 9mqA==
X-Gm-Message-State: AOAM532cdQCb33DvAgxugMUOmZxTDVQP6ZyuYDBYQBDPLK8cVfLBhEzO
 LGh4OqECUgN7o5asIo3Mo562cLHV0SLFmkeXD6c=
X-Google-Smtp-Source: ABdhPJz9mej3G7zwsTqVX7XOya/GijHznyeyK003pkbq+aa1Gg9tmDN3eic2WTQCFLc/xxmekPVTgWRuvQk6vHj8mfw=
X-Received: by 2002:ac8:714a:: with SMTP id h10mr1664619qtp.292.1604579765896; 
 Thu, 05 Nov 2020 04:36:05 -0800 (PST)
MIME-Version: 1.0
References: <CAFULd4aOca3k-AZ+ocMBqDRpH_kNisBQwfK0F4Jf7znsPxsrBw@mail.gmail.com>
 <CAFiYyc2a2ZY082MSjZiQNHo51ReYGAjyYB24hMhRQvbMY898vw@mail.gmail.com>
 <CAFULd4aoEG4b3AHKMcj-xK6OG0R-wH0HsjUoVyM6WnUB00gAtw@mail.gmail.com>
 <alpine.LNX.2.20.13.2011051224220.9902@monopod.intra.ispras.ru>
 <CAFULd4aa1-+KP5A2Zfyjh8b+cnZoJmU8GKDb9auTuMOwt0L2oA@mail.gmail.com>
 <alpine.LNX.2.20.13.2011051353350.9902@monopod.intra.ispras.ru>
 <CAFULd4agQSZ=v5DQgF=vKZdn_fvAHyfmKawSVBPnvqtNWdgcvQ@mail.gmail.com>
 <alpine.LNX.2.20.13.2011051506090.9902@monopod.intra.ispras.ru>
 <CAFiYyc3HcJBwmN+EmVKW4_R0VVQM6dsBtHsGwjyfsKza5QNFcw@mail.gmail.com>
 <CAFULd4Zz+Ju+1RVUcJQzUsvZpJn1O52YLPfVZD2_b4i05VFSDA@mail.gmail.com>
In-Reply-To: <CAFULd4Zz+Ju+1RVUcJQzUsvZpJn1O52YLPfVZD2_b4i05VFSDA@mail.gmail.com>
From: Uros Bizjak <ubizjak@gmail.com>
Date: Thu, 5 Nov 2020 13:35:54 +0100
Message-ID: <CAFULd4ZHcfsK=H4OTqeYS+N+9y=sr=DuJ0TN4JYBCk5_G6gMRA@mail.gmail.com>
Subject: Re: typeof and operands in named address spaces
To: Richard Biener <richard.guenther@gmail.com>
Cc: Alexander Monakov <amonakov@ispras.ru>, Jakub Jelinek <jakub@redhat.com>, 
 GCC Development <gcc@gcc.gnu.org>, X86 ML <x86@kernel.org>,
 Andy Lutomirski <luto@amacapital.net>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,
 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 12:36:07 -0000

On Thu, Nov 5, 2020 at 1:32 PM Uros Bizjak <ubizjak@gmail.com> wrote:
>
> On Thu, Nov 5, 2020 at 1:24 PM Richard Biener
> <richard.guenther@gmail.com> wrote:
>
> > > This is even worse undefined behavior compared to my solution above:
> > > this code references memory in uintptr_t type, while mine preserves the
> > > original type via __typeof. So this can visibly break with TBAA (though
> > > the kernel uses -fno-strict-aliasing, so this particular concern wouldn't
> > > apply there).
> > >
> > > If you don't care about preserving sizeof and type you can use a cast to char:
> > >
> > > #define strip_as(mem) (*(char *)(intptr_t)&(mem))
> >
> > But in the end, on x86 the (uintptr_t)&x cast yields you exactly
> > the offset from the segment register, no?  The casting back
> > to (uintrptr_t *) and the "dereference" is just because the
> > inline asm is not able to build the lea otherwise?  that said,
> > sth like
> >
> >  asm volatile ("lea fs:%1, %0" : "=r"(addr) : "r" ((uintptr_t)&x));
>
> No, this is not how LEA operates. It needs a memory input operand. The
> above will report "operand type mismatch for 'lea'" error.

The following will work:

  asm volatile ("lea (%1), %0" : "=r"(addr) : "r"((uintptr_t)&x));

Uros.