NoExcision internal compiler error

Issue #1693 closed
Ian Hinder created an issue

When compiling the NoExcision thorn on Hydra at the RZG with ifort (IFORT) 15.0.0 20140723, I get the following error:

/hydra/u/ihinder/Cactus/EinsteinToolkitGit/arrangements/EinsteinInitialData/NoExcision/src/cg.F90(373): remark #8291: Recommended relationship between field width 'W' and the number of fractional digits 'D' in this edit descriptor is 'W>=D+7'.
    write (res_message, '(16(a3,es9.3))' ) (' | ', infnormresid(i), i=1, 16 )
----------------------------------^
/hydra/u/ihinder/Cactus/EinsteinToolkitGit/configs/sim/build/NoExcision/cg.f90: catastrophic error: **Internal compiler error: segmentation violation signal raised** Please report this error along with the circumstances in which it occurred in a Software Problem Report.  Note: File and line given may not be explicit cause of this error.
compilation aborted for /hydra/u/ihinder/Cactus/EinsteinToolkitGit/configs/sim/build/NoExcision/cg.f90 (code 1)

I will just disable this thorn for this machine for the moment, but the problem might also arise with other machines which use this compiler version.

Keyword:

Comments (10)

  1. Peter Diener
    • removed comment

    I saw that as well when running tests on SuperMIC and QB2. The internal compiler error has nothing to do with the formatting warning and can be circumvented by commenting out the first set of !$OMP PARALLEL WORKSHARE and !$OMP END PARALLEL WORKSHARE openmp directives. I'm not sure why this would cause problems for the compiler, as it would generate single threaded code anyway. I don't know if any compiler in use is able to generate parallelized code for OpenMP workshare regions. This part of the code is only executed once anyway, so it might not be too bad to just comment this out for all compilers.

  2. Frank Löffler
    • removed comment

    You say it is executed only once - how "long" can the runtime for this be? It this is always only seconds we can probably remove it. If, however, this part may take an hour, and OpenMP can reduce it to a few minutes, we might not want to, at least not for compilers that don't choke on it and actually parallelize.

  3. Roland Haas
    • removed comment

    Currently none of the intel compilers (not sure about gfortran) actually parallelize WORKSHARE statements at all. They are always executed on a single core. So removing the OMP WORKSHARE won't make the code slower.

  4. Peter Diener
    • removed comment

    The code section in question just initialized work grid functions to zero, so the execution time is probably <1s. As Roland says, the intel compiler don't actually parallelize WORKSHARE constructs at all but instead generates serial code. I don't know if any of the other compilers are able to generate parallel code, but I don't expect the performance hit to be noticable in any case.

  5. Frank Löffler
    • removed comment

    In that case it seems that removing the OMP statements would be the right thing to do.

  6. Peter Diener
    • changed status to resolved
    • removed comment

    I commented out the offending set of OpenMP WORKSHARE dirctives and added a comment as to why that was done.

  7. Erik Schnetter
    • changed status to open
    • removed comment

    I reported this issue to Intel. It will be corrected in the next release of the compiler.

  8. Ian Hinder reporter
    • removed comment

    Does this ticket need to stay open? As far as I can see, the problem has been reported to Intel, and the ET no longer uses the directives which are miscompiled. There is a comment in the code to explain why, and there is judged to be no performance impact.

  9. Log in to comment