<div dir="ltr">It seems to be.  I will also make the copy constructor =delete() to make sure this cannot happen again.<div><br></div><div>I'm still concerned that the std::atomic is unnecessary, but at that point at least it just becomes a performance problem and not a bug.</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Aug 26, 2016 at 1:00 PM Greg Clayton <<a href="mailto:gclayton@apple.com">gclayton@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So after speaking with local experts on the subject, we do indeed have a problem. Please convert all placed where we pass lldb_private::Address by value to pass by "const Address &". Anyone that is modifying the address should make a local copy and work with that.<br>
<br>
Is Address the only class that is causing problems?<br>
<br>
Greg<br>
<br>
> On Aug 26, 2016, at 10:51 AM, Zachary Turner via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br>
><br>
> I recently updated to Visual Studio 2015 Update 3, which has improved its diagnostics.  As a result of this, LLDB is uncompilable due to a slew of errors of the following nature:<br>
><br>
> D:\src\llvm\tools\lldb\include\lldb/Target/Process.h(3256): error C2719: 'default_stop_addr': formal parameter with requested alignment of 8 won't be aligned<br>
><br>
> The issue comes down to the fact that lldb::Address contains a std::atomic<uint64_t>, and is being passed by value pervasively throughout the codebase.  There is no way to guarantee that this value is 8 byte aligned.  This has always been a bug, but until now the compiler just hasn't been reporting it.<br>
><br>
> Someone correct me if I'm wrong, but I believe this is a problem on any 32-bit platform, and MSVC is just the only one erroring.<br>
><br>
> I'm not really sure what to do about this.  Passing std::atomic<uint64>'s by value seems wrong to me.<br>
><br>
> Looking at the code, I don't even know why it needs to be atomic.  It's not even being used safely.  We'll have a single function write the value and later read the value, even though it could have been used in the meantime.  Maybe what is really intended is a mutex.  Or maybe it doesn't need to be atomic in the first place.<br>
><br>
> Does anyone have a suggestion on what to do about this?  I'm currently blocked on this as I can't compile LLDB.<br>
> _______________________________________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
<br>
</blockquote></div>