From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 900CA386F819 for ; Wed, 6 May 2020 23:15:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 900CA386F819 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=segher@kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 046NFR9D032402; Wed, 6 May 2020 18:15:27 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 046NFRxk032400; Wed, 6 May 2020 18:15:27 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 6 May 2020 18:15:26 -0500 From: Segher Boessenkool To: Dennis Clarke Cc: gcc-help Subject: Re: WARNING: program timed out. Message-ID: <20200506231526.GY31009@gate.crashing.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-14.8 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, TXREP, T_SPF_HELO_PERMERROR, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 23:15:33 -0000 Hi! On Wed, May 06, 2020 at 11:55:58AM +0000, Dennis Clarke via Gcc-help wrote: > I have a four stage bootstrap that took a very very very long time to > complete. Mostly due to the fact that I enabled code checks : > > > --enable-bootstrap --enable-stage1-languages=c,c++ \ > --enable-checking=assert,misc,tree,gc,rtlflag,runtime,df,rtl,gcac,extra \ > --enable-stage1-checking=assert,misc,tree,gc,rtlflag,runtime,df,rtl,gcac,extra > \ > > > So this was fun to let it run and it did run where time -p reports : > > . > . > . > sparc64-sun-solaris2.10/sparcv8plus/libstdc++-v3/src/filesystem/cow-dir.o > differs > sparc64-sun-solaris2.10/sparcv8plus/libstdc++-v3/src/filesystem/ops.o > differs > sparc64-sun-solaris2.10/sparcv8plus/libstdc++-v3/src/filesystem/dir.o > differs > sparc64-sun-solaris2.10/sparcv8plus/libstdc++-v3/src/filesystem/path.o > differs > sparc64-sun-solaris2.10/sparcv8plus/libstdc++-v3/src/filesystem/cow-ops.o > differs > sparc64-sun-solaris2.10/sparcv8plus/libstdc++-v3/src/c++17/fs_ops.o differs > sparc64-sun-solaris2.10/sparcv8plus/libstdc++-v3/src/c++17/fs_dir.o differs > sparc64-sun-solaris2.10/sparcv8plus/libstdc++-v3/src/c++17/cow-fs_path.o > differs > sparc64-sun-solaris2.10/sparcv8plus/libstdc++-v3/src/c++17/cow-fs_dir.o > differs > sparc64-sun-solaris2.10/sparcv8plus/libstdc++-v3/src/c++17/cow-fs_ops.o > differs > sparc64-sun-solaris2.10/sparcv8plus/libstdc++-v3/src/c++17/fs_path.o differs > gmake[2]: *** [Makefile:27282: compare3] Error 1 > gmake[2]: Leaving directory > '/opt/bw/build/gcc-9.2.0_SunOS5.10_sparc64vii+.003' > gmake[1]: *** [Makefile:27262: stage4-bubble] Error 2 > gmake[1]: Leaving directory > '/opt/bw/build/gcc-9.2.0_SunOS5.10_sparc64vii+.003' > gmake: *** [Makefile:27325: bootstrap4] Error 2 > > real 14078843.31 > user 13593892.79 > sys 437633.30 > beta$ > > I was surprised to see stage 3 and stage 4 differ in any way given that > stage 2 and stage 3 seemed perfect : > > > beta$ > beta$ ls -ltrEin */xgcc */xg++ > 4387682 -rwxr-xr-x 1 16411 20002 8106984 2019-11-16 > 22:53:28.194322200 +0000 stage1-gcc/xgcc > 4388403 -rwxr-xr-x 1 16411 20002 8115680 2019-11-16 > 22:53:50.102071100 +0000 stage1-gcc/xg++ > 4723452 -rwxr-xr-x 1 16411 20002 10271968 2019-12-30 > 20:32:32.671996900 +0000 stage2-gcc/xgcc > 4724042 -rwxr-xr-x 1 16411 20002 10284208 2019-12-30 > 20:38:02.458504400 +0000 stage2-gcc/xg++ > 4871655 -rwxr-xr-x 1 16411 20002 10271968 2020-02-22 > 08:38:28.492670800 +0000 prev-gcc/xgcc > 4871806 -rwxr-xr-x 1 16411 20002 10284208 2020-02-22 > 08:46:59.188336600 +0000 prev-gcc/xg++ > 4455418 -rwxr-xr-x 1 16411 20002 10271952 2020-04-16 > 04:10:05.877113800 +0000 gcc/xgcc > 4455567 -rwxr-xr-x 1 16411 20002 10284184 2020-04-16 > 04:18:39.998805900 +0000 gcc/xg++ > beta$ Those are the compiler drivers, tiny programs compared to the compilers themselves, which are called cc1, cc1plus, etc. > May as well let the testsuite run ... however I see a ton of : > > . > . > . > FAIL: gcc.c-torture/execute/20040709-1.c -O3 -fomit-frame-pointer > -funroll-loops -fpeel-loops -ftracer -finline-functions (test for > excess errors) > WARNING: program timed out. > FAIL: gcc.c-torture/execute/20040709-1.c -O3 -g (test for excess errors) > WARNING: program timed out. > FAIL: gcc.c-torture/execute/20040709-1.c -Os (test for excess errors) > WARNING: program timed out. > FAIL: gcc.c-torture/execute/20040709-1.c -O2 -flto > -flto-partition=none (test for excess errors) > WARNING: program timed out. > . > . > . > > I am guessing that there must be a "magic" testsuite incantation that > allows the tests to run as slowly as they wish? Anyone know? 1) Get a faster machine; 2) Change the timeouts (variables "timeout" and/or "gcc,timeout", in a site.exp file perhaps); 3) Consider that the code might actually be in an infinite loop, the default timeouts are quite generous, forever takes longer than any finite stretch of time :-) Segher