[PATCH] D54540: [ADT] Drop llvm::Optional clang-specific optmization for trivially copyable types

Tom Stellard via llvm-commits llvm-commits at lists.llvm.org
Fri Nov 30 21:05:55 PST 2018


On 11/30/2018 05:30 PM, Bob Wilson wrote:
> We need to figure out what to do about this. It breaks building Swift and I had to revert it from the swift-clang repo as a temporary workaround. Perhaps there is some way to adjust the code to avoid whatever problem GCC has with it? Otherwise, could we conditionally include the optimization for contexts where compatibility between GCC and Clang doesn’t matter? I don’t know of a good way to identify those contexts, but I suppose some kind of build configuration option could work.
> 

With all the reverts, this has been hard to follow.  Would someone be able to
submit the desired Optional implementation (even if gcc can't compile it),
so we have something to start a discussion with?

-Tom

>> On Nov 16, 2018, at 10:34 AM, John McCall via Phabricator via llvm-commits <llvm-commits at lists.llvm.org> wrote:
>>
>> rjmccall added a comment.
>>
>> Hmm.  This makes `Optional<int>` non-trivial, which is a serious semantic problem for certain uses of the type (e.g. putting it in a union); it's not just an optimization.  Obviously those were unportable because of the `#if`, but we should really fix this.  There's no way that GCC just generically miscompiles all partial specializations.
>>
>>
>> Repository:
>>  rL LLVM
>>
>> https://reviews.llvm.org/D54540
>>
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
> 



More information about the llvm-commits mailing list