Bug 12204 - [3.4 regression] gcc emits bogus .file when __inline__ called
Summary: [3.4 regression] gcc emits bogus .file when __inline__ called
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: debug (show other bugs)
Version: 3.4.0
: P1 critical
Target Milestone: 3.4.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-09-08 00:35 UTC by mec
Modified: 2005-07-23 22:49 UTC (History)
2 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed:


Attachments
Input that triggers the bug (169 bytes, application/octet-stream)
2003-09-08 00:36 UTC, mec
Details
Assembly file before the bug (1009 bytes, application/octet-stream)
2003-09-08 00:37 UTC, mec
Details
assembly output after the bug (1.01 KB, application/octet-stream)
2003-09-08 00:39 UTC, mec
Details

Note You need to log in before you can comment on or make changes to this bug.
Description mec 2003-09-08 00:35:05 UTC
gcc emits a bogus ".file" directive when an __inline__ function is called.

I will attach a full test program, before-and-after output, and so on.  Here is
a snippet of the test program:

  # 1 "z2.c"
  # 1 "/usr/include/sys/stat.h" 1 3
  # 337 "/usr/include/sys/stat.h" 3

  extern __inline__ int fstat ()
  {
    return 0;
  }

  #2 "z2.c" 2

  ...

  int
  test_fstat ()
  {
    marker1 ();
    fstat ();
    marker2 ();
    return 0;
  }

Here is the output from "gcc -gdwarf-2 -S":

  .globl main
          .type main, @function
  main:
  .LFB6:
          .file 2 "/usr/include/sys/stat.h"
          .loc 2 23 0
          pushl %ebp
  .LCFI7:
          movl %esp, %ebp

That ".file" directive is bogus!

This happens with gcc HEAD 2003-09-03 15:00:00 UTC.
It does not happen with gcc HEAD 2003-09-03 14:00:00 UTC.
The patch responsible is:

http://gcc.gnu.org/ml/gcc-patches/2003-09/msg00000.html

Wed Sep  3 16:55:25 CEST 2003  Jan Hubicka  <jh@suse.cz>
+                                                                              
+       * Makefile.in (c-objc-common.o): Kill gt-c-objc-common.h dependency.
+       * c-decl.c (finish_function):  Kill arguments, always use cgraph path. 
+       * c-objc-common.c: Kill include of gt-c-objc-common.h
+       (expand_deferred_fns, deffer_fn): Kill function.                       
+       (deferred_fns): Kill variable.
+       (finish_cdtor): Update finish_function call.                           
+       (c_objc_common_finish_file): Always call cgraph code.
+       * c-parse.c: Regenerate.                                               
+       * c-parse.y: Regenerate.
+       * c-tree.h (finish_function): Update prototype.                        
+       * objc-acct.c (build_module_descriptor, finish_method_def):
+       Update call of finish_function.                                        
+       * cgraphunit.c (cgraph_default_inline_p, cgraph_analyze_function): Add
+       forward prototype.                                                     
+       (cgraph_finalize_function): In non-unit-at-a-time mode analyze the
+       function and assemble it if needed.                                    
+       (cgraph_finalize_compilation_unit): Do nothing in non-unit-at-a-time
+       mode.                                                                  
+       (cgraph_optimize): Likewise.
+       (cgraph_expand_function): In non-unit-at-a-time mode keep function body
+       even when it has no inline callees.
+       * c-parse.in: Update calls to finish_function.                          +

This is a regression against gcc 3.3.1, so I am marking it "P1", although it is
just normal severity.
Comment 1 mec 2003-09-08 00:36:27 UTC
Created attachment 4713 [details]
Input that triggers the bug

This is a .i file.  I started with fileio.c in the gdb test suite (which is
where I encountered the bug) and stripped it down to a minimal case.
Comment 2 mec 2003-09-08 00:37:33 UTC
Created attachment 4714 [details]
Assembly file before the bug

This is assembly output from "gcc -gdwarf-2 -S" with gcc HEAD 2003-09-03
14:00:00 UTC, before the bug started happening.
Comment 3 mec 2003-09-08 00:39:04 UTC
Created attachment 4715 [details]
assembly output after the bug

This is assembly output from "gcc -gdwarf-2 -S" from 2003-09-03 15:00:00 UTC,
after the bug started happening.

The bad assembly line is the ".file ... stat.h" at the beginning of test_fstat.
Comment 4 mec 2003-09-11 21:03:41 UTC
The bug has been fixed.  The symptoms no longer happens with gcc HEAD 2003-09-10
18:52:57 UTC.  I tested with the z2.i file attached to the bug report as well as
the original test case from the gdb test suite.

The patch which caused the bug was in the call graph code.  I haven't
regression-searched for the patch which fixes the bug, but given the changes in
the call graph code lately, I am comfortable that the bug got fixed "on purpose"
rather than "completely by accident".

gdb has a test case which stumbles on this (gdb.base/fileio.exp), so if the bug
happens again, I will notice it again.

It's okay with me to close this PR.  Happy day!
Comment 5 Andrew Pinski 2003-09-11 21:06:42 UTC
Fixed according to the submitter.