Different assembly code generated when no change in code or compiler options

csakthikumar · 06-25-2018, 06:24 AM

Hi,
I am facing a weird issue, I used MIPS cross compiler to build MIPS based libs and lib building was fine. The very next day I build MIPS based libs again without changing code/compiler/compiler options(No change in compilation environment or code) but the newly generated libs are different from the previous one. To debug the issue further I took objdump of old and new libs I can see only 1 difference and that is as below

Objdump snippet from Old Lib:

Code:

    a8e0:	8fc20124 	lw	v0,292(s8)
    a8e4:	8fc3012c 	lw	v1,300(s8)
    a8e8:	8c420000 	lw	v0,0(v0)
    a8ec:	afc20110 	sw	v0,272(s8)
    a8f0:	8c630018 	lw	v1,24(v1)
    a8f4:	8fc2012c 	lw	v0,300(s8)
    a8f8:	afc30114 	sw	v1,276(s8)
    a8fc:	8fc30110 	lw	v1,272(s8)

Objdump snippet from New Lib:

Code:

    a8e0:	8fc20124 	lw	v0,292(s8)
    a8e4:	8fc3012c 	lw	v1,300(s8)
    a8e8:	8c420000 	lw	v0,0(v0)
    a8ec:	afc20110 	sw	v0,272(s8)
    a8f0:	0060102d 	move	v0,v1
    a8f4:	8c630018 	lw	v1,24(v1)
    a8f8:	afc30114 	sw	v1,276(s8)
    a8fc:	8fc30110 	lw	v1,272(s8)

Can you please help me understand what is the root cause for the same.

NevemTeve · 06-25-2018, 07:49 AM

Well, is it stated in the documentation that the compiler is deterministic, i.e. it always generates the same output from the same input?

csakthikumar · 06-25-2018, 11:36 AM

Quote:

Originally Posted by NevemTeve

Well, is it stated in the documentation that the compiler is deterministic, i.e. it always generates the same output from the same input?

No but was just wondering what can cause a compiler to spit different outputs even though source code and build environment is same

dogpatch · 06-26-2018, 12:12 PM

Quote:

Originally Posted by NevemTeve

Well, is it stated in the documentation that the compiler is deterministic, i.e. it always generates the same output from the same input?

So... unless the compiler specifically states that it is deterministic, the OP should just shrug his shoulders and accept it? IMHO, caprice should be expected in government policies, not in compilers. Am subscribing to this mostly because i find it intriguing and would like to be notified if csakthikumar ever finds the reason behind this.

rtmistler · 06-26-2018, 02:46 PM

My experience is:

Same code (no changes)
Same tools (no changes)
Same process/makefile (no changes)

Result EXACTLY the same.

I'd say for years, since the 70's, we either assemble, or compile. And once we had a release, we froze that code, along with the tools to build it and many, many times we verified that it generated exactly the same result. This used to be part of a submission process for one of my former employer's freeze process. We had to prove that we could regenerate the exact same result. If not, we did something wrong.

Any chance that you have a rolling distribution where something got upgraded?

csakthikumar · 06-26-2018, 08:28 PM

Quote:

Originally Posted by dogpatch

So... unless the compiler specifically states that it is deterministic, the OP should just shrug his shoulders and accept it? IMHO, caprice should be expected in government policies, not in compilers. Am subscribing to this mostly because i find it intriguing and would like to be notified if csakthikumar ever finds the reason behind this.

Exactly this is the first time I am seeing like this. I preassumed compiler will always give the same output if the environment and code is not modified

csakthikumar · 06-26-2018, 08:32 PM

Quote:

Originally Posted by rtmistler

My experience is:

Same code (no changes)
Same tools (no changes)
Same process/makefile (no changes)

Result EXACTLY the same.

I'd say for years, since the 70's, we either assemble, or compile. And once we had a release, we froze that code, along with the tools to build it and many, many times we verified that it generated exactly the same result. This used to be part of a submission process for one of my former employer's freeze process. We had to prove that we could regenerate the exact same result. If not, we did something wrong.

Any chance that you have a rolling distribution where something got upgraded?

I have also got this issue during code freeze process aka source code consistency process only. Also I am able to reproduce this issue. When I build the libs like 26 times I am able to find that the libs being built 25 times is different from the 26th time. Even though this 25 - 26 number is not consistent.

rtmistler · 06-27-2018, 06:48 AM

I know I wrote a few paragraphs, but I actually had a question at the end of that.

Quote:

Originally Posted by rtmistler

Any chance that you have a rolling distribution where something got upgraded?

Does sound like you answered though when you mention you can build repeatedly OK and then see a fault one time.

csakthikumar · 06-28-2018, 05:01 AM

Quote:

Originally Posted by rtmistler

I know I wrote a few paragraphs, but I actually had a question at the end of that.Does sound like you answered though when you mention you can build repeatedly OK and then see a fault one time.

in my OP have mentioned that there is no changes in compiler or related tools or literally anything else in the build environment. On further analysis have found that when we have multiple local variable declaration that is where this sort of problem is happening Once I finish my deep analysis I will post a report over the same.

pan64 · 06-28-2018, 06:07 AM

Theoretically there are a few tools available to detect [almost] any kind of changes, so you can compare two executions of the build process. But I'm not really sure you can do that in your case.
The changes could be: different source code, different tools, different environment, different os/platform/user/hardware, but unfortunately it can be simply the date which will be different every time.
Yes, in general from the same source the system should generate the same result, but without knowing the details hard to check what can influence your build process and what kind of differences have any effect on the result.

NevemTeve · 06-28-2018, 06:18 AM

Is the test automatized? I mean something like this:

Code:

for i in $(seq 100); do
    gcc-toplatform ... -o suspected.o -c suspected.c
    printf "%s %s\n" "$(date +%Y%md%d.%H%M%S)" "$(md5sum suspected.o)" >>checksum.log
done

csakthikumar · 06-28-2018, 06:20 AM

Quote:

Originally Posted by pan64

Theoretically there are a few tools available to detect [almost] any kind of changes, so you can compare two executions of the build process. But I'm not really sure you can do that in your case.
The changes could be: different source code, different tools, different environment, different os/platform/user/hardware, but unfortunately it can be simply the date which will be different every time.
Yes, in general from the same source the system should generate the same result, but without knowing the details hard to check what can influence your build process and what kind of differences have any effect on the result.

different source code, ---> my builds will have the sha id based on which the build has happened. This matches
different tools, ---> this is a CI environment which has not been modified or patched for the past 6 months atleast
different environment, ---> as above
different os/platform/user/hardware ---> as above

Adding to that our deliverable will be in terms of libs and for each platform we used to build 12 libs of which only 1 lib is mismatching on displaying the assembly similar to the one present in OP. It has been confirmed that only two instructions are swapped.

pan64 · 06-28-2018, 06:27 AM

can you reproduce it anyway? how? or it just happened once....

csakthikumar · 06-28-2018, 06:38 AM

Quote:

Originally Posted by NevemTeve

Is the test automatized? I mean something like this:

Code:

for i in $(seq 100); do
    gcc-toplatform ... -o suspected.o -c suspected.c
    printf "%s %s\n" "$(date +%Y%md%d.%H%M%S)" "$(md5sum suspected.o)" >>checksum.log
done

yes something like this since mine is lib i can just do "fc" over it with the base lib and break execution when both lib mismatches

Quote:

Originally Posted by pan64

can you reproduce it anyway? how? or it just happened once....

No I can reproduce it and I kindoff figured it out what the problem is too. NO trying to use asm to remove this kindoff issue