Re: [PATCH 0/3] Uncontroversial improvements to C++20 wait-related implementation

s that meant to be part of GCC 11's release? If not, what do we do about preventing the future BC break and potential heisenbugs? 1) do nothing, accept they will happen silently 2) cause non-silent BC breaks 3) disable the code for now (unless explicitly opted-in) -- Thiago Macieira - th

[PATCH 0/3] Uncontroversial improvements to C++20 wait-related implementation

h | 7 --- > libstdc++-v3/include/std/barrier| 10 +- > libstdc++-v3/include/std/latch | 4 ++-- > 3 files changed, 11 insertions(+), 10 deletions(-) ping? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering

[PATCH 2/3] std::latch: reduce internal implementation from ptrdiff_t to int

ints can be used as futex on Linux. ptrdiff_t on 64-bit Linux can't. libstdc++-v3/ChangeLog: * include/std/latch: Use int instead of ptrdiff_t --- libstdc++-v3/include/std/latch | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libstdc++-v3/include/std/latch b/libst

[PATCH 3/3] barrier: optimise by not having the hasher in a loop

Our thread's ID does not change so we don't have to get it every time and hash it every time. libstdc++-v3/ChangeLog: * include/std/barrier(arrive): move hasher one level up in the stack. --- libstdc++-v3/include/std/barrier | 10 +- 1 file changed, 5 insertions(+), 5 d

[PATCH 0/3] Uncontroversial improvements to C++20 wait-related implementation

Discussion at: https://gcc.gnu.org/pipermail/libstdc++/2021-February/052043.html This patch set includes the uncontroversial parts that improve performance but don't otherwise change ABI. Please note we still need to decide on how to deal with the future ABI break. Thiago Macieira (3): A

[PATCH 1/3] Atomic __platform_wait: accept any 32-bit type, not just int

The kernel doesn't care what we store in those 32 bits, only that they are comparable. This commit adds: * pointers and long on 32-bit architectures * unsigned * untyped enums and typed enums on int & unsigned int * float We're not using FUTEX_OP anywhere today. The kernel reserves 4 bits for

Re: [PATCH 2/5] Atomic __platform_wait: accept any 32-bit type, not just int

gt; (its defined in a really expensive way) and since we control all uses > of this constant, I don't think we need it. It's only ever used from > atomic waiting functions which are only defined for scalar types. Thanks. Will update and re-submit. -- Thiago Macieira - thiago

Re: [PATCH 1/5] std::latch: reduce internal implementation from ptrdiff_t to int

On Wednesday, 3 March 2021 06:34:26 PST Jonathan Wakely wrote: > On 26/02/21 07:59 -0800, Thiago Macieira via Libstdc++ wrote: > >ints can be used as futex on Linux. ptrdiff_t on 64-bit Linux can't. > > Yes, we should do this for GCC 11. Want me to re-submit this one alone,

Re: [PATCH 4/5] barrier: use int instead of unsigned char for the phase state

On Monday, 1 March 2021 14:31:09 PST Ville Voutilainen wrote: > On Tue, 2 Mar 2021 at 00:21, Thiago Macieira wrote: > > But the code I posted, if people are careful to use write like I did, > > would > > allow us to have the experimental "we're not sure this

Re: [PATCH 4/5] barrier: use int instead of unsigned char for the phase state

us to have the experimental "we're not sure this is right" implementation of atomic waits, latches, barriers and semaphores right now. It would simply require that we decrement the macros by 1 in the libstdc++ headers. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering

Re: [PATCH 4/5] barrier: use int instead of unsigned char for the phase state

d stability. That would make my check: #if __cplusplus >= 202002L && __has_include() # include #endif #if __cpp_lib_latch < 201907L # error "Please upgrade your Standard Library" #endif -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering

Re: [PATCH 4/5] barrier: use int instead of unsigned char for the phase state

ibutors realise they've made a mistake. I still don't like (b) because it pushes the problem to the wrong people: the packagers. But it's far better than (c). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering

Re: [PATCH 4/5] barrier: use int instead of unsigned char for the phase state

d to be weighed against the increased memory use for std::barrier, which means it's not a directly- objective conclusion. And given we *may* get 8-bit futexes, it might be worth keeping them this way and just tell people with large contentions to upgrade. That of course rests on the co

Re: [PATCH 4/5] barrier: use int instead of unsigned char for the phase state

On Sunday, 28 February 2021 07:05:47 PST Hans-Peter Nilsson wrote: > On Fri, 26 Feb 2021, Thiago Macieira via Gcc-patches wrote: > > ints can be used in futexes. chars can't. > > Shouldn't that be an atomic type instead of a bare int then? There are a couple of

Re: [PATCH 1/5] std::latch: reduce internal implementation from ptrdiff_t to int

On Friday, 26 February 2021 11:31:00 PST Andreas Schwab wrote: > On Feb 26 2021, Thiago Macieira wrote: > > On Friday, 26 February 2021 10:14:42 PST Andreas Schwab wrote: > >> On Feb 26 2021, Thiago Macieira via Gcc-patches wrote: > >> > -alignas(__aligno

Re: [PATCH 1/5] std::latch: reduce internal implementation from ptrdiff_t to int

On Friday, 26 February 2021 10:14:42 PST Andreas Schwab wrote: > On Feb 26 2021, Thiago Macieira via Gcc-patches wrote: > > @@ -85,7 +85,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION > > } > > > > private: > > -alignas(__alignof__(ptrdiff_t)) ptrdiff_t _M_a; >

[PATCH 5/5] barrier: optimise by not having the hasher in a loop

Our thread's ID does not change so we don't have to get it every time and hash it every time. --- libstdc++-v3/include/std/barrier | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/libstdc++-v3/include/std/barrier b/libstdc++-v3/include/std/barrier index ae058bd3dc3..e

[PATCH 4/5] barrier: use int instead of unsigned char for the phase state

ints can be used in futexes. chars can't. --- libstdc++-v3/include/std/barrier | 21 - 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/libstdc++-v3/include/std/barrier b/libstdc++-v3/include/std/barrier index e09212dfcb9..ae058bd3dc3 100644 --- a/libstdc++-v3/inc

[PATCH 3/5] std::__atomic_wait: don't use __detail::__waiter with futex

That violates "don't pay for what you don't need" rule of C++. Users of std::atomic::wait will often have some bit in their atomic indicate whether the value is contended or not, so we don't need libstdc++ to do double book-keeping for us. --- libstdc++-v3/include/bits/atomic_wait.h | 22 +

[PATCH 2/5] Atomic __platform_wait: accept any 32-bit type, not just int

The kernel doesn't care what we store in those 32 bits, only that they are comparable. This commit adds: * pointers and long on 32-bit architectures * unsigned * untyped enums and typed enums on int & unsigned int * float We're not using FUTEX_OP anywhere today. The kernel reserves 4 bits for

[PATCH 1/5] std::latch: reduce internal implementation from ptrdiff_t to int

ints can be used as futex on Linux. ptrdiff_t on 64-bit Linux can't. --- libstdc++-v3/include/std/latch | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libstdc++-v3/include/std/latch b/libstdc++-v3/include/std/latch index ef8c301e5e9..156aea5c5e5 100644 --- a/libstdc++-v3/i

Re: [PATCH] [x86] Add detection of Icelake Client and Server

m/llvm-mirror/compiler-rt/commit/ 787bbab3e844b25bd3f8f282c6d3c8b3ad892fb4 https://github.com/llvm-mirror/compiler-rt/commit/ 7a65a376f3ae2d770797eb87b7556a3689a6177a -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products

[PATCH] [x86] Add detection of Icelake Client and Server

gcc/ChangeLog: * config/i386/driver-i386.c (host_detect_local_cpu): Handle icelake-client and icelake-server. * testsuite/gcc.target/i386/builtin_target.c (check_intel_cpu_model): Verify icelakes are detected correctly. libgcc/ChangeLog: * config/i386/cp

[PATCH] x86: (Reapply) Move AESNI generation to Skylake and Goldmont

all SKUs have AES instructions are Skylake and Goldmont. I can't find any Skylake, Kabylake, Kabylake-R or Cannon Lake currently listed at https://ark.intel.com that says "Intel® AES New Instructions" "No". [1] https://en.wikipedia.org/wiki/AES_instruction_set 20

Re: [PATCH 1/1] Move AESNI generation to Skylake and Goldmont

>> PTA_AES | PTA_SHA | PTA_XSAVE>> > >> | PTA_RDSEED | PTA_XSAVEC | PTA_XSAVES | PTA_CLFLUSHOPT | > >> | PTA_XSAVEOPT > >> | PTA_FSGSBASE; > >> > >>const wide_int_bitmask PTA_GOLDMONT_PLUS = PTA_GOLDMONT | PTA_RDPID > >> > >> -- > >> 2.18.0 > > This is what I checked in. > > Thanks. Hello H.J., Uros, Martin Looks like Martin's change in r264052, which moved the code from i386.c to i386.h ended up accidentally reverting my change. Do you want me to re-submit with an update or will one of you simply re-apply? For reference, this change was applied to Clang in https://reviews.llvm.org/ rC341862 and LLVM in https://reviews.llvm.org/rL341862. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products

[PATCH 1/1] Move AESNI generation to Skylake and Goldmont

-R or Cannon Lake currently listed at https://ark.intel.com that says "Intel® AES New Instructions" "No". [1] https://en.wikipedia.org/wiki/AES_instruction_set --- gcc/ 2018-08-27 Thiago Macieira config/i386/i386.c: Update PTA_WESTMERE, PTA_SKYLAKE and PTA

Re: feature-testing macros for 4.9

t (although I'd be OK with the > trait going on the branch too). I'd also appreciate that the core language macros be defined too in 4.9. The patch I had submitted was based on 4.9 and tried to be the least intrusive as possible. -- Thiago Macieira - thiago.macieira (AT) intel.c

Re: [PATCH C++] - SD-6 Implementation

don't care who does this, as long as it gets done. Though I would appreciate if the macros were added to the 4.9 branch, as the C++11 and 14 features are already there. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center

Re: [PATCH, libcpp] SD-6 feature macros

On Monday 18 August 2014 14:32:04 Thiago Macieira wrote: > Hello > > The SD-6 [1] document keeps a list of built-in #defines that allow > application and library writers know when certain language and library > features have been implemented by the compiler. They are optional, sinc

[PATCH, libcpp] SD-6 feature macros

and http://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center >From 5cb90354d18c4edc1dcc11cf3674542409597863 Mon Sep 17 00:00:00 2001 From: Thiago Macieira Date: Mon, 1

Re: Add flag to optionally ignore ELF interposition

cause trouble in some places. The most common one for variables is copy relocation, whereas for functions it's the official function pointer address (will resolve to the PLT in the main executable). Large projects would really appreciate being able to declare some symbols not interposable

Re: [PATCH, libstdc++] Improve slightly __cxa_guard_acquire

On quinta-feira, 6 de setembro de 2012 13.33.11, Benjamin De Kosnik wrote: > Here's the patch as applied to trunk in rev. 191042. I'll apply it to > 4.7 this weekend as long as nobody yelps. Thanks. The change to ACQUIRE is also a bugfix. -- Thiago Macieira - thiago.macieir

[PATCH, libstdc++] Improve slightly __cxa_guard_acquire

noted in the previous patch I've just sent. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden 2012-08-30 Thiago Mac

[PATCH, libstdc++] Use acquire semantics in case of CAS failure

quire __cxa_guard_acquire CAS(0 -> 256) success __cxa_guard_release store.rel(1) CAS(0 ->256) fails At this point, we must synchronise with the store-release from thread A. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect -

[PATCH, libstdc++] Fix PR54172

en if both CAS fail in given thread: the first because the other thread started the initialisation and the second because the initialisation succeeded. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registrati