GNOME Bugzilla – Bug 350973
[ARM] Mangled floating point constants
Last modified: 2008-12-14 21:42:19 UTC
Please describe the problem: WHen importing a spreadsheet, either as .xls or .gnumeric to the Nokia 770 ) (or the other way) gnumeric application (maemo 2.0 port) then the formula =e146*1.035 (increase the value of cell e146 by 3.5 percent) imports (or exports) as: =e146*2.26204099014712e-111 This is without regard to whether the file comes/goes from gnumeric (version 1.5.or 1.6), Open Officer 2.0, or Excel XP. Steps to reproduce: 1. Enter formula in Nokia as e146*1.035 2. Save file as either .xls or .gnumeric 3. open same file in gnumeric (in the case of .gnumeric file) or gnumeric, open office or excel 5. Cell comes out as above. The opposite direction resolves exactly the same way. Actual results: see above Expected results: the formula would cross between systems unchanged. Does this happen every time? yes Other information: not that I'm aware of. If you need more information, please contact me.
I could not confirm the .gnumeric file is broken, just the .xls. Below, I'm attaching one simple .gnumeric file and the .xls equivalent and the screenshots showing the bug.
Created attachment 72324 [details] Simple .gnumeric test file
Created attachment 72325 [details] Screenshot of the .gnumeric test file opened in Nokia 770 device
Created attachment 72326 [details] Same .gnumeric test file in .xls format
Created attachment 72327 [details] Screenshot of the .xls test file opened in Nokia 770 device
What chip is being used? If it is ARM, please have a look at libgsf/gsf/gsf-utils.c. Search for "arm".
(In reply to comment #6) > What chip is being used? > > If it is ARM, please have a look at libgsf/gsf/gsf-utils.c. Search > for "arm". > Yes, it is ARM. I'll check if __arm__ is defined here. Thanks for the tip. I have created the same file in Nokia 770 and exported to both .xls and .gnumeric formats. And now you can see the same result in x86 platform. They are attached below.
Created attachment 72426 [details] Simple .gnumeric test file generated in Nokia 770 device.
Created attachment 72427 [details] Same .gnumeric test file in .xls format generated in Nokia 770 device.
(In reply to comment #6) > What chip is being used? > > If it is ARM, please have a look at libgsf/gsf/gsf-utils.c. Search > for "arm". > This is what we have in libgsf/gsf/gsf-utils.c: /* * Glib gets this wrong, really. ARM's floating point format is a weird * mixture. */ #define G_ARMFLOAT_ENDIAN 56781234 #if defined(__arm__) && !defined(__vfp__) && (G_BYTE_ORDER == G_LITTLE_ENDIAN) #define G_FLOAT_BYTE_ORDER G_ARMFLOAT_ENDIAN #else #define G_FLOAT_BYTE_ORDER G_BYTE_ORDER #endif Although __arm__ is defined and the Nokia 770 processor is an ARM, somehow we don't need to define G_FLOAT_BYTE_ORDER as G_ARMFLOAT_ENDIAN. So I've created a simple patch that will be applied in debian package creation only. It just forces G_FLOAT_BYTE_ORDER to be defined as G_BYTE_ORDER. Index: gsf-utils.c =================================================================== RCS file: /cvs/gnome/libgsf/gsf/gsf-utils.c,v retrieving revision 1.43 diff -u -p -r1.43 gsf-utils.c --- gsf-utils.c 14 Jun 2006 18:44:44 -0000 1.43 +++ gsf-utils.c 8 Sep 2006 21:46:49 -0000 @@ -34,7 +34,7 @@ * mixture. */ #define G_ARMFLOAT_ENDIAN 56781234 -#if defined(__arm__) && !defined(__vfp__) && (G_BYTE_ORDER == G_LITTLE_ENDIAN) +#if defined(__arm__) && !defined(__vfp__) && (G_BYTE_ORDER == G_LITTLE_ENDIAN) && 0 #define G_FLOAT_BYTE_ORDER G_ARMFLOAT_ENDIAN #else #define G_FLOAT_BYTE_ORDER G_BYTE_ORDER I really don't think this is a bug in libgsf. I have built new libgsf packages with the patch applied and now the bug is gone.
(In reply to comment #10) > (In reply to comment #6) > This is what we have in libgsf/gsf/gsf-utils.c: > > /* > * Glib gets this wrong, really. ARM's floating point format is a weird > * mixture. > */ > #define G_ARMFLOAT_ENDIAN 56781234 > #if defined(__arm__) && !defined(__vfp__) && (G_BYTE_ORDER == G_LITTLE_ENDIAN) > #define G_FLOAT_BYTE_ORDER G_ARMFLOAT_ENDIAN > #else > #define G_FLOAT_BYTE_ORDER G_BYTE_ORDER > #endif > > Although __arm__ is defined and the Nokia 770 processor is an ARM, somehow we > don't need to define G_FLOAT_BYTE_ORDER as G_ARMFLOAT_ENDIAN. This is not a cpu specific problem, but an FP emulation problem. On arm you can use 2 different floating point formats: fpa and vfp, both available as 'hard' (coprocessor or in-kernel emulation) or 'soft' (emulating in gcc/glibc). The current debian ARM port, and Nokia's IT2005 use the 'hard'fpa format, which means that floatingpoints are stored as bigendian, the upcoming EABI port of debian and Nokia's IT2006 use the softvfp format which stores floatingpoints with the same endiannes as the cpu (ARM cores are endian-agnostic, you can make the kernel put it in another endianness mode on boot). I hope this clears it up a bit :) Some recommended reading: http://wiki.debian.org/ArmEabiPort
That sounds like libgsf needs to be changed to run-time detect this.
Where do we stand here ? Does the maemo platform still require gsf to do runtime testing of endianness for floats ?
This issue seems still be present on current OS2008 platform. Somebody is porting Gnumeric 1.8 to OS2008, and found the same problem that Eduardo, and had to use a bugfix provided by Eduardo. http://www.internettablettalk.com/forums/showpost.php?p=142630&postcount=77
I can write up a proper fix if someone is willing to commit to test it in the proper environment. And we should probably add a simple run-time test for it somewhere -- that would be cheap and point directly at the problem instead of sending victims off on a wild goose chase.
I have added a self-check for gsf_le_get_double in gsf_init.
The self-check triggered a build problem on Debian's armel port and a patch for the G_FLOAT_BYTE_ORDER setting logic was provided in response (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503144), which I've committed to libgsf svn trunk, http://svn.gnome.org/viewvc/libgsf?view=revision&revision=1018 and added to the Debian libgsf source package, after which libgsf could be built successfully on armel. Thus, I believe this issue to be fixed. As I don't have access to a Nokia 770 myself, I'd appreciate it if someone could confirm that the problem as reported by Keith is no longer reproducible after updating libgsf to the svn trunk version.
Believed fixed -- closing. This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.