- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
Hi.
I just bought Intel Fortran to port some old code to OS X, and I am pretty rusty with Fortran. I am using it in the Xcode GUI. After a few bug fixes, the program works fine as long as "generate debug information" is selected in the build settings.
If I deselect it, and keep optimization at "O0" or any other setting, I get this error:
forrtl: No such file or directory
forrtl: severe (29): file not found, unit 1, file/build/Release/fort.1
Unit 1 is a scratch file (~17MB), which has no problem with the debug info setting. It also originally was a named, unknown, unformatted file, and the same error occurs (it was never named fort.1).
I had buffered IO set on and off, no difference.
OS X 10.5.2, Xcode 3, ifc 10.1.014, Mac Pro Jan 2008, 10GB
Thanks in advance for any help.
Jim
I just bought Intel Fortran to port some old code to OS X, and I am pretty rusty with Fortran. I am using it in the Xcode GUI. After a few bug fixes, the program works fine as long as "generate debug information" is selected in the build settings.
If I deselect it, and keep optimization at "O0" or any other setting, I get this error:
forrtl: No such file or directory
forrtl: severe (29): file not found, unit 1, file
Unit 1 is a scratch file (~17MB), which has no problem with the debug info setting. It also originally was a named, unknown, unformatted file, and the same error occurs (it was never named fort.1).
I had buffered IO set on and off, no difference.
OS X 10.5.2, Xcode 3, ifc 10.1.014, Mac Pro Jan 2008, 10GB
Thanks in advance for any help.
Jim
링크가 복사됨
4 응답
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
Jim,
Hard to say what is happening here. It appears your OPEN(UNIT=1....) statement was not in the code execution path and your code hit a READ(1, ....) statement.
Can you replicate this behavior outside of Xcode? Fortran Xcode integration is a "Preview Feature" - this means that it may have a few glitches.
From the command line, compile with:
-warn all -check all -g -traceback
This will give maximum compile-time warnings plus maximum runtime messages and give a stack trace if it aborts.
ron
Hard to say what is happening here. It appears your OPEN(UNIT=1....) statement was not in the code execution path and your code hit a READ(1, ....) statement.
Can you replicate this behavior outside of Xcode? Fortran Xcode integration is a "Preview Feature" - this means that it may have a few glitches.
From the command line, compile with:
-warn all -check all -g -traceback
This will give maximum compile-time warnings plus maximum runtime messages and give a stack trace if it aborts.
ron
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
A small correction to the recommended build command -- you must add the "-savetemps" option to ensure the symbol information is generated for access by the debugger:
From the command line, compile with:
-warn all -check all -g -savetemps -traceback
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
Thank you both! After using the suggested commands in terminal, I found that a couple of REAL arrays used in the scratch file were not initialized large enough - 9000 given, 40000 needed. It is amazing the code worked at all before.
I am really new at using debugging tools. I learned Fortran back in the CIBER days. Thanks much. :-)
Jim
I am really new at using debugging tools. I learned Fortran back in the CIBER days. Thanks much. :-)
Jim
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
MAD wgreen:
Jim,
Can you replicate this behavior outside of Xcode? Fortran Xcode integration is a "Preview Feature" - this means that it may have a few glitches.
Ron,
I obtained the same file error outside of Xcode as well, for the record. The "-check all" caught the error on the array bounds.
I do hope that Intel Fortran code folding makes it into Xcode GUI in the future. The build settings in Xcode also made it easy to discover many of the compile options.
Jim