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 [IPv6:2620:52:3:1:0:246e:9693:128c]) (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 42A261F55B for ; Wed, 20 May 2020 17:21:54 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2413B386F800; Wed, 20 May 2020 17:21:53 +0000 (GMT) Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id 213683851C25 for ; Wed, 20 May 2020 17:21:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 213683851C25 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=joseph_myers@mentor.com IronPort-SDR: 9Sv63H6GdcW96amMmqIzkqxV7FVwyp3uNJyfq6iNYsLKLysMfuq4vAZTyezydmFUUj7cK8eOyq AKWIH3btrpld5gFRCrR5U7XCtUojpVgXdTb12/pMmGd4bs8BRLFS2+8c/kDBSly7DV6rPb1ysi qEfCxo13HGlevRuPPJnmgHU/nRNJngnj8sgKs0uh6+QarNU/VYBF8v8VdywR2GcVeIRsyPDbuF 3Oxy5R8ruv4Q8EcwwqYbV9lyZAX4od4+ESUBfGtVZe2fmmfrNf2BjDi32KP0lDHvPW9x/yJgGs YG4= X-IronPort-AV: E=Sophos;i="5.73,414,1583222400"; d="scan'208";a="49099953" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa4.mentor.iphmx.com with ESMTP; 20 May 2020 09:21:48 -0800 IronPort-SDR: rI5Yop9Dl038E+HnfaTnEYmXnr0x0wcraxakceZQ+D6SHK7b6SUz7s9P9yMBjh/UNEwD4hzAhA ANjML1HGrAW4QhO5iw+wMH83+uGCcGZNk8TINCooLRNUL97MjduxRHF9lsGj3JMzUCYA9XXAWk PhlM31Nsfin2M/xNuBautTwFQi5VyFm544HfrKVByx/+ivj9z1w1kbQX1XY29/lHpfdwv3glYD HPRw2OhNqyjVwaatOW6/lA1cz+2AQMfdVuze5zTByp/zP8jyk21mHiw0vcIc0Gw4s8TCt72X3d n4E= Date: Wed, 20 May 2020 17:21:43 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Lukasz Majewski Subject: Re: [PATCH v2 6/7] y2038: linux: Provide __ntp_gettime64 implementation In-Reply-To: <20200520190817.7072b493@jawa> Message-ID: 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> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) 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" On Wed, 20 May 2020, Lukasz Majewski wrote: > I'm wondering if those archs use different set of gcc switches for > compilation? No. But there are various architecture-specific aspects to optimization that may result in warnings showing up on only some architectures. Florian has fixed this bug. > 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. A check-compilers failure simply means that one of the tasks from the "compilers" run failed. 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. > Joseph, do you use updated setup? 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). 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). -- Joseph S. Myers joseph@codesourcery.com