[sane-devel] xsane infinite loop lockup - seems to boil down to compiler optimisation difference
david at pastornet.net.au
Tue Aug 7 12:28:02 UTC 2007
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.
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.
Julien BLACHE wrote:
> David Campbell <david at pastornet.net.au> wrote:
>> 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.
More information about the sane-devel