|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Wed Mar 25, 2015 12:22 pm Post subject: Curiocities |
|
|
Want me to show you true pure example of programming devilry again? Here is one damn error resolved at 4 am:
Code: |
11800) Ctbr_Sum = Ctbr_Sum + RELABex(j,IZSp1,III)* Ct_Hull(j,i,IZSp1)/
11801) * (RELABexSUM(IZSp1,iii)+1.e-7)
*** ':' found where not expected
*** INTEGER expression expected in substring range
|
Where the hell here is this damn colon? Or Integer expressions? The fun was that exactly next lines in this log file were the following
Code: |
12149) 6666 b = A_exc_HULL(6,I,J,IZS)/TE_llnl
WARNING - Label 6666 is declared, but not used
11606) 66666 b = A_ion_Hull(6,I,J,IZS)/TE_llnl
WARNING - Label 66666 is declared, but not used
|
And even more - you think i actually eventually found the error? Not at all, after some time of harassing me it *disappeared* by itself!
And even that was not all. I decided to save this whole compilation log file for history because no one will believe me. And to find myself what was going on. But when i hit Ctrl+S the application of text viewer crashed with access violation. But the text was left on screen. I eventually succeeded to save it together with Fortran text and its BAK file. There is no colon there but the old BAK file does not compile!
May be somebody see here what i do not see? |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7932 Location: Salford, UK
|
Posted: Wed Mar 25, 2015 3:12 pm Post subject: |
|
|
For me this code fragment compiles without error.
Perhaps we need more code in order to comment. |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Fri Mar 27, 2015 8:56 am Post subject: |
|
|
Quote: | after some time of harassing me it *disappeared* by itself! |
well, I don't believe that that's for sure ! You must have done something in the interim period.
As for the errors, as you mention it's devilry it's obviously linked to the 666's in the non-referenced labels !! LOL |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Sat Mar 28, 2015 9:38 am Post subject: |
|
|
Exactly. As to believe or not - look at the continuation, this is interesting. Further investigation when computer compared two files instead of my faulty human eye revealed that these two lines in these files are different:
Upper part is defective, lower is not.
Binary comparison of these lines showed presence in defective file just one more ascii symbol hex 20 which is integer 32 ... which is just the space and nothing else
I checked that additional symbol does not expand the line beyond 72 symbols long, so that is not a reason of a problems.
I extracted this piece sans 666 part into small code and post it here. It produces exactly this error report. Try it yourselves and see if devilry disappears. This forum unfortunately destroys fixed fortran formatting and you may not get the effect. I can post this file zipped then
Code: |
integer NUMBlevsZ (100)
real*4 RELABex (100,100,100)
real*4 Ct_Hull (100,100,100)
real*4 RELABexSUM (100,100)
DO i = 1, NUMBlevsZ (izs)
Ctbr_Sum = 0
Do j = 1, NUMBlevsZ (izs+1)
Ctbr_Sum = Ctbr_Sum + RELABex(j,IZSp1,III)* Ct_Hull(j,i,IZSp1)/
* (RELABexSUM(IZSp1,iii)+1.e-7)
enddo
enddo
end
|
UPDATE: OK, to keep the experiment clean here is zipped file i posted on Microsoft OneDrive website:
http://1drv.ms/1Mf7XvO
Just compile it and see the devilry yourselves! It's just the text file so nothing to worry about. Besides the devilry |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1888
|
Posted: Sat Mar 28, 2015 1:30 pm Post subject: |
|
|
The devil's in the ASCII -- your source file has tabs. Replace them by spaces (most text editors can do that, or you can use the FTN95 /convert option) and your devils will have been put to bed.
Next time when you are typing in a program, make sure at first that your text editor is set to replace input tabs by spaces.
You can expect similar problems if other "whitespace" characters (reverse-tab, backspace, delete, form feed, ..., irregular combinations such as LF+CR) are embedded in your Fortran sources. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Sat Mar 28, 2015 8:59 pm Post subject: |
|
|
Let we investigate this suggestion a bit more since it sounds like an over-forcing to my style of programming. I always reasonably - mostly for indentation if this is correct english word for beginning of line formatting - used tabs with no problems, they are still used with working file with no problems and fun is that I did not touch the offending part of the file for decades to cause this problem. Tabs were used with DEC, Cray, MS, Compaq Fortran compilers in the past with this same code as it was evolving over all these years. Binary comparison also shows that the space was added to offending line not the tab. I afraid we will throw the child, I mean devilry, with the water and it will appear again .
So, first, can you guys with other compilers check how they compile this broken code?
Last edited by DanRRight on Sun Mar 29, 2015 7:01 am; edited 2 times in total |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Sun Mar 29, 2015 6:26 am Post subject: |
|
|
interesting that the extra space causes the failure.
I tried changing the code to F95 format (just changing the continuation) and it compiles fine with the space left there !!!
interesting that the lack of dimensioning of the array RELABexSUM(i,j) goes without error flagging. why is that ? |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1888
|
Posted: Sun Mar 29, 2015 9:26 am Post subject: |
|
|
An occurrence of a variable followed by a list of arguments within parentheses is taken to be a function reference if the variable is not known to be an array. Try linking the object file. No surprises here.
Had IMPLICIT NONE been specified, an error message regarding the type of RELABEXSUM would have been issued. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2390 Location: Yateley, Hants, UK
|
Posted: Sun Mar 29, 2015 11:51 am Post subject: |
|
|
Mecej4,
Would IMPLICIT NONE bring up an error if the array was in fact a function reference? Why should it? I can see that an EXTERNAL function might need to be explicitly typed so that when it is used as an argument in a call its type is clear (for example the callback in WINIO@), but the type of non-EXTERNAL functions is presumable decided later.
If it did elicit an 'error' message, surely it should be a warning rather than an error, as there would still be the opportunity for it to be a function.
I suspect that it takes more than IMPLICIT NONE to resolve this.
As a real oldie, I have to confess that IMPLICIT NONE simply makes code unreadable to me (especially in combination with F90 formatting) - so it takes all sorts!
I think that I discovered that the TAB character stopped being useful when I moved from terminal access to a VAX 780 to my first PC, c. 1983, with Microsoft (Yah, Boo, Hiss) Fortran version 3.1, and I converted them all to spaces with WordStar in 'non-document' mode. My memory of this is hazy, but didn't the VAX map the first tab to column 7 and after that to multiples of 8 or 10? Other systems didn't, and lost valuable character positions in fixed format! I'm astonished that Dan got away with it for all this time, so perhaps the 'devilry' is, in fact, 'original sin'!
Eddie |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1888
|
Posted: Sun Mar 29, 2015 12:25 pm Post subject: |
|
|
Eddie,
Unless there is a type declaration for a function within scope, when IMPLICIT NONE is used or the /IM compiler option is used, the result is an error message. Often, one adds IMPLICIT NONE to order the compiler not to apply implicit typing rules, thereby making explicit type declarations mandatory. In fact, FTN95 says this about Dan's code:
Code: | 0009) * (RELABexSUM(IZSp1,iii)+1.e-7)
*** RELABEXSUM must appear in a type declaration because IMPLICIT NONE has been used |
The use of tabs is an extension. Here is one vendor's specification of the rules for expanding tabs: http://docs.oracle.com/cd/E19957-01/805-4941/6j4m2sobi/index.html . I do not know if FTN95 has similar written rules.
Original sin? We do not need to hark back to Adam, the snake and the apple. Dan chose style over substance, and probably has a mess of it to handle. Fortunately for him, all that he has to do in expiation is to run his source code through a filter or to use FTN95's /CONVERT, and request the compiler to accept wide lines (expanding tabs can cause some lines to end to the right of col-72 or col-132). I think that is is wrong to shop for a compiler that will accept buggy code and produce correct results. |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Sun Mar 29, 2015 4:41 pm Post subject: |
|
|
I was wondering why a 'space' should cause a problem, then I saw there are other 'space's on the line in question.
Then I spotted the problem ...... we're talking f77, and that line has 73 characters long !!!!!! so, it doesn't pick up the continuation '*' !!!!!
Just bump the end of that line to a new intermediate continuation and everything compiles fine.
Of course it compiles in f95 because there is no 72 char limit to no. characters on a line
I'm still concerned that the other 'errors' are not even flagged as warnings by the compiler.
Even though it would assume RelaBexSUM as a function, why isn't it complaining that the function doesn't exist !!!!!! ?????
Here's the code I tried which compiled
Code: | integer NUMBlevsZ (100)
real*4 RELABex (100,100,100)
real*4 Ct_Hull (100,100,100)
DO i = 1, NUMBlevsZ (izs)
Ctbr_Sum = 0
Do j = 1, NUMBlevsZ (izs+1)
Ctbr_Sum = Ctbr_Sum + RELABex(j,IZSp1,III)
* * Ct_Hull(j,i,IZSp1)/
* (RELABexSUM(IZSp1,iii)+1.e-7)
enddo
enddo
end |
... there are of course the <tabs> in there which don't show correctly !!!!! but you see what I've done, just bumped the '* Ct_Hull.....' to the next line (leaving the 'space'. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1888
|
Posted: Sun Mar 29, 2015 5:19 pm Post subject: |
|
|
Quote: | why isn't it complaining that the function doesn't exist | That is not the compiler's prerogative. Fortran has the associated concept of separate and independent compilation. The source code of a program can be spread across a number of files. The function subprogram may reside in a different file than the source containing its invocation. In fact, the function may not even be available in source form, but in a precompiled library or DLL. When the compiler is processing one source file, it need not have any awareness of the contents of other files (unless modules are being USEd).
It is at link time that undefined external symbols get reported. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7932 Location: Salford, UK
|
Posted: Sun Mar 29, 2015 5:23 pm Post subject: |
|
|
The function will be declared as missing at link time. For an error report at compile time try using the command line option /DCLVAR. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2556 Location: Sydney
|
Posted: Sun Mar 29, 2015 11:57 pm Post subject: |
|
|
Just on the comments about the use of tab characters:
I find it very annoying when tab characters are used in fixed format Fortran code, as the different editors I use do not use the same tab spacing definitions.
I have been reviewing code recently, where in the editor I am using (Plato or notepad), the use of a tab character moves code to column 5, where the original IDE (probably VS) moves the character to column 7.
This is a problem when viewing the code in different IDE/editors and I am not sure what FTN95 or other compilers do with this code, which is another more important problem.
It is this poorly defined response to tab spacing that suggests to me that there should be a compiler option to report tab characters as an error. I think that they are not in the Fortran standard character set for code and their presence could change the action of the code, especially in .for files. Code that uses tab characters should have a header to define the tab spacing rules.
I have even written my own code viewer that replaces all control characters, especially <HT> <CR> and <LF> to identify these problems.
John |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Mon Mar 30, 2015 12:34 am Post subject: |
|
|
Not declared variable is not related issue. When extracting the line into the test code i just forgot to declare one variable which i thought is still irrelevant. It was declared in the posted code on this forum above by the way. Anyway, this code has 200000 tabs and never had any issues for 37 years with any compiler. Same with other large code written by colleagues and compiled on a half a dozen different compilers on PC, Unix and Mac. So, returning to our devilry -- what specifically caused compiler to issue this exact error report?
Respect to John's comment, few years back when i tried Plato i made a suggestion on this forum to discuss making the tab user-definable separately for fixed and free source codes. Have both types of sources in the same code but Plato does not automatically recognized them making Plato useless for me. This suggestion would solve all the tab problems i think. Substitution of tabs with respective amount of spaces option could be also useful as a bonus. |
|
Back to top |
|
|
|
|
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
|