opencilk-project icon indicating copy to clipboard operation
opencilk-project copied to clipboard

OpenCilk 2.0 RC1 Issue with namespacing of global types

Open wheatman opened this issue 2 years ago • 2 comments

The following code crashes with a lot of errors with unknown type names

namespace ns {
#include <cilk/cilk_api.h>
} // namespace ns
#include <cstdlib>
int main(int argc, char *argv[]) { return 1; }

error sample

In file included from test_reducer.cpp:7:
In file included from /usr/lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/cstdlib:75:
In file included from /usr/include/stdlib.h:394:
/usr/include/x86_64-linux-gnu/sys/types.h:103:9: error: unknown type name '__id_t'; did you mean 'ns::__id_t'?
typedef __id_t id_t;
        ^
/usr/include/x86_64-linux-gnu/bits/types.h:159:24: note: 'ns::__id_t' declared here
__STD_TYPE __ID_T_TYPE __id_t;          /* General type for IDs.  */

compiled with ./opencilkv20/build/bin/clang++ -fopencilk basic.cpp for reference

./opencilkv20/build/bin/clang++ --version
clang version 14.0.5 (https://github.com/OpenCilk/opencilk-project f51b7f1615e84757bfcc327a8e90371382db0e67)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/ubuntu/./opencilkv20/build/bin

It does not crash on the V1.1

clang++ --version
clang version 12.0.0 ([email protected]:OpenCilk/opencilk-project.git 5d2851d7d0e689ecb3b893aa6abd12390b838c4b)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/ubuntu/OpenCilk-12.0.0-Linux/bin

wheatman avatar Jul 07 '22 17:07 wheatman

Is there a particular reason you want to include cilk/cilk_api.h in its own namespace? Including headers within namespaces is generally considered a Bad Idea, so I'm curious why you would want to do this.

neboat avatar Jul 07 '22 17:07 neboat

This is a minimal example The reason why I did this originally was because I had some code that could be compiled with or without cilk, and when compiling without cilk didn't include the header since other compilers couldn't find it. I could just move this out of the namespace to fix this issue and use a separate ifdef, but wanted to report the bug in case it was something other people ran into, or something important

wheatman avatar Jul 07 '22 17:07 wheatman