| View previous topic :: View next topic |
| Author |
Message |
DanRRight
Joined: 10 Mar 2008
Posts: 2866
Location: South Pole, Antarctica
|
 Posted: Tue May 21, 2024 9:39 am Post subject: The error you will never find |
 |
|
| Code: | *** Error 607: Extraneous character ' ' following construct label
1 ERROR, 4 WARNINGS [<ZEROIZEWHATSTOPLOT> FTN95 v9.02.0.0]
NO ERRORS [<ZEROIZEWHATSTOPLOTONLYPARTICLES> FTN95 v9.02.0.0]
NO ERRORS [<LOADPROGRESS> FTN95 v9.02.0.0] |
Lately, like last couple years, FTN95 started sometimes generate compilation error reports without showing the exact line where the errors happens. Or reporting error twice - without the exact place in the beginning of the error report to totally confuse you and at the exact error place thousands lines below. I reported this bug multiple times but since I not always can send the large code to developers this rare error is still not found and not fixed. Of course there is no error in the ZEROIZEWHATSTOPLOT, this is just the arbitrary place compiler decided to tell about this error. And what the heck is "construct label"? I have just one label, and do not have any special "constructs"
Did you see such errors without the telling you the exact line? Please report it if you can also supply the code, please do not be procrastinators and diehard workarounders. For decades i know that most users of this compiler will go to the hell but will not report the bugs and suggestions. This will be your contribution to quality of this software, specifically if you use it for free.
I lose several days per year on this bug. This became really confusing. I need to keep numerous previous versions and compare files to see where special programs comparing texts line-by-line will find the difference. But with this error above i lost one more day and still did not find it. I can not use other compilers here because this is Clearwin program. In short - i stepped on pure devilry and am screwed up
Last edited by DanRRight on Tue May 21, 2024 10:09 am; edited 1 time in total |
|
| Back to top |
|
 |
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8017
Location: Salford, UK
|
| Posted: Tue May 21, 2024 10:03 am Post subject: |
|
|
Dan
This error report occurs only once in the compiler so I can (and have) fixed it for the next release.
It occurs after an END statement but I can't tell what kind of END it is, maybe END FUNCTION or END SUBROUTINE.
It is a false error report. I would need your code in order to understand why you are not getting the line number. |
|
| Back to top |
|
|
DanRRight
Joined: 10 Mar 2008
Posts: 2866
Location: South Pole, Antarctica
|
| Posted: Tue May 21, 2024 10:22 pm Post subject: |
|
|
Paul, Indeed the error was there, thanks for the hint. Here is reproducer. When in permanent hurry you easily miss such error. I just touch the code and there will be several errors. I may just came closer to working computer and sometimes happen it gets screwed  . I started using such optional endings recently because for the larger sources with thousands of lines it helps to find what subroutine is it quicker.
But demo reproduces only part of the problem - it gets this error report and shows exact line where the error appeared, but in my case the line where it happens was not reported. Last one is often happening problem i noticed many years ago - when the file becomes more than 30k lines something weird starts to happen. My suggestion would be to test FTN95 on very large codes, definitely there exist a lot of large codes in open access. Eventually i give up and divide the files into smaller ones until the problem appears again.
| Code: | program aaa
!external, integer :: bbb
integer, external :: bbb
i=bbb()
end
integer function bbb()
Print*,'asddfsdfsdf'
bbb=2
end function function bbb |
By the way one more not related issue i found with this demo : if you use
| Code: | | external, integer :: bbb |
instead of
| Code: | | integer, external :: bbb |
you get some other weird problem. Aren't these two statements completely equivalent ? |
|
| Back to top |
|
|
mecej4
Joined: 31 Oct 2006
Posts: 1896
|
| Posted: Tue May 21, 2024 11:31 pm Post subject: |
|
|
Dan, I agree that the error message is confusing, and that the wording could be improved for clarity.
The standard specifies (Fortran 2018, Sec.8.2) that:
| Quote: | R801 type-declaration-stmt is
declaration-type-spec [ [ , attr-spec ] ... :: ] entity-decl-list |
The standard document uses the convention that optional items are enclosed in brackets. Therefore, in your example, "integer", being a type-spec, should precede "external", which is an optional attr-spec.
When the compiler sees a section of code with an error, it sometimes has to guess what the programmer intended, or the closest valid program text. You are allowed to write a function subprogram with the name FUNCTION, as in
| Code: | function function(integer)
function = sqrt(real(integer))
end function function |
The following variant is allowed as well:
| Code: | function subroutine(integer)
subroutine = sqrt(real(integer))
end function subroutine |
If the code contains such ill-advised names, error messages can get very confusing. |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8017
Location: Salford, UK
|
| Posted: Wed May 22, 2024 6:57 am Post subject: |
|
|
Dan
Your demonstrator does not appear to give the same error report (error 607).
It gives
error 84 - Name of END FUNCTION is not the same as the name of the matching FUNCTION ('FUNCTION BBB' instead of 'BBB')
with the exact line number. |
|
| Back to top |
|
|
DanRRight
Joined: 10 Mar 2008
Posts: 2866
Location: South Pole, Antarctica
|
| Posted: Wed May 22, 2024 8:30 pm Post subject: |
|
|
Mecej4,
Yea, it is hard to write large software like compilers. You improve one thing and break 10 others. One among these 10 is internal test but other 9 are we users. But 8 off 9 keep mum waiting when somebody else will report back the feedback. You by the way do great job of permanent reporting. Pity only is that you do not use parallel programming like MPI and Clearwin...You use OpenMP but keep mum about it too preferring for that to use other compilers instead of demanding and advocating for it in FTN95. Why? That inevitably with time will turn any compiler into pensioners club discussing their good days with perfocards on Fortran4
Anyway, for sure few more such users here would MFGA (Make Fortran Great Again)
Paul,
Are you using 9.02? Here is complete error report with "construct label" error.
Compiled ftn95 aaa.f95 /link >z
| Code: | 0004) i=bbb()
WARNING - Variable I has been given a value but never used
NO ERRORS, 1 WARNING [<AAA> FTN95 v9.02.0.0]
0009) end function function bbb
*** Extraneous character ' ' following construct label
1 ERROR [<BBB> FTN95 v9.02.0.0]
|
|
|
| Back to top |
|
|
mecej4
Joined: 31 Oct 2006
Posts: 1896
|
| Posted: Thu May 23, 2024 2:09 pm Post subject: |
|
|
Dan, what do you have in your FTN95.CFG (in the FTN95 base directory)?
I ask because I suspect that you have /no_banner in it, or you may be using some IDE/build system that modifies the messages that the compiler would otherwise output. For instance, I do not see the name of the source file and its path in your post above. |
|
| Back to top |
|
|
DanRRight
Joined: 10 Mar 2008
Posts: 2866
Location: South Pole, Antarctica
|
| Posted: Thu May 23, 2024 11:12 pm Post subject: |
|
|
Mecej4, i don't have any CFGs. In the compilation error report above i just cut
"[FTN95/Win32 Ver. 9.02.0.0 Copyright (c) Silverfrost Ltd 1993-2024]
Licensed to ..."
on the top and
"*** Compilation failed" at the end |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
