Bug 34547

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>
Status:	RESOLVED FIXED
Severity:	normal	CC:	gcc-bugs, janus, mikael, zeccav
Priority:	P4	Keywords:	accepts-invalid, diagnostic, ice-on-invalid-code, rejects-valid
Version:	4.3.0
Target Milestone:	4.8.3
Host:		Target:
Build:		Known to work:
Known to fail:		Last reconfirmed:	2009-03-29 08:19:05
Bug Depends on:
Bug Blocks:	20585

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 7.1.4.1 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  <burnus@net-b.de>

        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  <burnus@net-b.de>

        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  <burnus@net-b.de>

        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  <pault@gcc.gnu.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  <pault@gcc.gnu.org>

	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