I have recently tried upgrading from solaris studio 12.2 to 12.3 under 64-bit linux, with the bundled upgrade of Fortran from f95 8.5 to 8.6.
I have been using sunf95 12.2 to compile a large electronic structure simulation code (CASTEP)
However with 12.3 the compile fails consistently on several modules with
"INTERNAL: Interrupt: Segmentation fault"
The segfault occurs instantaneously at the very beginning of the compile in "f90comp", (see below).
It does appear to be, at least in part, something to do with internal table sizes and stack overflow.
For many of the modules, the compiler segfaults can be avoided by increasing the shell stack limit
(ulimit -s 131072) or removing the "-g" option from the compiler command line (and thereby presumably
decreasing some symbol table sizes).
However there are some modules which will not compile even under -O0 without -g and with stack limit unlimited.
Is there any compiler option magic to tweak symbol table sizes or provide better diagnostics?
$ time sunf95 -v -c -xO0 ../../Source/Fundamental/wave.f90
### f90: Note: NLSPATH = /opt/intel/composer_xe_2011_sp1.11.339/compiler/lib/intel64/locale/%l_%t/%N:/opt/intel/composer_xe_2011_sp1.11.339/ipp/lib/intel64/locale/%l_%t/%N:/opt/intel/composer_xe_2011_sp1.11.339/mkl/lib/intel64/locale/%l_%t/%N:/opt/intel/composer_xe_2011_sp1.11.339/debugger/intel64/locale/%l_%t/%N:/opt/ekopath-2013-05-30/lib/3.1/%N.cat:/usr/share/locale/%l/%N:/opt/oracle/solarisstudio12.3/prod/bin/../lib/locale/%L/LC_MESSAGES/%N.cat:/opt/oracle/solarisstudio12.3/prod/bin/../../lib/locale/%L/LC_MESSAGES/%N.cat
### f90: Note: TMPDIR = /tmp
### command line files and options (expanded):
### -v -c -xO0 ../../Source/Fundamental/wave.f90
/opt/oracle/solarisstudio12.3/prod/bin/f90comp -m3 -ev -dq -xall -xivdep=loop -H "/opt/oracle/solarisstudio12.3/prod/bin/f90 -v -c -xO0 " -I/opt/oracle/solarisstudio12.3/prod/include/f95/amd64 -p/opt/oracle/solarisstudio12.3/prod/lib/modules/amd64 -xarch=amd64 -y-xarch=amd64 -xmemalign=1i -xvector=simd -iorounding=processor-defined -xhasc=yes -Oscalar0 -Otask0 -y-O0 -xcache=generic -y-xcache=generic -y-xassume_control=optimize -xassume_control=optimize -fstore -y-xdbggen=no%stabs+dwarf2 -y-ir -y/tmp/f90comp.1382696881.26710.01.ir -y-sd -y/tmp/f90comp.1382696881.26710.02.sd ../../Source/Fundamental/wave.f90
"../../Source/Fundamental/wave.f90", Line = 1, Column = 1: INTERNAL: Interrupt: Segmentation fault
I did attempt to run the f90comp process under "valgrind". In that case the compile succeeded, with no obvious fatal "invalid write" being signalled,
and the compile ran to a normal completion and apparently succeeded, and wrote the ".sd" and ".ir". files. There were several "invalid reads" from free'd blocks,
and overrunning an allocation (usually by 1 byte).
Any suggestions of where to go from here will be welcome.
We had a problem in compiling large modules containing many module procedures since the symbol tables for the module procedures got accumulated and would not be released until the end of the whole module. This has already been rewritten to remove the problem completely in the next release.
For now, these are steps that you can do to reduce the numbers of symbols and avoid the overflow:
- If many module procedures have a "USE FOO" statement, you should have a single USE FOO statement at the top of the module and remove the rest. The module procedures can still access the symbols in module FOO by host association but it will not result in the replication of the same symbols.
- If you only use a small number of symbols in a large module, then you can limit the number of imported symbols by doing USE FOO, ONLY and list the symbols that you actually need.
Hope that helps
If you have a support contract, please have your support representative file a defect report. If you do not have a support contract, please get in touch with me at firstname.lastname@example.org.
The compiler does have limited size tables, but it also does a good job of checking when those table sizes are exceeded. Because your program fails with a segmentation violation, I doubt that the problem is a table overflow. The biggest help for finding the bug would be if you could produce a source file that demonstrates the bug that we could have. Barring that, you could try running f90comp under dbx. If you can get a stack traceback, it would help a lot.
Ah, yes. That is an extremely good description of the character of the code - large modules containing many subroutines, each with "use, only" of the same file.
And indeed removing the "use" statements from the individual subroutines and aggregating them at the module level does avoid the segfault. So this sounds like a similar issue.