[PATCH] D80860: Exact integer emptiness checks for FlatAffineConstraints
Tobias Grosser via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Jan 5 11:52:02 PST 2022
grosser added a comment.
Hi @arjunp, I am wondering if there are ways to prevent future coverity warnings on this code?
================
Comment at: mlir/lib/Analysis/Presburger/Simplex.cpp:131
+ for (unsigned col = 0; col < nCol; ++col)
+ tableau(row, col) /= gcd;
+}
----------------
arjunp wrote:
> mehdi_amini wrote:
> > What guarantees that `gcd` can't be 0 and produce an invalid division here?
> > Should we guard this loop?
> >
> > (flagged by Coverity)
> One of the elements being GCD'd is a "denominator" value that is always non-zero. I will add a comment noting this.
Given that these are coverity errors, it might be useful to document this with an assert to ensure that coverity does not warn about this anymore.
================
Comment at: mlir/lib/Analysis/Presburger/Simplex.cpp:325
+
+ int64_t diff = retConst * elem - constTerm * retElem;
+ if ((diff == 0 && rowUnknown[row] < rowUnknown[*retRow]) ||
----------------
arjunp wrote:
> mehdi_amini wrote:
> > mehdi_amini wrote:
> > > If `retRow` is true, then `retConst` is used uninitialized right? Can you look into this?
> > > (flagged by Coverity)
> > (Same with `retElem`)
> If `retRow` has a value then lines 319-322 were executed in the iteration that that values was set in, so the values of `retElem` and `retConst` were also set in that iteration already.
Again, as these are coverity errors the question is how we can avoid coverity to flag these issues. I am almost tempted to just suggest to set retElement and retConst to 0 and add a comment stating that this is done to avoid the coverity warning.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D80860/new/
https://reviews.llvm.org/D80860
More information about the llvm-commits
mailing list