ICE with most horrible source ever

[IanH]

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??

[Anthony_Richards]

That should teach you!

[jimdempseyatthecove]

The error in that program is so obvious that it is not even worth mentioning.

Jim

[mecej4]

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 '+').

[IanH]

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.)

[mecej4]

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!

[IanH]

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.

[mecej4]

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

.

[IanH]

It definitely needs /standard-semantics - no one can accuse me of living in the past with respect to my Fortran source.

[mecej4]

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.

[IanH]

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:
...and assuming that what he posted is not his original source code, which is probably in "unbeautiful" free format...

What... you don't believe me??  I am crushed.

[Steven_L_Intel1]

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 m

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.

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...

[Steven_L_Intel1]

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.

[mecej4]

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.

[Steven_L_Intel1]

We're not that bored yet.

[Steven_L_Intel1]

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.

[IanH]

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.

[mecej4]

Got it, and it works fine. Thanks, Ian.

[Steven_L_Intel1]

Now we're bored. Fixed for 17.0.

[JohnNichols]

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

[Steven_L_Intel1]

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.