Bug 18713 - Large program size due to uninitialised global data
Summary: Large program size due to uninitialised global data
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 3.2.3
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: missed-optimization
Depends on:
Blocks:
 
Reported: 2004-11-29 08:15 UTC by Goh Boon Yeow
Modified: 2005-07-23 22:49 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Goh Boon Yeow 2004-11-29 08:15:01 UTC 
Configured with: ../sco/gcc-3.2.3/configure --prefix=/usr/local/gcc-3.2.3 --
enable-languages=c++ --with-gnu-as
Thread model: single
gcc version 3.2.3

System: SCO Unix 5.0.5

Compilation of source programs with declared but unitialised global data on the 
SCO system seems to cause the program to grow in proportion with the size of 
the data. Uninitialised data should be stored under BSS or the common section 
of a program. This seems to be the case for Linux but not on SCO.

-----
Test program: foo.cpp

struct My_t {
        char            myData[2048];
};
My_t myArr[10240];

int main ()
{
        return 0;
}

-----
Compilation: gcc -O -fconserve-space foo.cpp -lstdc++
Size listing (ls -l a.out) on SCO: 20977120
Size listing (ls -l a.out) on RedHat: 11341

However, converting the same program to a C standard and compiling with gcc on 
SCO produces the expected object code size as follows:

-----
Test program: foo.c

struct My_t {
        char            myData[2048];
};
struct My_t myArr[10240];

int
main ()
{
        return 0;
}

-----
Compilation: gcc foo.c
Size listing (ls -l a.out) on SCO: 5604
Comment 1 Goh Boon Yeow 2004-12-08 04:11:57 UTC 
Follow up on the earlier report, the size problem goes away when the global 
variables are declared as static:

struct My_t {
        char            myData[2048];
};
static My_t myArr[10240];

int main ()
{
        return 0;
}

Using nm on the object files that were generated:
without static keyword:
Symbols from foo.o:

[Index]   Value      Size    Type  Bind  Other Shndx   Name

[1]     |         0|       0|FILE |LOCL |0    |ABS    |foo.cpp
[2]     |         0|       0|SECT |LOCL |0    |2      |
[3]     |         0|       0|SECT |LOCL |0    |4      |
[4]     |         0|       0|SECT |LOCL |0    |5      |
[5]     |         0|       0|SECT |LOCL |0    |1      |
[6]     |         0|       0|SECT |LOCL |0    |6      |
[7]     |         0|20971520|OBJT |GLOB |0    |4      |myArr
[8]     |         0|      30|FUNC |GLOB |0    |2      |main

with static keyword:
Symbols from foo.o:

[Index]   Value      Size    Type  Bind  Other Shndx   Name

[1]     |         0|       0|FILE |LOCL |0    |ABS    |foo.cpp
[2]     |         0|       0|SECT |LOCL |0    |2      |
[3]     |         0|       0|SECT |LOCL |0    |4      |
[4]     |         0|       0|SECT |LOCL |0    |5      |
[5]     |         0|20971520|OBJT |LOCL |0    |5      |myArr
[6]     |         0|       0|SECT |LOCL |0    |1      |
[7]     |         0|       0|SECT |LOCL |0    |6      |
[8]     |         0|      30|FUNC |GLOB |0    |2      |main

The array was bound locally. Still doesn't solve the problem but its a work 
around for programs with a main line entry point.

NOTE: static is deprecated in a global context. Not that its going to go away 
or anything...
Comment 2 Steven Bosscher 2004-12-08 08:56:05 UTC 
Bugs for gcc 3.2.3 are not going to be fixed.  Are you seeing this 
problem with more recent versions of GCC as well?
Comment 3 Goh Boon Yeow 2004-12-14 10:03:27 UTC 
Have been trying to upgrade to a newer version of gcc (3.3.3 and above). But I 
am getting an error during compilation:

checking whether the C compiler ( /usr/byg/src/bld-gcc/gcc/xgcc -B/usr/byg/src/b
ld-gcc/gcc/ -B/usr/local/gcc-3.3.4/i386-pc-sco3.2v5.0.5/bin/ -B/usr/local/gcc-3.
3.4/i386-pc-sco3.2v5.0.5/lib/ -isystem /usr/local/gcc-3.3.4/i386-pc-sco3.2v5.0.5
/include -O2 -O2 ) works... no
configure: error: installation or configuration problem: C compiler cannot creat
e executables.
gmake: *** [configure-target-libiberty] Error 1

Any idea how to get past this?

Configured and built with:
$ configure --prefix=/usr/local/gcc-3.3.4 --enable-languages="c++"
$ gmake CFLAGS="-O2" LANGUAGES="c c++"
Comment 4 Andrew Pinski 2005-04-04 14:43:33 UTC 
No useful feedback in 3 months.