RE: Compiler bug - vector register constant not reloaded

["Richard Falk" <Richard dot Falk at efi dot com>]

P.S.

To eliminate the possibility that there might be a memory overwrite occurring
elsewhere in the system into some constant data area, I put in the following
code in different places and found that the "veight" constant vector only
becomes incorrect deeper into the function that contains the faulty assembly
code.  In other words, the problem isn't some memory overwrite from outside
the offending function.  I also removed the buffer writing from within the
function and the "veight" still becomes incorrect at the same point in the
function.  So this definitely seems to be a variable scoping / register reuse
problem in the compiler.

vec_st(veight, 0, (unsigned char *)&u.uchars[0]);
if ((u.uchars[0] != 8) || (u.uchars[1] != 8) || (u.uchars[2] != 8) ||
(u.uchars[3] != 8) || (u.uchars[4] != 8) ||
    (u.uchars[5] != 8) || (u.uchars[6] != 8) || (u.uchars[7] != 8) ||
(u.uchars[8] != 8) || (u.uchars[9] != 8) || 
    (u.uchars[10] != 8) || (u.uchars[11] != 8) || (u.uchars[12] != 8) ||
(u.uchars[13] != 8) || 
    (u.uchars[14] != 8) || (u.uchars[15] != 8)) 
{
errorflag = 1;
}

> ----------
> From: 	Richard Falk
> Sent: 	Wednesday, June 16, 2004 5:08 PM
> To: 	'gcc-bugs@gcc.gnu.org'
> Subject: 	Compiler bug - vector register constant not reloaded
> 
> I have a particularly nasty bug where I can see the incorrect assembly code
> that isn't reloading an Altivec (PowerPC) vector register for a vector
> constant before its use.  Unfortunately, doing almost anything to the
> source file, like adding a printf statement, causes the compiler to produce
> different assembly code that will now work correctly.  The source file is
> very large and contains proprietary code (I work for Electronics for
> Imaging).
> 
> This problem occurs with the following two versions of gcc I am using:
> 
> Reading specs from
> ../../mygcc/bin/../lib/gcc-lib/powerpc-apple-darwin6.8/3.3.2/specs
> Configured with: ../gcc-3.3.2/configure --prefix=/Users/richfalk/mygcc
> --enable-threads=posix --enable-altivec
> Thread model: posix
> gcc version 3.3.2
> 
> Reading specs from
> /vobs/buildtools/powerpc-eabi/lib/gcc-lib/powerpc-eabi/2.95.2/specs
> gcc version 2.95.2 19991024 (moto-1.7 release)
> 
> The problem does not occur with Apple's gcc version of:
> 
> Reading specs from /usr/libexec/gcc/darwin/ppc/3.1/specs
> Thread model: posix
> Apple Computer, Inc. GCC version 1175, based on gcc version 3.1 20020420
> (prerelease)
> 
> though that might just be luck.
> 
> The problem occurs with optimization set to -O3 and -O2 while -O1 (or -O)
> causes a Segmentation fault and -O produces correct output.  There are
> other options selected as well.
> 
> If I change the following line defining the constant vector (the one not
> getting loaded properly) from
> 
> const vector unsigned char veight = (vector unsigned
> char){8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8};
> 
> to
> 
> static const vector unsigned char veight = (vector unsigned
> char){8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8};
> 
> then the problem goes away and for now this is my workaround.
> 
> How can I get you what you need to debug this problem without publically
> disclosing the source code (or preprocessed code)?
> 
> Thanks,
> Richard Falk 
> Electronics for Imaging
> 
>