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: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id E13731F4B5 for ; Tue, 12 Nov 2019 22:39:13 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version:content-type; q=dns; s=default; b=xc0TG shpHPxFLrJHJeXN+sB6+/EQ888rORuc0Igs69rPvSkrOFgtxQM3MU+OanZz4CXv8 m5jlHqe2JHI81UynF3Jj1qn/xkMO1OLn1OSHSV0aG4hy4Oj+KJoKXVOXG9JihAJi ExN2BhemTvhwPpZuhZUsOzWNT9kpEkJBUC50Ys= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version:content-type; s=default; bh=I/cJnFiRBpf fDsku443xgYjcI44=; b=lFVGET33s7eUgLmx7ZGjH00PaROuEopJE/ul5BMo0c4 Z0giT0CiixY9rM30DuCObOMfDy+JWtxa3oejTiEv9FSPhfJ9c18/F4ZYsWHwRmZP wLincXDFkkhldEkeSIRGggq2MfONT4FO5QRGg6H/6XtqBjqUgyoZ50hmA2siu08I = Received: (qmail 65826 invoked by alias); 12 Nov 2019 22:39:12 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 65818 invoked by uid 89); 12 Nov 2019 22:39:11 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: esa3.mentor.iphmx.com IronPort-SDR: Wx0NocX4wzk8TxZ5bMGdVvZTMyU8sZeJSzfYlpWqRblNOllLrJ0cJmoEjEWgsGLJQjIuWtKC31 CZJixJBJo5zwf1binHOBqLKPK4/6V2BmX36b4n/OxReg9bWmzqRyGWycAMnI3eeKdkX+YgvuHO b/nSNw60bvVnCbCaq14XmRqcUwyoDuSAAerFqYwL5mZKUYmtbuZL2mSRHFV9Jc12LJZ/4oQ3US sAIPUl8tWh/aPyEtjOQatCUMZg7mQZKlf+XR0gPo9yQn/4Fj2JOG09nq35fTxAbIDkdDJ/fnrk Zm0= IronPort-SDR: EhGZE0zyfMd8S13ht1xoC7lv592B2EadLeAXWdWUS3LNxs8HwVgl6A1NJCxoiBrKDpYKzScjJR KHfcXUyRugQSEhvKV1vDXqq212IjpmBTnOjutab9AQy458Xkq+AGsDrSQN5LAKebeK6dVZk338 gjlitg7C7wK5L27MaAvjasLWhyPmZqdByGegdqr8nhxJfDoQ+HzX5d6ni9C1vk1GwAcRNdHWOH 9sWd39tiyCZldopD/D3qtBhg6q/iw0WnZoRZ056o7v8RpstaNCjZeRIUVu7RhHDqEUUWH4Thrc Xx0= Date: Tue, 12 Nov 2019 22:39:04 +0000 From: Joseph Myers To: Carlos O'Donell CC: Florian Weimer , Sandra Loosemore , Florian Weimer , , Szabolcs Nagy , , Subject: Re: [review v3] slotinfo in struct dtv_slotinfo_list should be flexible array [BZ #25... In-Reply-To: <9bf19b9d-1af1-c830-37e5-cadb06a2b0df@redhat.com> Message-ID: References: <20191112114732.2175B20AF6@gnutoolchain-gerrit.osci.io> <4e7ad8ea-43ae-6af6-d2a9-2a05d42b0cc6@codesourcery.com> <87r22dey2c.fsf@mid.deneb.enyo.de> <320362b6-854f-230e-5db8-af20f66ef838@redhat.com> <87sgmsbuxn.fsf@mid.deneb.enyo.de> <9bf19b9d-1af1-c830-37e5-cadb06a2b0df@redhat.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" On Tue, 12 Nov 2019, Carlos O'Donell wrote: > >> How long will that take and is it OK to leave things in a broken > >> state for that long for a given target like nios2? > > > > Maybe we should back the fix out and see how quickly we can get in the > > other GCC 10 patches? > > I'd like to hear Joseph's opinion on this. I think the GCC fix ought to be backported to GCC 8 and 9 branches (and generically that applies to fixes relevant to building new glibc versions - or to building GCC *with* new glibc versions, sometimes that can justify e.g. selective backports of libsanitizer fixes where new glibc broke it). I don't think we have a basis for backing out this change from glibc at this point. However, if people wish to fix building with GCC 10 on previous glibc release branches (and such fixes have been a common class of glibc patch backports in the past - evidently some people do wish to build glibc release branches with GCC versions that postdate those glibc releases), perhaps it would be better for the release-branch fix just to disable the warning in the affected file rather than backporting the fix from master. -- Joseph S. Myers joseph@codesourcery.com