Access Violation

It is hell and disaster when you try to use not your own code written in different compiler...And the total shutdown is when you get this scary system 'access violation' after which you search exit in total darkness...

In very short demo code, the variable is defined and used like here

	module M_matdim
	integer,  save :: iab = 0
	end module M_matdim

!....................................

	program test
	call sub1
	end program

!....................................
	subroutine sub1
	use M_matdim,only : iab
	iab = 0
	end subroutine

The code stops at the line iab=0 If i add some lines before this line the code still stops with access violation on iab=0.

Feel myself helpless when such errors occur...

I use /full_debug /check /undef What you'd suggest to look at? Any switches to add ?

Authors mention they see the same error with IFORT compiler with some options '-m64 -i8' AND some routines were compiled with flag '-g' and others 'without'. Means code hidden error somewhere?

Dan,

I'm not sure what the problem is, but there are some unusual codings in this example: Why use SAVE in a module ? Why select ONLY when there is only one element in the module ? I'm not sure if these are illegal but they look odd to me

John

Runs OK for me under 32bit XP. Are you using the latest FTN95? What operating system?

Dratted Fortran 90 stuff that old timers like me cannot read ....

Isn't iab effectively a parameter, and its value cannot (should not) be changed? Might have been clearer with:

integer, parameter :: iab = 0

presumably compiler assumes it to be a parameter because of the initial value assignment, and only enforces no reassignment rule with those fancy switches. (Paul ?) Does save make it a parameter with the other compiler?

Runs OK for me too (Windows 7 32 bit) with no compiler switches.

Eddie

The snippet above of course works fine. That example was just an illustration with a lot of real coding omitted. The full code makes something with this line so that access violation is happening. May be turning it into parameter at run time because at compile time FTN95 easily detects syntax violation and does not produce executable....

There is a lot of actual stuff in the module, so ONLY uses only this and couple more elements (also omitted for simplicity). Also, I removed temporally SAVE but that gave no change.

Yes, the language became more complex. In older Fortran77 that would probably not happen at all...

Dan,

If iab was a PARAMETER in Fortran 77 it should produce an error - and does in FTN95 when running on Fortran 77 code:

      PROGRAM M
      INTEGER IAB
      PARAMETER (IAB=0)
      IAB = 10
      END

The error on line 4 is 'Constant found on left hand side of an expression where variable expected', and so program won't compile. Wrapping things up in modules just makes the errors more difficult to detect - it's an access violation in the code you posted because you aren't supposed to change the values of constants - even if it is from 0 to 0.

This stops with the same error:

      INTEGER, PARAMETER :: IAB=0

But if you replace PARAMETER with SAVE (or leave it off) you get a warning that 'Variable IAB has been given a value but never used'. Perhaps it is assumed to be a parameter if defined in a Module in FTN95?

Eddie

Quoted from LitusSaxonicum

Isn't iab effectively a parameter, and its value cannot (should not) be changed? Might have been clearer with:

integer, parameter :: iab = 0

presumably compiler assumes it to be a parameter because of the initial value assignment, and only enforces no reassignment rule with those fancy switches. (Paul ?) Does save make it a parameter with the other compiler?

Save attribute just makes variable static, not constant. When variable is declared in the module, it probably just acts like global variable to those procedures using it.

In Fortran 90, a local variable that is initialized when declared has an implicit save attribute.

! these two declarations are the same
integer :: i = 10
integer, save :: i = 10

Jalih,

The question is not what the compiler *should *do, but what it does do.

I consider most of the changes introduced in recent Fortran definitions to be a sort of devilry, so expect them to cause hell!

Eddie

For catching such bugs FTN95 has to introduce one more compiler option -- /enforce -- to enforce the most strict rules on everything.

Also does access violation have different flavors to get more information what specifically is violated?

Have you tried /ISO.

Will check because the exact reason for access violation and its specifics are still unknown but what caused it now clear - some module was absent. Unclear why this gave scary Access Violation which killed several my days and your, guys, time, instead of missing subroutine warning. Thanks for discussion and suggestions