I'm trying to build a CLFS for a PPC 8270 processor. All is fine until I use the make ARCH=powerpc CROSS_COMPILE=${CLFS_TARGET}- command.

CC      arch/powerpc/kernel/align.o
arch/powerpc/kernel/align.c: In function 'fix_alignment':
arch/powerpc/kernel/align.c:704:33: error: variable 'instruction' set but not used [-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors

make[1]: *** [arch/powerpc/kernel/align.o] Error 1
make: *** [arch/powerpc/kernel] Error 2

In menuconfig, I used the default configuration except I choose compatibily with PPC 82XX processor family.

  • Do you have -Werror in your CFLAGS? (If so, you probably shouldn't except for compiling your own code.)
    – Mat
    Commented Apr 3, 2012 at 11:17
  • We need to know which kernel version you are compiling. You should see "instruction" used in the block if (cpu_has_feature(CPU_FTR_NODSISRALIGN)) { after line 704 Commented Apr 3, 2012 at 12:38

2 Answers 2


This appears to me to be a bug in align.c 2.6.39 and previous with respect to GCC >= 4.6. I am guessing that you are building on a recent Fedora that has GCC 4.6 as the default installed GCC. The bug should not appear using GCC < 4.6 IMHO.

The variable "instruction" is declared on line 704 and initialized to zero. It is then re-assigned on line 746. This re-assignment is not enough to squelch the gcc warning. I verified this behavior by compiling

int main()
    int i = 0;

    i = 4;
    return 1;

with /usr/local/gcc-4.7.0/bin/gcc -Wall -o test test.c and got

test.c:3:6: warning: variable ‘i’ set but not used [-Wunused-but-set-variable]

The variable "instruction" is referenced only in code that is ifdef'ed CONFIG_VSX, so that if you don't have CONFIG_VSX set then you will see this problem when compiling with GCC >= 4.6. Setting CONFIG_VSX should solve the problem. If that is not what you want then try setting CONFIG_PPC_DISABLE_WERROR in menuconfig or use these instructions to help you turn off the -Werror or patch the code.

If you do patch the code, consider submitting it to kernel.org as I see that this bug still exists in 3.3


Resolved copying libbfd.2-22.so and zlib.so (renamed to zlib.so.1) to /tools/lib. Sorry for the stupid error, I thought that files were there already.

You must log in to answer this question.