Hi Philipp,
I did some testing using this main.c:
int sum(long a[], long b[]) __reentrant
{
long f[1];
f[0] = a[0] + b[0];
return f[0] + b[0];
}
int main(void)
{
long a = 1, b = 2;
return sum(&a, &b);
}
Compiling with "sdcc --model-medium main.c".
Results for the following versions (all Windows binaries downloaded from
SourceForge, 32-bit versions unless nothed otherwise), on a Windows 11 machine.
4.2.0-x64 gives *different* results on consecutive compile cycles.
4.3.0-x64 gives same results on consecutive compile cycles.
4.4.0 gives same results on consecutive compile cycles.
4.5.0 gives same results on consecutive compile cycles.
4.5.0-x64 gives same results on consecutive compile cycles.
The differences in the 4.2.0-x64 generated files, first few lines of the
assembly listing:
Comparing files main.asm and MAIN.OLD.ASM
***** main.asm
;sloc0 Allocated to stack - _bp +8
;sloc1 Allocated to stack - _bp +1
;sloc2 Allocated to stack - _bp +5
;------------------------------------------------------------
***** MAIN.OLD.ASM
;sloc0 Allocated to stack - _bp +8
;sloc1 Allocated to stack - _bp +4
;sloc2 Allocated to stack - _bp +1
;------------------------------------------------------------
*****
With corresponding differences in the generated code further down the files.
To me this fits to what you described in the other email about
https://sourceforge.net/p/sdcc/bugs/3772/.
So there is a problem in the (older version of the) boost library (perhaps
uninitialized memory/pointer or so, perhaps giving different results with the
Windows randomized memory address space layout randomization feature or so),
and this seems to have been resolved with a newer version of the library.
In other words: depending on which boost version was used when SDCC was
compiled, the bug could be present or not.
I do not know if it still is possible to check which boost versions were used
for the mentioned SDCC packages, but other than that I would call this case
closed?
Eric
> -----Original Message-----
> From: Philipp Klaus Krause <[email protected]>
> Sent: dinsdag 4 november 2025 15:01
> To: [email protected]
> Subject: Re: [Sdcc-user] Potential issues with non-deterministic compilation
> of
> 8051 code on W10/11?
>
> Am 04.11.25 um 10:33 schrieb Eric Rullens:
> > Yes, I have seen this as well. After compiling I always calculate a
> > CRC over the entire binary, and this is not identical over compile
> > cycles.
> >
> > It has been some time since I investigated this, but Windows 10 (and
> > 11) contain some memory protection features that are not present in
> > Windows 7:
> >
> > https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/
> > windows-10/security/threat-protection/overview-of-threat-mitigations-
> > in-windows-10#table-2
> >
> > These should not influence "correct" programs, but I suspect SDCC
> > somewhere uses uninitialized memory and/or pointers.
> >
> > At the time I did not dig further in the problem, but if it helps I
> > can check my notes again and recreate a test case.
> >
> > Eric
> >
>
> If you can reproduce this in SDCC 4.5.0 or later: SDCC works mostly function
> by
> function, so most SDCC issues can be reproduced within a single function
> (basically take the affected progra, find the affected function, and the
> check if
> compiling just that function (preceded by any necessary declarations, macros
> and
> inline function definitions) reproduces the issue - most times it does).
> If you can find a not too big code sample to reproduce it, please open a bug
> ticket.
>
> Philipp
>
>
> _______________________________________________
> Sdcc-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
_______________________________________________
Sdcc-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sdcc-user
