[PATCH] Deprecate -frepo option.

[Martin Liška]

On 6/21/19 4:28 PM, Richard Biener wrote:
> On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek <jakub@redhat.com> wrote:
>>
>> On Fri, Jun 21, 2019 at 04:04:00PM +0200, Martin Liška wrote:
>>> On 6/21/19 1:58 PM, Jakub Jelinek wrote:
>>>> On Fri, Jun 21, 2019 at 01:52:09PM +0200, Martin Liška wrote:
>>>>> On 6/21/19 1:47 PM, Jonathan Wakely wrote:
>>>>>> On Fri, 21 Jun 2019 at 11:40, Martin Liška wrote:
>>>>>>> Yes, I would be fine to deprecate that for GCC 10.1
>>>>>>
>>>>>> Would it be appropriate to issue a warning in GCC 10.x if the option is used?
>>>>>
>>>>> Sure. With the patch attached one will see:
>>>>>
>>>>> $ gcc -frepo /tmp/main.cc -c
>>>>> gcc: warning: switch ‘-frepo’ is no longer supported
>>>>>
>>>>> I'm sending patch that also removes -frepo tests from test-suite.
>>>>> I've been testing the patch.
>>>>
>>>> IMHO for just deprecation of an option you don't want to remove it from the
>>>> testsuite, just match the warning it will generate in those tests, and
>>>> I'm not convinced you want to remove it from the documentation (rather than
>>>> just saying in the documentation that the option is deprecated and might be
>>>> removed in a later GCC version).
>>>
>>> Agree with you. I'm sending updated version of the patch.
>>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>
>> I'm also not convinced about the Deprecated flag, seems like that is a flag
>> that we use for options that have been already removed.
>> So, instead there should be some proper warning in the C++ FE for it,
>> or just Warn.
> 
> In principle -frepo is a nice idea - does it live up to its promises?  That is,
> does it actually work, for example when throwing it on the libstdc++
> testsuite or a larger C++ project? 

@Jonathan, Jason: Do we know whether it really work?

> The option doesn't document
> optimization issues but I assume template bodies are not available
> for IPA optimizations unless -frepo is combined with LTO where the
> template CU[s] then bring them in.
> 
> So I'm not sure - do we really want to remove this feature?
> 
> Richard.
> 
>>         Jakub