<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 7, 2015 at 4:55 AM, Andrey Bokhanko <span dir="ltr"><<a href="mailto:andreybokhanko@gmail.com" target="_blank">andreybokhanko@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">All,<br>
<br>
Now, with OpenMP 3.1 support completed<br>
(<a href="http://lists.cs.uiuc.edu/pipermail/cfe-dev/2015-May/042845.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-dev/2015-May/042845.html</a>) we<br>
(Intel) plan to go on with implementing 4.0 support. Others plan to<br>
contribute as well -- AFAIK, at least IBM has specific plans and some<br>
code already implemented.<br>
<br>
However, there is no chance for us to have OpenMP 4.0 completed in<br>
time for next release. And in general, it is next to impossible to<br>
sync state of the next OpenMP standard support with be-annual releases<br>
-- invariably we will have something only partially implemented (with<br>
some pragmas working in full, some analyzed (with errors reported) but<br>
no actual LLVM IR generated, some not supported at all) at any given<br>
release time.<br>
<br>
We can deal with this in two ways:<br>
1) Enable all new developments by default, just document in release<br>
notes that support of OpenMP x.x version is guaranteed, but everything<br>
else is "experimental".<br></blockquote><div><br></div><div>This makes a lot of sense to me. Maybe we could just have a piece of user-level documentation docs/OpenMPSupport.rst which lists the current support level for different things (granularity doesn't need to be openmp versions, e.g. simd might be an individual thing). These will naturally get bundled into each release's documentation and will indicate the current level of support for that release.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
2) Enable only completed standard (3.1 at the moment) by default, and<br>
let users enable non-completed support with an option. Say,<br>
-std-openmp=n.<br></blockquote><div><br></div><div>It doesn't really make sense to add a user-visible flag to control something that is just an implementation/development detail (how far along we are with each version of the standard). In particular, having a -std-openmp=n flag implies having a default for that flag; changing defaults for flags that have user-visible effects is nasty. It might make sense to add a -std-openmp=n flag in the case where different versions are conflicting in some (usually small, but definitely conflicting) way, the way we do for -std=.</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Personally, I believe option 2) is much more convenient for end users.<br>
<br>
Opinions? (Both on what is preferable and option name.)<br>
<br>
Yours,<br>
Andrey Bokhanko<br>
==============<br>
Software Engineer<br>
Intel Compiler Team<br>
Intel<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</blockquote></div><br></div></div>