Bug 45827 - [4.6 Regression] [OOP] mio_component_ref(): Component not found
Summary: [4.6 Regression] [OOP] mio_component_ref(): Component not found
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.6.0
: P4 normal
Target Milestone: 4.6.0
Assignee: janus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-09-29 07:40 UTC by Hans-Werner Boschmann
Modified: 2011-01-03 13:14 UTC (History)
7 users (show)

See Also:
Host:
Target:
Build:
Known to work: 4.5.2
Known to fail: 4.6.0
Last reconfirmed: 2010-09-29 08:54:49


Attachments
The sample source code of this bug report (9.31 KB, application/x-gzip)
2010-09-29 07:40 UTC, Hans-Werner Boschmann
Details
Version of the test that works for me. (8.11 KB, application/x-bzip-compressed-tar)
2010-10-24 12:02 UTC, Mikael Morin
Details
testcase, ICE with patch in comment #35 (617 bytes, text/x-fortran)
2010-12-28 12:22 UTC, Daniel Franke
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hans-Werner Boschmann 2010-09-29 07:40:49 UTC
Created attachment 21911 [details]
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
Comment 1 Joost VandeVondele 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.
Comment 2 Joost VandeVondele 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 ()
Comment 3 Tobias Burnus 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].)
Comment 4 Joost VandeVondele 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.
Comment 5 Mikael Morin 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...
Comment 6 Joost VandeVondele 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.
Comment 7 Mikael Morin 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.
Comment 8 Mikael Morin 2010-09-29 11:24:18 UTC
Hans, is the error gone once you have fixed your makefile ?
Comment 9 Hans-Werner Boschmann 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
Comment 10 Mikael Morin 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)
Comment 11 Hans-Werner Boschmann 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.
Comment 12 Tobias Burnus 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.
Comment 13 Hans-Werner Boschmann 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.
Comment 14 Tobias Burnus 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).
Comment 15 Hans-Werner Boschmann 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.
Comment 16 Hans-Werner Boschmann 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.
Comment 17 Tobias Burnus 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. :-(
Comment 18 Jerry DeLisle 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)
Comment 19 Jerry DeLisle 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.
Comment 20 janus 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.
Comment 21 Tobias Burnus 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.
Comment 22 Hans-Werner Boschmann 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".
Comment 23 Tobias Burnus 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 :-(
Comment 24 Mikael Morin 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 ;-).
Comment 25 Mikael Morin 2010-10-24 12:02:34 UTC
Created attachment 22140 [details]
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.
Comment 26 Jerry DeLisle 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?
Comment 27 Mikael Morin 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. :-(
Comment 28 Jerry DeLisle 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)
Comment 29 Mikael Morin 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.
Comment 30 Hans-Werner Boschmann 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.
Comment 31 Hans-Werner Boschmann 2010-10-27 09:35:07 UTC
I've posted the generic issue as Bug 46196
Comment 32 Daniel Franke 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.
Comment 33 janus 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).
Comment 34 Daniel Franke 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?
Comment 35 janus 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.  */
Comment 36 Daniel Franke 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.  */
Comment 37 janus 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?
Comment 38 Daniel Franke 2010-12-28 12:22:48 UTC
Created attachment 22856 [details]
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.
Comment 39 janus 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?
Comment 40 Daniel Franke 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?!
Comment 41 janus 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.
Comment 42 janus 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
Comment 43 janus 2011-01-02 21:27:48 UTC
Hans, does r168302 fix the problem for you, or do you still get "Component not found" errors?
Comment 44 Hans-Werner Boschmann 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.
Comment 45 janus 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.