From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18323 invoked by alias); 30 Sep 2010 13:03:25 -0000 Received: (qmail 18284 invoked by uid 22791); 30 Sep 2010 13:03:20 -0000 X-SWARE-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50,MISSING_MID,T_FRT_FREE X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 30 Sep 2010 13:03:12 +0000 From: "boschmann at tp1 dot physik.uni-siegen.de" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: boschmann at tp1 dot physik.uni-siegen.de X-Bugzilla-Status: WAITING X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.6.0 X-Bugzilla-Changed-Fields: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Thu, 30 Sep 2010 17:47:00 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-09/txt/msg03267.txt.bz2 Message-ID: <20100930174700.AaseED-98hdw5493fDb9_luKXEMoZVaTGU_A0FCJrAQ@z> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827 --- Comment #13 from 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 | grep f951` > > Memory related errors tend to show up only on few machines and in irregular > patterns, which makes finding them difficult.