Intel® C++ Compiler
Community support and assistance for creating C++ code that runs on platforms based on Intel® processors.

ICE with OpenMP and missing increment

Kensler__Andrew
Beginner
303 Views

A typo led me to discover that if the increment (e.g., ++) on an OpenMP parallel for is missing, then the compiler reports an internal error rather a normal error message such as I would expect.  Here is a reduced repro case:

int main() {
    #pragma omp parallel for
    for ( int foo = 0; foo < 100; foo )
        /* pass */;            // ^ ICE if increment missing
}

When I attempt to compile it, I see the following:

% icpc -fopenmp ompice.cpp
ompice.cpp(4): internal error: bad pointer
          /* pass */;            // ^ ICE if increment missing
                    ^

compilation aborted for ompice.cpp (code 4)
%

The most recent build of the compiler that I have tested this on is "Intel(R) C++ Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 19.0.0.120 Build 20180804", running on Ubuntu 18.04.  However, I also tried it on a machine with "17.0.4.196 Build 20170411" on Centos 7.3 and observed this behavior there as well.

Cheers,
- Andrew

0 Kudos
5 Replies
jimdempseyatthecove
Honored Contributor III
303 Views

ICE should not happen, even with an invalid OpenMP loop (it is not countable).

Jim Dempsey

0 Kudos
Viet_H_Intel
Moderator
303 Views

Your loop counter is wrong, it will work with foo++

Thanks,

Viet

0 Kudos
Viet_H_Intel
Moderator
303 Views

oh, I see what you meant. Yeah, the compiler shouldn't give "internal error". I'll report this to the developer.

Thanks,

Viet

0 Kudos
Viet_H_Intel
Moderator
303 Views

A bug report has been submitted (CMPLRIL0-30846)

0 Kudos
Kensler__Andrew
Beginner
303 Views

Thanks!  Yes, the code that I posted is definitely wrong in the sense that it is not a valid OpenMP loop and therefore really should fail to compile.  The workaround here is obviously to fix that (which I did in my original code once I'd realized that I'd typoed a deletion on the ++ while making other changes).

The issue here was simply that it seemed to produce an internal error in ICC's front end rather than a proper error message attributable to the loop statement.  Both GCC and Clang, for example, correctly point out the invalid increment.

0 Kudos
Reply