- User Since
- Jan 27 2014, 9:36 AM (322 w, 1 d)
I'm not sure this is a good idea at all. We want to keep the codepath as simple as possible to avoid introducing bugs. If a codebase sees a crash then it's easier to bisect one function at a time than doing something like this. I'd much rather see bisection using pragma to apply the uninitialized attribute to multiple declarations.
Fri, Mar 27
What's the verdict then?
Mon, Mar 23
The test files I added checked initialization had stores to each padding location, I think that's what would be needed here as well.
Fri, Mar 20
Oh good catch.
I've provided a large amount of feedback on prior iterations of this, and would like to see it addressed.
Maybe you should test nullptr as well, given that it's all padding?
Fri, Mar 13
Thu, Mar 12
Mon, Mar 9
Fri, Mar 6
Can you add a few tests for this specifically, both with identical subsequent bitcasts as well as with mixed ones?
Thu, Mar 5
Odd, the previous update only had the second commit. I've squashed all 3 commits now, so it's all here :)
Wed, Mar 4
Add i64/double test, as well as ptr/int
Tue, Mar 3
Please add tests for volatile loads.
Doing fork will still share an output file, right? Doe we currently end up interleaving content from both forks, or does one of them overwrite the other entirely?
I understand that crashing is undesirable, but wrong data isn't really any better.
Mon, Mar 2
Feb 28 2020
I meant compare and exchange, as well as RMW.
Feb 27 2020
Feb 26 2020
Actually: how are your locks implemented to support atomic? You disable interrupts? I think you want to contribute a version of atomic which does this, instead of saying "nothing is lock free, use locks" and then doing all the magic in the locks.
Please add extensive tests, this will absolutely break in the future without them.
Feb 20 2020
Feb 18 2020
Jan 31 2020
Jan 30 2020
I'm happy with this change since it's opt-in. Thanks!
Jan 27 2020
Jan 20 2020
Jan 17 2020
Jan 16 2020
Jan 14 2020
Jan 13 2020
This changes the expression to a constant expression as well, right? You should point this out in the commit message.
Jan 8 2020
@vitalybuka could we move this patch forward?
Jan 7 2020
- Address feedback
Jan 5 2020
Jan 3 2020
OK that helps a bit. I still don't understand though: why do you only need to protect flush and nothing else? You're protecting specific variables from being accesses concurrently only though flush, and not through the other paths that access those variables. Are these variables never accessed concurrently from these other functions?
Dec 19 2019
This generally seems fine. Does it work on most backends? I want to make sure it doesn't fail in backends :)
Dec 12 2019
Dec 9 2019
When you say "when the process is forked in different threads" you mean threads, not fork, right? Because this won't fix any issues you're seeing with fork.
Dec 6 2019
You should upload patches with context :)
Dec 5 2019
Nov 16 2019
Nov 15 2019
Nov 13 2019
Nov 8 2019
Minor comments, but otherwise LGTM.
Oct 21 2019
Oct 17 2019
More of an FYI, @jordan_rose might be interested in this.
Oct 16 2019
Oct 14 2019
This is pretty brittle... but 🤷♂️
Sep 27 2019
The entire point of this feature is to add guardrails to the language. What do people expect in the real world? Is there a cost to meeting these expectations? If we put the pattern (0x00 or 0xaa) in the technically undef space, what comes out?
Separately, does this do floating-point add / sub properly? We added them too C++20.
Sep 13 2019
Sep 12 2019
Sounds like this is ready to land again! Thanks for fixing everything.
Sep 10 2019
Sep 6 2019
Sep 5 2019
- Address arsenm's comments
Sep 4 2019
Sep 3 2019
Sorry for the delayed response, I was on vacation. Thanks for tackling it!
Sep 1 2019
I refer you to http://wg21.link/p0883
I don’t think this diagnostic should be added to clang until p0883 is fully implemented, even just for C. Otherwise we leave users with no portable way to do the right thing without diagnostic.
Aug 30 2019
Is atomic initialization now correct in all modes (including C++) without this macro? I don’t think we should diagnose until such a time because some code uses to macro to be portably correct. IIRC we only ended up fixing C++ in 20 with Nico’s paper (after Olivier and I failed repeatedly to do so.