Email or username:

Password:

Forgot your password?
Top-level
jubilee

@thephd @fasterthanlime
I'm having fun lately discussing things that C and C++ and LLVM never even fucking tried to handle in a consistent way but we're probably going to have to because we don't want to just gloss over things that matter in, say

proofs of soundness of concurrent operations?

the C++ memory model is effectively incomplete when held up against things programmers actually write.

5 comments
Dani (:cxx: modules addict)

@jubilee @thephd @fasterthanlime For dumb people like me: what do you mean with "incomplete memory model"? Mind to expand on that?

jubilee

@DanielaKEngert @thephd @fasterthanlime there are C/C++ programs that you can write today that have no coherently specified behavior if they involve concurrency. and technically it doesn't matter to the languages... because it only matters due to a "vendor extension".

a very old vendor extension that is used pervasively in high-performance code and effectively either makes the model incoherent when used OR means LLVM is miscompiling vast swathes of code and probably so is every other C compiler for x86.

Dani (:cxx: modules addict)

@jubilee @thephd @fasterthanlime Thanks.
So you're talking about " no coherently specified behavior" and potentially "miscompiling vast swathes of code". I still can't see what exactly you mean, what is missing, how this should be fixed, and how the fix fits into a (hopefully improved) memory model. And why does this affect only x86?
There must be a reason why a vendor extension is just that and not the standard.

Noratrieb

@jubilee @thephd @fasterthanlime even after the C++ memory model was _released_, people didn't realize that nontemporal stores are problematic because they didn't see them on their threads yet

jubilee

@nilstrieb @thephd @fasterthanlime yeah also the CPU had fewer actual write-combining buffers it could be retiring simultaneously.

but the CPUs have gotten more powerful at that sooooooooooo

Go Up