tra requested changes to this revision.
tra added a comment.
This revision now requires changes to proceed.
NVCC is not always right.
> Is there a specific use case for this, other than matching nvcc bug-for-bug?
I don't think I've seen the answer to my question above.
> However, user can turn
yaxunl requested review of this revision.
yaxunl added a comment.
We need to revive this review since we found it is very inconvenient without
this.
Also, nvcc only emits a warning for it
https://cuda.godbolt.org/z/AzrDTt
So I think maybe we even want to emit it as warning by default.
Reposi
jlebar added a comment.
> By default it is still treated as error, therefore no behavior change of
> clang.
Oh, I see, you already did what I'd suggested. :)
That's better. I think this needs to be made *much scarier* though. "Maybe
race condition" doesn't capture the danger here -- you can
jlebar requested changes to this revision.
jlebar added a comment.
This revision now requires changes to proceed.
I agree with Art. The fact that nvcc allows this is broken.
If you want a flag that makes this error a warning, that might work for me.
The flag should probably say "unsafe" or "I
tra added a comment.
This looks like one of the things we should *not* do as it affects correctness
-- non-trivial constructor may be arbitrarily complex and the per-TU flag to
enable this behavior is way too coarse, IMO.
On the other hand, I can believe that someone somewhere did write the code
yaxunl created this revision.
yaxunl added a reviewer: tra.
Herald added a project: clang.
In many cases the default constructor of a class contains initializer of data
members, which allows concise code. The class may be instantiated as
global or automatic variables in device code, which is total
