- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In order to reduce the wear and tear on my fingers I have decided that I need to type less. Consequently for me it's no more comments in source (I never read them anyway), no more mixed case keywords and names (saves pressing SHIFT), back to fixed source form (no need for all that extraneous white space - annoyances about IDE smart indenting behaviour become a thing of the past) and use of the statement termination character and continuations in preference to starting new lines (this will also save paper when I print my source out).
Unfortunately ifort won't play ball.
>ifort /check:all /warn:all /standard-semantics FIXEDFORMFOREVER.FOR Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.0.108 Build 20140726 Copyright (C) 1985-2014 Intel Corporation. All rights reserved. fortcom: Fatal: There has been an internal compiler error (C0000005). compilation aborted for FIXEDFORMFOREVER.FOR (code 1)
What's that? Do I have a bit too much spare time on my hands at the moment? Why yes I do as a matter of fact... how did you guess??
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That should teach you!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The error in that program is so obvious that it is not even worth mentioning.
Jim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The award-winning source code has a number of instances with the patterns
123456789012345678901234567890123456789012345678901234567890123456789012 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx;END +DO xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx;END +IF
If we keep in mind that the semicolon is not part of the statements that it terminates, a reading of 3.3.3.5 of the 2008 standard indicates to me that the special rule about not continuing even apparent END statements applies, and that splitting the keywords ENDDO and ENDIF in this fashion is not allowed. IFort does not seem to think so, however. To make the issue clear without the added distraction caused by the semicolons, try the example
1234567890 subroutine buggy(i,j) implicitnone integer,intent(in)::i integer, intent(out)::j if(mod(i,2)==0) +then j=2*i else j=2*i+1 end +if endsubroutinebuggy
with several compilers (the forum formatter may not show six leading blanks on lines whose first non blank character is not '+').
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Well that's a bug. I went to special effort to avoid that (you can see it in the source that causes the ICE around line 4463 with SUBROUTINETEST_APPEARS_LIKE_END). With less confidence I thought I also gave the fixed form scanner (the bulk of which starts at line 3392) the ability to detect that when reading the source. Oh well, the day is young.
(Here's the corrected source. Apparently MAX and MIN do different things - who would have guessed that! I must pay more attention when I read the language reference manual next time. My recollections around the scanner were complete and utter fabrications. As per the discussion on c.l.f I've taken the conservative approach in terms of what "appears" means. Still get an ICE (not that I actually care a whit - Intel people should stop reading this and go and do useful work.
Though.. if you are still reading this...
PROGRAM p ; PRINT 100 100 FORMAT('Hello world') ; END
as fixed form gives
>ifort EndAfterFormat.for Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.0.108 Build 20140726 Copyright (C) 1985-2014 Intel Corporation. All rights reserved. EndAfterFormat.for(2): error #5082: Syntax error, found FORMAT_ELEMENT ';END' when expecting one of: <END-OF-STATEMENT> ; 100 FORMAT('Hello world') ; END ------------------------------^ EndAfterFormat.for(2): error #5082: Syntax error, found END-OF-FILE when expecting one of: <LABEL> <END-OF-STATEMENT> ; BLOCK PROGRAM BLOCKDATA MODULE INTEGER REAL COMPLEX ... 100 FORMAT('Hello world') ; END -----------------------------------^ EndAfterFormat.for(1): error #6052: This label has not been defined as a FORMAT label. [100] PROGRAM p ; PRINT 100 --------------------------------------^ EndAfterFormat.for(1): error #6323: This label is not defined in this scoping unit. [100] PROGRAM p ; PRINT 100 --------------------------------------^ compilation aborted for EndAfterFormat.for (code 1)
Sometimes getting what you expect is not what you expect.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ian, I think that I have narrowed down the part of the program that causes an ICE. In line 1805 of the source that you attached to #5, you have split the token '::' in the middle, and that causes the ICE. Keep the two colons together, and the ICE goes away and the compiler continues until it stumbles at a later line, line 4566. This time, there is no ICE but there is some faulty parsing and a couple of spurious error messages. Again, reformatting the SELECT TYPE block makes the bug go away and an EXE gets built.
What is the program supposed to do? It should be interesting debugging it in the VS debugger, since F11 will cause all the multiple statements on the current line to be executed!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The program makes beautiful* fixed form source!
If you get an exe (I bow to you and the people who wrote ifort's fixed form parser if so), then running the exe without any command line options (or with --help) will give more details. If running exe's built from obscure and wacky source from strangers isn't your cup of tea, then have a look at the character literals in the last fifteen lines or so.
* Different opinions are rumoured to exist.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As of now, the program does not actually do any of the things it says it will do, because of bugs (?)
ifort /traceback /check forever.f forever forrtl: severe (408): fort: (8): Attempt to fetch from allocatable variable EXPANDED_ARGS when it is not allocated Image PC Routine Line Source forever.exe 012BB1E8 _CMDLINE_mp_PARSE 2966 forever.f forever.exe 012B785B _CMDLINE_mp_PARSE 2933 forever.f forever.exe 01335E4B _MAIN__ 4614 forever.f
.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It definitely needs /standard-semantics - no one can accuse me of living in the past with respect to my Fortran source.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ah, I see that /standard-semantics makes the code work.
Ian's program can be useful in creating "torture-test" fixed format Fortran examples for compilers. Given its complexity, and assuming that what he posted is not his original source code, which is probably in "unbeautiful" free format, I am astounded that the compiler can digest (after just two hiccups) the results of running the program on its own source code.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The secretary has just shown me how to load the fan-fold into the printer oriented in a different way (they keep insisting that it is "the right way", but I've always found that horizontal lines make my source code look fat). This opens up some possibilities for further savings in printing costs, when combined with the 132 character line limit of free form source. Plus, as we all know, shorter programs run faster.
But alas, ifort again refuses to play cricket.
MODULE m;IMPLICIT NONE;CONTAINS;SUBROUTINE s;END SUBROUTINE s;SUBROUTINE p END SUBROUTINE p; END MODULE m
>ifort /check:all /warn:all /standard-semantics two-lines-of-fun.f90 Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.0.108 Build 20140726 Copyright (C) 1985-2014 Intel Corporation. All rights reserved. two-lines-of-fun.f90(1): error #5141: END statement must be only statement on line MODULE m;IMPLICIT NONE;CONTAINS;SUBROUTINE s;END SUBROUTINE s;SUBROUTINE p --------------------------------------------------------------^ two-lines-of-fun.f90(2): error #5141: END statement must be only statement on line END SUBROUTINE p; END MODULE m -----------------^ compilation aborted for two-lines-of-fun.f90 (code 1)
What could possibly be so wrong with the statements ending those module procedures that ifort wants to cast them out from the company of their other colleagues in that same program unit.
"mecej4" wrote:What... you don't believe me?? I am crushed.
...and assuming that what he posted is not his original source code, which is probably in "unbeautiful" free format...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
IanH wrote:
But alas, ifort again refuses to play cricket.
MODULE m;IMPLICIT NONE;CONTAINS;SUBROUTINE s;END SUBROUTINE s;SUBROUTINE p END SUBROUTINE p; END MODULE mWhat could possibly be so wrong with the statements ending those module procedures that ifort wants to cast them out from the company of their other colleagues in that same program unit.
This was the topic of Fortran 90 interpretation 000130:
NUMBER: 000130 TITLE: Multiple statements on line with END statement KEYWORDS: END statement, source form DEFECT TYPE: Erratum STATUS: Published QUESTION: Can the end statement of a program unit be followed on the same line with statements for another program unit? By use of a ';' one can have multiple statements appear on a single line as in: A = 1; B = A; The standard does not seem to indicate one way or another whether an END statement can be followed by another statement on the same line. Presumably the statement would belong to the next compilation unit if such use was allowed, e.g.: END; SUBROUTINE S It is hoped that the intent of the standard is that any statement appearing on the same line as a program unit END statement must appear before the END statement. Note that END; SUBROUTINE S looks very much like END SUBROUTINE S; with a slight typo. ANSWER: No, a program unit END statement cannot be followed on the same line with statements for another program unit. The text in 3.3 "Source Form" is incomplete and an edit is provided for its repair. EDIT: Replace the first sentence of 3.3 [21:33] with: A Fortran program unit is a sequence of one or more lines, organized as Fortran statements, comments, and INCLUDE lines. SUBMITTED BY: Janice C. Shepherd HISTORY: 93-059 Submitted 93-094 Approved response 93-111 m125 ballot approved 94-160 m129 WG5 ballot approved
But I note that a module procedure is not a program unit, so... hmmm...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The parsing error and ICE from post 5 have been escalated as issue DPD200360539. We'll save this for a time when we're really bored.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I remembered this thread and wanted to use IanH's Fortran beautifier to prepare a torture-test for a Fortran indenter that I have been looking at. To my surprise, I find that today (15 months after the previous post), when I attempted to compile the source file in #8 with /Od /standard-semantics, the current compiler aborts the compilation.
Compiler version (all 32-bit) Result
14.0.4.237 Success
15.0.2.179 One syntax error followed by aborting of compilation
16.0.1.139 Many syntax errors followed by aborting of compilation
IanH, do you have a newer version of your program that can be compiled with a current IFort compiler?
Intel, any update on DPD200360539?
Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We're not that bored yet.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The source in #8 has an error that older compilers did not catch:
forever.f(941): error #6112: A function with the ELEMENTAL prefix-spec shall not
have the ALLOCATABLE attribute. [TKN_GETTYPETEXT]
ELEMENTALFUNCTIONTKN_GETTYPETEXT(THE_TOKEN)RESULT(TEXT);CLASS(TOKE
-----------------------^
The declaration, "beautified", is:
ELEMENTAL FUNCTION TKN_GETTYPETEXT(THE_TOKEN) RESULT(TEXT); CLASS(TOKEN),INTENT(IN)::THE_TOKEN; CHARACTER(:,KIND=SCCK),ALLOCATABLE::TEXT;
C1290 The result variable of an elemental function shall be scalar, shall not have the POINTER or ALLOCATABLE attribute, and shall not have a type parameter that is defined by an expression that is not a constant expression.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In addition to the elemental function with allocatable result, I think there were some bugs/workarounds for use/host association issues that got fixed with 16.0. http://www.megms.com.au/download/FF08FixedFormForEver.zip is the latest and compiles for me (again - needs /standard-semantics) with 16.0 update 1, unfortunately the intern has desecrated the source with comments and that new fangled free form nonsense - I have a lot of work ahead of me to restore it back to something compact and readable.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Got it, and it works fine. Thanks, Ian.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Now we're bored. Fixed for 17.0.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I read this -- darn you guys are a slightly more wacky than I realized
No one has that much time
If you used the old AutoCAD program one could do such things to your lisp code so people could not read them
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Or one could write in APL, which we used to joke was a "write-only language". When I was in college some guys taking the APL class took on the challenge to see if they could write all of the class's assigned programs in a single source line. Several succeeded.
![](/skins/images/D3C0B914909A6564BBB97F4AD1ED1973/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page