tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Regarding Long double Constant


From: Michael Matz
Subject: Re: [Tinycc-devel] Regarding Long double Constant
Date: Fri, 12 Feb 2021 23:01:00 +0100 (CET)
User-agent: Alpine 2.21 (LSU 202 2017-01-01)

Hello,

On Thu, 11 Feb 2021, Ayush Varshney wrote:

[1] https://www.researchgate.net/publication/245578769_Fully_Countering_Tru
sting_Trust_through_Diverse_Double-Compiling

On Thu, Feb 11, 2021 at 9:27 AM Ayush Varshney <varshneyayush90@gmail.com>
wrote:
      Hi everyone,
Hope you all are doing well!!
I am new to the tinycc community.
I was working over Diverse Double-compiling technique [1]. And found
there is a bad optimization performed by tcc. The problem is called
Long double constant problem.

Long double constant problem is for storing the value of 0.0, tcc stores 0.0 in memory as long double value but long double value in tcc takes only 10 bytes but the source code stores 0.0 value in 12 bytes.

Can you show this with a small example? Because TCC, when allocating storage in data sections (which is where float constants are stored) zeros the memory. (And the trivial example ala:

  long double ld;
  int foo(void) { return ld == 0.0; }

shows that indeed, .data contains only zeros. )

If you are talking about a different compiler than TCC having this problem (i.e. initializing only 10 of the 12 bytes), then _that_ needs to be fixed instead of putting such code in TCC.

Also, if TCC really has a problem in initializing some memory for reproducability it probably doesn't affect only long double, in which case fixing the root cause also will be better.

The extra two bytes creates variations in the output. The problem is solved using (f1-f1) instead of 0.0, it is semantically same and produces the same output. For example, Instead of ‘if(f2==0.0)’ use ‘if(f2==f1-f1)’

That's only a work around, for a compiler not initializing memory fully (and if it's TCC doing that, please show us where). Your change in init_putv also doesn't compile. Please don't push anything to mob that you haven't at least tested for that. But even better would be to give us some more details.

Meanwhile I've reverted the change as it broke mob.


Ciao,
Michael.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]