[cfe-dev] [OMP] Clang fails to handle parallel for + collapse

Hans Wennborg via cfe-dev cfe-dev at lists.llvm.org
Thu Feb 18 12:56:12 PST 2016


r261080 merged in r261256; Alexey, please check that I got the merge right.
r261209 merged in r261257.

Thanks,
Hans

On Thu, Feb 18, 2016 at 11:42 AM, Alexey Bataev <a.bataev at hotmail.com> wrote:
> Hans, keep the code from ".working" section to resolve the conflict
>
> Best regards,
> Alexey Bataev
> =============
> Software Engineer
> Intel Compiler Team
>
> 18.02.2016 22:33, Hans Wennborg пишет:
>> r261080 doesn't merge cleanly. I get this conflict in the end of
>> BuildCounterUpdate:
>>
>> <<<<<<< .working
>>    Update = SemaRef.BuildBinOp(S, Loc, BO_Assign, VarRef.get(), Update.get());
>> =======
>>    // Second attempt: try to build 'VarRef = Start (+|-) Iter * Step'.
>>    if (!Update.isUsable() || !UpdateVal.isUsable()) {
>>      Update = SemaRef.BuildBinOp(S, Loc, Subtract ? BO_Sub : BO_Add,
>>                                  NewStart.get(), SavedUpdate.get());
>>      if (!Update.isUsable())
>>        return ExprError();
>>
>>      if (!SemaRef.Context.hasSameType(Update.get()->getType(),
>>                                       VarRef.get()->getType())) {
>>        Update = SemaRef.PerformImplicitConversion(
>>            Update.get(), VarRef.get()->getType(), Sema::AA_Converting, true);
>>        if (!Update.isUsable())
>>          return ExprError();
>>      }
>>
>>      Update = SemaRef.BuildBinOp(S, Loc, BO_Assign, VarRef.get(), Update.get());
>>    }
>>>>>>>>> .merge-right.r261080
>>    return Update;
>> }
>>
>>
>> On Thu, Feb 18, 2016 at 11:02 AM, Hal Finkel <hfinkel at anl.gov> wrote:
>>> Hans?
>>>
>>> Thanks again,
>>> Hal
>>>
>>> ----- Original Message -----
>>>> From: "Alexey Bataev" <a.bataev at hotmail.com>
>>>> To: "Hal Finkel" <hfinkel at anl.gov>
>>>> Cc: cfe-dev at lists.llvm.org, "Jonas Hahnfeld" <hahnfeld at itc.rwth-aachen.de>, "Samuel Pitoiset"
>>>> <samuel.pitoiset at gmail.com>
>>>> Sent: Thursday, February 18, 2016 1:00:17 PM
>>>> Subject: Re: [cfe-dev] [OMP] Clang fails to handle parallel for + collapse
>>>>
>>>> Hal, yes, this one also must be committed to release branch. Could
>>>> you
>>>> ask Hans to commit it?
>>>>
>>>> Best regards,
>>>> Alexey Bataev
>>>> =============
>>>> Software Engineer
>>>> Intel Compiler Team
>>>>
>>>> 18.02.2016 17:26, Hal Finkel пишет:
>>>>> Hi Alexey,
>>>>>
>>>>> Have all of the recent OpenMP fixes made it into the release
>>>>> branch. Should this one?
>>>>>
>>>>>    -Hal
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Alexey Bataev via cfe-dev" <cfe-dev at lists.llvm.org>
>>>>>> To: "Jonas Hahnfeld" <Hahnfeld at itc.rwth-aachen.de>, "Samuel
>>>>>> Pitoiset" <samuel.pitoiset at gmail.com>
>>>>>> Cc: cfe-dev at lists.llvm.org
>>>>>> Sent: Thursday, February 18, 2016 7:53:26 AM
>>>>>> Subject: Re: [cfe-dev] [OMP] Clang fails to handle parallel for +
>>>>>> collapse
>>>>>>
>>>>>> Fixed in r261209
>>>>>>
>>>>>> Best regards,
>>>>>> Alexey Bataev
>>>>>> =============
>>>>>> Software Engineer
>>>>>> Intel Compiler Team
>>>>>>
>>>>>> 17.02.2016 14:39, Hahnfeld, Jonas пишет:
>>>>>>> Hi Alexey,
>>>>>>>
>>>>>>> I think this reveals another bug: q isn't correctly lastprivate
>>>>>>> and
>>>>>>> in the end doesn't hold buf2 + 8.
>>>>>>> This may be related to collapse(2) because it works fine if I
>>>>>>> remove that clause...
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Jonas
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf
>>>>>>>> Of
>>>>>>>> Alexey
>>>>>>>> Bataev via cfe-dev
>>>>>>>> Sent: Wednesday, February 17, 2016 11:35 AM
>>>>>>>> To: Samuel Pitoiset; cfe-dev at lists.llvm.org
>>>>>>>> Subject: Re: [cfe-dev] [OMP] Clang fails to handle parallel for
>>>>>>>> +
>>>>>>>> collapse
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>> Thanks for the report. Problem fixed in r261080
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Alexey Bataev
>>>>>>>> =============
>>>>>>>> Software Engineer
>>>>>>>> Intel Compiler Team
>>>>>>>>
>>>>>>>>
>>>>>>>> 16.02.2016 17:49, Samuel Pitoiset via cfe-dev пишет:
>>>>>>>>> Hi there,
>>>>>>>>>
>>>>>>>>> It seems like Clang fails to create a OMPParallelForDirective
>>>>>>>>> object
>>>>>>>>> for the given GCC test sample:
>>>>>>>>> https://github.com/gcc-mirror/gcc/blob/master/libgomp/testsuite/libgom
>>>>>>>>> p.c/loop-9.c
>>>>>>>>>
>>>>>>>>> I just tried to dump the AST with clang cc1 -ast-dump -fopenmp
>>>>>>>>> loop-9.c, and the output is:
>>>>>>>>>
>>>>>>>>> TranslationUnitDecl 0x3a53eb0 <<invalid sloc>> <invalid sloc>
>>>>>>>>> |-TypedefDecl 0x3a543c8 <<invalid sloc>> <invalid sloc>
>>>>>>>>> |implicit
>>>>>>>>> __int128_t '__int128'
>>>>>>>>> | `-BuiltinType 0x3a54100 '__int128'
>>>>>>>>> |-TypedefDecl 0x3a54428 <<invalid sloc>> <invalid sloc>
>>>>>>>>> |implicit
>>>>>>>>> __uint128_t 'unsigned __int128'
>>>>>>>>> | `-BuiltinType 0x3a54120 'unsigned __int128'
>>>>>>>>> |-TypedefDecl 0x3a546e8 <<invalid sloc>> <invalid sloc>
>>>>>>>>> |implicit
>>>>>>>>> __NSConstantString 'struct __NSConstantString_tag'
>>>>>>>>> | `-RecordType 0x3a54500 'struct __NSConstantString_tag'
>>>>>>>>> |   `-Record 0x3a54478 '__NSConstantString_tag'
>>>>>>>>> |-TypedefDecl 0x3a54778 <<invalid sloc>> <invalid sloc>
>>>>>>>>> |implicit
>>>>>>>>> __builtin_ms_va_list 'char *'
>>>>>>>>> | `-PointerType 0x3a54740 'char *'
>>>>>>>>> |   `-BuiltinType 0x3a53f40 'char'
>>>>>>>>> |-TypedefDecl 0x3a54a28 <<invalid sloc>> <invalid sloc>
>>>>>>>>> |implicit
>>>>>>>>> __builtin_va_list 'struct __va_list_tag [1]'
>>>>>>>>> | `-ConstantArrayType 0x3a549d0 'struct __va_list_tag [1]' 1
>>>>>>>>> |   `-RecordType 0x3a54850 'struct __va_list_tag'
>>>>>>>>> |     `-Record 0x3a547c8 '__va_list_tag'
>>>>>>>>> |-FunctionDecl 0x3aa0780
>>>>>>>>> |<tests/gcc-testsuite/libgomp.c/loop-9.c:1:13>
>>>>>>>>> col:13 implicit abort 'void (void) __attribute__((noreturn))'
>>>>>>>>> extern
>>>>>>>>> |-FunctionDecl 0x3aa0828 prev 0x3aa0780 <col:1, col:24> col:13
>>>>>>>>> |used
>>>>>>>>> abort 'void (void) __attribute__((noreturn))' extern
>>>>>>>>> |-VarDecl 0x3aa0948 <line:3:1, col:15> col:6 used buf 'char
>>>>>>>>> |[8]'
>>>>>>>>> |cinit
>>>>>>>>> |`-StringLiteral 0x3aa0a28 <col:15> 'char [8]' lvalue
>>>>>>>>> |"01234567"
>>>>>>>>> |-VarDecl 0x3aa0a98 <line:4:1, col:16> col:6 used buf2 'char
>>>>>>>>> |[8]'
>>>>>>>>> |cinit  `-StringLiteral 0x3aa0af8 <col:16> 'char [8]' lvalue
>>>>>>>>> |"23456789"
>>>>>>>>> `-FunctionDecl 0x3aa0bf0 <line:6:1, line:18:1> line:7:1 main
>>>>>>>>> 'int
>>>>>>>>> (void)'
>>>>>>>>>      `-CompoundStmt 0x3aa4fe0 <line:8:1, line:18:1>
>>>>>>>>>        |-DeclStmt 0x3aa0dc0 <line:9:3, col:14>
>>>>>>>>>        | |-VarDecl 0x3aa0cd8 <col:3, col:9> col:9 used p 'char
>>>>>>>>>        | |*'
>>>>>>>>>        | `-VarDecl 0x3aa0d48 <col:3, col:13> col:13 used q 'char
>>>>>>>>>        | *'
>>>>>>>>>        |-DeclStmt 0x3aa0e68 <line:10:3, col:14>
>>>>>>>>>        | `-VarDecl 0x3aa0de8 <col:3, col:13> col:7 used sum
>>>>>>>>>        | 'int'
>>>>>>>>>        | cinit
>>>>>>>>>        |   `-IntegerLiteral 0x3aa0e48 <col:13> 'int' 0
>>>>>>>>>        |-IfStmt 0x3aa4f78 <line:15:3, line:16:12>
>>>>>>>>>        | |-<<<NULL>>>
>>>>>>>>>        | |-BinaryOperator 0x3aa4e98 <line:15:7, col:47> 'int'
>>>>>>>>>        | |'||'
>>>>>>>>>        | | |-BinaryOperator 0x3aa4de8 <col:7, col:35> 'int' '||'
>>>>>>>>>        | | | |-BinaryOperator 0x3aa4cd0 <col:7, col:18> 'int'
>>>>>>>>>        | | | |'!='
>>>>>>>>>        | | | | |-ImplicitCastExpr 0x3aa4cb8 <col:7> 'char *'
>>>>>>>>> <LValueToRValue>
>>>>>>>>>        | | | | | `-DeclRefExpr 0x3aa4be8 <col:7> 'char *' lvalue
>>>>>>>>>        | | | | | Var
>>>>>>>>> 0x3aa0cd8 'p' 'char *'
>>>>>>>>>        | | | | `-UnaryOperator 0x3aa4c98 <col:12, col:18> 'char
>>>>>>>>>        | | | | *'
>>>>>>>>>        | | | | prefix
>>>>>>>>> '&'
>>>>>>>>>        | | | |   `-ArraySubscriptExpr 0x3aa4c70 <col:13, col:18>
>>>>>>>>>        | | | |   'char'
>>>>>>>>> lvalue
>>>>>>>>>        | | | |     |-ImplicitCastExpr 0x3aa4c58 <col:13> 'char
>>>>>>>>>        | | | |     |*'
>>>>>>>>> <ArrayToPointerDecay>
>>>>>>>>>        | | | |     | `-DeclRefExpr 0x3aa4c10 <col:13> 'char [8]'
>>>>>>>>>        | | | |     | lvalue
>>>>>>>>> Var 0x3aa0948 'buf' 'char [8]'
>>>>>>>>>        | | | |     `-IntegerLiteral 0x3aa4c38 <col:17> 'int' 8
>>>>>>>>>        | | | `-BinaryOperator 0x3aa4dc0 <col:23, col:35> 'int'
>>>>>>>>>        | | | '!='
>>>>>>>>>        | | |   |-ImplicitCastExpr 0x3aa4da8 <col:23> 'char *'
>>>>>>>>> <LValueToRValue>
>>>>>>>>>        | | |   | `-DeclRefExpr 0x3aa4cf8 <col:23> 'char *'
>>>>>>>>>        | | |   | lvalue
>>>>>>>>>        | | |   | Var
>>>>>>>>> 0x3aa0d48 'q' 'char *'
>>>>>>>>>        | | |   `-BinaryOperator 0x3aa4d80 <col:28, col:35> 'char
>>>>>>>>>        | | |   *'
>>>>>>>>>        | | |   '+'
>>>>>>>>>        | | |     |-ImplicitCastExpr 0x3aa4d68 <col:28> 'char *'
>>>>>>>>> <ArrayToPointerDecay>
>>>>>>>>>        | | |     | `-DeclRefExpr 0x3aa4d20 <col:28> 'char [8]'
>>>>>>>>>        | | |     | lvalue Var
>>>>>>>>> 0x3aa0a98 'buf2' 'char [8]'
>>>>>>>>>        | | |     `-IntegerLiteral 0x3aa4d48 <col:35> 'int' 8
>>>>>>>>>        | | `-BinaryOperator 0x3aa4e70 <col:40, col:47> 'int'
>>>>>>>>>        | | '!='
>>>>>>>>>        | |   |-ImplicitCastExpr 0x3aa4e58 <col:40> 'int'
>>>>>>>>>        | |   |<LValueToRValue>
>>>>>>>>>        | |   | `-DeclRefExpr 0x3aa4e10 <col:40> 'int' lvalue Var
>>>>>>>>> 0x3aa0de8 'sum' 'int'
>>>>>>>>>        | |   `-IntegerLiteral 0x3aa4e38 <col:47> 'int' 576
>>>>>>>>>        | |-CallExpr 0x3aa4f50 <line:16:5, col:12> 'void'
>>>>>>>>>        | | `-ImplicitCastExpr 0x3aa4f38 <col:5> 'void (*)(void)
>>>>>>>>> __attribute__((noreturn))' <FunctionToPointerDecay>
>>>>>>>>>        | |   `-DeclRefExpr 0x3aa4ee0 <col:5> 'void (void)
>>>>>>>>> __attribute__((noreturn))' Function 0x3aa0828 'abort' 'void
>>>>>>>>> (void)
>>>>>>>>> __attribute__((noreturn))'
>>>>>>>>>        | `-<<<NULL>>>
>>>>>>>>>        `-ReturnStmt 0x3aa4fc8 <line:17:3, col:10>
>>>>>>>>>          `-IntegerLiteral 0x3aa4fa8 <col:10> 'int' 0
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> As you can see, there is no OMPParallelForDirective.
>>>>>>>>>
>>>>>>>>> Is it a bug in Clang? Or maybe the OMPParallelForDirective is
>>>>>>>>> not
>>>>>>>>> created because the loop doesn't respect the canonical form
>>>>>>>>> described
>>>>>>>>> by the OpenMP spec? In this case, it should be much better to
>>>>>>>>> return
>>>>>>>>> an error message like "for is not canonical" or something.
>>>>>>>>>
>>>>>>>>> This test can be compiled with GCC 5.3.
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> cfe-dev mailing list
>>>>>>>> cfe-dev at lists.llvm.org
>>>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>>>> _______________________________________________
>>>>>> cfe-dev mailing list
>>>>>> cfe-dev at lists.llvm.org
>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>>>>
>>>>
>>> --
>>> Hal Finkel
>>> Assistant Computational Scientist
>>> Leadership Computing Facility
>>> Argonne National Laboratory
>



More information about the cfe-dev mailing list