Hi,
I've adjust the testcase and now it only contains constant offset, since
with -fPIC the mov target address does not contain any symbol in the assembler.
Could you help to check the attached changes on darwin and see if they
all get passed?
(I still can not build darwin target currently)
Tha
Snapshot gcc-8-20201105 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/8-20201105/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 8 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
> 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 Tue, Nov 3, 2020 at 5:21 PM Erick Ochoa
wrote:
>
> Thanks for the review Richard I'll address what I can. I also provide
> maybe some hindsight into some of the design decisions here. I'm not
> trying to be defensive just hoping to illuminate why some decisions were
> made and how some criticis
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
20 matches
Mail list logo
