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).
[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?
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?
this appears to affect ppc32 as well with a stage3 3.3.3_pre20040408 thanks to kc8apf!
try -fno-strict-aliasing please
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. :)
gcc-3.4 does not show the issue.
please try the new snapshot available on my overlay: http://dev.gentoo.org/~lu_zero/overlay/gcc.tar.bz2
for ppc64, gcc 3.4 does not have this problem.
I've pinged Alan about this, hopefully we're hear some status.
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
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.
stick a fork in it