Re: gcc3.1 regression?

[Jakub Jelinek <jakub at redhat dot com>]

On Wed, May 08, 2002 at 11:05:16PM -1000, Jimen Ching wrote:
> Hi all,
> 
> The code below seems to be incorrectly compiled by gcc3.1 cvs that I
> bootstraped on Debian2.2 (Linux kernel 2.2.17).
> 
> g++ -v
> Reading specs from
> oss/src/fsf/bin/../lib/gcc-lib/i586-pc-linux-gnu/3.1/specs
> Configured with: ../gcc/configure --prefix=/home/jching/oss/src/fsf
> Thread model: single
> gcc version 3.1 20020502 (prerelease)
> 
> Note, if you define either REMOVE_CTOR or USE_INT, the problem goes away.
> The command line I used is:
> 
> g++ -O2 file.cc
> 
> If I compile without -O2 and without either of the above macros, then it
> is fine.  So the problem is with a combination of the char member data,
> with copy constructor and level 2 optimization.

Verified on gcc version 3.1 20020509, 3.0.4 and 3.0.2 20011002, works just
fine with gcc-2.96-RH and egcs 1.1.2.
Can you please file a GNATS PR about this?
The problem is (again) RTX_UNCHANGING_P, looking forward to its final death
in 3.2:

(insn 76 410 78 (clobber (mem/s/u:BLK (plus:SI (reg/f:SI 20 frame)
                (const_int -16 [0xfffffff0])) [0 A128])) -1 (nil)
    (nil))
(insn 88 81 89 (set (reg:QI 69)
        (mem/s/j:QI (symbol_ref:SI ("S0")) [0 <variable>.state+0 S1 A8])) 60 {*movqi_1} (nil)
    (nil))
(insn 89 88 90 (set (mem/s/j:QI (plus:SI (reg/f:SI 20 frame)
                (const_int -16 [0xfffffff0])) [0 <variable>.state+0 S1 A8])
        (reg:QI 69)) 60 {*movqi_1} (insn_list 88 (nil))
    (nil))
(insn 109 106 110 (set (reg:HI 73)
        (mem/s/u:HI (plus:SI (reg/f:SI 20 frame)
                (const_int -16 [0xfffffff0])) [0 S2 A128])) 51 {*movhi_1} (nil)
    (nil))

and scheduling swaps 89 with 109 (among other things) as the read is
supposed to be unchanging.
Couldn't we at least check for MEM/u frame + offset if they don't fall
into the same stack slot if considering taking advantage of RTX_UNCHANGING_P
and if they are equal, avoid swapping them?
I know it won't catch all the cases, but at least on IA-32 it would kill
lots of (potential) failures.

This is the testcase I've been working on (so that it doesn't need any
headers and actually tests that it was initialized correctly):

struct L
{
  enum S { A, B, C };
  L (S x = C) : l (x) {}
  L (const L &x) : l (x.l) {}
  char l;
};

const L A (L::A);
const L B (L::B);

struct T
{
  L u, v;
};

const struct T x [] =
{
  {A, A}, {B, A}, {B, A}, {A, B}, {B, A}, {A, B}, {A, B}, {B, B}
};

extern "C" void abort (void);
extern "C" void exit (int);

int
main()
{
  for (int i = 0; i < 8; i++)
    {
      if (x[i].u.l * 2 != ((((i & 3) ^ (i >> 2)) + 1) & 2))
        abort ();
      if (x[i].v.l != ((((i + 1) ^ 1) - 1) >= 4))
        abort ();
    }
  exit (0);
}

	Jakub