From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <ubizjak@gmail.com>
Received: from mail-qk1-x742.google.com (mail-qk1-x742.google.com
 [IPv6:2607:f8b0:4864:20::742])
 by sourceware.org (Postfix) with ESMTPS id CC1E23851C1A
 for <gcc@gcc.gnu.org>; Thu,  5 Nov 2020 12:26:25 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org CC1E23851C1A
Received: by mail-qk1-x742.google.com with SMTP id 12so911189qkl.8
 for <gcc@gcc.gnu.org>; Thu, 05 Nov 2020 04:26:25 -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=5IeTH8toj4szlRp4bqfK+BmRXsT0Z3k5+2p2VDjByeE=;
 b=pleBooNpTF6tgyw7wuxqUX2cGoVws5yG1v4RtNI6DW0wbeX+0NkvrXVCvmk+QhZDCj
 vAWZj1E/H5rAs1ByAHDzoGxtt9XP52u+pYCyYSljUoe3eiyQtR6EcpGD3TdN0k4Ci6eI
 gOeysv1Kcrnpjlrm4Hbf3qo/mCA1Qz1hUqsAtDDW8xwm86nLfK3MCiLJeFOIKqwI6moQ
 sOfcqoqkHwzugC94NFp4uPT+L3tduazNE5IUyb/Id+P2xy1QTU08r9hkCYKmB9ren1Cc
 GZ5mqy3R0/8NBk7f+UU4TrJ/VRWSLkWIqJTsyISb9M7ghmyA4oTo3q5ivpteW3O7t97g
 YIxg==
X-Gm-Message-State: AOAM533t8WrMiPs4wzHEaiSsrrnkgtftqrnIezA9U4Bsx0X2I61ivdAP
 g7SjrUbJTQmtQSg+863C47hSOsEQDufkl7+41QA=
X-Google-Smtp-Source: ABdhPJxNyAHpF+gDoTmbKcWfgVDDvhLwl2BSTw9C1179Z7m+KKZDSpR2pLpFbS0NMVAeieeEeG/2N4bEcN+anm4SUlA=
X-Received: by 2002:a37:4fcb:: with SMTP id d194mr1644788qkb.465.1604579185426; 
 Thu, 05 Nov 2020 04:26:25 -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>
In-Reply-To: <alpine.LNX.2.20.13.2011051506090.9902@monopod.intra.ispras.ru>
From: Uros Bizjak <ubizjak@gmail.com>
Date: Thu, 5 Nov 2020 13:26:13 +0100
Message-ID: <CAFULd4b_kBKf0i7f1ytyyJpGwdoWfiGjJ+aY4PLy5cyq5JWxVA@mail.gmail.com>
Subject: Re: typeof and operands in named address spaces
To: Alexander Monakov <amonakov@ispras.ru>
Cc: Jakub Jelinek <jakub@redhat.com>, X86 ML <x86@kernel.org>, 
 Andy Lutomirski <luto@amacapital.net>, GCC Development <gcc@gcc.gnu.org>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-1.9 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:26:26 -0000

On Thu, Nov 5, 2020 at 1:14 PM Alexander Monakov <amonakov@ispras.ru> wrote:

> > I was also thinking of introducing of operand modifier, but Richi
> > advises the following:
> >
> > --cut here--
> > typedef __UINTPTR_TYPE__ uintptr_t;
> >
> > __seg_fs int x;
> >
> > uintptr_t test (void)
> > {
> >  uintptr_t *p = (uintptr_t *)(uintptr_t) &x;
> >  uintptr_t addr;
> >
> >  asm volatile ("lea %1, %0" : "=r"(addr) : "m"(*p));
> >
> >  return addr;
> > }
>
> 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).

Agreed, but I was trying to solve this lone use case in the kernel. It
fits this particular usage, so I found a bit of overkill to implement
the otherwise useless operand modifier in gcc. As discussed
previously, these hacks are needed exclusively in asm templates, they
are not needed in "normal" C code.
>
> 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))

I hope that a developer from kernel can chime in and express their
opinion on the proposed approaches.

Uros.