After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 141939 - Incorrect floating point format for arm
Incorrect floating point format for arm
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2004-05-05 17:54 UTC by Morten Welinder
Modified: 2018-05-24 10:31 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Morten Welinder 2004-05-05 17:54:37 UTC
M_PI from various machines:

sparc> ./a.out 
40 09 21 fb 54 44 2d 18 

x86> ./a.out
18 2d 44 54 fb 21 09 40 

arm> ./a.out
fb 21 09 40 18 2d 44 54

I don't know what endianness is reported for arm, but it is either little
or big endian and thus wrong for floating point.

See http://lists.gnome.org/archives/gnumeric-list/2004-May/msg00002.html
and follow-ups.
Comment 1 Morten Welinder 2004-05-05 17:57:35 UTC
Note especially that
http://lists.gnome.org/archives/gnumeric-list/2004-May/msg00005.html
claims they want to change format!  In other words, configure needs to determine
this based on a test program, not on cpp symbols.
Comment 2 Wookey 2004-05-21 15:08:00 UTC
The correct test for 'ARM devices using mixed-endian floating point' is:
#if defined(__arm__) && !defined(__vfp__) && (G_BYTE_ORDER == G_LITTLE_ENDIAN)

so it will still work on BIG_ENDIAN arm setups and newer hardware using the
vector floating point hardware.

This patches fixes reading in simple integers in a sheet:
--- gsf-utils.c.~1.20.~ Tue Apr 27 08:03:21 2004
+++ gsf-utils.c Wed May  5 13:17:25 2004
@@ -200,7 +200,12 @@
 double
 gsf_le_get_double (void const *p)
 {
-#if G_BYTE_ORDER == G_BIG_ENDIAN
+#if defined(__arm__) && !defined(__vfp__) && (G_BYTE_ORDER == G_LITTLE_ENDIAN)
+       double data;
+       memcpy ((char *)&data + 4, p, 4);
+       memcpy ((char *)&data, (const char *)p + 4, 4);
+       return data;
+#elif G_BYTE_ORDER == G_BIG_ENDIAN
        if (sizeof (double) == 8) {
                double  d;
                int     i;
Comment 3 Wookey 2004-05-21 15:21:13 UTC
Fixed in cvs (for get and set) (by Morten Welinder) see:
http://mail.gnome.org/archives/cvs-commits-list/2004-May/msg03303.html
Comment 4 Morten Welinder 2004-05-21 21:06:57 UTC
This has been worked around in libgsf, not really fixed.  This bug was filed for
glib and detect-the-right-endianess problem remains here.
Comment 5 Fabio Durán Verdugo 2010-12-29 03:17:58 UTC
This bug does still exists?
Comment 6 Morten Welinder 2010-12-29 14:09:33 UTC
> This bug does still exists?

Of course it does!  Hardware isn't likely to change.

configure.ac thinks there are only two choices: G_BIG_ENDIAN and G_LITTLE_ENDIAN.  You really can't handle more than two endian choices that way.

(Re-fixing title -- there's no relevant patch here.)
Comment 7 GNOME Infrastructure Team 2018-05-24 10:31:56 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/21.