gpderetta

There is really no such a thing as cacheline locking per-se. As far as I understand, the coherence protocol guarantees that the cpu can hold a cacheline in the exclusive state for a certain set amount of cycles, which is enough to write the top element of the store buffer into it. Making sure that the two cachelines are available at the same time would add either significant complexity to the coherence protocol, which is already one of the most complex bits of the system and very hard to validate, or force a potentially unbounded retry/backoff loop with no guaranteed forward progress.

You don't want them. Except for bug-compatibility with old broken software which is something that Intel (and MS) care a lot about.

If you mean split-lock detection, it is because split locks are a massive DoS vulnerability on high core count CPUs.

What are A-10s doing there? There isn't yet any ground operation, right?

Agree on both counts. I use debian unstable and is usually 50/50 on whether the machine will reboot on a working display after a kernel upgrade. Very easy to fix if you have a bit of knowledge, but certainly not ready for the general public.

I don't have a laptop with an nvidia card, but I often suspend the linux gaming machine on my living room, and sometimes it doesn't come back from sleep, while my steam deck never failed to.

Partial specialization specifically. Match some patterns and covert it to something else. For example:

  struct F { double x; };
  enum Op { Add, Mul };
  auto eval(F x) { return x.x; }
  template<class L, class R, Op op> struct Expr;
  template<class L, class R> struct Expr<L,R,Add>{  L l; R r; 
    friend auto eval(Expr self) { return eval(self.l) + eval(self.r); } };
  template<class L, class R> struct Expr<L,R,Mul>{  L l; R r; 
    friend auto eval(Expr self) { return eval(self.l) * eval(self.r); } };
  template<class L, class R, class R2> struct Expr<Expr<L, R, Mul>, R2, Add>{   Expr<L,R, Mul> l; R2 r; 
    friend auto eval(Expr self) { return fma(eval(self.l.l), eval(self.l.r), eval(self.r));}};
  template<class L, class R>
  auto operator +(L l, R r) { return Expr<L, R, Add>{l, r}; } 
  template<class L, class R>
  auto operator *(L l, R r) { return Expr<L, R, Mul>{l, r}; } 

  double optimized(F x, F y, F z) { return eval(x * y + z); }
  double non_optimized(F x, F y, F z) { return eval(x + y * z); }

Optimized always generates a call to fma, non-optimized does not. Use -O1 to see the difference (will inline trivial functions, but will not do other optimizations). -O0 also generates the fma, but it is lost in the noise.

The magic happens by specifically matching the pattern Expr<Expr<L, R, Mul>, R2, Add>; try to add a rule to optimize x+y*z as well.

arm64 added a load acquire instruction which I think it is fast enough on actual hardware that might not be worth bothering with consume. If it isn't, then load-relaxed plus atomic_signal_fence might be your best bet. Good luck!

Expression templates do AST manipulation of expressions at compile time. Let's say you have a complex matrix expression that naively maps to multiple BLAS operations but can be reduced to a single BLAS call. With expression templates you can translate one to the other, this is a static manipulation that does not depend on compiler level. What does depend on the compiler is whether the incidental trivial function calls to operators gets optimized away or not. But, especially with large matrices, the BLAS call will dominate anyway, so the optimization level shouldn't matter.

Of course in many cases the optimization level does matter: if you are optimizing small vector operators to simd inlining will still be important.

3-days special operation.

IMHO incompetent malice is as much likely.

re 3, clang has [[trivial_abi]] (and I believe GCC is also implementing it. But it won't be applied to standard types by default, because of course is ABI breaking. You'll have to derive your own.

use templates.

Interesting, apparently it did scoreboarding like the CDC6600 and allowed multiple memory loads in flight, but I can't find a definite statement on whether it did renaming (I.e. writes to the same registers stalled). It might not be OoO as per modern definition, but is also not a fully on-order design.

Was i960 OoO?

That's happens often in parliamentary proceedings: when the other party succeeds in unrecognizably amending the law, the party proposing it will vote against.

Specifically for the European Parliament, this is also why, while it is true it doesn't have the power of legislative initiative, given the ability to amend at will any "law", in practice it doesn't make much of a difference.

> We do? What did you think the European Parliament elections every four years were for?

Probably it is not taught as part of the curriculum in Russia.

People directly elects MEPs. And the Parliament literally right now just put a check on the Council.

Many EU nations are not presidential, and personally I prefer parliamentary republics than presidential ones.

That should completely change the regulation from mass surveillance to targeted wiretapping with a warrant.

Gorgoroth sounds about right.

As an EU citizen, I'm happy that the parliament has once again rejected the proposal, which at least gives credence to the notion that it not just there to rubber-stamp what the commission decides.

But the price of freedom is indeed eternal vigilance.

Pentium were the first superscalar x86 from intel, but were still in-order. Pentium-Pro (a completely different microarchitecture) was the first OoO intel x86 microarchitecture.

> https://cpp.godbolt.org/z/EYnWET8sT

I'm afraid that just C++ being C++ and you are deep into UB; you can't really modify a constexpr value at runtime, and if you cast away its constness with what is effectively a const cast you are on your own. This will print "0 3" which is obviously nonsense:

    constexpr int x = 3;
    ((int&)x)  = 0;
    char y[x];
    std::print("{}, {}",x, sizeof(y));    

The output might change according to the compiler and optimization level.

You can also move the problematic sequence into a constexpr function and invoke it in a constexpr context: the compiler will reject the cast now.

Enum constants can't become lvalues, so the following also won't compile:

    enum : int  { x = 3};
    ((int&)x)  = 0;

So I guess that's closer to the rust meaning of constant.

FWIW, notoriously you could modify numeric literals in early Fortrans and get into similar nonsense UB.

edit: in the end[1] it seems that you take exception with constexpr not being prvalues in C++. I guess it was found more convenient for them to have an address [1]. That doesn't make them less constant.

[1] or at least I think you do, it is not clear to me what you have been trying to claim in this discussion.

[2] C++ will materialize prvalues into temporaries when their address is needed (and give them an unique address), I guess it was thought to be wasteful for large constexpr objects, and avoids the rust pitfall you mentioned.

Yes I know, GCC has a long standing bug open on the issue :(.

Even in 2026, wars are won by the side that can shoots more bullets (or artillery rounds, or rockets, or missiles, or drones). They better be cheap.

Aside from the fact that the signal mask is still relevant in 2026 and even for multithreaded programs, that doesn't have anything to do with the fact that POSIX requires swapcontext to preserve it.

> mustn't catch (...)

You could use the same trick used by glibc to implement unstoppable exceptions for POSIX cancellation: the exception rethrows itself from its destructor.

GCC still uses sj/lj by default on some targets to implement exceptions.

A stackful coroutine implementation has to save exactly the same registers that a stackless one has to: the live ones at the suspension point.

A pure library implementation that uses on normal function call semantics obviously needs to conservatively save at least all callee-save registers, but that's not the only possible implementation. An implementation with compiler help should be able to do significantly better.

Ideally the compiler would provide a built-in, but even, for example, an implementation using GCC inline ASM with proper clobbers can do significantly better.

A proposal to add stackfull coroutines has been around forever and gets updated at every single mailing. Unfortunately the authors don't really have backing from any major company.

Unfortunately swap context requires saving and restoring the signal mask, which, at least on Linux, requires a syscall so it is going to be at least a hundred times slower than an hand rolled implementation.

Also, although not likely to be removed anytime soon from existing systems, POSIX has declared the context API obsolescent a while ago (it might actually no longer be part of the standard).

setjmp + longjump + sigaltstack is indeed the old trick.