Strange CFG for `try' blocks

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Strange CFG for `try' blocks

Xin Wang via cfe-dev
Hi everyone,

Recently we've noticed a strange behaviour in CFG construction for
function try blocks. Clang test suite has a test case
SemaCXX/return-noreturn.cpp with functions functionTryBlock{1,2,3}, and
at least for functionTryBlock2 control flow graph looks a bit strange:

$ .../clang -cc1 -nostdsysteminc
.../llvm/tools/clang/test/SemaCXX/return-noreturn.cpp -fsyntax-only
-fcxx-exceptions -Wreturn-type -Wmissing-noreturn -Wno-unreachable-code
-Wno-covered-switch-default -analyze -analyzer-checker debug.DumpCFG
2>&1 | grep functionTryBlock2 -A 19

    int functionTryBlock2(int s)
      [B3 (ENTRY)]
        Succs (1): B0

      [B1]
        T: try ...
        Succs (1): B2

      [B2]
       catch (...):
        1: catch (...) {
    [B2.3]}
        2: 0
        3: return [B2.2];
        Preds (1): B1
        Succs (1): B0

      [B0 (EXIT)]
        Preds (2): B2 B3

The strange place here is in the fact that block [B3] goes directly to
[B0], leaving the block [B1] non-visited. Moreover, for the below three
code examples the generated CFG looks the same:

============ 1 =============

int foo();

int functionTryBlock2(int s) try {
   s += foo();
} catch (...) {
   return s;
}

============ 2 =============

int foo();

int functionTryBlock2(int s) {
   try {
     s += foo();
   } catch (...) {
     return s;
   }
}

============ 3 =============

int foo();

int functionTryBlock2(int s) {
   s += foo();
   try {
   } catch (...) {
     return s;
   }
}

Is it a bug? It seems that `catch' blocks can be stayed without any
predecessors, since they are visited not by `control flow', but by the
exception. But why `try' blocks are not correctly included into CFG? And
how should the correct CFG look like?

--
Best regards,
Ilya Palachev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Strange CFG for `try' blocks

Xin Wang via cfe-dev

On Jun 26, 2017, at 2:42 AM, Ilya Palachev via cfe-dev <[hidden email]> wrote:

Hi everyone,

Recently we've noticed a strange behaviour in CFG construction for function try blocks. Clang test suite has a test case SemaCXX/return-noreturn.cpp with functions functionTryBlock{1,2,3}, and at least for functionTryBlock2 control flow graph looks a bit strange:

$ .../clang -cc1 -nostdsysteminc .../llvm/tools/clang/test/SemaCXX/return-noreturn.cpp -fsyntax-only -fcxx-exceptions -Wreturn-type -Wmissing-noreturn -Wno-unreachable-code -Wno-covered-switch-default -analyze -analyzer-checker debug.DumpCFG 2>&1 | grep functionTryBlock2 -A 19

  int functionTryBlock2(int s)
    [B3 (ENTRY)]
      Succs (1): B0

    [B1]
      T: try ...
      Succs (1): B2

    [B2]
     catch (...):
      1: catch (...) {
  [B2.3]}
      2: 0
      3: return [B2.2];
      Preds (1): B1
      Succs (1): B0

    [B0 (EXIT)]
      Preds (2): B2 B3

The strange place here is in the fact that block [B3] goes directly to [B0], leaving the block [B1] non-visited. Moreover, for the below three code examples the generated CFG looks the same:

============ 1 =============

int foo();

int functionTryBlock2(int s) try {
 s += foo();
} catch (...) {
 return s;
}

============ 2 =============

int foo();

int functionTryBlock2(int s) {
 try {
   s += foo();
 } catch (...) {
   return s;
 }
}

============ 3 =============

int foo();

int functionTryBlock2(int s) {
 s += foo();
 try {
 } catch (...) {
   return s;
 }
}

Is it a bug? It seems that `catch' blocks can be stayed without any predecessors, since they are visited not by `control flow', but by the exception. But why `try' blocks are not correctly included into CFG? And how should the correct CFG look like?


Unfortunately, support for exceptions in the CFG has not been fully implemented.

"Currently exceptions are treated as "black holes", and exception-handling control structures are poorly modeled (to be conservative). This could be much improved for both C++ and Objective-C exceptions.

Anna
--
Best regards,
Ilya Palachev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Loading...