g++ -fconserve-space makes no effect

[Takenaka Kazuhiro <takenaka at intellilink dot co dot jp>]

Hello every one.

Can you help me with the following problem. I tried to compile
C++ program on Fedra core 1 by g++ 3.3.2 and then compilation
was aborted.

(The program is first developped on Solaris 8 by Sun compiler.)

Source files are like following.

<<< main.C
#include <stdio.h>

int var;

int main(void)
{
    var = 0;
    printf("var = %d\n", var);
    return 0;
}
>>> end

<<< var.C
int var;
>>> end

Commands to compile are following.

<<< commands
1. g++ -o main.o -c main.C
2. g++ -o var.o  -c var.C
3. g++ -o testprg main.o var.o
>>> end

Command 3. aborted. messages were following.

<<< messages
var.o(.bss+0x0): multiple definition of `var'
main.o(.bss+0x0): first defined here
collect2: ld returned 1 exit status
>>> end

I looked up option `-fconserve-space' in manual(Node: C++ Dialect Options),
so I added Command 1-2 the option. But I got same result.

I searched effects of '-fconserve-space' in gcc source files and
found following.

<<< gcc/cp/decl.c:7825
#if ! defined (ASM_OUTPUT_BSS) && ! defined (ASM_OUTPUT_ALIGNED_BSS)
  /* Tell the back-end to use or not use .common as appropriate.  If we say
     -fconserve-space, we want this to save .data space, at the expense of
     wrong semantics.  If we say -fno-conserve-space, we want this to
     produce errors about redefs; to do this we force variables into the
     data segment.  */
  DECL_COMMON (tem) = ((TREE_CODE (tem) != VAR_DECL
                        || !DECL_THREAD_LOCAL (tem))
                       && (flag_conserve_space || ! TREE_PUBLIC (tem)));
#endif
>>> end

I found no definition of ASM_OUTPUT_BSS for i386/linux
but found ASM_OUTPUT_ALIGNED_BSS in gcc/config/i386/linux.h at 153.

So I commented out the definition and build gcc,
then the option makes specified effects.

Now, new gcc can compile and link the program.

I hava some questions:
    1. The behavior of compiler is inconsistent with the manual description.
       Which is wrong ?.

    2. What kind of side effect will be expected with the modification ?

    3. Is there any better solution for the problem ?

--
Takenaka Kazuhiro<takenakak@intellilink.co.jp>