Referenced methods break code compilation

[GoogleCodeExporter]

Hi there,

Currently I am creating a fluid simulation using Aparapi. This involves a 
pretty huge amount of kernel calls and function references within kernel 
entrypoints.

I noted that when accessing functions multiple times, the write order seems to 
be wrong. It seems to be possible, that a function is called before it is 
declared within the OpenCL code.

When looking at the source code, I found out that the functions are only 
defined, but not declared. If changing the code to explictely declare the 
function prototypes before defining them, the issue disappears. 

Appended you will find a corrected version of KernelWriter.java (but propably 
for an older version of Aparapi). By the way: What is the develop version of 
Aparapi? When checking out the trunk, as described in the Wiki, I only get 
compile errors. Using trunk-20130305 (which the file stems from), the 
compilation works great.

Thanks,
Matthias

Original issue reported on code.google.com by matthias.klass@gmail.com on 2 Jul 2013 at 8:59

Attachments:

• KernelWriter.java

[GoogleCodeExporter]

Mathias

Thanks, for finding and fixing this.   Just so I understand. Your observation 
was that we had generated something like

__kernel run(/* args */){
   foo();
}

void foo(){
}

And the OpenCL compilation was failing, so you added a 'forward reference' to 
the generated code to fix this...

void run(); // forward

__kernel run(/* args */){
   foo();
}

void foo(){
}

Do I understand the problem and the fix correctly?

If so, bravo and thanks.  I thought we built a Directed Acyclic Graph (DAG) of 
calls and traversed from the roots to get the call hierarchy correct.  Clearly 
there is something wrong with the current logic.

I am on vacation, but will try to review this today or tomorrow. 

Gary

Original comment by frost.g...@gmail.com on 2 Jul 2013 at 2:51

[GoogleCodeExporter]

Hi,

yip, exactly. This was a pretty simple fix, as you already had the code to 
provide a method signature in place. It's basically just another loop. Just out 
of interest: which one is the currently active folder or branch?

Matthias

Original comment by matthias.klass@gmail.com on 2 Jul 2013 at 3:08

[GoogleCodeExporter]

Great thanks. 

Yes the current branch is 'trunk' 
(https://code.google.com/p/aparapi/source/browse/#svn%2Ftrunk), trunk-20130305 
represents the code prior to the merge of Steven and Ryan's 'big tidy up' and 
support of multi-dimension arrays. 

I am currently working in 'branches/lambda' for Java 8 lambda support. 

This should be fixed in 'trunk', I will cross port it to 'trunk-20130305' and 
'branch/lambda'.

Thanks Matthias.  

Original comment by frost.g...@gmail.com on 2 Jul 2013 at 3:13

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Apologies for any bugs...Was this introduced by us or was it an existing bug 
that was recently exposed?

Also, the current Trunk does not build? On which platform?

Original comment by pnnl.edg...@gmail.com on 2 Jul 2013 at 6:05

[GoogleCodeExporter]

Hi,
sorry the not building trunk was my failure. My IDE used the wrong source 
folder ... sorry. No problem for the bug. I am currently evaluating various GPU 
abstraction frameworks - Aparapi is the (only) one that works.
Matthias

Original comment by matthias.klass@gmail.com on 2 Jul 2013 at 6:07