================
@@ -4022,8 +4169,36 @@ LValue CodeGenFunction::EmitArraySubscriptExpr(const
ArraySubscriptExpr *E,
ArrayLV = EmitArraySubscriptExpr(ASE, /*Accessed*/ true);
else
ArrayLV = EmitLValue(Array);
+
auto *Idx = EmitIdxAfterBase(/*Promote*/true);
+ if (SanOpts.has(SanitizerKind::ArrayBounds)) {
----------------
bwendling wrote:
> You should be able to refactor some code out of
> CodeGenFunction::EmitMemberExpr so it's not a completely independent codepath.
I could use it as a template, but refactoring probably won't work very well,
because even if I could call it to generate the FAM array access, I don't have
an Expr for the count.
> the nastiest problems are caused by one piece of code making assumptions
> about how an apparently unrelated part of the code behaves.
This is why I'm being very stubborn about *not* skipping the existing Emit
functions. The assumption we're making are that generating the GEPs by hand for
both fields is "easy". We can make that assumption for the `count` field,
because of the expectations I mentioned above (how it's at the top-level of the
struct, etc.). But I don't want to make those assumptions about the flexible
array field.
As it turns out, I should be able to use `getSourceElementType` on a GEP to
know when to stop skipping GEPs.
Keep in mind, the code we generate is for bounds checking, so we have a
fallback if we're unable to generate a proper bounds check using the `count`.
I.e., if we run into something unexpected, we can abort the bounds checking
generation.
https://github.com/llvm/llvm-project/pull/73730
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
