"next" is a reserved keyword for phasers. The frontend will throw an error whenever a local or a field is name next.
- Pitfall: It is forbidden to pass addresses of locals on stack to an async IN clause
- Use the OUT clause
- Pass a pointer to a data-structure allocated on the heap
- Pitfall: Arrays allocated on stack are currently not supported
- Work with arrays allocated on the heap
- Pitfall: Only a single IN, OUT or INOUT clause can be provided to an async.
- IN can take several arguments (similarly to a method call invocation).
- Pitfall: OUT variables are guaranteed to have been written back only after the enclosing finish scope is finished
Referencing Internal HC Values Without ROSE Generated HC Code
It's possible with certain function/macro calls to reference the HC worker state even though you aren't in a valid HC program. I ran into this in some HCMPI code compiled with hcc when trying to call
which reference the fields comm_rank and comm_size in the HC worker state. However, I got segfaults because no HC worker state existed as hcc had not generated any of the necessary code using ROSE. I solved this by adding a dummy finish scope in the program, indicating to the compiler that this was indeed HC code. hcc then correctly produced the auto-generated code for initializing the HC state.
Calling HC Functions From non-HC Code
When calling an HC function from non-HC code in separate files, the hcc compiler will not be able to resolve the function definition. This is a result of the name-mangling that HC does, which is not reflected in the original header files. As a result, when the final ROSE generated C file is compiled with the original calling C/C++, the compiler won't resolve the originally named function to the new HC-mangled one. The way to fix this is by adding
above the function declaration in the header file. And tada! Fixed. Credit to Vincent for teaching me this.