steakhal marked an inline comment as done.
steakhal added a comment.
In D136162#3873392 <https://reviews.llvm.org/D136162#3873392>, @NoQ wrote:
> Ok so you're saying that it's not just a wrong Decl but there's like an
> entire cast-expression missing in the AST? This fix is probably good enough
> for us but it begs a question, what does CodeGen do in such cases? Does it
> also need to emit a cast instruction into LLVM IR that doesn't correspond to
> anything in the AST? Or is this entirely about our weird pointer cast
> handling, that needs to act even when the numeric value of the pointer
> doesn't change?
Good question. The IR is identical for the two cases - except for metadata
markers e.g. for deb info, etc.
So, it might be simply that the "C" language just doesn't care if there is a
bitcast or not in the AST, because the hardware register is just an untyped
register; hence this `ImplicitCastExpr` (bitcast) is getting lowered as a noop
at the IR level.
Unfortunately, it's beyond my expertise. Do you think we should invite someone,
like Shafik or Aaron?
================
Comment at: clang/lib/StaticAnalyzer/Core/CallEvent.cpp:490
+ // edge-cases.
+ ArgVal = castArgToParamTypeIfNeeded(Call, Idx, ArgVal, SVB);
+
----------------
tomasz-kaminski-sonarsource wrote:
> Previously we didng make bindings if `ArgVal` was unknown, and we may want to
> preserve this invariant.
IDK what are the implications of not having a binding or having a binding to
unknown.
I'll change this anyway. Thanks for noticing.
================
Comment at: clang/test/Analysis/region-store.c:66
+ // expected-warning@+1 {{passing arguments to 'b' without a prototype is
deprecated in all versions of C and is not supported in C2x}}
+ b(&buffer);
+}
----------------
NoQ wrote:
> steakhal wrote:
> > tomasz-kaminski-sonarsource wrote:
> > > tomasz-kaminski-sonarsource wrote:
> > > > I would like to see an example where the called function is implicitly
> > > > defined.
> > > After rethinking it, I have not idea how to construct that example.
> > I could not construct such an example.
> > It seems like clang errors out for cases when an implicit declaration of a
> > call mismatches with the definition of that function.
> > https://godbolt.org/z/rM9ajeTf7
> Yeah, if you scroll really far to the right, you'll see that the first error
> is actually a warning auto-promoted to an error. So you can pass
> `-Wno-implicit-function-declaration` and it'll disappear. Not sure what to do
> with the other error though, it really does notice that the implicit
> definition conflicts with the later explicit definition. So, dunno.
Yup, I should have been more clear on this. See the test, I'm also passing the
`-Wno-implicit-function-declaration` :)
Maybe Shafik or Aaron knows some weird stuff about how to make it 'compile'.
WDYT?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D136162/new/
https://reviews.llvm.org/D136162
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
