OMP problem with Intel compiler

[flame]

OMP problem with Intel compiler

[jeffhammond]

Below is my attempt at an MCVE. It compiles cleanly with icc -std=c11 -O3 -qopenmp -qopt-report capture.c -o capture.x.

Can you evolve my code into a valid MCVE?

#include <stdio.h>
#include <stdlib.h>

struct thread_comm_s
{
    int n;
};
typedef struct thread_comm_s thread_comm_t;

thread_comm_t c;

int main(int argc, char* argv[])
{
    int a;
    thread_comm_t * p = &c;
    _Pragma("omp atomic capture")
    a = ++(p->n);

    return 0;
}

[jeffhammond]

Here's a better attempt:

#include <stdio.h>
#include <stdlib.h>

typedef size_t dim_t;

struct thread_comm_s
{
    dim_t n;
};
typedef struct thread_comm_s thread_comm_t;

thread_comm_t c;

int main(int argc, char* argv[])
{
    dim_t a;
    thread_comm_t * p = &c;
    _Pragma("omp atomic capture")
    a = ++(p->n);

    return 0;
}

[tlrmchlsmth]

BLIS is compiling for me with icc 15.0.1.

Victor, can you attach the make_defs.mk file that you're using?

On Thu, Aug 20, 2015 at 7:52 AM, VictorEijkhout [email protected]
wrote:

Compiling frame/base/bli_threading_omp.c
frame/base/bli_threading_omp.c: In function 'bli_barrier':
frame/base/bli_threading_omp.c:88: error: expected end of line before 'capture'
frame/base/bli_threading_omp.c:89: error: invalid operator for '#pragma omp atomic' before '=' token
make: *** [obj/sandybridge/frame/base/bli_threading_omp.o] Error 1

I know that earlier Intel compilers did not support the full OMP 3.1
standard, but this is Intel 15.

—
Reply to this email directly or view it on GitHub
#32.

[VictorEijkhout]

On Aug 20, 2015, at 10:43 AM, Tyler Michael Smith <[email protected]mailto:[email protected]> wrote:

BLIS is compiling for me with icc 15.0.1.

Victor, can you attach the make_defs.mk file that you're using?

I’m not using anything custom. Here’s my whole installation:

./configure -p $RPM_BUILD_ROOT/%{INSTALL_DIR} sandybridge
make
make install

I think this means I’m using the standard sandybridge configuration.

If you are using custom settings, feel free to mail them to me and indicate how to use them.

Victor.

[fgvanzee]

If you are using the sandybridge configuration unmodified, then you're not using icc, you're using gcc.

[VictorEijkhout]

On Aug 21, 2015, at 10:30 AM, Field G. Van Zee <[email protected]mailto:[email protected]> wrote:

If you are using the sandybridge configuration unmodified, then you're not using icc, you're using gcc.

Override with configure option?

Victor.

[VictorEijkhout]

On Aug 21, 2015, at 10:30 AM, Field G. Van Zee <[email protected]mailto:[email protected]> wrote:

If you are using the sandybridge configuration unmodified, then you're not using icc, you're using gcc.

PS I didn’t know the compiler was a property of the processor architecture…..

[fgvanzee]

Override with configure option?

Someday, yes. But for now, the compiler shall be specified in the configuration.

PS I didn’t know the compiler was a property of the processor architecture…..

It's not, it's a property of the configuration, which specifies the build environment as well as the kernels and their associated parameters (such as blocksizes).

[jeffhammond]

Is there any further action required on this specific issue or can it be closed?

[fgvanzee]

I think it can be closed. I suspect the issue was born largely from confusion over the build system. Devin's recent upgrades to the configure script, supporting icc and gcc explicitly, certainly helps as well.