Re: [creduce-bugs] crash --transformation=reduce-pointer-level

Hi Yang

Very strange/fragile situation.

And sounds like I hit some gcc-ICEs during reduction.
May be 'instable/sporadic' ICEs (hmmm... what its may be?) interfere with reduction process?

I'll try investigate further.

I have 4 variants after reduction:

-- from crashed version -- 32 lines/795 bytes

-- yesterday not crashed -- 42 lines/1263 bytes

-- one from today run -- 13 lines / 328 bytes

-- second from today -- 11 lines / 293 bytes

1) Run-time vary in range 350--850 secs
2) '--sllooww' key has no effect

3) today's reduction produces 5 times one output and 2 times the different one

4) yesterday's reduction twice produces the same results

-- 32.ii : best from crashed creduce

-- 42.ii : from yesterday

-- 13.ii : one from today

-- 11.ii : second from today

42.ii and 13.ii and 11.ii was produced by the same creduce-git-master-top-of-tree (as yesterday evening) + llvm-3.5.0-precompiled-from-llvm.org

Fedora 21 / x86_64 was updated today morinng.

How to reproduce

1) build gcc-trunk rev.220090

(my cmd is:
~/src/gcc_current/configure --prefix=/usr/local/gcc_current --enable-static --enable-checking=yes,df,fold,rtl --enable-languages=c,c++,lto --enable-plugin --disable-libstdcxx-dual-abi --disable-multilib && make
)

2) cp 42.ii t.ii

3) creduce ./c.sh t.ii

And one more strangeness:

if I change 'grep test' in script from
egrep "internal compiler error|too many memory references for" res

to
grep "too many memory references for" res

then there are many messages : shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory

and reduction is more deep. Probably smth with catch gcc-ICE?

In past when I run tests with compilers errors and hit ICE then extended grep-test can catch ICE.

And in past I can isolate ICE and reduce further without it.

Very interesting what is different now :)

Thank you,

Dmitry

2015-01-26 5:09 GMT+03:00 Yang Chen <chenyang@cs.utah.edu>:

Hi Dmitry

Thanks for reporting this!

I've seen similar behavior before. My guess is that we might suffer from the phase-ordering problem. If it doesn't require too much effort, can you send us the reduced test case in your second case and the script that orchestrated the reduction? I will check if C-Reduce miss some obvious reduction opportunities. You don't need to reproduce the crashing behavior. Thanks.

- Yang

On 01/25/2015 11:32 AM, Дмитрий Дьяченко wrote:

Hi,

sorry for noise.

I rebuild creduce from scratch and there are no crashes.

I use: Fedora 21/x86_x64, creduce-git-top-of-tree, clang-3.5.0-precompiled-from-llvm.org.

But I have strange additional result:

-- prev (crashed) version works 740 secs and reduce 17KLOC (400Kb) down to 32 lines (795 bytes)

-- new (without craches) works 840 secs and reduce downto 42 lines (1263 bytes)

If you are interested I can try reproduce this. Currently I dont know exactly about crached version how it was compiled and from which sources.

Thank you, sorry once again for noise.

Dmitry

2015-01-25 21:39 GMT+03:00 Дмитрий Дьяченко <dimhen@gmail.com>:

Hi!

With creduce-git, clang 3.7.0 (trunk 227039) Fedora 21/x86_64
I get 2 similar crashes

/usr/local/creduce/libexec/clang_delta --transformation=reduce-pointer-level --counter=4|5 ...

Thanks,

Dmitry