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

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

Gerard G.'s picture

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.

AttachmentSize
Download bug.tar.gz251.25 KB
24 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.
Steve Lionel (Intel)'s picture

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).

Steve
Gerard G.'s picture

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

Steve Lionel (Intel)'s picture

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

Steve
Gerard G.'s picture

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

Attachments: 

AttachmentSize
Download bug-source.tar.gz129.89 KB
Gerard G.'s picture

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

Attachments: 

AttachmentSize
Download bug2.tar.gz1.57 MB
Tim Prince's picture

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.'s picture

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

Steve Lionel (Intel)'s picture

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.

Steve
Gerard G.'s picture

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.

Attachments: 

AttachmentSize
Download sourcesmakefile.tar.gz416.87 KB
Steve Lionel (Intel)'s picture

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.

Steve
Gerard G.'s picture

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

Steve Lionel (Intel)'s picture

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

Steve
Rhodri D.'s picture

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

Steve Lionel (Intel)'s picture

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

Steve
Rhodri D.'s picture

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

 

 

Steve Lionel (Intel)'s picture

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.

Steve
Steve Lionel (Intel)'s picture

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.

Steve
Rhodri D.'s picture

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

Steve Lionel (Intel)'s picture

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.

Steve
Gerard G.'s picture

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

Rhodri D.'s picture

Hi Steve,

As Gerard said - a huge thank you for your efforts here. I have a few remaining questions: will the fix released with update 3 also include fixes for the issues occurring in Global_Parameters.F90 and Fields_Manipulation.F90? Or will we still need the following workarounds?

1) In Global_Parameters.F90, where various character fields arenitialized 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.

Can I also check that the test case Gerard provided will be added to your test suite (or that you guys have at least added unit tests of your own to check that these issues don't reoccur)? We'd find this extremely beneficial in the long-term.

Best wishes and thanks again,

Rhod

Steve Lionel (Intel)'s picture

Yes, Update 3 should fix all these issues. Yes, we added it to our regression test suite.

Steve
Rhodri D.'s picture

Great stuff. Thanks Steve.

Rhod

Login to leave a comment.