# clang Published articles for clang. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## How fast is C++23's std::flat\_map? DevFeed: [How fast is C++23's std::flat\_map?]() Original publisher: [Read original article]() Author: Daniel Lemire Published: 2026-09-16T20:26:36Z Content type: article Language: en Sources: [Daniel Lemire]() Topics: [Data structures](), [Library](), [gcc](), [LLVM](), [clang]() Tags: [array](), [arrays](), [clang](), [gcc](), [llvm](), [overhead](), [speed](), [standard-library]() ### AI overview This article benchmarks C++23's std::flat_map, a sorted container backed by parallel arrays of keys and values. It explains serialization and loading considerations, then compares insertion and lookup performance with std::map. Random-order insertion becomes quadratic as the container grows, while increasing-order or bulk insertion is much faster; random lookups can also be faster for large maps because std::flat_map uses less memory. ### Source excerpt C++23 added a new type to the standard library: std::flat_map. There is also a std::flat_set and other variants, but let me focus on std::flat_map. A flat map is a sorted vector of keys next to a vector of values. A query is a binary search over the sorted keys. You need a recent standard library: ... Continue reading How fast is C++23's std::flat_map? ## C++-техрадар: что разработчики действительно готовы брать в работу DevFeed: [C++-техрадар: что разработчики действительно готовы брать в работу]() Original publisher: [Read original article]() Author: Kaspersky\_Lab ("Лаборатория Касперского") Published: 2026-08-07T13:17:24Z Content type: article Language: ru Sources: ["Лаборатория Касперского" RU]() Topics: [C++](), [CMake](), [PostgreSQL]() Tags: [bash](), [bazel](), [c-plus-plus](), [clang](), [cmake](), [gdb](), [git](), [plus-plus-3a0baa67a2fc](), [postgresql](), [tech-radar](), [vs-code]() ### AI overview The article analyzes the C++ portion of a technical radar based on survey responses from developers at C++ Russia and HolyJS. It explains how technologies are assessed across Adopt, Trial, Assess, and Hold categories, emphasizing that the overall distribution of votes matters more than a single dominant response. The supplied evidence specifically notes CMake as a strong performer and PostgreSQL as dividing respondents. ### Source excerpt В мае на конференциях C++ Russia и HolyJS мы предложили участникам оценить технологии, инструменты и инженерные практики, с которыми они работают или за которыми следят. Так появились данные для двух технических радаров: по экосистеме C++ и по JavaScript. Сырые цифры сами по себе рассказывают немного, поэтому мы отдали результаты на разбор эксперту. Виктор Новиков, руководитель группы разработки в "Лаборатории Касперского", посмотрел на распределения голосов и поделился своим мнением, почему CMake уверенно побеждает, а PostgreSQL раскалывает аудиторию пополам. В этой статье -- его анализ C++-части исследования. Про техрадар JavaScript мы расскажем в другой статье. Посмотреть радар и принять участие в голосовании можно на странице проекта. Читать далее ## C++ libraries linking DevFeed: [C++ libraries linking]() Original publisher: [Read original article]() Author: Nenad Rakocevic (noreply@blogger.com) Published: 2026-07-29T19:07:38Z Content type: release Language: en Sources: [Red]() Topics: [Red](), [C++](), [toolchain]() Tags: [build](), [build-tools](), [c-plus-plus](), [clang](), [compilation](), [directx](), [gcc](), [libraries](), [linux](), [macos](), [msvc](), [static-linking](), [toolchain](), [windows](), [x86]() ### AI overview The Red toolchain now supports statically linking C++ libraries, including their runtime, on Windows, Linux, and macOS. It accepts libraries built with MSVC, GCC, or clang through the existing import system and compilation switch, with platform-specific prerequisites and constraints. ### Source excerpt When we introduced static linking of C libraries, the promise was simple: name a .lib or .a archive in your #import, compile with -s, and ship one self-contained executable, no DLLs riding along, nothing to install on the target machine. There was one big frontier left, and everyone saw it coming: the libraries people want most (vision, GUI, audio, machine learning) are written in C++. A C++ library is a very different animal to link: it brings global constructors, exceptions, RTTI, templates, thread-local storage, and an entire language runtime that expects to be wired up just so. Until now, that was the line where you switched back to DLLs. That line is gone. The Red toolchain now statically links C++ libraries too (their runtime included) on every platform Red targets: Windows, Linux (x86 and ARM), and macOS. The best part: nothing changes. It is the same import system and same compilation switch: red -r -s myapp.red Libraries built with MSVC, GCC or clang are all accepted, in their native object formats. What you need preinstalled ➤ Windows: for C++ libraries (or C code built against Microsoft's static runtime), install the free Visual Studio Build Tools with the "Desktop development with C++" workload. Just one installer, and Red locates everything by itself: no vcvarsall, no PATH, no environment variables. Plain C libraries still need nothing at all and that now extends to C libraries touching COM, DirectX or MediaFoundation: the GUID constants such code references ship inside the toolchain, so a fresh Windows 11 with only red-toolchain executable on it links them! ➤ Linux: the GNU runtime archives from your distribution's gcc packages (libstdc++.a, libgcc.a and friends) placed next to your library. If one is missing, the linker names exactly what it needs. ➤ macOS: nothing beyond the toolchain; the system C++ runtime binds automatically. Some constraints 32-bit libraries for now, until the 64-bit toolchain is ready. The imported surface must be C (extern "C", ## Optimizing LLVM's bump allocator DevFeed: [Optimizing LLVM's bump allocator]() Original publisher: [Read original article]() Published: 2026-06-28T07:00:00Z Content type: article Language: en Sources: [MaskRay]() Topics: [LLVM](), [clang]() Tags: [changes](), [clang](), [codegen](), [debug](), [llvm](), [memory](), [optimizing](), [performance]() ### AI overview This article explains three recent changes that optimize LLVM's BumpPtrAllocator: avoiding unnecessary realignment, using a sentinel to eliminate a null check, and removing per-allocation accounting from the hot path. It also discusses alignment, typed allocation, incomplete types, and ABI considerations. ### Source excerpt BumpPtrAllocator is LLVM's bump allocator (arena allocator): each allocation bumps a pointer within a slab, and everything is freed at once when the allocator dies. It backs Clang's ASTContext, lld's make object pools, TableGen records, and many other arenas. Here is the fast path before three recent changes: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 __attribute__((returns_nonnull)) void *Allocate(size_t Size, Align Alignment) { BytesAllocated += Size; // (3) accounting RMW uintptr_t AlignedPtr = alignAddr(CurPtr, Alignment); // (1) always realign size_t SizeToAllocate = Size; #if LLVM_ADDRESS_SANITIZER_BUILD SizeToAllocate += RedZoneSize; #endif uintptr_t AllocEndPtr = AlignedPtr + SizeToAllocate; if (LLVM_LIKELY(AllocEndPtr <= uintptr_t(End) && CurPtr != nullptr)) { // (2) bound + null check CurPtr = reinterpret_cast(AllocEndPtr); ... return reinterpret_cast(AlignedPtr); } return AllocateSlow(Size, SizeToAllocate, Alignment); } ## A deep dive into SmallVector::push\_back DevFeed: [A deep dive into SmallVector::push\_back]() Original publisher: [Read original article]() Published: 2026-06-27T07:00:00Z Content type: article Language: en Sources: [MaskRay]() Topics: [LLVM](), [Optimization](), [Compiler](), [clang](), [Assembly](), [gcc]() Tags: [assembly](), [clang](), [codegen](), [compiler](), [gcc](), [llvm](), [optimization](), [performance]() ### AI overview This article examines an LLVM SmallVector::push_back optimization for approximately trivially copyable element types. It explains how tail-calling the slow growth path reduces the fast path from 14 to 7 instructions and avoids callee-saved registers, while noting tradeoffs for out-of-line calls and overall build size. ### Source excerpt tl;dr This blog post describes a recent SmallVector::push_back optimization for approximately trivially copyable element types. SmallVector is LLVM's most-used container, and push_back its hot operation. For the trivially-copyable specialization the fast path should be fast. 1 2 3 #include void f(llvm::SmallVectorImpl &v, int x) { v.push_back(x); } clang -S --target=x86_64 -O2 -DNDEBUG a.cc generates: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 push rbp # callee-saved spills + a stack realignment, push rbx # all on the fast path push rax mov eax, [rdi + 8] # size cmp eax, [rdi + 12] # vs capacity jae .Lgrow .Lstore: # reached from the fast path AND from .Lgrow mov rcx, [rdi] mov [rcx + rax*4], esi inc dword ptr [rdi + 8] add rsp, 8 pop rbx pop rbp ret .Lgrow: mov rbx, rdi # keep `this`/`x` alive across the call mov ebp, esi call SmallVectorBase::grow_pod ... jmp .Lstore ## 【eBPF 内核实现深度拆解】从验证器到 JIT，从 BTF 到调度器 DevFeed: [【eBPF 内核实现深度拆解】从验证器到 JIT，从 BTF 到调度器]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-06-12T00:00:00Z Content type: article Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [eBPF](), [Linux](), [JIT](), [Benchmark](), [clang](), [hash](), [benchmarking](), [RISC-V](), [ast-matchers]() Tags: [arm](), [array](), [benchmark](), [bpf-jit](), [bpf-maps](), [bpf-verifier](), [btf](), [clang](), [co-re](), [cpu](), [ebpf](), [fentry](), [hash](), [jit](), [kernel](), [libbpf](), [linux](), [linux-kernel](), [precision](), [risc-v](), [sched-ext](), [trampoline](), [x86](), [xdp]() ### AI overview This Chinese-language series systematically explains eBPF's Linux kernel implementation, covering the BPF instruction set and registers, verifier algorithms, JIT compilation, map data structures and concurrency, helper type checking, BTF and CO-RE relocation, libbpf loading, trampolines, and sched_ext interfaces. It is aimed at engineers who want to understand eBPF kernel source code and build production BPF programs. ### Source excerpt eBPF 内核虚拟机内部实现系统讲解：BPF 指令集与寄存器机器、验证器的抽象解释与状态裁剪、JIT 编译器后端、Map 各类型的并发与内存模型、helper 函数注册与类型检查、BTF 格式规范与 CO-RE 重定位引擎、libbpf 加载器工程、fentry/fexit 蹦床机制、sched_ext 调度器内核接口。面向想读懂 eBPF 内核源码、写生产级 BPF 程序的系统工程师。 ## Fighting Hyrum's Law in LLVM DevFeed: [Fighting Hyrum's Law in LLVM]() Original publisher: [Read original article]() Published: 2026-05-10T07:00:00Z Content type: article Language: en Sources: [MaskRay]() Topics: [LLVM](), [Compiler](), [reproducible builds](), [hash]() Tags: [clang](), [compiler](), [hash](), [lld](), [llvm](), [reproducible-builds](), [test]() ### AI overview This article examines how LLVM can develop dependencies on unspecified or incidental behavior under Hyrum's Law, causing output variation that harms reproducible builds, bisection, and bug reports. It describes hash-seed perturbation, reverse container iteration, and iterator invalidation checks as mechanisms for exposing such dependencies. ### Source excerpt With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody. -- Hyrum's Law In a compiler, the most common form of Hyrum's Law is dependence on unspecified behavior -- hash bucket order, the order of equal elements after std::sort, padding offsets. The same framing covers a few cases that are technically undefined behavior (use of an invalidated iterator) or plain incidental properties (ABI struct layout, ELF section offsets). When the compiler itself harbors such a dependency, the symptom is usually output that varies build-to-build: an unstable sort that lands differently after the standard library changes, a hash map whose iteration order shifts when the hash function does. Occasionally the variation is run-to-run within a single build -- DenseMap keys with an ASLR-derived seed reorder buckets each invocation. Either way, reproducible builds, bisection, and bug reports all assume same input -> same output, and a stealth Hyrum dependency breaks that. This post surveys some mechanisms that perturb the contract's blind spots so dependencies cannot quietly form. ## Recent lld/ELF performance improvements DevFeed: [Recent lld/ELF performance improvements]() Original publisher: [Read original article]() Published: 2026-04-12T07:00:00Z Content type: article Language: en Sources: [MaskRay]() Topics: [LLVM](), [Benchmark](), [benchmarking](), [clang](), [Chromium]() Tags: [2026](), [benchmark](), [chromium](), [clang](), [gc](), [gdb](), [improvements](), [linker](), [lld](), [llvm](), [macos](), [overhead](), [patches](), [performance]() ### AI overview This article reports LLVM lld/ELF linker performance improvements from parallelizing link phases and reducing task-runtime overhead. Benchmarks show a 1.34x speedup over lld 22.1 for a Release+Asserts clang link and a 1.09x speedup for a Chromium debug link, while mold and wild remain faster in the comparisons described. ### Source excerpt Updated in 2026-05. Since the LLVM 22 branch was cut, I've landed patches that parallelize more link phases and cut task-runtime overhead. This post compares current main against lld 22.1, mold, and wild. Headline: a Release+Asserts clang --gc-sections link is 1.34x as fast as lld 22.1; Chromium debug with --gdb-index is 1.09x as fast. mold and wild are still ahead -- the last section explains why. ## Bit-field layout DevFeed: [Bit-field layout]() Original publisher: [Read original article]() Published: 2026-02-22T08:00:00Z Content type: tutorial Language: en Sources: [MaskRay]() Topics: [implementation](), [C](), [C++](), [Compiler](), [clang](), [gcc](), [LLVM](), [MSVC]() Tags: [c](), [c-plus-plus](), [clang](), [codegen](), [compiler](), [compiler-optimization](), [gcc](), [implementation](), [llvm](), [msvc]() ### AI overview This article explains how C and C++ bit-field layout is implementation-defined and governed primarily by platform ABIs. It distinguishes ABI-defined storage layout from compiler code generation, focusing on the Itanium ABI and describing differences in the Microsoft ABI. ### Source excerpt The C and C++ standards leave nearly every detail to the implementation. C23 §6.7.3.2: An implementation may allocate any addressable storage unit large enough to hold a bit-field. If enough space remains, a bit-field that immediately follows another bit-field in a structure shall be packed into adjacent bits of the same unit. If insufficient space remains, whether a bit-field that does not fit is put into the next unit or overlaps adjacent units is implementation-defined. The order of allocation of bit-fields within a unit (high-order to low-order or low-order to high-order) is implementation-defined. The alignment of the addressable storage unit is unspecified C++ is also terse -- [class.bit]p1: Allocation of bit-fields within a class object is implementation-defined. Alignment of bit-fields is implementation-defined. Bit-fields are packed into some addressable allocation unit. ## Unsigned char std::basic\_string\<\> in C++ DevFeed: [Unsigned char std::basic\_string\<\> in C++]() Original publisher: [Read original article]() Published: 2026-01-03T22:00:02Z Content type: tutorial Language: en Sources: [Bert Hubert's writings]() Topics: [C++](), [standard](), [LLVM](), [clang](), [gcc]() Tags: [bits](), [c-plus-plus](), [clang](), [concatenation](), [cryptographic](), [freebsd](), [gcc](), [llvm](), [openbsd](), [standard](), [string]() ### AI overview A C++ post explains why code using std::basic_string can fail on FreeBSD and OpenBSD. The issue involves std::char_traits: LLVM 19 removed its unconstrained base template because the C++ Standard does not require it for unsigned-character types. Code may need string concatenation and related operations replaced or a correct custom specialization provided. ### Source excerpt Brief post on a somewhat vexing and irritating C++ problem I ran into some time ago. I hope that this page will help other people deal with this problem more quickly than I did. I've long used std::basic_string, an unsigned char string, for fiddling with bits. You could use a regular char string, but especially when doing cryptographic or sub-byte operations, it is more convenient to not have to deal with sign bits. ## Understanding Apple Debug Info DevFeed: [Understanding Apple Debug Info]() Original publisher: [Read original article]() Author: Keith Smiley Published: 2025-09-21T17:00:00Z Content type: tutorial Language: en Sources: [Keith Smiley]() Topics: [debugging](), [Xcode](), [C](), [Linux]() Tags: [apple](), [binaries](), [build](), [c](), [clang](), [compiler](), [debug](), [debugging](), [ios](), [llvm](), [macos](), [xcode]() ### AI overview This article explains how debug information works for Apple platforms and Mach-O binaries, contrasting the approach with Linux ELF binaries. It shows how compiler-generated debug metadata is stored in intermediate object files and located by lldb, then introduces issues that can arise in complex or distributed Bazel builds, including invalid absolute paths. ### Source excerpt Apple platforms (macOS, iOS, etc), and specifically Mach-O binaries, have a slightly different approach to debug info than ELF binaries for Linux. If you are familiar with Xcode, you might have seen a few related settings that control what is produced and wondered what the trade-offs are. The goal of this post is to help you debug cases where these differences lead to a degraded debugging experience in lldb so that you can fix them. If you have a particularly complex build, potentially managed by Bazel1 or another tool, especially if you are using distributed builds, you are even more likely to hit issues. Let's dive in to how the pieces fit together. A brief explanation of debug info Debug info is metadata produced by the compiler that is consumed by debuggers (like lldb), profilers, and other tools. It is used to map runtime information, like addresses, function arguments, and stack traces, back to the source that was used to produce the binary. Without this information debugging in lldb shows primarily raw instructions and addresses, which is rarely acceptable for common debugging workflows. Inspecting debug info When building for Apple platforms debug info isn't contained in the final binary (this is the primary difference from the default Linux workflows). Instead the binary contains references to the files where lldb can find it (this is conceptually similar to if you use -gsplit-dwarf on Linux). Let's inspect some binaries to see what this really means. First we create a small binary: $ cat main.c int main() { return 0; } $ clang main.c -g -c -o main.o $ clang main.o -o main If we attempt to inspect the debug info contained in main, we find nothing: $ dwarfdump main # use llvm-dwarfdump if not on macOS main: file format Mach-O arm64 .debug_info contents: However when we debug this binary in lldb, you will correctly see the source file and line number information: $ lldb -- main (lldb) target create "main" Current executable set to '/tmp/demo/main' (arm64). (l ## Performance of the Python 3.14 tail-call interpreter DevFeed: [Performance of the Python 3.14 tail-call interpreter]() Original publisher: [Read original article]() Author: Nelson Elhage Published: 2025-03-09T22:00:00Z Content type: article Language: en Sources: [Nelson Elhage]() Topics: [Python 3.14](), [benchmarking](), [gcc](), [LLVM](), [Software Engineering]() Tags: [benchmark](), [benchmarking](), [benchmarks](), [bytecode](), [clang](), [compilers](), [cpu](), [gcc](), [intel](), [llvm](), [performance](), [performance-engineering](), [python](), [python-3-14](), [software-engineering]() ### AI overview This article examines the performance gains attributed to CPython's Python 3.14 tail-call bytecode interpreter. It finds that the initial 10-15% improvement was primarily caused by inadvertently working around an LLVM 19 regression; with better baselines, the gain is closer to 1-5%, depending on the setup. ### Source excerpt About a month ago, the CPython project merged a new implementation strategy for their bytecode interpreter. The initial headline results were very impressive, showing a 10-15% performance improvement on average across a wide range of benchmarks across a variety of platforms. Unfortunately, as I will document in this post, these impressive performance gains turned out to be primarily due to inadvertently working around a regression in LLVM 19. When benchmarked against a better baseline (such GCC, clang-18, or LLVM 19 with certain tuning flags), the performance gain drops to 1-5% or so depending on the exact setup. ## Bazel caching and compressed debug info DevFeed: [Bazel caching and compressed debug info]() Original publisher: [Read original article]() Author: Keith Smiley Published: 2025-02-14T18:00:00Z Content type: tutorial Language: en Sources: [Keith Smiley]() Topics: [C++](), [Caching](), [LLVM](), [gcc](), [C]() Tags: [bazel](), [build](), [c-plus-plus](), [caching](), [clang](), [cmake](), [config](), [configuration]() ### AI overview This article explains how compressing debug information can reduce C and C++ binary sizes and improve Bazel remote-cache efficiency. Using llvm-objcopy, the example reduces a roughly 536 MB binary to about 290 MB, and the authors report nearly 60% fewer cache reads after deployment. ### Source excerpt One of bazel's most attractive features is the ability for it to remotely cache artifacts to reduce unnecessary work for large builds. Unfortunately users quickly discover this comes with non-trivial financial and bandwidth implications. There are many ways, of varying difficulty, to try and improve your cache usage. From breaking unnecessary dependencies, to adding larger local storage for CI workers, builds without the bytes, build avoidance, etc. For codebases with lots of C or C++ one of the potentially easiest wins is to enable compressed debug information1. Let's look at an example from our codebase. Looking at the size of a non-trivial C++ binary built with -g -O2 (similar to cmake's RelWithDebInfo configuration), or binary clocks in at ~530mbs: % du -sh bin 536M bin To get a sense of what percentage of this binary is debug info, we can use llvm-objcopy to strip the debug info entirely: % llvm-objcopy --strip-debug bin strippedbin % du -sh strippedbin 159M strippedbin This shows us that almost 70%(!!) of the binary size is taken up with debug info. In release configurations we can eliminate this entirely with bazel's --strip argument, but for developer builds, or other use cases where you need debug info, we can still improve this. If we use llvm-objcopy again, this time to compress the debug info, we can immediately see our potential gains: % llvm-objcopy --compress-debug-sections bin compressedbin % du -sh compressedbin 290M compressedbin This shows us we can get an almost 50%(!!) improvement in binary size in this example. To enable this in bazel, assuming you're using a relatively recent version of gcc or clang, you can add something like this to your .bazelrc2: build --enable_platform_specific_config build:linux --copt=-gz --host_copt=-gz build:linux --linkopt=-gz --host_linkopt=-gz In practice we saw cache reads drop by nearly 60% when we rolled out this change. Reducing binary size with this approach has a lot of benefits, but it's even more pronounced ## C++ exception performance three years later DevFeed: [C++ exception performance three years later]() Original publisher: [Read original article]() Author: Thomas Neumann (noreply@blogger.com) Published: 2024-12-10T14:44:00Z Content type: article Language: en Sources: [Database Architects]() Topics: [C++](), [Exception](), [Scalability](), [gcc](), [JIT](), [LLVM]() Tags: [benchmark](), [c-plus-plus](), [clang](), [exception](), [gcc](), [glibc](), [jit](), [llvm](), [performance](), [series]() ### AI overview The article reviews improvements to C++ exception unwinding performance. Lock-free lookup mechanisms in glibc and libgcc improve scalability for statically generated and JIT-generated code, although clang's implementation may still have scaling limitations. ### Source excerpt About three years ago we noticed serious performance problems in C++ exception unwinding. Due to contention on the unwinding path these became more and more severe the more cores a system had, and unwinding could slow down by orders of magnitude. Due to the constraints of backwards compatibility this contention was not easy to eliminate, and P2544 discussed ways to fix this problem via language changes in C++. But fortunately people found less invasive solutions. First, Florian Weimer changed the glibc to provide a lock-free mechanism to find the (static) unwind tables for a given shared object. Which eliminates the most serious contention for "simple" C++ programs. For example in a micro-benchmark that calls a function with some computations (100 calls to sqrt per function invocation), and which throws with a certain probability, we previously had very poor scalability with increasing core count. With his patch we now see with gcc 14.2 on a dual-socket EPYC 7713 the following performance development (runtime in ms): 1 2 4 8 16 32 64 128 threads 0% failure 29 29 29 29 29 29 29 42 0.1% failure 29 29 29 29 29 29 29 32 1% failure 29 30 30 30 30 30 32 34 10% failure 36 36 37 37 37 37 47 65 Which is more or less perfect. 128 threads are a bit slower, but that is to be expected as one EPYC only has 64 cores. With higher failure rates unwinding itself becomes slower but that is still acceptable here. Thus most C++ programs are just fine. For our use case that is not enough, though. We dynamically generate machine code at runtime, and we want to be able to pass exceptions through generated code. The _dl_find_object mechanism of glibc is not used for JITed code, instead libgcc maintains its own lookup structure. Historically this was a simple list with a global lock, which of course had terrible performance. But through a series of patches we managed to change libgcc into using a lock-free b-tree for maintaining the dynamic unwinding frames. Using a similar experiment to the ## Espressif-IDE v3.0.0 -- LSP Support for C/C++ Editor DevFeed: [Espressif-IDE v3.0.0 -- LSP Support for C/C++ Editor]() Original publisher: [Read original article]() Author: John Lee Published: 2024-06-28T00:00:00Z Content type: release Language: en Sources: [Blog on Developer Portal]() Topics: [Espressif IDE](), [ide](), [C++](), [C](), [ESP-IDF](), [LLVM](), [cross-platform](), [Release notes](), [ESP32](), [ESP32-P4]() Tags: [blog](), [c](), [c-plus-plus](), [clang](), [cross-platform](), [eclipse](), [esp-idf](), [esp32](), [esp32-p4](), [espressif-ide](), [gcc](), [ide](), [llvm](), [news](), [release]() ### AI overview Espressif-IDE v3.0.0 is a cross-platform integrated development environment update for Espressif chip development. It introduces Eclipse CDT-LSP plugins for newer C/C++ standards and a C/C++ editor powered by LLVM clangd for ESP-IDF developers. ### Source excerpt This article briefly covers the most important features introduced in Espressif-IDE v3.0.0 and some of their implementation details. If you have further improvement ideas or if you encounter any issues while using Espressif-IDE, do not hesitate to report them in the project's GitHub issues. ## Thread Count Scaling Part 2. Blender and Clang DevFeed: [Thread Count Scaling Part 2. Blender and Clang]() Original publisher: [Read original article]() Author: Denis Bakhvalov Published: 2024-05-10T04:00:00Z Content type: article Language: en Sources: [Denis Bakhvalov]() Topics: [Benchmark](), [benchmarking](), [Concurrency](), [C++](), [Processes]() Tags: [benchmark](), [blender](), [book-chapters](), [c-plus-plus](), [clang](), [compilation](), [concurrency](), [floating-point](), [parallel](), [parallelism](), [performance](), [performance-analysis](), [process](), [scale](), [thread](), [threads]() ### AI overview This article examines thread-count scaling in Blender and Clang. Blender scales across the available threads because its rendering workload is highly parallelizable, but scaling declines as E-cores and SMT sibling threads are used. Clang compilation is also massively parallel, though its scaling is affected by cache and branch behavior, core differences, SMT, and frequency throttling. ### Source excerpt Subscribe to my newsletter, support me on Patreon, Github, or by PayPal donation. This blog is an excerpt from the book. More details in the introduction. Blender is the only benchmark in our suite that continues to scale up to all 16 threads in the system. The reason for this is that the workload is highly parallelizable. The rendering process is divided into small tiles, and each tile can be rendered independently. However, even with this high level of parallelism, the scaling is only . ## Accelerate Your IoT Development with the Espressif WebIDE DevFeed: [Accelerate Your IoT Development with the Espressif WebIDE]() Original publisher: [Read original article]() Author: John Lee Published: 2023-04-17T00:00:00Z Content type: tutorial Language: en Sources: [Blog on Developer Portal]() Topics: [Espressif](), [Internet of things](), [ESP-IDF](), [ide](), [Visual Studio Code](), [Framework](), [Website](), [Web](), [Open Source](), [Docker](), [TypeScript](), [Docker Container]() Tags: [blog](), [browser](), [c-c-plus-plus](), [clang](), [docker](), [eclipse-theia](), [esp-idf](), [esp32](), [espressif](), [esptool](), [ide](), [iot](), [json](), [open-source](), [python](), [qemu](), [theia](), [typescript](), [visual-studio-code](), [web]() ### AI overview This tutorial introduces the Espressif Web IDE, an Eclipse Theia-based IDE that integrates the ESP-IDF extension for Visual Studio Code with additional tools. It explains how to run the IDE from source or in Docker, connect to ESP chip serial ports, flash and monitor devices, and use C/C++ language features. ### Source excerpt The Espressif Web IDE is an implementation of the Eclipse Theia framework with the ESP-IDF extension for Visual Studio Code and few additional tools. You can see it in action in the Espressif DevCon22 presentation below. If you haven't used Eclipse Theia before, it is an open-source framework to develop Cloud & Desktop IDEs and tools in TypeScript with a Visual Studio Code UI and Visual Studio Code extensions support or extensions implemented in the OpenVSX registry. ## Auto linking with Mach-O binaries DevFeed: [Auto linking with Mach-O binaries]() Original publisher: [Read original article]() Author: Keith Smiley Published: 2022-02-24T02:00:00Z Content type: tutorial Language: en Sources: [Keith Smiley]() Topics: [Objective-C](), [Swift](), [toolchain]() Tags: [assembly](), [clang](), [objective-c](), [swift]() ### AI overview This article explains automatic linking for Mach-O binaries. It shows how Objective-C compilation can embed linker options for dependencies such as Foundation, how to inspect those options, and how omitting module support causes explicit linking to be required. It also covers module maps, Swift standard-library dependencies, and several ways to add linker options manually with clang, swiftc, or assembly directives. ### Source excerpt Auto linking is a feature that embeds information in your binaries' at compile time which is then used at link time to automatically link your dependencies. This allows you to reduce the duplication of flags between the different phases of your (or your consumers') builds. For example, with this Objective-C file: #include int main() { NSLog(@"Hello, World!"); return 1; } Compiled with: $ clang -fmodules -c foo.m -o foo.o You can then inspect the options added for use at link time: $ otool -l foo.o | grep LC_LINKER_OPTION -A3 cmd LC_LINKER_OPTION cmdsize 40 count 2 string #1 -framework string #2 Foundation ... Now when linking this binary you don't have to pass any extra flags to the linker to make sure you link Foundation: $ ld foo.o -syslibroot `xcrun --show-sdk-path` To compare, if you compile the binary without -fmodules1: $ clang -c foo.m -o foo.o You don't get any LC_LINKER_OPTIONs. Then when linking the binary with the same command as before, it fails with these errors: $ ld foo.o -syslibroot `xcrun --show-sdk-path` Undefined symbols for architecture arm64: "_NSLog", referenced from: _main in foo.o "___CFConstantStringClassReference", referenced from: CFString in foo.o ld: symbol(s) not found for architecture arm64 To make it succeed you must explicitly link Foundation through an argument to your linker invocation: $ ld foo.o -syslibroot `xcrun --show-sdk-path` -framework Foundation Auto linking is also applied when using module maps that use the link directive. For example with this module map file: // module.modulemap module foo { link "foo" link framework "Foundation" } That you include with in this source file: @import foo; int main() { return 1; } And compile (with an include path to the module.modulemap file): $ clang -fmodules -c foo.m -o foo.o -I. The produced object depends on foo and Foundation. This can be useful for handwriting module map files for prebuilt libraries, and for quite a few other cases. You can read about thi ## Reproducible codesigning on Apple Silicon DevFeed: [Reproducible codesigning on Apple Silicon]() Original publisher: [Read original article]() Author: Keith Smiley Published: 2021-10-06T03:00:00Z Content type: article Language: en Sources: [Keith Smiley]() Topics: [Arm](), [x86](), [C](), [Command-line interface](), [toolchain](), [Open Source]() Tags: [apple](), [architecture](), [arm](), [binaries](), [c](), [clang](), [code](), [command-line](), [identifier](), [open-source](), [reproducible-builds](), [signing](), [source](), [x86]() ### AI overview The article explains why codesigning universal macOS binaries can produce different results on Apple Silicon and Intel Macs, despite the binaries being identical before signing. It traces the issue through Apple's open-source code and identifies architecture-dependent UUID handling as the cause of non-reproducible codesigning. ### Source excerpt For people who expect reproducible builds, Apple Silicon machines provide an interesting challenge. Apple Silicon requires arm64 binaries, including command line tools you build yourself, be codesigned. This change is mostly transparent to developers, because Apple updated their linker to automatically ad-hoc sign binaries1. Unfortunately, if you're interested in producing binaries that support both Intel Macs and Apple Silicon Macs, you likely want to produce a fat binary. When codesigning this binary you hit some behavior that depends on your current machine's architecture. Example You can consistently produce the same result across multiple machines when compiling a binary without signing it. Here's an example with a simple C program: $ echo "int main() { return 0; }" > main.c $ clang main.c -Wl,-no_adhoc_codesign -arch arm64 -arch x86_64 -o main $ shasum main 113033b3d9a247210b49a476bbfadb2e347846fe main The shasum of main should always be the same regardless of your host machine2. On Apple Silicon machines you can see this binary has the same sha1 even if you run clang under Rosetta 23: $ arch -x86_64 clang main.c -Wl,-no_adhoc_codesign -arch arm64 -arch x86_64 -o main $ shasum main 113033b3d9a247210b49a476bbfadb2e347846fe main The issue is introduced when you codesign the binary on Apple Silicon machines versus Intel machines. You can immediately see the difference3: $ codesign --force --sign - main $ shasum main 84631e812bd480c306766ba03a728dd2565dd672 main % arch -x86_64 codesign --force --sign - main % shasum main f631b6c0daf3ffd0bb5f65d19fa045acf447a72d main We get closer to identifying the problem when you compare the details of these differences: $ codesign --force --sign - main $ codesign -dvvv main > arm.txt 2>&1 $ arch -x86_64 codesign --force --sign - main $ codesign -dvvv main > intel.txt 2>&1 $ diff -Nur intel.txt arm.txt --- intel.txt 2021-10-05 21:26:32.731918710 -0700 +++ arm.txt 2021-10-05 21:26:29.473702845 -0700 @@ -1,14 +1,14 @@ Executable=/ ## ReactOS in 2020 DevFeed: [ReactOS in 2020]() Original publisher: [Read original article]() Published: 2021-01-02T00:00:00Z Content type: article Language: en Sources: [Front Page on ReactOS Website]() Topics: [ReactOS](), [Kernel](), [build tools](), [CMake](), [Filesystems](), [gcc](), [Shell](), [clang](), [Command-line interface](), [MSVC](), [GitHub]() Tags: [c-plus-plus](), [ci](), [clang](), [cmake](), [command-line](), [filesystem](), [free](), [gcc](), [github](), [kernel](), [msvc](), [open-source](), [os](), [react](), [reactos](), [shell](), [tooling](), [upgrade](), [win32](), [winapi]() ### AI overview A 2020 retrospective on ReactOS reports bug fixes, new instabilities, full-time kernel hires, shell improvements, RAPPS application-manager enhancements, and upgrades to its compiler and build tooling. It covers GCC 8.4, CMake 3.17, restored Clang CI builds, reduced older MSVC support, and a move to the C99 standard. ### Source excerpt Despite all the turbulence, it has been quite a productive year for ReactOS. Many bugs and instabilities were resolved, many more have been introduced. This year we hired two kernel developers full-time, this happened for the first time in the project's history. The post highlights some of the changes which may be interesting to the community. Shell changes Shell hasn't seen much attention recently, due to most of the work being concentrated in the kernel, but there are still some useful fixes and feature implementations: ## On GitHub Actions with MSYS2 DevFeed: [On GitHub Actions with MSYS2]() Original publisher: [Read original article]() Published: 2020-08-01T03:33:31Z Content type: tutorial Language: en Sources: [Ariya Hidayat]() Topics: [GitHub Actions](), [CI/CD](), [C](), [gcc](), [GitHub](), [toolchain](), [Windows](), [Shell]() Tags: [architecture](), [c](), [clang](), [compilers](), [continuous-integration](), [gcc](), [github](), [github-actions](), [toolchains](), [windows](), [yaml]() ### AI overview A practical guide to using GitHub Actions with MSYS2 to build an ANSI C program on Windows. It shows configurations for GCC and Clang, then uses matrix parameters to cover both i686 and AMD64 architectures. ### Source excerpt Thanks to the complete GitHub Actions for MSYS2, it is easier than ever to construct a continuous integration setup for building with compilers and toolchains which can run on MSYS2. ## Smarter C/C++ inlining with \_\_attribute\_\_((flatten)) DevFeed: [Smarter C/C++ inlining with \_\_attribute\_\_((flatten))]() Original publisher: [Read original article]() Author: Andreas Kling Published: 2020-04-27T00:00:00Z Content type: tutorial Language: en Sources: [Andreas Kling]() Topics: [inlining](), [c/c++](), [Optimization](), [clang](), [gcc](), [build times]() Tags: [build-times](), [c-c-plus-plus](), [clang](), [compiler](), [cpp](), [function](), [gcc](), [inlining](), [optimization](), [performance](), [technical]() ### AI overview This post explains how to use the __attribute__((flatten)) function attribute in C/C++ to apply aggressive inlining selectively. GCC and Clang support the attribute, which inlines a function's callees while limiting the program-size, cache-locality, and build-time costs of broader inlining. ### Source excerpt This post describes a compile-time technique for getting the benefits of aggressive inlining in hot code while protecting cool code from its downsides. ## Clang on Windows DevFeed: [Clang on Windows]() Original publisher: [Read original article]() Published: 2020-01-05T22:46:09Z Content type: tutorial Language: en Sources: [Ariya Hidayat]() Topics: [c/c++](), [Windows](), [Package manager](), [make](), [Azure](), [CI/CD]() Tags: [azure](), [build](), [c](), [c-plus-plus](), [cache](), [clang](), [continuous-integration](), [make](), [pacman](), [windows]() ### AI overview A tutorial on using MSYS2 to install and run Clang on Windows for building 32-bit and 64-bit C/C++ applications. It also describes integrating the toolchain with Azure Pipelines and caching downloaded packages. ### Source excerpt Thanks to the MSYS2 project, now there is an easy way to utilize Clang to build C/C++ application on Windows. This works equally well for both 32-bit and 64-bit programs. ## Kotlin/Native (Stranger) Threads - Kevin Galligan DevFeed: [Kotlin/Native (Stranger) Threads - Kevin Galligan]() Original publisher: [Read original article]() Published: 2018-05-11T20:31:45Z Content type: tutorial Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [kotlin-native](), [Concurrency](), [Concurrent Programming](), [CLion](), [clang]() Tags: [clang](), [clion](), [code-sharing](), [concurrency](), [kotlin](), [kotlin-multiplatform](), [kotlin-native](), [thoughts](), [threading](), [threads]() ### AI overview The first chapter of a series on threading in Kotlin/Native introduces its thread and state model, recommends CLion for experimentation, and guides readers through creating and running a Kotlin/Native HelloWorld project. It previews Workers, data passing, and data freezing. ### Source excerpt This is going to be a multi-part series on threading in Kotlin Native. To build a reasonably functional product, understanding threads is critical. [Next page]()