Bug 964422 - R-bitops-1.0.5 is FTBS on ARM
Summary: R-bitops-1.0.5 is FTBS on ARM
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: R-bitops
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: josef radinger
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: ARMTracker
TreeView+ depends on / blocked
 
Reported: 2013-05-18 12:36 UTC by Peter Robinson
Modified: 2013-08-16 14:30 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-08-16 14:30:52 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Peter Robinson 2013-05-18 12:36:22 UTC
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 14:59:34 UTC
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 13:57:27 UTC
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 11:24:41 UTC
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 14:30:52 UTC
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.