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 - thi
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
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
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
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):
Atomic
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
ate
> (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.macieira
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, with
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 is
e'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
002L && __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
ise 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
td::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 contended atomic_wait being out-of-line.
--
Thiago Macieira - thi
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 atomic_ref
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
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;
>
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
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
---
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
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
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
---
er-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
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:
*
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
2018-08
t; >> 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
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_GOLD
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.com
Software Architect - Intel Open
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, since a
compliant
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
://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 thiago.macie...@intel.com
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 at all.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
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.macieira (AT) intel.com
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 - Registration Number: 556189-6027
__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 - Intel Open
is 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 Macieira
35 matches
Mail list logo