Intel Visual Fortran Error Message
in [Fortran]
|
Prev: printing output in fortran without preceding white space
Next: Buy Tramadol fedex without prescription, Tramadol shipped overnight no prescription
From: dpb on 27 Jun 2010 14:32 rfengineer55 wrote: .... > 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. --
From: Richard Maine on 27 Jun 2010 14:54 dpb <none(a)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. 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
From: dpb on 27 Jun 2010 15:00 Richard Maine wrote: > dpb <none(a)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... --
From: e p chandler on 27 Jun 2010 16:10 "Richard Maine" <nospam(a)see.signature> wrote in message news:1jkqtz4.gtb1lixurr60N%nospam(a)see.signature... > dpb <none(a)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. > > 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. [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?
From: e p chandler on 27 Jun 2010 16:22
"dpb" <none(a)non.net> wrote in message news:i0879q$llv$1(a)news.eternal-september.org... > Richard Maine wrote: >> dpb <none(a)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... > 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 |