All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: Uros Bizjak <ubizjak@gmail.com>,
	GCC Development <gcc@gcc.gnu.org>, X86 ML <x86@kernel.org>,
	Jakub Jelinek <jakub@redhat.com>,
	Andy Lutomirski <luto@amacapital.net>,
	linux-toolchains@vger.kernel.org, borntraeger@de.ibm.com,
	Will Deacon <will@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	mpe@ellerman.id.au
Subject: Re: typeof and operands in named address spaces
Date: Tue, 10 Nov 2020 08:52:36 +0100	[thread overview]
Message-ID: <20201110075236.GS2594@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20201109193851.GI2672@gate.crashing.org>

On Mon, Nov 09, 2020 at 01:38:51PM -0600, Segher Boessenkool wrote:
> On Mon, Nov 09, 2020 at 01:47:13PM +0100, Peter Zijlstra wrote:
> > 
> > + lots of people and linux-toolchains
> > 
> > On Wed, Nov 04, 2020 at 07:31:42PM +0100, Uros Bizjak wrote:
> > > Hello!
> > > 
> > > I was looking at the recent linux patch series [1] where segment
> > > qualifiers (named address spaces) were introduced to handle percpu
> > > variables. In the patch [2], the author mentions that:
> > > 
> > > --q--
> > > Unfortunately, gcc does not provide a way to remove segment
> > > qualifiers, which is needed to use typeof() to create local instances
> > > of the per-cpu variable. For this reason, do not use the segment
> > > qualifier for per-cpu variables, and do casting using the segment
> > > qualifier instead.
> > > --/q--
> > 
> > C in general does not provide means to strip qualifiers.
> 
> Most ways you can try to use the result are undefined behaviour, even.
> 
> > We recently had
> > a _lot_ of 'fun' trying to strip volatile from a type, see here:
> > 
> >   https://lore.kernel.org/lkml/875zimp0ay.fsf@mpe.ellerman.id.au
> > 
> > which resulted in the current __unqual_scalar_typeof() hack.
> > 
> > If we're going to do compiler extentions here, can we pretty please have
> > a sane means of modifying qualifiers in general?
> 
> What do you want to do with it?  It may be more feasible to do a
> compiler extension for *that*.

Like with the parent use-case it's pretty much always declaring
temporaries in macros. We don't want the temporaries to be volatile, or
as the parent post points out, to have a segment qualifier.


      parent reply	other threads:[~2020-11-10  7:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAFULd4aOca3k-AZ+ocMBqDRpH_kNisBQwfK0F4Jf7znsPxsrBw@mail.gmail.com>
2020-11-09 12:47 ` typeof and operands in named address spaces Peter Zijlstra
2020-11-09 19:38   ` Segher Boessenkool
2020-11-09 19:50     ` Nick Desaulniers
2020-11-10  7:57       ` Peter Zijlstra
2020-11-10 18:42         ` Nick Desaulniers
2020-11-10 20:11           ` Peter Zijlstra
2020-11-12  0:40             ` Segher Boessenkool
2025-05-29  6:29           ` Uros Bizjak
2020-11-12  0:47         ` Segher Boessenkool
2020-11-10  7:52     ` Peter Zijlstra [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201110075236.GS2594@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=borntraeger@de.ibm.com \
    --cc=gcc@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=linux-toolchains@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mpe@ellerman.id.au \
    --cc=segher@kernel.crashing.org \
    --cc=torvalds@linux-foundation.org \
    --cc=ubizjak@gmail.com \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.