On Thu, Oct 13, 2022 at 11:14 PM Vineet Gupta wrote:
>
>
>
> On 10/13/22 13:30, Uros Bizjak wrote:
>
> OTOH, for x86 (same default toggles) there's no barriers at all.
>
> _Z10bar_seqcstiPi:
> endbr64
> movlg(%rip), %eax
> movl%eax, (%rsi)
> movl
On Thu, Oct 13, 2022 at 9:31 PM Vineet Gupta wrote:
>
> Hi,
>
> I have a testcase (from real workloads) involving C++ atomics and trying
> to understand the codegen (gcc 12) for RVWMO and x86.
> It does mix atomics with non-atomics so not obvious what the behavior is
> intended to be hence some ex
On Wed, Jun 16, 2021 at 6:08 PM Liu Hao wrote:
>
> 在 2021-06-16 23:22, Jonathan Wakely via Gcc 写道:
> >> Is there someone who an dig into the commit below
> >> and try to find out how the author field was incorrectly set?
> >
> > That gets set when the local commit is done, before pushing it to the
The build currently fails to build for me on x86_64 in fixincludes:
/home/uros/gcc-build/./gcc/xgcc -B/home/uros/gcc-build/./gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/
-B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem
/usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-
Sorry for spamming gcc-patches@ ML, this message should go to gcc@.
-- Forwarded message -
From: Uros Bizjak
Date: Tue, Jan 5, 2021 at 3:04 PM
Subject: git commit hook does not record my patches to PRs
To: gcc-patc...@gcc.gnu.org
Cc: Martin Liska
Hello!
For some reason git co
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
> > >
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 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 pas
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
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
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
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
On Sun, Nov 1, 2020 at 2:04 PM Iain Sandoe wrote:
>
> Hi Uros,
>
> I was looking into the test fails for the new keylocker-* testcases.
>
> Many are because of missing “_” (which seems to happen more often than
> not). These I can fix trivially.
>
> But some are because we have:
>
> name+constant
I would like to inform GCC community, that I decided to step down from
maintaining x86 vector ISA part. x86 vector ISA has its own
non-responsive maintainer, but I have filled the maintainers role
nevertheless, until gcc-10 was released.
Unfortunately, maintaining the whole x86 target has been too
On Thu, May 7, 2020 at 8:16 AM Richard Biener
wrote:
>
> On May 6, 2020 11:15:08 PM GMT+02:00, Uros Bizjak via Gcc
> wrote:
> >Hello!
> >
> >I wonder, if the build process really needs to build all multilibs in
> >stage-1 bootstrap build. IIRC, stage-1 uses sy
Hello!
I wonder, if the build process really needs to build all multilibs in
stage-1 bootstrap build. IIRC, stage-1 uses system compiler to build
stage-1 gcc, so there is no need for multilibs, apart from library
that will be used by stage-1 gcc during compilation of stage-2
compiler.
Uros.
Hello!
> Over at RTEMS, we have had a report that this very old code has quit
> compiling:
>
> #ifdef __SSE__
> #define _CPU_Context_restore_fp(fp_context_pp) \
> do { \
>__asm__ __volatile__( \
> "fldcw %0"
$ git clone https://gcc.gnu.org/git/gcc.git
Cloning into 'gcc'...
fatal: repository 'https://gcc.gnu.org/git/gcc.git/' not found
Uros.
20 matches
Mail list logo
