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=-4.0 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 EA1101F4B5 for ; Tue, 12 Nov 2019 23:12:26 +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:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=h5aUzGPA2OgHbabU kLPf8NHelVHMOewjU1ozEvVSQF1p+LhlLWJJkYRrx3kV3AmtRAtmvCvT7Hm0YsTY M8FDAmQzF1ApwwapAKLdwbT+OFJeEfXnb/0sPGgfKEH4kYxOOyD+5xYzJZOHgiAE xs36LiD75enEtfqdwwFJyUcOhb0= 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:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=+fpUe4mOKCq0TUFqRA7Fw0 pv7fQ=; b=ahnTAXONVwzWdnK4YYAODA2B1jQC4sZ+fn+kCrXgnUaYddaBKBxc5B nwIT8slZD8EVLHpSL+H2+x6zDjlZDc79riHwMdNpUFZjoGATdifiZ6XHJ0OEROhJ ouBIS/jff6poOyUuQl7JwAcupZp3qPQzIcunw6/cQ57NtjFfsFp0M= Received: (qmail 94721 invoked by alias); 12 Nov 2019 23:12:24 -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 94712 invoked by uid 89); 12 Nov 2019 23:12:24 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: esa3.mentor.iphmx.com IronPort-SDR: U2aoXnyDz+us1pb03zkCTISLHYMbP/azxRAwAGAgBl+bqZ0zXRjlDw/BMZsuqt+jHni0Dg3ORs qExbsDRyhKMyVMX1z7qugoxEQDXdygyoAD6k418ifyO0a8+QzhxOz4p6w0RfIW/leTBqvG393Y XUKaAnuQWsw+d7wBZD470aF5BIC0nwgX5dqt2i2icvZpo5B1n8MMqag5OFXrCtsNx9AkEA36Fg ZXxVMw8wEOOi3Z61XbuETvzk8qMjTbuNTF2k+e2XwwS2cQmAeZDH44oGUWkWfm3XikkwCD7DUm 9sQ= IronPort-SDR: r+IYzzB0hbE6aSj71kDjgzhrOFifi59Wv/P1fZlgSXjfOIa9VL4fqjbUz/zYmK4KfBRyY/VqG6 Y6t9tyCmjAz/NV57SWFP4FaOjVq/SND/zFtg5HagQ9DGZXKlDj2s2ooGMllNKjk9UbpD7oYP8i 56wPso6+Uso0QFhpMTjFeNvj9Y7T9N31BJ30UofmLsiF1JnVaeoUkcRo2NQqxLMf9YPZAwlH6h baSv2ZBBtrwigWzYBVEQBo+PrAVDxoSsA23E5NfuDPwIwUOZ5OuX+CzI7X5UxHqrRycdr5rVWX +jk= Subject: Re: [review v3] slotinfo in struct dtv_slotinfo_list should be flexible array [BZ #25... To: Carlos O'Donell , Florian Weimer CC: Joseph Myers , Florian Weimer , , Szabolcs Nagy , , 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> From: Sandra Loosemore Message-ID: <104ddd32-7fd8-c288-0459-e9450687b562@codesourcery.com> Date: Tue, 12 Nov 2019 16:12:14 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <320362b6-854f-230e-5db8-af20f66ef838@redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit On 11/12/19 3:14 PM, Carlos O'Donell wrote: > If the new glibc cannot be compiled with gcc8 or gcc9 for nios2, then that's > a problem though. It immediately makes it difficult to test a new glibc on > existing systems without upgrading the system compiler. > > If there is a backend bug then it absolutely needs to be fixed, and it looks > like Sandra will try that, but that won't reach the affected compilers until > much much later. > > I dislike backing out the changes you made because they are quite nice > cleanups, and the downstream vendors tend to upgrade glibc and gcc and binutils > all in one big group to avoid these issues so I don't expect they will ever > see this problem. It's only us as developers that see the larger version > skew problem. IIUC Intel uses whatever versions of binutils/gcc/glibc that Mentor Graphics gives them (currently 2.32/9.2/2.30 respectively) in their SDK and does not mess with mainline trunk sources at all. I can raise the issue with them, but IIRC this would not be the first time some changes have been made to glibc that require newish tools for building it. > My inclination is to fix the gcc problem, backport the solution to the active > FSF branches, and then that fixes our testers. > > In order of importance: > - Fix all gcc10 issues. > - Fix the nios2 backend issue. > - Backport nios2 backend to active FSF branches. > - Rebuild and test to make sure we are all clean again. Yes, that's my plan. > 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? Preparing and testing a patch for the Nios II GCC bug might take a couple days, but I have another one ahead of it in my queue that I'm trying to finish before Stage 1 closes at the end of the week. So maybe a week maximum? BTW, does this problem affect any other target that tries to use GP-relative addressing for small data, like MIPS? -Sandra