[Bug fortran/45827] New: mio_component_ref(): Component not found when mixing f90 and f03 in large projects

[Bug fortran/45827] New: mio_component_ref(): Component not found when mixing f90 and f03 in large projects

[boschmann at tp1 dot physik.uni-siegen.de]

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

           Summary: mio_component_ref(): Component not found when mixing
                    f90 and f03 in large projects
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: boschmann@tp1.physik.uni-siegen.de


Created attachment 21911
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=21911
The sample source code of this bug report

common.f03:27.22:

  use arguments_module
                      1
Interner Fehler bei (1):
mio_component_ref(): Component not found

GNU Fortran (GCC) 4.6.0 20100921 (experimental)


Hi all!

First of all, I'm sorry about the bad sample code for this bug. It is attached
to the report as "gccbug.tar.gz". This bug has bothered me for a while and I
never was able to isolate it. The error message comes and goes when I update to
the latest revision of gfortran and appears in a part of my project, when I
edit a completely different part. Now it showed up in a module with few
dependencies to other modules. It is the smallest collection of modules so far,
that show this bug. I can repair it, when

* I rename all files to *.f03. Usually, *.f90 files are mixed with *.f03 in my
project. Maybe this is not supposed to work, but the compiler should give a
better error message then.

* I add an use statement for all modules that are used by the used modules and
put them into proper order, such that no module depends to a module that is
"used" further down. That is what I've done until now, because I didn't knew
the first fact till this day. But in 4.6.0 20100921, even this has failed.

* I remove symbols somewhere. Obviously, the bug needs a certain complexity to
show up. That's why I cannot give you a smaller sample code.

* I use the actual GNU Fortran (GCC) 4.6.0 20100928. But it already happened,
that the bug disappeared and appeared again.

Best regards,
Hans Boschmann

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

[Joost.VandeVondele at pci dot uzh.ch]

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

Joost VandeVondele <Joost.VandeVondele at pci dot uzh.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2010.09.29 08:54:49
               date|                            |
                 CC|                            |Joost.VandeVondele at pci
                   |                            |dot uzh.ch
     Ever Confirmed|0                           |1

--- Comment #1 from Joost VandeVondele <Joost.VandeVondele at pci dot uzh.ch> 2010-09-29 08:54:49 UTC ---
hmm interesting reduced testcase:

> cat bug.f90
  use,intrinsic::iso_fortran_env
> gfortran bug.f90
f951: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug fortran/45827] [4.6 Regression] ice in create_int_parameter_array

[Joost.VandeVondele at pci dot uzh.ch]

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

Joost VandeVondele <Joost.VandeVondele at pci dot uzh.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org
      Known to work|                            |4.5.2
   Target Milestone|---                         |4.6.0
            Summary|mio_component_ref():        |[4.6 Regression] ice in
                   |Component not found when    |create_int_parameter_array
                   |mixing f90 and f03 in large |
                   |projects                    |
      Known to fail|                            |4.6.0

--- Comment #2 from Joost VandeVondele <Joost.VandeVondele at pci dot uzh.ch> 2010-09-29 08:57:40 UTC ---
Program received signal SIGSEGV, Segmentation fault.
0x0000000000504fee in create_int_parameter_array (name=<value optimized out>,
size=2, value=0x144e150, modname=<value optimized out>,
    module=INTMOD_ISO_FORTRAN_ENV, id=22) at
/data03/vondele/gcc_trunk/gcc/gcc/fortran/module.c:5345
5345      e->shape = gfc_get_shape (1);
(gdb) bt
#0  0x0000000000504fee in create_int_parameter_array (name=<value optimized
out>, size=2, value=0x144e150, modname=<value optimized out>,
    module=INTMOD_ISO_FORTRAN_ENV, id=22) at
/data03/vondele/gcc_trunk/gcc/gcc/fortran/module.c:5345
#1  0x0000000000505709 in use_iso_fortran_env_module () at
/data03/vondele/gcc_trunk/gcc/gcc/fortran/iso-fortran-env.def:97
#2  0x000000000050b27d in gfc_use_module () at
/data03/vondele/gcc_trunk/gcc/gcc/fortran/module.c:5541
#3  0x0000000000510905 in accept_statement (st=20866384) at
/data03/vondele/gcc_trunk/gcc/gcc/fortran/parse.c:1574
#4  0x00000000005136a0 in parse_spec (st=ST_USE) at
/data03/vondele/gcc_trunk/gcc/gcc/fortran/parse.c:2588
#5  0x0000000000514de6 in parse_progunit (st=20866384) at
/data03/vondele/gcc_trunk/gcc/gcc/fortran/parse.c:3922
#6  0x0000000000516035 in gfc_parse_file () at
/data03/vondele/gcc_trunk/gcc/gcc/fortran/parse.c:4357
#7  0x000000000054fb8d in gfc_be_parse_file (set_yydebug=<value optimized out>)
at /data03/vondele/gcc_trunk/gcc/gcc/fortran/f95-lang.c:242
#8  0x00000000008667cd in toplev_main (argc=14, argv=0x7fff8331e858) at
/data03/vondele/gcc_trunk/gcc/gcc/toplev.c:955
#9  0x00007f771ead8436 in __libc_start_main () from /lib64/libc.so.6
#10 0x00000000004ab1b9 in _start ()

[Bug fortran/45827] [4.6 Regression] ice in create_int_parameter_array

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-09-29 09:57:57 UTC ---
Joost what's the version of your GCC? There was a bug fix (Bug 45793) on
Saturday.

Thus, if it occurs with Hans-Werner's 4.6.0 20100921, I am not surprised. But
if the problem occurs after 2010-09-26 I am surprised. Can you check?

Hans-Werner: Can you try a newer version?

(The bug is ridiculously obvious if one has found it; for some reasons it does
not crash all systems on a lot of systems it simply "worked" [did neither crash
nor fail].)

[Bug fortran/45827] [4.6 Regression] ice in create_int_parameter_array

[Joost.VandeVondele at pci dot uzh.ch]

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

--- Comment #4 from Joost VandeVondele <Joost.VandeVondele at pci dot uzh.ch> 2010-09-29 10:18:15 UTC ---
Oh... I'm using an old version ;)
gcc version 4.6.0 20100925 (experimental) [trunk revision 164618] (GCC).
I'll update and check again.

[Bug fortran/45827] [4.6 Regression] ice in create_int_parameter_array

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikael at gcc dot gnu.org

--- Comment #5 from Mikael Morin <mikael at gcc dot gnu.org> 2010-09-29 10:40:27 UTC ---
Joost, I think your problem is different and deserves a separate PR. 

About the original problem, it seems it is a makefile problem. 
One needs to insert the module dependencies in the makefile so that make
recompiles and updates module files appropriately. 

Like this: 

kinds.o kinds.mod: kinds.f90
    $(FC) $(FFLAGS) -c $< -o kinds.o

arguments.o arguments_module.mod: arguments.f03 kinds.mod
    $(FC) $(FFLAGS) -c $< -o arguments.o

And so on...

[Bug fortran/45827] [4.6 Regression] ice in create_int_parameter_array

[Joost.VandeVondele at pci dot uzh.ch]

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

Joost VandeVondele <Joost.VandeVondele at pci dot uzh.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #6 from Joost VandeVondele <Joost.VandeVondele at pci dot uzh.ch> 2010-09-29 11:00:59 UTC ---
(In reply to comment #4)
> Oh... I'm using an old version ;)
> gcc version 4.6.0 20100925 (experimental) [trunk revision 164618] (GCC).
> I'll update and check again.
OK, today's trunk works fine. I believe the bug can be closed as fixed.

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |
            Summary|[4.6 Regression] ice in     |mio_component_ref():
                   |create_int_parameter_array  |Component not found when
                   |                            |mixing f90 and f03 in large
                   |                            |projects

--- Comment #7 from Mikael Morin <mikael at gcc dot gnu.org> 2010-09-29 11:21:47 UTC ---
(In reply to comment #6)
> OK, today's trunk works fine. I believe the bug can be closed as fixed.

Back to the original problem then.

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |WAITING

--- Comment #8 from Mikael Morin <mikael at gcc dot gnu.org> 2010-09-29 11:24:18 UTC ---
Hans, is the error gone once you have fixed your makefile ?

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

[boschmann at tp1 dot physik.uni-siegen.de]

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

--- Comment #9 from Hans-Werner Boschmann <boschmann at tp1 dot physik.uni-siegen.de> 2010-09-29 11:49:11 UTC ---
My makefile is now:
FC=gfortran
FFLAGS=-ffree-form -ffree-line-length-0 -I. -L.

all: common.o common_module.mod arguments.o arguments_module.mod kinds.o
kinds.mod

kinds.o kinds.mod: kinds.f90
        $(FC) $(FFLAGS) -c $< -o kinds.o

arguments.o arguments_module.mod: arguments.f03 kinds.mod
        $(FC) $(FFLAGS) -c $< -o arguments.o

common.o common_module.mod: common.f03 arguments_module.mod kinds.mod
        $(FC) $(FFLAGS) -c $< -o common.o

clean:
        rm -rf *.mod *.o test


The result:

gfortran -ffree-form -ffree-line-length-0 -I. -L.  -c kinds.f90 -o kinds.o
gfortran -ffree-form -ffree-line-length-0 -I. -L.  -c arguments.f03 -o
arguments.o
gfortran -ffree-form -ffree-line-length-0 -I. -L.  -c common.f03 -o common.o
common.f03:27.22:

  use arguments_module
                      1
Interner Fehler bei (1):
mio_component_ref(): Component not found
make: *** [common.o] Fehler 1

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

[mikael at gcc dot gnu.org]

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

--- Comment #10 from Mikael Morin <mikael at gcc dot gnu.org> 2010-09-29 12:44:03 UTC ---
(In reply to comment #9)
> The result:
> 
> gfortran -ffree-form -ffree-line-length-0 -I. -L.  -c kinds.f90 -o kinds.o
> gfortran -ffree-form -ffree-line-length-0 -I. -L.  -c arguments.f03 -o
> arguments.o
> gfortran -ffree-form -ffree-line-length-0 -I. -L.  -c common.f03 -o common.o
> common.f03:27.22:
> 
>   use arguments_module
>                       1
> Interner Fehler bei (1):
> mio_component_ref(): Component not found
> make: *** [common.o] Fehler 1

Works here:

######

FC=$(HOME)/gcc46/bin/gfortran
FFLAGS=-ffree-form -ffree-line-length-0 -I. -L. 

all:test

test: test.o common.o arguments.o kinds.o
    $(FC) $(FFLAGS) $^ -o $@

test.o: test.f03 kinds.mod arguments_module.mod common_module.mod
    $(FC) $(FFLAGS) -c $< -o $@

common.o common_module.mod: common.f03 kinds.mod arguments_module.mod
    $(FC) $(FFLAGS) -c $< -o common.o

arguments.o arguments_module.mod: arguments.f03 kinds.mod
    $(FC) $(FFLAGS) -c $< -o arguments.o

kinds.o kinds.mod: kinds.f90
    $(FC) $(FFLAGS) -c $< -o kinds.o

clean:
    rm -rf *.mod *.a *.o test


#######


$ gmake clean                    
rm -rf *.mod *.a *.o test
$ gmake                          
/home/mik/gcc46/bin/gfortran -ffree-form -ffree-line-length-0 -I. -L.  -c
kinds.f90 -o kinds.o
/home/mik/gcc46/bin/gfortran -ffree-form -ffree-line-length-0 -I. -L.  -c
arguments.f03 -o arguments.o
/home/mik/gcc46/bin/gfortran -ffree-form -ffree-line-length-0 -I. -L.  -c
common.f03 -o common.o
/home/mik/gcc46/bin/gfortran -ffree-form -ffree-line-length-0 -I. -L.  -c
test.f03 -o test.o
/home/mik/gcc46/bin/gfortran -ffree-form -ffree-line-length-0 -I. -L.  test.o
common.o arguments.o kinds.o -o test
$ ./test                         
 process
 hallo
$ 



########

version:

gcc version 4.6.0 20100924 (experimental) (GCC)

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

[boschmann at tp1 dot physik.uni-siegen.de]

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

--- Comment #11 from Hans-Werner Boschmann <boschmann at tp1 dot physik.uni-siegen.de> 2010-09-30 07:37:46 UTC ---
So it works with 4.6.0 20100924, but it still doesn't work with 4.6.0 20100921.
Unfortunately, I cannot use the latest revision, until bug 45746 is fixed.
Plus, I assume that the error message will show up in later revisions again.

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

[burnus at gcc dot gnu.org]

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

--- Comment #12 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-09-30 09:24:49 UTC ---
(In reply to comment #11)
> So it works with 4.6.0 20100924, but it still doesn't work with 4.6.0 20100921.
> Unfortunately, I cannot use the latest revision, until bug 45746 is fixed.

Actually, I am confused: From that comment it sounds as if 20100921 does not
have the bug 45746 - but it has been reported using 20100921 and a comment by
Dominique indicates that it never worked with GCC 4.5/4.6 but it only worked
for a while on the fortran-dev branch.


> Plus, I assume that the error message will show up in later revisions again.

Any reason why you think that this will be the case?


(In reply to comment #0)
> I use the actual GNU Fortran (GCC) 4.6.0 20100928. But it already happened,
> that the bug disappeared and appeared again.

Such bugs are usually an indication for not properly initialized memory.
Especially when it happens, it helps if one can try valgrind on the file:

  valgrind `gfortran -v 2>&1 <other commandline options> | grep f951`

Memory related errors tend to show up only on few machines and in irregular
patterns, which makes finding them difficult.

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

[boschmann at tp1 dot physik.uni-siegen.de]

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

--- Comment #13 from Hans-Werner Boschmann <boschmann at tp1 dot physik.uni-siegen.de> 2010-09-30 13:03:09 UTC ---
(In reply to comment #12)
> Actually, I am confused: From that comment it sounds as if 20100921 does not
> have the bug 45746 - but it has been reported using 20100921 and a comment by
> Dominique indicates that it never worked with GCC 4.5/4.6 but it only worked
> for a while on the fortran-dev branch.

You are right about this, I'm switching back and forth in the version of gcc
and got lost.


But I have run valgrind now. It was the first time, so I don't understand the
result. Is it somehow the fault of my hardware/OS? Here is the output:


valgrind --leak-check=full /opt/gcc-trunk/bin/gfortran -ffree-form
-ffree-line-length-0 -I. -L.  -c common.f03 -o common.o
==31832== Memcheck, a memory error detector                                     
==31832== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.       
==31832== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info     
==31832== Command: /opt/gcc-trunk/bin/gfortran -ffree-form -ffree-line-length-0
-I. -L. -c common.f03 -o common.o                                          
==31832==                                                                       
common.f03:27.22:                                                               

  use arguments_module
                      1
Interner Fehler bei (1):
mio_component_ref(): Component not found
==31832==                               
==31832== HEAP SUMMARY:                 
==31832==     in use at exit: 32,209 bytes in 82 blocks
==31832==   total heap usage: 268 allocs, 186 frees, 49,388 bytes allocated
==31832==                                                                  
==31832== 1 bytes in 1 blocks are definitely lost in loss record 2 of 70   
==31832==    at 0x4C234E7: calloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31832==    by 0x41FC38: xcalloc (xmalloc.c:162)                               
==31832==    by 0x40DE7F: main (gcc.c:6993)                                     
==31832==                                                                       
==31832== 4 bytes in 1 blocks are possibly lost in loss record 4 of 70          
==31832==    at 0x4C241C3: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31832==    by 0x41FBF7: xmalloc (xmalloc.c:147)                               
==31832==    by 0x41DA2D: concat (concat.c:159)                                 
==31832==    by 0x407090: driver_handle_option (gcc.c:3729)                     
==31832==    by 0x410A37: handle_option (opts-common.c:673)                     
==31832==    by 0x410B7C: read_cmdline_option (opts-common.c:812)               
==31832==    by 0x40580E: process_command (gcc.c:4177)                          
==31832==    by 0x40C63C: main (gcc.c:6593)                                     
==31832==                                                                       
==31832== 15 bytes in 1 blocks are definitely lost in loss record 10 of 70      
==31832==    at 0x4C241C3: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31832==    by 0x41FBF7: xmalloc (xmalloc.c:147)                               
==31832==    by 0x4025D5: save_string (gcc.c:7322)                              
==31832==    by 0x40B3AB: handle_braces (gcc.c:6093)                            
==31832==    by 0x409303: do_spec_1 (gcc.c:5485)                                
==31832==    by 0x40B455: handle_braces (gcc.c:6096)                            
==31832==    by 0x409303: do_spec_1 (gcc.c:5485)                                
==31832==    by 0x40B455: handle_braces (gcc.c:6096)                            
==31832==    by 0x409303: do_spec_1 (gcc.c:5485)                                
==31832==    by 0x40A25A: do_spec_2 (gcc.c:4554)                                
==31832==    by 0x40A282: do_self_spec (gcc.c:4619)                             
==31832==    by 0x40ABCE: do_option_spec (gcc.c:4608)                           
==31832==                                                                       
==31832== 18 bytes in 1 blocks are definitely lost in loss record 16 of 70      
==31832==    at 0x4C241C3: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31832==    by 0x41FBF7: xmalloc (xmalloc.c:147)                               
==31832==    by 0x4025D5: save_string (gcc.c:7322)                              
==31832==    by 0x40B3AB: handle_braces (gcc.c:6093)                            
==31832==    by 0x409303: do_spec_1 (gcc.c:5485)                                
==31832==    by 0x40B455: handle_braces (gcc.c:6096)                            
==31832==    by 0x409303: do_spec_1 (gcc.c:5485)                                
==31832==    by 0x40B455: handle_braces (gcc.c:6096)                            
==31832==    by 0x409303: do_spec_1 (gcc.c:5485)                                
==31832==    by 0x4097A4: do_spec_1 (gcc.c:5584)                                
==31832==    by 0x40B455: handle_braces (gcc.c:6096)                            
==31832==    by 0x409303: do_spec_1 (gcc.c:5485)                                
==31832==                                                                       
==31832== 27 bytes in 1 blocks are definitely lost in loss record 21 of 70      
==31832==    at 0x4C241C3: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31832==    by 0x41FBF7: xmalloc (xmalloc.c:147)                               
==31832==    by 0x4025D5: save_string (gcc.c:7322)                              
==31832==    by 0x40B3AB: handle_braces (gcc.c:6093)                            
==31832==    by 0x409303: do_spec_1 (gcc.c:5485)                                
==31832==    by 0x40B455: handle_braces (gcc.c:6096)                            
==31832==    by 0x409303: do_spec_1 (gcc.c:5485)                                
==31832==    by 0x40A25A: do_spec_2 (gcc.c:4554)                                
==31832==    by 0x40A282: do_self_spec (gcc.c:4619)                             
==31832==    by 0x40ABCE: do_option_spec (gcc.c:4608)                           
==31832==    by 0x40C7C9: main (gcc.c:6629)                                     
==31832==                                                                       
==31832== 32 (16 direct, 16 indirect) bytes in 1 blocks are definitely lost in
loss record 35 of 70
==31832==    at 0x4C241C3: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)       
==31832==    by 0x41FBF7: xmalloc (xmalloc.c:147)                               
==31832==    by 0x407401: record_temp_file (gcc.c:2329)                         
==31832==    by 0x40767B: end_going_arg (gcc.c:4461)                            
==31832==    by 0x408544: do_spec_1 (gcc.c:4859)                                
==31832==    by 0x40B455: handle_braces (gcc.c:6096)                            
==31832==    by 0x409303: do_spec_1 (gcc.c:5485)                                
==31832==    by 0x40B455: handle_braces (gcc.c:6096)                            
==31832==    by 0x409303: do_spec_1 (gcc.c:5485)                                
==31832==    by 0x4097A4: do_spec_1 (gcc.c:5584)                                
==31832==    by 0x40B455: handle_braces (gcc.c:6096)                            
==31832==    by 0x409303: do_spec_1 (gcc.c:5485)                                
==31832==                                                                       
==31832== 37 bytes in 1 blocks are definitely lost in loss record 36 of 70      
==31832==    at 0x4C241C3: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)       
==31832==    by 0x41FBF7: xmalloc (xmalloc.c:147)                               
==31832==    by 0x4025D5: save_string (gcc.c:7322)                              
==31832==    by 0x40B3AB: handle_braces (gcc.c:6093)                            
==31832==    by 0x409303: do_spec_1 (gcc.c:5485)                                
==31832==    by 0x40B455: handle_braces (gcc.c:6096)                            
==31832==    by 0x409303: do_spec_1 (gcc.c:5485)                                
==31832==    by 0x4097A4: do_spec_1 (gcc.c:5584)                                
==31832==    by 0x40B455: handle_braces (gcc.c:6096)                            
==31832==    by 0x409303: do_spec_1 (gcc.c:5485)                                
==31832==    by 0x40B455: handle_braces (gcc.c:6096)                            
==31832==    by 0x409303: do_spec_1 (gcc.c:5485)                                
==31832==                                                                       
==31832== 38 bytes in 1 blocks are definitely lost in loss record 37 of 70      
==31832==    at 0x4C241C3: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)       
==31832==    by 0x41FBF7: xmalloc (xmalloc.c:147)                               
==31832==    by 0x41DA2D: concat (concat.c:159)                                 
==31832==    by 0x40588E: process_command (gcc.c:4250)                          
==31832==    by 0x40C63C: main (gcc.c:6593)                                     
==31832==                                                                       
==31832== 42 bytes in 1 blocks are definitely lost in loss record 40 of 70      
==31832==    at 0x4C241C3: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)       
==31832==    by 0x41FBF7: xmalloc (xmalloc.c:147)                               
==31832==    by 0x4025D5: save_string (gcc.c:7322)                              
==31832==    by 0x40B3AB: handle_braces (gcc.c:6093)                            
==31832==    by 0x409303: do_spec_1 (gcc.c:5485)                                
==31832==    by 0x40B455: handle_braces (gcc.c:6096)                            
==31832==    by 0x409303: do_spec_1 (gcc.c:5485)                                
==31832==    by 0x4097A4: do_spec_1 (gcc.c:5584)                                
==31832==    by 0x40B455: handle_braces (gcc.c:6096)                            
==31832==    by 0x409303: do_spec_1 (gcc.c:5485)                                
==31832==    by 0x40A25A: do_spec_2 (gcc.c:4554)                                
==31832==    by 0x40B845: do_spec (gcc.c:4522)                                  
==31832==                                                                       
==31832== 49 bytes in 2 blocks are definitely lost in loss record 41 of 70      
==31832==    at 0x4C241C3: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)       
==31832==    by 0x41FBF7: xmalloc (xmalloc.c:147)                               
==31832==    by 0x4025D5: save_string (gcc.c:7322)                              
==31832==    by 0x40B3AB: handle_braces (gcc.c:6093)                            
==31832==    by 0x409303: do_spec_1 (gcc.c:5485)                                
==31832==    by 0x40B455: handle_braces (gcc.c:6096)                            
==31832==    by 0x409303: do_spec_1 (gcc.c:5485)                                
==31832==    by 0x40A25A: do_spec_2 (gcc.c:4554)                                
==31832==    by 0x40B845: do_spec (gcc.c:4522)                                  
==31832==    by 0x40E05E: main (gcc.c:7075)                                     
==31832==                                                                       
==31832== 52 bytes in 2 blocks are definitely lost in loss record 42 of 70      
==31832==    at 0x4C241C3: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)       
==31832==    by 0x41FBF7: xmalloc (xmalloc.c:147)                               
==31832==    by 0x4025D5: save_string (gcc.c:7322)                              
==31832==    by 0x40B3AB: handle_braces (gcc.c:6093)                            
==31832==    by 0x409303: do_spec_1 (gcc.c:5485)                                
==31832==    by 0x40A25A: do_spec_2 (gcc.c:4554)                                
==31832==    by 0x40A282: do_self_spec (gcc.c:4619)                             
==31832==    by 0x40ABCE: do_option_spec (gcc.c:4608)                           
==31832==    by 0x40C7C9: main (gcc.c:6629)                                     
==31832==                                                                       
==31832== 64 bytes in 1 blocks are definitely lost in loss record 46 of 70      
==31832==    at 0x4C241C3: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)       
==31832==    by 0x41FBF7: xmalloc (xmalloc.c:147)                               
==31832==    by 0x41DA2D: concat (concat.c:159)                                 
==31832==    by 0x40D613: main (gcc.c:6755)                                     
==31832==                                                                       
==31832== 92 bytes in 1 blocks are definitely lost in loss record 47 of 70      
==31832==    at 0x4C241C3: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)       
==31832==    by 0x41FBF7: xmalloc (xmalloc.c:147)                               
==31832==    by 0x41DA2D: concat (concat.c:159)                                 
==31832==    by 0x4058C6: process_command (gcc.c:4256)                          
==31832==    by 0x40C63C: main (gcc.c:6593)                                     
==31832==                                                                       
==31832== 96 bytes in 1 blocks are definitely lost in loss record 50 of 70      
==31832==    at 0x4C241C3: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)       
==31832==    by 0x41FBF7: xmalloc (xmalloc.c:147)                               
==31832==    by 0x41DA2D: concat (concat.c:159)                                 
==31832==    by 0x4058DF: process_command (gcc.c:4261)                          
==31832==    by 0x40C63C: main (gcc.c:6593)                                     
==31832==                                                                       
==31832== 96 bytes in 1 blocks are definitely lost in loss record 51 of 70      
==31832==    at 0x4C241C3: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)       
==31832==    by 0x41FBF7: xmalloc (xmalloc.c:147)                               
==31832==    by 0x41DA2D: concat (concat.c:159)                                 
==31832==    by 0x405912: process_command (gcc.c:4264)                          
==31832==    by 0x40C63C: main (gcc.c:6593)                                     
==31832==                                                                       
==31832== 116 bytes in 1 blocks are definitely lost in loss record 52 of 70     
==31832==    at 0x4C241C3: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)       
==31832==    by 0x41FBF7: xmalloc (xmalloc.c:147)                               
==31832==    by 0x4025D5: save_string (gcc.c:7322)                              
==31832==    by 0x40B3AB: handle_braces (gcc.c:6093)                            
==31832==    by 0x409303: do_spec_1 (gcc.c:5485)                                
==31832==    by 0x4097A4: do_spec_1 (gcc.c:5584)                                
==31832==    by 0x40B455: handle_braces (gcc.c:6096)                            
==31832==    by 0x409303: do_spec_1 (gcc.c:5485)                                
==31832==    by 0x40B455: handle_braces (gcc.c:6096)                            
==31832==    by 0x409303: do_spec_1 (gcc.c:5485)                                
==31832==    by 0x40A25A: do_spec_2 (gcc.c:4554)                                
==31832==    by 0x40B845: do_spec (gcc.c:4522)                                  
==31832==                                                                       
==31832== 126 bytes in 5 blocks are definitely lost in loss record 53 of 70     
==31832==    at 0x4C241C3: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)       
==31832==    by 0x41FBF7: xmalloc (xmalloc.c:147)                               
==31832==    by 0x4025D5: save_string (gcc.c:7322)                              
==31832==    by 0x40B3AB: handle_braces (gcc.c:6093)                            
==31832==    by 0x409303: do_spec_1 (gcc.c:5485)                                
==31832==    by 0x4097A4: do_spec_1 (gcc.c:5584)                                
==31832==    by 0x40B455: handle_braces (gcc.c:6096)                            
==31832==    by 0x409303: do_spec_1 (gcc.c:5485)
==31832==    by 0x40A25A: do_spec_2 (gcc.c:4554)
==31832==    by 0x40B845: do_spec (gcc.c:4522)
==31832==    by 0x40E05E: main (gcc.c:7075)
==31832==
==31832== 135 bytes in 2 blocks are definitely lost in loss record 55 of 70
==31832==    at 0x4C241C3: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31832==    by 0x41FBF7: xmalloc (xmalloc.c:147)
==31832==    by 0x4025D5: save_string (gcc.c:7322)
==31832==    by 0x40B3AB: handle_braces (gcc.c:6093)
==31832==    by 0x409303: do_spec_1 (gcc.c:5485)
==31832==    by 0x40A25A: do_spec_2 (gcc.c:4554)
==31832==    by 0x40B845: do_spec (gcc.c:4522)
==31832==    by 0x40E05E: main (gcc.c:7075)
==31832==
==31832== 176 bytes in 1 blocks are definitely lost in loss record 58 of 70
==31832==    at 0x4C241C3: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31832==    by 0x41FBF7: xmalloc (xmalloc.c:147)
==31832==    by 0x405007: process_command (gcc.c:1178)
==31832==    by 0x40C63C: main (gcc.c:6593)
==31832==
==31832== 4,064 bytes in 1 blocks are definitely lost in loss record 70 of 70
==31832==    at 0x4C241C3: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31832==    by 0x41FBF7: xmalloc (xmalloc.c:147)
==31832==    by 0x4EA3BF8: _obstack_begin (obstack.c:186)
==31832==    by 0x40D188: main (gcc.c:6800)
==31832==
==31832== LEAK SUMMARY:
==31832==    definitely lost: 5,260 bytes in 26 blocks
==31832==    indirectly lost: 16 bytes in 1 blocks
==31832==      possibly lost: 4 bytes in 1 blocks
==31832==    still reachable: 26,929 bytes in 54 blocks
==31832==         suppressed: 0 bytes in 0 blocks
==31832== Reachable blocks (those to which a pointer was found) are not shown.
==31832== To see them, rerun with: --leak-check=full --show-reachable=yes
==31832==
==31832== For counts of detected and suppressed errors, rerun with: -v
==31832== ERROR SUMMARY: 20 errors from 20 contexts (suppressed: 4 from 4)

(In reply to comment #12)
> (In reply to comment #11)
> > So it works with 4.6.0 20100924, but it still doesn't work with 4.6.0 20100921.
> > Unfortunately, I cannot use the latest revision, until bug 45746 is fixed.
> 
> Actually, I am confused: From that comment it sounds as if 20100921 does not
> have the bug 45746 - but it has been reported using 20100921 and a comment by
> Dominique indicates that it never worked with GCC 4.5/4.6 but it only worked
> for a while on the fortran-dev branch.
> 
> 
> > Plus, I assume that the error message will show up in later revisions again.
> 
> Any reason why you think that this will be the case?
> 
> 
> (In reply to comment #0)
> > I use the actual GNU Fortran (GCC) 4.6.0 20100928. But it already happened,
> > that the bug disappeared and appeared again.
> 
> Such bugs are usually an indication for not properly initialized memory.
> Especially when it happens, it helps if one can try valgrind on the file:
> 
>   valgrind `gfortran -v 2>&1 <other commandline options> | grep f951`
> 
> Memory related errors tend to show up only on few machines and in irregular
> patterns, which makes finding them difficult.

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

[burnus at gcc dot gnu.org]

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

--- Comment #14 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-09-30 13:48:15 UTC ---
(In reply to comment #13)
> But I have run valgrind now. It was the first time, so I don't understand the
> result. Is it somehow the fault of my hardware/OS? Here is the output:

> valgrind --leak-check=full /opt/gcc-trunk/bin/gfortran -ffree-form
> -ffree-line-length-0 -I. -L.  -c common.f03 -o common.o

You did not do what I wrote. I wrote:

  valgrind `gfortran -v 2>&1 <other commandline options> | grep f951`

you did

  valgrind gfortran ...

Thus you are testing a completely different program! "gcc", "gfortran" etc. are
only "drivers" which call the actual compiler, which is named "cc1", "f951",
... (That is also the reason why C programs can be compiled with "gfortran
foo.c" as this then calls "cc1" rather than "f951".)

To find out the command line arguments to the real compiler 'f951', one can
compile using the option "-v" which shows the parts which are called. The line
of interest is the one which is calling "f951".


> ==31832== 1 bytes in 1 blocks are definitely lost in loss record 2 of 70   
> ==31832== 4 bytes in 1 blocks are possibly lost in loss record 4 of 
etc.

That only tells that some memory has not been freed and is possibly/definitely
lost. That should not happen, but usually just means that gfortran uses more
memory as it should (and which is then only freed by the operating system if
one returns). -- In some cases  (cf. e.g. Bug 45793) those indicate a true
error which have to be fixed. (But one usually should also try to fix normal
memory issues.)

I was more looking for warnings such as:
  ==27731== Invalid read of size 8
which indicate that there is an error (e.g. uninitialized variable or pointer).

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

[boschmann at tp1 dot physik.uni-siegen.de]

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

--- Comment #15 from Hans-Werner Boschmann <boschmann at tp1 dot physik.uni-siegen.de> 2010-10-01 06:52:14 UTC ---
Thank you, now I understand the difference. The correct invocation does not
supply any new information.

Revision 20100928 compiles my code, so it's fine for me now. But I have got
huge tables of use statements in my modules and I continue to get this error
message, when I forget to explicitly "use" the whole tree of modules.

It also might has been a coincidence that the error disappeared when I renamed
kind.f90 to kinds.f03. I did the same for 20100928, and it didn't work. But
mentioning all modules works for 20100928.

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

[boschmann at tp1 dot physik.uni-siegen.de]

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

--- Comment #16 from Hans-Werner Boschmann <boschmann at tp1 dot physik.uni-siegen.de> 2010-10-01 07:57:44 UTC ---
I have checked the f90/f03 combination again, there DEFINITELY IS A CORRELATION
between mixing dialects and the error. Using -std=f2003 also fixed the problem.

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

[burnus at gcc dot gnu.org]

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

--- Comment #17 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-10-01 08:13:37 UTC ---
(In reply to comment #16)
> I have checked the f90/f03 combination again, there DEFINITELY IS A CORRELATION
> between mixing dialects and the error. Using -std=f2003 also fixed the problem.

The file extensions should not have any influence (unless you use it in the
Makefile to pass different flags); .f90 and .f03 simply tell the compiler that
the file is in free format while .f indicates a fixed format. Thus, many
compilers only recognize .f90 and not .f95/.f03/.f08. Some do (such as
gfortran).

-std=f2003 changes several things and thus could have some influence (though it
shouldn't).

I think there is somewhere a latent bug and maybe things like using -std=f2003
changes slightly the internal program path and the memory usage which allows it
to pass or to fail.

Though, without being able to reproduce it, it is extremely difficult to find
the problem. :-(

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jvdelisle at gcc dot
                   |                            |gnu.org

--- Comment #18 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2010-10-01 14:39:23 UTC ---
This look suspicious:  valgrind on f951

==4245== 8,032 bytes in 1 blocks are possibly lost in loss record 120 of 127
==4245==    at 0x4A0515D: malloc (vg_replace_malloc.c:195)
==4245==    by 0xCCDAA7: xmalloc (xmalloc.c:147)
==4245==    by 0xCAA114: _cpp_get_buff (lex.c:2672)
==4245==    by 0xCA7FE1: cpp_create_reader (init.c:217)
==4245==    by 0x4B3B21: gfc_cpp_post_options (cpp.c:513)
==4245==    by 0x50072E: gfc_post_options (options.c:401)
==4245==    by 0x8347A8: toplev_main (toplev.c:1809)
==4245==    by 0x3E9F21EC5C: (below main) (libc-start.c:226)

Re: [Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

[Mikael Morin]

On Friday 01 October 2010 16:39:35 jvdelisle at gcc dot gnu.org wrote:
> 2010-10-01 14:39:23 UTC --- This look suspicious:  valgrind on f951
> 
No, it is unrelated. It happens on the most simple testcases like:
!!!!
end
!!!!

It can be circumvented by the following patch. But it is harmless (unreleased 
memory).

--- a/cpp.c
+++ b/cpp.c
@@ -510,10 +510,11 @@ gfc_cpp_post_options (void)
          || gfc_cpp_option.dump_includes))
     gfc_fatal_error("To enable preprocessing, use -cpp");
 
-  cpp_in = cpp_create_reader (CLK_GNUC89, NULL, line_table);
   if (!gfc_cpp_enabled ())
     return;
 
+  cpp_in = cpp_create_reader (CLK_GNUC89, NULL, line_table);
+
   gcc_assert (cpp_in);
 
   /* The cpp_options-structure defines far more flags than those set here.

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #19 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2010-10-01 17:42:40 UTC ---
After applying this patch to get rid of the error in comment #18:

--- a/cpp.c
+++ b/cpp.c
@@ -510,10 +510,11 @@ gfc_cpp_post_options (void)
          || gfc_cpp_option.dump_includes))
     gfc_fatal_error("To enable preprocessing, use -cpp");

-  cpp_in = cpp_create_reader (CLK_GNUC89, NULL, line_table);
   if (!gfc_cpp_enabled ())
     return;

+  cpp_in = cpp_create_reader (CLK_GNUC89, NULL, line_table);
+
   gcc_assert (cpp_in);

   /* The cpp_options-structure defines far more flags than those set here.


I can now see this:

==7134== 4 bytes in 2 blocks are definitely lost in loss record 2 of 842
==7134==    at 0x4A04481: calloc (vg_replace_malloc.c:418)
==7134==    by 0xCCDB08: xcalloc (xmalloc.c:162)
==7134==    by 0x4F6E8F: parse_atom (module.c:1037)
==7134==    by 0x4FD7EC: gfc_use_module (module.c:5595)
==7134==    by 0x501C94: accept_statement (parse.c:1574)
==7134==    by 0x504A2A: parse_spec (parse.c:2588)
==7134==    by 0x5074F0: gfc_parse_file (parse.c:4109)
==7134==    by 0x53EB97: gfc_be_parse_file (f95-lang.c:242)
==7134==    by 0x83523F: toplev_main (toplev.c:955)
==7134==    by 0x3E9F21EC5C: (below main) (libc-start.c:226)
==7134== 
==7134== 159 bytes in 1 blocks are definitely lost in loss record 499 of 842
==7134==    at 0x4A04481: calloc (vg_replace_malloc.c:418)
==7134==    by 0xCCDB08: xcalloc (xmalloc.c:162)
==7134==    by 0x659E64: init_emit (emit-rtl.c:5574)
==7134==    by 0x6E3328: prepare_function_start (function.c:4382)
==7134==    by 0x6E8E88: init_function_start (function.c:4436)
==7134==    by 0x5554D6: trans_function_start.isra.2 (trans-decl.c:2002)
==7134==    by 0x55F7C0: gfc_generate_function_code (trans-decl.c:4557)
==7134==    by 0x543B8A: gfc_generate_module_code (trans.c:1433)
==7134==    by 0x507AD5: gfc_parse_file (parse.c:4377)
==7134==    by 0x53EB97: gfc_be_parse_file (f95-lang.c:242)
==7134==    by 0x83523F: toplev_main (toplev.c:955)
==7134==    by 0x3E9F21EC5C: (below main) (libc-start.c:226)
==7134== 
==7134== 184 bytes in 1 blocks are definitely lost in loss record 514 of 842
==7134==    at 0x4A04481: calloc (vg_replace_malloc.c:418)
==7134==    by 0xCCDB08: xcalloc (xmalloc.c:162)
==7134==    by 0x4C853F: gfc_get_expr (expr.c:48)
==7134==    by 0x51A924: extract_compcall_passed_object (resolve.c:5283)
==7134==    by 0x51A978: check_typebound_baseobject (resolve.c:5405)
==7134==    by 0x51AE09: resolve_typebound_call (resolve.c:5607)
==7134==    by 0x51E730: resolve_code (resolve.c:5843)
==7134==    by 0x51F1AB: gfc_resolve_blocks (resolve.c:8568)
==7134==    by 0x51D3E3: resolve_code (resolve.c:8810)
==7134==    by 0x51F332: resolve_codes (resolve.c:13323)
==7134==    by 0x51F23F: resolve_codes (resolve.c:13309)
==7134==    by 0x51171B: gfc_resolve (resolve.c:13350)
==7134== 
==7134== 192 (96 direct, 96 indirect) bytes in 6 blocks are definitely lost in
loss record 518 of 842
==7134==    at 0x4A04481: calloc (vg_replace_malloc.c:418)
==7134==    by 0xCCDB08: xcalloc (xmalloc.c:162)
==7134==    by 0x4F7C87: mio_formal_arglist (module.c:2517)
==7134==    by 0x4FA0CF: mio_component (module.c:2402)
==7134==    by 0x4FA49D: mio_symbol (module.c:2434)
==7134==    by 0x4FA7CF: load_needed (module.c:4171)
==7134==    by 0x4FA775: load_needed (module.c:4132)
==7134==    by 0x4FA780: load_needed (module.c:4133)
==7134==    by 0x4FA775: load_needed (module.c:4132)
==7134==    by 0x4FA775: load_needed (module.c:4132)
==7134==    by 0x4FA780: load_needed (module.c:4133)
==7134==    by 0x4FA775: load_needed (module.c:4132)
==7134== 


and several other similar messages.

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |janus at gcc dot gnu.org

--- Comment #20 from janus at gcc dot gnu.org 2010-10-21 12:28:23 UTC ---
I fail to reproduce the ICE with today's r165769. Hans, are you still getting
this error? (If you do, maybe you can try to get a backtrace with gdb. Btw,
what architecture/OS are you on?)

valgrind shows me a couple of memory leaks, but no invalid memory accesses.

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

[burnus at gcc dot gnu.org]

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

--- Comment #21 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-10-21 14:04:12 UTC ---
(In reply to comment #20)
> I fail to reproduce the ICE with today's r165769. Hans, are you still getting
> this error?

Frankly, I already got lost in comment 12 with regards to which version shows
the bug and which doesn't.

In light of comment 15 (cf. excerpt below) and given that there was no useful
output with valgrind, I would suggest to close this PR as WORKSFORME. If the
error re-appears, one can open a new PR. Hans, would it be OK to close the bug?

(In reply to comment #15)
> Revision 20100928 compiles my code, so it's fine for me now. But I have got
> huge tables of use statements in my modules and I continue to get this error
> message, when I forget to explicitly "use" the whole tree of modules.
> 
> It also might has been a coincidence that the error disappeared when I renamed
> kind.f90 to kinds.f03. I did the same for 20100928, and it didn't work. But
> mentioning all modules works for 20100928.

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

[boschmann at tp1 dot physik.uni-siegen.de]

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

--- Comment #22 from Hans-Werner Boschmann <boschmann at tp1 dot physik.uni-siegen.de> 2010-10-24 10:17:00 UTC ---
Yes, I still get the error with later revisions. I am using an amd64 machine
with open SuSE 11.2. Here are some updates of my statements:

* All means like renaming files or using -std=f2003 coincidentally fixed the
problem for a specific revision and a specific peace of code. This is no
general fix.

* I also got the error with 4.6.0-20100928 when I changed some lines of code.

* Putting all use statements in "proper order" fixes the problem for all
revisions, including 4.6.0-20100921. I noticed later, that I forgot to sort the
intrinsic module iso_fortran_env in the example. It is mentioned before kinds
in arguments_module and after kinds in common_module.

* Not putting use statements into "proper order" doesn't mean that the error
shows up, it randomly appears sometimes while you edit the code.

So I have to update use statements in all modules, when I change dependencies
in a fundamental module. That's really annoying, but it is a workaround for all
revisions so far. Still, this is not what I take to mean "works for me".

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

[burnus at gcc dot gnu.org]

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

--- Comment #23 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-10-24 11:10:18 UTC ---
(In reply to comment #22)
> Yes, I still get the error with later revisions.
:-(

> * Not putting use statements into "proper order" doesn't mean that the error
> shows up, it randomly appears sometimes while you edit the code.

When it appears, can you try (again) with valgrind (on f951) to see whether it
shows some issues like uninitialised variables?

I assume that there is some underlying memory access problem, e.g. an
uninitialized variable or a dangling pointer. However, those errors tend to be
difficult to track down - and without being able to either reproduce it nor
having more information than "mio_component_ref(): Component not found", it is
almost impossible to track down the error :-(

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

[mikael at gcc dot gnu.org]

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

--- Comment #24 from Mikael Morin <mikael at gcc dot gnu.org> 2010-10-24 11:56:39 UTC ---
(In reply to comment #22)
> Still, this is not what I take to mean "works for me".
WORKSFORME means that it works for us. If it was working for you, I assume you
wouldn't have reported the bug ;-).

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

[mikael at gcc dot gnu.org]

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

--- Comment #25 from Mikael Morin <mikael at gcc dot gnu.org> 2010-10-24 12:02:34 UTC ---
Created attachment 22140
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22140
Version of the test that works for me.

Just to be clear. Can you check that with the just attached version of your
sample code you still have the problem ? I tried to reorder some use statements
on it and it still works fine.

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

[jvdelisle at gcc dot gnu.org]

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

--- Comment #26 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2010-10-24 15:14:59 UTC ---
I did not see any reply to my comment #19.  Isn't it obvious there is something
wromg at that point in the module.c ?  Did I miss something in the thread here?

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

[mikael at gcc dot gnu.org]

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

--- Comment #27 from Mikael Morin <mikael at gcc dot gnu.org> 2010-10-24 15:48:27 UTC ---
(In reply to comment #26)
> I did not see any reply to my comment #19.  Isn't it obvious there is something
> wromg at that point in the module.c ?
No, it's unreleased memory; it's harmless. Valgrind shows these _warnings_ with
the --leak-check=full argument if one wants to track unfreed pointers. It means
that gfortran could be improved to save a few kBs of memory, but not that we
are using uninitialized data, writing to random unallocated places or doing
whatever deserving an _error_. 
What's important is "0 errors from 0 contexts" in the summary at the end. 

Note that sometimes fixing a warning exposes genuine errors, so it's not just
as simple as that.

>  Did I miss something in the thread here?
What _I_ miss is a code to reproduce the error. :-(

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

[jvdelisle at gcc dot gnu.org]

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

--- Comment #28 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2010-10-24 18:56:49 UTC ---
There is a quality of implementation issue going on here.  Our goal has always
been "zero" leaks.  The reason?  These errors can and do mask other things
going on.  This to me looks like some pointers are being whacked. maybe
previously allocated space being reused that should not be.  At this point
no-one knows.

==4891== LEAK SUMMARY:
==4891==    definitely lost: 33,500 bytes in 230 blocks
==4891==    indirectly lost: 3,056 bytes in 150 blocks
==4891==      possibly lost: 0 bytes in 0 blocks
==4891==    still reachable: 320,546 bytes in 1,341 blocks
==4891==         suppressed: 0 bytes in 0 blocks
==4891== Reachable blocks (those to which a pointer was found) are not shown.
==4891== To see them, rerun with: --leak-check=full --show-reachable=yes
==4891== 
==4891== For counts of detected and suppressed errors, rerun with: -v
==4891== ERROR SUMMARY: 20 errors from 20 contexts (suppressed: 6 from 6)

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

[mikael at gcc dot gnu.org]

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

--- Comment #29 from Mikael Morin <mikael at gcc dot gnu.org> 2010-10-24 19:59:20 UTC ---
(In reply to comment #28)
> There is a quality of implementation issue going on here.  Our goal has always
> been "zero" leaks.  The reason?  These errors can and do mask other things
> going on.  This to me looks like some pointers are being whacked. maybe
> previously allocated space being reused that should not be.  At this point
> no-one knows.
> 
The testsuite shows that gfortran mostly works. Based on that, the memory leaks
are probably harmless, and I assume they are. But of course you're completely
right.

Here, the fact that the gfc_typebound_proc structs are never freed doesn't help
for the "zero leak" goal.

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

[boschmann at tp1 dot physik.uni-siegen.de]

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

--- Comment #30 from Hans-Werner Boschmann <boschmann at tp1 dot physik.uni-siegen.de> 2010-10-26 15:27:27 UTC ---
I've realized today, that the sample code is actually invalid. If you look at
lines 488 and 681 in arguments.f03, you'll see:

subroutine
argument_initialize(this,arg_list,short,long,description,description_list,named_option)
subroutine real_argument_initialize(this)

These subroutines seem to have different interfaces, but when you have a closer
look, you see that all dummy arguments are optional, except "this". Besides,
both "this" dummy arguments are type compatible. Therefore these subroutines
must not share a generic interface. But that is declared in line 133:

generic::initialize=>argument_initialize,real_argument_initialize

Could this ambiguity cause the confusion about symbols? I always have suspected
this module to be the reason for the error, because I never got the error
message before I wrote it. Furthermore, all error messages were somehow related
to this module, even when they were generated for other modules. 

Nevertheless, gfortran should complain about the ambiguity. I will try to
reduce the code to illustrate this point and open a new bug report.

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

[boschmann at tp1 dot physik.uni-siegen.de]

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

--- Comment #31 from Hans-Werner Boschmann <boschmann at tp1 dot physik.uni-siegen.de> 2010-10-27 09:35:07 UTC ---
I've posted the generic issue as Bug 46196

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

[dfranke at gcc dot gnu.org]

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

Daniel Franke <dfranke at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dfranke at gcc dot gnu.org

--- Comment #32 from Daniel Franke <dfranke at gcc dot gnu.org> 2010-12-27 02:22:45 UTC ---
Same error for this testcase:

MODULE abstract_weight_policy
  TYPE, ABSTRACT :: abstract_weight
    PRIVATE
    INTEGER              :: n
    REAL(8), ALLOCATABLE :: w(:)
  CONTAINS
    PROCEDURE(create), DEFERRED :: create
    PROCEDURE                   :: get
    PROCEDURE                   :: destroy
  END TYPE

  ABSTRACT INTERFACE
    SUBROUTINE create(this, n, s, I)
      IMPORT abstract_weight
      CLASS(abstract_weight), INTENT(inout) :: this
      INTEGER, INTENT(in)           :: n
      REAL(8), INTENT(in)           :: s(n), I(n)
    END SUBROUTINE
  END INTERFACE

CONTAINS
  PURE FUNCTION get(this)
    CLASS(abstract_weight), INTENT(in) :: this
    REAL(8), DIMENSION(this%n) :: get
    get = this%w
  END FUNCTION

  SUBROUTINE destroy(this)
    CLASS(abstract_weight), INTENT(inout) :: this
    IF (ALLOCATED(this%w)) DEALLOCATE(this%w)
    this%n = 0
  END SUBROUTINE
END MODULE

MODULE myweights_policy
  USE abstract_weight_policy
END MODULE

$> gfortran-svn -Wall -W polytest.f90 
polytest.f90:36.28:

  USE abstract_weight_policy
                            1
Internal Error at (1):
mio_component_ref(): Component not found

$ gfortran-svn -v
gcc version 4.6.0 20101226 (experimental) (GCC) 


The error is consistent and reproducible for me, nothing fishy from valgrind.
Although the error is identical, no idea if the reason to trigger it is the
same as the reporter's.

[Bug fortran/45827] [4.6 Regression] mio_component_ref(): Component not found

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|mio_component_ref():        |[4.6 Regression]
                   |Component not found when    |mio_component_ref():
                   |mixing f90 and f03 in large |Component not found
                   |projects                    |

--- Comment #33 from janus at gcc dot gnu.org 2010-12-27 14:22:12 UTC ---
(In reply to comment #32)
> Same error for this testcase:

Thanks for the test case, Daniel. Here is a slightly reduced version:


MODULE m

  TYPE, ABSTRACT :: t
    PRIVATE
    INTEGER   :: n
  CONTAINS
    PROCEDURE :: get
  END TYPE

  ABSTRACT INTERFACE
    SUBROUTINE create(this)
      IMPORT t
      CLASS(t) :: this
    END SUBROUTINE
  END INTERFACE

CONTAINS

  FUNCTION get(this)
    CLASS(t) :: this
    REAL, DIMENSION(this%n) :: get
  END FUNCTION

  SUBROUTINE destroy(this)
    CLASS(t) :: this
  END SUBROUTINE

END MODULE


PROGRAM p
  USE m
END


Also, note that this is a regression (the test case works with 4.5).

[Bug fortran/45827] [4.6 Regression] mio_component_ref(): Component not found

[dfranke at gcc dot gnu.org]

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

--- Comment #34 from Daniel Franke <dfranke at gcc dot gnu.org> 2010-12-27 14:27:36 UTC ---
With both testcases, tracing the search in module.c(mio_component_ref), I get:
mio_component_ref: looking for 'n', current: '_data'
mio_component_ref: looking for 'n', current: '_vptr'
polytest.f90:36.28:

  USE abstract_weight_policy
                            1
Internal Error at (1):
mio_component_ref(): Component not found

Does this help?

[Bug fortran/45827] [4.6 Regression] [OOP] mio_component_ref(): Component not found

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |janus at gcc dot gnu.org
                   |gnu.org                     |
            Summary|[4.6 Regression]            |[4.6 Regression] [OOP]
                   |mio_component_ref():        |mio_component_ref():
                   |Component not found         |Component not found

--- Comment #35 from janus at gcc dot gnu.org 2010-12-27 15:36:44 UTC ---
(In reply to comment #34)
> Does this help?

Yes, I think I know what's going on. One way to fix it is the following:

Index: gcc/fortran/module.c
===================================================================
--- gcc/fortran/module.c        (revision 168019)
+++ gcc/fortran/module.c        (working copy)
@@ -2317,6 +2317,9 @@ mio_component_ref (gfc_component **cp, gfc_symbol
       if (sym == NULL)
        return;

+      if (sym->attr.is_class)
+       sym = sym->components->ts.u.derived;
+      
       if (sym->components != NULL && p->u.pointer == NULL)
        {
          /* Symbol already loaded, so search by name.  */

[Bug fortran/45827] [4.6 Regression] [OOP] mio_component_ref(): Component not found

[dfranke at gcc dot gnu.org]

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

--- Comment #36 from Daniel Franke <dfranke at gcc dot gnu.org> 2010-12-27 22:18:27 UTC ---
(In reply to comment #35)
> Yes, I think I know what's going on. One way to fix it is the following:

I managed to get an ICE with your version (sym == NULL), this seems to work
(not regtested):

Index: module.c
===================================================================
--- module.c    (revision 168256)
+++ module.c    (working copy)
@@ -2311,6 +2311,9 @@
     {
       mio_internal_string (name);

+      if (sym && sym->attr.is_class)
+        sym = sym->components->ts.u.derived;
+
       /* It can happen that a component reference can be read before the
         associated derived type symbol has been loaded. Return now and
         wait for a later iteration of load_needed.  */

[Bug fortran/45827] [4.6 Regression] [OOP] mio_component_ref(): Component not found

[janus at gcc dot gnu.org]

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

--- Comment #37 from janus at gcc dot gnu.org 2010-12-28 08:14:46 UTC ---
(In reply to comment #36)
> (In reply to comment #35)
> > Yes, I think I know what's going on. One way to fix it is the following:
> 
> I managed to get an ICE with your version (sym == NULL)

No, that's not possible. My version (i.e. comment #35) is inserted at a
slightly different place than yours, where the existence of 'sym' is already
established. Also I have checked that it regtests cleanly. Ok if I commit it to
trunk?

[Bug fortran/45827] [4.6 Regression] [OOP] mio_component_ref(): Component not found

[dfranke at gcc dot gnu.org]

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

--- Comment #38 from Daniel Franke <dfranke at gcc dot gnu.org> 2010-12-28 12:22:48 UTC ---
Created attachment 22856
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22856
testcase, ICE with patch in comment #35

(In reply to comment #37)
> > I managed to get an ICE with your version (sym == NULL)
> 
> No, that's not possible. My version (i.e. comment #35) is inserted at a
> slightly different place than yours, where the existence of 'sym' is already
> established.

Err, sure it is possible:

+      if (sym->attr.is_class)
+       sym = sym->components->ts.u.derived;

After this, sym is not checked any more and the ICE occurs in the next line:

       if (sym->components != NULL && p->u.pointer == NULL)
           ^^^

That's why I moved it up a few lines and double check that sym really is
non-NULL.

[Bug fortran/45827] [4.6 Regression] [OOP] mio_component_ref(): Component not found

[janus at gcc dot gnu.org]

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

--- Comment #39 from janus at gcc dot gnu.org 2010-12-28 13:18:41 UTC ---
(In reply to comment #38)
> > > I managed to get an ICE with your version (sym == NULL)
> > 
> > No, that's not possible. My version (i.e. comment #35) is inserted at a
> > slightly different place than yours, where the existence of 'sym' is already
> > established.
> 
> Err, sure it is possible:

Ok, I get it. Sorry about the misconception. Feel free to commit the patch in
comment #36 (provided it regtests ok). Or should I take care of it?

[Bug fortran/45827] [4.6 Regression] [OOP] mio_component_ref(): Component not found

[dfranke at gcc dot gnu.org]

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

--- Comment #40 from Daniel Franke <dfranke at gcc dot gnu.org> 2010-12-28 17:27:00 UTC ---
(In reply to comment #39)
> Ok, I get it. Sorry about the misconception. Feel free to commit the patch in
> comment #36 (provided it regtests ok). Or should I take care of it?

Please, you did the hard work - it's yours :)

Regression tested on i686-pc-linux-gnu - there is one regression in
realloc_on_assign_2.f03, but that does not seem to be related to this patch?!

[Bug fortran/45827] [4.6 Regression] [OOP] mio_component_ref(): Component not found

[janus at gcc dot gnu.org]

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

--- Comment #41 from janus at gcc dot gnu.org 2010-12-28 18:53:19 UTC ---
(In reply to comment #40)
> > Feel free to commit the patch in
> > comment #36 (provided it regtests ok). Or should I take care of it?
> 
> Please, you did the hard work - it's yours :)

Alright, will commit shortly.


> Regression tested on i686-pc-linux-gnu - there is one regression in
> realloc_on_assign_2.f03, but that does not seem to be related to this patch?!

No, it's unrelated. For me this failure only appears for simple builds, but not
if I do a full boostrap. Maybe one should open a PR for it.

Anyway, thanks for regtesting.

[Bug fortran/45827] [4.6 Regression] [OOP] mio_component_ref(): Component not found

[janus at gcc dot gnu.org]

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

--- Comment #42 from janus at gcc dot gnu.org 2010-12-28 21:21:56 UTC ---
Author: janus
Date: Tue Dec 28 21:21:53 2010
New Revision: 168302

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168302
Log:
2010-12-28  Janus Weil  <janus@gcc.gnu.org>
        Daniel Franke  <dfranke@gcc.gnu.org>

    PR fortran/45827
    * module.c (mio_component_ref): Handle components of CLASS variables.


2010-12-28  Janus Weil  <janus@gcc.gnu.org>

    PR fortran/45827
    * gfortran.dg/class_32.f90: New.

Added:
    trunk/gcc/testsuite/gfortran.dg/class_32.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/module.c
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/45827] [4.6 Regression] [OOP] mio_component_ref(): Component not found

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4
                 CC|                            |jakub at gcc dot gnu.org

[Bug fortran/45827] [4.6 Regression] [OOP] mio_component_ref(): Component not found

[janus at gcc dot gnu.org]

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

--- Comment #43 from janus at gcc dot gnu.org 2011-01-02 21:27:48 UTC ---
Hans, does r168302 fix the problem for you, or do you still get "Component not
found" errors?

[Bug fortran/45827] [4.6 Regression] [OOP] mio_component_ref(): Component not found

[boschmann at tp1 dot physik.uni-siegen.de]

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

--- Comment #44 from Hans-Werner Boschmann <boschmann at tp1 dot physik.uni-siegen.de> 2011-01-03 12:55:53 UTC ---
I've run my project on R168414, there are no error messages so far. Thank you
all for making this fix, this bug has bothered me for a long time.

[Bug fortran/45827] [4.6 Regression] [OOP] mio_component_ref(): Component not found

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #45 from janus at gcc dot gnu.org 2011-01-03 13:14:13 UTC ---
(In reply to comment #44)
> I've run my project on R168414, there are no error messages so far.

Great, thanks for checking. I'm closing this bug as fixed.