Re: [PATCH] Deprecate -frepo option.

[Jason Merrill <jason@redhat.com>]

On 7/9/19 1:48 PM, Nathan Sidwell wrote:
> 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?)

I haven't noticed any responses to my earlier question: Are there any 
targets without COMDAT support that we still care about?

But given the observation above about the 17 limit, even if there are 
such targets it wouldn't be very useful for modern code.  And if people 
want to compile old code for old platforms, they might as well continue 
to use an old compiler.

So I'm OK with deprecating with a warning for the next GCC 9 release, to 
see if anyone complains, and removing in 10.

Jason