Intel Visual Fortran Error Message
rfengineer55
I' working on another of a large collection of FCC Fortran programs
compiled in VAX VMS Fortran.
There are variables in this program named Class4 , Class3, Class2, and
Class1.They are declared as type Logical. There are other variables
such as class_out declared as type character. All of my variables with
class as part of their name, are generating compiler errors. Here is
one -
When the compiler hits these, I get an error saying that #5082 syntax
error, found IDENTIFIER '_out when expecting one of : (%:, ==>
The line in the code associated with this error is -
class_out = 'OA"
An error message I get associated with the Logical variables is $5082
Syntax error, found INTEGER_CONSTANT '4' when expecting one of :
(%:,,==>
The line of code associated with this error is -
class4 - .false.
I am not aware of anything in Fortran where Class has any kind of
reserved meaning, There is some mention of Class made in the Visual
Studio 2008 book, but I have not doug deeply into that. Before I do,
I thought to run this interesting compiler situation by the list
members.
What do you think?
Thanks beforehand, for the help.
Jeff
RF ENGINEER55
dpb
> Hello,
>
> I' working on another of a large collection of FCC Fortran programs
> compiled in VAX VMS Fortran.
>
> There are variables in this program named Class4 , Class3, Class2, and
> Class1.They are declared as type Logical. There are other variables
> such as class_out declared as type character. All of my variables with
> class as part of their name, are generating compiler errors. Here is
> one -
>
> When the compiler hits these, I get an error saying that #5082 syntax
> error, found IDENTIFIER '_out when expecting one of : (%:, ==>
>
> The line in the code associated with this error is -
>
> class_out = 'OA"
>
There are mismatched character delimiters in the line as shown. If
that's really so, fix that first.
Otherwise, insufficient context given because in isolation the line
looks ok.
> An error message I get associated with the Logical variables is $5082
> Syntax error, found INTEGER_CONSTANT '4' when expecting one of :
> (%:,,==>
>
> The line of code associated with this error is -
>
> class4 - .false.
That's got a problem of an "-" instead of an "=" in what appears should
be an assignment statement.
From the above, I'm guessing this was optically scanned from a printed
listing and it's full of errors from that process.
--
Louis Krupp
A quick guess:
1. IVF recognizes a CLASS keyword.
2. Your compiler is treating blanks as insignificant, so it parses
"CLASS1" like "CLASS 1", and it's expecting something different after
"CLASS".
You'll have to find a way to make it treat blanks as significant (just
like in most other languages). This may be a matter of specifying
free-format source instead of fixed-format (or whatever they're called).
If your source files are really in fixed format, you may have to
change other things, like line continuations, but it will be worth it in
the end.
Louis
rfengineer55
>
> - Show quoted text -
dpb,
Thanks. The errors you found are a result of my sloppy typing. In the
source code, the character delimiters are actually OK
class_out = 'AB'
Same for the other line. In the sorce, it actually reads -
class4 = .false.
I'm truly sorry for not catching this before I posted. I will be more
careful in interest of everyone's time.
Thanks,
Jeff
RF ENGINEER55
rfengineer55
wrote:
>
> - Show quoted text -
Louis,
I think you're right on. Given your observations and suggestions, I'm
going to do some digging in the VS 2008 and find out more about the
Class references that I briefly noted. Hopefully there will be an easy
fix. I I can convince the compiler to treat class1 as written rather
than parsing it as class 1 like you're saying, I should be good to go.
This Fortran source I'm working with is large, so I hesitate to make
changes in the variable names because that could have far-reaching
consequences. I would normally just change the variable name and e
done with it, inthe case of a smaller program.
Louis, thank you for your thoughts on this.
Jeff
RF EGINEER55
dpb
...
> I think you're right on. Given your observations and suggestions, I'm
> going to do some digging in the VS 2008 and find out more about the
> Class references that I briefly noted. Hopefully there will be an easy
> fix. I I can convince the compiler to treat class1 as written rather
> than parsing it as class 1 like you're saying, I should be good to go.
...
Look at the language level switches -- I don't have IVF but I'd think
there would be a way to tell it to recognize/stick with F95 in which
case there would be no special meaning for CLASS.
I hadn't thought about the F2008 stuff earlier; just looked like bad
syntax above.
--
Richard Maine
> Look at the language level switches -- I don't have IVF but I'd think
> there would be a way to tell it to recognize/stick with F95 in which
> case there would be no special meaning for CLASS.
>
> I hadn't thought about the F2008 stuff earlier; just looked like bad
> syntax above.
Of course, as with all the other standard Fortran keywords, using them
for other purposes shoudl work fine. One of the nice points of the
language is that you don't have to memorize a list of keywords to avoid,
and even worse, find that new such keywords got added so that your code
that used to be fine becomes not-so-fine in later language revisions.
It is, of course, possible for a compiler to get it wrong. It is also
possible for error messages to be confusing if the code is invalid for
some other reason and the keyword usage makes the compiler "guess"
incorrectly about exactly what was wrong. Without (much) more context, I
could not say. I just note that ideally the use of the CLASS keyword as
a variable name (or part of one) is not suppose to cause problems,
regardless of blank significance.
I recall finding some early versions of BASIC annoying in that keywords
were reserved even as parts of names and without regard to blanks. For
example, AT was a keyword, making variable names like CAT invalid.
Worse, any variable name that ended in an "A" was a potential problem if
it might get used in context such as "IF ... BETA THEN..." The "A" in
BETA followed by the "T" in then got parsed as an AT. I'm glad not to
have to dela with that kind of cra^h^h^hstuff in Fortran.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
dpb
> dpb <no...@non.net> wrote:
>
>> Look at the language level switches -- I don't have IVF but I'd think
>> there would be a way to tell it to recognize/stick with F95 in which
>> case there would be no special meaning for CLASS.
>>
>> I hadn't thought about the F2008 stuff earlier; just looked like bad
>> syntax above.
>
> Of course, as with all the other standard Fortran keywords, using them
> for other purposes shoudl work fine. One of the nice points of the
> language is that you don't have to memorize a list of keywords to avoid,
> and even worse, find that new such keywords got added so that your code
> that used to be fine becomes not-so-fine in later language revisions.
Indeed, had a lapse there (and a quite large one, indeed)... :(
I'm back to the earlier comment that need more context and OP needs to
cut and paste exact source and error associated with it to have a clue
as there's nothing obvious in statements such as
CLASS4 = .FALSE.
if, indeed, CLASS4 is LOGICAL in the subject program unit.
Nor is there anything wrong in what's shown w/ the
CLASS_OUT = '0A'
if CLASS_OUT is CHARACTER
Either there is more to the story than is being shown (likely the case)
or there is, as you note, a problem in the parsing. That seems highly
unlikely to be this blatant an error in IVF if I had to guess, though...
--
e p chandler
"Richard Maine" <nos...@see.signature> wrote in message
news:1jkqtz4.gtb1lixurr60N%nos...@see.signature...
[OT] That was a standard "feature" in versions of interpreted Microsoft
BASIC. The internal representation of programs was partially tokenised
except for quoted text and some literal constants. So the tokeniser squished
out spaces as you describe. Many of the tokens were then used to compute an
address into a dispatch table for their respective verbs or functions. Was
there any early Fortran that was written in that fashion?
e p chandler
"dpb" <no...@non.net> wrote in message
news:i0879q$llv$1...@news.eternal-september.org...
There is more stuff going on here. Jeff and I had a discussion via e-mail
about a different program in which the errors he was seeing were the result
of an error cascade.
For example with gfortran
PARAMETER NUMIAB=12
LOGICAL CAN1AB
Error: Unexpected data declaration statement at (1)...
...
CAN1AB = .TRUE.
Error: Can't convert LOGICAL(4) to REAL(4) at (1)
It took me a while to figure this out. He is using fixed form source, so
PARAMETER is taken as an assignment statement instead of a non-standard
PARAMETER statement. A declaration follows an executable statement, so the
declaration is ignored. CAN1AB is un-declared, so it has the implicit type
of REAL.
Unfortunately for him, doing things like
PARAMETER (NUMIAB=12)
still did not fix his problem.
Elliot
Richard Maine
> There is more stuff going on here.
Somehow this doesn't surprise me (at all). That's why I alluded to more
context being needed. That's also (part of) why I didn't bother to reply
directly. I could invent all kinds of scenarios, but it just doesn't
seem worth it to speculate without information.
dpb
>
> "dpb" <no...@non.net> wrote in message
> news:i0879q$llv$1...@news.eternal-september.org...
>> Either there is more to the story than is being shown (likely the
>> case) or there is, as you note, a problem in the parsing. That seems
>> highly unlikely to be this blatant an error in IVF if I had to guess,
>> though...
>>
>
> There is more stuff going on here. Jeff and I had a discussion via
> e-mail about a different program in which the errors he was seeing were
> the result of an error cascade.
>
> For example with gfortran
>
> PARAMETER NUMIAB=12
> LOGICAL CAN1AB
> Error: Unexpected data declaration statement at (1)...
> ...
> CAN1AB = .TRUE.
> Error: Can't convert LOGICAL(4) to REAL(4) at (1)
>
> It took me a while to figure this out. He is using fixed form source, so
> PARAMETER is taken as an assignment statement instead of a non-standard
> PARAMETER statement. A declaration follows an executable statement, so
> the declaration is ignored. CAN1AB is un-declared, so it has the
> implicit type of REAL.
>
> Unfortunately for him, doing things like
>
> PARAMETER (NUMIAB=12)
>
> still did not fix his problem.
...
Ah....that makes sense, indeed. And, undoubtedly it's probably more of
the same or very similar going on here.
I'd think if the compiler warnings level were set very high the
out-of-order declaration above would have been flagged to give a clue if
Jeff isn't ignoring them???
Also, it would seem here's where an
IMPLICIT NONE
would help immeasurably in identifying such gaffes.
As noted in earlier threads, Jeff tends to snip too much and/or edit
before posting making assumptions of what is/isn't important and
generally leaving out the important.
--
Steve Lionel
>
> I think you're right on. Given your observations and suggestions, I'm
> going to do some digging in the VS 2008 and find out more about the
> Class references that I briefly noted. Hopefully there will be an easy
> fix. I I can convince the compiler to treat class1 as written rather
> than parsing it as class 1 like you're saying, I should be good to go.
Jeff,
Please make sure you are using the current Intel compiler, 11.1.065
(Update 6). An older version did have some issues with declarations of
variables whose names started with CLASS. You should not have to do
anything to get this accepted - we fixed the bug several months ago.
If you find you are still having these errors with 11.1.065, let me know.
--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH
For email address, replace "invalid" with "com"
User communities for Intel Software Development Products
http://software.intel.com/en-us/forums/
Intel Software Development Products Support
http://software.intel.com/sites/support/
My Fortran blog
http://www.intel.com/software/drfortran
rfengineer55
Richard,
I'm glad you had a chance to jump in here :-) BTW, I really like your
Fortran 2003 Reference. Just got it a few days ago.
If you can pass along an email address, I can email you the source
code. It is a long list, and given that I don't know what to send you
and what not, it would be better to send you the whole thing.
I have not had a chance to read my MS VS 2008 book yet, but I did see
a mention of classes in the book while looking for something else.
Have not yet gotten back to that book yet to research. I'm beginning
to think that this error is coming from VS 2008 and not the Fortran
compiler. This program worked once at the FCC in Washington DC, so I
would not expect any syntax or logic errors, but instead I would
expect compatibility errors because this source was originally
compiled to run on a VAX VMS system.
BTW, I have my Intel Visual Fortran set to VMS compatibility. I
realize also that this setting is not intended to be a silver bullet
to resolve all VMS compatibility issues.
Jeff
RF ENGINEER55
rfengineer55
>
> - Show quoted text -
dbp,
I don'tknow where the problem is, so it's difficult to know where the
snip point should be. I can post the entire source here if you want; I
have no objection.
The other reason I don't include much is that this is working source
code under VAX VMS, so it's different from a new program project that
refuses to compile and run.
I could chase down some VMS compatibility issues if you want, and see
where that takes me. I would bet that the problem has to to with
either VMS compatibility or the Visual Studio 2008 environment. But I
don't know for sure.
These class2, class3, class4 and class_out variable names are mission
critical, so if there was a fortran declaration or logic error with
those, the entire program would be a failure.
I certainly appreciate all the help that you are sending my way, so
I'll do my best to give you all the additional information you need.
Sincere thanks,
Jeff
RF ENGINEER55
rfengineer55
Steve,
I do not see a Help -> About in VS 2008 where I can check the version
number. What is the name of the executable, and I'll go into windows
and pull up the Properties of the file and check that out.
I bought this software a little less than a month ago through CDW
using an Academic discount. The exact date of purchase is probably in
your records.
Also, please send along an email address where I can write to you
directly. I used the Reply to Autor button here, and got no response
from you. Perhaps you have email sen by that feature blocked out. My
compiler will die in a couple weeks, and the info I received from a
support specialist at Intel was not valid information. I really rather
not say much more than that in a public forum.
Steve, thank you for your help with this immediate issue, and I hope
you can help me keep my compiler running.
Jeff
RF ENGINEER55
Louis Krupp
<snip>
> These class2, class3, class4 and class_out variable names are mission
> critical, so if there was a fortran declaration or logic error with
> those, the entire program would be a failure.
Have you written and tried to compile a small test program that uses
these variables? That could help you narrow things down a bit.
Louis
rfengineer55
Steve,
OK, I found it. Did not realize at first that the Intel ver could not
be harvested via Visual Studio 2008. My Programs shortcut under
Software Development Tools says Compiler rofessional 11.1.048, so it
would appear thyat I have an old version then.
When I bought this software, it came on a CDR as opposed to a
download. I hope this information helps.
Thanks,
Jeff
Richard Maine
> If you can pass along an email address, I can email you the source
> code.
As with Steve, my email address is in my signature. However, I don't do
private consulting. I post my address for people who might have personal
reason to email me. "Personal reason" does not include Fortran debugging
except in most unusual situations (which don't come close to applying
here).
P.S. Note Steve's separate comment about what sounds like a plausibly
related compiler bug. If that is the problem, which seems plausible
given Steve's comments, I wouldn't be able to do much about it anyway.
Steve Lionel
> OK, I found it. Did not realize at first that the Intel ver could not
> be harvested via Visual Studio 2008. My Programs shortcut under
> Software Development Tools says Compiler rofessional 11.1.048, so it
> would appear thyat I have an old version then.
You can get the version from Help > About in Visual Studio. Scroll down
the list of "Installed Products" until you get to a line that starts:
Intel(R) Visual Fortran Compiler Integration. After those words is
"Package ID w_cprof_p_11.1.xxx". The "package ID" matches the name of
the installable download (if you downloaded), and the 11.1.xxx is the
version.
11.1.048 is the current "boxed" version. 11.1.065 is the latest update.
Register your serial number at https://registrationcenter.intel.com/ and
you can download the latest update. You want the file
w_cprof_p_11.1.065_novsshell.exe since you already have Visual Studio
installed. Registering will also get you notices of product updates and
access to Intel Premier Support.
If you haven't already figured it out from the hints I gave you earlier,
my email address is steve.lionel at intel dot com. I don't show it
directly because I will get flooded with spam if I do. Just be aware
that I may be out of the office and unable to respond to your email in a
timely manner. The user forum is your best bet for immediate help, from
both experienced users and Intel engineers.
If the update doesn't help, please ask for help in the user forum, or
you can use Intel Premier Support (see
http://software.intel.com/en-us/articles/performance-tools-for-software-developers-intel-premier-support/
for information on that.)
dpb
...
> I don'tknow where the problem is, so it's difficult to know where the
> snip point should be. I can post the entire source here if you want; I
> have no objection.
...
Generally, unless as Louis suggests you make a small test
program--almost always a most excellent diagnostic tool, as noted,
btw--the entire source is generally too much information for usenet.
Granted, learning how to selectively decide what is significant does
take some effort.
It's a generic problem that doesn't afflict only you -- but in
particular, it's essentially impossible to say anything useful about
variables and/or functions without the associated declarations as a bare
minimum. Similarly, if the issue has to do w/ a calling sequence or
variable association or indexing in subprograms, unless one has the
declarations in both the caller and callee it's not possible in general
to find mismatches or difficulties there.
Also, it is much better to cut and paste without interpretation directly
from the compiler output and the source files than to try to paraphrase
or recreate. Subtle changes in wordings of error messages or typos can
inadvertently lead in the wrong path(s) or introduce other issues as in
the first posting despite the intent to be both concise and helpful.
I see later on that Steve L pointed out that there was indeed a parsing
error in an earlier release of the IVF compiler; I thought of that as a
possibility and almost suggested you go look at the Intel site and see
if there were any updates but knowing it was recent acquisition had
presumed that had been done. Which teaches a lesson on the other
end--one shouldn't presume... :)
Anyway, I gather that resolved the issue...
--