fbounds checking not working, any replacement?

I was trying to get the fbounds checking to work, but I did not succeed. I get a following error:

/tmp/cczxKZzn.s: Assembler messages:

/tmp/cczxKZzn.s:48: Error: invalid instruction suffix for `push'

/tmp/cc9xD8T3.s:125: Error: invalid instruction suffix for `pop'

while my makefile looks like this (with simple makefile everything is compiling properly):

all: error check

error: error.c
    /usr/local/gcc-4.0.2/bin/gcc -fbounds-checking -g -Wall -pedantic $< -o $@

.PHONY: clean check

clean:
    -rm error

check:  error
    ./error

Since that code has nothing to do with assembler, I don't know what to do. Assembler problems are the only ones I can see in my google search on that topic.

Can You propose other solutions checking for example for being outside an array? Such as (this is my error.c):

#include <stdio.h>
#include <stdlib.h>
int main()
{
  int a[1][10];
  a[0][11]=42;
  return 0;
}

EDIT. Can it be a version incompatibility; gcc 4.4+ is installed and I'm doing that with path to a little modified gcc 4.0.2 ?

Solution

Since that code has nothing to do with assembler, I don't know what to do. Assembler problems are the only ones I can see in my google search on that topic.

Looks like you're invoking the wrong assembler - a 32 bit one, trying to compile a 64bit object code. Check your PATHs and flags.

UPDATE: I never looked into how exactly gcc invokes its components. It's still not very clear to me. Anyway, it looks like it doesn't rely on PATH as I believed, but rather on its ./configure settings (--prefix, --build and so on).

Mine, with --prefix=/usr, --build=x86_64-suse-linux, --program-suffix=-4.6, looks for its components in (with respect to the directory where thegcc` binary resides: - ../lib64/gcc/x86_64-suse-linux/4.6 - ../lib64/gcc/ - ../lib64/gcc/x86_64-suse-linux/4.6/../../../../x86_64-suse-linux/bin/x86_64-suse-linux/4.6/ - ../lib64/gcc/x86_64-suse-linux/4.6/../../../../x86_64-suse-linux/bin/

(checked with strace).

Were a binary from another gcc present in one of those directories, it would get invoked instead of the 'correct' one.

Try checking with gcc -v (or with strace) to see which as is being run.