Special construction can cause Aparapi to fail parsing valid Java bytecode about aparapi

[GoogleCodeExporter]

Thanks Kenneth.   

I will add this to the junit test case.  

Thanks for annotating the stack this helps a lot.  

As you can probably tell if you have walked through MethodModel the dup2 and 
dup_x2 bytecodes required special handling (we create synthetic tree nodes for 
these when creating the IR) and it looks like we need to create another 'corner 
case' fix.

Obviously the code in your example can be re-coded to avoid this so I trust 
this is not blocking you.    I will dive in and take a look. 

Again thanks for this. 

Original comment by [email protected] on 9 Feb 2012 at 4:16

• Changed state: Accepted

[GoogleCodeExporter]

Kenneth I just got around to this and cannot recreate the bug.  

Can you tell me which compiler you were using?

Was this using eclipse or oracle's javac?

Although our bytecode is the same. Here is mine

 0:   aload_0
 1:   getfield        #2; //Field a:[I
 4:   aload_0
 5:   getfield        #3; //Field b:[I
 8:   iconst_0
 9:   dup2
 10:  iaload
 11:  dup_x2
 12:  iconst_1
 13:  iadd
 14:  iastore
 15:  iconst_1
 16:  iastore
 17:  return

And here is my generated OpenCL. 

typedef struct This_s{
   __global int *a;
   __global int *b;
   int passid;
}This;
int get_pass_id(This *this){
   return this->passid;
}
__kernel void run(
   __global int *a, 
   __global int *b, 
   int passid
){
   This thisStruct;
   This* this=&thisStruct;
   this->a = a;
   this->b = b;
   this->passid = passid;
   {
      this->a[this->b[0]++]  = 1;
      return;
   }
}

I added this test to the codegen junit tests 
(com.amd.aparapi.test.junit.codegen.ArrayTortureIssue35)

cd aparapitrunk
cd examples
cd codegen
ant 

And it does not seem fail.

Can you try running the junit tests as shown above and see if you get different 
results. 

Original comment by [email protected] on 20 Feb 2012 at 8:59

[GoogleCodeExporter]

Codegen is in "test" not "examples".
Here is what I get from ant:
  [junit] Test com.amd.aparapi.test.junit.codegen.AccessDoubleArray FAILED
    [junit] Test com.amd.aparapi.test.junit.codegen.AssignAndPassAsParameterSimple FAILED
    [junit] Test com.amd.aparapi.test.junit.codegen.ContinueTorture FAILED
    [junit] Test com.amd.aparapi.test.junit.codegen.Drem FAILED
    [junit] Test com.amd.aparapi.test.junit.codegen.FirstAssignInExpression FAILED
    [junit] Test com.amd.aparapi.test.junit.codegen.FirstAssignInExpression2 FAILED
    [junit] Test com.amd.aparapi.test.junit.codegen.IEEERemainderDouble FAILED
    [junit] Test com.amd.aparapi.test.junit.codegen.MathAbs FAILED
    [junit] Test com.amd.aparapi.test.junit.codegen.MathDegRad FAILED
    [junit] Test com.amd.aparapi.test.junit.codegen.MathFallThru FAILED
    [junit] Test com.amd.aparapi.test.junit.codegen.MathMax FAILED
    [junit] Test com.amd.aparapi.test.junit.codegen.MathMin FAILED
    [junit] Test com.amd.aparapi.test.junit.codegen.MathRemainder FAILED

But those are likely false errors because libOpenCL is not found.

My Java version is:
java version "1.6.0_29"
Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-11D50b)
Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode)

My Eclipse version is:
Version: Indigo Service Release 1
Build id: 20110916-0149

And the problem was the same regardless of wether I used Eclipse or Java to 
build it.
But using the latests r268, the problem is no longer there.
It still hits (!txFormed), MethodModel.java:1292, but previously it did not 
find a match.
Now it finds the transform with "field array element post inccrement with 
nested index (local variable) ".
Not sure why that is though, but you can close this issue I think

Original comment by [email protected] on 21 Feb 2012 at 11:07

[GoogleCodeExporter]

That is very weird.   I do not recall modifying any of the code to fix this.

Let me leave this open for a while in case we see something similar.  I will 
create some more codegen tests and see if I can break it.

Thanks Kenneth.  

Original comment by [email protected] on 21 Feb 2012 at 3:20