[Bug fortran/28788] [gfortran: 4.1, 4.2 regression] ICE on valid code
--- Comment #18 from pault at gcc dot gnu dot org 2006-08-30 04:37 --- Fixed on trunk and 4.1 again Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28788
[Bug fortran/28788] [gfortran: 4.1, 4.2 regression] ICE on valid code
--- Comment #15 from paul dot richard dot thomas at cea dot fr 2006-08-28 11:56 --- Created an attachment (id=12146) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12146action=view) Fix and two test cases for the latest regressions I post this now, as a prelude to submitting the patch in the next 24 hours. Before doing so, I want to check that all the derived type symbols get cleaned up and to try a last ditch attemt to identify the references that cause these regressions. The patch regtests on Cygwin_NT/PIV and Martin Reinecke confirms that it compiles his real-life code correctly. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28788
[Bug fortran/28788] [gfortran: 4.1, 4.2 regression] ICE on valid code
--- Comment #16 from pault at gcc dot gnu dot org 2006-08-29 04:51 --- Subject: Bug 28788 Author: pault Date: Tue Aug 29 04:51:32 2006 New Revision: 116552 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116552 Log: 2006-08-29 Paul Thomas [EMAIL PROTECTED] PR fortran/28788 REGRESSION FIX * symbol.c (gfc_use_derived): Never eliminate the symbol, following reassociation of use associated derived types. 2006-08-29 Paul Thomas [EMAIL PROTECTED] PR fortran/28788 * gfortran.dg/used_types_5.f90: New test. * gfortran.dg/used_types_6.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/used_types_5.f90 trunk/gcc/testsuite/gfortran.dg/used_types_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/symbol.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28788
[Bug fortran/28788] [gfortran: 4.1, 4.2 regression] ICE on valid code
--- Comment #17 from pault at gcc dot gnu dot org 2006-08-29 04:57 --- Subject: Bug 28788 Author: pault Date: Tue Aug 29 04:57:29 2006 New Revision: 116553 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116553 Log: 2006-08-29 Paul Thomas [EMAIL PROTECTED] PR fortran/28788 REGRESSION FIX * symbol.c (gfc_use_derived): Never eliminate the symbol, following reassociation of use associated derived types. 2006-08-29 Paul Thomas [EMAIL PROTECTED] PR libfortran/28005 * m4/matmul.m4: Working part of function ported from trunk. * generated/matmul_r4.c: Regenerate. * generated/matmul_r8.c: Regenerate. * generated/matmul_r10.c: Regenerate. * generated/matmul_r16.c: Regenerate. * generated/matmul_c4.c: Regenerate. * generated/matmul_c8.c: Regenerate. * generated/matmul_c10.c: Regenerate. * generated/matmul_c16.c: Regenerate. * generated/matmul_i4.c: Regenerate. * generated/matmul_i8.c: Regenerate. * generated/matmul_i16.c: Regenerate. 2006-08-29 Paul Thomas [EMAIL PROTECTED] PR fortran/28788 * gfortran.dg/used_types_5.f90: New test. * gfortran.dg/used_types_6.f90: New test. PR fortran/28005 * gfortran.dg/matmul_3.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/matmul_3.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/used_types_5.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/used_types_6.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/symbol.c branches/gcc-4_1-branch/libgfortran/ChangeLog branches/gcc-4_1-branch/libgfortran/generated/matmul_c10.c branches/gcc-4_1-branch/libgfortran/generated/matmul_c16.c branches/gcc-4_1-branch/libgfortran/generated/matmul_c4.c branches/gcc-4_1-branch/libgfortran/generated/matmul_c8.c branches/gcc-4_1-branch/libgfortran/generated/matmul_i16.c branches/gcc-4_1-branch/libgfortran/generated/matmul_i4.c branches/gcc-4_1-branch/libgfortran/generated/matmul_i8.c branches/gcc-4_1-branch/libgfortran/generated/matmul_r10.c branches/gcc-4_1-branch/libgfortran/generated/matmul_r16.c branches/gcc-4_1-branch/libgfortran/generated/matmul_r4.c branches/gcc-4_1-branch/libgfortran/generated/matmul_r8.c branches/gcc-4_1-branch/libgfortran/m4/matmul.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28788
[Bug fortran/28788] [gfortran: 4.1, 4.2 regression] ICE on valid code
--- Comment #12 from paulthomas2 at wanadoo dot fr 2006-08-26 09:30 ---
Subject: Re: [gfortran: 4.1, 4.2 regression] ICE on valid
code
Jerry and Martin,
All of this is very depressing - I can reproduce the 32 bit version of
the problem and, I suppose, will reproduce the 64 bit version in a
moment. There are three things that really start me scratching my head:
(i) gcc-4.2 has it that there is a format error in the module file itself:
[EMAIL PROTECTED] f90bug]# /svn-4.2/bin/gfortran -I./*.mod -c lensing.f90
Fatal Error: Reading module modelparams at line 27 column 73: Expected
integer;
(ii) This difficulty disappears if I use 4.1; and
(iii) I cannot for the life of me understand what the -I. would do to
affect the parsing and processing of the .mod file. (Jerry, is there any
recent IO library modification that would do this?)
Still worse and what has me completely floored is this
module z
type :: x
integer :: i
end type x
end module z
module modeldata
use z
type :: cltransferdata
type(x) :: ls
integer :: numsources
integer :: num_q_int
real(8) :: q_int
real(8) :: dq_int
real(8) :: delta_p_l_k
end type cltransferdata
end module modeldata
Produces a modeldata.mod like this:
GFORTRAN module created from tests.f90 on Sat Aug 26 10:43:24 2006
If you edit this, you'll get what you deserve.
(() () () ()
() () () () () () () () () () () () () () () () ())
()
()
()
()
(2 'cltransferdata' 'modeldata' 1 ((DERIVED UNKNOWN-INTENT UNKNOWN-PROC
UNKNOWN) (UNKNOWN 0 ()) 0 0 () () 0 ((3 'ls' (DERIVED 4 ()) () 0 0 0 ())
(5 'numsources' (INTEGER 4 ()) () 0 0 0 ()) (6 'num_q_int' (INTEGER 4 ())
() 0 0 0 ()) (7 'q_int' (REAL 8 ()) () 0 0 0 ()) (8 'dq_int' (REAL 8 ())
() 0 0 0 ()) (9 'delta_p_l_k' (REAL 8 ()) () 0 0 0 ())) PUBLIC ())
4 'x' 'z' 1 ((DERIVED UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN) (UNKNOWN 0 ())
0 0 () () 0 ((10 'i' (INTEGER 4 ()) () 0 0 0 ())) PUBLIC ())
11 'z' 'z' 1 ((MODULE UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN) (UNKNOWN 0 ())
0 0 () () 0 () ())
12 'modeldata' 'modeldata' 1 ((MODULE UNKNOWN-INTENT UNKNOWN-PROC
UNKNOWN) (UNKNOWN 0 ()) 0 0 () () 0 () ())
)
('modeldata' 0 12 'cltransferdata' 0 2 'z' 0 11 'x' 0 4)
Note the entry starting with (2 'cltransferdata'... ; this has a
reference to the component 'ls' on the next line. (3 'ls' (DERIVED 4 ())
says that 'ls' is derived and is of a type that is defined in entry 4.
This entry is:
4 'x' 'z' 1 ((DERIVED UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN) (UNKNOWN 0 ())
0 0 () () 0 ((10 'i' (INTEGER 4 ()) () 0 0 0 ())) PUBLIC ())
which says that it is declared in module z, is derived and has an
integer component i.
with the -I. option, like you, I get
use ModelData
1
Error: The component 'ls' is a PRIVATE type and cannot be a component of
'cltransferdata', which is PUBLIC at (1)
(Why is it this USE statement and not others, either before or after?)
Anyway, ignoring this last question for the time being, I find in
modeldata.mod the entry(line 55)
24 'cltransferdata' 'modeldata' 1 ((DERIVED UNKNOWN-INTENT UNKNOWN-PROC
UNKNOWN) (UNKNOWN 0 ()) 0 0 () () 0 ((25 'ls' (DERIVED 26 ()) () 0 0 ())
(27 'numsources' (INTEGER 4 ()) () 0 0 ()) (28 'num_q_int' (INTEGER 4 ())
() 0 0 ()) (29 'q_int' (REAL 8 ()) (1 DEFERRED () ()) 1 1 ()) (30 'dq_int'
(REAL 8 ()) (1 DEFERRED () ()) 1 1 ()) (31 'delta_p_l_k' (REAL 8 ()) (3
DEFERRED () () () () () ()) 1 1 ())) PUBLIC ())
You will see that 'ls' is of derived type declared in entry 26, which is
present in the file but out of order. That said, it does not matter
where I put it, nor is it PRIVATE.
PRIVATE objects do not appear at all in .mod files.
I will think some more about this but I will, at the same time, prepare
the patch to revert to the original state, with the kludged up version,
in resolve.c, of the fixes for the PRs. The release of 4.2.0 is
looming! This is such a pity because the current version of derived
type association is so much better in principle.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28788
[Bug fortran/28788] [gfortran: 4.1, 4.2 regression] ICE on valid code
--- Comment #13 from aovb94 at dsl dot pipex dot com 2006-08-26 12:15 --- I'm getting an ICE and segmentation fault in the following code. I think it may be related to Paul Thomas's observation about pointers to components of derived type arrays. However, it does compile under these circumstances: * when foo and bar are not in the module * when the module contains foo or bar but not both * when the types a and b have no reference to each other * when , only, a (or b) is not used on the use statement MODULE type_mod TYPE a INTEGER :: n(10) END TYPE a ! TYPE b TYPE (a), POINTER :: m(:) = NULL () END TYPE b END MODULE type_mod MODULE seg_mod CONTAINS SUBROUTINE foo (x) USE type_mod, ONLY : a ! fails ! USE type_mod ! works IMPLICIT NONE TYPE (a) :: x ! RETURN END SUBROUTINE foo ! SUBROUTINE bar (x) USE type_mod, ONLY : b ! fails ! USE type_mod ! works IMPLICIT NONE TYPE (b) :: x ! RETURN END SUBROUTINE bar END MODULE seg_mod gfc -c type_mod.f95 seg_mod.f95 seg_mod.f95:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. gfc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --enable-languages=c,fortran --prefix=/home/martin/GCC/usr/local --disable-nls --disable-multilib --enable-shared --enable-threads=posix --disable-checking --enable-long-long --enable-__cxa_atexit --enable-clocale=gnu --disable-libunwind-exception Thread model: posix gcc version 4.2.0 20060825 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28788
[Bug fortran/28788] [gfortran: 4.1, 4.2 regression] ICE on valid code
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2006-08-26 21:27 --- With latest svn update and full bootstrap with Martins case above on i686-linux-pc-gnu: (gdb) r Starting program: /home/jerry/bin/f951 newbug.f90 Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0x43229000 Warning: Reading file 'stdin' as free form. .file stdin Program received signal SIGSEGV, Segmentation fault. 0x0809e8f8 in gfc_use_derived (sym=0x894b7e0) at ../../gcc42/gcc/fortran/symbol.c:1561 1561 st-n.sym = s; (gdb) bt #0 0x0809e8f8 in gfc_use_derived (sym=0x894b7e0) at ../../gcc42/gcc/fortran/symbol.c:1561 #1 0x0809e834 in gfc_use_derived (sym=0x8949a98) at ../../gcc42/gcc/fortran/symbol.c:1538 #2 0x0805ba02 in gfc_match_data_decl () at ../../gcc42/gcc/fortran/decl.c:2261 #3 0x080851fa in match_word (str=Variable str is not available. ) at ../../gcc42/gcc/fortran/parse.c:65 #4 0x0808579d in decode_statement () at ../../gcc42/gcc/fortran/parse.c:134 #5 0x0808612e in next_statement () at ../../gcc42/gcc/fortran/parse.c:493 #6 0x08087ddc in parse_spec (st=ST_IMPLICIT_NONE) at ../../gcc42/gcc/fortran/parse.c:1855 #7 0x08088299 in parse_progunit (st=Variable st is not available. ) at ../../gcc42/gcc/fortran/parse.c:2855 #8 0x080884e2 in parse_contained (module=1) at ../../gcc42/gcc/fortran/parse.c:2801 #9 0x08088b03 in gfc_parse_file () at ../../gcc42/gcc/fortran/parse.c:3040 #10 0x080a9e0d in gfc_be_parse_file (set_yydebug=0) at ../../gcc42/gcc/fortran/f95-lang.c:303 #11 0x0839fcc5 in toplev_main (argc=1, argv=0xbfa4fc14) at ../../gcc42/gcc/toplev.c:999 #12 0x080ddf6f in main (argc=Cannot access memory at address 0x ) at ../../gcc42/gcc/main.c:35 (gdb) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28788
[Bug fortran/28788] [gfortran: 4.1, 4.2 regression] ICE on valid code
--- Comment #7 from martin at mpa-garching dot mpg dot de 2006-08-25 12:57 --- Hi Paul, sorry for the late reply, I was away for a few days. I compiled the most recent gcc sources, and there still appears to be some bad memory access inside gfortran, which causes the compiler to sometimes work fine sometimes, sometimes give incorrect errors, and sometimes segfault :( I have a testcase where gfortran works fine, but reports a bogus error when I add -I. to the command line. I fear the best way to locate this is to use valgrind or something similar on the compiler, and I don't manage to produce a small (single-file) testcase at the moment. Any ideas what I could do? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28788
[Bug fortran/28788] [gfortran: 4.1, 4.2 regression] ICE on valid code
--- Comment #8 from paulthomas2 at wanadoo dot fr 2006-08-25 13:25 --- Subject: Re: [gfortran: 4.1, 4.2 regression] ICE on valid code martin, --- Comment #7 from martin at mpa-garching dot mpg dot de 2006-08-25 12:57 --- Hi Paul, sorry for the late reply, I was away for a few days. I compiled the most recent gcc sources, and there still appears to be some bad memory access inside gfortran, which causes the compiler to sometimes work fine sometimes, sometimes give incorrect errors, and sometimes segfault :( I have a testcase where gfortran works fine, but reports a bogus error when I add -I. to the command line. I fear the best way to locate this is to use valgrind or something similar on the compiler, and I don't manage to produce a small (single-file) testcase at the moment. Any ideas what I could do? Perhaps you can let me have an idea of the kind of code that is doing this? Is this a continuation of the derived type problem or did it exist prior to the patch of a week back? A good starting point is to use gdb on $yourgccpath/libexec/gcc/i*/4.2.0/f951 ; Then run command line Best regards Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28788
[Bug fortran/28788] [gfortran: 4.1, 4.2 regression] ICE on valid code
--- Comment #9 from martin at mpa-garching dot mpg dot de 2006-08-25 14:36 --- Created an attachment (id=12139) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12139action=view) new testcase Compile with gfortran -c lensing.f90 and with gfortran -c -I. lensing.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28788
[Bug fortran/28788] [gfortran: 4.1, 4.2 regression] ICE on valid code
--- Comment #10 from martin at mpa-garching dot mpg dot de 2006-08-25 14:37 --- Perhaps you can let me have an idea of the kind of code that is doing this? Is this a continuation of the derived type problem or did it exist prior to the patch of a week back? I don't think it existed before your patch last week, but I cannot be absolutely sure, since I don't test the most recent gfortran every day. However the behaviour is similar to the one you fixed with your latest patch. I'm going to attach a small test package, which you can try by running gfortran -c lensing.f90. The funny thing is this: - with gcc compiled on a P4, this compiles without an error - if I add (on the same machine) the flag -I., I get: In file lensing.f90:599 use ModelData 1 Error: The component 'ls' is a PRIVATE type and cannot be a component of 'cltransferdata', which is PUBLIC at (1) - with gcc compiled on an Athlon64, I get (independent of -I.): lensing.f90:0: internal compiler error: Segmentation fault -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28788
[Bug fortran/28788] [gfortran: 4.1, 4.2 regression] ICE on valid code
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2006-08-25 17:09 --- On x86-64 linux: (gdb) set args lensing.f90 (gdb) r Starting program: /home/jerry/bin/f951 lensing.f90 Warning: Reading file 'stdin' as free form. .file stdin In file :598 use ModelParams 1 Error: The derived type 'p' at (1) is of type 'pp', which has not been defined. In file :415 use ModelParams 1 Error: The derived type 'p' at (1) is of type 'bessel0', which has not been defined. In file :82 use ModelParams 1 Program received signal SIGSEGV, Segmentation fault. error_string (p=0x3 Address 0x3 out of bounds) at ../../gcc42/gcc/fortran/error.c:112 112 while (*p) (gdb) bt #0 error_string (p=0x3 Address 0x3 out of bounds) at ../../gcc42/gcc/fortran/error.c:112 #1 0x00417c6a in error_print (type=Variable type is not available. ) at ../../gcc42/gcc/fortran/error.c:409 #2 0x0041809d in gfc_error (nocmsgid=Variable nocmsgid is not available. ) at ../../gcc42/gcc/fortran/error.c:611 #3 0x0044c820 in resolve_symbol (sym=0xcfa1d0) at ../../gcc42/gcc/fortran/resolve.c:5656 #4 0x00454e1e in traverse_ns (st=0xcfb5c0, func=0x44bb60 resolve_symbol) at ../../gcc42/gcc/fortran/symbol.c:2650 #5 0x00454e06 in traverse_ns (st=0xcfb600, func=0x44bb60 resolve_symbol) at ../../gcc42/gcc/fortran/symbol.c:2653 #6 0x0044931f in resolve_types (ns=0xcef530) at ../../gcc42/gcc/fortran/resolve.c:6628 #7 0x0044bb3d in gfc_resolve (ns=0xcef530) at ../../gcc42/gcc/fortran/resolve.c:6703 #8 0x0044bcb4 in resolve_symbol (sym=0xce4740) at ../../gcc42/gcc/fortran/resolve.c:5729 #9 0x00454e1e in traverse_ns (st=0xcd2c40, func=0x44bb60 resolve_symbol) at ../../gcc42/gcc/fortran/symbol.c:2650 #10 0x00454e06 in traverse_ns (st=0xceec90, func=0x44bb60 resolve_symbol) at ../../gcc42/gcc/fortran/symbol.c:2653 #11 0x00454e06 in traverse_ns (st=0xcc9170, func=0x44bb60 resolve_symbol) at ../../gcc42/gcc/fortran/symbol.c:2653 #12 0x00454e06 in traverse_ns (st=0xccb0d0, func=0x44bb60 resolve_symbol) at ../../gcc42/gcc/fortran/symbol.c:2653 #13 0x00454e06 in traverse_ns (st=0xcd2700, func=0x44bb60 resolve_symbol) at ../../gcc42/gcc/fortran/symbol.c:2653 #14 0x00454e06 in traverse_ns (st=0xcc8cb0, func=0x44bb60 resolve_symbol) at ../../gcc42/gcc/fortran/symbol.c:2653 #15 0x0044931f in resolve_types (ns=0xcc62f0) at ../../gcc42/gcc/fortran/resolve.c:6628 #16 0x004493eb in resolve_types (ns=0xcc4500) at ../../gcc42/gcc/fortran/resolve.c:6639 #17 0x0044bb3d in gfc_resolve (ns=0xcc4500) at ../../gcc42/gcc/fortran/resolve.c:6703 #18 0x00441418 in gfc_parse_file () at ../../gcc42/gcc/fortran/parse.c:3197 #19 0x00460bbe in gfc_be_parse_file (set_yydebug=Variable set_yydebug is not available. ) at ../../gcc42/gcc/fortran/f95-lang.c:303 #20 0x0074aa53 in toplev_main (argc=Variable argc is not available. ) at ../../gcc42/gcc/toplev.c:999 #21 0x003816e1ce54 in __libc_start_main () from /lib64/libc.so.6 #22 0x00403d99 in _start () #23 0x7fff8414b8c8 in ?? () #24 0x in ?? () (gdb) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28788
[Bug fortran/28788] [gfortran: 4.1, 4.2 regression] ICE on valid code
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-08-23 13:20 --- Created an attachment (id=12117) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12117action=view) Fix for this and Martin Tee's submission to the list Martin, I would be very grateful if you would test this patch to see if it fixes your problem in the flesh. It is just now regression testing and I will run the tonto and Polyhedron testsuites before submitting it. Thanks for coming back with the problem so quickly. Whilst I was willing to be surprised, I did expect some fall-out from the derived type reform. Sorry for any inconvenience. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28788
[Bug fortran/28788] [gfortran: 4.1, 4.2 regression] ICE on valid code
--- Comment #4 from patchapp at dberlin dot org 2006-08-23 14:51 --- Subject: Bug number PR28788 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00831.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28788
[Bug fortran/28788] [gfortran: 4.1, 4.2 regression] ICE on valid code
--- Comment #5 from pault at gcc dot gnu dot org 2006-08-24 04:47 --- Subject: Bug 28788 Author: pault Date: Thu Aug 24 04:47:28 2006 New Revision: 116369 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116369 Log: 2006-08-23 Paul Thomas [EMAIL PROTECTED] PR fortran/28788 * gfortran.dg/used_types_4.f90: New test. * gfortran.dg/derived_init_2.f90: Modify to check sibling association of derived types. * gfortran.dg/used_types_2.f90: Add module cleanup. * gfortran.dg/used_types_3.f90: The same. PR fortran/28771 * gfortran.dg/assumed_charlen_in_main.f90: Modify to check fix of regression. 2006-08-23 Paul Thomas [EMAIL PROTECTED] PR fortran/28788 * gfortran.dg/used_types_4.f90: New test. * gfortran.dg/derived_init_2.f90: Modify to check sibling association of derived types. * gfortran.dg/used_types_2.f90: Add module cleanup. * gfortran.dg/used_types_3.f90: The same. PR fortran/28771 * gfortran.dg/assumed_charlen_in_main.f90: Modify to check fix of regression. Added: trunk/gcc/testsuite/gfortran.dg/used_types_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/assumed_charlen_in_main.f90 trunk/gcc/testsuite/gfortran.dg/derived_init_2.f90 trunk/gcc/testsuite/gfortran.dg/used_types_2.f90 trunk/gcc/testsuite/gfortran.dg/used_types_3.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28788
[Bug fortran/28788] [gfortran: 4.1, 4.2 regression] ICE on valid code
--- Comment #6 from pault at gcc dot gnu dot org 2006-08-24 04:54 --- Subject: Bug 28788 Author: pault Date: Thu Aug 24 04:54:18 2006 New Revision: 116370 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116370 Log: 2006-08-24 Paul Thomas [EMAIL PROTECTED] PR fortran/28788 * symbol.c (shift_types): Shift the derived type references in formal namespaces. (gfc_use_derived): Return if the derived type symbol is already in another namspace. Add searches for the derived type in sibling namespaces. PR fortran/28771 * decl.c (add_init_expr_to_sym): Restore the original but restricted to parameter arrays to fix a regression. 2006-08-24 Paul Thomas [EMAIL PROTECTED] PR fortran/28788 * gfortran.dg/used_types_4.f90: New test. * gfortran.dg/used_types_2.f90: Add module cleanup. * gfortran.dg/used_types_3.f90: The same. PR fortran/28771 * gfortran.dg/assumed_charlen_in_main.f90: Modify to check fix of regression. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/used_types_4.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/decl.c branches/gcc-4_1-branch/gcc/fortran/symbol.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/assumed_charlen_in_main.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/used_types_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/used_types_3.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28788
[Bug fortran/28788] [gfortran: 4.1, 4.2 regression] ICE on valid code
--- Comment #2 from pault at gcc dot gnu dot org 2006-08-22 20:02 --- I have figured out what the problem is: The module procedure formal arguments go into their own namespace; derived type references pointing to the contained namespace. In the reformed association of derived types, the symbols to which the formal arguments are pointing are removed when host association occurs. It is something of a miracle that the old system works - it certainly was not intentional! Now for a clean solution! Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28788
[Bug fortran/28788] [gfortran: 4.1, 4.2 regression] ICE on valid code
--- Comment #1 from pault at gcc dot gnu dot org 2006-08-22 05:30 --- This problem was not present a few days ago, and it is quite elusive. Even adding or removing a few !innocent lines can change the error message, e.g. to something like This is my doing, for which I apologise. I cannnot see why, right now, but the variable 'p' is picking up a broken derived type that has junk for its name. A workaround is to comment out the last 'use ModelParams'; the host associated version of the derived type is OK. I am on to it. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-08-22 05:30:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28788
