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 <[email protected]>: > 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 Дмитрий Дьяченко <[email protected]>: > >> 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 >> > > >
11.ii
Description: Binary data
12.ii
Description: Binary data
32.ii
Description: Binary data
42.ii
Description: Binary data
c.sh
Description: Bourne shell script
