Re: gcc3.1 regression?

Re: gcc3.1 regression?

[Thaddeus L. Olczyk]

My apologies. I misunderstood "not compile correctly" to mean "not
compile".

Re: gcc3.1 regression?

[Jakub Jelinek]

On Thu, May 09, 2002 at 12:02:57PM -1000, Jimen Ching wrote:
> On Thu, 9 May 2002, Jakub Jelinek wrote:
> >On Wed, May 08, 2002 at 11:05:16PM -1000, Jimen Ching wrote:
> >> The code below seems to be incorrectly compiled by gcc3.1 cvs that I
> >> bootstraped on Debian2.2 (Linux kernel 2.2.17).
> >Can you please file a GNATS PR about this?
> 
> Ok, it is PR/6613.  I used my original sample source code, since I have no
> idea what your test case does.  Hope that is ok.  I wanted to add a link
> to this thread, but I didn't know how to do that.
> 
> >The problem is (again) RTX_UNCHANGING_P, looking forward to its final
> >death in 3.2
> 
> Does this mean that the 3.1 release will not have a fix?

Yes, very likely. It might be fixed for 3.1.1 though.

> Debian/GNU-Linux 2.2 still uses 2.95.2, and it works with that version.
> So I would assume this is a regression.  Though removing the copy
> constructor or using an integer member data is a work-around, neither are
> acceptable in the application I am developing.  I can remove the -O2, but
> the application is already slow.

For now, you can surely try either -O2 -fno-schedule-insns2 or remove some
of the const keywords.

	Jakub

Re: gcc3.1 regression?

[Jimen Ching]

On Thu, 9 May 2002, Jakub Jelinek wrote:
>On Wed, May 08, 2002 at 11:05:16PM -1000, Jimen Ching wrote:
>> The code below seems to be incorrectly compiled by gcc3.1 cvs that I
>> bootstraped on Debian2.2 (Linux kernel 2.2.17).
>Can you please file a GNATS PR about this?

Ok, it is PR/6613.  I used my original sample source code, since I have no
idea what your test case does.  Hope that is ok.  I wanted to add a link
to this thread, but I didn't know how to do that.

>The problem is (again) RTX_UNCHANGING_P, looking forward to its final
>death in 3.2

Does this mean that the 3.1 release will not have a fix?

Debian/GNU-Linux 2.2 still uses 2.95.2, and it works with that version.
So I would assume this is a regression.  Though removing the copy
constructor or using an integer member data is a work-around, neither are
acceptable in the application I am developing.  I can remove the -O2, but
the application is already slow.  It would be really disappointing if 3.1
can not correctly build my app with optimization enabled.

--jc
-- 
Jimen Ching (WH6BRR)      jching@flex.com     wh6brr@uhm.ampr.org

Re: gcc3.1 regression?

[Jakub Jelinek]

On Thu, May 09, 2002 at 02:03:02PM +0000, Thaddeus L. Olczyk wrote:
> I also have not been able to replicate the bug in Jakub's code with
> either the 4/19 or the 5/6 snapshots (specs below). 
> 
> I checked this because when first looking at the code, I thought it
> shouldn't compile ( in the declaration of T it looks as though A,B
> should be copied). So I tried it out on different compilers. Those
> that didn't choke for other reasons seemed to accept the code.

The thing is not acceptance of the code, but miscompilation of
static initialization/destruction.

> I notice that my build is a 686 build whereas  the build in question
> is a 586 build, could that be the reason ( sorry if it's obvious, I
> don't know the internals of gcc ).

But were you using -O2 and running the resulting binary?
I can reproduce it with all of -O2 -march={3,5,6}86.

	Jakub

Re: gcc3.1 regression?

[Thaddeus L. Olczyk]

I also have not been able to replicate the bug in Jakub's code with
either the 4/19 or the 5/6 snapshots (specs below). 

I checked this because when first looking at the code, I thought it
shouldn't compile ( in the declaration of T it looks as though A,B
should be copied). So I tried it out on different compilers. Those
that didn't choke for other reasons seemed to accept the code.

I notice that my build is a 686 build whereas  the build in question
is a 586 build, could that be the reason ( sorry if it's obvious, I
don't know the internals of gcc ).



------------------------------------------------------------------------------------------------------------------
Reading specs from
/usr/local/20429/lib/gcc-lib/i686-pc-linux-gnu/3.1/specs
Configured with: ../gcc-20020429/configure --prefix=/usr/local/20429
Thread model: single
gcc version 3.1 20020429 (prerelease)

Reading specs from
/usr/local/20020506/lib/gcc-lib/i686-pc-linux-gnu/3.1/specs
Configured with: ../gcc-20020506/configure
--prefix=/usr/local/20020506
Thread model: single
gcc version 3.1 20020506 (prerelease)

Re: gcc3.1 regression?

[Thaddeus L. Olczyk]

I have not been able to replicate with either the 4/19 or the 5/6
snapshots:

Reading specs from
/usr/local/20429/lib/gcc-lib/i686-pc-linux-gnu/3.1/specs
Configured with: ../gcc-20020429/configure --prefix=/usr/local/20429
Thread model: single
gcc version 3.1 20020429 (prerelease)

Reading specs from
/usr/local/20020506/lib/gcc-lib/i686-pc-linux-gnu/3.1/specs
Configured with: ../gcc-20020506/configure
--prefix=/usr/local/20020506
Thread model: single
gcc version 3.1 20020506 (prerelease)

Re: gcc3.1 regression?

[Jakub Jelinek]

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

gcc3.1 regression?

[Jimen Ching]

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.

Let me know if more information is needed.  I am willing to test a patch
if necessary.

Thanks.

--jc
-- 
Jimen Ching (WH6BRR)      jching@flex.com     wh6brr@uhm.ampr.org


--------------------------------
#include <iostream>

struct logic
	{
	enum state_value { LO, HI, DC, Z, NVL };

	logic(state_value l = NVL)
		: state(l) { }
#ifndef REMOVE_CTOR
	logic(const logic &l)
		: state(l.state) { }
#endif

#ifdef USE_INT
	int state;
#else
	char state;
#endif
	};

const logic  LO(logic::LO);
const logic  HI(logic::HI);

void func(void);

int
main()
	{
	func();
	return 0;
	}

struct addtab
	{
	logic sum;
	logic carry;
	};
const struct addtab ADDTABLE[] =
	{
	{LO,LO},
	{HI,LO},
	{HI,LO},
	{LO,HI},
	{HI,LO},
	{LO,HI},
	{LO,HI},
	{HI,HI}
	};

void
func(void)
	{
	for (int tmp = 0; tmp < 8; ++tmp)
		{
		std::cout << (int)ADDTABLE[tmp].sum.state
				  << ","
				  << (int)ADDTABLE[tmp].carry.state
				  << std::endl;
		}
	}