catastrophic error: segfault in compilation

catastrophic error: segfault in compilation

Bild des Benutzers ereisch
ereisch
Do, 06/09/2012 - 10:10

Previously was using composerxe-2011.4.191 with the same arguments, and no errors/issues were encountered compiling this file.

ifort -extend-source 132 -assume nounderscore -assume nobscc -align dcommons -static-libgcc -zero -fp-port -save -c -fpe0 -ftz -prec-div -fp-stack-check -ccdefault fortran -traceback -fp-model precise -xSSE2 -axSSE2 -g -debug full -debug-parameters -check bounds -O0 -gen-interfaces -module /tmp/.mod -I/usr/src/project/.mod -warn interfaces -m32 -I/tmp/text hit.for -o obj/hit.o

hit.for: catastrophic error: **Internal compiler error: segmentation violation signal raised** Please report this error.........

compilation aborted for hit.for (code 1)

I'm trying to narrow down the exact combination of factors in the file that cause the error, but in the meantime, is there an environment variable I can set that will give me more detail from the compiler?

Using version 12.1.5.339 Build 20120612

RSS Oben
6 Beiträge / 0 neu
Letzter Beitrag
Nähere Informationen zur Compiler-Optimierung finden Sie in unserem Optimierungshinweis.
Bild des Benutzers Udit Patidar (Intel)
  • Zum Verfassen von Kommentaren bitte anmelden.
Udit Patidar (Intel)
Do, 06/09/2012 - 11:39

The segmentation fault internal compiler error usually indicates something unexpected was encountered during compilation. Without a reproducing source file hit.for, it is difficult to pinpoint which part of the compiler is at fault. Is it possible to attach that?
You could try removing -gen-interfaces -warn-interfaces and play with -g /debug switches to see if those could be causing the internal error.

Oben
Bild des Benutzers ereisch
  • Zum Verfassen von Kommentaren bitte anmelden.
ereisch
Do, 06/09/2012 - 11:58

I'm trying to narrow down the combination of data in the file that is causing the error, but it is very unpredictable. I have removed all of the arguments that handle prototype checking, as well as the bulk of the code in the source file in question, and it still segfaults. The interesting thing is that when I remove a line that does a simple L = VAR1(X).FOO(Y), it compiles fine, but when I re-insert that line back in and remove a couple other lines above it, it also compiles fine. Removing other sections of the file seem to randomly make the problem go away and re-appear as well.

I also checked, and the issue happens on both 32 and 64-bit systems.

Oben
Bild des Benutzers jimdempseyatthecove
  • Zum Verfassen von Kommentaren bitte anmelden.
jimdempseyatthecove
Fr, 07/09/2012 - 08:36

>> L = VAR1(X).FOO(Y)

As an experiment try using the official "%" member variable separator instead of the IVF optional "." member variable seperator. "." is officially used as an operator prefix and suffix (.OR., .true.). I have experienced similar cases where the compiler gets confused as to if this is a member variable seperator as opposed to operator prefix.

Jim Dempsey

Blog: The Parallel Void

www.quickthreadprogramming.com
Oben
Bild des Benutzers ereisch
  • Zum Verfassen von Kommentaren bitte anmelden.
ereisch
Fr, 07/09/2012 - 09:40

I went through the subroutine and replaced all instances of the "." separator with "%", and it's still segfaulting.

Oben
Bild des Benutzers jimdempseyatthecove
  • Zum Verfassen von Kommentaren bitte anmelden.
jimdempseyatthecove
Fr, 07/09/2012 - 15:17

I've seen another old report on this forum relating to compiler crash that occured on a source file that was generated by a program. The generated source file was huge (100's of 1000's of lines). Is hit.for a huge source file?

Also, try renaming hit.for to hit.f90 then try compiling it using the new name omitting "-extend-source 132" to see what happens.

Jim Dempsey

Blog: The Parallel Void

www.quickthreadprogramming.com
Oben

Melden Sie sich an, um einen Kommentar zu hinterlassen.