[sane-devel] xsane infinite loop lockup - seems to boil down to compiler optimisation difference

[David Campbell]

Hi,

I did earlier today report a problem to fedora at 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=251096 and it has 
since been resolved as not a bug, and they make a good case.

Read http://www.network-theory.co.uk/docs/gccintro/gccintro_70.html 
which says that the default behaviour on linux with gcc is to use the 
extended precision mode of operation

Basically, the default behaviour with Linux is for the processor to use 
the extended precision mode, which means that depending on whether the 
compiler has made the code use processor registers, some floating point 
operations can end up with greater precision than others.

This means that the current comparison "if (new_val != val)" in the 
xsane_back_gtk_value_update() function in xsane-back-gtk.c is invalid, 
because if there is the slightest difference in the floating point value 
(and there can be if the compiler has decided to implement the code 
optimally using processor registers), it will attempt to set the value 
again, and I'm seeing an infinite looping happening there because it 
never gets to the point where the values are the same!

I'm not so familiar with the rest of the code and haven't been able to 
propose a proper fix for this, but there are some compiler flags that 
apparently work around it, but they might be specific to the x86 
architecture...see the bottom of the bugzilla comment above.

-- Dave

Julien BLACHE wrote:
> David Campbell <david at pastornet.net.au> wrote:
>
> Hi,
>
>   
>> I stripped it down to a little snippet of code, and you can see that 
>> this program below gives a different result when compiled with -O2 than 
>> it does when compiled without -O2.  Also, if you uncomment the print 
>> statements below, you get different behaviour.
>>     
>
> Please report this compiler bug to Fedora.
>
> JB.
>
>