------- Comment #11 from burnus at gcc dot gnu dot org 2010-03-04 11:22 ------- (In reply to comment #10) > To me the code in comment #8 looks completely insane and unreadable, but if > some crazy standards document says it's legal, then so be it :)
I think it dates back to punch cards; there it helped with mispunches and saved space as continuation lines are no fun with punch cards - in the human-readable version at the top you could still add spaces. Fortran punch card: http://upload.wikimedia.org/wikipedia/commons/5/58/FortranCardPROJ039.agr.jpg Manually operatated puncher: http://en.wikipedia.org/wiki/File:IBM_Port-A-Punch.jpg Punch-card type writer: http://upload.wikimedia.org/wikipedia/commons/b/bb/GfhR_%2814%29.jpg > I wouldn't expect anyone to use F03 FINAL statements in F77 fixed source > form anyways. [Anyone progressive enough to even *think* about FINAL > statements would probably have abandoned fixed form long before producing > such thoughts.] I do not agree. The main code in our group is based on fixed-form FORTRAN 77 code, which has been modernized, but still it remains fixed form. Nevertheless, some Fortran 2003 constructs are used - and for consistency, I would not be surprised that if OOP came up (no plans so far), fixed form would be continued to be used also for the new code. -- Thus at least all valid code should work; whether one gets an as good diagnostic with fixed form as with free form is another matter, but adding a check like if (fixedform && gfc_state_stack->state != COMP_DERIVED_CONTAINS) return MATCH_NO; does not seem to ask too much. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43244