[Bug fortran/60780] Equivalence statements in nested modules results in fast growing duplicate statements in module files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60780 --- Comment #8 from russelldub at gmail dot com --- > May be the patch should be submitted to fort...@gcc.gnu.org (for next stage1). I'd be happy if this could be resolved. Should I submit or someone with more clout among the gfortran maintainers/developers?
[Bug fortran/63529] Bad error and ICE with Cray Pointers in Modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63529 --- Comment #11 from russelldub at gmail dot com --- > > 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.
[Bug fortran/63529] Bad error and ICE with Cray Pointers in Modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63529 --- Comment #8 from russelldub at gmail dot com --- 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.
[Bug fortran/63529] Bad error and ICE with Cray Pointers in Modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63529 --- Comment #7 from russelldub at gmail dot com --- (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.
[Bug fortran/63529] Bad error and ICE with Cray Pointers in Modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63529
--- Comment #5 from russelldub at gmail dot com ---
> 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.
[Bug fortran/63529] Bad error and ICE with Cray Pointers in Modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63529 --- Comment #4 from russelldub at gmail dot com --- > 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 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)
[Bug fortran/63529] Bad error and ICE with Cray Pointers in Modules
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) > > 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?
[Bug fortran/63529] New: Bad error and ICE with Cray Pointers in Modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63529 Bug ID: 63529 Summary: Bad error and ICE with Cray Pointers in Modules Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: russelldub at gmail dot com 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.
[Bug fortran/40958] module files too large
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958 --- Comment #18 from russelldub at gmail dot com --- Created attachment 33703 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33703&action=edit Proposed patch to fix module equivalence duplicates Here is a proposed fix for the problem related to equivalence statements in nested/recursive use (see also PR 60780). I've run 'make check-fortran' on rev. 216017 with and without this patch had a FAIL on gfortran.dg/typebound_operator_3.f03 (as discussed in PR 63404) both ways.
[Bug fortran/60780] Equivalence statements in nested modules results in fast growing duplicate statements in module files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60780 --- Comment #4 from russelldub at gmail dot com --- Any hope for movement on this? I've made some attempts at diagnosing the issue, but not sure why equivalences behave differently than other statements in the modules.
[Bug fortran/60780] Equivalence statements in nested modules results in fast growing duplicate statements in module files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60780 --- Comment #3 from russelldub at gmail dot com --- Any hope for movement on this? I've made some attempts at diagnosing the issue, but not sure why equivalences behave differently than other statements in the modules.
[Bug fortran/60780] Equivalence statements in nested modules results in fast growing duplicate statements in module files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60780 --- Comment #1 from russelldub at gmail dot com --- > Equivalence statements in equivalence statements Should read "Equivalence statements in modules". Apologies.
[Bug fortran/60780] New: Equivalence statements in nested modules results in fast growing duplicate statements in module files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60780 Bug ID: 60780 Summary: Equivalence statements in nested modules results in fast growing duplicate statements in module files Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: russelldub at gmail dot com Created attachment 32558 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32558&action=edit Code to reproduce issue. Equivalence statements in equivalence statements results in quickly growing number of duplicated statements in nested module files. The attached file shows the issue. Compiled with > gfortran equiv_mod.f90 Resulting module files grow from 3.1 kb to 128 kb. (This issue is somewhat mitigated by compressing modules in latest gfortran, but duplicate statements still exist). The fortran interface to HDF5 is affected by this. In code that uses HDF5 in nested fashion module files can grow to multiple GB in size resulting in ICE when memory is exhausted. May be related to pr 38171. Reproduced in 4.4.7, 4.6.1, 4.8.2 and recent git clone.
