[all-commits] [llvm/llvm-project] 1b4e7f: [Clang] Enforce the same size limits for `vector_s...

[Akash Manna via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 1b4e7f41268eb3db5300e79256764140e509e3f5
      https://github.com/llvm/llvm-project/commit/1b4e7f41268eb3db5300e79256764140e509e3f5
  Author: Akash Manna <akash.manna.mymail at gmail.com>
  Date:   2026-09-25 (Fri, 25 Sep 2026)

  Changed paths:
    M clang/docs/ReleaseNotes.md
    M clang/lib/Sema/SemaType.cpp
    M clang/test/Sema/large-bit-int.c
    M clang/test/Sema/types.c
    M clang/test/SemaCXX/vector.cpp

  Log Message:
  -----------
  [Clang] Enforce the same size limits for `vector_size` and `ext_vector_type` (#226375)

Fixes #165458

A `bool` vector declared with `ext_vector_type` isn't lowered as an LLVM
vector in memory: `ConvertTypeForMem` packs it into a single integer
with one bit per element. `BuildExtVectorType` only checked that the
element count fits in 32 bits, though, so a vector of 187,553,262 bools
got through Sema and the first consumer that needed its memory type (the
zero initializer of a tentative definition here) asked
`IntegerType::get` for far more than the 2^23 bits it supports. The
count matters for every element type, not just `bool`, because Sema also
forms bool vectors out of other vectors (`c ? true : false` with a
`char` vector condition), and `vector_size` was no better off with its
limits of 2^32 elements and 2^61 bytes.

Both attributes now go through the same two limits when the type is
built, reusing the existing "vector size too large" error: at most
`llvm::IntegerType::MAX_INT_BITS` (2^23) elements, and at most 2^28
bytes so that the natural alignment, the size rounded up to a power of
two, still fits in the `unsigned` alignment of `TypeInfo`. These replace
the old `isIntN(61)` and `UINT32_MAX` checks in `BuildVectorType`.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications