[Bug fortran/33408] ICE: tree check: expected type_decl, have in debug_flush_symbol_queue, at final.c:3986

["fxcoudert at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #11 from fxcoudert at gcc dot gnu dot org  2007-10-01 11:19 -------
(In reply to comment #10)
> It looks like it is now only a Macintosh PowerPC version problem. It also
> works Ok on the Intel Macintosh and on the MSYS versions of gfortran.

I can confirm that bug on ppc-darwin. It disappears when you change -g into
-gdwarf-2, making it a stabs-related issue. This is further proved by running
under valgrind on x86_64-linux with -gstabs, where I can see invalid reads,
even for the very small testcase:

$ cat out.f
# 1 "outt.F"
      end
$ valgrind ./libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/f951 out.f -quiet
-gstabs
==501== Memcheck, a memory error detector.
==501== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==501== Using LibVEX rev 1658, a library for dynamic binary translation.
==501== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==501== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation
framework.
==501== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==501== For more details, rerun with: -v
==501==
==501== Invalid read of size 1
==501==    at 0x4A1C7D1: strcmp (mc_replace_strmem.c:341)
==501==    by 0x50E1F1: dbxout_source_line (dbxout.c:1231)
==501==    by 0x50E5C4: dbxout_begin_prologue (dbxout.c:1258)
==501==    by 0x59174F: final_start_function (final.c:1444)
==501==    by 0x593EA6: rest_of_handle_final (final.c:4049)
==501==    by 0x6516C0: execute_one_pass (passes.c:1116)
==501==    by 0x65189F: execute_pass_list (passes.c:1169)
==501==    by 0x6518B4: execute_pass_list (passes.c:1170)
==501==    by 0x6518B4: execute_pass_list (passes.c:1170)
==501==    by 0x72BEC7: tree_rest_of_compilation (tree-optimize.c:404)
==501==    by 0x8A1973: cgraph_expand_function (cgraphunit.c:1070)
==501==    by 0x8A2C45: cgraph_assemble_pending_functions (cgraphunit.c:431)
[... rest of output snipped ...]

Now, there are good news: my patch for PR33502 (the updated one, attached to
the PR), which reworks the way the front-end treats preprocessor lines and
emits debug info, apparently fixes this simple testcase. So, there's a good
chance that this PR will be fixed when that patch gets committed. Wait and see!
(Or apply the patch and test for yourself, Dale, if you have the resources to
do so).


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2007-09-17 09:33:47         |2007-10-01 11:19:13
               date|                            |


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