[llvm] [libcxx] [flang] [clang] [clang-tools-extra] [compiler-rt] [libc] [Clang] Generate the GEP instead of adding AST nodes (PR #73730)

Bill Wendling via cfe-commits cfe-commits at lists.llvm.org
Fri Dec 15 11:07:02 PST 2023


================
@@ -4073,6 +4221,51 @@ LValue CodeGenFunction::EmitArraySubscriptExpr(const ArraySubscriptExpr *E,
       ArrayLV = EmitLValue(Array);
     auto *Idx = EmitIdxAfterBase(/*Promote*/true);
 
+    if (SanOpts.has(SanitizerKind::ArrayBounds)) {
+      // If the array being accessed has a "counted_by" attribute, generate
+      // bounds checking code. The "count" field is at the top level of the
+      // struct or in an anonymous struct, that's also at the top level. Future
+      // expansions may allow the "count" to reside at any place in the struct,
+      // but the value of "counted_by" will be a "simple" path to the count,
+      // i.e. "a.b.count", so we shouldn't need the full force of EmitLValue or
+      // similar to emit the correct GEP.
+      const LangOptions::StrictFlexArraysLevelKind StrictFlexArraysLevel =
+          getLangOpts().getStrictFlexArraysLevel();
+
+      if (const auto *ME = dyn_cast<MemberExpr>(Array);
+          ME &&
+          ME->isFlexibleArrayMemberLike(getContext(), StrictFlexArraysLevel) &&
+          ME->getMemberDecl()->hasAttr<CountedByAttr>()) {
+        RecordDecl *RD = ME->getMemberDecl()
+                             ->getDeclContext()
+                             ->getOuterLexicalRecordContext();
----------------
bwendling wrote:

Basically, yes. If you have something like:

```
void foo(struct B *b) {
  bar(b->member[12]);`
}
```

Then there won't be a check, because we won't be able to "see" the `count` in `struct A`. I know it's restrictive, but it's the best we can do given that `someB` may not be allocated within an enclosing `struct A`.

https://github.com/llvm/llvm-project/pull/73730


More information about the cfe-commits mailing list