|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
ahalls_dsc
Joined: 12 Nov 2018 Posts: 16
|
Posted: Fri Aug 30, 2019 11:50 am Post subject: [ADVICE] /OPT with /64 - Internal Compiler Error |
|
|
When running /64 /OPTIMISE compilation, I'm getting various floating point exception internal compiler errors cropping up. When running /64 /FU, compilation works.
As a relative beginner, I'm trying to get an idea of how/whether to deal with these, so have some questions:
1. Is there a comprehensive list of compiler optimisations, in relatively plain English, for me to study?
2. When /OPT compilation is done, what are some of the most frequent issues arising?
3. Is the issue I'm seeing (ICE FPE) common, or is it something that would be worth putting into a minimally reproducible example for the forum? |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Fri Aug 30, 2019 12:03 pm Post subject: |
|
|
Please provide a simple example of the failure and then we can work from that. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2560 Location: Sydney
|
Posted: Fri Aug 30, 2019 1:15 pm Post subject: |
|
|
Hopefully the source of teh problem is unidentified coding bugs.
If there are bugs in your program, /OPT is more likely to find them.
Try using /CHECKMATE and see what happens then. This can help with identifying those annoying bugs. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1892
|
Posted: Fri Aug 30, 2019 6:11 pm Post subject: |
|
|
To ahalls_dsc:
Are you getting errors during compilation and/or linking, or are you getting errors when you run the EXE that got built?
Only the former can be called ICE, and their occurrence should be reported along with the source files being compiled.
On the other hand, if an EXE gets built the errors occur when that EXE is run, those are not internal compiler errors. Floating point errors that arise when your EXE is run can be caused by bugs in the code generation process, but more often such bugs arise in the user's code.
It is not possible to give you a list of conditions that lead to ICEs. These are errors that are not expected at all, and need considerable study when they occur. In fact, such conditions are nearly impossible to reproduce based on a mere description of the program. A full bug report is needed with all the information that is relevant: compiler version, OS details, CPU, memory available, complete source code and related files, instructions to build and run, and any data files that are needed. |
|
Back to top |
|
|
ahalls_dsc
Joined: 12 Nov 2018 Posts: 16
|
Posted: Fri Aug 30, 2019 8:53 pm Post subject: |
|
|
Thanks all.
It is likely errors in the code; definitely an ICE as it occurs when compiling.
Will get something together. Watch this space. |
|
Back to top |
|
|
ahalls_dsc
Joined: 12 Nov 2018 Posts: 16
|
Posted: Fri Aug 30, 2019 10:18 pm Post subject: |
|
|
The following code:
Code: | SUBROUTINE rdgenc_purp(jyr)
INTEGER,INTENT(IN) :: jyr
INTEGER,PARAMETER :: JAYEAR=803,JBYEAR=804,LXTZN=1714,
& MXNSEW=4,MXNCOT=4
REAL, DIMENSION(1:lxtzn,1:lxtzn,1:mxnsew,1:mxncot,JAYEAR:JBYEAR)
& :: gchowkswcoyr
gchowkswcoyr(:,:,:,:,jyr) = 1.0E05
ENDSUBROUTINE |
compiled thus:
Code: | ftn95 rdgenc_purp.for /64 /defint_kind 3 /deflog_kind 1 /no_com /optimise /im /mod_path \source\mods /cfpp /define DEBUG 0 |
produces the following compiler message in v8.51:
Code: | [FTN95/x64 Ver. 8.51.0 Copyright (c) Silverfrost Ltd 1993-2019]
Licensed to: Alistair Halls
Organisation: David Simmonds Consultancy
0005) REAL, DIMENSION(1:lxtzn,1:lxtzn,1:mxnsew,1:mxncot,JAYEAR:JBYEAR)
0006) & :: gchowkswcoyr
WARNING - Variable GCHOWKSWCOYR has been given a value but never used
*** Internal compiler error - floating point exception
1 ERROR [rdgenc_purp.FOR] - Compilation failed. |
Entirely possible that a) there are issues with the code, b) there are issues with the compiler options or c) both of the above...
NB the subroutine this is taken from is much larger, with various other USE and INCLUDE statements. The purpose is to read a specific subset of a data file, according to the parameters in the array which is causing the issue. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2560 Location: Sydney
|
Posted: Sat Aug 31, 2019 2:11 am Post subject: |
|
|
I don't have Ver 8.51 installed, but I suspect there is overflow in calculating the array offset.
( lxtzn * lxtzn * mxnsew * mxncot * JBYEAR = 37,791,807,744 )
Ver 8.4 does not fail for my test of your example.
Could you try the following adaptation. Code: | SUBROUTINE rdgenc_purp(jyr)
INTEGER,INTENT(IN) :: jyr
INTEGER,PARAMETER :: JAYEAR=803,JBYEAR=804,LXTZN=1714, &
& MXNSEW=4,MXNCOT=4
INTEGER,PARAMETER :: J0YEAR=JAYEAR-1
REAL, DIMENSION(1:lxtzn,1:lxtzn,1:mxnsew,1:mxncot,JBYEAR-J0YEAR) &
& :: gchowkswcoyr
gchowkswcoyr(:,:,:,:,jyr-J0YEAR) = 1.0E05
END SUBROUTINE |
|
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1892
|
Posted: Sat Aug 31, 2019 3:02 am Post subject: Re: |
|
|
JohnCampbell wrote: | I don't have Ver 8.51 installed, but I suspect there is overflow in calculating the array offset.
( lxtzn * lxtzn * mxnsew * mxncot * JBYEAR = 37,791,807,744 )
|
The array has its fifth dimension varying from JAYEAR to JBYEAR, not 1 to JBYEAR, so that you should have had (JBYEAR-JAYEAR+1) = 2 instead of JBYEAR in the size calculation. That would make the size of the array to be about 94 million, i.e., about 0.4 GB.
When I compiled the original source with Ver 8.51, but without all those options, it compiled fine. I suggest removing the options one by one to see which one (if it is just one) caused the compiler to fault. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2560 Location: Sydney
|
Posted: Sat Aug 31, 2019 3:55 am Post subject: |
|
|
My mistake, I left off /opt.
FTN95 /64 /opt also fails with Ver 8.40
No surprises with this result.
mecej4, it would depend how the offset is calculated. Perhaps /opt tries to simplify the offset calculation to gchowkswcoyr(i,j,k,l,m) as
(((m*mxncot+l)*mxnsew+k)*lxtzn+j)*lxtzn+i - offset
where offset = (((yayear*mxncot+1)*mxnsew+1)*lxtzn+1)*lxtzn+1 - 1,
ie calculating for gchowkswcoyr(1,1,1,1,yayear) ; the minimum address |
|
Back to top |
|
|
ahalls_dsc
Joined: 12 Nov 2018 Posts: 16
|
Posted: Sat Aug 31, 2019 9:31 am Post subject: |
|
|
I can confirm that the following adaptation compiles fine:
Code: | SUBROUTINE rdgenc_purp(jyr)
INTEGER,INTENT(IN) :: jyr
INTEGER,PARAMETER :: JAYEAR=803,JBYEAR=804,LXTZN=1714,
& MXNSEW=4,MXNCOT=4
INTEGER, PARAMETER :: J0YEAR=JAYEAR-1
REAL, DIMENSION(1:lxtzn,1:lxtzn,1:mxnsew,1:mxncot,JBYEAR-J0YEAR)
& :: gchowkswcoyr
gchowkswcoyr(:,:,:,:,jyr-J0YEAR) = 1.0E05
ENDSUBROUTINE |
I will return once the exe has been tested. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Tue Oct 01, 2019 7:16 am Post subject: |
|
|
This internal compiler error has now been fixed with the effect that the error is now reported as "Array size is too big when optimising". This will be in the next release of FTN95. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2560 Location: Sydney
|
Posted: Wed Oct 02, 2019 12:29 pm Post subject: |
|
|
Paul,
The actual array size is not too big, but I was guessing that the optimised approach may utilise a virtual array that is too big. Shouldn't there be a test that "if this were the case" then this guessed optimising approach should be rejected ? |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Thu Oct 03, 2019 9:39 am Post subject: |
|
|
I forgot to mention that the failure can be avoided by adding /INHIBIT_OPT 63.
An alternative in this particular case is to change the range of the final dimension from JAYEAR:JBYEAR to 1:JBYEAR-JAYEAR.
John
The optimiser fails with an arithmetic overflow whilst calculating the bounds of the array. An initial investigation has shown that a major revision would be required at this point of the code in order to fix the problem.
So the current "fix" has been limited to that of providing a better failure message. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2390 Location: Yateley, Hants, UK
|
Posted: Fri Oct 04, 2019 11:47 am Post subject: |
|
|
I suppose that I shouldn't be surprised that there are at least 63 optimisation 'actions', because reading the corresponding list for gfortran makes one's head spin with the number that they have.
Mind you, it does make me wonder what are Nos 1 .. 62 and, and what are Nos 64 et seq.
Not that it makes any difference to me, as FTN95 without /opt is adequate, but a tiny bit of me hankers after a speed improvement, even if it's meaningless to me !
Eddie |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Fri Oct 04, 2019 5:31 pm Post subject: |
|
|
Unfortunately the available documentation is very limited and incomplete. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|