forums.silverfrost.com

davidb · Joined: 17 Jul 2009 Posts: 560 Location: UK

Paul,

This compiles correctly, but gives an Access violation run time error in /CHECKMATE mode. It works fine in release mode.

PaulLaidler · Posted: Fri Jan 04, 2013 8:45 am Post subject:

I have logged this for investigation.

At first glance in looks like /CHECKMATE ought to provide a graceful runtime error report. For release mode, FTN95 cannot do anything about the logical programming error. Is this your expectation?

davidb · Joined: 17 Jul 2009 Posts: 560 Location: UK

Hello Paul. All the best for 2013 to you and the people at Silverfrost

I'm sorry, I haven't been clear.

The code above is valid Fortran 95 code. (I haven't made a programming error). In the standard it says that indices used in FORALL statements and constructs have the scope of the FORALL statement or construct only, and do not affect or inherit attributes from other variables in scope that happen to have the same name.

The Fortran Handbook, J Adams et.al. specifically describes the case I have coded above where the index i has the same name as a dummy argument with the INTENT(IN) attribute as legal code.

The BUG is that an "Access Violation" error occurs at run-time when I run the code compiled with /CHECKMATE.

The code compiles and runs correctly in release mode, as I would expect.

The problem is similar to the one on nesting a FORALL inside a DO loop in the other thread.

I don't know how you are handling FORALL index scope in your compiler. One way to do it is to internally pre-pend some "illegal" character (e.g. @) to the index names in FORALL statements so the above code looks like the following internally. This will work even for nested FORALLs (where the FORALL scope is shared in the nest). I assume you are doing something like this anyway, since the code works fine in release mode.

PaulLaidler · Posted: Fri Jan 04, 2013 7:11 pm Post subject:

The reason why the code works OK in release mode is probably because the argument value 1 is passed as an address and this address is used for the forall index.

The access violation will be something to do with the runtime checking code that goes wrong in this situation, otherwise I would anticipate a graceful runtime error message.

Your suggestion to change the internal name of the index may well fix everything in this context.

I have not had chance to look at the explist which should reveal what is going wrong.

davidb · Joined: 17 Jul 2009 Posts: 560 Location: UK

PaulLaidler · Posted: Sat Jan 05, 2013 8:07 am Post subject:

Thanks. I did understand that there is no programming error.

PaulLaidler · Posted: Wed Mar 27, 2013 6:27 pm Post subject:

I have fixed this bug for the next release (after 6.35).

davidb · Joined: 17 Jul 2009 Posts: 560 Location: UK

Thanks Paul.
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl