status of cilkplus in gcc?

[rnickb]

What's going on with cilkplus in gcc? Is it still being actively used and developed? 

This link says it's been "supported" for some time: https://www.cilkplus.org/which-license#gcc-development.

​Yet it doesn't seem to work with some of the simplest code like below which gives an ICE with gcc.

http://melpon.org/wandbox/permlink/PxcBvdYh1nMvUlsZ

#include <cilk/cilk.h>                                                             
#include <vector>                                                                  
                                                                                   
auto f() {                                                                         
  std::vector<double> v;                                                           
  return v;                                                                        
}                                                                                  
                                                                                   
int main() {                                                                       
  auto x = cilk_spawn f();                                                         
  auto y = f();                                                                    
  cilk_sync;                                                                       
  return 0;                                                                        
} 

[Igor_Z_Intel]

Hi!

Sorry for delay! This looks like regression from gcc5.x. I'm testing a patch for the issue so hopefully it will be in gcc trunk next week

Thanks,

Igor

[rnickb]

Great! And thanks for getting back to me. The bug report is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68001 fyi.

[rnickb]

The other major issue is that code compiled without an optimization level triggers a floating point exception (http://melpon.org/wandbox/permlink/dylzm0PkGt8zdLgp)

Something similar was reported in this bug report (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66326)

[rnickb]

It looks like the floating point exception bug is fixed. But any progress on the other issue of supporting functions that return values for cilk_spawn?

[Igor_Z_Intel]

Change that fixes the internal compiler error will be committed soon, hopefully tomorrow.

[rnickb]

Any progress with the cilk_spawn issue? It looks like cilk_spawn is broken for functions that returns a type with a non-default copy or move constructor. I put in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68997 to keep that bug distinct from the diagnostic ICE issue.

Not being able to use cilk_spawn for simple functions like this is a total show stopper. It would be great if it could be fixed. Thanks.

[Igor_Z_Intel]

Thank you for submitting separate issue for the problem. It is occurred that cilk_spawn issue fix requires non-trlivial changes and it's too late to GCC6 so we plan to work on it in GCC7

[TimP]

Will cilkrts be supported eventually for any Windows gcc target?

[Hansang_B_Intel]

A short answer is that there isn't any plan of supporting Cilk on GCC+Windows now.

I am not sure if it helps, but cilkplus.org started releasing source code for Windows runtime which depends on Intel compiler and Visual Studio. Of course, it wouldn't work with GCC at all, but users with a keen interest can start from there at least.

[rnickb]

I put in a patch that fixed the issue of using cilk_spawn with a function that returns a value, but there are still a lot of showstopper bugs with cilk. There's a meta bug (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69582) aggregating the different problems. These are some of the more serious issues:

• cilk_spawn is broken when used with assignment operators (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69021 and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69017)
• cilk extensions don't work inside of precompiled headers (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70865)

Now that the gcc-7 branch is open, I hope you guys will consider working through some of these to bring cilk support up to a stable state in gcc. I think that would be a great step forward for cilk's adoption.

Thanks - Ryan 

[TimP]

cilkplus is enabled in some gcc Windows distributions, including cygwin64 gcc 5.3, but so little of it works that I don't see the value.  I  built gcc7 on cygwin again yesterday, but I didn't see a possibility of including cilkrts.  I've heard from people who never use cilk_for, as an example, so maybe not everyone cares.

Most of the discrepancies between Intel C++ and cilk(tm) plus were fixed some time ago so it is possible to get equivalent vectorization either way, using pragmas as necessary, at least with active releases like 15.0.6 and the less stable 16.0.

[rnickb]

Any updates on this? 

Do you plan on fixing the assignment issues for gcc7?

[Hansang_B_Intel]

Yes, there is a plan for fixing the assignment issue for gcc7.

[GAl-G]

​Simplest Cilk Plus doesn't work for me on Mac with the HPC Mac GCC: http://hpc.sourceforge.net

Undefined symbols for architecture x86_64:

  "___cilkrts_cilk_for_32", referenced from:

      _main in ccUGwP6T.o

ld: symbol(s) not found for architecture x86_64

collect2: error: ld returned 1 exit status

I've of course passed -fcilkplus

[TimP]

Gabriel A. wrote:

​Simplest Cilk Plus doesn't work for me on Mac with the HPC Mac GCC: http://hpc.sourceforge.net

Undefined symbols for architecture x86_64:

  "___cilkrts_cilk_for_32", referenced from:

      _main in ccUGwP6T.o

ld: symbol(s) not found for architecture x86_64

collect2: error: ld returned 1 exit status

I've of course passed -fcilkplus

Did you check gcc -v or the lib directories to see whether libcilkrts was included?  It's not built by default for some targets (presumably those where it hasn't been tested and debugged).

[TimP]

It has been more than a year since any of my gcc bugzilla submissions on cilkplus have been touched.  I guess Intel may be terminating support of this project.  I don't think any of us who are now on the outside can have any way of knowing whether any such projects initiated by Intel will continue, given the recent cuts of projects which don't have a direct revenue stream and early retirements of people working on them.  Even before I retired, Intel shifted resources from Cilk(tm) Plus to OpenMP, where they have one of the best offerings now (OpenMP 4.5 in beta, nearly all in releases).

Intel's own cilk(tm) plus implementation matches performance of their C++ on a mini-benchmark I have resurrected this month, when run on single CPU Nehalem with HT disabled. 11 of 13 tests in that benchmark are able to run on stock gcc cilkplus. 

On my Haswell which has no option to disable HT, and on my old boxes with more than 4 cores, Intel cilk(tm) plus falls short of performance of their OpenMP.  Those older programming models are difficult enough, with the recent update of ifort 2015 out-performing their 2016 and 2017 releases (with -Qfma-). Of course, there is a different targeting between OpenMP, which expects one user to have exclusive use of all CPUs sharing memory, vs. cilk(tm) plus which may facilitate dynamic sharing of resources among independent jobs (not a mode for which Intel(r) Xeon Phi(tm) is suited).

[rnickb]

Yes, Intel certainly seems to be dragging its feet with regards to gcc cilk support. 

But they shouldn't! And I would disagree: I think cilk's task based parallelism is very well suited for their Phi processors, especially Knight's Landing. If they finally get around to fixing these issues, then gcc coupled with the TBB version of MKL (https://software.intel.com/en-us/articles/using-intel-mkl-and-intel-tbb-in-the-same-application) will allow you to write highly parallel library components that are then reusable in any environment, without mandating exclusive CPU access to get good performance - something OpenMP and Nvidia's CUDA can't do.

The gcc cilk support is important because 1) Without it, everything you write would either require intel's ICC compiler or be forced to disable the cilk parallelism and 2) Support for the latest c++11/c++14 features are really flaky with ICC, and support for the upcoming c++ TSs such as concepts likely won't be added anytime soon; so if you want to use modern c++ together with cilk, then gcc is the only option.

[Hansang_B_Intel]

Gabriel A. wrote:

​Simplest Cilk Plus doesn't work for me on Mac with the HPC Mac GCC: http://hpc.sourceforge.net

Undefined symbols for architecture x86_64:

  "___cilkrts_cilk_for_32", referenced from:

      _main in ccUGwP6T.o

ld: symbol(s) not found for architecture x86_64

collect2: error: ld returned 1 exit status

I've of course passed -fcilkplus

It looks like the GCC driver is not adding the required link flag (-lcilkrts) when -fcilkplus was specified. 

Adding -lcilkrts should be fixing the problem for now.

[rnickb]

Any updates on this? I haven't seen any patches on the GCC mailing list to fix the cilk issues. Are you guys still planning on working on this?