[PATCH] Deprecate -frepo option.

Nathan Sidwell nathan@acm.org
Tue Jul 9 17:48:00 GMT 2019


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 <mliska@suse.cz> 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



More information about the Gcc mailing list