On Tue, Nov 17, 2020 at 09:10:53PM +, Will Deacon wrote:
> On Tue, Nov 17, 2020 at 11:31:57AM -0800, Linus Torvalds wrote:
> > On Tue, Nov 17, 2020 at 11:25 AM Jakub Jelinek wrote:
> > >
> > > It would need to be typeof( (typeof(type)) (type) ) to not be that
> > > constrained on what kind of
Am Dienstag, den 17.11.2020, 11:31 -0800 schrieb Linus Torvalds:
> On Tue, Nov 17, 2020 at 11:25 AM Jakub Jelinek wrote:
> >
> > It would need to be typeof( (typeof(type)) (type) ) to not be that
> > constrained on what kind of expressions it accepts as arguments.
>
> Yup.
>
> > Anyway, it won'
On Tue, Nov 17, 2020 at 11:31:57AM -0800, Linus Torvalds wrote:
> On Tue, Nov 17, 2020 at 11:25 AM Jakub Jelinek wrote:
> >
> > It would need to be typeof( (typeof(type)) (type) ) to not be that
> > constrained on what kind of expressions it accepts as arguments.
>
> Yup.
>
> > Anyway, it won't
On Tue, Nov 17, 2020 at 11:13 AM Linus Torvalds
wrote:
>
> > +#define __unqual_typeof(type) typeof( (typeof(type))type )
>
> that's certainly a much nicer version than the existing pre-processor
> expansion from hell.
Oh, and sparse doesn't handle this, and doesn't remove any qualifiers
for the
On Tue, Nov 17, 2020 at 11:25 AM Jakub Jelinek wrote:
>
> It would need to be typeof( (typeof(type)) (type) ) to not be that
> constrained on what kind of expressions it accepts as arguments.
Yup.
> Anyway, it won't work with array types at least,
> int a[10];
> typeof ((typeof (a)) (a)) b;
On Tue, Nov 17, 2020 at 11:13:52AM -0800, Linus Torvalds wrote:
> > +#define __unqual_typeof(type) typeof( (typeof(type))type )
> that's certainly a much nicer version than the existing pre-processor
> expansion from hell.
It would need to be typeof( (typeof(type)) (type) ) to not be that
constr
On Mon, Nov 16, 2020 at 3:11 AM Peter Zijlstra wrote:
>
> XXX: I've only verified the below actually compiles, I've not verified
> the generated code is actually 'correct'.
Well, it was mainly the arm64 code generation for load-acquire and
store-release that wanted this - so it's really the
On Mon, Nov 16, 2020 at 12:23:17PM +, Uecker, Martin wrote:
> > > > Another way to drop qualifiers is using a cast. So you
> > > > can use typeof twice:
> > > >
> > > > typeof((typeof(_var))_var) tmp__;
> > > >
> > > > This also works for non-scalars but this is a GCC extension.
>
> (That c
Am Montag, den 16.11.2020, 12:10 +0100 schrieb Peter Zijlstra:
> ( restoring at least linux-toolcha...@vger.kernel.org, since that
> seems
> to have gone missing )
>
> On Mon, Nov 16, 2020 at 10:11:50AM +0100, Richard Biener wrote:
> > On Sun, Nov 15, 2020 at 11:53 AM Uecker, Martin
> > wrote
On Mon, Nov 16, 2020 at 12:10:56PM +0100, Peter Zijlstra wrote:
> > > Another way to drop qualifiers is using a cast. So you
> > > can use typeof twice:
> > >
> > > typeof((typeof(_var))_var) tmp__;
> > >
> > > This also works for non-scalars but this is a GCC extension.
FWIW, clang seems to supp
( restoring at least linux-toolcha...@vger.kernel.org, since that seems
to have gone missing )
On Mon, Nov 16, 2020 at 10:11:50AM +0100, Richard Biener wrote:
> On Sun, Nov 15, 2020 at 11:53 AM Uecker, Martin
> wrote:
> > > On Wed, Nov 04, 2020 at 07:31:42PM +0100, Uros Bizjak wrote:
> > > >
On Sun, Nov 15, 2020 at 11:53 AM Uecker, Martin
wrote:
>
>
> > 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
> > > varia
> 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--
> > U
On Tue, Nov 10, 2020 at 08:57:42AM +0100, Peter Zijlstra wrote:
> On Mon, Nov 09, 2020 at 11:50:15AM -0800, Nick Desaulniers wrote:
> > On Mon, Nov 9, 2020 at 11:46 AM Segher Boessenkool
> > wrote:
> > > On Mon, Nov 09, 2020 at 01:47:13PM +0100, Peter Zijlstra wrote:
> > > > C in general does not
On Tue, Nov 10, 2020 at 09:11:08PM +0100, Peter Zijlstra wrote:
> On Tue, Nov 10, 2020 at 10:42:58AM -0800, Nick Desaulniers wrote:
> > When I think of qualifiers, I think of const and volatile. I'm not
> > sure why the first post I'm cc'ed on talks about "segment" qualifiers.
> > Maybe it's in re
On Tue, Nov 10, 2020 at 10:42:58AM -0800, Nick Desaulniers wrote:
> When I think of qualifiers, I think of const and volatile. I'm not
> sure why the first post I'm cc'ed on talks about "segment" qualifiers.
> Maybe it's in reference to a variable attribute that the kernel
> defines? Looking at
On Mon, Nov 9, 2020 at 11:57 PM Peter Zijlstra wrote:
>
> Stripping const to delcare another variable is useful though. Sure C has
> sharp edges, esp. if you cast stuff, but since when did that stop anyone
> ;-)
>
> The point is, C++ has these very nice template helpers that can strip
> qualifiers
On Mon, Nov 09, 2020 at 11:50:15AM -0800, Nick Desaulniers wrote:
> On Mon, Nov 9, 2020 at 11:46 AM 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 +
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 r
On Mon, Nov 9, 2020 at 11:46 AM 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 linu
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) wer
+ 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 mention
> On Nov 5, 2020, at 4:26 AM, Uros Bizjak wrote:
>
> On Thu, Nov 5, 2020 at 1:14 PM Alexander Monakov 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;
>>>
On Thu, Nov 5, 2020 at 2:39 PM Alexander Monakov wrote:
>
> On Thu, 5 Nov 2020, Alexander Monakov via Gcc wrote:
>
> > On Thu, 5 Nov 2020, Uros Bizjak via Gcc wrote:
> >
> > > > No, this is not how LEA operates. It needs a memory input operand. The
> > > > above will report "operand type mismatch
On Thu, 5 Nov 2020, Alexander Monakov via Gcc wrote:
> On Thu, 5 Nov 2020, Uros Bizjak via Gcc wrote:
>
> > > 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 vo
On Thu, 5 Nov 2020, Uros Bizjak via Gcc wrote:
> > 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));
This is th
On Thu, Nov 5, 2020 at 1:32 PM Uros Bizjak wrote:
>
> On Thu, Nov 5, 2020 at 1:24 PM Richard Biener
> 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.
On Thu, Nov 5, 2020 at 1:24 PM Richard Biener
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
On Thu, Nov 5, 2020 at 1:14 PM Alexander Monakov 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 = (ui
On Thu, Nov 5, 2020 at 1:16 PM Alexander Monakov via Gcc
wrote:
>
>
>
> On Thu, 5 Nov 2020, Uros Bizjak wrote:
>
> > On Thu, Nov 5, 2020 at 12:38 PM Alexander Monakov
> > wrote:
> > >
> > > On Thu, 5 Nov 2020, Uros Bizjak via Gcc wrote:
> > >
> > > > > What is the usecase for stripping the addre
On Thu, 5 Nov 2020, Uros Bizjak wrote:
> On Thu, Nov 5, 2020 at 12:38 PM Alexander Monakov wrote:
> >
> > On Thu, 5 Nov 2020, Uros Bizjak via Gcc wrote:
> >
> > > > What is the usecase for stripping the address space for asm operands?
> > >
> > > Please see the end of [2], where the offset to
On Thu, Nov 5, 2020 at 12:38 PM Alexander Monakov wrote:
>
> On Thu, 5 Nov 2020, Uros Bizjak via Gcc wrote:
>
> > > What is the usecase for stripping the address space for asm operands?
> >
> > Please see the end of [2], where the offset to is passed in %rsi
> > to the call to this_cpu_cmpxchg16b
On Thu, 5 Nov 2020, Uros Bizjak via Gcc wrote:
> > What is the usecase for stripping the address space for asm operands?
>
> Please see the end of [2], where the offset to is passed in %rsi
> to the call to this_cpu_cmpxchg16b_emu. this_cpu_cmpxchg16b_emu
> implements access with PER_CPU_VAR((%r
On Thu, Nov 5, 2020 at 10:36 AM Alexander Monakov wrote:
>
> 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 ass
On Thu, Nov 5, 2020 at 10:36 AM Alexander Monakov wrote:
>
> 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 ass
On Thu, Nov 05, 2020 at 10:45:59AM +0100, Richard Biener wrote:
> Well, I think we should fix typeof to not retain the address space. It's
> probably our implementation detail of having those in TYPE_QUALS
> that exposes the issue and not standard mandated.
>
> The rvalue trick is to avoid depend
On Thu, Nov 5, 2020 at 9:56 AM Uros Bizjak wrote:
>
> On Thu, Nov 5, 2020 at 8:26 AM Richard Biener
> wrote:
> >
> > On Wed, Nov 4, 2020 at 7:33 PM Uros Bizjak via Gcc wrote:
> > >
> > > Hello!
> > >
> > > I was looking at the recent linux patch series [1] where segment
> > > qualifiers (named a
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'
On Thu, Nov 5, 2020 at 8:26 AM Richard Biener
wrote:
>
> On Wed, Nov 4, 2020 at 7:33 PM Uros Bizjak via Gcc 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 p
On Wed, Nov 4, 2020 at 7:33 PM Uros Bizjak via Gcc 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 doe
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 ty
41 matches
Mail list logo
