Bug 63529 - Bad error and ICE with Cray Pointers in Modules
Summary: Bad error and ICE with Cray Pointers in Modules
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.9.0
: P4 normal
Target Milestone: 9.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-13 22:31 UTC by russelldub
Modified: 2018-05-13 17:21 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2014-10-15 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description russelldub 2014-10-13 22:31:18 UTC
Consider the following "cray_ptr_issue1.f90":

MODULE PTR_MOD
  IMPLICIT NONE
  REAL :: ptee1(*)
  POINTER (ptr1, ptee1)
END MODULE PTR_MOD
PROGRAM MAIN
  USE PTR_MOD
  IMPLICIT NONE
  WRITE(*,*) "Hello, world!"
END PROGRAM MAIN

> gfortran -fcray-pointer cray_ptr_issue1.f90
cray_ptr_issue.f90:7.6:

  USE PTR_MOD
      1
Error: Assumed size array at (1) must be a dummy argument

Scratch head.  Change "REAL :: ptee1(*)" to REAL :: ptee1(10)".

> gfortran -fcray-pointer cray_ptr_issue2.f90
f951: internal compiler error: backend decl for module variable ptr1 already exists
0x5fd8f8 gfc_create_module_variable
        ../../gcc-4.9.0/gcc/fortran/trans-decl.c:4251
0x5ca9ab do_traverse_symtree
        ../../gcc-4.9.0/gcc/fortran/symbol.c:3575
0x5fe552 gfc_generate_module_vars(gfc_namespace*)
        ../../gcc-4.9.0/gcc/fortran/trans-decl.c:4694
0x5e0851 gfc_generate_module_code(gfc_namespace*)
        ../../gcc-4.9.0/gcc/fortran/trans.c:1946
0x59ea59 translate_all_program_units
        ../../gcc-4.9.0/gcc/fortran/parse.c:4522
0x59ea59 gfc_parse_file()
        ../../gcc-4.9.0/gcc/fortran/parse.c:4732
0x5db795 gfc_be_parse_file
        ../../gcc-4.9.0/gcc/fortran/f95-lang.c:188
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
Comment 1 kargls 2014-10-14 00:34:12 UTC
(In reply to russelldub from comment #0)
> Consider the following "cray_ptr_issue1.f90":
> 
> MODULE PTR_MOD
>   IMPLICIT NONE
>   REAL :: ptee1(*)
>   POINTER (ptr1, ptee1)
> END MODULE PTR_MOD
> PROGRAM MAIN
>   USE PTR_MOD
>   IMPLICIT NONE
>   WRITE(*,*) "Hello, world!"
> END PROGRAM MAIN
> 
> > gfortran -fcray-pointer cray_ptr_issue1.f90
> cray_ptr_issue.f90:7.6:
> 
>   USE PTR_MOD
>       1
> Error: Assumed size array at (1) must be a dummy argument

Error makes more sense if compiled without -fcray-pointer.

> 
> Scratch head.  Change "REAL :: ptee1(*)" to REAL :: ptee1(10)".
> 
> > gfortran -fcray-pointer cray_ptr_issue2.f90
> f951: internal compiler error: backend decl for module variable ptr1 already
> exists

Which operating system?  It compiles and executes for me on
x86_64-*-freebsd with 5.0, 4.9.3, and 4.8.something.

PS: Do you have a copyright assignment with the FSF?

-- 
steve
Comment 2 russelldub 2014-10-14 00:49:52 UTC
(In reply to kargl from comment #1)
> (In reply to russelldub from comment #0)
> > Consider the following "cray_ptr_issue1.f90":
> > 
> > MODULE PTR_MOD
> >   IMPLICIT NONE
> >   REAL :: ptee1(*)
> >   POINTER (ptr1, ptee1)
> > END MODULE PTR_MOD
> > PROGRAM MAIN
> >   USE PTR_MOD
> >   IMPLICIT NONE
> >   WRITE(*,*) "Hello, world!"
> > END PROGRAM MAIN
> > 
> > > gfortran -fcray-pointer cray_ptr_issue1.f90
> > cray_ptr_issue.f90:7.6:
> > 
> >   USE PTR_MOD
> >       1
> > Error: Assumed size array at (1) must be a dummy argument
> 
> Error makes more sense if compiled without -fcray-pointer.
> 

I suppose, but I'm using cray pointers, so I would expect to include the flag, and shouldn't assumed size arrays be allowed?  What's the correct syntax if so.  (This works with ifort.)

> > 
> > Scratch head.  Change "REAL :: ptee1(*)" to REAL :: ptee1(10)".
> > 
> > > gfortran -fcray-pointer cray_ptr_issue2.f90
> > f951: internal compiler error: backend decl for module variable ptr1 already
> > exists
> 
> Which operating system?  It compiles and executes for me on
> x86_64-*-freebsd with 5.0, 4.9.3, and 4.8.something.
> 

RHEL derivative on x86_64, tried 4.4.6, 4.6.1, 4.7.1, 4.8.2, and 4.9.0.  No ICE on Fedora 20 x86_64 with gcc-4.8.3.  Can try my Ubuntu laptop later if necessary.

> PS: Do you have a copyright assignment with the FSF?
> 

No.  I suppose I should get that?
Comment 3 Steve Kargl 2014-10-14 01:27:17 UTC
On Tue, Oct 14, 2014 at 12:49:52AM +0000, russelldub at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63529
> 
> --- Comment #2 from russelldub at gmail dot com ---
> (In reply to kargl from comment #1)
> > (In reply to russelldub from comment #0)
> > > 
> > > > gfortran -fcray-pointer cray_ptr_issue1.f90
> > > cray_ptr_issue.f90:7.6:
> > > 
> > >   USE PTR_MOD
> > >       1
> > > Error: Assumed size array at (1) must be a dummy argument
> > 
> > Error makes more sense if compiled without -fcray-pointer.
> > 
> 
> I suppose, but I'm using cray pointers, so I would expect to include
> the flag, and shouldn't assumed size arrays be allowed?  What's the
> correct syntax if so.
>  (This works with ifort.)

With ifort, are you compiling with whatever flag enforces
standards conformance.  I need to go hunting through the
standard to see if assumed size arrays are allowed in the
declaration section of a module.

>>> Scratch head.  Change "REAL :: ptee1(*)" to REAL :: ptee1(10)".
>>> 
>>>> gfortran -fcray-pointer cray_ptr_issue2.f90
>>> f951: internal compiler error: backend decl for module variable ptr1 already
>>> exists
>> 
>> Which operating system?  It compiles and executes for me on
>> x86_64-*-freebsd with 5.0, 4.9.3, and 4.8.something.
> 
> RHEL derivative on x86_64, tried 4.4.6, 4.6.1, 4.7.1, 4.8.2,
> and 4.9.0.  No ICE on Fedora 20 x86_64 with gcc-4.8.3.  Can try
> my Ubuntu laptop later if necessary.

Hmmm, this smells like a 'used after free' issue.  Do you
have valgrind on the system where the failure occurs? That
might point at the smoking gun.
Comment 4 russelldub 2014-10-14 06:08:42 UTC
> With ifort, are you compiling with whatever flag enforces
> standards conformance.  I need to go hunting through the
> standard to see if assumed size arrays are allowed in the
> declaration section of a module.
> 

I don't think so.  Need to check and see if any of the flags affect it.

> >> Which operating system?  It compiles and executes for me on
> >> x86_64-*-freebsd with 5.0, 4.9.3, and 4.8.something.
> > 
> > RHEL derivative on x86_64, tried 4.4.6, 4.6.1, 4.7.1, 4.8.2,
> > and 4.9.0.  No ICE on Fedora 20 x86_64 with gcc-4.8.3.  Can try
> > my Ubuntu laptop later if necessary.
> 
> Hmmm, this smells like a 'used after free' issue.  Do you
> have valgrind on the system where the failure occurs? That
> might point at the smoking gun.


I get the ICE on Ubuntu 13.04, gcc-4.8.  Valgrind doesn't tell me anything:

$ valgrind gfortran -fcray-pointer cray_ptr_error2.f90 
==6319== Memcheck, a memory error detector
==6319== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==6319== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==6319== Command: gfortran -fcray-pointer cray_ptr_error.f90
==6319== 
f951: internal compiler error: backend decl for module variable ptr1 already exists
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.8/README.Bugs> for instructions.
==6319== 
==6319== HEAP SUMMARY:
==6319==     in use at exit: 41,057 bytes in 88 blocks
==6319==   total heap usage: 194 allocs, 106 frees, 50,830 bytes allocated
==6319== 
==6319== LEAK SUMMARY:
==6319==    definitely lost: 5,169 bytes in 33 blocks
==6319==    indirectly lost: 16 bytes in 1 blocks
==6319==      possibly lost: 0 bytes in 0 blocks
==6319==    still reachable: 35,872 bytes in 54 blocks
==6319==         suppressed: 0 bytes in 0 blocks
==6319== Rerun with --leak-check=full to see details of leaked memory
==6319== 
==6319== For counts of detected and suppressed errors, rerun with: -v
==6319== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Comment 5 russelldub 2014-10-14 17:08:57 UTC
> With ifort, are you compiling with whatever flag enforces
> standards conformance.  I need to go hunting through the
> standard to see if assumed size arrays are allowed in the
> declaration section of a module.

ifort doesn't complain with -standard-semantics.  If I add -std{f90,f95,f03,f08} then I get a warning about the POINTER statement being dis-allowed, but it still compiles.
Comment 6 Dominique d'Humieres 2014-10-15 08:35:19 UTC
AFAICT the ICE with "REAL :: ptee1(10)" has been fixed for gfortran 4.9.1 and above (also for 4.8.4).

I also think the error for "REAL :: ptee1(*)" is right.

If you agree with the above, could you please close this PR as FIXED?
Comment 7 russelldub 2014-10-15 17:30:32 UTC
(In reply to Dominique d'Humieres from comment #6)
> AFAICT the ICE with "REAL :: ptee1(10)" has been fixed for gfortran 4.9.1
> and above (also for 4.8.4).

I can't easily test with either of those, but the ICE doesn't happen for me with a trunk build, so I guess that's OK.

> I also think the error for "REAL :: ptee1(*)" is right.

Whether or not the assumed size array is allowed is one question.  I don't know the answer but I can say that both ifort and pgf95 think it's fine.  I can't find a definitive answer in the standards, but as cray-pointers aren't part of the standard, it's probably not the right way to handle that question.

The second question is whether the emitted error is sufficient to allow one to fix the problem.  It's true that omitting -fcray-pointer from the arguments does give a more informative error, but I would have tried a lot of other things before getting to that as I am trying to compile code that depends on cray pointers.  It would be much better if the informative error showing the actual location of the issue was emitted when using -fcray-pointer.
Comment 8 russelldub 2014-12-03 19:16:34 UTC
Not sure what correct etiquette is for checking on bug status, but this has been sitting for close to two months now, so I thought I would poke my head in again.
Comment 9 Dominique d'Humieres 2014-12-06 16:38:53 UTC
> Not sure what correct etiquette is for checking on bug status, but this has
> been sitting for close to two months now, so I thought I would poke my head
> in again.

Nasty answer: what did you do to fix it?

I RTFM and saw at https://gcc.gnu.org/onlinedocs/gfortran/Cray-pointers.html#Cray-pointers

> The pointer is an integer that is intended to hold a memory address.
> The pointee may be an array or scalar. A pointee can be an assumed size
> array—that is, the last dimension may be left unspecified by using a *
> in place of a value—but a pointee cannot be an assumed shape array.
> No space is allocated for the pointee.

So the test in comment 0 seems valid according the above. So either the POINTER statement is not recorded in the module, or it is recorded, but not used when the module is read. Note that using f77 extensions with f90+ standard features is a *VERY BAD* idea: if one wants to "modernize" a "legacy" f77 code, I think the first step should be to replace all the non-standard extensions with the suitable standard f90+ constructs, then refactor the code to use modules, ... .

For this PR, I see three possibilities:

(1) Document that cray pointers should not be used in modules for assumed size arrays. That's the easiest.

(2) Reject cray pointers used in modules for assumed size arrays. This requires that you find the location to do it, but should not be too difficult.

(3) Accept cray pointers used in modules for assumed size arrays, i.e., check that cray pointers are recorded in the module and that the information is properly used when reading the module. This is probably a lot of work, especially if you know very little about the generation and use of *.mod files (it is also quite tricky to change this part of the code).

So pick your choice and do the work. Good luck!
Comment 10 Steve Kargl 2014-12-06 19:11:49 UTC
On Sat, Dec 06, 2014 at 04:38:53PM +0000, dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63529
> 
> --- Comment #9 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> > Not sure what correct etiquette is for checking on bug status, but this has
> > been sitting for close to two months now, so I thought I would poke my head
> > in again.
> 
> Nasty answer: what did you do to fix it?
> 
> I RTFM and saw at
> https://gcc.gnu.org/onlinedocs/gfortran/Cray-pointers.html#Cray-pointers

That's a tad bit harsh.  I don't recall Russell reporting previous
bugs/issues.  Don't want to scare off a potential contributor. :)

Russell, there is no "correct etiquette" when inferring about
the status of a bug.  Unfortunately, the reality of the situation
is that there are too few gfortran developers and too many issues.
That is, there is a man power problem.  A gfortran developer typically
fixes bugs that effect his own ability to use gfortran or, well, bugs
that he knows how to fix.  The individual who implemented the Cray
pointer feature (and the person with the most intimate knowledge of
how it works) hasn't contributed to gfortran in a long time, which is 
understandable in that the priorities of volunteers do change.

Dominique's advise of not mixing vendor extensions with newer
Fortran features (i.e., cray pointers and modules) is well intended.

I know this above isn't what you want to read, but unfortunately,
it is the reality of the situation.
Comment 11 russelldub 2014-12-07 22:08:16 UTC
> > Nasty answer: what did you do to fix it?
> > 
> > I RTFM and saw at
> > https://gcc.gnu.org/onlinedocs/gfortran/Cray-pointers.html#Cray-pointers
> 
> That's a tad bit harsh.  I don't recall Russell reporting previous
> bugs/issues.  Don't want to scare off a potential contributor. :)

It would be a fair enough response if I had gotten any response when I did do some work and provided code on another PR (PR 40958).  As it is, it's fairly discouraging.
Comment 12 Joost VandeVondele 2014-12-08 06:22:54 UTC
(In reply to russelldub from comment #11)
> > > Nasty answer: what did you do to fix it?

> > That's a tad bit harsh.  I don't recall Russell reporting previous
> > bugs/issues.  Don't want to scare off a potential contributor. :)
> 
> It would be a fair enough response if I had gotten any response when I did
> do some work and provided code on another PR (PR 40958).  As it is, it's
> fairly discouraging.

It is indeed not so easy to really get code accepted... concerning the patch in PR40958, you need to post to gcc-patches@ and fortran@ to get the discussion started. Patches in bugzilla are seldom noticed/committed by somebody else.
Comment 13 kargls 2018-03-13 19:18:10 UTC
I intend to close this PR after updating the information
about Cray pointers and an assumed-sized array.  The
Fortran clearly states


8.5.8.5 Assumed-size array
An assumed-size array is a dummy argument array whose size
is assumed from that of its effective argument, ...

An assumed-sized simply cannot appear in the specification
portion of a module. The text in gfortran.info will be


    The pointer is an integer that is intended to hold
    a memory address. The pointee may be an array or scalar.
    If an assumed-size array is permitted within the scoping
    unit, a pointee can be an assumed-size array. That is, the
    last dimension may be left unspecified by using a * in place
    of a value. A pointee cannot be an assumed shape array. No
    space is allocated for the pointee.

Index: gfortran.texi
===================================================================
--- gfortran.texi       (revision 258468)
+++ gfortran.texi       (working copy)
@@ -1906,10 +1906,13 @@ or,
         pointer ( <pointer1> , <pointee1> ), ( <pointer2> , <pointee2> ), ...
 @end smallexample
 The pointer is an integer that is intended to hold a memory address.
-The pointee may be an array or scalar.  A pointee can be an assumed
-size array---that is, the last dimension may be left unspecified by
-using a @code{*} in place of a value---but a pointee cannot be an
-assumed shape array.  No space is allocated for the pointee.
+The pointee may be an array or scalar.
+If an assumed-size array is permitted within the scoping unit, a
+pointee can be an assumed-size array.
+That is, the last dimension may be left unspecified by using a @code{*}
+in place of a value.
+A pointee cannot be an assumed shape array.
+No space is allocated for the pointee.
 
 The pointee may have its type declared before or after the pointer
 statement, and its array specification (if any) may be declared
Comment 14 kargls 2018-05-13 17:18:36 UTC
Author: kargl
Date: Sun May 13 17:18:05 2018
New Revision: 260213

URL: https://gcc.gnu.org/viewcvs?rev=260213&root=gcc&view=rev
Log:
2018-05-13  Steven G. Kargl  <kargl@gcc.gnu.org>

	PR fortran/63529
	* gfortran.texi: Clarify documentation for Cray pointer and
	assumed-sized array.

Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/gfortran.texi
Comment 15 kargls 2018-05-13 17:21:16 UTC
I've committed the documentation update from comment #13.

Russell, thanks for the report, and sorry it took
so long to determine what to do with it.