From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 45370 invoked by alias); 9 Jul 2019 17:48:35 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 43431 invoked by uid 89); 9 Jul 2019 17:48:27 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*RU:209.85.210.194, HX-Spam-Relays-External:209.85.210.194, HX-Languages-Length:1744 X-HELO: mail-pf1-f194.google.com Received: from mail-pf1-f194.google.com (HELO mail-pf1-f194.google.com) (209.85.210.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 09 Jul 2019 17:48:25 +0000 Received: by mail-pf1-f194.google.com with SMTP id y15so9654429pfn.5; Tue, 09 Jul 2019 10:48:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=C0fpb0Ex+L/NGiD8dxwauDVNHUSbCC9swET4BJ8rWn0=; b=ZZymfkHCsXa80Brj6a7Bbxa+IfRaHlOaFLduQnb2BgXzIC5Rt/6034pT302hxKBNf2 3xp1c/IrK4GTsJG9PpxDnWuDwDYsSOGQVzD3Owt2RoCYxe9nIXTzfDXuUSBAoVz1W/hy E0avlB0egiqmNL0Q21ctwUscJl0sR8T8Q/EIgb/DV8JnwtX0v9Nn60gYSd47FYWUyRlz Mt/3Gpzhdt2re9IhPK4QDu9q2tdWWbo62vtZPMEqEiTF2Jzp5tIA+a988bGnYanxs8ER ZGsbo1UjOOWcm2jH4cP9bSOhReZ6gKidInokbR4ChWAcv57MXSIS3xYlpQywZ92SV+y5 ii1g== Return-Path: Received: from ?IPv6:2620:10d:c0a3:1407:6972:4c9f:5464:7a6c? ([2620:10d:c091:500::2:88e0]) by smtp.googlemail.com with ESMTPSA id d2sm20876480pgo.0.2019.07.09.10.48.16 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jul 2019 10:48:18 -0700 (PDT) Subject: Re: [PATCH] Deprecate -frepo option. To: =?UTF-8?Q?Martin_Li=c5=a1ka?= , Richard Biener Cc: Jakub Jelinek , Jonathan Wakely , Iain Sandoe , "gcc@gcc.gnu.org" , David Edelsohn , Jan Hubicka , GCC Patches , Jason Merrill References: <884b9feb-3e71-db00-8c72-8e096bf75c1e@suse.cz> <69a11998-93c1-d61d-ba31-ac93bcbb353a@suse.cz> <20190621115838.GX815@tucnak> <79fcb5a4-0eba-d39f-e7ca-389f371cd48c@suse.cz> <20190621141309.GY815@tucnak> <140a1eb3-9652-9516-0274-19977fa3021d@suse.cz> <5c3aaf4a-b68a-f7a1-38b7-2e83182b0bc4@suse.cz> From: Nathan Sidwell Message-ID: Date: Tue, 09 Jul 2019 17:48:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <5c3aaf4a-b68a-f7a1-38b7-2e83182b0bc4@suse.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2019-07/txt/msg00078.txt.bz2 On 7/9/19 9:00 AM, Martin Liška wrote: > On 7/9/19 1:41 PM, Nathan Sidwell wrote: >> On 7/9/19 6:39 AM, Richard Biener wrote: >>> On Mon, Jul 8, 2019 at 2:04 PM Martin Liška wrote: >>>> >> >>>> >>>> Same happens also for GCC7. It does 17 iteration (#define MAX_ITERATIONS 17) and >>>> apparently 17 is not enough to resolve all symbols. And it's really slow. >>> >>> Ouch. >> >> hm, 17 is a magic number.  in C++98 it was the maximum depth of template instantiations that implementations needed to support.  Portable code could not expect more.  So the worst case -frepo behaviour would be 17 iterations. >> >> That's not true any more, it's been 1024 since C++11. >> >> Has a bug been filed about this frepo problem? > > I create a new one: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91125 > >> If not, it suggest those using frepo are not compiling modern C++. >> >>>> That said, I would recommend to remove it :) >>> >>> In the end it's up to the C++ FE maintainers but the above clearly >>> doesn't look promising >>> (not sure if it keeps re-compiling _all_ repo-triggered templates or >>> just incrementally adds >>> them to new object files). >> >>> I'm not opposed to removing -frepo from GCC 10 but then I would start >>> noting it is obsolete >>> on the GCC 9 branch at least. >> >> I concur.  frepo's serial reinvocation of the compiler is not compatible with modern C++ code bases. > > Great. Then I'm sending patch that does the functionality removal. > > Ready to be installed after proper testing & bootstrap? I'd like Jason to render an opinion, and we should mark it obsolete in the gcc 9 branch (how much runway would that give people?) nathan -- Nathan Sidwell