From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id DF0501F55B for ; Thu, 21 May 2020 10:31:18 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 279433840C0B; Thu, 21 May 2020 10:31:18 +0000 (GMT) Received: from mail-out.m-online.net (mail-out.m-online.net [IPv6:2001:a60:0:28:0:1:25:1]) by sourceware.org (Postfix) with ESMTPS id 8B0C93870855 for ; Thu, 21 May 2020 10:31:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8B0C93870855 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=denx.de Authentication-Results: sourceware.org; spf=none smtp.mailfrom=lukma@denx.de Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 49SQrf1JRbz1rtyS; Thu, 21 May 2020 12:31:14 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 49SQrf09Dxz1qqkx; Thu, 21 May 2020 12:31:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id n6LYJVvBpGlJ; Thu, 21 May 2020 12:31:12 +0200 (CEST) X-Auth-Info: 0zaMtww/aQdvW8fe0ClUSvo61q0/yWyTfLTjcf+DeLc= Received: from jawa (85-222-111-42.dynamic.chello.pl [85.222.111.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Thu, 21 May 2020 12:31:12 +0200 (CEST) Date: Thu, 21 May 2020 12:31:11 +0200 From: Lukasz Majewski To: Joseph Myers Subject: Re: [PATCH v2 6/7] y2038: linux: Provide __ntp_gettime64 implementation Message-ID: <20200521123111.49ba6319@jawa> In-Reply-To: References: <20200508145640.16336-1-lukma@denx.de> <20200508145640.16336-7-lukma@denx.de> <1cb96b4a-3e56-0b31-32f4-136be4d7ae10@linaro.org> <20200519222048.7e212556@jawa> <20200520190817.7072b493@jawa> Organization: denx.de X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/gjuSvZNn_Jx9o/lCadn82.l"; protocol="application/pgp-signature" X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Florian Weimer , Andreas Schwab , GNU C Library , Alistair Francis Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" --Sig_/gjuSvZNn_Jx9o/lCadn82.l Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Joseph, > On Wed, 20 May 2020, Lukasz Majewski wrote: >=20 > > I'm wondering if those archs use different set of gcc switches for > > compilation? =20 >=20 > No. But there are various architecture-specific aspects to > optimization that may result in warnings showing up on only some > architectures. >=20 > Florian has fixed this bug. >=20 > > And another question (I think related) - after updating the the > > glibc -master (there was a switch to gcc 10 for > > build-many-glibc.py) I do have an issue with "check-compilers" task > > on those archs. =20 >=20 > A check-compilers failure simply means that one of the tasks from the=20 > "compilers" run failed. >=20 > In general, if you did a "compilers" run when the build was broken, > you will have an incomplete set of compilers that isn't good for > testing subsequent glibc changes and will need to rerun "compilers" > with the source trees in an unbroken state. Yes, you are 100% correct. That was the case - I wanted to rebuild compilers after update to gcc 10 for build-many-glibc.py. As a result I used the broken glibc for building compilers. Thanks for explanation. >=20 > > Joseph, do you use updated setup? =20 >=20 > My bots using GCC release branches only rebuild "compilers" once a > week. That means a short-lived glibc build breakage is likely to show > up as a failure in "glibcs" rather than "compilers" (but if the build > is broken at the wrong time, when "compilers" runs, the "glibcs" > builds will be using the broken compilers for a week). >=20 > My bot using GCC master rebuilds the compilers every time (but only > runs once a day, whereas the ones using GCC release branches will run > more frequently if there are new glibc changes to test). >=20 Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de --Sig_/gjuSvZNn_Jx9o/lCadn82.l Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEgAyFJ+N6uu6+XupJAR8vZIA0zr0FAl7GWG8ACgkQAR8vZIA0 zr1SgwgAzK6eb1b2Nf3e0gcVzXcMCXFrpEmBq7RdhaS8Z1aAwLzrtBkgCRM0bP/A bmbD8Kl2xWG6dehzWc+eO8HZJu8SRDyzbl0bZSb5GLNAdJ9uMsnYj5le7H5OdJaJ qL69AzojFpu7BgIiNv2G3HVJtRS5/GkIOQQsG1nEq2Fki7VFJkId9DxwMl04hPq6 sRJeII4rebekj76DTAwNF9+kVEOqfulB/xZqJOGXXUuDm2UUd9u54aM77Tfoi44P G/LWPu767o5zTVexGRji67ZFV5MKTIe4bKuU2V0RnPGJYxzf3sTz6teHtrJ5ys6K GXf+tMqiCPfczz59ajzkb1j/9wfLkg== =wcip -----END PGP SIGNATURE----- --Sig_/gjuSvZNn_Jx9o/lCadn82.l--