This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, fortran] PR - Problems with -fwhole-file
- From: Tobias Burnus <burnus at net-b dot de>
- To: Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>
- Cc: "fortran at gcc dot gnu dot org" <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Sun, 17 May 2009 15:16:18 +0200
- Subject: Re: [Patch, fortran] PR - Problems with -fwhole-file
- References: <339c37f20905161404q2fc8d9f7i322c8e30eb895c9e@mail.gmail.com>
Paul Richard Thomas wrote:
> The attached is a first step towards putting the whole file scope
> option onto a good footing. The patch is mostly what has already been
> posted up to an improvement to the modification to allow type
> cheating, This is fixed by producing warnings instead of errors for
> std=legacy and -fwhole-file, without pedantic. If pedantic is set,
> errors are produced.
>
I wonder how to put it into the gfortran invoke.texi manual such that
users can actually find that their error (might) go away when using
-std=legacy; as long as -fwhole-file is not the default, that's not a
problem. But as the goal is to enable it by default ... (As tests have
shows, errors of this kind are extremely common; usually they are
written kind of on purpose and work on most systems.)
> The next step is to grab the backend_decls for module procedures. I
> am working on this now.
>
Thanks for taking care of this. In terms of error checking, the
-fwhole-file checking found problems which otherwise only NAG f95 found!
Thanks for your fantastic work to improve diagnostics and performance at
the same time!
> Bootstrapped and regtested on FC9/x86_i64 - OK for trunk
>
OK; however, I wonder whether one should use an enum instead of a magic
number for the following to make the meaning more obvious
+ if (pedantic && gfc_option.flag_whole_file)
+ gfc_option.flag_whole_file = 2;
There are some further issues, which could however be fixed later; they
seem to be orthogonal to this patch. See below.
* * *
Additionally, as Daniel Franke has pointed out: PR40011 comment 16 still
gives an ICE.
* * *
Compiling Elk.sf.net, one gets the error:
cfftnd.f90:470.38:
call cmf2kb ( lot, ido, l1, na, c, jump, inc, ch, 1, lot, wa(iw) )
1
Error: Type mismatch in argument 'cc' at (1); passed COMPLEX(8) to REAL(8)
That's in line with NAG f95, which prints:
Error: cfftnd.f90, line 472: Inconsistent datatype for arg 5 in call
to CMF2KB
however, using NAG "f95 -dusty" helps while "gfortran -std=legacy" does
not help.
For completeness: g95 prints (default settings)
Warning (155): Inconsistent types (COMPLEX(8)/REAL(8)) in actual
argument lists at (1) and (2)
while "ifort -warn all -stand f95" prints nothing.
* * *
I get an ICE in:
==17012== Invalid read of size 8
==17012== at 0x4FABF0: resolve_branch (resolve.c:6305)
==17012== by 0x505670: resolve_code (resolve.c:7002)
==17012== by 0x5059AB: gfc_resolve_blocks (resolve.c:6749)
For the following test case:
SUBROUTINE vrfftb(m,n,r,rt,mdimr,wsave)
DIMENSION r(mdimr,n),rt(mdimr,n),wsave(n+15)
CALL vrftb1(m,n,r,rt,mdimr,wsave(1),wsave(n+1))
END
SUBROUTINE vradb3(mp,ido,l1,cc,ch,mdimc,wa1,wa2)
DIMENSION cc(mdimc,ido,3,l1),ch(mdimc,ido,l1,3),wa1(ido),wa2(ido)
END
SUBROUTINE vrftb1(m,n,c,ch,mdimc,wa,fac)
DIMENSION ch(mdimc,n),c(mdimc,n),wa(n),fac(15)
DO k1 = 1,nf
CALL vradb3(m,ido,l1,c,ch,mdimc,wa(iw),wa(ix2))
GO TO 80
70 CALL vradb3(m,ido,l1,ch,c,mdimc,wa(iw),wa(ix2))
80 continue
end do
END
Tobias
> 2009-05-16 Paul Thomas <pault@gcc.gnu.org>
>
> PR fortran/40011
> * gfortran.h : Add prototype for void gfc_errors_to_warnings.
> * error.c (gfc_error): If warnings_not_errors is set, produce a
> warning.
> (gfc_errors_to_warnings): New function.
> options.c (gfc_post_options): If pedantic and whole_file, set
> flag_whole_file to 2.
> resolve.c (not_in_recursive, not_entry_self_reference): New
> functions.
> (resolve_global_procedure): Modify conditions for resolving the
> procedures referenced and checking their interfaces. Add error
> for missing interface or wrong rank.
> (gfc_resolve): Stack cs_base and flag partially resolved name
> spaces.
> trans-decl.c (gfc_get_extern_function_decl): Do not try to get
> backend_decls of procedures that are use associated, since they
> might have an explicit interface in the module.
>
> 2009-05-16 Paul Thomas <pault@gcc.gnu.org>
>
> PR fortran/40011
> * gfortran.dg/whole_file_7.f90: New test.
> * gfortran.dg/whole_file_8.f90: New test.
> * gfortran.dg/whole_file_9.f90: New test.
> * gfortran.dg/whole_file_10.f90: New test.