This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Compiler bug - vector register constant not reloaded
- From: "Richard Falk" <Richard dot Falk at efi dot com>
- To: <gcc-bugs at gcc dot gnu dot org>
- Date: Wed, 16 Jun 2004 17:08:13 -0700
- 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