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 

An unexpected single step exception has occurred
Goto page Previous  1, 2, 3  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
sparge



Joined: 11 Apr 2005
Posts: 371

PostPosted: Sun Jun 12, 2011 3:11 am    Post subject: Reply with quote

@David, Hi!

I'm not sure if you have read the whole thread - in particular, you don't seem to:
- have realised that I posted a modified version of my code which the compiler swallowed lock, stock and barrel, without offering any error message at all
- have read my reply to Eddie and John of Fri Jun 10 11:52.

With the code I posted first, the compiler did at least diagnose an error of omission. I suppose it is a matter of taste whether a compiler should make sense of flawed source code by assuming a missing keyword and inferring an error of omission, rather than assuming nothing and inferring an error of commission. My own taste, according to Occam's razor, is that it should assume nothing to make its inferences.

Besides, the whole point of posting illustrative snippets of code is that they stand alone, isn't it? If I don't include a definition of a function called chainp, there's not meant to be one. The fact that I can make the compiler happy by telling it that it'll all be OK at link time rather defeats the purpose of posting code to illustrate a compiler bug Rolling Eyes

With the code I posted second, the compiler diagnoses nothing wrong at all. That is one issue. The second is that /DEBUG and /CHECKMATE builds of that code offer less helpful diagnosis of the ensuing runtime error than the /RELEASE build.

And yes, I am using Plato. As I have observed to Eddie, I need to be more careful about the way I present code snippets in future, making sure I describe explicitly any underlying division into files.
Back to top
View user's profile Send private message Send e-mail
JohnCampbell



Joined: 16 Feb 2006
Posts: 2239
Location: Sydney

PostPosted: Sun Jun 12, 2011 5:30 am    Post subject: Reply with quote

Andy,

I do agree that it appears to be a compiler bug to not identify, either that
- it has assumed a function that was not named as EXTERNAL, or
- the syntax for the character variable is wrong, and
- SDBG did not identify that the assumed function was not defined properly.

But at least, I ran your example on an old version of FTN95 and SDBG and it did "stop" at the offending line.

Paul, do you have a view on this ?
Back to top
View user's profile Send private message
davidb



Joined: 17 Jul 2009
Posts: 558
Location: UK

PostPosted: Sun Jun 12, 2011 2:20 pm    Post subject: Re: Reply with quote

JohnCampbell wrote:
davidb,

I'm not sure that the default assumption is a function, as a text I have, "Fortran 95 Handbook", by Adams et al, claims "the processor assumes that the argument is a variable".
I'd expect that for "chainp" to be assumed a function, it should have been declared EXTERNAL, although the only valid interpretation of "chainp(b)" is that it is a function.
You say "The compiler should assume this", but I'm not sure that this is the case. My recollection of F77, is that EXTERNAL is required and not optional, but alas I've recently lost my copy of the Fortran 77 standard.


As you know Fortran allows individual compilation of files. When the module is compiled (first), it assumes from the syntax that chainp must be an external function as this is the only thing which makes sense to it.
By default it assumes if a file looks OK it is OK (it doesn't look forward to what other file will make use of the file).

The function chaout does not to declare chainp as EXTERNAL. Only, the main program which calls chaout needs to declare chainp as EXTERNAL. This is what it says in Adams Book (which I have). As this is not done in the example code, an error message is issued.

Of course in this example, there is another interpretation, that the function chaout is incorrect, but the compiler cannot see this when it compiles the module since it does it separately.

The compiler should be reporting the error it reports for both DEBUG(CHECKMATE) and RELEASE builds. If it is not doing this then there is something wrong.
Back to top
View user's profile Send private message
davidb



Joined: 17 Jul 2009
Posts: 558
Location: UK

PostPosted: Sun Jun 12, 2011 2:32 pm    Post subject: Re: Reply with quote

sparge wrote:
I suppose it is a matter of taste whether a compiler should make sense of flawed source code by assuming a missing keyword


There is no missing keyword! Smile

Hopefully, Paul will throw some light on this when he gets a chance.
Back to top
View user's profile Send private message
sparge



Joined: 11 Apr 2005
Posts: 371

PostPosted: Mon Jun 13, 2011 11:02 am    Post subject: Re: Reply with quote

davidb wrote:
[ When the module is compiled (first), it assumes from the syntax that chainp must be an external function as this is the only thing which makes sense to it.


David, I don't follow this logic? chainp is declared, within chaout, as character*3. Even if chainp is a function, ICHAR can only take a single character as an argument, and the compiler is not spotting that ICHAR is being passed three characters. I don't see how the code I posted is perfectly valid FORTRAN if chainp is declared as EXTERNAL in the main program?
Back to top
View user's profile Send private message Send e-mail
davidb



Joined: 17 Jul 2009
Posts: 558
Location: UK

PostPosted: Mon Jun 13, 2011 11:34 am    Post subject: Reply with quote

Like this sparge. Very Happy

The syntax for defining a variable and the return type of a function is the same (in Fortran 77, and therefore in Fortran 9x too). You think you are declaring a variable as character*3 but you could equally be declariing a function of character*3.

Have a look at the code below.

I moved your module to the head of the file (just so I could put it all in one file), but I have not changed anything in it. These three routines are valid Fortran code (if they are very ugly and contrived).

So, if the module is valid here, it must be valid in your example too. This must be the case since we require that the module should be capable of being compiled separately, without any knowledge as to how it is to be used, provided the interface is followed.


Code:


! Nothing has changed in this module
module knots
integer, parameter :: nb = 3
contains
character (len = nb) function chaout (chainp)
character (len = nb) chainp
integer b, inp (nb)
do b = 1, nb
inp (b) = ichar (chainp (b)) ! the error is here
end do
chaout = char (inp (2)) // char (inp (3)) // char (inp (1))
end function chaout
end module knots


program strung_out
use knots
EXTERNAL chainp  ! << ADDED. Note it only goes in here. Not in the function chaout
character (len = nb) chainp, chance  ! << Changed to declare type of function chainp
chance = chaout (chainp) ! Pass the external function
print *, chance ! prints yzx
stop
end program strung_out


! EXTERNAL FUNCTION
character(len=3) function chainp(p)
integer p
character(len=3) :: chintz
chintz = 'xyz'
chainp = chintz(p:p)
end function chainp
Back to top
View user's profile Send private message
sparge



Joined: 11 Apr 2005
Posts: 371

PostPosted: Mon Jun 13, 2011 12:48 pm    Post subject: Re: Reply with quote

davidb wrote:
You think you are declaring a variable as character*3 but you could equally be declariing a function of character*3 ... So, if the module is valid here, it must be valid in your example too.


Variable character*3 or function character*3, neither is a legitimate argument to pass to ICHAR, as I understand it (and as the FTN95 manual documents it). From the FTN95 help file for ICHAR:

Syntax
INTEGER FUNCTION ICHAR(C)
CHARACTER C

Description
C is a character of length one.

Yes, the routines are ugly and contrived. They are contrived to make a point. I do get the (different) point that the module must be able to be compiled separately! Forget the code order thing, it is a red herring - I do compile the module separately.

You appear to be saying that the module compiles and therefore it is valid? So by definition it is impossible to demonstrate any compiler bug if that bug consists of compiling something that ought not to compile?!

I just tried to compile this code fragment, fully expecting FTN95 to object. Much to my surprise, it did not. The code compiles and runs. That does not make it valid code!

Code:
        program eyechar
        character (len = 3) c
        integer i
        c = 'abc'
        i = ichar (c)
        stop
        end

I found a Microsoft FORTRAN support page that says ICHAR will discard all but the first character if it is passed a character variable of length greater than 1. That is what is happening here. Whether it is what should happen, I don't know. ICHAR is a standard intrinsic function, and therefore its behaviour should be fully documented by the standard, and that behaviour and documentation should be the same for all compilers. What ICHAR should do if passed a character variable of length greater than 1 is, I guess, a question that can only be answered by the standard, and I don't have a copy ...
Back to top
View user's profile Send private message Send e-mail
davidb



Joined: 17 Jul 2009
Posts: 558
Location: UK

PostPosted: Mon Jun 13, 2011 1:13 pm    Post subject: Reply with quote

I wasn't suggesting that because it compiles its correct code, rather it looks correct code so it should not give an error on compilation.

Anyway, you might be right. I don't have the Standard here either.

For what its worth the documentation for Gfortran says this (the bold emphasis is mine):

Description:
ICHAR(C) returns the code for the character in the first character position of C in the system's native character set. The correspondence between characters and their codes is not necessarily the same across different GNU Fortran implementations.

Standard:
Fortran 95 and later, with KIND argument Fortran 2003 and later

Class:
Elemental function

Syntax:
RESULT = ICHAR(C [, KIND])

Arguments:

C Shall be a scalar CHARACTER, with INTENT(IN)
KIND (Optional) An INTEGER initialization expression indicating the kind parameter of the result.


And microsoft says this:

"The character string in each case must be a single character CHARACTER*1. If the character string is longer than one, the ICHAR function converts only the first character of the value. "
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2239
Location: Sydney

PostPosted: Mon Jun 13, 2011 1:52 pm    Post subject: Reply with quote

In ICHAR(C), C can be a character*1 variable or a character*1 array.
Where C is character*n, is not covered by the standard, but FTN95 only considers the first character.

I'm with Andy here, there should have been some warning, as a dummy function should not have been assumed.
If you create an .xrf report, CHAINP is FUNCTION, ARGUMENT :: CHAINP, no mention of CHARACTER(3) ??

Have a look at the error in the following example. On checking argument consistency, ZZ is identified as wrong but not CHIMP(edit: should be CHAINP).

John
Code:
        module knots
        integer, parameter :: nb = 3
        contains
        subroutine charcoal (champ, chimp, zz)
        character (len = nb) champ, chimp
        champ = chaout (chimp, zz)
        end subroutine charcoal
        character (len = nb) function chaout (chainp, zz)
        character (len = nb) chainp
        integer b, inp (nb)
        do b = 1, nb
          inp (b) = ichar (chainp (b)) + zz(b) ! the error is here
        end do
        chaout = char (inp (2)) // char (inp (3)) // char (inp (1))
        end function chaout
        end module knots

        program strung_out
        use knots
        character (len = nb) chintz, chance
        external zz
        chintz = 'xyz'
        call charcoal (chance, chintz, zz)
        stop
        end program strung_out

        function zz(i)
        zz = i
        end function zz


Last edited by JohnCampbell on Tue Jun 14, 2011 12:37 am; edited 1 time in total
Back to top
View user's profile Send private message
sparge



Joined: 11 Apr 2005
Posts: 371

PostPosted: Mon Jun 13, 2011 4:50 pm    Post subject: Re: Reply with quote

JohnCampbell wrote:
Where C is character*n, is not covered by the standard, but FTN95 only considers the first character.


John/David,

I looked a bit harder - I had forgotten that http://www.fortran.com/ provides a pretty exhaustive stock of FORTRAN standard documents. And the final draft FORTRAN 95 standard, which seems to be as close as we ever got to a FORTRAN 95 standard (it is supplemented by 6 other documents), has the following to say on the subject of ICHAR:

13.14.45 ICHAR (C)
Description. Returns the position of a character in the processor collating sequence associated with the kind type parameter of the character.

Class. Elemental function.

Argument. C shall be of type character and of length one. Its value shall be that of a character capable of representation in the processor.

Result Characteristics. Default integer.

Result Value. The result is the position of C in the processor collating sequence associated with the kind type parameter of C and is in the range , where is the number of characters in the collating sequence. For any characters C and D capable of representation in the processor, C .LE. D is true if and only if ICHAR (C) .LE. ICHAR (D) is true and C .EQ. D is true if and only if ICHAR (C) .EQ. ICHAR (D) is true.

Example. ICHAR ('X') has the value 88 on a processor using the ASCII collating sequence for the default character type.


It seems completely unambiguous to me. "Argument ... shall be of type character and of length one". So lengths greater than one are not allowed; and a compiler that adopts a "pragmatic" implementation of ICHAR, that works with the first character of an argument of length greater than one instead of diagnosing an error, is not adhering to the standard.

Incidentally, the FORTRAN 90 standard is even more unequivocal: it says "C must be of type character and of length one" (italic mine).

The final draft FORTRAN 2003 standard, and the FORTRAN 2008 standard, revert to the use of "shall" rather than must.

What is the point of a standards document if something as unambiguous as this can be interpreted so pragmatically? By this criterion, it would be scarcely more outrageous if a compiler interpreted the result of ICHAR, when passed any old data type at all, to be the result of passing it just the first byte. (FTN95 is not this pragmatic, by the way; I checked Smile )

The Microsoft documentation is pretty funny. Unlike the GFORTRAN documentation (which says only how their version of the function actually behaves), the Microsoft documentation does at least acknowledge how the function is supposed to behave, before going on to ride semi-roughshod all over it. It reminds me of Groucho Marx's line "Those are my principles, and if you don't like them ... well, I have others".

Andy
Back to top
View user's profile Send private message Send e-mail
davidb



Joined: 17 Jul 2009
Posts: 558
Location: UK

PostPosted: Mon Jun 13, 2011 5:17 pm    Post subject: Reply with quote

Hmmm ok I agree. Just have to wait and see what support thinks about it and whether a fix can be scheduled for the next release. It shouldn't be too difficult to fix.
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2239
Location: Sydney

PostPosted: Tue Jun 14, 2011 12:41 am    Post subject: Reply with quote

Andy,

It is interesting that the definition you quoted does not refer specifically to support of array syntax, which is supported by Lahey, Ftn95, Intel and a number of books.

My copy of the "Standard" is J3/97-007R2. I wonder when the final version was published and by whom.

John
Back to top
View user's profile Send private message
sparge



Joined: 11 Apr 2005
Posts: 371

PostPosted: Tue Jun 14, 2011 10:30 am    Post subject: Reply with quote

Hi John,

That's the version I was looking at too. I started to put those numbers in my post then I took them out again when I realised I couln't make head or tail of the "genealogy". That one for example ... if you look at the various versions of it on the Information page here:

http://www.fortran.com/

The document itself refers to itself on the front page as J3/97-007R2, but the main link to it (which of course only lets you buy it, not actually see it) talks about ISO/IEC 1539-1:1997, and if you follow that link it resolves to a page that talks about a document called ISO/IEC 1539-1:2004, which revises ISO/IEC 1539-1:1997 and two other corrigenda documents (all of which are now woithdrawn), and is in turn revised by ISO/IEC 1539-1:2010 Rolling Eyes and the 2004 and 2010 versions are apparently the FORTRAN 2003 and FORTRAN 2008 standards Rolling Eyes Rolling Eyes Rolling Eyes

So as far as I can see, the FORTRAN95 standard never actually did get finalized. It just got rolled up into the 2003 version (which also stayed as a final draft) and that in turn got rolled up into the FORTRAN 2008 version (which I note is finally a standard again).

By "support of array syntax" I presume you mean the ability to pass an array of CHARACTER*1 (as you pointed out yesterday) and get back an array of INTEGER? I presume this is not mentioned specifically because it is covered generically by virtue of ICHAR (along with a load of other intrinsics) being elemental. This prompted me to check that FTN95's ICHAR does behave elementally, and it does. This works as it should:

Code:
        program eyechar
        character c (26)
        integer j, i (26)
        do j = 1, 26
          c (j) = char (j + 64)
        end do
        i = ichar (c)
        stop
        end


If c is defined to be of length greater than 1, ICHAR (mis)behaves elementally the same way as it does with a scalar argument i.e. it works with only the first character of each element.

Andy
Back to top
View user's profile Send private message Send e-mail
JohnCampbell



Joined: 16 Feb 2006
Posts: 2239
Location: Sydney

PostPosted: Wed Jun 15, 2011 1:13 am    Post subject: Reply with quote

I got my copy of the fortran 95 document some time ago. The latest info on the different versions (95, 03 and 0Cool can be found at http://j3-fortran.org/.
It appears that the 95 .pdf is no longer available.

To repeat my previous comment, everyone should have a look at the 08 draft. I am quite concerned about where the J3 committe is taking the Fortran language. It is a massive change from what Fortran 95 is.
It looks like a language rewrite to allow C programmers to use Fortran. I think the number of programmers that would use the features required in the 08 standard would not justify the expense of developing the compiler.
We've seen what the .net development had on the viability of Salford and Lahey. I'd like to know how many users there are expected for the 08 features in the fortran standard.

John
Back to top
View user's profile Send private message
sparge



Joined: 11 Apr 2005
Posts: 371

PostPosted: Wed Jun 15, 2011 8:37 am    Post subject: Reply with quote

To play devil's advocate, then ... if it is going to be too expensive for anyone to develop a FORTRAN 2008 compiler, and not many people would want to use it anyway, we can all keep using battle-tested FORTRAN 95 compilers and everyone is happy. No?
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
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