g++ optimizes better with -fno-elide-constructors switch than without

["Loren J. Rittle" <rittle at supra dot rsch dot comm dot mot dot com>]

For a small test case, g++ (egcs-2.93.16 for sparc-sun-solaris2.6)
optimizes better with the -fno-elide-constructors switch than without
it.  This seems wrong after reading the info page.  Perhaps more
important, supplying the switch causes additional fatal errors to be
reported.

Consider the following code:

; cat o.C
class inner
{
  int t;
  int s;
public:
  inner (int _t, int _s) : t (_t), s (_s) {}
  // inner (const inner& n) : t (n.t), s (n.s) {}  // trivial copy constructor
};

class outer
{
  inner t;
  int s;
public:
  outer (const inner& _t, int _s) : t (_t), s (_s) {}
};

void
f (void)
{
  outer a (inner (1, 2), 3);
}

When compiled to produce the assembly language for f() as follows:

; rm o.s; g++ -S -O2 -fno-exceptions o.C; sed -n /f__Fv:/,/.LLfe1:/p o.s
f__Fv:
        !#PROLOGUE# 0
        add     %sp, -240, %sp
        !#PROLOGUE# 1
        mov     1, %g2
        mov     2, %g3
        std     %g2, [%sp+96]
        mov     %g2, %o0
        ld      [%sp+100], %g2
        mov     3, %g3
        st      %o0, [%sp+160]
        st      %g2, [%sp+164]
        st      %g3, [%sp+168]
        retl
        sub     %sp, -240, %sp
.LLfe1:

; rm o.s;g++ -S -O2 -fno-exceptions -fno-elide-constructors o.C; \
  sed -n /f__Fv:/,/.LLfe1:/p o.s
o.C: In method `inner::inner(const inner &)':
o.C:15: invalid use of void expression
f__Fv:
        !#PROLOGUE# 0
        add     %sp, -240, %sp
        !#PROLOGUE# 1
        mov     1, %g2
        mov     2, %g3
        mov     3, %o0
        std     %g2, [%sp+96]
        st      %o0, [%sp+168]
        retl
        sub     %sp, -240, %sp
.LLfe1:

Note: g++ printed new errors with this switch and returned 1 to the
shell but produced a legal looking assembly file which, according to
the info page, happens to be optimized the way it should be without
the switch!  Adding the `obvious' trivial copy constructor to inner
makes the second case compile without errors, but the assembly code
produced is exactly as in the first case.

Regards,
Loren