[Bug fortran/35003] New: spurious warning using -Wconversion, a do loop, and 8 byte integers

2008-01-28 Thread bcbarnes at gmail dot com
Part of original report:

I have recently had the chance to compile some code using -Wconversion and a
loop that may iterate more than 2.2 billion times.  There is a compiler warning
of this sort which I cannot resolve:

nell:~/work/bit barnes$ gfortran -Wconversion -o t.x testcase.f
testcase.f:7.16:

  do i=1_8,n
   1
Warning: Conversion from INTEGER(4) to INTEGER(8) at (1)
---
  program testcase
  implicit none
  integer(8) i,n

  n=1_8

  do i=1_8,n
  enddo

  end
---

The only variables in the testcase are 8-byte integers, yet I get that
conversion warning.  I skimmed the gfortran bugzilla and did not notice
anything similar.  If the loop is executed 2.2 billion times (n=2 200 000
000_8), it does run each instance, so I know the do loop is not being truncated
at the limit of a 4-byte integer.

---
nell:~/work/bit barnes$ gfortran -v
Using built-in specs.
Target: i686-apple-darwin8
Configured with: ../gcc-4.2.2/configure --prefix=/sw --prefix=/sw/lib/gcc4.2
--mandir=/sw/share/man --infodir=/sw/share/info
--enable-languages=c,c++,fortran,objc,java --with-arch=nocona
--with-tune=generic --host=i686-apple-darwin8 --with-gmp=/sw
--with-libiconv-prefix=/sw --with-system-zlib --x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6/lib
Thread model: posix
gcc version 4.2.2


Part of reply from Tobias Burnus (he asked me to file a bug report):

The problem is that the iterator step variable is INTEGER(4) [implicitly added
"1_4" ("gfc_int_expr (1);")]:

  do i = 1_8, n, 1_4


Something like the following should work:


Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c (revision 131912)
+++ gcc/fortran/match.c (working copy)
@@ -958,6 +965,8 @@ gfc_match_iterator (gfc_iterator *iter,
  if (gfc_match_char (',') != MATCH_YES)
{
  e3 = gfc_int_expr (1);
+  if (var->ts.type == BT_INTEGER)
+   e3->ts.kind = var->ts.kind;
  goto done;
}


-- 
   Summary: spurious warning using -Wconversion, a do loop, and 8
byte integers
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: bcbarnes at gmail dot com


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



[Bug fortran/35009] New: error on valid with -std=f95 (character arrays in format tags)

2008-01-28 Thread bcbarnes at gmail dot com
from my original report:

I have a program which uses conditional format tags, similar to this testcase
which is taken from page 187 of Metcalf, Reid and Cohen's Fortran 95/2003
explained:

---
  program testcase
  integer :: ival(30),key,i
  character(30) :: buffer
  character(6) :: form2(3) = (/ '(30i1)', '(15i2)', '(10i3)' /)

  read (*, '(a30,i1)') buffer, key
  read (buffer, form2 (key)) (ival(i), i=1,30/key)

  end
---

When compiled with -std=gnu  (gfortran 4.2.2, darwin8), no warning is issued
(which is good).  But when compiled with -std=f95 or -std=f2003, the following
error results:

---
nell:~/work/bit barnes$ gfortran -std=f95 testcase.f
testcase.f:7.19:

  read (buffer, form2 (key)) (ival(i), i=1,30/key)
  1
Error: Extension: Character array in FORMAT tag at (1)
---


Tobias S. confirmed this as a bug.  I was using gfortran 4.2.2 but this is
probably in 4.3.0 as well.


-- 
   Summary: error on valid with -std=f95 (character arrays in format
tags)
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bcbarnes at gmail dot com


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



[Bug fortran/29458] Spurious -Wuninitialized warning for implied do-loop counter

2008-01-30 Thread bcbarnes at gmail dot com


--- Comment #7 from bcbarnes at gmail dot com  2008-01-30 17:18 ---
This bug also shows up when executing the example code for initializing
random_seed in the gfortran documentation.  Is it a regression w.r.t.  4.0 or
4.1?  Maybe not, but it would be nice if something in the docs didn't generate
a warning ;)


-- 


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