I have a question regarding how to build a builtin type for my custom instruction. The instruction itself has a VR (RISCV vector register) type parameter. The corresponding intrinsic type is llvm_anyvector_ty. However I could not search any type to define it in TARGET_BUILTIN.

For example, in BuiltinsRISCV.def, we could find something like:

TARGET_BUILTIN(__builtin_riscv_sgcfgsatu, "vUWi", "nc", "xsgmat,64bit")

It defines return type as void and the only paramter as unsigned long. But what key word corresponds to the parameter types of RVV, like __rvv_float32m1_t?

PS: it seems RVVBuiltin provides the parsing method, but would it be possible to define them without assistance from RVVBuiltin?

Thanks!

I tried to use "V16f" as the keyword string, like

TARGET_BUILTIN(__builtin_riscv_sgmovtv, "vV4fUWi", "nc", "xsgmat,64bit")

but while compiling the following code, LLVM reports: test.c:47:29: error: passing '__rvv_float32m1_t' to parameter of incompatible type 'attribute((vector_size(16 * sizeof(float)))) float' (vector of 16 'float' values)

__rvv_float32m1_t vec_a = __riscv_vle32_v_f32m1(ptr_a, vl);
__builtin_riscv_sgmovtv(vec_a, 0xFFA);

I have some code that defines a niebloid as such:

#define FWD(...) static_cast<decltype(__VA_ARGS__)&&>(__VA_ARGS__)

namespace mylib {
    namespace detail {
        auto func(struct poison&) = delete;

        struct func_function {
            constexpr auto operator()(auto&& a) const -> decltype(func(FWD(a))) {
                return func(FWD(a));
            }
        };
    }

    inline namespace niebloid {
        inline constexpr auto func = detail::func_function{};
    }

    template<typename T>
    struct some_type {
        template<typename U>
        friend constexpr auto func(U&&) -> int {
            return 42;
        }
    };
}


int main() {
    return mylib::func(mylib::some_type<int>{});
}

Everything looks good, except for clang 16 specifically.

If we look at this conformance view, we can observe older version of clang down to clang 11 handles this code very well, and clang 17 and up also handles it quite well.

But clang 16 and only 16 seem to not be able to compile this code.

Making some_type non template or making the hidden friend non template too seems to not trigger the bug, but both options are not available for my codebase.

Now for the question. Is there a most minimally disruptive workaround I could use to make this code work with clang 16 or this compiler is inherently incompatible with niebloid like patterns?

Windows 10, Ryzen 3700x, gcc 8.1.0 (Posix, SEH-enabled)

I am building clang, llvm, and compiler-rt (the PGO tools) from source. I have downloaded the clang+llvm source for 14.0.0, and built it successfully with the following:

cmake -G "MinGW Makefiles" -DLLVM_ENABLE_PROJECTS="clang;lld;compiler-rt" -DCMAKE_BUILD_TYPE=Release -DLLVM_TARGETS_TO_BUILD=X86 ../llvm

After this, I can invoke clang, and build projects, ranging from simple "Hello, World", to a much more complex one. I am able to make use of -flto, with the addition of -fuse-ld=lld.

However, if I attempt to do ANY sort of PGO building, I fail. For example, here is the minimal example to demonstrate the problem.

Andrew@Ryzen3700x MINGW64 ~/Desktop
$ cat test.c
#include <stdio.h>

int main() {
    printf("Hello, World!");
    return 0;
}

Andrew@Ryzen3700x MINGW64 ~/Desktop
$ clang -fprofile-instr-generate test.c

Andrew@Ryzen3700x MINGW64 ~/Desktop
$ ./a.exe
Hello, World!
Andrew@Ryzen3700x MINGW64 ~/Desktop
$ llvm-profdata merge -output=test.profdata default.profraw
warning: default.profraw: malformed instrumentation profile data
error: no profile can be merged

Andrew@Ryzen3700x MINGW64 ~/Desktop
$ llvm-profdata show default.profraw
error: default.profraw: malformed instrumentation profile data: function name is empty

I am aware of many answers to this question, and none of them seem to apply. My .profraw file is not empty.

I will note that when I installed LLVM/Clang directly (not building on my own), the PGO portions DID work. However, after many hours I could not resolve linking issues regarding -flto.

I'm encountering an error while building a project using a Dockerfile on Ubuntu 20.04. The error message I'm receiving is:

(https://i.stack.imgur.com/1QLAM.png)

It seems to occur during the compilation process, but it went on, until:

(https://i.stack.imgur.com/CmY5h.png)

I suspect this error might be related to memory issues or resource constraints, as it's terminating the compiler process. Could someone please help me diagnose and resolve this issue?

I am compiling my project with clang-16 which worked fine so far, but now I am getting a segmentation fault from clang itself during compilation:

[1/2] Building CXX object CMakeFiles/reinforce_tests_all.dir/test/libreinforce/test_space_tuple.cpp.o
FAILED: CMakeFiles/reinforce_tests_all.dir/test/libreinforce/test_space_tuple.cpp.o 
/usr/bin/ccache /usr/bin/clang++ -DHAVE_CBLAS=1 -DSPDLOG_ACTIVE_LEVEL=SPDLOG_LEVEL_DEBUG -DSPDLOG_COMPILED_LIB -DSPDLOG_FMT_EXTERNAL -DXTENSOR_USE_XSIMD -I/tmp/reinforce/src/libreinforce/include -I/tmp/reinforce/test/shared_test_utils -isystem /home/root/conan_cache/p/pcg-c4aa2cafcf36e3/p/include -isystem /home/root/conan_cache/p/range0301bf3d76d5d/p/include -isystem /home/root/conan_cache/p/b/fmted8c40f5dd02d/p/include -isystem /home/root/conan_cache/p/xtens8c3f32033d144/p/include -isystem /home/root/conan_cache/p/xtl7161fe009dc21/p/include -isystem /home/root/conan_cache/p/nlohm0567ffc90cfc1/p/include -isystem /home/root/conan_cache/p/xsimd7b0628df207bb/p/include -isystem /home/root/conan_cache/p/b/spdlo0e2ce77e2e884/p/include -isystem /home/root/conan_cache/p/froze7ac551bf2fb61/p/include -isystem /tmp/reinforce/cmake-build-debug-docker-clang-reinforce/_deps/xtensor-python-src/include -isystem /home/root/conan_cache/p/pybin895b9560d7d3f/p/include -isystem /usr/include/python3.10 -isystem /usr/local/lib/python3.10/dist-packages/numpy/core/include -isystem /tmp/reinforce/cmake-build-debug-docker-clang-reinforce/_deps/xtensor-blas-src/include -isystem /home/root/conan_cache/p/b/gtest79f180a2a4833/p/include -g -std=gnu++20 -fcolor-diagnostics -g3 -ftemplate-backtrace-limit=0 -flto -funroll-loops -Wall -Wextra -Wshadow -Wnon-virtual-dtor -Wold-style-cast -Wcast-align -Wunused -Woverloaded-virtual -Wpedantic -Wconversion -Wsign-conversion -Wnull-dereference -Wdouble-promotion -Wformat=2 -Winvalid-pch -Xclang -include-pch -Xclang /tmp/reinforce/cmake-build-debug-docker-clang-reinforce/CMakeFiles/reinforce_tests_all.dir/cmake_pch.hxx.pch -Xclang -include -Xclang /tmp/reinforce/cmake-build-debug-docker-clang-reinforce/CMakeFiles/reinforce_tests_all.dir/cmake_pch.hxx -MD -MT CMakeFiles/reinforce_tests_all.dir/test/libreinforce/test_space_tuple.cpp.o -MF CMakeFiles/reinforce_tests_all.dir/test/libreinforce/test_space_tuple.cpp.o.d -o CMakeFiles/reinforce_tests_all.dir/test/libreinforce/test_space_tuple.cpp.o -c /tmp/reinforce/test/libreinforce/test_space_tuple.cpp
Segmentation fault
ninja: build stopped: subcommand failed.

There is no stacktrace or any other further info on where or how this happens so I am a little lost. Compiling with -v (verbose mode) doesn't add any further info except for the exact run command

Run Build Command(s): /usr/bin/ninja -v reinforce_tests_all
[1/2] /usr/bin/ccache /usr/bin/clang++ -DHAVE_CBLAS=1 -DSPDLOG_ACTIVE_LEVEL=SPDLOG_LEVEL_DEBUG -DSPDLOG_COMPILED_LIB -DSPDLOG_FMT_EXTERNAL -DXTENSOR_USE_XSIMD -I/tmp/reinforce/src/libreinforce/include -I/tmp/reinforce/test/shared_test_utils -isystem /home/root/conan_cache/p/pcg-c4aa2cafcf36e3/p/include -isystem /home/root/conan_cache/p/range0301bf3d76d5d/p/include -isystem /home/root/conan_cache/p/b/fmted8c40f5dd02d/p/include -isystem /home/root/conan_cache/p/xtens8c3f32033d144/p/include -isystem /home/root/conan_cache/p/xtl7161fe009dc21/p/include -isystem /home/root/conan_cache/p/nlohm0567ffc90cfc1/p/include -isystem /home/root/conan_cache/p/xsimd7b0628df207bb/p/include -isystem /home/root/conan_cache/p/b/spdlo0e2ce77e2e884/p/include -isystem /home/root/conan_cache/p/froze7ac551bf2fb61/p/include -isystem /tmp/reinforce/cmake-build-debug-docker-clang-reinforce/_deps/xtensor-python-src/include -isystem /home/root/conan_cache/p/pybin895b9560d7d3f/p/include -isystem /usr/include/python3.10 -isystem /usr/local/lib/python3.10/dist-packages/numpy/core/include -isystem /tmp/reinforce/cmake-build-debug-docker-clang-reinforce/_deps/xtensor-blas-src/include -isystem /home/root/conan_cache/p/b/gtest79f180a2a4833/p/include -g -std=gnu++20 -fcolor-diagnostics -g3 -ftemplate-backtrace-limit=0 -flto -funroll-loops -Wall -Wextra -Wshadow -Wnon-virtual-dtor -Wold-style-cast -Wcast-align -Wunused -Woverloaded-virtual -Wpedantic -Wconversion -Wsign-conversion -Wnull-dereference -Wdouble-promotion -Wformat=2 -Winvalid-pch -Xclang -include-pch -Xclang /tmp/reinforce/cmake-build-debug-docker-clang-reinforce/CMakeFiles/reinforce_tests_all.dir/cmake_pch.hxx.pch -Xclang -include -Xclang /tmp/reinforce/cmake-build-debug-docker-clang-reinforce/CMakeFiles/reinforce_tests_all.dir/cmake_pch.hxx -MD -MT CMakeFiles/reinforce_tests_all.dir/test/libreinforce/test_space_tuple.cpp.o -MF CMakeFiles/reinforce_tests_all.dir/test/libreinforce/test_space_tuple.cpp.o.d -o CMakeFiles/reinforce_tests_all.dir/test/libreinforce/test_space_tuple.cpp.o -c /tmp/reinforce/test/libreinforce/test_space_tuple.cpp
FAILED: CMakeFiles/reinforce_tests_all.dir/test/libreinforce/test_space_tuple.cpp.o
/usr/bin/ccache /usr/bin/clang++ -DHAVE_CBLAS=1 -DSPDLOG_ACTIVE_LEVEL=SPDLOG_LEVEL_DEBUG -DSPDLOG_COMPILED_LIB -DSPDLOG_FMT_EXTERNAL -DXTENSOR_USE_XSIMD -I/tmp/reinforce/src/libreinforce/include -I/tmp/reinforce/test/shared_test_utils -isystem /home/root/conan_cache/p/pcg-c4aa2cafcf36e3/p/include -isystem /home/root/conan_cache/p/range0301bf3d76d5d/p/include -isystem /home/root/conan_cache/p/b/fmted8c40f5dd02d/p/include -isystem /home/root/conan_cache/p/xtens8c3f32033d144/p/include -isystem /home/root/conan_cache/p/xtl7161fe009dc21/p/include -isystem /home/root/conan_cache/p/nlohm0567ffc90cfc1/p/include -isystem /home/root/conan_cache/p/xsimd7b0628df207bb/p/include -isystem /home/root/conan_cache/p/b/spdlo0e2ce77e2e884/p/include -isystem /home/root/conan_cache/p/froze7ac551bf2fb61/p/include -isystem /tmp/reinforce/cmake-build-debug-docker-clang-reinforce/_deps/xtensor-python-src/include -isystem /home/root/conan_cache/p/pybin895b9560d7d3f/p/include -isystem /usr/include/python3.10 -isystem /usr/local/lib/python3.10/dist-packages/numpy/core/include -isystem /tmp/reinforce/cmake-build-debug-docker-clang-reinforce/_deps/xtensor-blas-src/include -isystem /home/root/conan_cache/p/b/gtest79f180a2a4833/p/include -g -std=gnu++20 -fcolor-diagnostics -g3 -ftemplate-backtrace-limit=0 -flto -funroll-loops -Wall -Wextra -Wshadow -Wnon-virtual-dtor -Wold-style-cast -Wcast-align -Wunused -Woverloaded-virtual -Wpedantic -Wconversion -Wsign-conversion -Wnull-dereference -Wdouble-promotion -Wformat=2 -Winvalid-pch -Xclang -include-pch -Xclang /tmp/reinforce/cmake-build-debug-docker-clang-reinforce/CMakeFiles/reinforce_tests_all.dir/cmake_pch.hxx.pch -Xclang -include -Xclang /tmp/reinforce/cmake-build-debug-docker-clang-reinforce/CMakeFiles/reinforce_tests_all.dir/cmake_pch.hxx -MD -MT CMakeFiles/reinforce_tests_all.dir/test/libreinforce/test_space_tuple.cpp.o -MF CMakeFiles/reinforce_tests_all.dir/test/libreinforce/test_space_tuple.cpp.o.d -o CMakeFiles/reinforce_tests_all.dir/test/libreinforce/test_space_tuple.cpp.o -c /tmp/reinforce/test/libreinforce/test_space_tuple.cpp
Segmentation fault
ninja: build stopped: subcommand failed.

I would expect clang to throw the stacktrace or other info on this, so I am actually unsure if this is even clang's or potentially ninja's segfault?

I'm interested in putting an opening brace for functions (but not if statements and other contexts). For example

void foo()
{
   ...
}

Flamewars aside, is there a good rationale for not doing this? Although I use same-line open-brackets for if/else and smaller blocks, I think in this case visual organization of larger units of code (functions/methods/classes/structs) can trump perfect consistency.

Moreover, how do I get clang-format to follow this style?

I want to debug C code in a Swiftpackage during unit testing. The test runs successfully, but the breakpoint in main.c is inactive. I set a breakpoint, but the message is:

The `Package.swift:

// swift-tools-version: 5.8
// The swift-tools-version declares the minimum version of Swift required to build this package.

import PackageDescription

let package = Package(
    name: "Foo",
    platforms: [.macOS(.v13)],
    products: [
        .executable(
            name: "hello",
            targets: ["HelloWorld"])
    ],
    dependencies: [
        // Dependencies declare other packages that this package depends on.
        // .package(url: /* package url */, from: "1.0.0"),
    ],
    targets: [
        // Targets are the basic building blocks of a package. A target can define a module or a test suite.
        // Targets can depend on other targets in this package, and on products in packages this package depends on.
        .target(
            name: "Foo",
            dependencies: []),
        .executableTarget(
            name: "HelloWorld",
            dependencies: [],
            path: "Sources/HelloWorld",
            publicHeadersPath: ".",
            cSettings: [
                .headerSearchPath("./"),
                .unsafeFlags(["-std=c11","-g"])]),
        .testTarget(
            name: "FooTests",
            dependencies: ["Foo"]),
    ]
)

How can I change the setting so main.c can be debugged? I'm not sure if it's a setting in Xcode Scheme or a thing inSwift.package.

Code is here: https://gitlab.com/ms152718212/testspmccodedebug.git

Given a known constant static function pointer such as:

#include <stdio.h>
static int (* const puts_ptr)(char const*) = &puts;

I would like to use inline assembly with puts_ptr as an input to generate jmp puts.

This:

#include <stdio.h>
 static int (* const puts_ptr)(char const*) = &puts;
void callputs(char const*X){ 
    __asm volatile ("jmp %c0\n" : : "i"(puts_ptr));
    __builtin_unreachable();
 }

works, with the i (immediate) constraint and the c (print without a dollar sign) modifier works on GCC, but doesn't compile on clang.

Is there a clang version of this?

https://godbolt.org/z/vsbWEbsqT

What is the proper way to set up a clang compiler to use in vs code ? why is it error when i compile it and say

"clang++: warning: unable to find a Visual Studio installation; try running Clang from a developer command prompt [-Wmsvc-not-found]
crudc.cpp:1:10: fatal error: 'iostream' file not found
#include <iostream>
         ^~~~~~~~~~
1 error generated." ? 

and how can i change the code runner from g++ to clang++ ?. I'll show my setting the next picture I tried to change my setting but it still error