forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Spurious violation error during compilation

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
StamK



Joined: 12 Oct 2016
Posts: 159

PostPosted: Wed Dec 02, 2020 7:18 pm    Post subject: Spurious violation error during compilation Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Wed Dec 02, 2020 8:17 pm    Post subject: Reply with quote

StamK

Is this a continuation of http://forums.silverfrost.com/viewtopic.php?t=3340?

The image is partly hidden and blurred. But in any case a lot more information would be needed.
Back to top
View user's profile Send private message AIM Address
StamK



Joined: 12 Oct 2016
Posts: 159

PostPosted: Wed Dec 02, 2020 8:44 pm    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Thu Dec 03, 2020 8:52 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Mon Dec 07, 2020 5:41 am    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Mon Dec 07, 2020 8:20 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Tue Dec 08, 2020 1:37 am    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Tue Dec 08, 2020 11:04 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
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