# clang

Clang is a C, C++, and Objective-C compiler and language front end for LLVM.

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?](<https://devfeed.tech/articles/how-fast-is-c-23-s-std-flat-map-31465.md>)

Original publisher: [Read original article](<https://lemire.me/blog/2026/09/16/how-fast-is-c23s-stdflat_map/>)

Author: Daniel Lemire

Published: 2026-09-16T20:26:36Z

Content type: article

Language: en

Sources: [Daniel Lemire](<https://devfeed.tech/sources/daniel-lemire.md>)

Topics: [Data structures](<https://devfeed.tech/topics/data-structures.md>), [Library](<https://devfeed.tech/topics/library.md>), [gcc](<https://devfeed.tech/topics/gcc.md>), [LLVM](<https://devfeed.tech/topics/llvm.md>), [clang](<https://devfeed.tech/topics/clang.md>)

Tags: [array](<https://devfeed.tech/tags/array.md>), [arrays](<https://devfeed.tech/tags/arrays.md>), [clang](<https://devfeed.tech/tags/clang.md>), [gcc](<https://devfeed.tech/tags/gcc.md>), [llvm](<https://devfeed.tech/tags/llvm.md>), [overhead](<https://devfeed.tech/tags/overhead.md>), [speed](<https://devfeed.tech/tags/speed.md>), [standard-library](<https://devfeed.tech/tags/standard-library.md>)

### 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?

## Optimizing LLVM's bump allocator

DevFeed: [Optimizing LLVM's bump allocator](<https://devfeed.tech/articles/optimizing-llvm-s-bump-allocator-31134.md>)

Original publisher: [Read original article](<https://maskray.me/blog/optimizing-llvm-bump-allocator>)

Published: 2026-06-28T07:00:00Z

Content type: article

Language: en

Sources: [MaskRay](<https://devfeed.tech/sources/maskray.md>)

Topics: [LLVM](<https://devfeed.tech/topics/llvm.md>), [clang](<https://devfeed.tech/topics/clang.md>)

Tags: [changes](<https://devfeed.tech/tags/changes.md>), [clang](<https://devfeed.tech/tags/clang.md>), [codegen](<https://devfeed.tech/tags/codegen.md>), [debug](<https://devfeed.tech/tags/debug.md>), [llvm](<https://devfeed.tech/tags/llvm.md>), [memory](<https://devfeed.tech/tags/memory.md>), [optimizing](<https://devfeed.tech/tags/optimizing.md>), [performance](<https://devfeed.tech/tags/performance.md>)

### 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<T> 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<char *>(AllocEndPtr); ... return reinterpret_cast<char *>(AlignedPtr); } return AllocateSlow(Size, SizeToAllocate, Alignment); }

## A deep dive into SmallVector::push\_back

DevFeed: [A deep dive into SmallVector::push\_back](<https://devfeed.tech/articles/a-deep-dive-into-smallvector-push-back-31123.md>)

Original publisher: [Read original article](<https://maskray.me/blog/a-deep-dive-into-smallvector-push-back>)

Published: 2026-06-27T07:00:00Z

Content type: article

Language: en

Sources: [MaskRay](<https://devfeed.tech/sources/maskray.md>)

Topics: [LLVM](<https://devfeed.tech/topics/llvm.md>), [Optimization](<https://devfeed.tech/topics/optimization.md>), [Compiler](<https://devfeed.tech/topics/compiler.md>), [clang](<https://devfeed.tech/topics/clang.md>), [Assembly](<https://devfeed.tech/topics/assembly.md>), [gcc](<https://devfeed.tech/topics/gcc.md>)

Tags: [assembly](<https://devfeed.tech/tags/assembly.md>), [clang](<https://devfeed.tech/tags/clang.md>), [codegen](<https://devfeed.tech/tags/codegen.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [gcc](<https://devfeed.tech/tags/gcc.md>), [llvm](<https://devfeed.tech/tags/llvm.md>), [optimization](<https://devfeed.tech/tags/optimization.md>), [performance](<https://devfeed.tech/tags/performance.md>)

### 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 <llvm/ADT/SmallVector.h> void f(llvm::SmallVectorImpl<int> &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<unsigned>::grow_pod ... jmp .Lstore

## 【eBPF 内核实现深度拆解】从验证器到 JIT，从 BTF 到调度器

DevFeed: [【eBPF 内核实现深度拆解】从验证器到 JIT，从 BTF 到调度器](<https://devfeed.tech/articles/ebpf-jit-btf-33982.md>)

Original publisher: [Read original article](<https://quant67.com/post/ebpf/index.html>)

Author: Liao Tonglang

Published: 2026-06-12T00:00:00Z

Content type: article

Language: zh

Sources: [土法炼钢 - 系统与基础设施](<https://devfeed.tech/sources/source-4.md>)

Topics: [eBPF](<https://devfeed.tech/topics/ebpf.md>), [Linux](<https://devfeed.tech/topics/linux.md>), [JIT](<https://devfeed.tech/topics/jit.md>), [Benchmark](<https://devfeed.tech/topics/benchmark.md>), [clang](<https://devfeed.tech/topics/clang.md>), [hash](<https://devfeed.tech/topics/hash.md>), [benchmarking](<https://devfeed.tech/topics/benchmarking.md>), [RISC-V](<https://devfeed.tech/topics/riscv.md>), [ast-matchers](<https://devfeed.tech/topics/ast-matchers.md>)

Tags: [arm](<https://devfeed.tech/tags/arm.md>), [array](<https://devfeed.tech/tags/array.md>), [benchmark](<https://devfeed.tech/tags/benchmark.md>), [bpf-jit](<https://devfeed.tech/tags/bpf-jit.md>), [bpf-maps](<https://devfeed.tech/tags/bpf-maps.md>), [bpf-verifier](<https://devfeed.tech/tags/bpf-verifier.md>), [btf](<https://devfeed.tech/tags/btf.md>), [clang](<https://devfeed.tech/tags/clang.md>), [co-re](<https://devfeed.tech/tags/co-re.md>), [cpu](<https://devfeed.tech/tags/cpu.md>), [ebpf](<https://devfeed.tech/tags/ebpf.md>), [fentry](<https://devfeed.tech/tags/fentry.md>), [hash](<https://devfeed.tech/tags/hash.md>), [jit](<https://devfeed.tech/tags/jit.md>), [kernel](<https://devfeed.tech/tags/kernel.md>), [libbpf](<https://devfeed.tech/tags/libbpf.md>), [linux](<https://devfeed.tech/tags/linux.md>), [linux-kernel](<https://devfeed.tech/tags/linux-kernel.md>), [precision](<https://devfeed.tech/tags/precision.md>), [risc-v](<https://devfeed.tech/tags/risc-v.md>), [sched-ext](<https://devfeed.tech/tags/sched-ext.md>), [trampoline](<https://devfeed.tech/tags/trampoline.md>), [x86](<https://devfeed.tech/tags/x86.md>), [xdp](<https://devfeed.tech/tags/xdp.md>)

### 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 程序的系统工程师。

## Recent lld/ELF performance improvements

DevFeed: [Recent lld/ELF performance improvements](<https://devfeed.tech/articles/recent-lld-elf-performance-improvements-31121.md>)

Original publisher: [Read original article](<https://maskray.me/blog/2026-04-12-recent-lld-elf-performance-improvements>)

Published: 2026-04-12T07:00:00Z

Content type: article

Language: en

Sources: [MaskRay](<https://devfeed.tech/sources/maskray.md>)

Topics: [LLVM](<https://devfeed.tech/topics/llvm.md>), [Benchmark](<https://devfeed.tech/topics/benchmark.md>), [benchmarking](<https://devfeed.tech/topics/benchmarking.md>), [clang](<https://devfeed.tech/topics/clang.md>), [Chromium](<https://devfeed.tech/topics/chromium.md>)

Tags: [2026](<https://devfeed.tech/tags/2026.md>), [benchmark](<https://devfeed.tech/tags/benchmark.md>), [chromium](<https://devfeed.tech/tags/chromium.md>), [clang](<https://devfeed.tech/tags/clang.md>), [gc](<https://devfeed.tech/tags/gc.md>), [gdb](<https://devfeed.tech/tags/gdb.md>), [improvements](<https://devfeed.tech/tags/improvements.md>), [linker](<https://devfeed.tech/tags/linker.md>), [lld](<https://devfeed.tech/tags/lld.md>), [llvm](<https://devfeed.tech/tags/llvm.md>), [macos](<https://devfeed.tech/tags/macos.md>), [overhead](<https://devfeed.tech/tags/overhead.md>), [patches](<https://devfeed.tech/tags/patches.md>), [performance](<https://devfeed.tech/tags/performance.md>)

### 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](<https://devfeed.tech/articles/bit-field-layout-31124.md>)

Original publisher: [Read original article](<https://maskray.me/blog/bit-field-layout>)

Published: 2026-02-22T08:00:00Z

Content type: tutorial

Language: en

Sources: [MaskRay](<https://devfeed.tech/sources/maskray.md>)

Topics: [implementation](<https://devfeed.tech/topics/implementation.md>), [C](<https://devfeed.tech/topics/c.md>), [C++](<https://devfeed.tech/topics/c-plus-plus.md>), [Compiler](<https://devfeed.tech/topics/compiler.md>), [clang](<https://devfeed.tech/topics/clang.md>), [gcc](<https://devfeed.tech/topics/gcc.md>), [LLVM](<https://devfeed.tech/topics/llvm.md>), [MSVC](<https://devfeed.tech/topics/msvc.md>)

Tags: [c](<https://devfeed.tech/tags/c.md>), [c-plus-plus](<https://devfeed.tech/tags/c-plus-plus.md>), [clang](<https://devfeed.tech/tags/clang.md>), [codegen](<https://devfeed.tech/tags/codegen.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [compiler-optimization](<https://devfeed.tech/tags/compiler-optimization.md>), [gcc](<https://devfeed.tech/tags/gcc.md>), [implementation](<https://devfeed.tech/tags/implementation.md>), [llvm](<https://devfeed.tech/tags/llvm.md>), [msvc](<https://devfeed.tech/tags/msvc.md>)

### 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.

## ReactOS in 2020

DevFeed: [ReactOS in 2020](<https://devfeed.tech/articles/reactos-in-2020-33215.md>)

Original publisher: [Read original article](<https://reactos.org/project-news/reactos-in-2020/>)

Published: 2021-01-02T00:00:00Z

Content type: article

Language: en

Sources: [Front Page on ReactOS Website](<https://devfeed.tech/sources/front-page-on-reactos-website.md>)

Topics: [ReactOS](<https://devfeed.tech/topics/reactos.md>), [Kernel](<https://devfeed.tech/topics/kernel.md>), [build tools](<https://devfeed.tech/topics/build-tools.md>), [CMake](<https://devfeed.tech/topics/cmake.md>), [Filesystems](<https://devfeed.tech/topics/filesystems.md>), [gcc](<https://devfeed.tech/topics/gcc.md>), [Shell](<https://devfeed.tech/topics/shell.md>), [clang](<https://devfeed.tech/topics/clang.md>), [Command-line interface](<https://devfeed.tech/topics/cli.md>), [MSVC](<https://devfeed.tech/topics/msvc.md>), [GitHub](<https://devfeed.tech/topics/github.md>)

Tags: [c-plus-plus](<https://devfeed.tech/tags/c-plus-plus.md>), [ci](<https://devfeed.tech/tags/ci.md>), [clang](<https://devfeed.tech/tags/clang.md>), [cmake](<https://devfeed.tech/tags/cmake.md>), [command-line](<https://devfeed.tech/tags/command-line.md>), [filesystem](<https://devfeed.tech/tags/filesystem.md>), [free](<https://devfeed.tech/tags/free.md>), [gcc](<https://devfeed.tech/tags/gcc.md>), [github](<https://devfeed.tech/tags/github.md>), [kernel](<https://devfeed.tech/tags/kernel.md>), [msvc](<https://devfeed.tech/tags/msvc.md>), [open-source](<https://devfeed.tech/tags/open-source.md>), [os](<https://devfeed.tech/tags/os.md>), [react](<https://devfeed.tech/tags/react.md>), [reactos](<https://devfeed.tech/tags/reactos.md>), [shell](<https://devfeed.tech/tags/shell.md>), [tooling](<https://devfeed.tech/tags/tooling.md>), [upgrade](<https://devfeed.tech/tags/upgrade.md>), [win32](<https://devfeed.tech/tags/win32.md>), [winapi](<https://devfeed.tech/tags/winapi.md>)

### 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:

## Smarter C/C++ inlining with \_\_attribute\_\_((flatten))

DevFeed: [Smarter C/C++ inlining with \_\_attribute\_\_((flatten))](<https://devfeed.tech/articles/smarter-c-c-inlining-with-attribute-flatten-38362.md>)

Original publisher: [Read original article](<https://awesomekling.github.io/Smarter-C++-inlining-with-attribute-flatten/>)

Author: Andreas Kling

Published: 2020-04-27T00:00:00Z

Content type: tutorial

Language: en

Sources: [Andreas Kling](<https://devfeed.tech/sources/andreas-kling.md>)

Topics: [inlining](<https://devfeed.tech/topics/inlining.md>), [c/c++](<https://devfeed.tech/topics/c-c-plus-plus.md>), [Optimization](<https://devfeed.tech/topics/optimization.md>), [clang](<https://devfeed.tech/topics/clang.md>), [gcc](<https://devfeed.tech/topics/gcc.md>), [build times](<https://devfeed.tech/topics/build-times.md>)

Tags: [build-times](<https://devfeed.tech/tags/build-times.md>), [c-c-plus-plus](<https://devfeed.tech/tags/c-c-plus-plus.md>), [clang](<https://devfeed.tech/tags/clang.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [cpp](<https://devfeed.tech/tags/cpp.md>), [function](<https://devfeed.tech/tags/function.md>), [gcc](<https://devfeed.tech/tags/gcc.md>), [inlining](<https://devfeed.tech/tags/inlining.md>), [optimization](<https://devfeed.tech/tags/optimization.md>), [performance](<https://devfeed.tech/tags/performance.md>), [technical](<https://devfeed.tech/tags/technical.md>)

### 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.

## A Minimal LLDB Guide for Investigating Crashes

DevFeed: [A Minimal LLDB Guide for Investigating Crashes](<https://devfeed.tech/articles/i-don-t-really-want-to-learn-lldb-i-just-want-to-fix-a-crash-35552.md>)

Original publisher: [Read original article](<https://meowni.ca/posts/unscary-lldb/>)

Author: Monica Dinculescu

Published: 2014-06-23T00:00:00Z

Content type: tutorial

Language: en

Sources: [Monica Dinculescu](<https://devfeed.tech/sources/monica-dinculescu.md>)

Topics: [debugging](<https://devfeed.tech/topics/debugging.md>), [Tooling](<https://devfeed.tech/topics/tooling.md>), [clang](<https://devfeed.tech/topics/clang.md>), [gdb](<https://devfeed.tech/topics/gdb.md>), [Chromium](<https://devfeed.tech/topics/chromium.md>)

Tags: [breakpoint](<https://devfeed.tech/tags/breakpoint.md>), [chromium](<https://devfeed.tech/tags/chromium.md>), [clang](<https://devfeed.tech/tags/clang.md>), [commands](<https://devfeed.tech/tags/commands.md>), [crash](<https://devfeed.tech/tags/crash.md>), [debugging](<https://devfeed.tech/tags/debugging.md>), [gdb](<https://devfeed.tech/tags/gdb.md>), [tutorials](<https://devfeed.tech/tags/tutorials.md>)

### AI overview

A concise tutorial on using LLDB to investigate program crashes. It covers launching an executable, reproducing a crash, reading a stack trace, and setting breakpoints, with Chromium debugging examples.

### Source excerpt

lldb stands for Llama-DB, and is a database of llamas you can use to debug programs compiled with clang (lldb is to clang like gdb is to gcc). If you already know how to use gdb, then here's a translation of the common commands. Disclaimer: There is a ton of tutorials and pages about all of the awesome features and commands of lldb, and how to become a debugging pro. This is not that. This is the smallest set of things you need to read to answer the question "what's making this shit crash". That's it. Step 1. Make it go If you want to pass a bunch of arguments to your executable moose, use (´ ▽｀).。ｏ♡ src on fix/moose-crash ☀ ❥ lldb -- moose arg1 arg2 Current executable set to 'moose' (x86_64). If you don't have arguments, lldb foo is enough. This just tells lldb which executable to care about, but it won't actually start the process for you. (lldb) run --> Start or re-start your process (lldb) exit --> Stop your process. Step 2. Make it crash Since we (me) are investigating a crash, the first thing you need is a stack trace that tells you where the crash is. So, start your process in lldb, make it crash, and we'll take it from there. Side bar: I literally typed this blog out while sorting out a crash in the sign-in bits of Chromium, so all my screenshots are Chromium code. Do not panic. Your code can crash just as well if you give it enough time and attention. Once you hit your crash, lldb tells you something like this. I can't tell you how excited I am at that little arrow. It almost looks non-intimidating. Almost. Step 3. Breakpoints! It's hammer time The first thing I did was set a breakpoint at that line to figure out what's going on right before things got crashy (because I'm sure you're dying to know, my crash was happening because we hit that DCHECK which reads "the item should always be signed in" and, spoilers, it isn't) To set a breakpoint in a file at a specific line: (lldb) breakpoint set --file profile_chooser_controller.mm --line 1509 Awesome discovery

## Breaking Kryptonite's obfuscation: a static analysis approach relying on symbolic execution

DevFeed: [Breaking Kryptonite's obfuscation: a static analysis approach relying on symbolic execution](<https://devfeed.tech/articles/breaking-kryptonite-s-obfuscation-a-static-analysis-approach-relying-on-symbolic-execution-39691.md>)

Original publisher: [Read original article](<https://doar-e.github.io/blog/2013/09/16/breaking-kryptonites-obfuscation-with-symbolic-execution/>)

Author: Axel "0vercl0k" Souchet

Published: 2013-09-16T18:47:00Z

Content type: tutorial

Language: en

Sources: [Diary of a reverse-engineer](<https://devfeed.tech/sources/diary-of-a-reverse-engineer.md>)

Topics: [obfuscation](<https://devfeed.tech/topics/obfuscation.md>), [execution](<https://devfeed.tech/topics/execution.md>), [LLVM](<https://devfeed.tech/topics/llvm.md>), [clang](<https://devfeed.tech/topics/clang.md>), [Assembly](<https://devfeed.tech/topics/assembly.md>), [x86](<https://devfeed.tech/topics/x86.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [analysis](<https://devfeed.tech/tags/analysis.md>), [asm](<https://devfeed.tech/tags/asm.md>), [assembly](<https://devfeed.tech/tags/assembly.md>), [clang](<https://devfeed.tech/tags/clang.md>), [code](<https://devfeed.tech/tags/code.md>), [llvm](<https://devfeed.tech/tags/llvm.md>), [obfuscation](<https://devfeed.tech/tags/obfuscation.md>), [reverse-engineering](<https://devfeed.tech/tags/reverse-engineering.md>), [static](<https://devfeed.tech/tags/static.md>), [symbolic-execution](<https://devfeed.tech/tags/symbolic-execution.md>), [x86](<https://devfeed.tech/tags/x86.md>)

### AI overview

This tutorial demonstrates how symbolic execution can break Kryptonite, a proof-of-concept obfuscator that applies semantics-preserving transformations at the LLVM intermediate representation level. It describes a small symbolic execution engine built with IDAPy and Z3Py, using an x86 binary generated from LLVM code for a 32-bit adder.

### Source excerpt

Introduction Kryptonite was a proof-of-concept I built to obfuscate codes at the LLVM intermediate representation level. The idea was to use semantic-preserving transformations in order to not break the original program. One of the main idea was for example to build a home-made 32 bits adder to replace the add ...

## Clang now builds Postgres without additional warnings

DevFeed: [Clang now builds Postgres without additional warnings](<https://devfeed.tech/articles/clang-now-builds-postgres-without-additional-warnings-33640.md>)

Original publisher: [Read original article](<https://pgeoghegan.blogspot.com/2011/08/clang-now-builds-postgres-without.html>)

Author: Peter Geoghegan (noreply@blogger.com)

Published: 2011-08-06T20:14:00Z

Content type: opinion

Language: en

Sources: [Peter Geoghegan's blog](<https://devfeed.tech/sources/peter-geoghegan-s-blog.md>)

Topics: [clang](<https://devfeed.tech/topics/clang.md>), [PostgreSQL](<https://devfeed.tech/topics/postgresql.md>), [bug](<https://devfeed.tech/topics/bug.md>), [gcc](<https://devfeed.tech/topics/gcc.md>)

Tags: [bug](<https://devfeed.tech/tags/bug.md>), [c](<https://devfeed.tech/tags/c.md>), [c-plus-plus](<https://devfeed.tech/tags/c-plus-plus.md>), [clang](<https://devfeed.tech/tags/clang.md>), [enum](<https://devfeed.tech/tags/enum.md>), [gcc](<https://devfeed.tech/tags/gcc.md>), [postgres](<https://devfeed.tech/tags/postgres.md>), [postgresql](<https://devfeed.tech/tags/postgresql.md>)

### AI overview

The article reports that Clang can build PostgreSQL without additional warnings beyond one warning also produced by GCC. It describes how Clang's diagnostic context helped reveal a potentially dangerous enum-type misuse in PostgreSQL code and notes fixes for other spurious warnings.

### Source excerpt

I'm happy to report that as of this evening, Clang builds PostgreSQL without any warnings, apart from a single remaining warning that also occurs when building with GCC, which is actually a bug in GNU Flex that the Flex developers don't seem to want to fix. On GCC 4.6, the warning looks like this: In file included from gram.y:12962:0: scan.c: In function 'yy_try_NUL_trans': scan.c:16246:23: warning: unused variable 'yyg' [-Wunused-variable] With Clang, however, it looks like this: scan.c:16246:23: warning: unused variable 'yyg' [-Wunused-variable] struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; /* This var may be unused depending upon options. */ ^ Note that the "^" is directly underneath the offending variable "yyg" on the terminal emulator that generated this warning. Note also that Clang usefully gives the context of the warning, and as a result a comment is displayed that suggests that the warning is spurious. The Clang developers finally committed a fix to remove spurious warnings that occured when building Postgres as a result of it being statically detected that there are assignments past what appears to be the end of a single element array at the end of a struct. That doesn't happen now, although only under circumstances exactly consistent with the use of a popular idiom that is seen quite a bit in the Postgres code. In working towards removing all Clang warnings, we detected a bug; we were assigning an enum constant from one enum to a variable that was actually another type of enum, which represented a potentially dangerous misuse of an abstraction that the Postgres code uses to represent nodes. This all occurred within a nested macro. Without Clang, it probably would have taken a long time for the problem to be noticed.

## Could Clang displace GCC generally? Part II: Performance of PostgreSQL binaries

DevFeed: [Could Clang displace GCC generally? Part II: Performance of PostgreSQL binaries](<https://devfeed.tech/articles/could-clang-displace-gcc-generally-part-ii-performance-of-postgresql-binaries-33639.md>)

Original publisher: [Read original article](<https://pgeoghegan.blogspot.com/2011/07/could-clang-displace-gcc-generally-part.html>)

Author: Peter Geoghegan (noreply@blogger.com)

Published: 2011-07-28T16:12:00Z

Content type: article

Language: en

Sources: [Peter Geoghegan's blog](<https://devfeed.tech/sources/peter-geoghegan-s-blog.md>)

Topics: [clang](<https://devfeed.tech/topics/clang.md>), [gcc](<https://devfeed.tech/topics/gcc.md>), [PostgreSQL](<https://devfeed.tech/topics/postgresql.md>), [Benchmark](<https://devfeed.tech/topics/benchmark.md>), [cpu](<https://devfeed.tech/topics/cpu.md>), [Compiler](<https://devfeed.tech/topics/compiler.md>)

Tags: [benchmark](<https://devfeed.tech/tags/benchmark.md>), [c](<https://devfeed.tech/tags/c.md>), [c-plus-plus](<https://devfeed.tech/tags/c-plus-plus.md>), [clang](<https://devfeed.tech/tags/clang.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [cpu](<https://devfeed.tech/tags/cpu.md>), [gcc](<https://devfeed.tech/tags/gcc.md>), [performance](<https://devfeed.tech/tags/performance.md>), [postgresql](<https://devfeed.tech/tags/postgresql.md>)

### AI overview

This second article in a two-part series compares the performance of PostgreSQL binaries built with Clang and GCC. It uses repeated pgbench runs with identical compiler flags, four connections, and a CPU-focused workload to examine the difference between the two compilers.

### Source excerpt

This is the second in a two-part series on Clang. If you haven't already, you'll want to read my original post on the topic, Could Clang displace GCC among PostgreSQL developers? Part I: Intro and compile times. So, what about the performance of PostgreSQL binaries themselves when built with each compiler? I had heard contradictory reports of the performance of binaries built with Clang. In Belgium, Chris Lattner said that Clang built binaries could perform better, but a number of independent benchmarks suggested that Clang was generally behind, with some notable exceptions. I asked 2ndQuadrant colleague and PostgreSQL performance expert Greg Smith to suggest a useful benchmark to serve as a good starting point for comparing Postgres performance when built with Clang to performance when built with GCC. He suggested that I apply Jeff Janes' recent patch for pgbench that he'd reviewed. It stresses the executor, and therefore the CPU quite effectively, rather than table locks or IPC mechanisms. The results of this benchmark were very interesting. Greg provided me with shell access to a beefy server, the same server that he used in his review of Jeff's patch, which added the -P option: http://archives.postgresql.org/message-id/4DFE788F.5020704@2ndQuadrant.com . I hacked together a shell script to run pgbench for this purpose. Binaries were built using GCC and Clang, each with exactly the same flags - Clang accepts the same flags as GCC. To smooth the results out, and to get a conclusive outcome, I decided on 16 10 minute -P runs with 4 connections, that alternated between using each set of binaries, lasting a total of 3 hours. Here's a summary of the results: 1) GCC test: tps = 34.242839 (including connections establishing) 2) Clang test: tps = 34.370732 (including connections establishing) 3) GCC test: tps = 34.186687 (including connections establishing) 4) Clang test: tps = 34.922954 (including connections establishing) 5) GCC test: tps = 32.393383 (including connecti