Bug 50705 – PPC compiler gcc-3.3.3_pre20040408-r1 not initalising variables under -On?

• Product: Gentoo Linux
• Status: VERIFIED WONTFIX

[Description Cameron Blackwood 2004-05-10 22:13:37 UTC]

bug
===
This is the compiler based on the ppc32 for G5 stage3 given below.

This seems to me to be a _compiler_ problem, not a diffutils or ebuild problem.

It _may_ just be G5 related (but ive linked to another bug below which may be related) or it may be related to the gcc version. Ill be conservative and log it as a ppc64 problem for now.

diff's default output is "-C 4" not "--normal"
sdiff hangs forever writing tabs to stdout

The problem is variables arnt being initialised correctly.

steps to reproduce
==================
Run the following script:

--------- vv below vv -----------
echo "creating test files"
(echo "1"; echo "2"; echo "3"; echo "4" ) > /tmp/foo.n
(echo "1"; echo "2"; echo "extra"; echo "3"; echo "4" ) > /tmp/foo.y

echo "compile flags: full"
CFLAGS="-O2 -mcpu=G5 -maltivec -mabi=altivec -fno-strict-aliasing -pipe" emerge diffutils > /dev/null
diff /tmp/foo.?

echo "compile flags: no altivec"
CFLAGS="-O2 -mcpu=G5 -fno-strict-aliasing -pipe" emerge diffutils > /dev/null
diff /tmp/foo.?

echo "compile flags: no -On"
CFLAGS="-mcpu=G5 -maltivec -mabi=altivec -fno-strict-aliasing -pipe" emerge diffutils > /dev/null
diff /tmp/foo.?
--------- ^^ above ^^ -----------

results for me:

---------- vv below vv -----------
creating test files
compile flags: full
*** /tmp/foo.n  Tue May 11 14:38:52 2004
--- /tmp/foo.y  Tue May 11 14:38:52 2004
***************
*** 1,4 ****
--- 1,5 ----
  1
  2
+ extra
  3
  4
compile flags: no altivec
*** /tmp/foo.n  Tue May 11 14:38:52 2004
--- /tmp/foo.y  Tue May 11 14:38:52 2004
***************
*** 1,4 ****
--- 1,5 ----
  1
  2
+ extra
  3
  4
compile flags: no -On
2a3
> extra
---------- ^^ above ^^ -----------

I expected the last output each time, personally.

system
======
A G5 apple running ppc32 base system with a ppc64 kernel.
I get the same behaviour when I test with a ppc32 kernel.

Infact, if I extract stage3-g5-20040420.tar.bz2 and chroot into there and run the script, I get the same thing.

reproducable
============
Yes. Should be reproducable directly from the stage3 above.

Compiler problem?
=================
If you do the following:

mkdir /tmp/t
cd /tmp/t
tar xpfz /usr/portage/distfiles/diffutils-2.8.4.tar.gz
cd diffutils-2.8.4
sh ./configure --prefix=/tmp/t
make
src/diff /tmp/foo.?

you get the same result.

If you edit  src/diff.c line 279 and add the line:

  show_c_function = 0;

and rebuild it works as expected, which is odd given that the variable is declared with:

  bool show_c_function = 0;

on line 259.

notes
=====
This might be related to:

http://bugs.gentoo.org/show_bug.cgi?id=36127

but im not sure (changing altivec makes no difference for me).

[Comment 1 Cameron Blackwood 2004-05-10 22:46:06 UTC]

[confirmed in ppc32 kernel off the 2004.1 cd. I thought I noted that but I cant see it here].

More disturbingly is adding the line:

    printf("show_c is %d\n",(int) show_c_function);

on line 609 of diff.c also fixes the problem.

yes, reading the variable also fixes the problem. (it isnt printf adding to the heap/stack because printing other variables doesnt fix the problem).

This has to be a compiler problem.. yeah?

[Comment 2 Tom Gall (RETIRED) 2004-06-03 20:55:00 UTC]

Alanm won't be back for a few days so I can't run this past him. (He's the gcc maintainer for ppc) ... have you tried 3.4 by chance?  

[Comment 3 Tom Gall (RETIRED) 2004-06-07 12:28:38 UTC]

this appears to affect ppc32 as well with a stage3 3.3.3_pre20040408

thanks to kc8apf!

[Comment 4 Luca Barbato 2004-06-08 07:50:15 UTC]

try -fno-strict-aliasing please

[Comment 5 Cameron Blackwood 2004-06-08 18:13:44 UTC]

Additional Comment #4 From Luca Barbato  2004-06-08 07:50 PST -------

try -fno-strict-aliasing please


If you look at the script I included in my report, I used that option in every attempt. :)

[Comment 6 Luca Barbato 2004-06-10 07:47:55 UTC]

gcc-3.4 does not show the issue.

[Comment 7 Luca Barbato 2004-06-11 09:33:22 UTC]

please try the new snapshot available on my overlay:

http://dev.gentoo.org/~lu_zero/overlay/gcc.tar.bz2

[Comment 8 Tom Gall (RETIRED) 2004-06-12 13:46:26 UTC]

for ppc64, gcc 3.4 does not have this problem.  

[Comment 9 Tom Gall (RETIRED) 2004-06-12 13:53:15 UTC]

I've pinged Alan about this, hopefully we're hear some status.

[Comment 10 Cameron Blackwood 2004-06-21 00:13:08 UTC]

Luca Barbato asked:

   please try the new snapshot available on my overlay:

   http://dev.gentoo.org/~lu_zero/overlay/gcc.tar.bz2

but this is a longer reply than i expected, so please hang in there... :)

---------

Sadly, some portage update has _HIDDEN_ this problem. Im not sure whats changed, but something has 'fixed' this. 

I did the following:

extracted:   stage3-g5-20040420.tar.bz2
chrooted into it.

tested diff (broken)

cd /usr/portage/sys-apps/diffutils/
emerge  diffutils-2.8.4-r3.ebuild

which shouldnt have done anything...
[ebuild   R   ] sys-apps/diffutils-2.8.4-r3  -build -debug +nls -static  0 kB

but when I ran the test again, the problem was gone.

So then I ran my initial 'repeat' script of:

mkdir /tmp/t
cd /tmp/t
tar xpfz /usr/portage/distfiles/diffutils-2.8.4.tar.gz
cd diffutils-2.8.4
sh ./configure --prefix=/tmp/t
make
src/diff /tmp/foo.?

and I still get the problem... but somehow the ebuild fixes it? Weird!!!

Anyway, I rebuilt gcc with that overlay and then ran that series of instructions (to not use the ebuild, but manually build the tarball) above and I still get the problem.

If you edit  src/diff.c line 279 and add the line:

  show_c_function = 0;

as I said in my inital report, the problem goes away again.

So, in summary:
  * the problem is still there with that overlay, 
  * something in a portage update since the report has 'HIDDEN' the problem, but it is still there and probably effecting other programs

[Comment 11 Tom Gall (RETIRED) 2004-08-23 06:15:54 UTC]

well I'm planning on doing much more wit hthis one so I'm just going to close it as 3.4.x has become the standard compiler now for some time now and it doesn't have this problem. The 3.3-x compiler while used as an early bring up vehicle is essentially depricated.

[Comment 12 Tom Gall (RETIRED) 2004-08-23 06:16:47 UTC]

stick a fork in it