mlsys-lab 0.1.0__py3-none-any.whl

mlsys/tasks/cpp-false-sharing-classifier-10-access-patterns/task.md

@@ -0,0 +1,76 @@
+## Context
+
+**False sharing** occurs when two or more threads access different
+variables that happen to reside on the same cache line. If at least one
+thread is writing to that line, the CPU's cache coherence protocol keeps
+invalidating and transferring the line between cores, severely degrading
+performance — even though the threads never touch the same variable.
+
+Assume a standard 64-byte cache line, and that a `ThreadState` instance is
+allocated at an address aligned to 64 bytes (so byte offset `o` falls in
+cache line `o / 64`):
+
+```cpp
+struct ThreadState {
+    int       id;
+    int       read_count;
+    long      write_count;
+    double    items[5];
+    long long padding[5];
+    double    local_sum;
+    int       local_flag;
+};
+```
+
+## Task
+
+Implement, in `solve.cpp`,
+
+```cpp
+std::pair<std::vector<bool>, long> classify_false_sharing();
+```
+
+Classify these 10 fixed concurrent access patterns (Thread 1 and Thread 2
+both touching the same `ThreadState` instance simultaneously):
+
+```
+ 1. T1 writes id,          T2 writes read_count
+ 2. T1 writes id,          T2 reads  write_count
+ 3. T1 reads  read_count,  T2 reads  write_count
+ 4. T1 writes items[4],    T2 writes padding[0]
+ 5. T1 writes items[4],    T2 writes padding[1]
+ 6. T1 writes padding[0],  T2 writes padding[1]
+ 7. T1 writes local_sum,   T2 writes local_flag
+ 8. T1 writes items[0],    T2 reads  local_sum
+ 9. T1 writes padding[1],  T2 reads  local_flag
+10. T1 reads  items[0],    T2 writes items[1]
+```
+
+A pattern is false sharing exactly when both accesses fall in the **same**
+64-byte cache line **and** at least one of the two is a write. Two
+simultaneous reads never cause false sharing; accesses landing in
+different lines never do either, however many writes are involved.
+
+Return `{labels, struct_size}`: `labels` is exactly 10 booleans in the
+order above (`true` = false sharing), and `struct_size` is
+`sizeof(ThreadState)`. Find each field's real byte offset with
+`offsetof(ThreadState, field)` on the actual struct — do not hand-compute
+or guess the layout.
+
+## Example
+
+`id` is at offset `0` and `read_count` at offset `4`; both fall in cache
+line `0`, and pattern 1 writes both, so pattern 1 is false sharing
+(`true`). `items[4]` sits near the end of the `items` array (offset `48`,
+still cache line `0`), while `padding[1]` sits at offset `64` (cache line
+`1`) — different lines, so pattern 5 is **not** false sharing (`false`)
+even though both threads write.
+
+## What the gate checks
+
+The fixed driver (`main.cpp`) calls `classify_false_sharing()` and prints
+the struct size followed by the 10 labels as `0`/`1`. The gate is an
+exact string match (`exact_match == 1.0`) against the reference's printed
+output — the reference computes its labels from real `offsetof` values
+on the real compiled struct, not a hand-typed answer key, so every label
+must match what the actual memory layout produces.

mlsys/tasks/cpp-fix-a-binding-that-copies-instead-of-viewing/main.cpp

@@ -0,0 +1,35 @@
+#include <cstdio>
+#include "sol.hpp"
+
+int main() {
+    const int N = 6;
+    const int header_size = 24;   // e.g. sizeof({long, long, void*}) on LP64
+    const int total = header_size + N * (int)sizeof(double);
+
+    unsigned char* buf = new unsigned char[total];
+    for (int i = 0; i < header_size; i++) buf[i] = (unsigned char)(i + 1);  // filler header bytes
+
+    double* payload = reinterpret_cast<double*>(buf + header_size);
+    for (int i = 0; i < N; i++) payload[i] = i * 1.5;                      // deterministic payload
+
+    double* view = view_payload(buf, header_size, N);
+
+    // 1. Reading through the view must see the current payload values.
+    printf("read:");
+    for (int i = 0; i < N; i++) printf(" %.3f", view[i]);
+    printf("\n");
+
+    // 2. Writing through the view, then re-reading directly out of `buf`,
+    //    must see the write -- this is the actual zero-copy test.
+    for (int i = 0; i < N; i++) view[i] = view[i] * 2.0 + 1.0;
+    double* direct = reinterpret_cast<double*>(buf + header_size);
+    printf("direct-after-write:");
+    for (int i = 0; i < N; i++) printf(" %.3f", direct[i]);
+    printf("\n");
+
+    // 3. A real zero-copy view aliases buf's own memory exactly.
+    printf("shares_memory=%d\n", (view == direct) ? 1 : 0);
+
+    delete[] buf;
+    return 0;
+}

mlsys/tasks/cpp-fix-a-binding-that-copies-instead-of-viewing/meta.json

@@ -0,0 +1,19 @@
+{
+  "id": "cpp-fix-a-binding-that-copies-instead-of-viewing",
+  "title": "Fix a binding that copies instead of viewing (real C++)",
+  "track": "02 Deep C++",
+  "tier": "I",
+  "module": "M2",
+  "difficulty": 4,
+  "genre": "debug",
+  "platform": "cross-platform",
+  "native": "cpp",
+  "gates": [
+    {
+      "metric": "exact_match",
+      "op": "==",
+      "threshold": 1.0
+    }
+  ],
+  "info": []
+}

mlsys/tasks/cpp-fix-a-binding-that-copies-instead-of-viewing/ref.cpp

@@ -0,0 +1,7 @@
+#include "sol.hpp"
+
+// Fixed: return a pointer into buf's own memory -- a real zero-copy view.
+double* view_payload(unsigned char* buf, int header_size, int n) {
+    (void)n;
+    return reinterpret_cast<double*>(buf + header_size);
+}

mlsys/tasks/cpp-fix-a-binding-that-copies-instead-of-viewing/sol.hpp

@@ -0,0 +1,16 @@
+#pragma once
+
+// `buf` points at a single contiguous allocation: a header of exactly
+// `header_size` bytes, followed immediately by a payload of `n` doubles.
+//
+// Return a ZERO-COPY VIEW into that same memory — i.e. exactly
+// reinterpret_cast<double*>(buf + header_size) — so that:
+//   - reading through the returned pointer sees the current payload bytes
+//   - WRITING through the returned pointer is visible through `buf` too,
+//     because it is the same underlying storage, not a copy
+//
+// Do NOT allocate a new `double[n]` and memcpy the payload into it — that
+// is exactly the bug this task asks you to fix, and it breaks the
+// zero-copy contract this function exists to provide (pybind11 / NumPy
+// `frombuffer`-style zero-copy interop).
+double* view_payload(unsigned char* buf, int header_size, int n);

mlsys/tasks/cpp-fix-a-binding-that-copies-instead-of-viewing/starter.cpp

@@ -0,0 +1,12 @@
+#include <cstring>
+#include "sol.hpp"
+
+// BUG: allocates a fresh owned buffer and memcpy's the payload into it,
+// instead of returning a view into buf's own memory. Reads happen to look
+// right at first, but writes through the returned pointer never reach
+// `buf` -- this is exactly "copies instead of views".
+double* view_payload(unsigned char* buf, int header_size, int n) {
+    double* owned = new double[n];
+    std::memcpy(owned, buf + header_size, (size_t)n * sizeof(double));
+    return owned;
+}

mlsys/tasks/cpp-fix-a-binding-that-copies-instead-of-viewing/task.md

@@ -0,0 +1,55 @@
+## Context
+
+When interfacing C++ data structures with Python via libraries like
+pybind11 or the buffer protocol, creating zero-copy views around existing
+C++ buffers is essential for performance. A common but subtle bug: a
+binding allocates a fresh buffer and copies the payload into it "to be
+safe". Reads through the result look correct, but the binding has silently
+become an *owning copy* instead of a *view* — writes through it never reach
+the original buffer, and `np.shares_memory(original, result)` is `False`
+when it should be `True`.
+
+Given a single contiguous allocation laid out as a header of `header_size`
+bytes followed immediately by a payload of `n` doubles, a correct zero-copy
+binding returns a pointer that is *literally* `buf + header_size`
+reinterpreted as `double*` — the same memory, not a duplicate.
+
+## Task
+
+Fix `view_payload` in `solve.cpp`:
+
+```cpp
+double* view_payload(unsigned char* buf, int header_size, int n);
+```
+
+It must return `reinterpret_cast<double*>(buf + header_size)` — a pointer
+into `buf`'s own storage. Do not allocate a new buffer or copy any bytes.
+
+The fixed driver in `main.cpp`:
+1. builds a `buf` with a filler header followed by `n` deterministic
+   payload doubles,
+2. calls `view_payload` and prints what it reads back,
+3. **writes** through the returned pointer, then reads directly out of
+   `buf` at the same offset and prints that,
+4. prints whether the returned pointer is pointer-equal to
+   `buf + header_size` (the zero-copy check, standing in for
+   `np.shares_memory`).
+
+## Example
+
+```cpp
+double* view = view_payload(buf, header_size, n);
+view[0] = 99.0;
+// A correct view: *(double*)(buf + header_size) is now 99.0 too.
+// A buggy copy:    *(double*)(buf + header_size) is unchanged.
+```
+
+## What the gate checks
+
+The grader compiles `main.cpp` + your `solve.cpp` with real
+`clang++ -O2 -std=c++20`, runs it, and compares stdout byte-for-byte against
+the reference build (`exact_match == 1.0`). The starter allocates a fresh
+`double[n]` and `memcpy`s the payload into it: the first printed line
+(plain reads) happens to still match, but writing through the returned
+pointer never reaches `buf`, so the "direct-after-write" line and the
+pointer-equality line both fail.

mlsys/tasks/cpp-fix-a-data-race-with-correct-atomics-tsan/main.cpp

@@ -0,0 +1,32 @@
+#include <cstdio>
+#include <thread>
+#include <vector>
+#include "sol.hpp"
+
+// FIXED driver. T threads each call increment() ITERS times on the SAME
+// shared counter, with no synchronization between them beyond `increment`
+// itself. A correct atomic read-modify-write can NEVER lose an update, so
+// the final count is EXACTLY T * ITERS on every run, no matter how the OS
+// schedules the threads. A load()+store() race loses updates under real
+// concurrent execution -- at this thread count and iteration count, on real
+// multi-core hardware, it essentially always comes out wrong.
+int main() {
+    const int T = 8;
+    const long ITERS = 200000;
+
+    SharedCounter counter;
+    std::vector<std::thread> threads;
+    threads.reserve(T);
+    for (int t = 0; t < T; t++) {
+        threads.emplace_back([&counter]() {
+            for (long i = 0; i < ITERS; i++) increment(counter);
+        });
+    }
+    for (auto& th : threads) th.join();
+
+    long final_value = counter.value.load();
+    long expected = (long)T * ITERS;
+    printf("final=%ld expected=%ld ok=%d\n",
+           final_value, expected, (final_value == expected) ? 1 : 0);
+    return 0;
+}

mlsys/tasks/cpp-fix-a-data-race-with-correct-atomics-tsan/meta.json

@@ -0,0 +1,2 @@
+{"id":"cpp-fix-a-data-race-with-correct-atomics-tsan","title":"Fix a data race with correct atomics (real C++ threads)","native":"cpp","difficulty":4,
+ "gates":[{"metric":"exact_match","op":"==","threshold":1.0}]}

mlsys/tasks/cpp-fix-a-data-race-with-correct-atomics-tsan/ref.cpp

@@ -0,0 +1,10 @@
+#include "sol.hpp"
+
+void increment(SharedCounter& counter) {
+    // A single atomic read-modify-write instruction: no other thread's
+    // fetch_add can interleave inside it, so no increment is ever lost.
+    // (The memory_order argument affects ordering relative to OTHER memory
+    // operations, not whether THIS increment itself is atomic -- relaxed is
+    // sufficient for a plain counter with no data being published by it.)
+    counter.value.fetch_add(1, std::memory_order_relaxed);
+}

mlsys/tasks/cpp-fix-a-data-race-with-correct-atomics-tsan/sol.hpp

@@ -0,0 +1,20 @@
+#pragma once
+#include <atomic>
+
+// A counter that must be safe to increment from many threads concurrently,
+// with no lost updates.
+struct SharedCounter {
+    std::atomic<long> value{0};
+};
+
+// Increment `counter` by exactly 1, safely under concurrent callers.
+//
+// Must perform the increment as a SINGLE ATOMIC read-modify-write (e.g.
+// counter.value.fetch_add(1, ...)). Separately load()-ing the current value,
+// adding 1 in a local, and store()-ing it back is a DATA RACE even though
+// `value`'s TYPE is std::atomic<long>: two threads can both load() the same
+// old value, both compute old+1, and both store() the same result -- one of
+// the two increments is silently lost. Wrapping a variable in std::atomic
+// only makes each INDIVIDUAL load/store atomic; it does not make a
+// load-then-store sequence atomic as a whole.
+void increment(SharedCounter& counter);

mlsys/tasks/cpp-fix-a-data-race-with-correct-atomics-tsan/starter.cpp

@@ -0,0 +1,14 @@
+#include "sol.hpp"
+
+// BROKEN: this LOOKS safe because `value` is std::atomic<long>, but the
+// increment is done as two separate atomic operations -- a load(), then
+// (after a plain, non-atomic +1 in a local) a store() -- instead of one
+// atomic read-modify-write. Two threads can both load() the same old value
+// before either has stored, both compute old+1, and both store() the same
+// result: one increment vanishes. Fix it with a single RMW op such as
+// counter.value.fetch_add(1, ...).
+void increment(SharedCounter& counter) {
+    long v = counter.value.load(std::memory_order_relaxed);
+    v = v + 1;
+    counter.value.store(v, std::memory_order_relaxed);
+}

mlsys/tasks/cpp-fix-a-data-race-with-correct-atomics-tsan/task.md

@@ -0,0 +1,62 @@
+## Context
+
+A **data race** happens when two threads access the same memory location
+concurrently, at least one access is a write, and nothing establishes an
+ordering between them. Wrapping a variable in `std::atomic<T>` does not, by
+itself, make *every* sequence of operations on it race-free — it only
+guarantees that each *individual* `load()` or `store()` is indivisible.
+
+A very common mistake:
+
+```cpp
+long v = counter.value.load();   // step 1: read
+v = v + 1;                       // step 2: compute, in a local (not shared)
+counter.value.store(v);          // step 3: write back
+```
+
+Each of steps 1 and 3 is atomic on its own, but the *sequence* is not: two
+threads can both execute step 1 and read the same old value before either
+one reaches step 3. Both then compute `old + 1` and both store the same
+result back — one of the two increments is silently lost. This is exactly a
+classic check-then-act (TOCTOU) race, just dressed up with an atomic type.
+
+The fix is to perform the whole increment as a single **read-modify-write**
+instruction, which the hardware executes indivisibly — no other thread's
+RMW can interleave in the middle of it:
+
+```cpp
+counter.value.fetch_add(1, std::memory_order_relaxed);
+```
+
+## Task
+
+Fix `increment(SharedCounter& counter)` (declared in `sol.hpp`) so it
+increments `counter.value` by exactly 1, safely, under real concurrent
+callers — using a single atomic read-modify-write instead of a separate
+load and store.
+
+## Example
+
+The driver spawns 8 threads that each call `increment()` 200000 times on
+the *same* `SharedCounter`, with no synchronization between calls other than
+`increment` itself, then joins all of them and reads the final value. A
+correct RMW increment can never lose an update — the atomicity guarantee
+does not depend on scheduling — so the final count is **exactly**
+`8 * 200000 = 1600000` on every single run, regardless of how the OS
+interleaves the threads.
+
+## What the gate checks
+
+The driver prints `final=<n> expected=<n> ok=<0|1>`. The grader compiles
+`solve.cpp` with `clang++ -O2 -std=c++20`, runs it (spawning 8 real
+`std::thread`s), and requires
+
+$$
+\mathrm{exact\_match} = 1 \iff \text{the printed final count equals } T \times \mathrm{ITERS}
+$$
+
+A load-then-store "increment" loses updates under real concurrent execution
+at this scale — not occasionally, but on essentially every run, since 1.6
+million increments across 8 real threads give the race an enormous number of
+chances to interleave badly. The gate is on the actual printed count from
+actually running the threads, not a simulated or predicted one.

mlsys/tasks/cpp-fix-a-py-decref-leak/main.cpp

@@ -0,0 +1,25 @@
+#include <cstdio>
+#include "sol.hpp"
+
+// FIXED driver: five objects, one with a negative value (triggers the error
+// path on the 4th object). Prints the return code and every object's final
+// ob_refcnt.
+
+int main() {
+    long values[5] = {10, 20, 30, -5, 40};
+    MyPyObject objs[5];
+    for (int i = 0; i < 5; ++i) {
+        objs[i].ob_refcnt = 1;
+        objs[i].ob_type = nullptr;
+        objs[i].value = values[i];
+    }
+
+    int rc = process_items(objs, 5);
+
+    printf("rc=%d\n", rc);
+    for (int i = 0; i < 5; ++i) {
+        printf("%ld ", objs[i].ob_refcnt);
+    }
+    printf("\n");
+    return 0;
+}

mlsys/tasks/cpp-fix-a-py-decref-leak/meta.json

@@ -0,0 +1,13 @@
+{
+  "id": "cpp-fix-a-py-decref-leak",
+  "title": "Fix a Py_DECREF leak (real C++)",
+  "track": "02 Deep C++",
+  "tier": "I",
+  "module": "M2",
+  "difficulty": 4,
+  "genre": "debug",
+  "platform": "cross-platform",
+  "native": "cpp",
+  "gates": [{"metric": "exact_match", "op": "==", "threshold": 1.0}],
+  "info": []
+}

mlsys/tasks/cpp-fix-a-py-decref-leak/ref.cpp

@@ -0,0 +1,16 @@
+#include "sol.hpp"
+
+int process_items(MyPyObject* objs, int n) {
+    for (int i = 0; i < n; ++i) {
+        MyPyObject* obj = &objs[i];
+        obj_incref(obj);          // acquire a new/owned reference
+
+        if (obj->value < 0) {
+            obj_decref(obj);      // release it before the early return
+            return -1;
+        }
+
+        obj_decref(obj);          // success path: release, keep going
+    }
+    return 0;
+}

mlsys/tasks/cpp-fix-a-py-decref-leak/sol.hpp

@@ -0,0 +1,36 @@
+#pragma once
+
+// ============================================================================
+// Fixed simplified PyObject-like record and its ref-counting ops (FIXED —
+// do not modify these three definitions; mirrors Py_INCREF/Py_DECREF).
+// ============================================================================
+struct MyPyObject {
+    long ob_refcnt;
+    void* ob_type;
+    long value;
+};
+
+inline void obj_incref(MyPyObject* obj) { ++obj->ob_refcnt; }
+inline void obj_decref(MyPyObject* obj) { --obj->ob_refcnt; }
+
+// ============================================================================
+// LEARNER implements this in solve.cpp.
+//
+// Simulates a C-extension loop over `objs` (`n` of them), modeled on a
+// pattern like `PyObject_GetAttrString` (returns a NEW/owned reference) plus
+// application logic that can fail:
+//
+//   for each object:
+//     obj_incref(obj)              // acquire a new/owned reference
+//     if obj->value < 0:
+//       // error path — release the reference you just acquired, THEN
+//       // return -1 immediately. Do not touch any later object.
+//       ...
+//     // success path — release the reference, continue to the next object.
+//
+// Return -1 the first time an object with value < 0 is seen, otherwise 0
+// after processing every object. Every object's ob_refcnt must end up
+// EXACTLY where it started (no net change) — the reference acquired on the
+// error path must not leak.
+// ============================================================================
+int process_items(MyPyObject* objs, int n);

mlsys/tasks/cpp-fix-a-py-decref-leak/starter.cpp

@@ -0,0 +1,19 @@
+#include "sol.hpp"
+
+// BROKEN: acquires a new reference every iteration but forgets to release
+// it on the error path — a classic Py_DECREF leak on early return.
+int process_items(MyPyObject* objs, int n) {
+    for (int i = 0; i < n; ++i) {
+        MyPyObject* obj = &objs[i];
+        obj_incref(obj);          // acquire a new/owned reference
+
+        if (obj->value < 0) {
+            // BUG: missing obj_decref(obj) before returning — the acquired
+            // reference leaks.
+            return -1;
+        }
+
+        obj_decref(obj);          // success path: release, keep going
+    }
+    return 0;
+}

mlsys/tasks/cpp-fix-a-py-decref-leak/task.md

@@ -0,0 +1,62 @@
+## Context
+
+When writing Python C extensions, managing `PyObject` reference counts is
+critical. C-API calls fall into two categories: **borrowed** references
+(e.g. `PyTuple_GetItem` — you don't own it, don't decref it) and **new**
+references (e.g. `PyObject_GetAttrString` — you own it and **must**
+`Py_DECREF` it when done). A classic bug: acquiring a new reference, then
+returning early on an error path without releasing it first — a leak.
+
+The fixed contract (`sol.hpp`) models this with a simplified record and its
+ref-counting ops:
+
+```cpp
+struct MyPyObject { long ob_refcnt; void* ob_type; long value; };
+void obj_incref(MyPyObject* obj);   // like Py_INCREF
+void obj_decref(MyPyObject* obj);   // like Py_DECREF
+```
+
+## Task
+
+Fix `process_items(MyPyObject* objs, int n)` in `solve.cpp`. For each
+object, in order: acquire a new/owned reference (`obj_incref`, as if calling
+`PyObject_GetAttrString`), then check `value`:
+
+- If `value < 0` — an error — release the reference you just acquired
+  (`obj_decref`) **before** returning `-1`. Do not touch any later object.
+- Otherwise release the reference (`obj_decref`) and continue to the next
+  object.
+
+Return `0` after every object has been processed without error.
+
+The invariant: after the call, every object's `ob_refcnt` must be back to
+exactly what it was before the call — no net change, on either the success
+path or the error path.
+
+## Example
+
+The fixed driver builds 5 objects (`ob_refcnt = 1` each) with values
+`10, 20, 30, -5, 40`. Processing stops at the 4th object (`value = -5`). The
+correct run prints:
+
+```
+rc=-1
+1 1 1 1 1
+```
+
+The shipped starter acquires the reference on that 4th object but never
+releases it before returning, so it still reports `rc=-1` but leaves that
+object's `ob_refcnt` at `2`:
+
+```
+rc=-1
+1 1 1 2 1
+```
+
+## What the gate checks
+
+The grader compiles `main.cpp` + `solve.cpp` with `clang++ -O2 -std=c++20`,
+runs it, and requires an **exact match** of the printed return code and all
+five final `ob_refcnt` values against the same driver linked with `ref.cpp`.
+Any missing `obj_decref` on the error path — or an extra one that
+under-releases a later object — changes a refcount and fails the gate.

mlsys/tasks/cpp-fix-an-ambiguous-overload-broken-sfinae/main.cpp

@@ -0,0 +1,11 @@
+// FIXED driver. Trivial on purpose: the `process` template overloads and
+// the classification test that exercises them both have to live in
+// whichever .cpp defines them (function templates need their definition
+// visible in every translation unit that instantiates them), so all the
+// real work happens in ref.cpp / solve.cpp's run_overload_tests().
+#include "sol.hpp"
+
+int main() {
+    run_overload_tests();
+    return 0;
+}

mlsys/tasks/cpp-fix-an-ambiguous-overload-broken-sfinae/meta.json

@@ -0,0 +1,15 @@
+{
+  "id": "cpp-fix-an-ambiguous-overload-broken-sfinae",
+  "title": "Fix an Ambiguous Overload (Broken SFINAE)",
+  "track": "02 Deep C++",
+  "tier": "I",
+  "module": "M2",
+  "difficulty": 4,
+  "genre": "debug",
+  "platform": "cross-platform",
+  "native": "cpp",
+  "gates": [
+    {"metric": "exact_match", "op": "==", "threshold": 1.0}
+  ],
+  "info": []
+}

mlsys/tasks/cpp-fix-an-ambiguous-overload-broken-sfinae/ref.cpp

@@ -0,0 +1,54 @@
+#include "sol.hpp"
+
+#include <cstdio>
+#include <type_traits>
+#include <utility>
+
+static int g_tag = 0;
+
+// Reference: mutually exclusive constraints.
+//   Overload 1 (tag 1): integral types with sizeof(T) > 4
+//   Overload 2 (tag 2): ANY type with sizeof(T) <= 4
+//   Overload 3 (tag 3): floating-point types with sizeof(T) > 4
+// Every scalar type satisfies at most one of these, so overload resolution
+// is never ambiguous.
+template <typename T, std::enable_if_t<std::is_integral_v<T> && (sizeof(T) > 4), int> = 0>
+void process(T) { g_tag = 1; }
+
+template <typename T, std::enable_if_t<(sizeof(T) <= 4), int> = 0>
+void process(T) { g_tag = 2; }
+
+template <typename T, std::enable_if_t<std::is_floating_point_v<T> && (sizeof(T) > 4), int> = 0>
+void process(T) { g_tag = 3; }
+
+// Harness-side detection idiom: does `process(T{})` compile at all for this
+// T? A genuinely ambiguous or genuinely no-viable-candidate call is invalid
+// in the immediate context of this decltype, so this safely evaluates to
+// false in either case instead of taking the whole program down with it.
+template <typename T, typename = void>
+struct can_process : std::false_type {};
+template <typename T>
+struct can_process<T, std::void_t<decltype(process(std::declval<T>()))>> : std::true_type {};
+
+template <typename T>
+static void test_type(const char* name) {
+    if constexpr (can_process<T>::value) {
+        g_tag = 0;
+        process(T{});
+        printf("%s %d\n", name, g_tag);
+    } else {
+        printf("%s NoMatch\n", name);
+    }
+}
+
+void run_overload_tests() {
+    test_type<bool>("bool");
+    test_type<char>("char");
+    test_type<short>("short");
+    test_type<int>("int");
+    test_type<long>("long");
+    test_type<long long>("long long");
+    test_type<float>("float");
+    test_type<double>("double");
+    test_type<int*>("pointer");
+}

mlsys/tasks/cpp-fix-an-ambiguous-overload-broken-sfinae/sol.hpp

@@ -0,0 +1,12 @@
+#pragma once
+// Runs the SFINAE-overload classification test for 9 scalar types (bool,
+// char, short, int, long, long long, float, double, and a pointer) and
+// prints one line per type: `<name> <tag>` where `<tag>` is 1, 2, or 3 for
+// whichever `process` overload uniquely matched, or `<name> NoMatch` if
+// none did.
+//
+// Implement this entirely in your .cpp: it needs your `process` template
+// overloads' definitions in the same translation unit that instantiates
+// them, which is true of function templates in general (unlike ordinary
+// functions, you can't declare a template here and define it elsewhere).
+void run_overload_tests();