<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <br>
    <div class="moz-cite-prefix">On 3/26/18 2:01 AM, Alexey Knyshev
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAM5izQvLHivLQSetYNkm+72P4A1GP+1u67Td64Q-FHS6Aobx0w@mail.gmail.com">
      <div dir="ltr">
        <div>
          <div>
            <div>Hi all,<br>
              <br>
            </div>
            During last few days I was working on std::shared_ptr
            constructor modeling and trying to understand how path
            sensitive analysis works. After some time I faced unexpected
            modelling of Call arguments SVals. Here is the portion of
            code that caused analyzer behavior that I don't understand:<br>
            <br>
            <div style="margin-left:40px">auto del =
              std::default_delete<S>();<br>
              return std::shared_ptr<S>((S*)malloc(sizeof(S)),
              del);<br>
              <br>
            </div>
            The case I observed: first argument SVal is modeled properly
            and I can get RegionState info from program state (provided
            by MallocChecker). The second one (del symbol) is unknown
            (DelSVal.dump() shows me that). On the other hand, the
            following code doesn't cause such problem and prints
            '&code{free}' as expected:<br>
            <br>
            <div style="margin-left:40px">const auto &del = free;<br>
              return std::shared_ptr<S>((S*)malloc(sizeof(S)),
              del);<br>
              <br>
            </div>
            So, the question is: what can cause such imprecise modeling
            of SVal (Deleter - second constructor arg)?<br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    "Well," said Owl, "the customary procedure in such cases is as
    follows:"<br>
    <br>
    1. View the exploded graph in GraphViz (as described in
    <a class="moz-txt-link-freetext" href="https://clang-analyzer.llvm.org/checker_dev_manual.html#visualizing">https://clang-analyzer.llvm.org/checker_dev_manual.html#visualizing</a>).<br>
    2. Find the top-most node on it that has incorrect or missing info.<br>
    3. Does the node have a checker tag at the bottom? If so, find the
    respective code that adds transitions in the checker.<br>
    4. Otherwise see what statement is being evaluated at this node. The
    code you're interested in lies somewhere within ExprEngine::Visit()
    for the respective statement kind.<br>
    5. Put a breakpoint in the code you've found and debug step-by-step
    until you see the problem.<br>
    <br>
    Exploded graph is quite overwhelming at first, but it's not as hard
    as it looks.<br>
    <br>
    In your case the call argument is an UnknownVal - which means that
    you know that we couldn't evaluate argument expression. If you're
    not sure what kind of expression it is, consult the -ast-dump. The
    (last) node that evaluates that expression would not contain the
    value for the expression (because UnknownVal is dropped in
    Environment - but not in Store). If any of its sub-expressions are
    also incorrectly dropped, you might want to look at them first.<br>
    <br>
    <blockquote type="cite"
cite="mid:CAM5izQvLHivLQSetYNkm+72P4A1GP+1u67Td64Q-FHS6Aobx0w@mail.gmail.com">
      <div dir="ltr">
        <div>P.S. I've changed shared_ptr constructor declaration in
          'test/Analysis/Inputs/system-header-simulator-cxx-std-suppression.h':<br>
        </div>
      </div>
    </blockquote>
    <br>
    You should only use these simulators for regression testing. They're
    simplified standard library headers that try to be as accurate as
    possible but don't guarantee that. After all, For your actual
    development, you should use the real system headers, because that's
    what the users will care about, and then try to update the
    simulators to simulate them as closely as you need.<br>
    <br>
    <blockquote type="cite"
cite="mid:CAM5izQvLHivLQSetYNkm+72P4A1GP+1u67Td64Q-FHS6Aobx0w@mail.gmail.com">
      <div dir="ltr">
        <div><br>
          <div style="margin-left:40px">shared_ptr(_Tp* __p,
            void(*deleter)(void*))<br>
            <br>
          </div>
          to<br>
          <br>
          <div style="margin-left:40px">template<class Deleter><br>
          </div>
          <div style="margin-left:40px">shared_ptr(_Tp* __p, Deleter d)<br>
            <br>
          </div>
          and I don't understand why it was declared with function
          pointer argument instead template. But looks like it isn't the
          source of my problem <span id="gmail-result_box"
            class="gmail-short_text" lang="en"><span class="gmail-">at
              first sight</span></span>.<br>
          <br>
        </div>
        Regards, Alexey K<br>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">2018-03-20 0:37 GMT+03:00 Artem
          Dergachev <span dir="ltr"><<a
              href="mailto:noqnoqneo@gmail.com" target="_blank"
              moz-do-not-send="true">noqnoqneo@gmail.com</a>></span>:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex"><span
              class=""><br>
              <br>
              On 17/03/2018 7:25 AM, Alexey Knyshev wrote:<br>
              <blockquote class="gmail_quote" style="margin:0 0 0
                .8ex;border-left:1px #ccc solid;padding-left:1ex">
                <br>
                    This should already be supported by MallocChecker -
                i.e. it warns<br>
                    when you allocate memory with, say, new() and
                release it with<br>
                    free() or delete[]().<br>
                <br>
                    If methods of a smart pointer are "inlined" during
                analysis, these<br>
                    bugs will already be caught automatically.<br>
                <br>
                <br>
                I took a look at your recent work & status report
                posted there in mailing lists. And I have a question
                about how it would work in particular cases, e.g.:<br>
                1. Returning smart_ptr by value from function that has
                it's implementation in analyzed translation unit but it
                isn't called from any other function in the same TU.<br>
                <br>
                std::shared_ptr<S> createInstance() {<br>
                   return std::shared_ptr<S>(new S, free);<br>
                }<br>
                <br>
                If I understand correctly, compiler is free to apply
                copy-elison optimization on shared_ptr which is returned
                by value. So destructor call won't be modeled properly
                because it's not inlined during analysis. And bug won't
                be caught.<br>
              </blockquote>
              <br>
            </span>
            Indeed, the tempting - but risky - thing to do here is to
            declare construction of "std::shared_ptr<S>(new S,
            free);" to be a bug on its own. It is risky because it
            leaves us with a checker that finds non-bugs; there is a
            chance that the destructor will never be called while the
            pointer is still being owned by the shared_ptr. Such code
            would be ridiculous but at the same time we wouldn't like to
            drive away users who had to write this to work around an
            equally ridiculous proprietary API that they have no way of
            changing.<br>
            <br>
            In this particular case i'd have tried to take the risk,
            keeping in mind that i might end up rewriting the checker
            back to the conservative behavior of only warning at the
            destructor.<br>
            <br>
            Note that copy elision is irrelevant, because in any case we
            won't free() the pointer at the return site, because
            reference count will never reach zero within the function.
            That's the whole point of the shared pointer.<span class=""><br>
              <br>
              <blockquote class="gmail_quote" style="margin:0 0 0
                .8ex;border-left:1px #ccc solid;padding-left:1ex">
                2. As you mentioned before, report would be fired only
                if constructor and destructor have been inlined (which
                is not guaranteed to be done). As the result such check
                won't work in general case.<br>
              </blockquote>
              <br>
            </span>
            Yeah, that's pretty much the primary motivation for making
            an API-specific checker. It's not super strong in this case
            because this would likely give a very slight increase over
            the existing coverage.<br>
            <br>
            In this case, however, the much more important motivation is
            to avoid false positives that occur when we don't know the
            original reference count of a shared pointer that was
            constructed before analysis has started - and we start
            "assuming..." that any destructor of a shared pointer could
            release memory. This is currently planned to be suppressed
            in a fairly gross manner (<a
              href="https://reviews.llvm.org/D44281" rel="noreferrer"
              target="_blank" moz-do-not-send="true">https://reviews.llvm.org/D442<wbr>81</a>).
            For this reason we believe that having explicit modeling for
            various smart pointers is a must.<span class=""><br>
              <br>
              <blockquote class="gmail_quote" style="margin:0 0 0
                .8ex;border-left:1px #ccc solid;padding-left:1ex">
                Actually my point is about modeling smart pointers
                behavior specifically and don't inline any calls to
                constructor / destructor & methods those modeled by
                checker. And the question immediately arises: is there
                way to control inline policy?<br>
              </blockquote>
              <br>
            </span>
            It is indeed possible to make the checker "take over"
            function call modeling by subscribing on the `eval::Call`
            callback. In this case both inlining and conservative
            evaluation by the core are avoided, and the checker who
            evaluates the call is responsible for modeling *all* effects
            of the call (because two checkers cannot evalCall the same
            call, even though they can do the usual
            checkPreCall/checkPostCall thingy as much as they want).<br>
            <br>
            There is also the BodyFarm mechanism (which allows you to
            mock simplified ASTs for standard functions) but you DO NOT
            WANT to use it for C++ because it'd take you forever to
            construct the correct C++ AST with templates manually.<br>
            <br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex"><span
                class="">
                And sorry for any possible misunderstanding from my side
                as I'm not quite familiar with CSA internals.<br>
                <br>
                Regards, Alexey K<br>
                <br>
              </span>
              2018-03-17 5:21 GMT+03:00 Artem Dergachev <<a
                href="mailto:noqnoqneo@gmail.com" target="_blank"
                moz-do-not-send="true">noqnoqneo@gmail.com</a>
              <mailto:<a href="mailto:noqnoqneo@gmail.com"
                target="_blank" moz-do-not-send="true">noqnoqneo@gmail.com</a>>>:<span
                class=""><br>
                <br>
                <br>
                <br>
                    On 16/03/2018 12:30 PM, Alexey Knyshev wrote:<br>
                <br>
                        Sorry, accidentally removed part of message
                before sending.<br>
                <br>
                        Aleksei,<br>
                <br>
                            Could you share your ideas of checker
                design? It is<br>
                        possible that<br>
                            problems you met can be solved in different
                (maybe even<br>
                        better)<br>
                            way if we know the whole picture.<br>
                <br>
                <br>
                        I'm currently have no clear idea how to
                implement it in the<br>
                        "right manner". But first of all I would aim to
                track the<br>
                        origin (malloc, new, new [], etc) of SVal and
                check if Deleter<br>
                        is the expected corresponding way to deallocate
                such SVal.<br>
                <br>
                <br>
                    This should already be supported by MallocChecker -
                i.e. it warns<br>
                    when you allocate memory with, say, new() and
                release it with<br>
                    free() or delete[]().<br>
                <br>
                    If methods of a smart pointer are "inlined" during
                analysis, these<br>
                    bugs will already be caught automatically.<br>
                <br>
                <br>
                        Regards, Alexey K<br>
                <br>
                        2018-03-16 22:22 GMT+03:00 Alexey Knyshev<br>
                        <<a href="mailto:alexey.knyshev@gmail.com"
                  target="_blank" moz-do-not-send="true">alexey.knyshev@gmail.com</a>
                <mailto:<a href="mailto:alexey.knyshev@gmail.com"
                  target="_blank" moz-do-not-send="true">alexey.knyshev@gmail.c<wbr>om</a>><br>
              </span>
                      <mailto:<a
                href="mailto:alexey.knyshev@gmail.com" target="_blank"
                moz-do-not-send="true">alexey.knyshev@gmail.c<wbr>om</a>
              <div>
                <div class="h5"><br>
                          <mailto:<a
                    href="mailto:alexey.knyshev@gmail.com"
                    target="_blank" moz-do-not-send="true">alexey.knyshev@gmail.c<wbr>om</a>>>>:<br>
                  <br>
                              Hello guys,<br>
                  <br>
                              And thanks for your attention<br>
                  <br>
                              Aleksei,<br>
                  <br>
                                  Could you share your ideas of checker
                  design? It is<br>
                          possible<br>
                                  that problems you met can be solved in
                  different<br>
                          (maybe even<br>
                                  better) way if we know the whole
                  picture.<br>
                  <br>
                  <br>
                              As I said, I'm interested in improving
                  current state of<br>
                          dynamic<br>
                              memory modeling. Especially stuff related
                  to smart<br>
                          pointers (e.g.<br>
                              shared, unique) which also mentioned in
                  list of potential<br>
                          checkers<br>
                              as smartptr.SmartPtrInit<br>
                              <<a
                    href="https://clang-analyzer.llvm.org/potential_checkers.html"
                    rel="noreferrer" target="_blank"
                    moz-do-not-send="true">https://clang-analyzer.llvm.o<wbr>rg/potential_checkers.html</a><br>
                          <<a
                    href="https://clang-analyzer.llvm.org/potential_checkers.html"
                    rel="noreferrer" target="_blank"
                    moz-do-not-send="true">https://clang-analyzer.llvm.o<wbr>rg/potential_checkers.html</a>>>*<br>
                  <br>
                              *<br>
                  <br>
                                  **You can see an example of how state
                  trait is exported in<br>
                                  GenericTaintChecker or MPIChecker.
                  Generally, you just<br>
                          create<br>
                                  a named ProgramStateTrait in the
                  header.<br>
                  <br>
                  <br>
                              Briefly looked at MPITypes.h. Does it mean
                  we should move<br>
                              RegionState to separate file and register
                  it via Traits in the<br>
                              same manner to make it avaliable from
                  other checkers (not<br>
                          other TU<br>
                              as mentioned in ento::mpi::RequestMap)?<br>
                  <br>
                  <br>
                      GenericTaintChecker is made in a fairly intrusive
                  manner by<br>
                      putting stuff into the program state class
                  directly, which isn't<br>
                      very sane. I'd definitely prefer something similar
                  to dynamic type<br>
                      propagation (see DynamicTypeMap.cpp,
                  DynamicTypeMap.h). You can<br>
                      use the usual REGISTER_MAP_WITH_PROGRAMSTATE
                  (etc.) macros in the<br>
                      .cpp file as long as you provide accessor methods
                  declared in the<br>
                      .h file that other checkers could include.<br>
                  <br>
                  <br>
                              Artem,<br>
                  <br>
                                  you need to keep all of this in mind
                  when writing a<br>
                          checker.<br>
                  <br>
                  <br>
                              Sure, but on the other hand I think it's
                  possible to<br>
                          implement and<br>
                              improve modeling of various API calls'
                  effects<br>
                          step-by-step. Let's<br>
                              say, it case of SmartPtrInit checker
                  mentioned before the bare<br>
                              minimum would be modeling of construction
                  (and destruction to<br>
                              avoid leak report from existing related
                  checkers).<br>
                  <br>
                                  which is why the few experimental C++
                  checkers that we<br>
                                  currently have required heavy hacks to
                  become<br>
                          possible. But<br>
                                  for now you'd rather keep an eye on
                  these problems.<br>
                  <br>
                  <br>
                              Does it mean it's better to wait a bit for
                  Core<br>
                          improvements from<br>
                              main contributors? Does it make sense to
                  make an efforts to<br>
                              implement SmartPtrItnit checker in current
                  state of things?<br>
                  <br>
                  <br>
                      You should feel free to start working on the
                  checker in an<br>
                      incremental manner (everything is better in an
                  incremental<br>
                      manner!), but in some cases i may prefer improving
                  the checker API<br>
                      or fixing core modeling bugs instead of writing
                  large portions of<br>
                      checker code to work around inconvenient APIs or
                  bugs, and this is<br>
                      something i might not be immediately capable of
                  doing myself (due<br>
                      to being busy with other things), which may
                  potentially delay your<br>
                      progress.<br>
                  <br>
                              Thanks in advance and regards,<br>
                              Alexey K<br>
                  <br>
                              2018-03-16 21:47 GMT+03:00 Artem Dergachev<br>
                          <<a href="mailto:noqnoqneo@gmail.com"
                    target="_blank" moz-do-not-send="true">noqnoqneo@gmail.com</a>
                  <mailto:<a href="mailto:noqnoqneo@gmail.com"
                    target="_blank" moz-do-not-send="true">noqnoqneo@gmail.com</a>><br>
                </div>
              </div>
                          <mailto:<a
                href="mailto:noqnoqneo@gmail.com" target="_blank"
                moz-do-not-send="true">noqnoqneo@gmail.com</a>
              <mailto:<a href="mailto:noqnoqneo@gmail.com"
                target="_blank" moz-do-not-send="true">noqnoqneo@gmail.com</a>>>><wbr>:
              <div>
                <div class="h5"><br>
                  <br>
                  <br>
                                  Dynamic memory management is pretty
                  much done at this<br>
                          point -<br>
                                  we have very good support for
                  malloc()-like stuff and<br>
                                  reasonably good support for operator
                  new() (support for<br>
                                  operator new[]() is currently missing
                  because it requires<br>
                                  calling an indefinite number of
                  constructors which is<br>
                          not yet<br>
                                  implemented). There is also a known
                  issue with custom<br>
                          operator<br>
                                  new(...) returning null pointers - in
                  this case we<br>
                          should not<br>
                                  be calling the constructor but for now
                  we evaluate the<br>
                                  constructor conservatively.<br>
                  <br>
                                  Your real problem will be managing
                  smart pointers<br>
                          themselves<br>
                                  because they are C++ objects that have
                  a myriad of<br>
                          methods,<br>
                                  they can be copied, moved, assigned,
                  move-assigned, they<br>
                                  destroyed, they lifetime-extended, you
                  need to keep all of<br>
                                  this in mind when writing a checker.
                  This is slowly<br>
                          getting<br>
                                  easier because i'm currently working
                  on that, but until<br>
                                  recently it wasn't working correctly
                  in the core, let<br>
                          alone<br>
                                  checkers, which is why the few
                  experimental C++<br>
                          checkers that<br>
                                  we currently have required heavy hacks
                  to become<br>
                          possible. But<br>
                                  for now you'd rather keep an eye on
                  these problems.<br>
                  <br>
                                  On 16/03/2018 3:57 AM, Aleksei Sidorin
                  via cfe-dev wrote:<br>
                  <br>
                                      Hi Alexey!<br>
                  <br>
                                      Could you share your ideas of
                  checker design? It is<br>
                                      possible that problems you met can
                  be solved in<br>
                          different<br>
                                      (maybe even better) way if we know
                  the whole picture.<br>
                                      Regarding your questions, you can
                  find some<br>
                          answers below.<br>
                  <br>
                                      1. a) The first way for checker
                  communication is<br>
                          to share<br>
                                      their program state trait. You can
                  see an example<br>
                          of how<br>
                                      state trait is exported in
                  GenericTaintChecker or<br>
                                      MPIChecker. Generally, you just
                  create a named<br>
                                      ProgramStateTrait in the header.
                  You can take a<br>
                          look at<br>
                                      TaintManager.h and MPITypes.h and
                  how they are used.<br>
                                      b) To set a dependency from
                  another checker, you<br>
                          can just<br>
                                      register it while registering your
                  checker. An<br>
                          example can<br>
                                      be found in MallocChecker where
                  register$Checker also<br>
                                      calls registerCStringCheckerBasic
                  to register a<br>
                          checker it<br>
                                      depends on.<br>
                                      As you pointed, inter-checker
                  communication can<br>
                          become a<br>
                                      source of some problems. Most of
                  them are discussed in<br>
                                      this conversation:<br>
                          <a
href="http://clang-developers.42468.n3.nabble.com/analyzer-RFC-Design-idea-separate-modelling-from-checking-td4059122.html"
                    rel="noreferrer" target="_blank"
                    moz-do-not-send="true">http://clang-developers.42468.<wbr>n3.nabble.com/analyzer-RFC-Des<wbr>ign-idea-separate-modelling-<wbr>from-checking-td4059122.html</a><br>
                          <<a
href="http://clang-developers.42468.n3.nabble.com/analyzer-RFC-Design-idea-separate-modelling-from-checking-td4059122.html"
                    rel="noreferrer" target="_blank"
                    moz-do-not-send="true">http://clang-developers.42468<wbr>.n3.nabble.com/analyzer-RFC-<wbr>Design-idea-separate-modelling<wbr>-from-checking-td4059122.html</a>><br>
                                     <br>
                          <<a
href="http://clang-developers.42468.n3.nabble.com/analyzer-RFC-Design-idea-separate-modelling-from-checking-td4059122.html"
                    rel="noreferrer" target="_blank"
                    moz-do-not-send="true">http://clang-developers.42468<wbr>.n3.nabble.com/analyzer-RFC-<wbr>Design-idea-separate-modelling<wbr>-from-checking-td4059122.html</a><br>
                          <<a
href="http://clang-developers.42468.n3.nabble.com/analyzer-RFC-Design-idea-separate-modelling-from-checking-td4059122.html"
                    rel="noreferrer" target="_blank"
                    moz-do-not-send="true">http://clang-developers.42468<wbr>.n3.nabble.com/analyzer-RFC-<wbr>Design-idea-separate-modelling<wbr>-from-checking-td4059122.html</a>><wbr>><br>
                  <br>
                                      2. I think there is nothing bad in
                  sharing RegionState<br>
                                      across checkers in the way shown
                  in 1a.<br>
                  <br>
                                      3. Artem Dergachev has done some
                  excellent work on<br>
                                      improvement of operator 'new'
                  processing in CSA<br>
                          engine.<br>
                                      Regarding checkers, I can see some
                  on<br>
                          <a
                    href="https://clang-analyzer.llvm.org/potential_checkers.html"
                    rel="noreferrer" target="_blank"
                    moz-do-not-send="true">https://clang-analyzer.llvm.or<wbr>g/potential_checkers.html</a><br>
                          <<a
                    href="https://clang-analyzer.llvm.org/potential_checkers.html"
                    rel="noreferrer" target="_blank"
                    moz-do-not-send="true">https://clang-analyzer.llvm.o<wbr>rg/potential_checkers.html</a>><br>
                                     <br>
                          <<a
                    href="https://clang-analyzer.llvm.org/potential_checkers.html"
                    rel="noreferrer" target="_blank"
                    moz-do-not-send="true">https://clang-analyzer.llvm.o<wbr>rg/potential_checkers.html</a><br>
                          <<a
                    href="https://clang-analyzer.llvm.org/potential_checkers.html"
                    rel="noreferrer" target="_blank"
                    moz-do-not-send="true">https://clang-analyzer.llvm.o<wbr>rg/potential_checkers.html</a>>>:<br>
                                      for example,
                  undefbehavior.AutoptrsOwnSameO<wbr>bj. You can<br>
                                      search this list to find more.<br>
                  <br>
                  <br>
                                      15.03.2018 23:54, Alexey Knyshev
                  via cfe-dev пишет:<br>
                  <br>
                                          Hi there!<br>
                  <br>
                                          While thinking about how it
                  would be possible to<br>
                                          implement various smart ptr
                  related checkers I<br>
                          tried<br>
                                          to review current state of
                  MallocChecker and<br>
                          came up<br>
                                          with that it would be great to
                  have<br>
                          RegionState info<br>
                                          available to other checkers.
                  Could you please<br>
                          share<br>
                                          your points of view and
                  comments on the following<br>
                                          statements / questions:<br>
                  <br>
                                          1. Is there any right way for
                  chaining<br>
                          checkers? How<br>
                                          they are expected to
                  communicate between each<br>
                          other<br>
                                          (excluding generation of nodes
                  /<br>
                          ProgramStates). I've<br>
                                          heard that there are couple of
                  problems caused by<br>
                                          inlining functions,
                  constructors / descructors.<br>
                                          2. What do you think about
                  moving RegionState<br>
                          to the<br>
                                          Core of CSA or providing
                  optional extended info in<br>
                                          MemRegion about the source of
                  such region (new<br>
                                          opearator / array new, malloc,
                  alloca, etc). So it<br>
                                          would be available to all
                  checkers.<br>
                                          3. Is there any roadmap for
                  CSA and especially for<br>
                                          dynamic memory management
                  modeling & related<br>
                          checkers?<br>
                  <br>
                                          Regards, Alexey K<br>
                  <br>
                                          -- <a
                    href="http://linkedin.com/profile" rel="noreferrer"
                    target="_blank" moz-do-not-send="true">linkedin.com/profile</a><br>
                </div>
              </div>
                      <<a href="http://linkedin.com/profile"
                rel="noreferrer" target="_blank" moz-do-not-send="true">http://linkedin.com/profile</a>>
              <<a href="http://linkedin.com/profile" rel="noreferrer"
                target="_blank" moz-do-not-send="true">http://linkedin.com/profile</a>><span
                class=""><br>
                                       <br>
                        <<a
href="https://www.linkedin.com/profile/view?id=AAMAABn6oKQBDhBteiQnWsYm-S9yxT7wQkfWhSw"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://www.linkedin.com/prof<wbr>ile/view?id=AAMAABn6oKQBDhBtei<wbr>QnWsYm-S9yxT7wQkfWhSw</a><br>
                        <<a
href="https://www.linkedin.com/profile/view?id=AAMAABn6oKQBDhBteiQnWsYm-S9yxT7wQkfWhSw"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://www.linkedin.com/prof<wbr>ile/view?id=AAMAABn6oKQBDhBtei<wbr>QnWsYm-S9yxT7wQkfWhSw</a>><br>
                                       <br>
                        <<a
href="https://www.linkedin.com/profile/view?id=AAMAABn6oKQBDhBteiQnWsYm-S9yxT7wQkfWhSw"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://www.linkedin.com/prof<wbr>ile/view?id=AAMAABn6oKQBDhBtei<wbr>QnWsYm-S9yxT7wQkfWhSw</a><br>
                        <<a
href="https://www.linkedin.com/profile/view?id=AAMAABn6oKQBDhBteiQnWsYm-S9yxT7wQkfWhSw"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://www.linkedin.com/prof<wbr>ile/view?id=AAMAABn6oKQBDhBtei<wbr>QnWsYm-S9yxT7wQkfWhSw</a>>>><br>
                <br>
                        <a href="http://github.com/alexeyknyshev"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">github.com/alexeyknyshev</a>
                <<a href="http://github.com/alexeyknyshev"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">http://github.com/alexeyknysh<wbr>ev</a>><br>
                                        <<a
                  href="http://github.com/alexeyknyshev"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">http://github.com/alexeyknysh<wbr>ev</a><br>
                        <<a href="http://github.com/alexeyknyshev"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">http://github.com/alexeyknysh<wbr>ev</a>>><br>
                                        <<a
                  href="http://github.com/alexeyknyshev"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">http://github.com/alexeyknysh<wbr>ev</a><br>
                        <<a href="http://github.com/alexeyknyshev"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">http://github.com/alexeyknysh<wbr>ev</a>><br>
                                        <<a
                  href="http://github.com/alexeyknyshev"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">http://github.com/alexeyknysh<wbr>ev</a><br>
                        <<a href="http://github.com/alexeyknyshev"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">http://github.com/alexeyknysh<wbr>ev</a>>>><br>
                        <a href="http://bitbucket.org/alexeyknyshev"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">bitbucket.org/alexeyknyshev</a>
                <<a href="http://bitbucket.org/alexeyknyshev"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">http://bitbucket.org/alexeykn<wbr>yshev</a>><br>
              </span>
                                      <<a
                href="http://bitbucket.org/alexeyknyshev"
                rel="noreferrer" target="_blank" moz-do-not-send="true">http://bitbucket.org/alexeykn<wbr>yshev</a><span
                class=""><br>
                        <<a href="http://bitbucket.org/alexeyknyshev"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">http://bitbucket.org/alexeykn<wbr>yshev</a>>><br>
                                        <<a
                  href="https://bitbucket.org/alexeyknyshev/"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://bitbucket.org/alexeyk<wbr>nyshev/</a><br>
                        <<a
                  href="https://bitbucket.org/alexeyknyshev/"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://bitbucket.org/alexeyk<wbr>nyshev/</a>><br>
                                        <<a
                  href="https://bitbucket.org/alexeyknyshev/"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://bitbucket.org/alexeyk<wbr>nyshev/</a><br>
                        <<a
                  href="https://bitbucket.org/alexeyknyshev/"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://bitbucket.org/alexeyk<wbr>nyshev/</a>>>><br>
                <br>
                <br>
                                        ______________________________<wbr>_________________<br>
                                        cfe-dev mailing list<br>
                        <a href="mailto:cfe-dev@lists.llvm.org"
                  target="_blank" moz-do-not-send="true">cfe-dev@lists.llvm.org</a>
                <mailto:<a href="mailto:cfe-dev@lists.llvm.org"
                  target="_blank" moz-do-not-send="true">cfe-dev@lists.llvm.org</a><wbr>><br>
              </span>
                      <mailto:<a href="mailto:cfe-dev@lists.llvm.org"
                target="_blank" moz-do-not-send="true">cfe-dev@lists.llvm.org</a>
              <mailto:<a href="mailto:cfe-dev@lists.llvm.org"
                target="_blank" moz-do-not-send="true">cfe-dev@lists.llvm.org</a><wbr>>><span
                class=""><br>
                        <a
                  href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
                        <<a
                  href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">http://lists.llvm.org/cgi-bin<wbr>/mailman/listinfo/cfe-dev</a>><br>
                                       <br>
                        <<a
                  href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">http://lists.llvm.org/cgi-bin<wbr>/mailman/listinfo/cfe-dev</a><br>
                        <<a
                  href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">http://lists.llvm.org/cgi-bin<wbr>/mailman/listinfo/cfe-dev</a>>><br>
                <br>
                <br>
                <br>
                                    --             Best regards,<br>
                                    Aleksei Sidorin,<br>
                                    SRR, Samsung Electronics<br>
                <br>
                <br>
                                    ______________________________<wbr>_________________<br>
                                    cfe-dev mailing list<br>
                        <a href="mailto:cfe-dev@lists.llvm.org"
                  target="_blank" moz-do-not-send="true">cfe-dev@lists.llvm.org</a>
                <mailto:<a href="mailto:cfe-dev@lists.llvm.org"
                  target="_blank" moz-do-not-send="true">cfe-dev@lists.llvm.org</a><wbr>><br>
              </span>
                      <mailto:<a href="mailto:cfe-dev@lists.llvm.org"
                target="_blank" moz-do-not-send="true">cfe-dev@lists.llvm.org</a>
              <mailto:<a href="mailto:cfe-dev@lists.llvm.org"
                target="_blank" moz-do-not-send="true">cfe-dev@lists.llvm.org</a><wbr>>><br>
                      <a
                href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev"
                rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
                      <<a
                href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev"
                rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.llvm.org/cgi-bin<wbr>/mailman/listinfo/cfe-dev</a>><br>
                                 <br>
                      <<a
                href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev"
                rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.llvm.org/cgi-bin<wbr>/mailman/listinfo/cfe-dev</a><br>
                      <<a
                href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev"
                rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.llvm.org/cgi-bin<wbr>/mailman/listinfo/cfe-dev</a>>><br>
              <br>
              <br>
              <br>
              <br>
              <br>
                          -- <a href="http://linkedin.com/profile"
                rel="noreferrer" target="_blank" moz-do-not-send="true">linkedin.com/profile</a>
              <<a href="http://linkedin.com/profile" rel="noreferrer"
                target="_blank" moz-do-not-send="true">http://linkedin.com/profile</a>><span
                class=""><br>
                           <br>
                        <<a
href="https://www.linkedin.com/profile/view?id=AAMAABn6oKQBDhBteiQnWsYm-S9yxT7wQkfWhSw"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://www.linkedin.com/prof<wbr>ile/view?id=AAMAABn6oKQBDhBtei<wbr>QnWsYm-S9yxT7wQkfWhSw</a><br>
                        <<a
href="https://www.linkedin.com/profile/view?id=AAMAABn6oKQBDhBteiQnWsYm-S9yxT7wQkfWhSw"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://www.linkedin.com/prof<wbr>ile/view?id=AAMAABn6oKQBDhBtei<wbr>QnWsYm-S9yxT7wQkfWhSw</a>>><br>
                <br>
                        <a href="http://github.com/alexeyknyshev"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">github.com/alexeyknyshev</a>
                <<a href="http://github.com/alexeyknyshev"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">http://github.com/alexeyknysh<wbr>ev</a>><br>
                        <<a href="http://github.com/alexeyknyshev"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">http://github.com/alexeyknysh<wbr>ev</a><br>
                        <<a href="http://github.com/alexeyknyshev"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">http://github.com/alexeyknysh<wbr>ev</a>>><br>
                        <a href="http://bitbucket.org/alexeyknyshev"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">bitbucket.org/alexeyknyshev</a><br>
                        <<a href="http://bitbucket.org/alexeyknyshev"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">http://bitbucket.org/alexeykn<wbr>yshev</a>><br>
                        <<a
                  href="https://bitbucket.org/alexeyknyshev/"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://bitbucket.org/alexeyk<wbr>nyshev/</a><br>
                        <<a
                  href="https://bitbucket.org/alexeyknyshev/"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://bitbucket.org/alexeyk<wbr>nyshev/</a>>><br>
                <br>
                <br>
                <br>
                <br>
                        --         <a href="http://linkedin.com/profile"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">linkedin.com/profile</a> <<a
                  href="http://linkedin.com/profile" rel="noreferrer"
                  target="_blank" moz-do-not-send="true">http://linkedin.com/profile</a>><br>
                        <<a
href="https://www.linkedin.com/profile/view?id=AAMAABn6oKQBDhBteiQnWsYm-S9yxT7wQkfWhSw"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://www.linkedin.com/prof<wbr>ile/view?id=AAMAABn6oKQBDhBtei<wbr>QnWsYm-S9yxT7wQkfWhSw</a><br>
                        <<a
href="https://www.linkedin.com/profile/view?id=AAMAABn6oKQBDhBteiQnWsYm-S9yxT7wQkfWhSw"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://www.linkedin.com/prof<wbr>ile/view?id=AAMAABn6oKQBDhBtei<wbr>QnWsYm-S9yxT7wQkfWhSw</a>>><br>
                <br>
                        <a href="http://github.com/alexeyknyshev"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">github.com/alexeyknyshev</a>
                <<a href="http://github.com/alexeyknyshev"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">http://github.com/alexeyknysh<wbr>ev</a>><br>
                        <<a href="http://github.com/alexeyknyshev"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">http://github.com/alexeyknysh<wbr>ev</a><br>
                        <<a href="http://github.com/alexeyknyshev"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">http://github.com/alexeyknysh<wbr>ev</a>>><br>
                        <a href="http://bitbucket.org/alexeyknyshev"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">bitbucket.org/alexeyknyshev</a><br>
                        <<a href="http://bitbucket.org/alexeyknyshev"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">http://bitbucket.org/alexeykn<wbr>yshev</a>><br>
                        <<a
                  href="https://bitbucket.org/alexeyknyshev/"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://bitbucket.org/alexeyk<wbr>nyshev/</a><br>
                        <<a
                  href="https://bitbucket.org/alexeyknyshev/"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://bitbucket.org/alexeyk<wbr>nyshev/</a>>><br>
                <br>
                <br>
                <br>
                <br>
                <br>
              </span><span class="">
                -- <br>
                <a href="http://linkedin.com/profile" rel="noreferrer"
                  target="_blank" moz-do-not-send="true">linkedin.com/profile</a>
                <<a
href="https://www.linkedin.com/profile/view?id=AAMAABn6oKQBDhBteiQnWsYm-S9yxT7wQkfWhSw"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://www.linkedin.com/prof<wbr>ile/view?id=AAMAABn6oKQBDhBtei<wbr>QnWsYm-S9yxT7wQkfWhSw</a>><br>
                <br>
                <a href="http://github.com/alexeyknyshev"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">github.com/alexeyknyshev</a>
                <<a href="http://github.com/alexeyknyshev"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">http://github.com/alexeyknysh<wbr>ev</a>><br>
                <a href="http://bitbucket.org/alexeyknyshev"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">bitbucket.org/alexeyknyshev</a>
                <<a href="https://bitbucket.org/alexeyknyshev/"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://bitbucket.org/alexeyk<wbr>nyshev/</a>><br>
              </span></blockquote>
            <br>
          </blockquote>
        </div>
        <br>
        <br clear="all">
        <br>
        -- <br>
        <div class="gmail_signature" data-smartmail="gmail_signature">
          <div dir="ltr"><a
href="https://www.linkedin.com/profile/view?id=AAMAABn6oKQBDhBteiQnWsYm-S9yxT7wQkfWhSw"
              target="_blank" moz-do-not-send="true">linkedin.com/profile</a><br>
            <br>
            <a href="http://github.com/alexeyknyshev" target="_blank"
              moz-do-not-send="true">github.com/alexeyknyshev</a><span></span><span></span><br>
            <a href="https://bitbucket.org/alexeyknyshev/"
              target="_blank" moz-do-not-send="true">bitbucket.org/alexeyknyshev</a><br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>