Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
27 Views

Compiler Bug (missing symbol / ICE) in ifort 16.0.3 on Linux 64

Jump to solution

Dear Intel support team

When I compile the attached example with "debugging" flags I obtain an ICE.
With "release" flags it compiles fine, but at least one (required!) symbol is missing in the generated object file

I also added a version where I removed an another subroutine which makes everything work fine.

I tried to attach all required module files generated on Linux 64: 518369

Regards

Melven

Detailed output:

> tar xJf intel_bug.tar.xz
> cd intel_bug/
intel_bug> cat compile.sh
echo version
ifort -V

echo "test_abstract_config_.F90 works:"
ifort  -DDOUBLE -DHAVE_LONG_LINES -DHAVE_PREPROCESSOR_STRINGIFICATION -DINTEL -DUSE_MPI -DUSE_OPENMP -I./include  -fpp -std08 -diag-disable=5268 -diag-disable=5462 -assume norealloc_lhs -mkl -O3 -xHOST   -real-size 64 -double-size 64 -qopenmp -assume realloc_lhs -c test_abstract_config_.F90 -o test_abstract_config_.F90.o
echo "expecting: 000000000000bc90 T test_abstract_config_suite_"
nm test_abstract_config_.F90.o | grep "T test_abstract_config_suite"

## differs only in another subroutine, see
#diff test_abstract_config_.F90 test_abstract_config.F90

echo "test_abstract_config.F90 fails (missing symbol!):"
ifort  -DDOUBLE -DHAVE_LONG_LINES -DHAVE_PREPROCESSOR_STRINGIFICATION -DINTEL -DUSE_MPI -DUSE_OPENMP -I./include  -fpp -std08 -diag-disable=5268 -diag-disable=5462 -assume norealloc_lhs -mkl -O3 -xHOST   -real-size 64 -double-size 64 -qopenmp -assume realloc_lhs -c test_abstract_config.F90 -o test_abstract_config.F90.o
echo "expecting: 000000000000bc90 T test_abstract_config_suite_"
nm test_abstract_config.F90.o | grep "T test_abstract_config_suite"

echo "test_abstract_config.F90 with debug flag fails (ICE):"
ifort  -DDEBUG -DDOUBLE -DHAVE_LONG_LINES -DHAVE_PREPROCESSOR_STRINGIFICATION -DINTEL -DUSE_MPI -DUSE_OPENMP -I./include  -fpp -std08 -diag-disable=5268 -diag-disable=5462 -assume norealloc_lhs -mkl -warn all -g -O0 -traceback -check all -check noarg_temp_created   -real-size 64 -double-size 64 -qopenmp -assume realloc_lhs -c test_abstract_config.F90 -o test_abstract_config.F90.o
echo "expecting: 000000000000bc90 T test_abstract_config_suite_"
nm test_abstract_config.F90.o | grep "T test_abstract_config_suite"

intel_bug> sh compile.sh
version
Intel(R) Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0.3.210 Build 20160415
Copyright (C) 1985-2016 Intel Corporation.  All rights reserved.

test_abstract_config_.F90 works:
fpp: warning: keyword redefined: DOUBLE
expecting: 000000000000bc90 T test_abstract_config_suite_
000000000000bc90 T test_abstract_config_suite_
test_abstract_config.F90 fails (missing symbol!):
fpp: warning: keyword redefined: DOUBLE
expecting: 000000000000bc90 T test_abstract_config_suite_
test_abstract_config.F90 with debug flag fails (ICE):
fpp: warning: keyword redefined: DOUBLE
/tmp/ifort70yPuT.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 test_abstract_config.F90 (code 1)
expecting: 000000000000bc90 T test_abstract_config_suite_
nm: 'test_abstract_config.F90.o': No such file

 

0 Kudos

Accepted Solutions
Highlighted
Employee
27 Views

I can reproduce the error. The internal error triggers related to the -warn all option, specifically the inclusion of the Interface warnings (i.e. -warn interfaces). The error is avoidable by expanding -warn all to the equivalent longer form and eliminating “interfaces”. This syntax enables the equivalent warnings sans interfaces:

-warn alignments,general,usage,declarations,ignore_loc,interfaces,stderrors,truncated_source,uncalled,unused,usage

Unfortunately I could not find a more convenient command-line syntax to enable compile-time warnings w/o interfaces that avoids the internal error.

Thank you for your time/effort in creating the convenient reproducer. I escalated this to Development and will keep the post updated on progress of a fix. I may have to request additional source files from you for some or all the .mod files you provided. I will await word from Development about that.

(Internal tracking id: DPD200413371)

View solution in original post

0 Kudos
6 Replies
Highlighted
Beginner
27 Views

I just noticed that to workaround this bug I can also comment out / remove (any) other test subroutine (marked with @test)...

0 Kudos
Highlighted
Employee
27 Views

Thank you for the test case. I will look into it.

0 Kudos
Highlighted
Employee
28 Views

I can reproduce the error. The internal error triggers related to the -warn all option, specifically the inclusion of the Interface warnings (i.e. -warn interfaces). The error is avoidable by expanding -warn all to the equivalent longer form and eliminating “interfaces”. This syntax enables the equivalent warnings sans interfaces:

-warn alignments,general,usage,declarations,ignore_loc,interfaces,stderrors,truncated_source,uncalled,unused,usage

Unfortunately I could not find a more convenient command-line syntax to enable compile-time warnings w/o interfaces that avoids the internal error.

Thank you for your time/effort in creating the convenient reproducer. I escalated this to Development and will keep the post updated on progress of a fix. I may have to request additional source files from you for some or all the .mod files you provided. I will await word from Development about that.

(Internal tracking id: DPD200413371)

View solution in original post

0 Kudos
Highlighted
Beginner
27 Views

Thank you for your fast replay.

In your line above you accidently kept the interfaces flag; it should be:

-warn alignments,general,usage,declarations,ignore_loc,stderrors,truncated_source,uncalled,unused,usage

With this workaround the ICE is not triggered any more, however the required symbol is still missing in the output for me!

0 Kudos
Highlighted
Employee
27 Views

The missing symbol case took some work, and I managed to whittle the test case down further. I can’t explain the cause of the malfunction but something leads the compiler to confuse the membership of the function in question. In the failing case the function becomes decorated as a module-procedure from MODULE MPICONTEXT_MOD. Thus, you will find the routine present in the object, but with a different decorated name:

$ nm test_abstract_config.F90.o | grep "test_abstract_config_suite"
0000000000009d10 T mpicontext_mod_mp_test_abstract_config_suite_
0000000000000160 d mpicontext_mod_mp_test_abstract_config_suite_$BLK.var$214629
000000000000a2a0 B mpicontext_mod_mp_test_abstract_config_suite_$BLK.var$214687

I submitted this case to Development (under internal tracking id below). While I eliminated additional code and USE statements, the complexity and inner-relationship of your app’s modules prevented trimming any .mod files from those provided. Generally our Developers require source for modules used; however, let’s wait and see if those are needed for this case.

As for a work around, perhaps you could move the affected function’s definition to a separate source file. I will let you know if Development offers any other work around.

(Internal tracking id: DPD200413475)

0 Kudos
Highlighted
Employee
27 Views

Development notified me that they do require source for your mod files to continue investigating of the case of the missing symbol. Is it possible we can obtain the corresponding source files?

0 Kudos