[Bug fortran/20618] New: Variable format expressions not supported

[Bug fortran/20618] New: Variable format expressions not supported

[Thomas dot Koenig at online dot de]

This occurs in a legacy package that I inherited.
A testcase looks like this:

$ cat v-fmt.f
      program main
      implicit none
      integer i,n
      real a(10)
      a(1) = 1.
      a(2) = -1.
      n = 2
      print 9000,(a(i),i=1,n)
 9000 format (<n>F12.5," and that's all.")
      end
$ ifort v-fmt.f
$ ./a.out
     1.00000    -1.00000 and that's all.
$ gfortran v-fmt.f
 In file v-fmt.f:9

 9000 format (<n>F12.5," and that's all.")
              1
Error: Unexpected element in format string at (1)
 In file v-fmt.f:8

      print 9000,(a(i),i=1,n)
               1
Error: FORMAT label 9000 at (1) not defined
$ gfortran -v
Using built-in specs.
Target: ia64-unknown-linux-gnu
Configured with: ../gcc-4.1-20050320/configure --prefix=/home/zfkts
--enable-languages=c,f95
Thread model: posix
gcc version 4.1.0 20050320 (experimental)

There, the repeat count <n> is substituded by
the value of the expression n.  This also works
with expressions like <n-1>, and for other parts
of a format expression.

For new code, this can be done with an internal write
to the format.  For legacy code, this can be a bit of
a headache to convert.

g77 also doesn't support this extension, so this is
not a regression wrt g77.

-- 
           Summary: Variable format expressions not supported
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P2
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: Thomas dot Koenig at online dot de
                CC: gcc-bugs at gcc dot gnu dot org


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

[Bug fortran/20618] Variable format expressions not supported

[Thomas dot Koenig at online dot de]

------- Additional Comments From Thomas dot Koenig at online dot de  2005-03-24 14:29 -------
Actually, implementing this would be a bit harder
than I thought.

It seems that the variable expression is evaluated
at runtime, so you can do things like

$ cat v-fmt2.f
      program main
      character*1 c
 10   continue
      read(fmt=9000,unit=*,end=20) j,c
      print *,c
      goto 10
 20   continue
 9000 format(i1,t<j>,a1)
      end
$ ifort -traceback v-fmt2.f
$ ./a.out
1abcd
 1
2abcd
 a
3abcd
 b

Still doable with non-advancing I/O and internal writes, but
tricky.

-- 


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

[Bug fortran/20618] Variable format expressions not supported

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-24 15:12 -------
Confirmed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-03-24 15:12:59
               date|                            |


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

[Bug fortran/20618] Variable format expressions not supported

[tkoenig at gcc dot gnu dot org]

------- Comment #4 from tkoenig at gcc dot gnu dot org  2006-03-25 22:21 -------
As agreed on the mailing list, I'm closing this as WONTFIX.


-- 

tkoenig at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX


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

[Bug fortran/20618] Variable format expressions not supported

[tkoenig at gcc dot gnu dot org]

------- Comment #3 from tkoenig at gcc dot gnu dot org  2006-03-17 21:12 -------
Following the discussion on comp.lang.fortran on this subject,
I'm tempted to mark this WONTFIX.  This feature can cause
a lot of headaches to implement and is of questionable
semantics.

Any objections?


-- 


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