A bug with --constant-propagator and --dump-c

[rladydpf1]

CBMC version: 5.43.0
Operating system: Ubuntu 20.04.4 LTS
Exact command line resulting in the issue:

goto-cc test.c -o test
goto-instrument test --constant-propagator test
goto-instrument test --dump-c test1.c

What happened instead:
test.c :

#include <assert.h>
int ab, bc;
int f(int x) {
    ab = 1 + 1 + 1 + 1;
    bc = ab + x;
    return ab + bc;
}
int main() {
    int a;
    a = -4;
    int b;
    b = nondet();
    a = f(a);
    assert(!(0 <= a && a < 5 && 0 <= b && b < 5));
}

and test1.c:

#include <assert.h>

// f
// file test.c line 5
signed int f(signed int x);
// nondet
// file test.c line 15 function main
signed int nondet(void);

// ab
// file test.c line 3
signed int ab;
// bc
// file test.c line 3
signed int bc;

// f
// file test.c line 5
signed int f(signed int x)
{
  ab = 4;
  bc = 0;
  return ab + bc;
}

// main
// file test.c line 11
signed int main()
{
  signed int a=-4;
  signed int b=nondet();
  a=f(-4);
  /* assertion !(0 <= a && a < 5 && 0 <= b && b < 5) */
  assert(1);
}

The "assert(1);" is invalid.

and another bug case with a recursive function: https://gitlab.com/sosy-lab/benchmarking/sv-benchmarks/-/blob/main/c/recursive-simple/fibo_25-1.c

goto-cc sv-benchmarks/c/recursive-simple/fibo_25-1.c -o fibo
goto-instrument fibo --constant-propagator fibo
goto-instrument fibo --dump-c fibo.c

the fibo.c:

#include <assert.h>
#include <stdlib.h>

// fibo
// file data/cbmc/sv-benchmarks/c/recursive-simple/fibo_25-1.c line 7
signed int fibo(signed int n);
// reach_error
// file data/cbmc/sv-benchmarks/c/recursive-simple/fibo_25-1.c line 4
void reach_error();

// fibo
// file data/cbmc/sv-benchmarks/c/recursive-simple/fibo_25-1.c line 7
signed int fibo(signed int n)
{
  goto __CPROVER_DUMP_L1;
  return 0;

__CPROVER_DUMP_L1:
  ;
  goto __CPROVER_DUMP_L2;
  return 1;

__CPROVER_DUMP_L2:
  ;
  signed int return_value_fibo=fibo(24);
  signed int return_value_fibo$0=fibo(n - 2);
  return return_value_fibo + return_value_fibo$0;
}

// main
// file data/cbmc/sv-benchmarks/c/recursive-simple/fibo_25-1.c line 25
signed int main(void)
{
  signed int x=25;
  signed int result;
  signed int return_value_fibo=fibo(25);
  result = return_value_fibo;
  if(result == 75025)
  {

  ERROR:
    ;
    reach_error();
    abort();
  }

  return 0;
}

// reach_error
// file data/cbmc/sv-benchmarks/c/recursive-simple/fibo_25-1.c line 4
void reach_error()
{
  /* assertion 0 */
  assert(0);
}

"signed int return_value_fibo=fibo(24);" : In this case, you shouldn't have propagate the constant.

[tautschnig]

My hunch is that we’re missing return-value removal before doing constant propagation.

[martin-cs]

Strong suggestion @tautschnig , I would not be at all surprised if that is the case.

@rladydpf1 please could you try two options, each instead of using goto-instrument --constant-propagator:
A. goto-analyzer test --simplify test1 --constants
B. goto-analyzer test --simplify test1 --vsd --vsd-value constants

I am pretty sure they handle return-value removal correctly so if A works, it was that. If A fails but B works then it is a problem with the constants domain.

[rladydpf1]

goto-analyzer test --simplify test1 --constants
goto-instrument test1 --dump-c test1.c

It does work,
test1.c : (Case A)

signed int f(signed int x)
{
  ab = 4;
  bc = 0;
  return 4;
}

signed int main()
{
  signed int a=-4;
  signed int b;
  nondet();
  b = nondet_signed_int();
  f(-4);
  a = 4;
  /* assertion !(0 <= a && a < 5 && 0 <= b && b < 5) */
  assert(!(b >= 0) || b >= 5);
}

however, fibo_25-1.c has stll the same error.

goto-cc sv-benchmarks/c/recursive-simple/fibo_25-1.c fibo
goto-analyzer test --simplify fibo --constants
goto-instrument fibo --dump-c fibo.c

fibo.c : (Case A)

signed int fibo(signed int n)
{
  signed int return_value_fibo=fibo(24);
  signed int return_value_fibo$0=fibo(n + -2);
  return return_value_fibo + return_value_fibo$0;
}

// main
// file data/cbmc/sv-benchmarks/c/recursive-simple/fibo_25-1.c line 25
signed int main(void)
{
  signed int x=25;
  signed int result;
  signed int return_value_fibo=fibo(25);
  result = return_value_fibo;
  if(result == 75025)
  {

  ERROR:
    ;
    reach_error();
    __CPROVER_assume(0);
  }

  return 0;
}

// reach_error
// file data/cbmc/sv-benchmarks/c/recursive-simple/fibo_25-1.c line 4
void reach_error()
{
  /* assertion 0 */
  assert(0);
}

The case B does work:

goto-cc sv-benchmarks/c/recursive-simple/fibo_25-1.c fibo
goto-analyzer fibo --simplify fibo --vsd --vsd-values constants
goto-instrument fibo --dump-c fibo.c

fibo.c : (Case B)

signed int fibo(signed int n)
{
  if(!(n >= 1))
    return 0;

  else
    if(n == 1)
      return 1;

    else
    {
      signed int return_value_fibo=fibo(n - 1);
      signed int return_value_fibo$0=fibo(n - 2);
      return return_value_fibo + return_value_fibo$0;
    }
}

// main
// file data/cbmc/sv-benchmarks/c/recursive-simple/fibo_25-1.c line 25
signed int main(void)
{
  signed int x=25;
  signed int result;
  signed int return_value_fibo=fibo(25);
  result = return_value_fibo;
  if(result == 75025)
  {

  ERROR:
    ;
    reach_error();
    __CPROVER_assume(0);
  }

  return 0;
}

// reach_error
// file data/cbmc/sv-benchmarks/c/recursive-simple/fibo_25-1.c line 4
void reach_error()
{
  /* assertion 0 */
  assert(0);
}

[martin-cs]

@rladydpf1 thanks for testing this out. If A works but goto-instrument doesn't then it is probably an issues like @tautschnig suggests. I have an in-progress patch set that deprecates the functionality in goto-instrument in favour of goto-analyze. Would using A or (probably better) B work for you?

As regards the recursive example, there is a bug in how our abstract interpreter handles recursive programs. We are working on a fix. If you have urgent use-cases then it would be good to know as it would increase the priority.

[jimgrundy]

Isn't this a soundness issue? (Adding soundness label).

[jimgrundy]

Confirmed that this is an issue in the current version 5.63

[martin-cs]

@jimgrundy It is certainly a "this can trash your program and give you wrong results" bugs.

@rladydpf1 does the workaround work for you? How urgent are the recursive examples?