Page 1 of 1

Compiling Serpent 2.1.31 with OpenMP: issue with gcc 9

Posted: Mon Nov 11, 2019 7:19 pm
by paulromano
Trying to compile Serpent 2.1.31 with gcc 9.2 produces the following:

Code: Select all

gcc -O3 -ffast-math -Wall -ansi -Wunused -DOPEN_MP -fopenmp -pedantic -c collectfet.c
collectfet.c: In function ‘CollectFET’:
collectfet.c:60:9: error: ‘coef2’ not specified in enclosing ‘parallel’
   60 | #pragma omp parallel for collapse(3) default(none) \
      |         ^~~
collectfet.c:60:9: error: enclosing ‘parallel’
collectfet.c:60:9: error: ‘coef1’ not specified in enclosing ‘parallel’
collectfet.c:60:9: error: enclosing ‘parallel’
collectfet.c:60:9: error: ‘coef0’ not specified in enclosing ‘parallel’
collectfet.c:60:9: error: enclosing ‘parallel’
collectfet.c:68:15: error: ‘params’ not specified in enclosing ‘parallel’
   68 |     coefIdx = FETIdx(params, n2, n1, n0);
      |               ^~~~~~~~~~~~~~~~~~~~~~~~~~
collectfet.c:60:9: error: enclosing ‘parallel’
   60 | #pragma omp parallel for collapse(3) default(none) \
      |         ^~~
collectfet.c:78:25: error: ‘scorePtr’ not specified in enclosing ‘parallel’
   78 |       bufPtr = scorePtr + coefOffset*BUF_BLOCK_SIZE;
      |                ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
collectfet.c:60:9: error: enclosing ‘parallel’
   60 | #pragma omp parallel for collapse(3) default(none) \
      |         ^~~
collectfet.c:93:23: error: ‘totalCoefficients’ not specified in enclosing ‘parallel’
   93 |       if (coefIdx + 1 == totalCoefficients)
      |           ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~
collectfet.c:60:9: error: enclosing ‘parallel’
   60 | #pragma omp parallel for collapse(3) default(none) \
      |         ^~~
collectfet.c:70:27: error: ‘totalLayers’ not specified in enclosing ‘parallel’
   70 |     for (layer = 0; layer < totalLayers; ++layer)
      |                     ~~~~~~^~~~~~~~~~~~~
collectfet.c:60:9: error: enclosing ‘parallel’
   60 | #pragma omp parallel for collapse(3) default(none) \
      |         ^~~
It looks like this is related to some changes in how data sharing is treated with gcc 9, where they've defaulted to OpenMP 4 behavior rather than OpenMP 3.1. Not sure what the right fix is but I figured I would report this so that others may address it.

Re: Compiling Serpent 2.1.31 with OpenMP: issue with gcc 9

Posted: Wed Nov 13, 2019 12:56 pm
by Ville Valtavirta
Thank you Paul for reporting this,

it seems a quick fix for this is to move from default(none) on line 60 of the file to default(shared).

I'll have to test the change once I get my hands on gcc 9.

-Ville

Re: Compiling Serpent 2.1.31 with OpenMP: issue with gcc 9

Posted: Thu Jun 04, 2020 3:23 pm
by jan.frybort
I can confirm the same behaviour with Ubuntu 20.04 gcc 9.3. Changing to default(shared) helped, but there is a linking error:

Code: Select all

/usr/bin/ld: collectsensresults.o: in function `CollectSensResults._omp_fn.0':
collectsensresults.c:(.text+0xb3): undefined reference to `GOMP_loop_nonmonotonic_dynamic_start'
/usr/bin/ld: collectsensresults.c:(.text+0x381): undefined reference to `GOMP_loop_nonmonotonic_dynamic_next'
/usr/bin/ld: collectuncresults.o: in function `CollectUncResults._omp_fn.0':
collectuncresults.c:(.text+0xcb): undefined reference to `GOMP_loop_nonmonotonic_dynamic_start'
/usr/bin/ld: collectuncresults.c:(.text+0x3c1): undefined reference to `GOMP_loop_nonmonotonic_dynamic_next'
/usr/bin/ld: initialcritsrc.o: in function `InitialCritSrc._omp_fn.0':
initialcritsrc.c:(.text+0x52): undefined reference to `GOMP_loop_nonmonotonic_dynamic_start'
/usr/bin/ld: initialcritsrc.c:(.text+0xcf): undefined reference to `GOMP_loop_nonmonotonic_dynamic_next'
/usr/bin/ld: sampledelnu.o: in function `SampleDelnu._omp_fn.0':
sampledelnu.c:(.text+0x40): undefined reference to `GOMP_loop_nonmonotonic_dynamic_start'
/usr/bin/ld: sampledelnu.c:(.text+0x9a): undefined reference to `GOMP_loop_nonmonotonic_dynamic_next'
/usr/bin/ld: sampledelnu.o: in function `SampleDelnu._omp_fn.1':
sampledelnu.c:(.text+0x110): undefined reference to `GOMP_loop_nonmonotonic_dynamic_start'
/usr/bin/ld: sampledelnu.c:(.text+0x16a): undefined reference to `GOMP_loop_nonmonotonic_dynamic_next'
/usr/bin/ld: transportcycle.o: in function `TransportCycle._omp_fn.0':
transportcycle.c:(.text+0x4d): undefined reference to `GOMP_loop_nonmonotonic_dynamic_start'
/usr/bin/ld: transportcycle.c:(.text+0xc2): undefined reference to `GOMP_loop_nonmonotonic_dynamic_next'
/usr/bin/ld: transportcycle.o: in function `TransportCycle._omp_fn.1':
transportcycle.c:(.text+0x1d2): undefined reference to `GOMP_loop_nonmonotonic_dynamic_start'
/usr/bin/ld: transportcycle.c:(.text+0x264): undefined reference to `GOMP_loop_nonmonotonic_dynamic_next'
/usr/bin/ld: transportcycle.o: in function `TransportCycle._omp_fn.3':
transportcycle.c:(.text+0x31d): undefined reference to `GOMP_loop_nonmonotonic_dynamic_start'
/usr/bin/ld: transportcycle.c:(.text+0x38c): undefined reference to `GOMP_loop_nonmonotonic_dynamic_next'
/usr/bin/ld: transportcycle.o: in function `TransportCycle._omp_fn.7':
transportcycle.c:(.text+0x40d): undefined reference to `GOMP_loop_nonmonotonic_dynamic_start'
/usr/bin/ld: transportcycle.c:(.text+0x47c): undefined reference to `GOMP_loop_nonmonotonic_dynamic_next'
/usr/bin/ld: transportcycle.o: in function `TransportCycle._omp_fn.11':
transportcycle.c:(.text+0x4fd): undefined reference to `GOMP_loop_nonmonotonic_dynamic_start'
/usr/bin/ld: transportcycle.c:(.text+0x54e): undefined reference to `GOMP_loop_nonmonotonic_dynamic_next'
collect2: error: ld returned 1 exit status

Re: Compiling Serpent 2.1.31 with OpenMP: issue with gcc 9

Posted: Mon Jun 08, 2020 8:38 am
by Antti Rintala
jan.frybort wrote:
Thu Jun 04, 2020 3:23 pm
I can confirm the same behaviour with Ubuntu 20.04 gcc 9.3. Changing to default(shared) helped, but there is a linking error:

Code: Select all

/usr/bin/ld: collectsensresults.o: in function `CollectSensResults._omp_fn.0':
collectsensresults.c:(.text+0xb3): undefined reference to `GOMP_loop_nonmonotonic_dynamic_start'
/usr/bin/ld: collectsensresults.c:(.text+0x381): undefined reference to `GOMP_loop_nonmonotonic_dynamic_next'
/usr/bin/ld: collectuncresults.o: in function `CollectUncResults._omp_fn.0':
collectuncresults.c:(.text+0xcb): undefined reference to `GOMP_loop_nonmonotonic_dynamic_start'
/usr/bin/ld: collectuncresults.c:(.text+0x3c1): undefined reference to `GOMP_loop_nonmonotonic_dynamic_next'
/usr/bin/ld: initialcritsrc.o: in function `InitialCritSrc._omp_fn.0':
initialcritsrc.c:(.text+0x52): undefined reference to `GOMP_loop_nonmonotonic_dynamic_start'
/usr/bin/ld: initialcritsrc.c:(.text+0xcf): undefined reference to `GOMP_loop_nonmonotonic_dynamic_next'
/usr/bin/ld: sampledelnu.o: in function `SampleDelnu._omp_fn.0':
sampledelnu.c:(.text+0x40): undefined reference to `GOMP_loop_nonmonotonic_dynamic_start'
/usr/bin/ld: sampledelnu.c:(.text+0x9a): undefined reference to `GOMP_loop_nonmonotonic_dynamic_next'
/usr/bin/ld: sampledelnu.o: in function `SampleDelnu._omp_fn.1':
sampledelnu.c:(.text+0x110): undefined reference to `GOMP_loop_nonmonotonic_dynamic_start'
/usr/bin/ld: sampledelnu.c:(.text+0x16a): undefined reference to `GOMP_loop_nonmonotonic_dynamic_next'
/usr/bin/ld: transportcycle.o: in function `TransportCycle._omp_fn.0':
transportcycle.c:(.text+0x4d): undefined reference to `GOMP_loop_nonmonotonic_dynamic_start'
/usr/bin/ld: transportcycle.c:(.text+0xc2): undefined reference to `GOMP_loop_nonmonotonic_dynamic_next'
/usr/bin/ld: transportcycle.o: in function `TransportCycle._omp_fn.1':
transportcycle.c:(.text+0x1d2): undefined reference to `GOMP_loop_nonmonotonic_dynamic_start'
/usr/bin/ld: transportcycle.c:(.text+0x264): undefined reference to `GOMP_loop_nonmonotonic_dynamic_next'
/usr/bin/ld: transportcycle.o: in function `TransportCycle._omp_fn.3':
transportcycle.c:(.text+0x31d): undefined reference to `GOMP_loop_nonmonotonic_dynamic_start'
/usr/bin/ld: transportcycle.c:(.text+0x38c): undefined reference to `GOMP_loop_nonmonotonic_dynamic_next'
/usr/bin/ld: transportcycle.o: in function `TransportCycle._omp_fn.7':
transportcycle.c:(.text+0x40d): undefined reference to `GOMP_loop_nonmonotonic_dynamic_start'
/usr/bin/ld: transportcycle.c:(.text+0x47c): undefined reference to `GOMP_loop_nonmonotonic_dynamic_next'
/usr/bin/ld: transportcycle.o: in function `TransportCycle._omp_fn.11':
transportcycle.c:(.text+0x4fd): undefined reference to `GOMP_loop_nonmonotonic_dynamic_start'
/usr/bin/ld: transportcycle.c:(.text+0x54e): undefined reference to `GOMP_loop_nonmonotonic_dynamic_next'
collect2: error: ld returned 1 exit status
Have you performed make clean before compiling with gcc 9? First Google hit suggests that this might be due to linking with something compiled with earlier compiler or library versions.

Re: Compiling Serpent 2.1.31 with OpenMP: issue with gcc 9

Posted: Mon Jun 08, 2020 12:26 pm
by jan.frybort
Thank you for the suggestions. I did check it again and tried make clean and there is no stuff compiled before.

Re: Compiling Serpent 2.1.31 with OpenMP: issue with gcc 9

Posted: Sun Jul 05, 2020 2:09 am
by jordancrowell
I have experienced this same issue and was curious if the anyone else has been having the same problem? I changed "default(none)" to "default(shared}" and was curious if this will affect any other aspect of the code I don't know about? When I change it to "default(shared}" it compiles fine but wasn't sure if other issues will occur.

Thanks,

Jordan

Re: Compiling Serpent 2.1.31 with OpenMP: issue with gcc 9

Posted: Sun Jul 05, 2020 8:00 pm
by Ana Jambrina
Following the post above (see: https://www.gnu.org/software/gcc/gcc-9/porting_to.html): for GCC9, and OpenMP 4.0, and later, compliance, 'const' qualified variables need to be specified on constructs in which they are used , either in 'shared' or 'firstprivate' clause. Specifying them in 'firstprivate' clause is one way to achieve compatibility with both older GCC versions and GCC 9, another option is to drop the 'default(none)' clause - GCC9 predetermined rule is 'shared'.

Re: Compiling Serpent 2.1.31 with OpenMP: issue with gcc 9

Posted: Tue Aug 11, 2020 6:39 pm
by froberto
I am working on Ubuntu 20.04, gcc vestion 9.3.0 and I had the same compilation error.
This solution worked for me:
Ville Valtavirta wrote:
Wed Nov 13, 2019 12:56 pm
it seems a quick fix for this is to move from default(none) on line 60 of the file to default(shared).