Perhaps. But I think it unlikely that the only effect of a broken compiler would be too slow down all the programs you compile with it. I would think it would compile some programs, fail on some, and/or produce programs that don't work. I guess want I'm trying to say is that if rearrange instructions in an unexpected way, chances are that the program will simply fail, rather than being slower. Of course this is all conjecture on my part.
I guess I would expect the aforementioned results if there were an optimizing stage that broken compiler failed on (but the compile succeeded). But as a compiler writer, I would at least output that the optimizing stage failed. Sorry if I am rambling on, but I find the topic interesting. I don't have professional experience writing compilers, but I took a course in college. -Nathan -----Original Message----- From: Eamon Caddigan Van Eps, Nathan D. (James Tower) <[EMAIL PROTECTED]> wrote: >>From: Eamon Caddigan >> >>>Van Eps, Nathan D. (James Tower) <[EMAIL PROTECTED]> wrote: >>> That is weird. A compiler should generate the same code whether it is >>> optimized or unoptimized. It would be interesting to hear an explanation >>> from the gcc folk as to what causes this. >> >>Plenty of programs break when compiled with aggressive optimizations -- >>why should a compiler be any different? > > If the compiler broke (because of aggressive optimizations), the compiler > wouldn't make an executable. And if you compiled the compiler with good > optimizations, the compiler would simply run faster (not the executable it > generates). Its like deterministic. > > You expect your programs to run the same regardless of compiler > optimization. You just want them to run faster... That's a fair expectation, but not quite how it works. When optimizing code, compilers rearrange instructions (among other things) to achieve faster (or smaller, etc.) code. It's not too difficult to imagine an incorrectly-optimized compiler creating executables that themselves fail, rather then simply refusing to compile any code. Especially when you consider how subtle the problems introduced by incorrect "optimizations" can be. -- [EMAIL PROTECTED] mailing list
