Messages in this thread |  | | Date | Sun, 22 Oct 2000 23:38:13 -0400 | From | Michael Meissner <> | Subject | Re: Kernel 2.2.17 with RedHat 7 Problem ! |
| |
On Sun, Oct 22, 2000 at 11:16:36PM -0400, David Relson wrote: > At 09:14 PM 10/22/00, Horst von Brand wrote: > >Jurgen Kramer <GTM.Kramer@inter.nl.net> said: > > > > > You can blame it on the compiler which is included with RH7.0. It's a > > > pre-release version of some sort. It seems that the gcc people are not > > > happy that RH included this version with RH7. > > > >It is the *kernel's* fault, as far as can be ascertained now. The compiler > >is stricter, and implements new optimizations, for which the kernel (being > >only ever compiled with gcc) is just unprepared. > > The problem, as I understand it, is that gcc-2.96 handles language > constructs slightly different than older compilers. This is a preprocessor > change, not an optimization problem. > > To say "new optimizations ... kernel ... unprepared" is incorrect. Having > worked with compilers (some years ago), I always took it as an article of > faith that the same answer(s) would be generated whether optimization was > turned on or not. Optimization should always be a way to do a task either > quicker (fewer instructions executing, less executing time, etc) or shorter > (less memory needed for the instructions). Optimization should never, > never give a different result. Having new optimizations break an executing > program is simply wrong.
Ummm, that should read "Having new optimizations break a correct exeucting program...". For example, the following program:
#include <stdio.h>
int main(){ int i; printf ("i = %d\n", i); return 0; }
will necessarily print different values for i, depending on the optimization level, what was on the stack and in the registers when main started, and possibly other criteria. Just because a program is executing, it doesn't mean it is correct.
Both the kernel and the compiler are large complex pieces of software, and almost certainly have bugs in them, and over the years, I have certainly found some of these bugs as I use new versions of each.
-- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: meissner@redhat.com phone: +1 978-486-9304 Non-work: meissner@spectacle-pond.org fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |