|Summary:||[4.8/4.9 regression] NULL(): Fortran 2003 changes, accepts invalid, ICE on invalid|
|Product:||gcc||Reporter:||Tobias Burnus <burnus>|
|Component:||fortran||Assignee:||Paul Thomas <pault>|
|Severity:||normal||CC:||gcc-bugs, janus, mikael, zeccav|
|Priority:||P4||Keywords:||accepts-invalid, diagnostic, ice-on-invalid-code, rejects-valid|
|Build:||Known to work:|
|Known to fail:||Last reconfirmed:||2009-03-29 08:19:05|
|Bug Depends on:|
Description Tobias Burnus 2007-12-21 10:23:48 UTC
The following gives an ICE: print *, NULL() The program is invalid as the MOLD of NULL([MOLD]) is required in this context (see F2003, 13.7.88): "If MOLD is absent, the characteristics of the result are determined by the entity with which the reference is associated. See Table 13.1. MOLD shall not be absent in any other context." Table 13.1 contains: rhs of pointer assignment; initialization of an object in a declaration; default component init; struct constr; actual argument; in a DATA statement. Likewise for Fortran 97, see 18.104.22.168 around Table 7.2 - and 13.14.79. --------------------- integer, allocatable :: i(:) print *, NULL(i) Prints: Error: 'mold' argument of 'null' intrinsic at (1) must be a POINTER. While Fortran 97 has: "MOLD shall be a pointer and may be of any type." Fortran 2003 has: "MOLD shall be a pointer or allocatable. It may be of any type or may be a procedure pointer". ---- NULL as actual argument: external foo call foo(NULL()) is invalid without a MOLD as (F2003, similar in F97): "If any type parameters of the contextual entity are deferred, those type parameters of the result are deferred. If any type parameters of the contextual entity are assumed, MOLD shall be present. If the context of the reference to NULL is an actual argument to a generic procedure, MOLD shall be present if the type, type parameters, or rank is required to resolve the generic reference. MOLD shall also be present if the reference appears as an actual argument corresponding to a dummy argument with assumed character length." --- Someone could also check whether we do the right thing for: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/5a1e0cc2c7eb95cc/
Comment 1 Tobias Burnus 2008-01-16 21:20:08 UTC
See also http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/f014195ccf7b93e6/ for some other possible diagnostic issues.
Comment 2 Mikael Morin 2010-05-31 17:36:15 UTC
*** Bug 44349 has been marked as a duplicate of this bug. ***
Comment 3 Tobias Burnus 2011-09-14 06:26:13 UTC
Author: burnus Date: Wed Sep 14 06:26:07 2011 New Revision: 178841 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178841 Log: 2011-09-14 Tobias Burnus <email@example.com> PR fortran/34547 PR fortran/50375 * check.c (gfc_check_null): Allow allocatables as MOLD to NULL. * resolve.c (resolve_transfer): Reject NULL without MOLD. * interface.c (gfc_procedure_use): Reject NULL without MOLD if no explicit interface is known. (gfc_search_interface): Reject NULL without MOLD if it would lead to ambiguity. 2011-09-14 Tobias Burnus <firstname.lastname@example.org> PR fortran/34547 PR fortran/50375 * gfortran.dg/null_5.f90: New. * gfortran.dg/null_6.f90: New. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/interface.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
Comment 4 Tobias Burnus 2011-09-14 06:27:30 UTC
Author: burnus Date: Wed Sep 14 06:27:25 2011 New Revision: 178842 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178842 Log: Really add: 2011-09-14 Tobias Burnus <email@example.com> PR fortran/34547 PR fortran/50375 * gfortran.dg/null_5.f90: New. * gfortran.dg/null_6.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/null_5.f90 trunk/gcc/testsuite/gfortran.dg/null_6.f90
Comment 5 Tobias Burnus 2011-09-14 07:19:03 UTC
The patch fixes the issues of comment 0. However, one should go through the lengthy, convoluted thread at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/f014195ccf7b93e6/ to check whether it contains some still-unfixed issues.
Comment 6 Dominique d'Humieres 2013-06-25 17:48:20 UTC
> However, one should go through the lengthy, convoluted thread at > > http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/f014195ccf7b93e6/ >to check whether it contains some still-unfixed issues. The thread is too convoluted for me. Is this still an issue?
Comment 7 Vittorio Zecca 2013-06-25 19:03:39 UTC
It looks like it was fixed in 4.7.0 with the following error message Error: NULL intrinsic at (1) in data transfer statement requires MOLD=
Comment 8 Dominique d'Humieres 2013-06-29 14:06:32 UTC
> It looks like it was fixed in 4.7.0 with the following error message > > Error: NULL intrinsic at (1) in data transfer statement requires MOLD= Confirmed, however compiling the second test in comment #0, namely integer, allocatable :: i(:) print *, NULL(i) end gives an ICE with 4.8.1 and trunk (4.9) pr34547_1.f90:2:0: internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:6423 print *, NULL(i) It compiles with 4.7.3, and gives the reported error with 4.6.4.
Comment 9 Mikael Morin 2013-08-25 16:01:47 UTC
(In reply to Dominique d'Humieres from comment #8) > > gives an ICE with 4.8.1 and trunk (4.9) > > pr34547_1.f90:2:0: internal compiler error: in gfc_conv_expr_descriptor, at > fortran/trans-array.c:6423 > print *, NULL(i) > > It compiles with 4.7.3, and gives the reported error with 4.6.4. ... which makes it a regression.
Comment 10 Jakub Jelinek 2013-10-16 09:48:20 UTC
GCC 4.8.2 has been released.
Comment 11 Tobias Burnus 2013-12-01 10:53:00 UTC
(In reply to Dominique d'Humieres from comment #8) > Confirmed, however compiling the second test in comment #0, namely > > integer, allocatable :: i(:) > print *, NULL(i) > end > gives an ICE with 4.8.1 and trunk (4.9) "If an input item is a pointer, it shall be associated with a definable target and data are transferred from the file to the associated target. If an output item is a pointer, it shall be associated with a target and data are transferred from the target to the file." (F2008, "9.6.3 Data transfer input/output list") And NULL(...) isn't. Fixed by Paul's patch at http://gcc.gnu.org/ml/fortran/2013-11/msg00203.html
Comment 12 janus 2014-01-19 10:27:10 UTC
(In reply to Tobias Burnus from comment #11) > Fixed by Paul's patch at > http://gcc.gnu.org/ml/fortran/2013-11/msg00203.html ... which has been committed to trunk as r205565. Backport pending.
Comment 13 Paul Thomas 2014-01-19 11:29:19 UTC
Author: pault Date: Sun Jan 19 11:28:44 2014 New Revision: 206772 URL: http://gcc.gnu.org/viewcvs?rev=206772&root=gcc&view=rev Log: 2014-01-19 Paul Thomas <firstname.lastname@example.org> PR fortran/34547 * resolve.c (resolve_transfer): EXPR_NULL is always in an invalid context in a transfer statement. 2014-01-19 Paul Thomas <email@example.com> PR fortran/34547 * gfortran.dg/null_5.f90 : Include new error. * gfortran.dg/null_6.f90 : Include new error. Modified: branches/gcc-4_8-branch/gcc/fortran/ChangeLog branches/gcc-4_8-branch/gcc/fortran/resolve.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/null_5.f90 branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/null_6.f90
Comment 14 Paul Thomas 2014-01-19 11:31:44 UTC
Finally backported to 4.8! Thanks for the report Paul