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 188.8.131.521 [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.
I have been following an example in the book Guide to Fortran 2008 programming
type, public :: matrix(rows, cols, k)
integer len :: rows, cols
integer, kind :: k =kind(0.0)
real(kind = k), dimension (rows, cols) :: values
end type matrix
type (matrix =:, cols=:, k=kind(0.0)) = double) :: A
According to the technical support people len can only be used to specify the length of character strings. But, as you see in the above example that is not what they are doing.
A length type parameter can be used for array bounds or character lengths. The main difference between a length type parameter and a kind type parameter is that the latter is a constant and the former is evaluated at run-time when the procedure is entered. Support people aren't always current on the language, unfortunately, and PDTs, while they have been supported in Intel Fortran for a long time now, are not familiar to many.
As I wrote above, the syntax error was from your introduction of SEQUENCE in the wrong position. It is unrelated to the ICE.
If you get the punctuation wrong even slightly, the result can be an error message that is not easy to understand. The book "Guide to Fortran 2008 Programming" by Brainerd contains some typographical errors in the relevant pages.
Here is the matrix example, massaged to make it acceptable to the Intel 2020U2 compiler:
program tst type :: matrix(rows, cols, k) integer, len :: rows, cols integer, kind :: k =kind(0.0) real(kind = k), dimension (rows, cols) :: values end type matrix type (matrix(2, 3, k=kind(0.0))) :: A A%values = reshape([(i*0.5,i=1,6)],[2,3]) do i=1,2 print '(3F8.4)',A%values(i,:) end do end program
You omitted the comma between integer and len .
Since I know my book is not strictly correct. I was looking at the statement that they have for allocating derived type and this is what they have:
type(matrix(rows=:, cols-:, k=kind(0.0)), allocatable :: A
I know the number of parentheses is not correct and I fixed that. The problem is when I allocate A I get a compiler error. I want to allocate it by passing in variables.
Are you using copy and paste? Or retyping your statement?
type(matrix(rows=:, cols-:, k=kind(0.0)), allocatable :: A ------------------------^ Should be =
Also, I am not an expert on parameter'd derived types, but I believe the parameters need to be parameters.
Can you explain what you are attempting to do?
What I am trying to do is eliminate the need to have 2 different executables of our modeling system. One variation can do a full model and the other does a small initial run to create data to do the larger run.
When the application was created memory use was limited, so they used a compiler directive with 2 sets of parameters and tested to see which executable was being built and used that set. I would like to be able to make use of a new parameter that flags the type of run and then create the arrays and types with the size needed based on the table of parameters.
If we could do the above we could have just one executable.
I typed in the one line, so that is definitely my mistake posting.
I will have to take a look at that closely as we have 50 or so configuration limits. But, the number that are build dependent are a lot less than that.
We definitely have structures that change size based on the build type. That is why I was interested in the parameter derived types..
PDTs do generally work in Intel Fortran, which is not something I can say for gfortran (the main gfortran developer recommended avoiding PDTs when using that compiler.) But obviously there are still bugs. If you have not already, please submit a test case to Intel Support about the ICE.
There is a bug report, CMPLRIL0-33130
and an OSC issue 04735259.
the ICE is in 19.0.x.
and not 19.1.x nor the ifort in 2021.1 beta in oneAPI HPC Toolkit
Regarding the code sample in Walt's 'Guide to Fortran 2008 Programming' and other books - when the authors start to write these while the Standard is not fully ratified (but very close) and there are no fully compliant compilers. I know Walt was doing as much early testing as he could for this one. He usually used NAG for early testing like this. Once the text is published and printed it's difficult to convince publishers to cut a new edition just to correct a few typos. I'm sure it's similar for other authors and their books.
are you using the original code, or did you fix the sequence placement for override$_data ? I am using the original:
type override$_data(num_elements, num_groups) sequence 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 end type
Also, I'm testing on mac and Linux - wondering if the Windows compiler would differ. My -what option returns:
Intel(R) Fortran 19.1-1648
Perhaps you can attach your zip. I've attached my reproducer with simplified names and 2 mod files, build.sh to invoke and compile.
A number of file archivers and archive extractors can process gzipped tar files on Windows.
I ran Ron's examples on Windows 10, using the current 19.1U2 compiler.
Q:\lang\RGreen\repro>ifort /Od /what /c mod2.f90 Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 2021.1.2.254 Beta Build 20200623 Copyright (C) 1985-2020 Intel Corporation. All rights reserved. Intel(R) Visual Fortran 19.1-1648 mod2.f90(13): error #8912: The type parameter declaration is incorrectly positioned within the derived-type definition. [NUM_ELEMENTS] integer*4, len :: num_elements, num_groups -------------------------^ mod2.f90(13): error #8912: The type parameter declaration is incorrectly positioned within the derived-type definition. [NUM_GROUPS] integer*4, len :: num_elements, num_groups ---------------------------------------^ mod2.f90(32): error #7002: Error in opening the compiled module file. Check INCLUDE paths. [OVERRIDE] use override ----^ mod2.f90(215): error #6457: This derived type name has not been declared. [OVERRIDE$_DATA]
@Ron_Green Minimal example
D:\Projects\Console1\Console1>type bonddefinition.f90 module override type override$_data(num_elements, num_groups) integer*4, len :: num_elements, num_groups integer*4, dimension(num_elements) :: number_tables integer*4, dimension(num_groups) :: first end type integer, public :: MS_ ! maximum number of bond series, must be odd! integer, public :: MTBG_ ! maximum total bond groups for dsg arrays, bond tic = average of 5 groups for 40 series end module override module bond_definition use override type , public :: b$$s integer*4 nbs type (override$_data (num_elements= ms_, num_groups=mtbg_) ):: over end type type (b$$s) :: b$s end module bond_definition D:\Projects\Console1\Console1>ifort -c bonddefinition.f90 Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 184.108.40.206 Build 20200623 Copyright (C) 1985-2020 Intel Corporation. All rights reserved. Internal error store_pdtlen_data_space: Cannot find record bonddefinition.f90: 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. compilation aborted for bonddefinition.f90 (code 1)
When it comes to "Fortran community", you may want to consider participating in a growing one at https://fortran-lang.discourse.group/ where you can get further guidance on your code modernization effort. There is also comp.lang.fortran newsgroup.
yes, the bug is of course still open. For the bug I have to tag it with a Forum ID or a OSC issue id or both. I find it easiest to use 1 target origin. That way when the bug is fixed I have but 1 place to report the fix. Given the interest in this here, I decided the community would like to hear when a fix is ready.