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-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-4.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI,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 DCA3A1F8C6 for ; Tue, 17 Aug 2021 23:34:47 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id AD99C382CC2D for ; Tue, 17 Aug 2021 23:34:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AD99C382CC2D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1629243285; bh=e6XMr/tEP8ajm1xMTAvmH6LEp0KYJW2ti5A/2zYJhaE=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=EAbwFycdx9rT+A/2hkOCvRpyofZQ0M1f3R8tSHFd8LGjSUYTo7cPclzBbrYJ+LpHb EnNcIBGxDNT+hGs0m9o21Kle5NfVFwy4ymM3jSqkVGTlY+OCOhR2Lar/V1LsG7dgR2 Y7zC9PdZt1LVpNVZVY+6+e2QYoDegJm9pXQmvHRg= Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) by sourceware.org (Postfix) with ESMTPS id 8DA38383F42C for ; Tue, 17 Aug 2021 23:33:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8DA38383F42C Received: by mail-ej1-x62e.google.com with SMTP id h9so1049058ejs.4 for ; Tue, 17 Aug 2021 16:33:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=d7I381UOgt8GnWBy6HNvmhcl9qnbRMlh1/cMmWCN/pI=; b=jC/J/iwBy9g0WzPfcM6P0a9QUZaXB6FiivCRjQusujRRj/gyp4zjg4HFQcFmssH9Qf s40SQ11bJ9IdwHI2l0ZfzYeIzAhYfrYO+brQ23+OTrNaPBPUUoFmX2HYoDwr9lXKsGcK +kbOX52prYoa7l8QFaAhVNGBhZqkp1BesNlukqcr1iH2ptYJp0iHk7yEEHmMN/ok6vOc KETglZZUhoDhJP1JnoC9M5Ms8LcGKso4N5SnXCIZtRTh0dnpkZQtoLxlyLPmRp0UsIhy VGqyaNmuPYw+wqp5jNzTET8ooRJz/l2qjyMDeXquCzS9Y44WMPF7OfnT6hsYjx9ZSIiw Ymxw== X-Gm-Message-State: AOAM53247O44+z0oq0AhRyNQFjtIBGDwtEjhy8a9frsc6psmBDkfhyan E+ZrXXDWOoFuYsGe6leXKM/9TezFIf6HzDFbi6MbC5lW X-Google-Smtp-Source: ABdhPJy4H11CmoUeFIowF9xFtQnNvOTIWDkpOaCUZdO6Xvocggb75g2JWu0x2lFzNWtSoxhAlQVg0MFZrDiQJkVz9y0= X-Received: by 2002:a17:906:1e42:: with SMTP id i2mr6638346ejj.76.1629243225684; Tue, 17 Aug 2021 16:33:45 -0700 (PDT) MIME-Version: 1.0 References: <20210806094217.3227877-1-shorne@gmail.com> <0f577bc8-bef8-6c06-aaa9-57bf16d8443b@linaro.org> In-Reply-To: Date: Wed, 18 Aug 2021 08:33:33 +0900 Message-ID: Subject: Re: [PATCH v2] time: Fix overflow itimer tests on 32-bit systems To: Joseph Myers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: , From: Stafford Horne via Libc-alpha Reply-To: Stafford Horne Cc: Openrisc , GLIBC patches Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On Tue, Aug 17, 2021, 7:33 AM Joseph Myers wrote: > On Tue, 17 Aug 2021, Stafford Horne via Libc-alpha wrote: > > > Should we provide __KERNEL_OLD_TIMEVAL_MATCHES_TIMEVAL64 for not linux > builds, > > or remove __KERNEL_OLD_TIMEVAL_MATCHES_TIMEVAL64 from the itimer test > again? > > The reason for using __KERNEL_OLD_TIMEVAL_MATCHES_TIMEVAL64 is to pick > up the > > timeval size which is different on each architecture. > > I'd suggest having a macro that doesn't refer to either "kernel" or "old > timeval" (and that is defined for both Linux and Hurd). As far as I > understand, the logical concept that's relevant for this test isn't either > one of those, it's more like "setitimer supports times that cannot be > represented in 32 bits". > Hello, That makes sense, currently with the hurd build being broken how urgent is this? I worked on reproducing the build issue with build-many but didn't get it working yet, probably about 80% there before I ran out of time. I'll try to get it fixed in a few days as my top priority, but I only have an hour or two a day to look at it. If we need to revert or add a temporary patch please feel free. -stafford >