ioc32/ioc64 doesn't work with #include

[RunDevelopment]

I can't get the IOC to work properly with the problem matcher of the task. When files contain #includes, I need to set the cwd of the IOC process to the directory where my files are but this will cause the IOC to output relative paths for included files. E.g.

./file.cl:10:1: error: some error message

This relative file format isn't supported by the problem matcher, even though I used options.cwd to set the working directory.

Is there any way to tell the IOC to output absolute paths or to get the problem matcher to support relative paths?

---

task.json

{
	"version": "2.0.0",
	"tasks": [
		{
			"type": "shell",
			"label": "opencl: custom build",
			"command": "ioc64",
			"args": [
				"-cmd=build",
				"-input=\"c:\\path\\to\\main.cl\""
			],
			"problemMatcher": [
				"$opencl.common"
			],
			"group": "build"
		}
	]
}

[Galarius]

That requires a research... @RunDevelopment, do you have a sample code that you can share for testing this case?

[RunDevelopment]

Sample project: sample.zip

The output of opencl: custom build absolute will this:

> Executing task: ioc64 -cmd=build -input="c:\Users\micha\Downloads\sample\cl\main.cl" <

OpenCL Intel(R) Graphics device was found!
Device name: Intel(R) HD Graphics 620
Device version: OpenCL 2.1 NEO
Device vendor: Intel(R) Corporation
Device profile: FULL_PROFILE
c:\Users\micha\Downloads\sample\cl\main.cl:2:10: fatal error: 'line.cl' file not found     
#include "line.cl"
         ^~~~~~~~~

Failed to build program...: -11 (CL_BUILD_PROGRAM_FAILURE)
Build failed!

As you can see, it can't find line.cl because the current working directory of ioc64 is the project directory c:\Users\micha\Downloads\sample.

The output of opencl: custom build relative

> Executing task: ioc64 -cmd=build -input="main.cl" <

OpenCL Intel(R) Graphics device was found!
Device name: Intel(R) HD Graphics 620
Device version: OpenCL 2.1 NEO
Device vendor: Intel(R) Corporation
Device profile: FULL_PROFILE
In file included from 1:2:
./line.cl:11:10: error: initializing 'float2' (vector of 2 'float' values) with an expression of incompatible type 'float3' (vector of 3 'float' values)
  float2 a = (float3)(0);
         ^   ~~~~~~~~~~
c:\Users\micha\Downloads\sample\cl\main.cl:7:3: error: implicit declaration of function 'bar' is invalid in OpenCL
  bar();
  ^

Failed to build program...: -11 (CL_BUILD_PROGRAM_FAILURE)
Build failed!

That will work but IOC outputs the path of included files relative to the working directory, so the problem matcher can't find the file.

The result will be that VS Code displays an error in main.cl but not in line.cl.

[Galarius]

@RunDevelopment, thank you for the detailed description. I believe the issue with problemMatcher’s configuration I specified for IOC. Take a look at this line.

I suggest to replace built-in problem matcher $opencl.common in tasks.json with manual configuration:

{
    "name": "opencl.fixed",
    "owner": "opencl",
    "pattern": {
        "regexp": "^(.*):(\\d+):(\\d+): ((fatal )?error|warning|Scholar): (.*)$",
        "file": 1,
        "line": 2,
        "column": 3,
        "severity": 4,
        "message": 6
    }
},

Just remove "fileLocation": "absolute" or replace “absolute” with “relative” (keeping options.cwd).

Some examples of using fileLocation option can be found in thread.

I’ll fix this in the next release or you could contribute if you wish :)

[RunDevelopment]

I tried you suggestion and after some trial and error I present this:

{
	"type": "shell",
	"label": "opencl: custom build relative",
	"command": "ioc64",
	"options": {
		"cwd": "${workspaceFolder}/cl"
	},
	"args": [
		"-cmd=build",
		"-input=\"main.cl\""
	],
	"problemMatcher": [
		{
			"fileLocation": ["autoDetect", "${workspaceFolder}/cl"],
			"pattern": {
				"regexp": "^(.*):(\\d+):(\\d+): ((fatal )?error|warning|Scholar): (.*)$",
				"file": 1,
				"line": 2,
				"column": 3,
				"severity": 4,
				"message": 6
			}
		}
	],
	"group": "build"
}

It works for me but the problem matcher has one obvious problem: I hardcoded the cwd.

This is because just "fileLocation": "autoDetect" resolve line.cl as /line.cl on my Windows PC (same for ./line.cl).

"fileLocation": "relative" will resolve line.cl as ${workspaceFolder}/line.cl and not ${workspaceFolder}/cl/line.cl and ${workspaceFolder}/cl/main.cl as ${workspaceFolder}/${workspaceFolder}/cl/main.cl.

So why didn't I use "fileLocation": ["autoDetect", "${cwd}"], so it's relative to the cwd? Because ${cwd} will get substitued as ${workspaceFolder} and not the actual cwd of the IOC process. No idea why it does that.

So yeah, after about 1h of experimenting with tasks, this is what I got.

---

Before this experiment, I played around with the IOC a bit more and found out that the IOC will basically specify the cwd as an included path in the build options. Not ver surprising, BUT it will output the absolute path of included files if you specifiy the cwd manually as part of the build options! So this task will output absolute paths:

{
	"type": "shell",
	"label": "opencl: custom build absolute with include",
	"command": "ioc64",
	"args": [
		"-cmd=build",
		"-input=\"${workspaceFolder}\\cl\\main.cl\"",
		"-bo=\"-I ${workspaceFolder}\\cl\""
	],
	"problemMatcher": [
		"$opencl.common"
	],
	"group": "build"
},

> Executing task: ioc64 -cmd=build -input="c:\Users\micha\Downloads\sample\cl\main.cl" -bo="-I c:\Users\micha\Downloads\sample\cl" <

Using build options: -I c:\Users\micha\Downloads\sample\cl
OpenCL Intel(R) Graphics device was found!
Device name: Intel(R) HD Graphics 620
Device version: OpenCL 2.1 NEO
Device vendor: Intel(R) Corporation
Device profile: FULL_PROFILE
In file included from 1:2:
c:\Users\micha\Downloads\sample\cl\line.cl:11:10: error: initializing 'float2' (vector of 2 'float' values) with an expression of incompatible type 'float3' (vector of 3 'float' values)
  float2 a = (float3)(0);
         ^   ~~~~~~~~~~
c:\Users\micha\Downloads\sample\cl\main.cl:7:3: error: implicit declaration of function 'bar' is invalid in OpenCL
  bar();
  ^

Failed to build program...: -11 (CL_BUILD_PROGRAM_FAILURE)
Build failed!

I have no idea why the IOC compiler behaves like this but I'll take it because it resolves my issue perfectly.

So maybe a small addition to README.md might be enough?

[Galarius]

It's definitely not enough, but it's a good start. I've added note about the issue to ReadMe. I hope to fix it this weekend if I can get to my Windows PC.

[LaVieEstDure]

Any updates on this? My language server diagnostics stop at the begging of the file at the #include of the other .cl file in the same directory.

[Galarius]

Hello, @LaVieEstDure! No updates, couldn't get to my Windows PC ;-)

This issue is related to offline compilation using ioc32/ioc64 compilers (not a language server). The feature is described here. There is a workaround available. But according to your comment, it is not something that can be useful to you.

Language server uses OpenCL API directly to compile the source code and publish diagnostics. You can specify headers search path using OpenCL.server.buildOptions. Supported build options are specified at khronos registry. Unfortunately, -I might not work, as this option is not portable. The recommended way to handle this issue is to create source objects from each included header using OpenCL API. I will try to allocate some time to update language server, but rather not mention any exact dates.

Please try to set OpenCL.server.buildOptions to -I "<headers search path>" in the workspace settings as a workaround.

[LaVieEstDure]

Cheers, I've gotten it to work with the -I option for now. Thanks for the great work!