Intel® Cilk™ Plus

Is this a bug for icc

The following program causes a runtime crash reducer_impl.cpp:527: cilk assertion failed: h

My compiler is icc 13.1.1 on Ubuntu 12.04. 

#include <cilk/reducer.h>
#include <cilk/reducer_opadd.h> 
#include <cilk/cilk.h> 
#include void empty() {} 
std::atomic n; 
int test(int *x) { 
  cilk::reducer_opadd r; 
  n = 40000; 
  while (n--) { 
    cilk_spawn empty(); 
  return 0;
int main() { 
  int x = 1; 
  return test(&x); 

Convert regular FFT code to cilk


The attached code is an FFT implementation. It should work on any input vector length

I converted each for loop into a clik_for loop.

When I did it in line "for (i = 1; i < n; i += 2)" the results of the FFT were wrong.

There is also a probem with the while loops.

I tried to convert: "while (n > mmax)" to "cilk_for (;n>mmax;)" but I got a syntax error: missing control variable declaration and initialization.

What is the right way to convert a regular FFT code to a clik code ? 



How to cause cilk_for to use all cores ?


I ran a (very) simple cilk_for loop on a CoreI5-2400 CPU under windows XP-32bit.

The code is attached. It was compiled and built with the latest intel compiler using MSDEV 2010 

It seems that this loop runs a little bit faster than this loop implemented with intrinsic C.

But my CPU has 4 cores.

I expect the cilk code to run 4 times faster.  

How can I cause all cores to participate in the calculation ?



vectorlengthfor types


What are the types allowed in the vectorlengthfor clause?  

The 1.1 spec just says "type-name" with no restrictions whatsoever.  However, the icc 12.1 manual says "data type must be one of built-in integer types (8, 16, 32, or 64bit), pointer types (treated as pointer-sized integer), floating point types (32 or 64bit), or complex types (64bit or 128bit).".  Which is correct?

Assuming the icc manual is correct and the spec is lacking, are typedef substitutions allowed?  Say, "typedef int typint".  Is vectorlength(typint) allowed?

Subscribe to Intel® Cilk™ Plus