User account creation filtered due to spam.

Bug 25403 - gfortran run-time error with multiple tabs in format continuation
Summary: gfortran run-time error with multiple tabs in format continuation
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.1.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Keywords: accepts-invalid
Depends on:
Blocks: 19292
  Show dependency treegraph
Reported: 2005-12-14 00:45 UTC by mast
Modified: 2006-09-01 19:34 UTC (History)
2 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2005-12-14 09:26:02

Program with indentation that gives run-time error (109 bytes, text/plain)
2005-12-14 00:47 UTC, mast

Note You need to log in before you can comment on or make changes to this bug.
Description mast 2005-12-14 00:45:26 UTC
If a format statement is continued onto another line and the continuation
line is indented with more than one tab after the continuation character,
there is
a runtime error such as
Fortran runtime error: Unexpected element in format
(i4,i4,                                                             i4,i4)
A test program for this is:
       do i=1,1
          do j=1,2
            do k=1,1
              do l=1,1
101             format(i4,i4,
     &              i4,i4)
        call exit(0)

Where the indentation is with tabs (e.g., tabify in emacs).

Fails on Fedora Core 4, gcc-gfortran-4.0.2-8.fc4
Also fails under Mac OS X , gcc version 4.1.0 20051026 (experimental)
Comment 1 mast 2005-12-14 00:47:18 UTC
Created attachment 10479 [details]
Program with indentation that gives run-time error
Comment 2 Francois-Xavier Coudert 2005-12-14 09:26:02 UTC
Confirmed (and it's a regression wrt g77). The tree dump has:

  dt_parm.0.format = "(i4,i4, \ti4,i4)";

so I think it's up to the front-end to remove that.
Comment 3 kargl 2005-12-14 17:29:28 UTC
Technically, gfortran can do whatever it wants, because
the code is nonconforming.  The tab character is not a 
member of the Fortran character set.  The code is using
a tab where a member of the Fortran character set is 
expected.  This is just one more example of PR 18537,
for which I submitted a patch on 05 Mar 05.  Unfortunately,
the dialogue about that patch never resolved how a tab
should be handled.  I will revisit that patch with the 
following plan:
1) gfortran will issue an error during compiliation if a 
   tab is found in the input.  The only exceptions that I am 
   currently contemplating are tabs in comments and character
2) I'll probably introduce a -fexpand-stupid-tabs or similar
   pejorative named option for those user who fail to read
   Chapter 3 of the Fortran 95 standard. The option will
   simply replace the tab with a space (which happens to be
   a member of the Fortran character set).
3) Document that tabs are evil in gfortran.texi.

Finally, I don't care if this isn't backwards compatible with g77.
g77 is a cesspool of nonstandard features.  The introduction of this
cesspool into gfortran is severely reducing the quality of gfortran's
code and affect its maintainability.
Comment 4 Jerry DeLisle 2006-09-01 19:14:10 UTC
Current gfortran is handling this correctly
Comment 5 Jerry DeLisle 2006-09-01 19:16:54 UTC
I am looking into this a little. setWunused is called which calls SetWextras.  Just a little tweaking we need to do here I think.
Comment 6 Jerry DeLisle 2006-09-01 19:34:49 UTC
oops disregard that last comment. Typed in the wrong box.