[Bug fortran/34899] New: Continuation lines with <tab><number> not recognized

[Bug fortran/34899] New: Continuation lines with <tab><number> not recognized

[burnus at gcc dot gnu dot org]

The following program - which uses a very common extension - is rejected by
gfortran. It is accepted by ifort, NAG f95 (!), sunf95, openf95, pgi, absoft.
As it is a very common extension, I marked it as reject-valid though the tab
makes it non-standard.

It is essential that at least for the second and third line a TAB and not
spaces are used.

        PARAMETER (LUMIN=11,LUMAX=20,MAPMAX=256,NPLANEMAX=999)
        INTEGER NAXIS(0:MAPMAX,LUMIN:LUMAX),NAXIS1(0:MAPMAX,LUMIN:LUMAX),
        1NAXIS2(0:MAPMAX,LUMIN:LUMAX),NAXIS3(0:MAPMAX,LUMIN:LUMAX)
        end

>From the ifort documentation:
>
> In fixed and tab source forms, a continuation line is indicated by one of the 
> following:
>   * For fixed form: Any character (except a zero or blank) in column 6 of a 
>     source line
>   * For tab form: Any digit (except zero) after the first tab

If this bug is fixed, please also update the *.texi file.


-- 
           Summary: Continuation lines with <tab><number> not recognized
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Keywords: rejects-valid
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: burnus at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34899

[Bug fortran/34899] Continuation lines with <tab><number> not recognized

[burnus at gcc dot gnu dot org]

------- Comment #1 from burnus at gcc dot gnu dot org  2008-01-21 08:45 -------
Real-world test case:
http://www.chara.gsu.edu/~gudehus/fits_library_package.html

Untested:

Index: scanner.c
===================================================================
--- scanner.c   (revision 131688)
+++ scanner.c   (working copy)
@@ -912,12 +912,21 @@
        }

       if (!openmp_flag)
-       for (i = 0; i < 5; i++)
-         {
-           c = next_char ();
-           if (c != ' ')
-             goto not_continuation;
-         }
+       {
+         c = next_char ();
+         if (c == '\t')
+           {
+             c = next_char ();
+             if (c < 1 || c > 9)
+               goto not_continuation;
+           }
+         else if (c != ' ')
+           goto not_continuation;
+         else
+           for (i = 1; i < 5; i++)
+             if ((c = next_char ()) != ' ')
+               goto not_continuation;
+       }
       else
        for (i = 0; i < 5; i++)
          {

Index: invoke.texi
===================================================================
--- invoke.texi (revision 131688)
+++ invoke.texi (working copy)
@@ -499,10 +499,11 @@
 @cindex warnings, tabs
 @cindex tabulators
 By default, tabs are accepted as whitespace, but tabs are not members
-of the Fortran Character Set.  @option{-Wno-tabs} will cause a warning
-to be issued if a tab is encountered. Note, @option{-Wno-tabs} is active
-for @option{-pedantic}, @option{-std=f95}, @option{-std=f2003}, and
-@option{-Wall}.
+of the Fortran Character Set.  For continuation lines, a tab followed
+by a digit between 1 and 9 is supported.  @option{-Wno-tabs} will cause
+a warning to be issued if a tab is encountered. Note, @option{-Wno-tabs}
+is active for @option{-pedantic}, @option{-std=f95}, @option{-std=f2003},
+and @option{-Wall}.


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |burnus at gcc dot gnu dot
                   |dot org                     |org
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-01-21 08:45:12
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34899

[Bug fortran/34899] Continuation lines with <tab><number> not recognized

[burnus at gcc dot gnu dot org]

------- Comment #2 from burnus at gcc dot gnu dot org  2008-01-21 10:55 -------
Actually, this does not work as in scanner.c's "load_line" the '\t' is changed
into 6 spaces. And of cause, if one changes this, e.g., "\tPARAMETER" is no
longer recognized ...

+             if (c < 1 || c > 9)
And this should be: if (c < '1' || c > '9')


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34899

[Bug fortran/34899] Continuation lines with <tab><number> not recognized

[kargl at gcc dot gnu dot org]

------- Comment #3 from kargl at gcc dot gnu dot org  2008-01-21 17:40 -------
(In reply to comment #0)
> The following program - which uses a very common extension - is rejected by
> gfortran. It is accepted by ifort, NAG f95 (!), sunf95, openf95, pgi, absoft.
> As it is a very common extension, I marked it as reject-valid though the tab
> makes it non-standard.

Wrong!  It is invalid code.  Period.
Please remove the 'rejects-valid' designation.
At best, this is an 'enhancement request'.

>  It is essential that at least for the second and third line a TAB and not
> spaces are used.

Sorry, no!  The code is non-conforming.  The code should be fixed.


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sgk at troutmask dot apl dot
                   |                            |washington dot edu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34899

[Bug fortran/34899] Continuation lines with <tab><number> not recognized

[kargl at gcc dot gnu dot org]

------- Comment #4 from kargl at gcc dot gnu dot org  2008-01-21 19:24 -------
(In reply to comment #3)
> 
> Sorry, no!  The code is non-conforming.  The code should be fixed.
> 

I downloaded the FITS package, and it's worse than I thought.  Please
don't unfix gfortran.  This is valid fixed-form Fortran.

c23456789012345678901234567890123456789012345678901234567890123456789012
      program a
      integer aaaaaaaaaaaa, bbbbbbbbb, cccccccc, dddddddddd, eeeeeeee, f
     1gggg
      fgggg = 1
      print *, fgggg
      end program a

If I understand correctly, you want to change gfortran to parse a leading
tab as 5 spaces if it is followed by digit; otherwise, the leading tab is
parsed as 6 spaces.  OK, change the above program by replacing the 1 in
column 5 to 'd'.  This is again a valid fixed-form code.  Now, replace the
leading spaces with a tab.  Do you expand the leading tab by 5 or 6 spaces?

Seriously, the FITS code is invalid.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34899

[Bug fortran/34899] Continuation lines with <tab><number> not recognized

[jvdelisle at gcc dot gnu dot org]

------- Comment #5 from jvdelisle at gcc dot gnu dot org  2008-01-22 03:12 -------
With Tobias patch, the example code in comment 4 compiles with or without a tab
preceding the 1 digit.  It also works with 0 to 5 spaces preceding the tab and
fails with anything between the tab and the first digit 1.  So I think the
patch is safe.  Call it a legacy feature, it gives a warning with -std=f95 or
-pedantic

(rant) That being said, With all the brain power out there writing extremely
complex code, you would think some one would just right the simple conversion
program and get rid of all the tabs and handle the special case once and for
all.  It ain't that hard folks to fix your damn code. :) whooo! that felt good.

Of course this patch is only about 15 lines of code.

Maybe I should post a Fortran -std=f95 compliant program on the wiki,  Call it
"TabStripper.f"


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34899

[Bug fortran/34899] Continuation lines with <tab><number> not recognized

[burnus at gcc dot gnu dot org]

------- Comment #6 from burnus at gcc dot gnu dot org  2008-01-22 07:34 -------
Subject: Bug 34899

Author: burnus
Date: Tue Jan 22 07:33:46 2008
New Revision: 131713

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131713
Log:
2008-01-22  Tobias Burnus  <burnus@net-b.de>

        PR fortran/34899
        * scanner.c (load_line): Support <tab><digit> continuation
        * lines.
        * invoke.texi (-Wtabs): Document this.

2008-01-22  Tobias Burnus  <burnus@net-b.de>

        PR fortran/34899
        * gfortran.dg/tab_continuation.f: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/tab_continuation.f
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/invoke.texi
    trunk/gcc/fortran/scanner.c
    trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34899

[Bug fortran/34899] Continuation lines with <tab><number> not recognized

[manfred99 at gmx dot ch]

------- Comment #7 from manfred99 at gmx dot ch  2008-01-22 08:41 -------
Hmm,
I like the idea of being able to compile also legacy code with gfortran.
However, I really see the point Steve is making. With this patch things
get confusing.

If you consider a modified version of Steve's example:
c23456789012345678901234567890123456789012345678901234567890123456789012
      program a
      integer aaaaaaaaaaaa, bbbbbbbbb, cccccccc, dddddddddd, eeeeeeee, f
      1gggg
      f1gggg = 1
      print *, f1gggg
      end program a

If you write this with tabs, then the program becomes invalid.
So the mere user looking at the code can't see whether this is valid code
or not, you have to investigate the individual lines with an editor.

So I really would suggest to do something like
+      if (found_tab)
        {
+         found_tab = false;
+         if (c >= '1' && c <= '9')
+           {
+             *(buffer-1) = c;
+             gfc_warning_now ("Continuation line with tab ... etc.");
+             continue;
+           }
+       }


Secondly: Tradition in gfortran was to bury such things behind -std=legacy.
There are other things which are supported by other compilers and g77 and
which are only supported with -std=legacy in gfortran (e.g. FORMAT("f8")).
I don't care whether it's declared as legacy or not, but there should
perhaps be some overall strategy.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34899

[Bug fortran/34899] Continuation lines with <tab><number> not recognized

[manfred99 at gmx dot ch]

------- Comment #8 from manfred99 at gmx dot ch  2008-01-22 09:23 -------
Gaa, my example is BS, of course.
The really interesting thing is however, that g77 compiles it just fine
and happily treats "1gggg" as continuation line.
What a can of worms!!  


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34899

[Bug fortran/34899] Continuation lines with <tab><number> not recognized

[burnus at gcc dot gnu dot org]

------- Comment #9 from burnus at gcc dot gnu dot org  2008-01-22 09:30 -------
Patch was: http://gcc.gnu.org/ml/fortran/2008-01/msg00261.html
FIXED on the trunk (4.3.0).

Manfred Schwarb wrote:
> I like the idea of being able to compile also legacy code with gfortran.
> However, I really see the point Steve is making. With this patch things
> get confusing.

I do not think so. We were supporting "<tab>" before - and giving a warning
with  -std=f95/f2003 or -pedantic; except that we were not supporting
<tab><digit> for continuation lines. g77, NAG f95, ifort, openf95, sunf95,
pgf90, absoft, pathscale all support both <tab> for "normal" lines and
<tab><digit> for continuation lines. I do not see why this patch changes the
default behaviour of gfortran in this regard.


> c23456789012345678901234567890123456789012345678901234567890123456789012
>       integer aaaaaaaaaaaa, bbbbbbbbb, cccccccc, dddddddddd, eeeeeeee, f
>       1gggg

gfortran currently cuts off (by default) everything after 72 characters; thus
for the spaces version have the variable "f" and an invalid "1gggg" line. But
this is unchanged by my patch. The spaces version of your example compiles only
with g77 - and it does not compile if one adds an "implicit none" ("Invalid
declaration of or reference to symbol `f1gggg'"). With all my other compilers
it gives a compile error. The g77 error message indicates that it also regards
6 spaces + digit as a continuation line.

> If you write this with tabs, then the program becomes invalid.

No, it becomes valid (though not a valid by the Fortran standard) as without
"implicit none" one defines the variable "fgggg" and the variable "f1gggg" is
then implicitly typed.

> Secondly: Tradition in gfortran was to bury such things behind -std=legacy.
> There are other things which are supported by other compilers and g77

If you want, you can submit a patch which hides general "<tab>" support behind
-std=legacy. (I do not see why <tab> should be supported by default while
<tab><digit> should only be supported with -std=legacy.)

 * * *

My added comment of yesterday somehow vanished; re-add some bits:

> The code is non-conforming.
Agreed - <tab><digit> and <tab> are non-standard Fortran, even though they are
widely supported.

> I downloaded the FITS package, and it's worse than I thought.
Indeed: None of my 6 compilers is able to compile it - and I do not intent to
make gfortran compile it. (gfortran now compiles as fas as NAG f95 and after
one line change (realvar = ' ') as far as ifort, which should be enough.)

The advantage of <tab><digit> is that is both widely used and rather
unambiguous. The other failures look rather like bugs and I do not know what a
sensible compiler could do (other than rejecting it).


> If I understand correctly, you want to change gfortran to parse a leading
> tab as 5 spaces if it is followed by digit; otherwise, the leading tab is
> parsed as 6 spaces.

Kind of. Before my patch, gfortran replaced a <tab> in the first 7 columns
replacing it by up to 7 spaces, i.e. "<tab>", " <tab>", "  <tab>" and "       "
are treated identical. With the patch only 6 columns are regarded and if the
next digit after the tab is a digit, it is moved to the 6th column.


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
           Keywords|rejects-valid               |
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34899