Bug 16103 - -Os does not remove a nested func even when inlined
Summary: -Os does not remove a nested func even when inlined
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 3.4.0
: P2 normal
Target Milestone: 4.0.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-06-20 18:38 UTC by Yoshinori K. Okuji
Modified: 2005-07-23 22:49 UTC (History)
1 user (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
The preprocessed file of my source file (254 bytes, text/plain)
2004-06-20 18:40 UTC, Yoshinori K. Okuji
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yoshinori K. Okuji 2004-06-20 18:38:20 UTC
Configured with: ../configure --enable-languages=c
Thread model: posix
gcc version 3.4.0

GCC 3.4.0 seems to inline some nested functions, but sometimes it does not
remove the standalone definitions of them even if they are not referred at all.
This increases the binary size unnecessarily. I compiled my C source file in
this way:

/usr/local/bin/gcc -c -Os -save-temps nested.c

I checked the object file by objdump. This is a small version of the source file
which reproduces the same result:

----------------------------------------------------------

int
next_partition (unsigned long drive, unsigned long dest,
		unsigned long *partition, int *type,
		unsigned long *start, unsigned long *len,
		unsigned long *offset, int *entry,
		unsigned long *ext_offset, char *buf)
{
  auto int next_bsd_partition (void);
  auto int next_pc_slice (void);

  int next_bsd_partition (void)
    {
      return 0;
    }

  int next_pc_slice (void)
    {
      return 1;
    }

  if (*partition != 0xFFFFFF)
    {
      return next_bsd_partition ();
    }
	  
  return next_pc_slice ();
}

----------------------------------------------------------

Even though the function next_partition does not call next_bsd_partition.0 or
next_pc_slice.1 in the object file, their defnitions are left.
Comment 1 Yoshinori K. Okuji 2004-06-20 18:40:59 UTC
Created attachment 6583 [details]
The preprocessed file of my source file

This is a small version of my source file which reproduces the same result.
Comment 2 Andrew Pinski 2004-06-20 18:45:56 UTC
Fixed on the mainline, by the unnested functionality of the tree-ssa.