<html dir="ltr"><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto" style="text-align:left; direction:ltr;"><div>Am Freitag, den 06.12.2019, 13:15 +0000 schrieb Alexey Bataev:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">You described the behavior of trivilly copyable types. If we don't call the constructor/destructor, we may break something in the inner type data, if the constructor/destructor requires some additional actions.<div>We don't need default constructor, we need defaulted drfault constructor, no copy/move operators and defaulted destructor.<br><br>The runtime at first allocates memory for the mapped data (here we need to call default constructor to initialize the data),</div></blockquote><div><br></div><div>Why would we need to call the default constructor here? If the data is not mapped to / tofrom, the "value of the corresponding list item is undefined" (OpenMP 5.0, p318).</div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>then bitcopies the data from mapped data to the buffer (need to call copy operator)</div></blockquote><div><br></div><div>If the runtime does copy the data, these two steps together are equivalent to a single invocation of the copy-constructor, aren't they?</div><div><br></div><div>Jonas</div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>and when we exit we need to destroy the data in the buffer (need for the defaulted destructor).<br><div dir="ltr">Best regards,<div>Alexey Bataev</div></div><div dir="ltr"><br><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">6 дек. 2019 г., в 08:02, Jonas Hahnfeld <hahnjo@hahnjo.de> написал(а):<br><br></blockquote></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div dir="ltr">
<meta http-equiv="content-type" content="text/html; charset=utf-8"><div>For the constructors, the runtime is doing kind of an implicit trivial copy constructor by memcpy'ing. Could you explain (or hint to an explanation) why we need a default constructor, ie T::T() in my previous example?</div><div><br></div><div><a href="https://en.cppreference.com/w/cpp/language/destructor#Trivial_destructor">https://en.cppreference.com/w/cpp/language/destructor#Trivial_destructor</a></div><div>"A trivial destructor is a destructor that performs no action."</div><div>This is guaranteed for "trivially copyable" types. Do you agree that we are fine with a trivial destructor?</div><div><br></div><div>Jonas</div><div><br></div><div>Am Freitag, den 06.12.2019, 12:54 +0000 schrieb Alexey Bataev:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">Yes, we need it. Just I like said before, only fully serializable types are guaranteed to be mapped fully correctly. We don not call constructors/destructors, that's why they must be default.<br><br><div dir="ltr">Best regards,<div>Alexey Bataev</div></div><div dir="ltr"><br><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">6 дек. 2019 г., в 07:39, Jonas Hahnfeld <hahnjo@hahnjo.de> написал(а):<br><br></blockquote></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div dir="ltr">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div>I think checkTypeMappable() in lib/Sema/SemaOpenMP.cpp currently checks QualType::isTrivialType(). This implies QualType::isTriviallyCopyableType(), but it additionally also requires a default constructor and no non-trivial default constructor.</div><div>Do we actually need guarantees on the default constructors? Please note that "trivially copyable" requires a trivial destructor, so this should be fine from that perspective.</div><div><br></div><div>For example, consider attached class T which is trivially copyable (see static_assert). Clang warns because T::T() is non-trivial, but I don't see how this affects the mapping (which is eventually just memcpy'ing the int member).</div><div><br></div><div>Jonas</div><div><br></div><div>Am Freitag, den 06.12.2019, 02:48 +0000 schrieb Doerfert, Johannes via Openmp-dev:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div dir="auto" style="direction: ltr; margin: 0; padding: 0; font-family: sans-serif; font-size: 11pt; color: black; ">No error please, except if we know something will break. I'll write up a proposal with more detail tomorrow (hopefully).<br><br></div><div dir="auto" style="direction: ltr; margin: 0; padding: 0; font-family: sans-serif; font-size: 11pt; color: black; "><span id="OutlookSignature"><div dir="auto" style="direction: ltr; margin: 0; padding: 0; font-family: sans-serif; font-size: 11pt; color: black; ">--<br></div><div dir="auto" style="direction: ltr; margin: 0; padding: 0; font-family: sans-serif; font-size: 11pt; color: black; ">written from my phone</div></span><br></div><div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Alexey Bataev <Alexey.Bataev@ibm.com><br><b>Sent:</b> Thursday, December 5, 2019 8:43:50 PM<br><b>To:</b> Itaru Kitayama <itaru.kitayama@gmail.com><br><b>Cc:</b> Doerfert, Johannes <jdoerfert@anl.gov>; Guido Juckeland <g.juckeland@hzdr.de>; Jeffrey Kelling <j.kelling@hzdr.de>; Sunita Chandrasekaran <schandra@udel.edu>; openmp-dev@lists.llvm.org <openmp-dev@lists.llvm.org><br><b>Subject:</b> RE: [Openmp-dev] Clang9 warning and compiler error with atomics</font><div> </div></div><div dir="auto">The only guarantee is the trivially copyable type. If you insist, I can convert a warning into an error.<br><br><div dir="ltr">Best regards,
<div>Alexey Bataev</div></div><div dir="ltr"><br><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">5 дек. 2019 г., в 21:41, Itaru Kitayama <itaru.kitayama@gmail.com> написал(а):<br><br></blockquote></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div dir="ltr">
<div><div dir="auto">That’d be extremely helpful for C++ application developers.</div></div><div><br><div class="x_gmail_quote"><div dir="ltr" class="x_gmail_attr">On Fri, Dec 6, 2019 at 11:21 Doerfert, Johannes via Openmp-dev <<a href="mailto:openmp-dev@lists.llvm.org">openmp-dev@lists.llvm.org</a>> wrote:<br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><div dir="auto" style="direction:ltr; margin:0; padding:0; font-family:sans-serif; font-size:11pt; color:black">I think we talk past each other. Let me try to rephrase.<br></div><div dir="auto" style="direction:ltr; margin:0; padding:0; font-family:sans-serif; font-size:11pt; color:black"><br></div><div dir="auto" style="direction:ltr; margin:0; padding:0; font-family:sans-serif; font-size:11pt; color:black">Even if a type is not trivially copyable, as defined by the standard, we can determine sufficient conditions under which the mapping will happen as expected by a reasonable user. That said, we need to define these conditions. Does this make sense?<br><br></div><div dir="auto" style="direction:ltr; margin:0; padding:0; font-family:sans-serif; font-size:11pt; color:black"><span id="x_m_-8662528268726126948ms-outlook-mobile-signature"><div><br></div>--<br>written from my phone</span><br></div><hr style="display:inline-block; width:98%"><div id="x_m_-8662528268726126948divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Alexey Bataev <<a href="mailto:Alexey.Bataev@ibm.com" target="_blank">Alexey.Bataev@ibm.com</a>><br><b>Sent:</b> Thursday, December 5, 2019 7:51:02 PM<br><b>To:</b> Doerfert, Johannes <<a href="mailto:jdoerfert@anl.gov" target="_blank">jdoerfert@anl.gov</a>><br><b>Cc:</b> Jeffrey Kelling <<a href="mailto:j.kelling@hzdr.de" target="_blank">j.kelling@hzdr.de</a>>; Narayanaswamy, Ravi <<a href="mailto:ravi.narayanaswamy@intel.com" target="_blank">ravi.narayanaswamy@intel.com</a>>; Sunita Chandrasekaran <<a href="mailto:schandra@udel.edu" target="_blank">schandra@udel.edu</a>>;
<a href="mailto:openmp-dev@lists.llvm.org" target="_blank">openmp-dev@lists.llvm.org</a> <<a href="mailto:openmp-dev@lists.llvm.org" target="_blank">openmp-dev@lists.llvm.org</a>>; Guido Juckeland <<a href="mailto:g.juckeland@hzdr.de" target="_blank">g.juckeland@hzdr.de</a>><br><b>Subject:</b> RE: Clang9 warning and compiler error with atomics</font><div> </div></div><div dir="auto">"Working" has different meanings here. We don't call constructors, destructors or any copy/move operators. And we say the user about this with this warning. If the user does not need the results of these function, he can ignore the warning and
transfer data as is. It may work in some cases and in some it may not (if constructors/destructors are very complex, for example). But we don't know for sure whrn it works and when it is not.<br><br><div dir="ltr">Best regards,
<div>Alexey Bataev</div></div><div dir="ltr"><br><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">5 дек. 2019 г., в 20:39, Doerfert, Johannes <<a href="mailto:jdoerfert@anl.gov" target="_blank">jdoerfert@anl.gov</a>> написал(а):<br><br></blockquote></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div dir="ltr"> </div></blockquote></div></div><div><div dir="auto"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div dir="ltr"><div dir="auto" style="direction:ltr; margin:0; padding:0; font-family:sans-serif; font-size:11pt; color:black">My key point is: Is the mapping of the type in question"working" or not? If not, it should be an error, if it is working, no warning, only if we don't know, it should be a warning.<br><br></div><div dir="auto" style="direction:ltr; margin:0; padding:0; font-family:sans-serif; font-size:11pt; color:black"><span id="x_m_-8662528268726126948x_OutlookSignature"><div dir="auto" style="direction:ltr; margin:0; padding:0; font-family:sans-serif; font-size:11pt; color:black">--<br></div><div dir="auto" style="direction:ltr; margin:0; padding:0; font-family:sans-serif; font-size:11pt; color:black">written from my phone</div></span><br></div><hr style="display:inline-block; width:98%"><div id="x_m_-8662528268726126948x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Alexey Bataev <<a href="mailto:Alexey.Bataev@ibm.com" target="_blank">Alexey.Bataev@ibm.com</a>><br><b>Sent:</b> Thursday, December 5, 2019 7:34:50 PM<br><b>To:</b> Doerfert, Johannes <<a href="mailto:jdoerfert@anl.gov" target="_blank">jdoerfert@anl.gov</a>><br><b>Cc:</b> Jeffrey Kelling <<a href="mailto:j.kelling@hzdr.de" target="_blank">j.kelling@hzdr.de</a>>; Narayanaswamy, Ravi <<a href="mailto:ravi.narayanaswamy@intel.com" target="_blank">ravi.narayanaswamy@intel.com</a>>; Sunita Chandrasekaran <<a href="mailto:schandra@udel.edu" target="_blank">schandra@udel.edu</a>>;
<a href="mailto:openmp-dev@lists.llvm.org" target="_blank">openmp-dev@lists.llvm.org</a> <<a href="mailto:openmp-dev@lists.llvm.org" target="_blank">openmp-dev@lists.llvm.org</a>>; Guido Juckeland <<a href="mailto:g.juckeland@hzdr.de" target="_blank">g.juckeland@hzdr.de</a>><br><b>Subject:</b> RE: Clang9 warning and compiler error with atomics</font><div> </div></div><div dir="auto">1. The warning is emitted correctly, there is no bug. It just might be annoying but it warns correctly. I'll just put it under different warning group so it would be easier to disable it.
<div>2. +1 here. It would be good if you could fix this bug. NVPTX backend doesn't support atomic loads for sure and some other instructions too. <br><br><div dir="ltr">Best regards,
<div>Alexey Bataev</div></div><div dir="ltr"><br><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">5 дек. 2019 г., в 20:05, Doerfert, Johannes <<a href="mailto:jdoerfert@anl.gov" target="_blank">jdoerfert@anl.gov</a>> написал(а):<br><br></blockquote></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div dir="ltr">
<div dir="auto" style="direction:ltr; margin:0; padding:0; font-family:sans-serif; font-size:11pt; color:black">My two cents,<br><br></div><div dir="auto" style="direction:ltr; margin:0; padding:0; font-family:sans-serif; font-size:11pt; color:black">1) while the standard might not guarantee proper mapping for non trivially copyable types, we should determine under which condition we can guarantee the expected behaviour and not issue a warning expect we have to. The warning should then inform the user why
we couldn't and how it can be resolved.<br></div><div dir="auto" style="direction:ltr; margin:0; padding:0; font-family:sans-serif; font-size:11pt; color:black">Could anyone open a bug for this as well?<br><br></div><div dir="auto" style="direction:ltr; margin:0; padding:0; font-family:sans-serif; font-size:11pt; color:black">2) atomics should "work". I'll look into this with the caveat that the performance is hardware dependent. as Alexey mentioned, if the hardware doesn't provide direct support we'll need to emulate them which might be even more costly. Nevertheless, it should
work and not error out.<br><br></div><div dir="auto" style="direction:ltr; margin:0; padding:0; font-family:sans-serif; font-size:11pt; color:black">Cheers,<br></div><div dir="auto" style="direction:ltr; margin:0; padding:0; font-family:sans-serif; font-size:11pt; color:black"> Johannes<br><br></div><div dir="auto" style="direction:ltr; margin:0; padding:0; font-family:sans-serif; font-size:11pt; color:black"><span id="x_m_-8662528268726126948x_x_OutlookSignature"><div dir="auto" style="direction:ltr; margin:0; padding:0; font-family:sans-serif; font-size:11pt; color:black">--<br></div><div dir="auto" style="direction:ltr; margin:0; padding:0; font-family:sans-serif; font-size:11pt; color:black">written from my phone</div></span><br></div><hr style="display:inline-block; width:98%"><div id="x_m_-8662528268726126948x_x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Alexey Bataev <<a href="mailto:Alexey.Bataev@ibm.com" target="_blank">Alexey.Bataev@ibm.com</a>><br><b>Sent:</b> Thursday, December 5, 2019 5:30:23 PM<br><b>To:</b> Jeffrey Kelling <<a href="mailto:j.kelling@hzdr.de" target="_blank">j.kelling@hzdr.de</a>><br><b>Cc:</b> Narayanaswamy, Ravi <<a href="mailto:ravi.narayanaswamy@intel.com" target="_blank">ravi.narayanaswamy@intel.com</a>>; Sunita Chandrasekaran <<a href="mailto:schandra@udel.edu" target="_blank">schandra@udel.edu</a>>;
<a href="mailto:openmp-dev@lists.llvm.org" target="_blank">openmp-dev@lists.llvm.org</a> <<a href="mailto:openmp-dev@lists.llvm.org" target="_blank">openmp-dev@lists.llvm.org</a>>; Guido Juckeland <<a href="mailto:g.juckeland@hzdr.de" target="_blank">g.juckeland@hzdr.de</a>>;
Doerfert, Johannes <<a href="mailto:jdoerfert@anl.gov" target="_blank">jdoerfert@anl.gov</a>><br><b>Subject:</b> RE: Clang9 warning and compiler error with atomics</font><div> </div></div><div dir="auto">There is std::is_trivially_copyable trait, you can check if your types are actually trivially copyable.
<div><br></div><div>std::is_trivially_copyable<type>::value is true if type is trivially copyable, false otherwise.</div><div><br></div><div>Here is the definition of trivially copyable types <br><br></div><div><a href="https://en.cppreference.com/w/cpp/named_req/TriviallyCopyable" target="_blank">https://en.cppreference.com/w/cpp/named_req/TriviallyCopyable</a></div><div><br></div><div>Compiler relies on the standard here.</div><div><br><div dir="ltr">Best regards,
<div>Alexey Bataev</div></div><div dir="ltr"><br><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">5 дек. 2019 г., в 18:03, Jeffrey Kelling <<a href="mailto:j.kelling@hzdr.de" target="_blank">j.kelling@hzdr.de</a>> написал(а):<br><br></blockquote></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div dir="ltr"><span>Hello Alexey.</span><br><span></span><br><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><span>The warning is definitely fired only for non-trivially copyable</span><br><span>types. But for each of them.</span><br></blockquote><span>I am not completely sure what the definition of non-trivially copyable is, but
</span><br><span>I would not expect the following:</span><br><span></span><br><span>* It is giving me warning for std::tuple:</span><br><span>warning: Non-trivial type 'std::__1::tuple<unsigned int *, unsigned int *, </span><br><span>unsigned int *, unsigned long>' is mapped, only trivial types are guaranteed
</span><br><span>to be mapped correctly [-Wopenmp-target]</span><br><span></span><br><span>Tuple has a defaulted copy constructor according to the standard. However, the
</span><br><span>example above does have pointers, so it may still warrant a warning, but it
</span><br><span>would be nice if I could turn that one off separately.</span><br><span></span><br><span>* I also get a waring on another type:</span><br><span>warning: Non-trivial type 'const </span><br><span>alpaka::vec::Vec<std::__1::integral_constant<unsigned long, 1>, unsigned </span><br><span>long>' is mapped, only trivial types are guaranteed to be mapped correctly [-</span><br><span>Wopenmp-target]</span><br><span>This one also has default move and copy constructors. It only has one data </span><br><span>member:</span><br><span>TVal m_data[TDim::value == 0u ? 1u : TDim::value]; // TVal = unsigned long</span><br><span></span><br><span>While I do agree, that this type is anything bus trivial as a whole, it still
</span><br><span>should not warrant this warning.</span><br><span></span><br><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><span>What I can do is to put this warning into a</span><br><span>different warning group, like -Wopenmp-mapping or something like this.
</span><br></blockquote><span>This would help a lot already, thanks.</span><br><span></span><br><span>Best Regards,</span><br><span></span><br><span>Jeffrey</span><br><span></span><br><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><span>Best regards,</span><br><span>Alexey Bataev</span><br><br><br><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><span>5 дек. 2019 г., в 16:49, Jeffrey Kelling <<a href="mailto:j.kelling@hzdr.de" target="_blank">j.kelling@hzdr.de</a>> написал(а):</span><br><br><br><br><span>Hello Alexey.</span><br><br><br><br><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><span>1. What is the preferrable way of fixing the problem with the warning? I</span><br><span>don't think we should throw it away because it may help developers to</span><br><span>identify possible prpblems with the offloading.</span><br></blockquote><br><span>I agree, that the warning may be important, which is why it would be nice</span><br></blockquote><br><span>it</span><br><br><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><span>it would not be spammed so much. I would suggest to not show the warning</span><br></blockquote><br><span>if</span><br><br><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><span>the type is trivially copyable.</span><br><br><br><br><span>I some cases a warning might be useful if the type, even if trivially</span><br><span>copyable, has member of pointer of reference types. However, there should</span><br></blockquote><br><span>be</span><br><br><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><span>separate flag to toggle this one (at least a no- flag), because I am</span><br><span>intentionally pushing pointer to device memory into the target region</span><br></blockquote><br><span>this way</span><br><br><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><span>and thus the spam would continue. Maybe, if there is a reference member</span><br></blockquote><br><span>the</span><br><br><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><span>warning would always make sense, because the reference can maybe only</span><br></blockquote><br><span>refer to</span><br><br><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><span>something on the host.</span><br><br><br><br><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><span>2. It is known problem and</span><br><span>there is no quick way to fix it. Some of the atomic constructs are not</span><br><span>supported by the NVPTX backend. Possible solution is to use critical</span><br><span>sections or, maybe, intrinsics/builtins directly.</span><br></blockquote><br><span>This is a good thing to note, thanks.</span><br><br><br><br><span>Best Regards,</span><br><br><br><br><span>Jeffrey Kelling</span><br><br><br><br><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><span>Best regards,</span><br><span>Alexey Bataev</span><br><br><br><br><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><span>5 дек. 2019 г., в 15:27, Narayanaswamy, Ravi</span><br><span><<a href="mailto:ravi.narayanaswamy@intel.com" target="_blank">ravi.narayanaswamy@intel.com</a>> написал(а):</span><br><br><br><br><br><span>+Alexey</span><br><br><br><br><span>From: Sunita Chandrasekaran [mailto:<a href="mailto:schandra@udel.edu" target="_blank">schandra@udel.edu</a>]</span><br><span>Sent: Wednesday, December 4, 2019 7:02 PM</span><br><span>To: <a href="mailto:openmp-dev@lists.llvm.org" target="_blank">openmp-dev@lists.llvm.org</a></span><br><span>Cc: Jeffrey Kelling <<a href="mailto:j.kelling@hzdr.de" target="_blank">j.kelling@hzdr.de</a>>; Guido Juckeland</span><br><span><<a href="mailto:g.juckeland@hzdr.de" target="_blank">g.juckeland@hzdr.de</a>>; Narayanaswamy, Ravi</span><br><span><<a href="mailto:ravi.narayanaswamy@intel.com" target="_blank">ravi.narayanaswamy@intel.com</a>>; Doerfert, Johannes Rudolf</span><br><span><<a href="mailto:jdoerfert@anl.gov" target="_blank">jdoerfert@anl.gov</a>> Subject: Clang9 warning and compiler error with</span><br><span>atomics</span><br><br><br><br><span>Hello Everyone</span><br><br><br><br><span>I guess I have not posted to this alias in the near past, but I</span><br></blockquote></blockquote></blockquote><br><span>probably</span><br><br><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><span>*can* ! Guess we will find out :-)</span><br><span>(copying Ravi and Johannes just in case my mail doesn't get thru the</span><br><span>mailing list..please let me know)</span><br><br><br><br><span>Some of us are working on an application PIConGPU which is also one of</span><br></blockquote></blockquote></blockquote><br><span>the</span><br><br><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><span>8 ORNL CAAR projects for Frontier system. There are 2 issues pointed</span><br></blockquote></blockquote></blockquote><br><span>out</span><br><br><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><span>by the developer Jeffrey Kelling (copied here) while he is running</span><br></blockquote></blockquote></blockquote><br><span>Alpaka</span><br><br><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><span>tests with LLVM.</span><br><br><br><br><span>1. Clang9 is spamming the a pointless warning:</span><br><span>warning: Non-trivial type 'const</span><br><span>alpaka::vec::Vec<std::__1::integral_constant<unsigned long, 1>,</span><br></blockquote></blockquote></blockquote><br><span>unsigned</span><br><br><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><span>long>' is mapped, only trivial types are guara</span><br><span>nteed to be mapped correctly [-Wopenmp-target]</span><br><br><br><br><span>While we are aware that the warning will appear, we need to turn off</span><br><span>-werror because of this, may miss more important warnings due to the</span><br><span>spam. Jeff also does not want to turn of -Wopenmp-target, because these</span><br><span>should be the most interesting warnings. It would be nice, if this one</span><br><span>could be fixed.</span><br><br><br><br><span>2. Jeff also just encountered an internal compiler error with atomics</span><br></blockquote></blockquote></blockquote><br><span>and</span><br><br><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><span>the NVPTX backend, and created a bug report:</span><br><span><a href="https://bugs.llvm.org/show_bug.cgi?id=44219" target="_blank">https://bugs.llvm.org/show_bug.cgi?id=44219</a></span><br><br><br><br><span>Addressing these issues for CAAR is very time critical and that led me</span><br></blockquote></blockquote></blockquote><br><span>to</span><br><br><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><span>send an email to this mailing list to get some quick advice/insights</span><br></blockquote></blockquote></blockquote><br><span>into</span><br><br><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><span>both these issues.</span><br><br><br><br><span>Thank you very much for your time!!</span><br><span>Cheers</span><br><span>sunita</span><br><br><br><br><br><br><span>----------------------------------------</span><br><span>Sunita Chandrasekaran</span><br><span>Asst. Prof. Computer and Information Sciences</span><br><span>Affiliated, Center for Bioinformatics and Computational Biology</span><br><span>Affiliated, Data Science Institute</span><br><span>University of Delaware</span><br><span>430 Smith Hall, Newark, DE, USA</span><br><span>p: 302-831-2714 e: <a href="mailto:schandra@udel.edu" target="_blank">schandra@udel.edu</a></span><br><span>----------------------------------------</span><br><span>Adjunct Prof. Dept. of Computer Science</span><br><span>University of Houston, TX</span><br><span>----------------------------------------</span><br><span>CRPL</span><br><span>Research Group:</span><br><span><a href="http://crpl.cis.udel.edu/" target="_blank">http://crpl.cis.udel.edu/</a></span><br><span>t: <a href="https://twitter.com/sunitachandra29" target="_blank">https://twitter.com/sunitachandra29</a></span><br><span>w: <a href="https://www.eecis.udel.edu/~schandra/" target="_blank">https://www.eecis.udel.edu/~schandra/</a></span><br></blockquote></blockquote><br><br><br><br><span>--</span><br><span>Dr. Jeffrey Kelling</span><br><br><br><br><span>Computational Science Group (FWCC)</span><br><span>Department of Information Services and Computing (FWC)</span><br><span>Building 613, Room 260</span><br><span>Phone: +49 - 351 - 260 3680</span><br><br><br><br><span>Helmholtz-Zentrum Dresden-Rossendorf e.V.</span><br><span><a href="http://www.hzdr.de" target="_blank">http://www.hzdr.de</a></span><br><br><br><br><span>Vorstand: Prof. Dr. Dr. h. c. Roland Sauerbrey</span><br><span>Vereinsregister: VR 1693 beim Amtsgericht Dresden</span><br><span><smime.p7s></span><br></blockquote></blockquote><span></span><br><span></span><br><span>-- </span><br><span>Dr. Jeffrey Kelling</span><br><span></span><br><span>Computational Science Group (FWCC)</span><br><span>Department of Information Services and Computing (FWC)</span><br><span>Building 613, Room 260</span><br><span>Phone: +49 - 351 - 260 3680</span><br><span></span><br><span>Helmholtz-Zentrum Dresden-Rossendorf e.V.</span><br><span><a href="http://www.hzdr.de" target="_blank">http://www.hzdr.de</a></span><br><span></span><br><span>Vorstand: Prof. Dr. Dr. h. c. Roland Sauerbrey</span><br><span>Vereinsregister: VR 1693 beim Amtsgericht Dresden
<div><smime.p7s></div></span></div></blockquote></div><br></div></div></blockquote></div><br></div></div></blockquote><br></div></div>_______________________________________________<br>Openmp-dev mailing list<br><a href="mailto:Openmp-dev@lists.llvm.org" target="_blank">Openmp-dev@lists.llvm.org</a><br><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev</a><br></blockquote></div></div></div></blockquote><br></div>
<pre>_______________________________________________</pre><pre>Openmp-dev mailing list</pre><a href="mailto:Openmp-dev@lists.llvm.org"><pre>Openmp-dev@lists.llvm.org</pre></a><br><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev"><pre>https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev</pre></a><br></blockquote><div><map.cpp></div><div><signature.asc></div></div></blockquote><br>
</blockquote><div><signature.asc></div></div></blockquote></div><br>
</blockquote></body></html>