forums.silverfrost.com

[DanRRight]

Usually spending hell of time to decipher where is my error due to such diagnostics. Would it be possible for compiler to tell exactly what's wrong - which variable is bad ? The one like below was acceptable when the cars were not self-driving ))

[mecej4]

In similar situations, where it is not clear which variable has an improper type and causes the compiler to issue an error message but without the name of the variable that is responsible for the error, we can specify /xref and look at the types in the cross-reference listing.

I tried this code based on your report:

[DanRRight]

I am making so many typos and errors per day that usually avoid any xref or lis or any other additional files besides the standard output of diagnostics because afraid to break my head in these additional kilometer long files. The standard compilation output warning and comment output is also hell long but there it is possible to search for the pattern *** and this is the only i can afford doing 200 times per day

BTW, in my case all variables were real*8. The final place for error was in not declaring
integer, external:: PrepDataForSlider_f_E.

Compiler kept mum about this and that caused me to lose an hour swearing on myself and a devilry

Compiler diagnostics should be much more specific and more verbose in explaining errors. We are living in the times when computers with artificial intelligence overcome humans, why they can not find such easy for them errors for themselves?

[mecej4]

[mecej4]

Duplicate, please DELETE!

[DanRRight]

[quote="John-Silver"]

[PaulLaidler]

In future these error messages for winio@ will take the form

[DanRRight]

[mecej4]

[DanRRight]

In our specific case compiler was simply too lazy. In "...%30^sl..." compiler knows for sure what ^ means. It means here is expected not a variable but a function. Despite of that it did not check if something where it should be placed a function was declared as a function. Functions for winio always have to be declared, here no freedom is given like avoiding using implicit none.
And by the way for more general case the compiler also knows if "implicit none" was declared or not. If not it can give more precise diagnostics about expected reals and integers just by first letter. So, here we return to our forgotten sheep: don't use implicit none! 😁

[mecej4]

[DanRRight]

[PaulLaidler]

In case anyone has missed it, there is a relatively new FTN95 compiler option /CHECK_WINIO that does some checking of winio@ arguments which otherwise would not be checked until runtime. This will only be useful for simple winio@ calls. As mecej4 rightly points out, there are some things that can only be checked at runtime.

As for compilers (and by implication their authors) being lazy, personally I respond better to encouragement rather than to abuse, but we have been down that road before.

[DanRRight]

Paul, "Lazy" relates to all Fortran compilers error reporting, with all other ones being much worse in finding errors, describing what the error is, and suggesting the cure. Perhaps this was done due to Fortran Standard Committee decisions to make this language operate like that.
I wrote many times here that diagnostics has to be more verbose and user friendly. Even for me who used Fortran for 40 years the language of diagnostics is often unacceptable laconic and worse than it could be. It often just gives the hint and leaves more on humans to find the error while in reality could tell exactly what the error is, or at least narrow the guessing job substantially. Probably i should be mentioning more that i already see in FTN95 the changes in the areas of wording in diagnostics messages and in what is diagnosed, so that this discussion would be understood as more general than specific to FTN95. I well understand that any diagnostics (and FTN95 finds several times more problems than other compilers) is way better than no diagnostics at all. Even just the pattern *** with no diagnostics message at all, or something in Chinese, is better than no diagnostics.
Here is how many common errors find other compilers for example

FTN95 49
PGI 15
Absoft 18
Gfortran 26
Intel 28

Can anyone imagine me with PGI compiler? With it i'd be dancing every time my black cat meowed with the hint when i'm on the page with the bug i could not find

And i wrote that what is missing is way smaller than what's already done: would be good to add more user friendly layer of explanation of diagnostics (say, with suggestions what could be typically wrong) and to add more deeper scanning of source texts to make error reports less general and more specific. Both are just the additions to what's already exist, so no reason for taking this thread way too personal. My productivity due to larger and larger GUI and larger main source code slowly and steadily approaching zero. We've all heard of this trend as a function of size. This is because of too many options to suspect for the possible reason of the bug. Without more and more sophisticated and targeted computer diagnostics i soon will be unable to find any bugs.

[wahorger]

Paul,

Thanks for the reference to /CHECK_WINIO. I have been making many modifications to my code, and this has found a number of errors (typos, mostly), but also some other problems that my old eyes did not catch when typing.

It would appear that when a single error is detected using this option, the compiler immediately exits versus what I would have expected; namely to continue the compilation of the file to the end. I have /NO_QUIT turned on.

Bill