public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "boschmann at tp1 dot physik.uni-siegen.de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects
Date: Thu, 30 Sep 2010 17:47:00 -0000 [thread overview]
Message-ID: <20100930174700.AaseED-98hdw5493fDb9_luKXEMoZVaTGU_A0FCJrAQ@z> (raw)
In-Reply-To: <bug-45827-4@http.gcc.gnu.org/bugzilla/>
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.
next prev parent reply other threads:[~2010-09-30 13:03 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-29 11:49 [Bug fortran/45827] New: " boschmann at tp1 dot physik.uni-siegen.de
2010-09-29 12:37 ` [Bug fortran/45827] " Joost.VandeVondele at pci dot uzh.ch
2010-09-29 12:44 ` [Bug fortran/45827] [4.6 Regression] ice in create_int_parameter_array Joost.VandeVondele at pci dot uzh.ch
2010-09-29 12:49 ` burnus at gcc dot gnu.org
2010-09-29 12:54 ` Joost.VandeVondele at pci dot uzh.ch
2010-09-29 13:02 ` mikael at gcc dot gnu.org
2010-09-29 13:18 ` Joost.VandeVondele at pci dot uzh.ch
2010-09-29 14:22 ` [Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects mikael at gcc dot gnu.org
2010-09-29 14:30 ` boschmann at tp1 dot physik.uni-siegen.de
2010-09-29 14:30 ` mikael at gcc dot gnu.org
2010-09-29 14:59 ` mikael at gcc dot gnu.org
2010-09-30 10:19 ` boschmann at tp1 dot physik.uni-siegen.de
2010-09-30 10:44 ` burnus at gcc dot gnu.org
2010-09-30 17:47 ` boschmann at tp1 dot physik.uni-siegen.de [this message]
2010-09-30 18:39 ` burnus at gcc dot gnu.org
2010-10-01 6:52 ` boschmann at tp1 dot physik.uni-siegen.de
2010-10-01 7:57 ` boschmann at tp1 dot physik.uni-siegen.de
2010-10-01 8:13 ` burnus at gcc dot gnu.org
2010-10-01 14:39 ` jvdelisle at gcc dot gnu.org
[not found] ` <20101001143948.D63711C0008C@msfrf2419.sfr.fr>
2010-10-01 15:17 ` Mikael Morin
2010-10-01 17:42 ` jvdelisle at gcc dot gnu.org
2010-10-21 12:28 ` janus at gcc dot gnu.org
2010-10-21 14:04 ` burnus at gcc dot gnu.org
2010-10-24 10:17 ` boschmann at tp1 dot physik.uni-siegen.de
2010-10-24 11:10 ` burnus at gcc dot gnu.org
2010-10-24 11:56 ` mikael at gcc dot gnu.org
2010-10-24 12:02 ` mikael at gcc dot gnu.org
2010-10-24 15:15 ` jvdelisle at gcc dot gnu.org
2010-10-24 15:48 ` mikael at gcc dot gnu.org
2010-10-24 18:57 ` jvdelisle at gcc dot gnu.org
2010-10-24 19:59 ` mikael at gcc dot gnu.org
2010-10-26 15:27 ` boschmann at tp1 dot physik.uni-siegen.de
2010-10-27 9:35 ` boschmann at tp1 dot physik.uni-siegen.de
2010-12-27 2:23 ` dfranke at gcc dot gnu.org
2010-12-27 14:22 ` [Bug fortran/45827] [4.6 Regression] mio_component_ref(): Component not found janus at gcc dot gnu.org
2010-12-27 14:27 ` dfranke at gcc dot gnu.org
2010-12-27 15:37 ` [Bug fortran/45827] [4.6 Regression] [OOP] " janus at gcc dot gnu.org
2010-12-27 22:18 ` dfranke at gcc dot gnu.org
2010-12-28 8:15 ` janus at gcc dot gnu.org
2010-12-28 12:23 ` dfranke at gcc dot gnu.org
2010-12-28 13:19 ` janus at gcc dot gnu.org
2010-12-28 17:27 ` dfranke at gcc dot gnu.org
2010-12-28 18:53 ` janus at gcc dot gnu.org
2010-12-28 21:22 ` janus at gcc dot gnu.org
2010-12-31 11:21 ` jakub at gcc dot gnu.org
2011-01-02 21:28 ` janus at gcc dot gnu.org
2011-01-03 12:56 ` boschmann at tp1 dot physik.uni-siegen.de
2011-01-03 13:14 ` janus at gcc dot gnu.org
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100930174700.AaseED-98hdw5493fDb9_luKXEMoZVaTGU_A0FCJrAQ@z \
--to=gcc-bugzilla@gcc.gnu.org \
--cc=gcc-bugs@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).