Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

Journeyman III

OpenCL compiler crash in clBuildProgram (W8100/Win7/Crimson 16.30)


I reported this problem to the AMD driver team, which referred me to this forum.

I recently updated to the AMD FirePro Beta 16.30 driver suite currently available from your website. I am using it together with the latest version of the AMD APP development kit 3.0 under Windows 7. After updating the driver from the current stable version 15.301.2601.1002 in order to also use the card with the Oculus Rift, I experience the following problem when compiling certain OpenCL code: Under very specific (one might say obscure) circumstances, I get a crash of the AMD OpenCL compiler during the call to clBuildProgram. The output on the console is:

Error in hsa_code section, at offset 756: Instruction has invalid rounding (default), expected: none

LLVM ERROR: Brig container validation has failed in BRIGAsmPrinter.cpp

Afterwards the program crashes, i.e. the call to clBuildProgram never returns. I traced the issue to the use of a bool type variable in an arithmetic expression such as my_bool*my_float. However, I only can trigger the problem after some gymnastics before, in particular using read_imagef.

I was able to reduce my code to the attached test case. Strangely enough, it seems that all of the weird bells and whistles in the code are required to trigger the bug. That seems to include in particular

  1. the outer loop (even though of a fixed size)
  2. the call to read_imagef
  3. the strange boolean gymnastics in the lines preceding the arithmetic statement.

Removing any of these does not trigger the bug any more for me. As mentioned, this is a new error appearing in conjunction with the 16.X version of the workstation display drivers. Versions 15.X were fine.

Maybe someone here can have a look and figure out what's going on. It is my understanding of the OpenCL 2.0 specification that all of the included statements in my code should be allowed. In any case, even if they did violate the language specs this should not crash the compiler (or rather linker, judging by the error message). As a work around, I found that my code compiles and works well when I use a trinary operator instead of the bool arithmetic statement (that is x += accept ? x : 0.0).

Thank you,

Alexander Wittig

4 Replies

Hi Alexander,

Thanks for reporting the issue. We'll check and get back to you shortly.




I'm able to reproduce the crash. I'll file a bug report against it.



Thank you!



The compilation error (and also the crash) is no longer reproducible with the latest internal driver. So, please keep patience until that driver is publicly available.