I am sorry for the late response, my health hasn't been very good today.
What I wanted to discuss was in terms of reproducibility of tcc compiler, We know that we should focus more on reproducible builds, and even more so; security of reproducible builds can be of great importance.  suggest that we can use a trusted compiler to recompile the source code of a build twice to see if there is any backdoor in the binary, this helps with ensuring the reproducibility and security of the build.
has type long
double, tcc eventually stores this 0.0 in memory as a
long double value. The problem is that tcc’s “long
double” uses only 10 bytes, but it is stored in 12 bytes,
and tcc’s source code does not initialize the extra 2
bytes. The two excess “junk” bytes end up depending
on the underlying environment, causing variations in
the output. In normal operation these bytes are
ignored and thus cause no problems.
To resolve this, the value “0.0” was replaced with
the _expression_ (f1-f1), since f1 is a long double
variable known to have a finite value there (e.g., it is
not a NaN). This is semantically the same and
eliminated the problem. A better long-term solution
for tcc would be to always set these “excess” values to
constants (such as 0x00)"
Using (f1-f1) is a workaround for using 0.0. It would not affect the normal operations but would be useful for reproducibility and DDC test (for security).