Various fixes in setting globals in a script group

Bug: 25602504

1) Fixed setting 64-bit globals on a 32-bit platform.

The long values were casted to pointer-size integers (uintptr_t) or void*
in the runtime implementation. This caused the upper 32 bits to be lost
on 32-bit platforms. Fixed that by casting to int64_t instead.

2) Fixed setting Allocation values (either as arg or a global) in a script
group.

The size for a value in a script is signed, with -1 indicating that the
value is an Allocation. The sign has to be kept across different layers
of our stack.

3) Added a test for both native and support libraries for passing
floating point values to a script group, and for passing 64-bit values
(long or double) to a script group.

Change-Id: Ifff099a76be7707df7b67c388395f5a00f9cae66

1 files changed, 2 insertions, 2 deletions

diff --git a/cpu_ref/rsCpuScriptGroup2.cpp b/cpu_ref/rsCpuScriptGroup2.cpp
index f0b657a2..5ea71d3c 100644
--- a/cpu_ref/rsCpuScriptGroup2.cpp
+++ b/cpu_ref/rsCpuScriptGroup2.cpp
@@ -509,9 +509,9 @@ void Batch::setGlobalsForBatch() {
         const IDBase* funcID = closure->mFunctionID.get();
         Script* s = funcID->mScript;;
         for (const auto& p : closure->mGlobals) {
-            const void* value = p.second.first;
+            const int64_t value = p.second.first;
             int size = p.second.second;
-            if (value == nullptr && size == 0) {
+            if (value == 0 && size == 0) {
                 // This indicates the current closure depends on another closure for a
                 // global in their shared module (script). In this case we don't need to
                 // copy the value. For example, an invoke intializes a global variable