Question bank — GCC - Clang flags — optimization (-O0 to -O3, -Os), warnings (-Wall, -Wextra), sanitizers

False. It's a curated common-bug subset; -Wextra, -Wshadow, -Wconversion and others live outside it. The name is historical, not literal.

False. Aggressive inlining/vectorization can grow code and thrash the instruction cache (see figure s02 and CPU Caches and Instruction Cache); each optimization is a bet that can lose. Benchmark before trusting it.

False. A warning by default lets the build succeed; only -Werror promotes warnings to build-stopping errors.

False. -O0 can accidentally mask UB. The optimizer is allowed to assume UB never happens, so the same source can break at -O2. Correct-at--O0 proves nothing.

False. Sanitizers are runtime checkers — they add instrumentation that fires only when the buggy path actually executes on real inputs. Warnings are the static tool.

Mostly-but-not-always false. -Os disables size-bloating passes, so it's usually a bit slower — but a smaller binary can fit the i-cache better and occasionally win on cache-bound code.

False (for a correct program). The as-if rule forbids changing observable results. It only changes how fast/small the machine code is. If the result changes, your program had UB.

False. AddressSanitizer (ASan) needs its runtime library linked in; you must pass the flag at the link step too, or you get undefined-reference errors. Put it in both CFLAGS and LDFLAGS (see Makefiles and CFLAGS/LDFLAGS).

False. -Ofast adds -ffast-math, which breaks strict IEEE float semantics (reassociates operations, ignores NaN/inf rules). It can change numeric results — dangerous unless you've verified your maths tolerates it.

False. ASan costs roughly 2× time and 3× memory because every load/store consults shadow memory (figure s01). It belongs in tests/CI, never production.

The idea is fine but the level is off. -O0 is readable but slow; -O3 may optimize away the very UB you want to catch. The conventional sweet spot is -O1 -g -fsanitize=....

That combination does compile and run — the compiler allows it — but it's the wrong tool for a release: ASan makes it ~2× slower and heavy -O3 optimization can muddy the reports. Ship -O2 -DNDEBUG; sanitize separately in CI.

n - 10 is computed in unsigned arithmetic, so 5u - 10u wraps to a huge positive number and < 0 is always false. -Wall/-Wtype-limits flags it. Fix with signed types or a cast.

Not a miscompile. Pointer overflow is UB, so the compiler assumes p + n never wraps and folds the check to false. The check itself was the bug; use size comparisons, not pointer wraparound.

Warnings are static heuristics; they can't see runtime memory bugs like use-after-free or heap overflow. Zero warnings ≠ memory-safe. Add ASan to actually exercise the paths.

Expected, not a bug. Newer compilers add new warnings, so -Werror can fail on previously-clean code. That's the tradeoff of a zero-warning gate; pin versions or scope -Werror to specific warnings in CI.

-O0 keeps variables in memory and adds load/store traffic every iteration, so its timings don't reflect the optimized reality. Always benchmark at the level you'll ship (-O2/-O3).

At -O0 every variable (loop counter, accumulator) lives in stack memory so a debugger can read/modify it at any breakpoint. Each iteration pays load+store traffic instead of using registers.

Because of the as-if rule: only observable behaviour must be preserved. Register allocation, inlining, and loop-invariant motion don't change results, so they're permitted.

Warnings catch statically visible mistakes; sanitizers catch runtime ones — buffer overflows, use-after-free, signed overflow — that no static pass can prove in general. They're complementary, not redundant.

A pointer alone doesn't know its bounds. ASan maps every 8 app bytes to 1 shadow byte recording "addressable?", places poisoned redzones around allocations, and instruments each access to consult the shadow (figure s01) — an $O(1)$ (constant-time, input-size-independent) check per memory op.

It's the highest bug-found-per-second tool: a compile-time, zero-runtime-cost detector of the most common mistakes (uninitialized vars, sign-compare, switch fallthrough). No test needs to run.

-Os disables passes that trade size for speed (e.g. aggressive vectorization; see SIMD and Auto-Vectorization), so it's typically slower on compute-bound work. Use it only when size is the actual constraint.

-Og optimizes for a good debugging experience: faster than -O0 but keeps line-info and variable locations sane so Debugging with GDB and -g still works. It's the dev/interactive middle ground.

CI runs the full test suite on every commit under sanitizers, catching UB before merge in a shared, reproducible environment — no reliance on individuals remembering to run it.

Nothing is guaranteed. Since UB voids the as-if contract, any level may produce any behaviour — including "works" at one level and "crashes" at another. The fix is removing the UB, not tuning the flag.

You get -O0 — the default is "no optimization," not -O2. Many people assume the compiler optimizes by default; it does not.

Mostly no — plain -O3 respects IEEE semantics under the as-if rule. But there are hardware corners: -ffp-contract may fuse a*b+c into a single FMA (fused multiply-add) that rounds once instead of twice, and on legacy x87 the 80-bit extended-precision registers can give results that differ from strict 64-bit doubles. So "identical bits" isn't guaranteed across targets even without -ffast-math.

The last one wins — flags are applied left to right, so -O0 -O2 gives -O2. This is why build systems put user overrides after defaults in CFLAGS.

Yes; ASan and UBSan compose in one build. But TSan is incompatible with ASan (different memory models), so you can't combine those two — run thread-sanitized builds separately.

Silence it locally and explicitly — [[fallthrough]], (void)param;, or a targeted pragma — not by dropping -Wall. Turning the whole warning off hides future real bugs.