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: Richard Maine on 27 Jun 2010 16:33 e p chandler <epc8(a)juno.com> wrote: > 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. -- 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 16:36 e p chandler wrote: > > "dpb" <none(a)non.net> wrote in message > news:i0879q$llv$1(a)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. --
From: Steve Lionel on 27 Jun 2010 16:58 On 6/27/2010 2:17 PM, 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. 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
From: rfengineer55 on 27 Jun 2010 18:06 On Jun 27, 3:33 pm, nos...(a)see.signature (Richard Maine) wrote: > e p chandler <e...(a)juno.com> wrote: > > > 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. > > -- > Richard Maine | Good judgment comes from experience; > email: last name at domain . net | experience comes from bad judgment. > domain: summertriangle | -- Mark Twain 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
From: rfengineer55 on 27 Jun 2010 18:20
On Jun 27, 3:36 pm, dpb <n...(a)non.net> wrote: > e p chandler wrote: > > > "dpb" <n...(a)non.net> wrote in message > >news:i0879q$llv$1(a)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. > > --- Hide quoted text - > > - 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 |