View previous topic :: View next topic |
Author |
Message |
StamK
Joined: 12 Oct 2016 Posts: 159
|
Posted: Wed Dec 02, 2020 7:18 pm Post subject: Spurious violation error during compilation |
|
|
Was working fine with 8.51.
Now getting this.
If I move the subroutines around (just tried randomly), I am not getting it anymore. Very long code - may have to send it if nobody can suggest a possible reason.
|
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
|
Back to top |
|
|
StamK
Joined: 12 Oct 2016 Posts: 159
|
Posted: Wed Dec 02, 2020 8:44 pm Post subject: |
|
|
If you click on the error, you can open the full image.
However it appears that removing some duplicate USE calls stopped this problem, meaning
Code: | MODULE A
USE MODULE B
....
END MODULE A
MODULE B
USE MODULE C
....
END MODULE B
PROGRAM MAIN
USE A
! USE C !removing this fixed it - for now!
END |
The reason the modules were called was because of module variables - however this is now not required. Just wanted to add it's the first time that we got this error - so perhaps previous ftn95 versions were more lenient.
Will keep you updated if something else comes up |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Thu Dec 03, 2020 8:52 am Post subject: |
|
|
StamK
Thank you for the feedback.
On reflection I was wondering if your problem concerned old object (.obj) files or old module (.mod) files. Sometimes a new release (or even a change in your source files) requires a full rebuild which means deleting all existing .obj and all existing .mod files.
Modules are designed to be used in an "object oriented" approach to programming. If they are based on random groupings of variables and routines then there is the risk that the dependencies between the modules may become recursive as the project is developed. A source file for a new module can be made to depend on a compiled .mod file for another module. In other words there is the risk of an unintended bootstrapping effect in the development cycle. The result is that a complete rebuild will fail because, for example, A depends on B, B depends on C and C depends on A.
It is just possible that something of this nature is the root of this issue. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Mon Dec 07, 2020 5:41 am Post subject: |
|
|
My understanding of this problem of double-referencing of modules is that you need to plan your module dependencies. I think USE MSWIN needs to be checked for this also.
FTN95 appears to be generous in this regard as duplicates appear to be managed, but this might not be standard conforming.
I think it is best to review module dependencies and definition order when compiling so you know what is happening. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Mon Dec 07, 2020 8:20 am Post subject: |
|
|
John
Thanks for the feedback. I don't know of any problems with MSWIN or FTN95 in this respect. Can you be more specific? |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Tue Dec 08, 2020 1:37 am Post subject: |
|
|
Paul,
I am referring to the double use of module clrwin, eg
USE mswin
USE clrwin
I vaguely recall past examples where this was posted and accepted by FTN95. (I may be wrong)
My approach is to limit use of multi-level MODULES, limiting to referencing derived type and precision definitions and not variables/arrays.
I would avoid the example above of MODULE A and definitely not consider the use of MODULE B which is referenced and also references other modules.
For me, the only conceivable use of MODULE C would be for KIND definitions and MODULE B for type definitions. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Tue Dec 08, 2020 11:04 am Post subject: |
|
|
John
The combination
Code: | USE mswin
USE clrwin |
is currently accepted by FTN95 even though clrwin is part of mswin.
These modules only contain PARAMETERs and subprogram interfaces where duplicates are acceptable. |
|
Back to top |
|
|
|