[cfe-dev] GSoC 2018

[Mikhail Ramalho via cfe-dev]

Hi all,

I've been playing with the static analyzer in the last couple of weeks and
I came up with some questions about the project:

1. What's the preferable way of implementing the option to double check the
results? I had some ideas about that:

1.1 To add a new option to the analyzer, so the user can specify when to
double check the results. This option gives the user more freedom but the
checker's developers won't have any control about it.

1.2 To change emitReport and add a default parameter to allow/force double
check; this will likely override the user's desire to double check the
reports. One scenario is if the Z3 double checker doesn't support something
in the bug path but the developer wants to show the result anyway.

1.3 Some combination of the two options?

~

2. I still don't quite understand how dynamic memory track works in the
analyzer, is the double checker expected to work for pointers and dynamic
memory as well? I'm assuming yes here and that Z3ConstraintManager might
need to be extended somehow (a plan will be added to the proposal).

~

3. This is a list of the TODOs in Z3ConstraintManager, from more important
to less important, in my opinion. I just want to know if the analyzer's
developers (and the project mentor) agree with this list, as it might go
into my proposal:

3.1. Don't assume nearest ties to even rounding mode: currently, only
rounding to even is supported, even if the code changes the rounding mode
using fesetround.

3.2. Don't add all the constraints, only the relevant ones: adding
unnecessary constraints will slowdown the solver.

3.3. Refactor doTypeConversion to use built-in conversion functions (Refactor
to Sema::FindCompositePointerType(), and
Sema::CheckCompareOperands(); Refine behavior for invalid type casts)
3.4. Refactor doIntTypeConversion to use Sema::handleIntegerConversion()
3.5. Refactor doFloatTypeConversion to use Sema::handleFloatConversion()

I bundled this together because, although the conversion seems incomplete
(based on the comments), it's about removing duplicated code.

3.6. Refactor getAPSIntType(const llvm::APSInt &Int) const to put elsewhere.

~

Thank you,


2018-02-24 1:03 GMT+00:00 Devin Coughlin <dcoughlin at apple.com>:

>
>
> > On Feb 23, 2018, at 9:29 AM, Mikhail Ramalho via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
> >
> > I also have a question about the proposal. I understand that ideas about
> the project will be discussed in the mailing list. However, once that's
> settled and I write my first draft proposal, should I send it to the
> mailing list for discussion again or should I send it only to the mentor?
>
> Please make sure to keep email discussions on the mailing list rather than
> just personal email. This is a topic that members of the community will be
> interested in and will have valuable feedback on.
>
> Devin
>
>


-- 

Mikhail Ramalho.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180311/be39a37f/attachment.html>