Internal compiler error when compiling PSBLAS solver

[htg20]

Hello,

I am trying to compile the psblas solver version 3. fromhttp://www.ce.uniroma2.it/psblas/but it gives me the error:

**Internal compiler error: segmentation violation signal raised**

The psblas 3 is a Fortran 2003 code. This problem has been there for almost a year now with all updates of intel 12. I use openmpi (compiled from source with Intel) for the MPI library, if it matters. The download link address of the psblas software is:http://www.ce.uniroma2.it/psblas/psblas-3.0-beta1.tgz.

I have tested with the gfortran 4.6 and NAG compiler and both can compile psblas 3.

Thank you.

Cheers

Hossein

[Steven_L_Intel1]

Thanks - we'll take a look at this. Which specific source files give you errors?

[mecej4]

Each new release of the Intel Fortran compiler comes with more F2003 capabilities added. However, the compiler is not yet a full F2003 compiler.

It would be more useful for you to post the specific subprogram (along with those that it depends on) whose compilation causes the segmentation violation.

[htg20]

From the release notes the intel compiler has all the capabilities to compile the psblas packge. psblas is kind of big package with many dependancies, I mean it is difficult to extract the subprograms causing the problem. One time, I tried to change the compiling sequence of files but it gave the same error for another file.

If it helps, for me it happens first time when compiling the"psb_serial_mod.f90" file.

[Steven_L_Intel1]

I was able to reproduce at least some internal compiler errors. I have not seen any language usages we don't support. I will report any issues I find to the developers - thanks for letting us know. I'm not aware that these have been reported to us previously.

[Steven_L_Intel1]

I submitted issue DPD200179742 for the errors I found building the "base/modules" files. I can't really do much more until that is resolved. The factors here seem to be a type-bound procedure with a separate procedure-name given where that is a procedure in an interface block. That itself doesn't trigger the error, but a chain of modules using the definition eventually does. I could not figure out a reasonable workaround. I will update this thread as I get news.

Thank you for bringing this to our attention.

[htg20]

It's my pleasure and thank you too for following up so quickly. I wish I posted this earlier.I have already notified the psblas developers about this issue.

I'm looking forward to hear the problem solved.

[Steven_L_Intel1 · Accepted solution]

The internal compiler error I reported has been fixed for a release later this year. I will see if there are other issues.

[htg20]

Dear Steve,

I just checked the issue with the PSBLAS package with the ifort build20120612 and same problem exists. Are you sure that the bug is fixed?

Thank you.

Cheers

Hossein

[Steven_L_Intel1]

We have not yet released the version containing the fix. I expect that in the September timeframe.

[jb84]

Dear Steve,

I am getting the same error on our F2003 CFD code where, as you said,  we have "a type-bound procedure with a separate procedure-name given where that is a procedure in an interface block". I have also tried to compile the PSBLAS package (http://www.ce.uniroma2.it/psblas/psblas-3.0-2.tgz) with the latest ifort build (from composer_xe_2013.2.146) and the internal error also arises for me, at file: psb_srwextd.f90.

Do you have any news on this issue? Thanks,

Joan

[Steven_L_Intel1]

You're seeing a different error than before, though the symptom may be similar. The sources from the earlier beta compile fine for me, but I am getting different errors (not yet an ICE) for the 3.0-2. I'll look into this in more detail.

[Steven_L_Intel1]

I'm stuck analyzing this - this version of PSBLAS has too many valid coding errors that the compiler complains about, so that the modules that psb_srwextd.f90 depends on can't be compiled.

For example, psb_hash_map_mod.f90 (which is needed to compile psb_tools_mod) extends type psb_indx_map with psb_hash_map and overrides the type-bound procedure g2ls1_ins with hash_g2ls1_ins. ifort correctly complains that the non-passed arguments, corresponding by position, don't match in type as is required by the standard (the lidx argument is logical in the base routine and integer in the override.)

The source you complained about depends on some of these erroneous modules. I am not sure how you got as far as an internal compiler error but there's nothing more I can do here for now.