Messages in this thread | | | Date | Wed, 22 Sep 1999 14:08:29 +0200 | From | Artur Skawina <> | Subject | Re: Possible GCC contamination of Linux |
| |
> > > a patch which adds -fno-builtins to the Makefile and makes the abs() work.
> So you can compile a i386 or i486 kernel with a 'C' compiler that was > built on a i686 machine. It took me a week to find the reason why > a kernel, configured to run on a 486 (or even 386) would crash on > the boot of a 486.
> The only built-in I found used was abs(). It was the '486 killer.
the builtin abs() was a known issue, but I assumed it was harmless. Are you saying gcc generates 686 instructions (cmov i guess) even when configured for a 486? I'd like to reproduce this -- which gcc version, cflags, file? Does '-march=i486' (or ..=i386) solve this? Do you have the offending abs dissassembly? Have you compared the code generated for the builtin vs proper define (ie one which can take args w/ side effects (the one i saw posted didn't)).
[it sounds like a gcc bug affecting more than just the kernel, hence i'd like to identify it before working it around... I never looked at gcc2.95 generated code for pre686 so it's possible i never saw this, but i did look at the 686 code and chose not to "fix" abs(); right now i don't remember exactly why, but it must have been either (1) builtin_abs() generated better code or (2) there was no difference]
> The memcpy and other routines are in the architecture-specific directories > in cases where processors offer certain advantages.
gcc should pick the best sequence for the builtin ones depending on the target cpu. unfortunately currently this only seems to work for certain cases (and even then not always). for the 686 cases i looked at the builtins were better than the asm inlines.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |