Martin Sebor

The corresponding GCC report is in PR #[98536](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98536). As explained there, the warning is intentional.

Okay, so to start let me look at adding the missing `annotateNonNullNoUndefBasedOnAccess` calls and take it from there. I understand that some of the attributes (like `nocpature` on the `strlen`...

For function declarations GCC applies the `const` and `pure` attribute to the declarations themselves (rather than to their types) but when deciding whether to retain or remove a call to...

From what I can see in the dumps, Clang emits a loop with each iteration calling to `llvm.memset.inline` with a constant size. Each call that then gets expanded into a...

That should work if suppressing it even for stores that didn't originate from `memset.inline` is okay (e.g., those from calls to other functions inlined into the caller). Is there already...

There are other examples that boil down to the same underlying problem: `isValidProtoForLibFunc` being overly permissive and accepting as valid declarations of functions whose signatures the libcall simplifier is not...

Another example is below. This is one is closer to the `sprintf` problem in that it's induced by transforming the `strchr(p, 0)` call to `p + strlen(p)` and assuming that...

Okay then, let me use this bug to fix just the `strtol` class of bugs, i.e., those triggered by lax compatibility checking in `TargetLibraryInfoImpl::isValidProtoForLibFunc` unrelated to pointer types.

The reported issue has been fixed in rG0dcfe7aa35cd. A patch for the problem noted above has been submitted in [D129915](https://reviews.llvm.org/D129915).

Fixed in [rG0dcfe7aa35cd](https://reviews.llvm.org/rG0dcfe7aa35cd).