[Bug target/15486] New: -fdata-sections moves COMMON vars to .bss

["jifl-bugzilla at jifvik dot org" <gcc-bugzilla at gcc dot gnu dot org>]

This is a regression from GCC 3.2.1 (at least).

If I create a file foo.c containing simply:
  int x;
and compile it with:
  arm-elf-gcc -c foo.c
then I can get the following with 'arm-elf-nm foo.o'
00000004 C x

However if I compile with
  arm-elf-gcc -c -fdata-sections foo.c
then with arm-elf-nm I get:
00000000 B x

i.e. x is in the BSS. This results in breaking the long-standing behaviour of
common variables being merged. If you typed the following:
cat >foo2.c
int x=0;
int main(){
  return x;
}
arm-elf-gcc -c -fdata-sections foo.c
arm-elf-gcc -c -fdata-sections foo2.c
arm-elf-gcc -o foo foo.o foo2.o
then you get:
foo2.o(.data.x+0x0): multiple definition of `x'
foo.o(.bss.x+0x0): first defined here

I can see how this behaviour would be beneficial if "-fno-common" was passed to
gcc and if not using "legacy" code (actually the real code I'm having trouble
with is derived from a BSD kernel of about 4 years ago, so not that old), but in
the absence of -fno-common, -fdata-sections should not operate on uninitialised
data. Perhaps the default should be -fno-common, and I should be required to
pass -fcommon to get the old behaviour, I'm not bothered. Or alternatively
perhaps this treatment of uninitialised data should only happen with a separate
-fbss-sections option (for symmetry with -ffunction-sections and -fdata-sections).

-- 
           Summary: -fdata-sections moves COMMON vars to .bss
           Product: gcc
           Version: 3.3.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jifl-bugzilla at jifvik dot org
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linuxgnulibc2.2
  GCC host triplet: i686-pc-linuxgnulibc2.2
GCC target triplet: arm-elf


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