$ /usr/local/gfortran/bin/gfortran --save-temps -c -fno-second-underscore -fdefault-integer-8 -m64 -DMOLPRO -I. -I.. -I../global f12_integrals.f f12_integrals.f: In function 'dfasmbl_f12': f12_integrals.f:2850: internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:950 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. $ gfortran -v Using built-in specs. Target: i386-apple-darwin8.10.1 Configured with: /tmp/gfortran-20090321/ibin/../gcc/configure --prefix=/usr/local/gfortran --enable-languages=c,fortran --with-gmp=/tmp/gfortran-20090321/gfortran_libs --enable-bootstrap Thread model: posix gcc version 4.4.0 20090321 (experimental) [trunk revision 144983] (GCC)
Created attachment 17566 [details] tarball containing source file and its includes
Confirmed for gfortran 4.4 and trunk, works on 4.3. Reduced test case: module df_f12_integrals implicit double precision (a-h,o-z) save c parameter (maxint=2147483647) common/zahl/ z0,z1,z2,z4,z05,z10h6,z10hm8,z10m12 CONTAINS c----------------------------------------------------------------------- subroutine dfasmbl_f12(nibatch,numbti,lenbta,lenbtc, > namout,ifout,offset,iaddmat,fac, > cpu_asmbl,flops_asmbl,title) c----------------------------------------------------------------------- implicit double precision (a-h,o-z) c parameter (maxint=2147483647) common/zahl/ z0,z1,z2,z4,z05,z10h6,z10hm8,z10m12 if(icase.gt.1) call writem_big(g,leng,ifout,namout,z0,'EX') end subroutine dfasmbl_f12 end [ibook-dhum] Downloads/gfortranbug% gfc44 -c dfasmbl_f12_no.f dfasmbl_f12_no.f: In function 'dfasmbl_f12': dfasmbl_f12_no.f:11: internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:950 If one of the COMMON or IF lines is commented, the ICE disappears. Next time please take some time to do the reduction yourself.
My apologies that I did not do some reduction, which of course I could have easily done. I was merely following the guidelines at http://gcc.gnu.org/bugs.html which says lots of things, but does not mention this as desirable.
> My apologies that I did not do some reduction, ... After having sent my post, I have realized that it was more unfriendly than intended (and I agree that the instructions could be more explicit than "Please avoid posting an archive ..."). Reduced tests are necessary not only to fix the bug, but also for the test suite. May be you can do the exercise for PR39595, although Richard has probably a clear idea about where to look at. Thanks for the reports.
> May be you can do the exercise for PR39595 ... Already done! These guys are incredibly fast!
More simplified testcase: module pr39594 implicit double precision(z) common /z/ z0,z1,z2,z3,z4,z5,z6,z7 contains subroutine foo implicit double precision(z) common /z/ z0,z1,z2,z3,z4,z5,z6,z7 call bar(z0) end subroutine foo end In the module it doesn't matter if implicit or double precision z0,z1,z2,z3,z4,z5,z6,z7 is used, in foo it fixes the ICE.
Jakub, could you mark this PR as a 4.4/4.5 regression? TIA
Regressed since PR36592: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140790
I guess it is the gfc_add_flavor call removal from gfc_add_in_common that causes this, attr->flavor in this case is FL_UNKNOWN.
(In reply to comment #9) > I guess it is the gfc_add_flavor call removal from gfc_add_in_common that > causes this, attr->flavor in this case is FL_UNKNOWN. Good guess: The problem is a check in gfc_create_module_variable. I tried the following patch, but it still fails - FL_VARIABLE is properly set but if (sym->attr.use_assoc || sym->attr.in_common) return; comes just before the /* We always want module variables to be created. */ sym->attr.referenced = 1; Index: resolve.c =================================================================== --- resolve.c (revision 145366) +++ resolve.c (working copy) @@ -719,6 +719,9 @@ resolve_common_vars (gfc_symbol *sym, bo gfc_error_now ("Derived type variable '%s' in COMMON at %L " "may not have default initializer", csym->name, &csym->declared_at); + + if (csym->attr.flavor == FL_UNKNOWN && !csym->attr.proc_pointer) + gfc_add_flavor (&csym->attr, FL_VARIABLE, csym->name, &csym->declared_at); } }
Mine. Working patch posted at http://gcc.gnu.org/ml/fortran/2009-04/msg00009.html I forgot to thank you, Peter, for reporting the bug. (And Jakub for quickly reducing it and finding the offending check in.)
It's a pleasure, and also amazing to see you folks work so quickly on this. The context for the report is our large code (http://www.molpro.net) which hopefully now for the first time will build correctly with released gcc on linux and Darwin. Lots of our users will be happy about this.
Subject: Bug 39594 Author: burnus Date: Fri Apr 3 18:26:44 2009 New Revision: 145513 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145513 Log: 2009-04-03 Tobias Burnus <burnus@net-b.de> PR fortran/39594 * resolve.c (resolve_common_vars): Add FL_VARIABLE to symbol if it is not a procedure pointer. * primary.c (match_actual_arg): Ditto. 2009-04-03 Tobias Burnus <burnus@net-b.de> PR fortran/39594 * gfortran.dg/common_12.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/common_12.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
Subject: Bug 39594 Author: burnus Date: Fri Apr 3 20:56:54 2009 New Revision: 145519 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145519 Log: 2009-04-03 Tobias Burnus <burnus@net-b.de> PR fortran/39594 * resolve.c (resolve_common_vars): Add FL_VARIABLE to symbol if it is not a procedure pointer. * primary.c (match_actual_arg): Ditto. 2009-04-03 Tobias Burnus <burnus@net-b.de> PR fortran/39594 * gfortran.dg/common_12.f90: New. Added: branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/common_12.f90 Modified: branches/gcc-4_4-branch/gcc/fortran/ChangeLog branches/gcc-4_4-branch/gcc/fortran/primary.c branches/gcc-4_4-branch/gcc/fortran/resolve.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
FIXED on the trunk (4.5) and on the 4.4.0 branch. Hopefully that is all what is needed for Molpro.