<div dir="ltr">Methods like Address::SetOffset and Address::Slide seem to have data races despite m_offset being atomic.  Callers of those methods would have to guarantee that nothing else is trying to write to m_offset.  And if they're doing that, then there doesn't appear to be a need for std::atomic on that field.<div><br></div><div>BTW, I propose we move the member variables from protected to private.  As far as I can tell, there aren't any derived classes (yet), at least none that access those members.  If we need to add a mutex to the class itself, it'll be better if any future derived classes access the data through accessors.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 26, 2016 at 11:36 AM, Zachary Turner via lldb-dev <span dir="ltr"><<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">The thing is, the code is already full of data races.  I think the std::atomic is actually used incorrectly and is not even doing anything.<div><br></div><div>That said, consider darwin on 32-bit, where I believe each stack frame is 4-byte aligned.  I dont' think there's any way the compiler can guarantee that a function parameter is 8-byte aligned without allocating from the heap, which is obviously impossible for a stack variable.</div></div><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Fri, Aug 26, 2016 at 11:29 AM Greg Clayton <<a href="mailto:gclayton@apple.com" target="_blank">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"><br>
> On Aug 26, 2016, at 11:24 AM, Greg Clayton via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br>
><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\<wbr>include\lldb/Target/Process.h(<wbr>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>
> Feel free to #ifdef around the m_offset member of Address and you can have the data race and compile. This seems like a compiler bug to me. If a struct/classe by value argument has alignment requirements, then the compiler should handle this correctly IMHO. Am I wrong????<br>
<br>
Or if this isn't a compiler bug, feel free to modify anything that was passing Address by value and make it a "const Address &".</blockquote></div>
</div></div><br>______________________________<wbr>_________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@lists.llvm.org">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/<wbr>mailman/listinfo/lldb-dev</a><br>
<br></blockquote></div><br></div>