Yagarto (GCC, Win32) compiles same code differentl

2019-04-11 00:22发布

I am using a Yagarto toolchain on Windows to compile a codebase of about 100K lines of code.

We have two development PCs. However, they each build slightly different binaries despite having the same toolchain and building the same source code.

I have checked using MD5 that we have the same compiler binaries, the same system headers, and we are compiling the same source, with the same commandline being passed to GCC, yet there are subtle differences.

Out of the 81 object files in our codebase, 77 compile exactly the same; and four have minor differences. There is no functional difference, but since we are going to be supporting the compiled binaries, I would like to get to the bottom of this issue.

The "arm-elf-gcc.exe" is dated Jul 16 2006. The output of "arm-elf-gcc -v" is:

Using built-in specs.
Target: arm-elf
Configured with: ../gcc-4.1.1/configure --target=arm-elf --prefix=/home/yagarto/yagarto --disable-nls --disable-shared --disable-threads --with-gcc --with-gnu-ld --with-gnu-as --with-stabs --enable-languages=c,c++ --enable-interwork --enable-multilib --with-newlib --disable-libssp --disable-libstdcxx-pch --disable-libmudflap --enable-win32-registry=yagarto -v
Thread model: single
gcc version 4.1.1

Here is an example from the list files of the different generated code:

.LCB1356:
mov r7, #0
mov r5, #2
str r7, [sp, #16]
str r7, [sp, #20]
str r7, [sp, #24]
str r7, [sp, #28]
str r7, [sp, #40]
.L231:

.LCB1356:
mov r7, #0
mov r5, #2
str r7, [sp, #16]
str r7, [sp, #20]
str r7, [sp, #40]
str r7, [sp, #24]
str r7, [sp, #28]
.L231:

In the two cases, just the order of variables in the stack frame is different; all the code is the same except the variables were in a different order. ("diff" on the list files just shows up various other lines corresponding to #40 being swapped with #28 and so on).

This change is obviously harmless (although I would like to know why), but in two of the other object files, the size of the text segment is actually 4 bytes larger in one version, and as well as variables being in different order on the stack frame, there are a couple of instructions that differ.

One PC is a Intel Core 2 Duo running Windows 2000, and the other is a AMD X4 running Windows 7. Each PC reliably reproduces the same build, but one PC's build differs to the others.

Is it possible that GCC will optimize differently depending on what CPU is actually being used for the build? (not the target CPU). Or what else might cause this discrepancy?

0条回答
登录 后发表回答