Depends on http://reviews.llvm.org/D18875
This makes the C11 / C++11 *ABI* atomic ordering accessible from LLVM, as discussed in http://reviews.llvm.org/D18200#inline-151433
Paths
| Differential D18876
NFC: unify clang / LLVM atomic ordering ClosedPublic Authored by jfb on Apr 7 2016, 3:47 PM.
Details Summary Depends on http://reviews.llvm.org/D18875 This makes the C11 / C++11 *ABI* atomic ordering accessible from LLVM, as discussed in http://reviews.llvm.org/D18200#inline-151433
Diff Detail
Event Timelinejfb updated this object. Comment Actions The large amount of casting to/from integers for AtomicOrderingCABI makes me think that it probably ought not actually be converted to an enum class after all. jfb edited edge metadata. Comment Actions
Comment Actions
Untrusted user input with enums is a problem: you have to range-check before casting the int to the enum, with or without enum class, otherwise out-of-range is UB. I like it being explicit, but yeah what I had was wordy so I factored out the check. Casting *out* of the enum to generate constants is also wordy, but I think that's also fine. We could add a version of ConstantInt which takes in is_integral_or_enum but that seems like a lot of work for little typing? I'm happy to do that if you think it's worthwhile. Comment Actions
Well, my suggestion had been to just leave it as a non-enum-class, like it was before -- with no casts to or from the enum type. I think the code as it was before was actually safe, too, wasn't it? I'm just not really sure using strong enums for the CABI type is really buying much, since the basically only point of the C ABI kind is to use it as an integer. Essentially every uses of it will be converting to/from integers, won't it? I don't really feel strongly though, so if you want to go ahead, I'm okay with that. Comment Actions
Yup the previous code was correct because it didn't create an enum from an untrusted int and then use it, it always carried the int around and relied on the known-good enum to convert to int when needed.
Yeah maybe it's a personal preference, but IMO the explicitness makes it harder to mess up :-) Closed by commit rL266574: NFC: unify clang / LLVM atomic ordering (authored by jfb). · Explain WhyApr 17 2016, 2:06 PM This revision was automatically updated to reflect the committed changes.
Revision Contents
Diff 54012 cfe/trunk/include/clang/AST/Expr.h
cfe/trunk/lib/CodeGen/CGAtomic.cpp
cfe/trunk/lib/Sema/SemaChecking.cpp
|