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.

StamK

Is this a continuation of https://forums.silverfrost.com/Forum/Topic/2953?

The image is partly hidden and blurred. But in any case a lot more information would be needed.

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

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

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.

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.

John

Thanks for the feedback. I don't know of any problems with MSWIN or FTN95 in this respect. Can you be more specific?

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.

John

The combination

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.