The following program

#include <iostream>

constexpr bool is_host()
{
  bool result = true;

  if target(__nvvm_current_device_sm)
  {
    result = false;
  }

  return result;
}

int main()
{
  if constexpr(is_host())
  {
    std::cout << "main on host" << std::endl;
  }

  return 0;
}

Causes circle to emit the error message

$ circle --cuda-path=/usr/local/cuda -sm_60 repro.cu 
function call: repro.cu:17:23
error during call to bool is_host()
  function declared at repro.cu:3:16
  if constexpr(is_host()) 
                      ^
  error: repro.cu:7:13
  definition for @codegen object __nvvm_current_device_sm not available
    if target(__nvvm_current_device_sm) 

Compiler details:

$ ~/Desktop/circle/circle --version
circle version 1.0.0-140
  Circle public preview build 140
  Built Oct 21 2021 17:21:34
  (c) 2021 Sean Baxter
  https://www.circle-lang.org/
  Twitter: @seanbax

Hi, I'm interested in using circle's metaprogramming tools to extend an existing codebase that makes use of SIMD intrinsics, but it seems to be failing to compile. A small example here (code below)

#include <immintrin.h>

struct vec4 {
    double values[4];
    double & operator()(int i) { return values[i]; }
    const double & operator()(int i) const { return values[i]; }
};

vec4 plus(const vec4 & x, const vec4 & y) {
    return vec4{x(0) + y(0), x(1) + y(1), x(2) + y(2), x(3) + y(3)};
}

vec4 operator+(const vec4 & x, const vec4 & y) {
    __m256d _x = _mm256_loadu_pd(x.values);
    __m256d _y = _mm256_loadu_pd(y.values);
    vec4 sum;
    _mm256_storeu_pd(sum.values, _mm256_add_pd(_x, _y));
    return sum;
}

illustrates the problem: errors to the tune of

vector_size 64 is unsupported
typedef char __v64qi __attribute__ ((__vector_size__ (64))); 

Meanwhile, the 128-bit intrinsics seem to compile successfully:

#include <xmmintrin.h>

struct vec2 {
    double values[2];
    double & operator()(int i) { return values[i]; }
    const double & operator()(int i) const { return values[i]; }
};

vec2 plus(const vec2 & x, const vec2 & y) {
    return vec2{x(0) + y(0), x(1) + y(1)};
}

vec2 operator+(const vec2 & x, const vec2 & y) {
    __m128d _x = _mm_loadu_pd(x.values);
    __m128d _y = _mm_loadu_pd(y.values);
    vec2 sum;
    _mm_storeu_pd(sum.values, _mm_add_pd(_x, _y));
    return sum;
}

With gcc/clang, flags (e.g. -mavx) are sometimes needed to enable the larger intrinsics, I was wondering if there is something similar that needs to be passed to circle or if these are currently unsupported.

These examples were tested against build_136 on Ubuntu 20.04, as well as compiler explorer's "Latest" circle option (unsure what version that actually is).

#include <cstdio>

template<class T>
struct child {
    ~child() {
        @meta std::printf("Never called\n");
    }
};

template<class T>
child<T> dep = {};

static_assert(sizeof(dep<int>));

Hey @thedmd, is it possible to upgrade the godbolt circle to libstdc++10? I'm not sure why it is only finding 9. I've tried -libstdc++=10 which fails.

The program

__managed__ int result;

int main()
{
  return 0;
}

Causes circle to emit the error message

$ circle --cuda-path=/usr/local/cuda -sm_50 repro.cu 
error: repro.cu:1:17
unsupported attribute on declaration
__managed__ int result; 
                ^

Compiler details:

$ ~/Desktop/circle/circle --version
circle version 1.0.0-136
  Circle public preview build 136
  Built Sep 27 2021 23:42:52
  (c) 2021 Sean Baxter
  https://www.circle-lang.org/
  Twitter: @seanbax

The program

extern __shared__ int x[];

int main()
{
  return 0;
}

Causes circle to segmentation fault:

$ circle --cuda-path=/usr/local/cuda -sm_70 repro.cu 
Segmentation fault (core dumped)

Compiler details:

$ circle --version
circle version 1.0.0-162
  Circle public preview build 162
  Built Mar 12 2022 19:09:24
  (c) 2022 Sean Baxter
  https://www.circle-lang.org/
  Twitter: @seanbax

Hi, thank you for writing this compiler.

I am wondering if there is a recipe to replace an existing compiler, such as clang++ or g++, in a CMake project.

To switch between g++ and clang++ I do:

CXX=clang++  cmake .. -DCMAKE_BUILD_TYPE=Debug     && make
CXX=g++         cmake .. -DCMAKE_BUILD_TYPE=Release  && make

However this doesn't work:

CXX=/home/user/Download/build_161/circle  cmake .. -DCMAKE_BUILD_TYPE=Debug     && make

I get errors in cmake's modules when using circle, for example:

CMake version: 3.18.4
current build directory: /home/correaa/prj/alf/boost/multi/.build.circle.fast
CMake Warning at /usr/share/cmake-3.18/Modules/FindBoost.cmake:1187 (message):
  New Boost version may have incorrect or missing dependencies and imported
  targets
Call Stack (most recent call first):
  /usr/share/cmake-3.18/Modules/FindBoost.cmake:1311 (_Boost_COMPONENT_DEPENDENCIES)
  /usr/share/cmake-3.18/Modules/FindBoost.cmake:1919 (_Boost_MISSING_DEPENDENCIES)
  test/CMakeLists.txt:20 (find_package)


CMake Warning at /usr/share/cmake-3.18/Modules/FindBoost.cmake:1187 (message):
  New Boost version may have incorrect or missing dependencies and imported
  targets
Call Stack (most recent call first):
  /usr/share/cmake-3.18/Modules/FindBoost.cmake:1311 (_Boost_COMPONENT_DEPENDENCIES)
  /usr/share/cmake-3.18/Modules/FindBoost.cmake:1919 (_Boost_MISSING_DEPENDENCIES)
  test/CMakeLists.txt:20 (find_package)


CMake Error at /usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:165 (message):
  Could NOT find Boost (missing: unit_test_framework serialization) (found
  version "1.74.0")
Call Stack (most recent call first):
  /usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:458 (_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake-3.18/Modules/FindBoost.cmake:2177 (find_package_handle_standard_args)
  test/CMakeLists.txt:20 (find_package)


-- Configuring incomplete, errors occurred!
See also "/home/correaa/prj/alf/boost/multi/.build.circle.fast/CMakeFiles/CMakeOutput.log".
See also "/home/correaa/prj/alf/boost/multi/.build.circle.fast/CMakeFiles/CMakeError.log".

This is to stress test c++ compliance in my library for multidimensional arrays: https://gitlab.com/correaa/boost-multi

Thank you in advance, Alfredo

The program

#include <iterator>

template<class I>
class stride_iterator
{
  public:
    using difference_type = std::iter_difference_t<I>;

    // XXX commenting out this constructor allows the program to compile without error
    template<class OtherI>
    stride_iterator(OtherI iter, difference_type stride);

    stride_iterator& operator++();

    stride_iterator operator++(int);
};


template<class T>
concept is_signed_integer_like = std::signed_integral<T> || std::same_as<T, std::ranges::__detail::__max_diff_type>;


template<class I>
  concept weakly_incrementable =
    std::movable<I> &&
    requires(I i) {
      typename std::iter_difference_t<I>;
      requires is_signed_integer_like<std::iter_difference_t<I>>;
      { ++i } -> std::same_as<I&>;
      i++;                        
    };

int main()
{
  // XXX this static_assert compiles OK
  static_assert(weakly_incrementable<stride_iterator<int*>>);

  // XXX this static assert compiles with error
  static_assert(std::weakly_incrementable<stride_iterator<int*>>);

  return 0;
}

Causes circle to emit the error

$ circle -std=c++20 repro.cpp 
error: repro.cpp:39:3
static_assert failed
  static_assert(std::weakly_incrementable<stride_iterator<int*>>); 
  ^

error: translation aborted; too many errors

Compiler details:

$ circle --version
circle version 1.0.0-160
  Circle public preview build 160
  Built Feb 19 2022 17:49:52
  (c) 2021 Sean Baxter
  https://www.circle-lang.org/
  Twitter: @seanbax

The program

template<int>
void foo()
{
}

template<class F>
__global__ void kernel(F f)
{
  f();
}

template<class F>
void launch(F f)
{
  kernel<<<1,1>>>(f);
}

int main()
{
  constexpr int block_size = 512;

  launch([=]
  {
    foo<block_size>();
  });

  return 0;
}

Causes circle to emit the error message

$ circle --cuda-path=/usr/local/cuda -sm_60 repro.cpp -L/usr/local/cuda/lib64 -lcudart
error: void foo()
failure on overload resolution for function void foo()
  function declared at repro.cpp:2:6
repro.cpp:24:20
    foo<block_size>(); 
                   ^
  error: repro.cpp:24:9
  internal compiler error: cannot access 'this' at compile time
    class type is lambda auto() const
      foo<block_size>(); 

Compiler details:

$ circle --version
circle version 1.0.0-157
  Circle public preview build 157
  Built Feb 14 2022 18:29:10
  (c) 2021 Sean Baxter
  https://www.circle-lang.org/
  Twitter: @seanbax

The program

#include <sm_30_intrinsics.hpp>

__global__ void kernel()
{
  int mask = __activemask();
}

int main()
{
  kernel<<<1,1>>>();

  return 0;
}

Causes circle to emit the error

$ circle --cuda-path=/usr/local/cuda -sm_70 repro.cpp 
ptxas /tmp/circle-tmp-dir-hyAkRh/repro-compute-70.ptx, line 17; error   : Feature 'activemask' requires PTX ISA .version 6.2 or later
ptxas fatal   : Ptx assembly aborted due to errors
fatbinary fatal   : Could not open input file '/tmp/circle-tmp-dir-hyAkRh/repro-sm-70.cubin'
error: could not load fatbin file /tmp/circle-tmp-dir-hyAkRh/repro.fatbin

Compiler details:

$ circle --version
circle version 1.0.0-155
  Circle public preview build 155
  Built Feb  8 2022 11:15:07
  (c) 2021 Sean Baxter
  https://www.circle-lang.org/
  Twitter: @seanbax

I understand that the complaint comes from ptxas, but it's not clear to me that I've misused __activemask or how to proceed with a solution.

The code below fails to compile for me with the error memoized meta object int 'val' is not a portable type. Originally found this when trying to do something more interesting, with a @meta loop instead of a block, and a loop variable instead of @meta int val = 0. Removing one of the @meta val statements makes the error go away.

struct MyStruct {
    @meta {
        @meta int val = 0;
        void member_function() {
            @meta val;
            @meta val;
        }
    }
};

P.S. Great work on Circle! Found out about it last week. Many of the features (simple compile-time metaprogramming, single-source shaders, etc.) are things I've been wishing for in a programming language for a long time, so it's been really cool to actually be able to try some of them out.

the regular C++ code

#include <cstdio>

template < int m >
void foo() {
    printf("m: %d\n", m);
}

int main() {
    int m = 2;
    [&](){ foo<m>(); }();
    return 0;
}

should fail to compile, as m is not a constant expression, but circle experiences an internal compiler error:

  error: example.cpp:10:16
  internal compiler error: cannot access data members of closure at compile time
      [&](){ foo<m>(); }(); 
                 ^
Compiler returned: 1

Oddly enough, nvcc also dies on this code snippet and fails to emit an error message before doing so.

circle still provides a helpful error message to help diagnose the problem before it hits the ICE-- so better than nvcc in that respect!

This valid code:

struct A { void f(); };
struct B : A {};
extern void (A::*p)();
decltype(&B::f) p;

is rejected with the error

error: example.cpp:4:17
redeclaration of 'p' with a different type: void(B::*)() vs void(A::*)()
  previous declaration at example.cpp:3:13
decltype(&B::f) p; 
                ^

It looks like Circle is incorrectly using the class in which the member was named, rather than the class in which it was declared, when forming a pointer-to-member type. (For what it's worth, the Circle rule makes a lot more sense to me, and fixes a hole in the C++ access control rules, but it's not the standard rule.)

A metafunction with an 'auto' return type causes compiler error 139.

Reproducible with the following

@meta auto bad() {
    return "something";
}

Reproduced with build 131. Godbolt example: https://circle.godbolt.org/z/q48jKdc8P

Referencing the functionality for metafunctions in https://www.circle-lang.org/quickref.html

Given code that tries to brace initialize an auto variable with an empty brace, or multiple values (more than one), the compiler crashes with a segmentation fault. Reproducable with the latest build on both godbolt and locally.

Example 1:

auto a{};

Example 2:

auto a{1,2};

Attached local run inside of valgrind for context (Using the first example, the include related args are due to #124 :

~/code/circle ⵃ valgrind /opt/circle/circle --nostdinc \
-I/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/include \
-I/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/include/c++ \
-I/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/include/c++/x86_64-pc-linux-gnu main.cxx 
==49507== Memcheck, a memory error detector
==49507== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==49507== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==49507== Command: /opt/circle/circle --nostdinc -I/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/include -I/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/include/c++ -I/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/include/c++/x86_64-pc-linux-gnu main.cxx
==49507== 
==49507== Invalid read of size 4
==49507==    at 0x51B649: sema::stmt_builder_t::object_init(sema::decl_object_t*, std::unique_ptr<sema::arg_t, std::default_delete<sema::arg_t> >, source_loc_t) (in /opt/circle/circle)
==49507==    by 0x51C6B6: sema::stmt_builder_t::decl_init(sema::decl_t*, std::unique_ptr<sema::arg_t, std::default_delete<sema::arg_t> >, source_loc_t) (in /opt/circle/circle)
==49507==    by 0x812726: fe::decl_builder_t::declare_objectlike(fe::decl_builder_t::parse_t&, fe::range_t&, bool&) (in /opt/circle/circle)
==49507==    by 0x80F868: fe::decl_builder_t::process_declaration(fe::decl_builder_t::parse_t&, fe::range_t&, bool) (in /opt/circle/circle)
==49507==    by 0x80DA66: fe::decl_builder_t::regular_declarations(fe::range_t, bool) (in /opt/circle/circle)
==49507==    by 0x80820C: fe::decl_builder_t::parse(fe::range_t, bool) (in /opt/circle/circle)
==49507==    by 0x818A6B: fe::grammar_t::simple_declaration(fe::range_t, bool, llvm::SmallVector<std::unique_ptr<sema::template_header_t, std::default_delete<sema::template_header_t> >, 1u>*) (in /opt/circle/circle)
==49507==    by 0x8191AE: fe::grammar_t::declaration_statement(fe::range_t, bool, llvm::SmallVector<std::unique_ptr<sema::template_header_t, std::default_delete<sema::template_header_t> >, 1u>*) (in /opt/circle/circle)
==49507==    by 0x7F7254: fe::grammar_t::generic_statement(fe::range_t, meta_prefix_t) (in /opt/circle/circle)
==49507==    by 0x7F6EC4: fe::grammar_t::statement(fe::syntax_stmt_t*) (in /opt/circle/circle)
==49507==    by 0x7F6C8C: fe::grammar_t::statements(llvm::SmallVector<std::unique_ptr<fe::syntax_stmt_t, std::default_delete<fe::syntax_stmt_t> >, 2u>&) (in /opt/circle/circle)
==49507==    by 0x4433FF: main (in /opt/circle/circle)
==49507==  Address 0x9 is not stack'd, malloc'd or (recently) free'd
==49507== 
==49507== 
==49507== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==49507==  Access not within mapped region at address 0x9
==49507==    at 0x51B649: sema::stmt_builder_t::object_init(sema::decl_object_t*, std::unique_ptr<sema::arg_t, std::default_delete<sema::arg_t> >, source_loc_t) (in /opt/circle/circle)
==49507==    by 0x51C6B6: sema::stmt_builder_t::decl_init(sema::decl_t*, std::unique_ptr<sema::arg_t, std::default_delete<sema::arg_t> >, source_loc_t) (in /opt/circle/circle)
==49507==    by 0x812726: fe::decl_builder_t::declare_objectlike(fe::decl_builder_t::parse_t&, fe::range_t&, bool&) (in /opt/circle/circle)
==49507==    by 0x80F868: fe::decl_builder_t::process_declaration(fe::decl_builder_t::parse_t&, fe::range_t&, bool) (in /opt/circle/circle)
==49507==    by 0x80DA66: fe::decl_builder_t::regular_declarations(fe::range_t, bool) (in /opt/circle/circle)
==49507==    by 0x80820C: fe::decl_builder_t::parse(fe::range_t, bool) (in /opt/circle/circle)
==49507==    by 0x818A6B: fe::grammar_t::simple_declaration(fe::range_t, bool, llvm::SmallVector<std::unique_ptr<sema::template_header_t, std::default_delete<sema::template_header_t> >, 1u>*) (in /opt/circle/circle)
==49507==    by 0x8191AE: fe::grammar_t::declaration_statement(fe::range_t, bool, llvm::SmallVector<std::unique_ptr<sema::template_header_t, std::default_delete<sema::template_header_t> >, 1u>*) (in /opt/circle/circle)
==49507==    by 0x7F7254: fe::grammar_t::generic_statement(fe::range_t, meta_prefix_t) (in /opt/circle/circle)
==49507==    by 0x7F6EC4: fe::grammar_t::statement(fe::syntax_stmt_t*) (in /opt/circle/circle)
==49507==    by 0x7F6C8C: fe::grammar_t::statements(llvm::SmallVector<std::unique_ptr<fe::syntax_stmt_t, std::default_delete<fe::syntax_stmt_t> >, 2u>&) (in /opt/circle/circle)
==49507==    by 0x4433FF: main (in /opt/circle/circle)
==49507==  If you believe this happened as a result of a stack
==49507==  overflow in your program's main thread (unlikely but
==49507==  possible), you can try to increase the size of the
==49507==  main thread stack using the --main-stacksize= flag.
==49507==  The main thread stack size used in this run was 8388608.
==49507== 
==49507== HEAP SUMMARY:
==49507==     in use at exit: 4,370,324 bytes in 24,898 blocks
==49507==   total heap usage: 31,842 allocs, 6,944 frees, 7,369,409 bytes allocated
==49507== 
==49507== LEAK SUMMARY:
==49507==    definitely lost: 432 bytes in 3 blocks
==49507==    indirectly lost: 0 bytes in 0 blocks
==49507==      possibly lost: 4,608 bytes in 2 blocks
==49507==    still reachable: 4,365,284 bytes in 24,893 blocks
==49507==                       of which reachable via heuristic:
==49507==                         newarray           : 34,024 bytes in 5 blocks
==49507==                         multipleinheritance: 4,160 bytes in 44 blocks
==49507==         suppressed: 0 bytes in 0 blocks
==49507== Rerun with --leak-check=full to see details of leaked memory
==49507== 
==49507== For lists of detected and suppressed errors, rerun with: -s
==49507== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Segmentation fault (core dumped)

Is there a way to use @meta to generate nested for loops?

I've got a tensor class where, depending on the ranks of the tensors, the calculations require a different number of for loops to iterate over the relevant indices. This is something that is hard to do in C++, and I often end up writing a lot of different overloads for some calculations, depending on the tensor ranks (but for functions with multiple tensor arguments, each of arbitrary rank, this strategy is not feasible).

For example, the regular C++ code (intentionally unindented to emphasize how it might be generated):

int n0 = 2, n1 = 2, n2 = 2, n3 = 2;
for (int i0 = 0; i0 < n0; i0++) {
for (int i1 = 0; i1 < n1; i1++) {
for (int i2 = 0; i2 < n2; i2++) {
for (int i3 = 0; i3 < n3; i3++) {
    printf("%d, %d, %d, %d\n", i0, i1, i2, i3);
}
}
}
}

has an obvious structure: a bunch of for loops with unterminated curly braces, then the body of the nested loops, and then the closing curly braces. I tried to do this with @meta: but wasn't able to get it working.

int n0 = 2, n1 = 2, n2 = 2, n3 = 2;

// trying to use @meta to generate the nested for loops
// for (int i0 = 0; i0 < n0; i0++) {
// for (int i1 = 0; i1 < n1; i1++) {
// for (int i2 = 0; i2 < n2; i2++) {
// for (int i3 = 0; i3 < n3; i3++) {
@meta for (int d = 0; d < 4; d++) {
    for (int @("i", @string(d)) = 0; @("i", @string(d)) < @("n", @string(d)); @("i", @string(d))++) {
}

// nested for-loop body
//printf("%d, %d, %d, %d\n", i0, i1, i2, i3);

// trying to use @meta to generate the closing braces for nested for loops
// }
// }
// }
// }
@meta for (int d = 0; d < 4; d++) {
    }
}

https://godbolt.org/z/xToedcf3b

The tuple/pack features in circle (indexing, slicing, filtering) have simplified the rest of the tensor class implementation considerably, so if there is a mechanism to generate these nested loops, 95% of the implementation would disappear!

The comprehension readme makes some comparisons to Python, but doesn't state clearly a significant difference from Python. I wonder if there's a mistake or if it needs to be made more clear.

printf("%d\n", v[::-1])...;

This code prints all elements in reverse order. If the step is positive (it defaults to 1 when not specified), the begin and end indices default to 0 and -1, respectively. If the step is negative, the begin and end indices default to -1 and 0. The above slice is shorthand for v[-1:0:-1].

In python [-1:0:-1] is not all elements in reverse order.

>>> [1, 2, 3][-1:0:-1]
[3, 2]

Is [::-1] shorthand for [-1:0:-1]? Does [-1:0:-1] yield all elements in reverse order? Do "the begin and end indices default to 0 and -1, respectively" (which is not the same as Python)?

As a side note, I think the inclusion of negative indices in Python makes Python worse. It's more confusing and more difficult to debug if there are unintended negative indices. If it just crashed when there are unintended negative indices, it would be much easier to figure out what the problem is. But instead, unintended negative indices tend to not crash, and instead make strange behavior so it's difficult to figure out what's going on.

I would hope there would be an option to disable negative indices in circle.