Bug 964422 - R-bitops-1.0.5 is FTBS on ARM
R-bitops-1.0.5 is FTBS on ARM
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: R-bitops (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: josef radinger
Fedora Extras Quality Assurance
:
Depends On:
Blocks: ARMTracker
  Show dependency treegraph
 
Reported: 2013-05-18 08:36 EDT by Peter Robinson
Modified: 2013-08-16 10:30 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-16 10:30:52 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Peter Robinson 2013-05-18 08:36:22 EDT
R-bitops-1.0.5 is FTBS on ARM. 1.0.4 previously built fine. It fails on F-18/19/rawhide

Error is:

* checking compiled code ... OK
* checking examples ... ERROR
Running examples in 'bitops-Ex.R' failed
The error most likely occurred in:
> ### Name: bitFlip
> ### Title: Binary Flip (Not) Operator
> ### Aliases: bitFlip
> ### Keywords: arith utilities
> 
> ### ** Examples
> 
>  stopifnot(
+   bitFlip(-1) == 0,
+   bitFlip(0 ) == 4294967295,
+   bitFlip(0, bitWidth=8) == 255
+  )
Error: bitFlip(-1) == 0 is not TRUE
Execution halted

Full logs can be found here:

http://arm.koji.fedoraproject.org/koji/packageinfo?packageID=184
Comment 1 Peter Robinson 2013-06-03 10:59:34 EDT
Any update? This is blocking a number of other R packages on ARM that all previously built fine
Comment 2 Tom "spot" Callaway 2013-08-14 09:57:27 EDT
1.0.4.1 has the same bug, just not triggered by the less strict test.

bitflip(-1) should be 0, but on arm, it is 4294967295.

Something in this function is not correct on ARM:

SEXP bitFlip(SEXP a, SEXP bitWidth ) {
        int i, n, *xbitWidth;
        unsigned int  mask ;
        unsigned int tmp ;
        double *xa, *xaflip ;
        SEXP aflip ;

        PROTECT (a = AS_NUMERIC(a) ) ;
        PROTECT (bitWidth = AS_INTEGER(bitWidth) ) ;

        n=LENGTH(a) ;
        PROTECT (aflip = NEW_NUMERIC(n) ) ;

        xa=NUMERIC_POINTER(a) ;
        xaflip=NUMERIC_POINTER(aflip) ;
        xbitWidth=INTEGER_POINTER(bitWidth)  ;

        mask = ( unsigned int ) -1 >> (32 - *xbitWidth)  ;


        for (i=0; i<n; i++ ) {
                if ( !R_FINITE(xa[i]) || logb(xa[i])>31 ) xaflip[i]=NA_REAL ;

                else {
                      	tmp=(unsigned int) xa[i] ;
                        xaflip[i]=(double) ( ~tmp & mask ) ;
                }
        }
	UNPROTECT(3) ;
        return (aflip) ;
}
Comment 3 Florian Weimer 2013-08-16 07:24:41 EDT
This is the bug:

                      	tmp=(unsigned int) xa[i] ;

Casting double to unsigned is undefined if the value is negative.

Use this instead:

                      	tmp=xa[i] < 0 ? (int) xa[i] : (unsigned) xa[i];

Here's a small reproducer if you want to play with it:

#include <stdio.h>

int
main(int argc, char **argv)
{
  double v = 0.0;
  sscanf(argv[1], "%lf", &v);
  unsigned i = (int) v;
  printf("int = %08x\n", i);
  unsigned u = (unsigned) v;
  printf("unsigned = %08x\n", u);
  return 0;
}

[root@calxeda-arm-soc-02 ~]# ./a.out -1
int = ffffffff
unsigned = 00000000
Comment 4 Tom "spot" Callaway 2013-08-16 10:30:52 EDT
Thanks Florian! Fixed in R-bitops-1.0.5-3.fc20. Patch sent to upstream.

Note You need to log in before you can comment on or make changes to this bug.