[cfe-dev] OpenMP support in CLANG: A proposal

Mahesha HS mahesha.llvm at gmail.com
Wed Nov 7 19:20:23 PST 2012


Sometimes, the *dry* definitions of standard (I do not hesitate to use
the word *dry* here) makes the implementation job very messy. And, I
am sure, it is true in all standards including C/C++ standard.

GCC ( g++ ) happily reports *un-declared* error for the variable VarA
when I do not pass -fopenmp option, and abort the compilation. Yes,
OpenMP spirit is clearly broken here.  Though, I did not test the
other compilers, I guess that they follow GCC for whatever the
reasons.

And, now, if Clang starts fighting against these clearly violated
rules, it is very probable that users will start their voice against
it.


--
mahesha


On Wed, Nov 7, 2012 at 10:46 PM, Ronan Keryell <Ronan.Keryell at silkan.com> wrote:
>>>>>> On Wed, 07 Nov 2012 17:02:23 +0100, Olaf Krzikalla <Olaf.Krzikalla at tu-dresden.de> said:
>
>     Olaf> Am 07.11.2012 16:00, schrieb Mahesha HS:
>     >> Regarding your question about *scope*, I meant following
>     >> example. In OpenMP annotated C++ source, following code snippet
>     >> is valid. In this particular example, I meant about handling the
>     >> scope of variable "VarA" .
>     >>
>> =======================================
>> #pragma omp parallel if (int VarA = 2)
>> {
>>     // parallel region
>> }
>>
>> VarA = 3;
>>
>> #pragma omp parallel if (VarA = 2)
>> {
>>     // parallel region
>> }
>> ========================================
>
>     Olaf> This is not backed up by the OpenMP standard. The Grammar
>     Olaf> mentions only
>     Olaf> if (expression)
>
>     Olaf> And the C++ standard has its own grammar rules for expressions
>     Olaf> in conditions in order to make declarations possible.  Of
>     Olaf> course if the above extension is consensus among all other
>     Olaf> compilers then we have to adopt to it. However I doubt it. It
>     Olaf> begs for trouble if you e.g. compile with OpenMP
>     Olaf> disabled. Thus, if this is just an gcc extension I'd just
>     Olaf> leave it out.
>
> I was puzzled by this too and I quickly browse again the OpenMP 3.1
> standard.
>
> I think we should get back to the "OpenMP spirit", but of course it is
> very subjective and I had some passionate debates on this (hi Antoniu
> Pop! :-) ).
>
> For me, the first example violates the property that if a compiler
> ignores the #pragma omp, the program should remain a syntax-correct
> program here. If we have an example where VarA is not defined before but
> used inside the parallel block, it would not even compile.
>
> The second example is that we have a side effect on VarA = 2.
> This makes me uncomfortable since I try usually to write OpenMP programs
> with the same semantics as the sequential program resulting of ignoring
> the #pragma. It is where we can argument on what is the "OpenMP spirit",
> since I do not remember having seen this stated as an axiom in the norm.
>
> The only thing I can relate to it in the "OpenMP Application Program
> Interface Version 3.1 July 2011" norm:
>
> p. 35: Restrictions
> lines 24-25:
>
>     A program must not depend on any ordering of the evaluations of the
>     clauses of the parallel directive, or on any side effects of the
>     evaluations of the clauses.
>
> p. 36: 2.4.1 Determining the Number of Threads for a parallel Region
> lines 16-19:
>
>     The if clause expression and the num_threads clause expression are
>     evaluated in the context outside of the parallel construct, and no
>     ordering of those evaluations is specified. It is also unspecified
>     whether, in what order, or how many times any side-effects of the
>     evaluation of the num_threads or if clause expressions occur.
>
> So these not preclude the use of side effect (well, I had not imagined
> to be able to put side effects here. Thank you for this Halloween
> suggestion :-) ). I just keep thinking side effects in the OpenMP pragma
> is against the OpenMP spirit and depends too much on implementation
> details.
>
> So clearly
> #pragma omp parallel num_threads(++i) if(++i)
> is forbidden :-)
>
> If we go back to:
>
> #pragma omp parallel if (VarA = 2)
> {
>     // parallel region
> }
> this is not forbidden by the norm but I choke on the fact that if we
> have an OpenMP compiler, the value of VarA is 2 in the continuation of the program
> after the #pragma, but if we compile without an OpenMP compiler, the
> value of VarA is unchanged neither even accessed.
>
> So to summarize: I vote for Olaf Krzikalla on this point. :-)
> --
>   Ronan KERYELL                            |\/  Phone:  +1 650 386 6482
>   SILKAN Wild Systems                      |/)
>   4962 El Camino Real #201                 K    Ronan.Keryell at silkan.com
>   Los Altos, CA 94022                      |\   skype:keryell
>   USA                                      | \  http://silkan.com
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev



-- 
mahesha



More information about the cfe-dev mailing list