| |||||||||||||
Checking same object files producedChecking same object files producedPosted Jul 26, 2012 11:39 UTC (Thu) by NRArnot (subscriber, #3033)In reply to: Checking same object files produced by epa Parent article: The UAPI header file split
That's assuming the compiler is perfectly well-behaved. It might be that the different ordering of #define statements changes the internal state of the compiler, leading to a change in the ordering of entities which are present in the generated code. The binary code would then be functionally identical but not byte-for-byte identical.
(Log in to post comments)
Checking same object files produced Posted Jul 26, 2012 12:28 UTC (Thu) by ms (subscriber, #41272) [Link]
Take the generated assembly before and after and prove it's equivalent? Yes, I'll fetch my coat...
Checking same object files produced Posted Jul 27, 2012 11:17 UTC (Fri) by nix (subscriber, #2304) [Link]
Given that the only #defines this code should be altering are those related to multiple-inclusion guards, I think we could describe any such ordering changes as a compiler bug. That is not to say that no such bugs exist, but it is likely that they'd also lead to inconsistent code generation when faced with identical output, and cause failures in GCC bootstrap comparison. (This has happened before, e.g. with optimizations depending on the ordering of pieces of compiler state in hash tables -- the infamous 'hashing by
address' bug class -- and that sort of thing.)
|
|||||||||||||