I know that my compiler is licensed, but I am not sure if we are paid for support. I just got a compiler failure trying to use parameterized derived types. I am going to attach the build log, which is very short. This is just a proof of concept program.
Compiling with Intel(R) Visual Fortran Compiler 184.108.40.2061 [IA-32]... ifort /nologo /debug:full /Od /fpp /extend_source:80 /warn:none /module:"Debug\\" /object:"Debug\\" /Fd"Debug\vc150.pdb" /traceback /check:bounds /check:stack /libs:dll /threads /dbglibs /c /Qlocation,link,"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\bin\HostX86\x86" /Qm32 "C:\Michael\params_test_2\Console1\Console1\bonddefinition.f90" C:\Michael\params_test_2\Console1\Console1\$OVERRIDE.fi(29): catastrophic error: **Internal compiler error: internal abort** 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. Internal error store_pdtlen_data_space: Cannot find record compilation aborted for C:\Michael\params_test_2\Console1\Console1\bonddefinition.f90 (code 1) test_params_2 - 1 error(s), 0 warning(s)
I could not attach the html file. So I just added the text.
**Internal compiler error is a bug even if your code is non-conforming.
You should file a ticket or if that is not possible post a source file that reproduces here
and someone will take it up.
Here is some simplified code.
The following code is in an include file. Call it test.fi
module called param.mod
integer ms_ = 21
A module for this case called test.mod contains the following
type , public :: b$$s
type (override$_data (num_elements= ms_) ):: over
public :: set_parameters
Your code above is non-standard e.g., #include directive when Fortran language supports INCLUDE statement with its own rules for syntax: see this. It also looks incomplete: what is 'override$_data' in your TYPE declaration in the module named 'test'. Intel Fortran can very well find it impossible to process what you show and throw an "internal compiler error" in response i.e., unless you have specified just the right combinations of options and steps to make it work e.g., preprocessor instructions. Otherwise one can't blame ifort for suffering from an ICE with your code.
It'll be rather difficult, if not impossible, for you to get any useful guidance given your posts here. Your posts do suggest you can help yourself greatly by reviewing closely a few textbooks on Fortran, say Chapman's latest edition on Fortran for Scientists and Engineers.
Here are some facts regarding internal compiler errors that are worth noting.
- Whether you are eligible for paid support or not, ICEs are worth reporting: through Intel support if you are eligible, in this forum if not.
- ICEs are unexpected. They can be very hard to reproduce without the exact code that you were using when you encountered an ICE. Small changes to the test code, changing the compiler version or the compiler options can make the ICE disappear. This is why it is useless to present a precis, a purely verbal description or fragments of code.
- In order to preserve the ICE, you should zip up the code and attach that zip file to a reply. Posting code here inline or in a code box, except for purposes of discussion, does not help much because copy-pasting code may change the code and make the ICE disappear, or cause a different ICE to occur than the one that you experienced.
- It is good practice to copy the entire file set associated with the ICE to a fresh directory on the same or a different PC and try to duplicate the ICE yourself (or by a colleague). If you do this, you will discover all the little pieces (such as include files) that are needed to reproduce the ICE but you forgot to include in the zip archive.
Sorry for the delay, I am always running the latest Intel Sources and the latest 2019 VS Preview -- I have to maintain computers all over the place -- I need one that always breaks first -- it is a lot better than the one in Iowa breaking --
it is easy to fix on the desk - not 180 feet in the air on a bridge
The latest Intel update required me to remove all of the intel programs and then start form scratch with the tuner first.
I downloaded params_test_2.zip and with a few cosmetic edits (eg #include to include and end type xxx), I got a compiled version of test_params.exe to run with gFortran 9.2.0.
Interesting, it accepts "sequence" before "integer, len ::", but not after, reporting:
13 | sequence
Error: SEQUENCE statement at (1) must precede structure components
Not sure what the correct order is.
Also, I am not sure if parameterized derived type is needed in my subset of Fortran.
This code example features extensive use of "integer, public ::". I don't see any benefit from this approach.
Is this a style that is being encouraged by F08 and F18 ?
@John_Campbell The extensive use of public in that module is rather superfluous given that public is the default status. Adding a single "public" in the module header would have achieved the same result. It can often makes sense to add "private" in the module header so that makes everything private by default and add public to only those items you wish to be used or modified external to the module.
This in my mind does two things. If you blanket "USE" the module i.e. without the ONLY clause you don't pollute the namespace with lots of unnecessary variable names. And secondly it shows the intent of the coder as to what a users "interface" with the module is meant to be thus keeping things clearer and simpler. I think such approaches lead to more maintainable and less buggy code.
That is my take on that subject but I am sure there are other views.
The bug ID is CMPLRIL0-33130
The code has a number of syntax errors. Granted, it should not cause an internal error. that is a bug in the compiler. Our recommendation is to install the latest PSXE 2020 compiler which will show you the syntax errors that you can repair to continue your development. A fix in PSXE 2019 would take too long to get to you.
Start with this error
type override$_data(num_elements, num_groups)
integer*4, len :: num_elements, num_groups
type (date$_set) ride(mkd_)
integer*4, dimension(num_elements) :: number_tables
integer*4 padding ! ms_ is odd number
integer*4, dimension(num_groups) :: first
integer*4, dimension(num_groups) :: length
integer*4, dimension(num_groups) :: start_date
integer*4, dimension(num_groups) :: basis
integer*4, dimension(num_groups) :: group
integer*4, len :: num_elements, num_groups
LEN is out of position or is not an attribute of INTEGER types. Check this syntax with your book. What book are you using? If you are new to Fortran this seems a very ambitious program to start with.
Ignoring for the moment your use of nonstandard syntax such as integer*4, the immediate problem with that type definition is that the standard requires SEQUENCE, if present, to follow type parameter declarations. So move the SEQUENCE after the declaration of the LEN parameters.
If I do that, I get an ICE - that's definitely a compiler bug.
If I remove the SEQUENCE entirely, then I get the (appropriate) error that it has to be SEQUENCE because it includes a SEQUENCE type component.
But if I then remove all SEQUENCE lines from the code, then I still get the ICE. So the bug is not related to SEQUENCE.