ifort -C causing Internal compiler error: segmentation violation signal raised

[Gerard_G_]

I am using:

Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 13.0.1.117 Build 20121010

However, when I compile with -C it fails:

$ ifort -I./ -c Global_Numbering.F90
[ggorman@login-2 bug]$ ifort -I./ -c -C Global_Numbering.F90
/tmp/ifort8MN7Rd.i90: 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 Global_Numbering.F90 (code 1)

Without -C it builds fine. I have attached the minimum set of files required to reprooduce the bug.

[Steven_L_Intel1]

We will need the sources of all the modules as well. Often the problem begins when the module is compiled.  However, I'd first ask you to try the latest version, 13.1.3 (Composer XE 2013 Update 5).

[Gerard_G_]

Thanks Steve. I'll report back once I've got the compiler upgraded and tested again.

[Steven_L_Intel1]

I can reproduce it with the latest compiler, but do need all the sources.

[Gerard_G_]

Hi Steve. Many thank for taking a look at this. I have attached all the sources files for those modules.

[Gerard_G_]

I have another internal compiler error from ifort for the same project. This time I am using Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 13.1.3.192 Build 20130607

I have attached all the files. To reproduce type:

ifort -I./ -c Divergence_Matrix_CV.F90

[TimP]

I see the compiler segfaulting even at -O0 in 2 recent versions.  But I have to hunt around to see if you provided missing sources in any previous downloads.

[Gerard_G_]

Apologies for missing files. I was trying to have a minimum set for clarity as the dependencies are non trivial. All the files are accessible here: http://bazaar.launchpad.net/~fluidity-core/fluidity/dev-trunk/files

[Steven_L_Intel1]

Sorry, there are just too many sources missing for me to work on this. I went to the web site you link to, but there are dozens of folders with names that don't suggest where to find the missing sources.

Please create a separate directory with all the sources needed to reproduce the problem, and a makefile that doesn't use -I to bring in external modules or include files. Zip that up and attach it here.

[Gerard_G_]

This is now a kitchensink complete test that should show both bugs. Just untar this and type `make`. It should fail with an internal compiler error when compilering Divergence_Matrix_CV.F90. To reproduce the "-C" error, just edit Makefile and uncomment the line with FCFLAGS=-C; make clean; make. In this second case you will see that it fails with an internal compiler error when compiling Global_Numbering.F90.

Many thanks for all your time on this.

[Steven_L_Intel1]

Thanks for the sources.

There are two different problems here. The one in Global_Numbering.F90 is triggered by -check pointer (included in -C) and the use of the very complicated specification expression in function Common, and is fixed in our version 14 compiler due out in September. The Divergence_Matrix_CV.F90 issue is very different and I am investigating that.

[Gerard_G_]

Is the root of the problem understood? We would be quite happy with a workaround for now if we knew what was triggering the problem.

Gerard

[Steven_L_Intel1]

There are several problem here - we're working through them.  If we find workarounds we'll let you know.

[Rhodri_D_]

Hi Steve,

Do you have any further update on the situation with the compiler issues discussed above? Fluidity has over 500 users globally. Due to compiler errors, we are unable to compile the code with anything more recent that intel version 11.1.073. As you know, this version is now several years old and, accordingly, it is not available on a number of clusters used by our users. Our inability to use the intel compiler (and several of the associated profiling tools etc...) is starting to become a real pain.

Best wishes,

Rhodri

[Steven_L_Intel1]

I don't have any news for you yet - when I do I will let you know.

[Rhodri_D_]

Hi Steve,

I have now tried compiling the reproducer that Gerard gave you on intel version 14.1.106. There is a new issue (!), with the build failing in Fields_Manipulation.F90 (i.e. before Divergence_Matrix_CV.F90 - which means we can't test whether or not the previously reported issue is fixed). The error is copied below - is there any chance you could give an update on the status of the previous bug and try to resolve this new one?

These intel issues have been going on for an awfully long time and we'd like to get them fixed (as I'm sure would you). I think a good start would be for you to tell us that the reproducer can be compiled (and on what version of intel) - we can then test the remainder of the code to see if other issues crop up.

In the longer term, perhaps this reproducer could form a part of your internal test suite - we have noticed, in the past, that issues that you fix, suddenly reappear in later versions - naturally we're keen that this doesn't continue to happen.

Here is the error:

Fields_Manipulation.F90(29): warning #6738: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-name.   [ELEMENTS^ALLOCATE_ELEMENT]
use elements
----^
Fields_Manipulation.F90(29): warning #6738: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-name.   [ELEMENTS^ALLOCATE_ELEMENT_WITH_SURFACE]
use elements
----^
Fields_Manipulation.F90(29): warning #6738: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-name.   [ELEMENTS^ALLOCATE_CONSTRAINTS_TYPE]
use elements
----^
Fields_Manipulation.F90(29): warning #6738: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-name.   [ELEMENTS^DEALLOCATE_ELEMENT]
use elements
----^
Fields_Manipulation.F90(29): warning #6738: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-name.   [ELEMENTS^DEALLOCATE_CONSTRAINTS]
use elements
----^
Fields_Manipulation.F90(29): warning #6738: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-name.   [ELEMENTS^INCREF_ELEMENT_TYPE]
use elements
----^
Fields_Manipulation.F90(29): warning #6738: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-name.   [ELEMENTS^HAS_REFERENCES_ELEMENT_TYPE]
use elements
----^
Fields_Manipulation.F90(2330): error #8032: Generic procedure reference has two or more specific procedure with the same type/rank/keyword signature.   [DEALLOCATE]
    call deallocate(shape)
---------^
Fields_Manipulation.F90(2351): error #8032: Generic procedure reference has two or more specific procedure with the same type/rank/keyword signature.   [DEALLOCATE]
    call deallocate(shape)
---------^
Fields_Manipulation.F90(3591): error #8032: Generic procedure reference has two or more specific procedure with the same type/rank/keyword signature.   [INCREF]
      call incref(output_mesh%faces%shape)

Best wishes,

Rhodri

[Steven_L_Intel1]

Rhodri, I noted above that there were still various issues compiling this package. I did not say that all issues had been resolved. This program is proving difficult to diagnose as the symptoms change as we look at it. We will get to the bottom of it, but I don't think it will be soon.

We do have an extensive regression suite and every program submitted as a problem report is added to it.

[Steven_L_Intel1]

We made some good progress on this today. The hard part has been that when we do the build, we see other errors (including the ones Rhodri mentions.) One bug has been identified and a fix is in progress, the other I have a smallish reproducer for. We have workarounds for both:

1) In Global_Parameters.F90, where various character fields are initialized to "", change these to a blank (" ").

2) In Fields_Manipulation.F90, change the name of the elements component of patch_type to something else - I used elementsx - and then change the references in that source and in Field_Derivatives.F90.

With these edits, then the segfault can be reproduced and we can get a handle on what is going on there.

[Rhodri_D_]

Thanks for the update Steve. If there's anything we can do to help then let us know. Naturally, the sooner we can get to the bottom of this the better.

Happy new year.

Rhod

[Steven_L_Intel1]

Rhodri and Gerard, we believe that we have fixed all the problems this program demonstrated. I expect the fix to appear in Update 3, scheuled for late April. Thanks for providing all the sources.

[Gerard_G_]

That's great news. I look forward to playing with it. Thanks for all your efforts on this.