[Bug fortran/28788] New: [gfortran: 4.1, 4.2 regression] ICE on valid code

[Bug fortran/28788] New: [gfortran: 4.1, 4.2 regression] ICE on valid code

[martin at mpa-garching dot mpg dot de]

Current gfortran (trunk and head of 4.1 branch) segfaults when compiling the
following code:

module Precision
  integer, parameter :: dl = KIND(1.d0)
end module Precision

module ModelParams
use precision

type CAMBparams
  real(dl)::omegab,h0,tcmb,yhe
end type

type (CAMBparams) :: CP

contains

subroutine CAMBParams_Set(P)
  type(CAMBparams), intent(in) :: P
end subroutine CAMBParams_Set

end module ModelParams

module TimeSteps
use precision
use ModelParams

end module TimeSteps

module ThermoData
use TimeSteps
contains
subroutine inithermo(taumin,taumax)
  use precision
  use ModelParams
  real(dl) taumin,taumax

  call InitRECFAST(CP%omegab,CP%h0,CP%tcmb,CP%yhe)
end subroutine inithermo

end module ThermoData

martin@linux:~/tmp> gfortran -v -c modules.F90
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /home/martin/software/gcc/configure --disable-multilib
--with-gmp=/home/martin/software/mygmp --with-mpfr=/home/martin/software/mympfr
--prefix=/home/martin/software/ugcc --enable-languages=c++,fortran
--enable-checking=release
Thread model: posix
gcc version 4.2.0 20060821 (experimental)
 /home/martin/software/ugcc/libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/cc1 -E
-lang-fortran -traditional-cpp -D_LANGUAGE_FORTRAN -quiet -v modules.F90
-mtune=generic -o /tmp/ccNsJVqs.f95
ignoring nonexistent directory
"/home/martin/software/ugcc/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /home/martin/software/ugcc/include
 /home/martin/software/ugcc/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/include
 /usr/include
End of search list.
 /home/martin/software/ugcc/libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/f951
/tmp/ccNsJVqs.f95 -ffree-form -quiet -dumpbase modules.F90 -mtune=generic
-auxbase modules -version -fpreprocessed -I
/home/martin/software/ugcc/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/finclude -o
/tmp/cciJjRCJ.s
GNU F95 version 4.2.0 20060821 (experimental) (x86_64-unknown-linux-gnu)
        compiled by GNU C version 4.2.0 20060821 (experimental).
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128005
 In file modules.F90:33

  use ModelParams
                1
modules.F90:16: 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.


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

 In file modules.F90:43

        use ModelParams
                      1
Error: The derived type 'p' at (1) is of type '', which has not been defined.

which makes no sense.


-- 
           Summary: [gfortran: 4.1, 4.2 regression] ICE on valid code
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: martin at mpa-garching dot mpg dot de
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28788

[Bug fortran/28788] [gfortran: 4.1, 4.2 regression] ICE on valid code

[pault at gcc dot gnu dot org]

------- 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|0000-00-00 00:00:00         |2006-08-22 05:30:08
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28788

[Bug fortran/28788] [gfortran: 4.1, 4.2 regression] ICE on valid code

[pault at gcc dot gnu dot org]

------- 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

[paul dot richard dot thomas at cea dot fr]

------- 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=12117&action=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

[patchapp at dberlin dot org]

------- 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

[pault at gcc dot gnu dot org]

------- 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=gcc&view=rev&rev=116369
Log:
2006-08-23  Paul Thomas  <pault@gcc.gnu.org>

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

        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

[pault at gcc dot gnu dot org]

------- 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=gcc&view=rev&rev=116370
Log:
2006-08-24  Paul Thomas  <pault@gcc.gnu.org>

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

        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

[martin at mpa-garching dot mpg dot de]

------- 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

[paulthomas2 at wanadoo dot fr]

------- 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

[martin at mpa-garching dot mpg dot de]

------- 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=12139&action=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

[martin at mpa-garching dot mpg dot de]

------- 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

[jvdelisle at gcc dot gnu dot org]

------- 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  0x0000000000417c6a in error_print (type=Variable "type" is not available.
)
    at ../../gcc42/gcc/fortran/error.c:409
#2  0x000000000041809d in gfc_error (nocmsgid=Variable "nocmsgid" is not
available.
)
    at ../../gcc42/gcc/fortran/error.c:611
#3  0x000000000044c820 in resolve_symbol (sym=0xcfa1d0)
    at ../../gcc42/gcc/fortran/resolve.c:5656
#4  0x0000000000454e1e in traverse_ns (st=0xcfb5c0,
    func=0x44bb60 <resolve_symbol>) at ../../gcc42/gcc/fortran/symbol.c:2650
#5  0x0000000000454e06 in traverse_ns (st=0xcfb600,
    func=0x44bb60 <resolve_symbol>) at ../../gcc42/gcc/fortran/symbol.c:2653
#6  0x000000000044931f in resolve_types (ns=0xcef530)
    at ../../gcc42/gcc/fortran/resolve.c:6628
#7  0x000000000044bb3d in gfc_resolve (ns=0xcef530)
    at ../../gcc42/gcc/fortran/resolve.c:6703
#8  0x000000000044bcb4 in resolve_symbol (sym=0xce4740)
    at ../../gcc42/gcc/fortran/resolve.c:5729
#9  0x0000000000454e1e in traverse_ns (st=0xcd2c40,
    func=0x44bb60 <resolve_symbol>) at ../../gcc42/gcc/fortran/symbol.c:2650
#10 0x0000000000454e06 in traverse_ns (st=0xceec90,
    func=0x44bb60 <resolve_symbol>) at ../../gcc42/gcc/fortran/symbol.c:2653
#11 0x0000000000454e06 in traverse_ns (st=0xcc9170,
    func=0x44bb60 <resolve_symbol>) at ../../gcc42/gcc/fortran/symbol.c:2653
#12 0x0000000000454e06 in traverse_ns (st=0xccb0d0,
    func=0x44bb60 <resolve_symbol>) at ../../gcc42/gcc/fortran/symbol.c:2653
#13 0x0000000000454e06 in traverse_ns (st=0xcd2700,
    func=0x44bb60 <resolve_symbol>) at ../../gcc42/gcc/fortran/symbol.c:2653
#14 0x0000000000454e06 in traverse_ns (st=0xcc8cb0,
    func=0x44bb60 <resolve_symbol>) at ../../gcc42/gcc/fortran/symbol.c:2653
#15 0x000000000044931f in resolve_types (ns=0xcc62f0)
    at ../../gcc42/gcc/fortran/resolve.c:6628
#16 0x00000000004493eb in resolve_types (ns=0xcc4500)
    at ../../gcc42/gcc/fortran/resolve.c:6639
#17 0x000000000044bb3d in gfc_resolve (ns=0xcc4500)
    at ../../gcc42/gcc/fortran/resolve.c:6703
#18 0x0000000000441418 in gfc_parse_file ()
    at ../../gcc42/gcc/fortran/parse.c:3197
#19 0x0000000000460bbe in gfc_be_parse_file (set_yydebug=Variable "set_yydebug"
is not available.
)
    at ../../gcc42/gcc/fortran/f95-lang.c:303
#20 0x000000000074aa53 in toplev_main (argc=Variable "argc" is not available.
) at ../../gcc42/gcc/toplev.c:999
#21 0x0000003816e1ce54 in __libc_start_main () from /lib64/libc.so.6
#22 0x0000000000403d99 in _start ()
#23 0x00007fff8414b8c8 in ?? ()
#24 0x0000000000000000 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

[paulthomas2 at wanadoo dot fr]

------- 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:
[prt@localhost 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

[aovb94 at dsl dot pipex dot com]

------- 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

[jvdelisle at gcc dot gnu dot org]

------- 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 0xffffffff
) 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

[paul dot richard dot thomas at cea dot fr]

------- 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=12146&action=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

[pault at gcc dot gnu dot org]

------- 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=gcc&view=rev&rev=116552
Log:
2006-08-29  Paul Thomas  <pault@gcc.gnu.org>

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

        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

[pault at gcc dot gnu dot org]

------- 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=gcc&view=rev&rev=116553
Log:
2006-08-29  Paul Thomas  <pault@gcc.gnu.org>

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

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

        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

[pault at gcc dot gnu dot org]

------- 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