Dropping support of repo files (tlink)

classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Dropping support of repo files (tlink)

Martin Liška-2
Hi.

In order to not buffer stderr output in LTO mode, I would like to remove
support for repo files (tlink). If I'm correctly it's only used by AIX
target. Would it be possible to drop that for the future? Is it even
used?

Thank you,
Martin
Reply | Threaded
Open this post in threaded view
|

Re: Dropping support of repo files (tlink)

David Edelsohn-2
On Thu, Jun 20, 2019 at 10:05 AM Martin Liška <[hidden email]> wrote:
>
> Hi.
>
> In order to not buffer stderr output in LTO mode, I would like to remove
> support for repo files (tlink). If I'm correctly it's only used by AIX
> target. Would it be possible to drop that for the future? Is it even
> used?

AIX currently does not support GCC LTO, but the hope was that GCC
would not do anything to specifically inhibit that ability to
eventually support that feature. AIX currently needs collect2.  I
guess that AIX could try to find another mechanism when it adds
support.

Thanks, David
Reply | Threaded
Open this post in threaded view
|

Re: Dropping support of repo files (tlink)

Iain Sandoe

> On 20 Jun 2019, at 15:21, David Edelsohn <[hidden email]> wrote:
>
> On Thu, Jun 20, 2019 at 10:05 AM Martin Liška <[hidden email]> wrote:
>>
>> Hi.
>>
>> In order to not buffer stderr output in LTO mode, I would like to remove
>> support for repo files (tlink). If I'm correctly it's only used by AIX
>> target. Would it be possible to drop that for the future? Is it even
>> used?
>
> AIX currently does not support GCC LTO, but the hope was that GCC
> would not do anything to specifically inhibit that ability to
> eventually support that feature. AIX currently needs collect2.  I
> guess that AIX could try to find another mechanism when it adds
> support.

Darwin needs collect2,  but does not use the tlink facility.
thanks
Iain

Reply | Threaded
Open this post in threaded view
|

Re: Dropping support of repo files (tlink)

Martin Liška-2
In reply to this post by David Edelsohn-2
On 6/20/19 4:21 PM, David Edelsohn wrote:

> On Thu, Jun 20, 2019 at 10:05 AM Martin Liška <[hidden email]> wrote:
>>
>> Hi.
>>
>> In order to not buffer stderr output in LTO mode, I would like to remove
>> support for repo files (tlink). If I'm correctly it's only used by AIX
>> target. Would it be possible to drop that for the future? Is it even
>> used?
>
> AIX currently does not support GCC LTO, but the hope was that GCC
> would not do anything to specifically inhibit that ability to
> eventually support that feature. AIX currently needs collect2.  I
> guess that AIX could try to find another mechanism when it adds
> support.

Yes, I'm fine with collect2. I'm more precisely asking about read_report_files
that lives in tlink.c. If I understand correctly, it's parsing output of linker
and tries to find template implementations in a .rpo files that live on a disk.
That's a legacy functionality that I'm targeting to remove.

Thanks,
Martin

>
> Thanks, David
>

Reply | Threaded
Open this post in threaded view
|

Re: Dropping support of repo files (tlink)

Richard Biener-2
On June 20, 2019 5:09:55 PM GMT+02:00, "Martin Liška" <[hidden email]> wrote:

>On 6/20/19 4:21 PM, David Edelsohn wrote:
>> On Thu, Jun 20, 2019 at 10:05 AM Martin Liška <[hidden email]> wrote:
>>>
>>> Hi.
>>>
>>> In order to not buffer stderr output in LTO mode, I would like to
>remove
>>> support for repo files (tlink). If I'm correctly it's only used by
>AIX
>>> target. Would it be possible to drop that for the future? Is it even
>>> used?
>>
>> AIX currently does not support GCC LTO, but the hope was that GCC
>> would not do anything to specifically inhibit that ability to
>> eventually support that feature. AIX currently needs collect2.  I
>> guess that AIX could try to find another mechanism when it adds
>> support.
>
>Yes, I'm fine with collect2. I'm more precisely asking about
>read_report_files
>that lives in tlink.c. If I understand correctly, it's parsing output
>of linker
>and tries to find template implementations in a .rpo files that live on
>a disk.
>That's a legacy functionality that I'm targeting to remove.

IIRC -frepo also works on Linux?

Richard.

>Thanks,
>Martin
>
>>
>> Thanks, David
>>

Reply | Threaded
Open this post in threaded view
|

Re: Dropping support of repo files (tlink)

Martin Liška-2
On 6/20/19 9:53 PM, Richard Biener wrote:

> On June 20, 2019 5:09:55 PM GMT+02:00, "Martin Liška" <[hidden email]> wrote:
>> On 6/20/19 4:21 PM, David Edelsohn wrote:
>>> On Thu, Jun 20, 2019 at 10:05 AM Martin Liška <[hidden email]> wrote:
>>>>
>>>> Hi.
>>>>
>>>> In order to not buffer stderr output in LTO mode, I would like to
>> remove
>>>> support for repo files (tlink). If I'm correctly it's only used by
>> AIX
>>>> target. Would it be possible to drop that for the future? Is it even
>>>> used?
>>>
>>> AIX currently does not support GCC LTO, but the hope was that GCC
>>> would not do anything to specifically inhibit that ability to
>>> eventually support that feature. AIX currently needs collect2.  I
>>> guess that AIX could try to find another mechanism when it adds
>>> support.
>>
>> Yes, I'm fine with collect2. I'm more precisely asking about
>> read_report_files
>> that lives in tlink.c. If I understand correctly, it's parsing output
>> of linker
>> and tries to find template implementations in a .rpo files that live on
>> a disk.
>> That's a legacy functionality that I'm targeting to remove.
>
> IIRC -frepo also works on Linux?

Heh, you are right ;). Is there are consumer of that infrastructure
or can we just drop it?

Martin

>
> Richard.
>
>> Thanks,
>> Martin
>>
>>>
>>> Thanks, David
>>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Dropping support of repo files (tlink)

Jonathan Wakely-4
On Fri, 21 Jun 2019 at 11:22, Martin Liška <[hidden email]> wrote:

>
> On 6/20/19 9:53 PM, Richard Biener wrote:
> > On June 20, 2019 5:09:55 PM GMT+02:00, "Martin Liška" <[hidden email]> wrote:
> >> On 6/20/19 4:21 PM, David Edelsohn wrote:
> >>> On Thu, Jun 20, 2019 at 10:05 AM Martin Liška <[hidden email]> wrote:
> >>>>
> >>>> Hi.
> >>>>
> >>>> In order to not buffer stderr output in LTO mode, I would like to
> >> remove
> >>>> support for repo files (tlink). If I'm correctly it's only used by
> >> AIX
> >>>> target. Would it be possible to drop that for the future? Is it even
> >>>> used?
> >>>
> >>> AIX currently does not support GCC LTO, but the hope was that GCC
> >>> would not do anything to specifically inhibit that ability to
> >>> eventually support that feature. AIX currently needs collect2.  I
> >>> guess that AIX could try to find another mechanism when it adds
> >>> support.
> >>
> >> Yes, I'm fine with collect2. I'm more precisely asking about
> >> read_report_files
> >> that lives in tlink.c. If I understand correctly, it's parsing output
> >> of linker
> >> and tries to find template implementations in a .rpo files that live on
> >> a disk.
> >> That's a legacy functionality that I'm targeting to remove.
> >
> > IIRC -frepo also works on Linux?
>
> Heh, you are right ;). Is there are consumer of that infrastructure
> or can we just drop it?

Anybody using option 2 at
https://gcc.gnu.org/onlinedocs/gcc/Template-Instantiation.html

I have no idea if anybody is using that, but we should at least
deprecate it instead of just dropping a documented option without
warning.
Reply | Threaded
Open this post in threaded view
|

Re: Dropping support of repo files (tlink)

Iain Sandoe

> On 21 Jun 2019, at 11:28, Jonathan Wakely <[hidden email]> wrote:
>
> On Fri, 21 Jun 2019 at 11:22, Martin Liška <[hidden email]> wrote:
>>
>> On 6/20/19 9:53 PM, Richard Biener wrote:
>>> On June 20, 2019 5:09:55 PM GMT+02:00, "Martin Liška" <[hidden email]> wrote:
>>>> On 6/20/19 4:21 PM, David Edelsohn wrote:
>>>>> On Thu, Jun 20, 2019 at 10:05 AM Martin Liška <[hidden email]> wrote:
>>>>>>
>>>>>> Hi.
>>>>>>
>>>>>> In order to not buffer stderr output in LTO mode, I would like to
>>>> remove
>>>>>> support for repo files (tlink). If I'm correctly it's only used by
>>>> AIX
>>>>>> target. Would it be possible to drop that for the future? Is it even
>>>>>> used?
>>>>>
>>>>> AIX currently does not support GCC LTO, but the hope was that GCC
>>>>> would not do anything to specifically inhibit that ability to
>>>>> eventually support that feature. AIX currently needs collect2.  I
>>>>> guess that AIX could try to find another mechanism when it adds
>>>>> support.
>>>>
>>>> Yes, I'm fine with collect2. I'm more precisely asking about
>>>> read_report_files
>>>> that lives in tlink.c. If I understand correctly, it's parsing output
>>>> of linker
>>>> and tries to find template implementations in a .rpo files that live on
>>>> a disk.
>>>> That's a legacy functionality that I'm targeting to remove.
>>>
>>> IIRC -frepo also works on Linux?
>>
>> Heh, you are right ;). Is there are consumer of that infrastructure
>> or can we just drop it?
>
> Anybody using option 2 at
> https://gcc.gnu.org/onlinedocs/gcc/Template-Instantiation.html
>
> I have no idea if anybody is using that, but we should at least
> deprecate it instead of just dropping a documented option without
> warning.

I should have been clearer about Darwin:

collect2 is required because it wraps the calling of lto-wrapper and ld.

FWIW Darwin also passes all the “-frepo” testcases, however, I’m not aware of anyone actually
using case #2 from Jonathan’s post.

So, AFAIK the tlink capability isn’t required for modern C++ on Darwin; but, maybe deprecation is a
safer step.

Iain

Reply | Threaded
Open this post in threaded view
|

Re: Dropping support of repo files (tlink)

Martin Liška-2
On 6/21/19 12:34 PM, Iain Sandoe wrote:

>
>> On 21 Jun 2019, at 11:28, Jonathan Wakely <[hidden email]> wrote:
>>
>> On Fri, 21 Jun 2019 at 11:22, Martin Liška <[hidden email]> wrote:
>>>
>>> On 6/20/19 9:53 PM, Richard Biener wrote:
>>>> On June 20, 2019 5:09:55 PM GMT+02:00, "Martin Liška" <[hidden email]> wrote:
>>>>> On 6/20/19 4:21 PM, David Edelsohn wrote:
>>>>>> On Thu, Jun 20, 2019 at 10:05 AM Martin Liška <[hidden email]> wrote:
>>>>>>>
>>>>>>> Hi.
>>>>>>>
>>>>>>> In order to not buffer stderr output in LTO mode, I would like to
>>>>> remove
>>>>>>> support for repo files (tlink). If I'm correctly it's only used by
>>>>> AIX
>>>>>>> target. Would it be possible to drop that for the future? Is it even
>>>>>>> used?
>>>>>>
>>>>>> AIX currently does not support GCC LTO, but the hope was that GCC
>>>>>> would not do anything to specifically inhibit that ability to
>>>>>> eventually support that feature. AIX currently needs collect2.  I
>>>>>> guess that AIX could try to find another mechanism when it adds
>>>>>> support.
>>>>>
>>>>> Yes, I'm fine with collect2. I'm more precisely asking about
>>>>> read_report_files
>>>>> that lives in tlink.c. If I understand correctly, it's parsing output
>>>>> of linker
>>>>> and tries to find template implementations in a .rpo files that live on
>>>>> a disk.
>>>>> That's a legacy functionality that I'm targeting to remove.
>>>>
>>>> IIRC -frepo also works on Linux?
>>>
>>> Heh, you are right ;). Is there are consumer of that infrastructure
>>> or can we just drop it?
>>
>> Anybody using option 2 at
>> https://gcc.gnu.org/onlinedocs/gcc/Template-Instantiation.html
>>
>> I have no idea if anybody is using that, but we should at least
>> deprecate it instead of just dropping a documented option without
>> warning.
>
> I should have been clearer about Darwin:
>
> collect2 is required because it wraps the calling of lto-wrapper and ld.
>
> FWIW Darwin also passes all the “-frepo” testcases, however, I’m not aware of anyone actually
> using case #2 from Jonathan’s post.
>
> So, AFAIK the tlink capability isn’t required for modern C++ on Darwin; but, maybe deprecation is a
> safer step.

Thank you for the information.

Yes, I would be fine to deprecate that for GCC 10.1

Martin

>
> Iain
>

Reply | Threaded
Open this post in threaded view
|

Re: Dropping support of repo files (tlink)

Jonathan Wakely-4
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?

I think in most cases the "fix" would be to simply remove the -frepo
option from your makefiles (or other build system) and let the linker
handle things. You'd get larger object files and slower links, but it
should work.
Reply | Threaded
Open this post in threaded view
|

Re: Dropping support of repo files (tlink)

Iain Sandoe
In reply to this post by Martin Liška-2

> On 21 Jun 2019, at 11:40, Martin Liška <[hidden email]> wrote:
>
> On 6/21/19 12:34 PM, Iain Sandoe wrote:
>>
>>> On 21 Jun 2019, at 11:28, Jonathan Wakely <[hidden email]> wrote:
>>>
>>> On Fri, 21 Jun 2019 at 11:22, Martin Liška <[hidden email]> wrote:
>>>>
>>>> On 6/20/19 9:53 PM, Richard Biener wrote:
>>>>> On June 20, 2019 5:09:55 PM GMT+02:00, "Martin Liška" <[hidden email]> wrote:
>>>>>> On 6/20/19 4:21 PM, David Edelsohn wrote:
>>>>>>> On Thu, Jun 20, 2019 at 10:05 AM Martin Liška <[hidden email]> wrote:
>>>>>>>>
>>>>>>>> Hi.
>>>>>>>>
>>>>>>>> In order to not buffer stderr output in LTO mode, I would like to
>>>>>> remove
>>>>>>>> support for repo files (tlink). If I'm correctly it's only used by
>>>>>> AIX
>>>>>>>> target. Would it be possible to drop that for the future? Is it even
>>>>>>>> used?
>>>>>>>
>>>>>>> AIX currently does not support GCC LTO, but the hope was that GCC
>>>>>>> would not do anything to specifically inhibit that ability to
>>>>>>> eventually support that feature. AIX currently needs collect2.  I
>>>>>>> guess that AIX could try to find another mechanism when it adds
>>>>>>> support.
>>>>>>
>>>>>> Yes, I'm fine with collect2. I'm more precisely asking about
>>>>>> read_report_files
>>>>>> that lives in tlink.c. If I understand correctly, it's parsing output
>>>>>> of linker
>>>>>> and tries to find template implementations in a .rpo files that live on
>>>>>> a disk.
>>>>>> That's a legacy functionality that I'm targeting to remove.
>>>>>
>>>>> IIRC -frepo also works on Linux?
>>>>
>>>> Heh, you are right ;). Is there are consumer of that infrastructure
>>>> or can we just drop it?
>>>
>>> Anybody using option 2 at
>>> https://gcc.gnu.org/onlinedocs/gcc/Template-Instantiation.html
>>>
>>> I have no idea if anybody is using that, but we should at least
>>> deprecate it instead of just dropping a documented option without
>>> warning.
>>
>> I should have been clearer about Darwin:
>>
>> collect2 is required because it wraps the calling of lto-wrapper and ld.
>>
>> FWIW Darwin also passes all the “-frepo” testcases, however, I’m not aware of anyone actually
>> using case #2 from Jonathan’s post.
>>
>> So, AFAIK the tlink capability isn’t required for modern C++ on Darwin; but, maybe deprecation is a
>> safer step.
>
> Thank you for the information.
>
> Yes, I would be fine to deprecate that for GCC 10.1

“thinking aloud” - would it work to deprecate (or even disallow immediately if no-one is using it) LTO + frepo?
(so that non-LTO frepo continues as long as anyone needs it)


Iain




Reply | Threaded
Open this post in threaded view
|

Re: Dropping support of repo files (tlink)

Richard Biener-2
On Fri, Jun 21, 2019 at 1:50 PM Iain Sandoe <[hidden email]> wrote:

>
>
> > On 21 Jun 2019, at 11:40, Martin Liška <[hidden email]> wrote:
> >
> > On 6/21/19 12:34 PM, Iain Sandoe wrote:
> >>
> >>> On 21 Jun 2019, at 11:28, Jonathan Wakely <[hidden email]> wrote:
> >>>
> >>> On Fri, 21 Jun 2019 at 11:22, Martin Liška <[hidden email]> wrote:
> >>>>
> >>>> On 6/20/19 9:53 PM, Richard Biener wrote:
> >>>>> On June 20, 2019 5:09:55 PM GMT+02:00, "Martin Liška" <[hidden email]> wrote:
> >>>>>> On 6/20/19 4:21 PM, David Edelsohn wrote:
> >>>>>>> On Thu, Jun 20, 2019 at 10:05 AM Martin Liška <[hidden email]> wrote:
> >>>>>>>>
> >>>>>>>> Hi.
> >>>>>>>>
> >>>>>>>> In order to not buffer stderr output in LTO mode, I would like to
> >>>>>> remove
> >>>>>>>> support for repo files (tlink). If I'm correctly it's only used by
> >>>>>> AIX
> >>>>>>>> target. Would it be possible to drop that for the future? Is it even
> >>>>>>>> used?
> >>>>>>>
> >>>>>>> AIX currently does not support GCC LTO, but the hope was that GCC
> >>>>>>> would not do anything to specifically inhibit that ability to
> >>>>>>> eventually support that feature. AIX currently needs collect2.  I
> >>>>>>> guess that AIX could try to find another mechanism when it adds
> >>>>>>> support.
> >>>>>>
> >>>>>> Yes, I'm fine with collect2. I'm more precisely asking about
> >>>>>> read_report_files
> >>>>>> that lives in tlink.c. If I understand correctly, it's parsing output
> >>>>>> of linker
> >>>>>> and tries to find template implementations in a .rpo files that live on
> >>>>>> a disk.
> >>>>>> That's a legacy functionality that I'm targeting to remove.
> >>>>>
> >>>>> IIRC -frepo also works on Linux?
> >>>>
> >>>> Heh, you are right ;). Is there are consumer of that infrastructure
> >>>> or can we just drop it?
> >>>
> >>> Anybody using option 2 at
> >>> https://gcc.gnu.org/onlinedocs/gcc/Template-Instantiation.html
> >>>
> >>> I have no idea if anybody is using that, but we should at least
> >>> deprecate it instead of just dropping a documented option without
> >>> warning.
> >>
> >> I should have been clearer about Darwin:
> >>
> >> collect2 is required because it wraps the calling of lto-wrapper and ld.
> >>
> >> FWIW Darwin also passes all the “-frepo” testcases, however, I’m not aware of anyone actually
> >> using case #2 from Jonathan’s post.
> >>
> >> So, AFAIK the tlink capability isn’t required for modern C++ on Darwin; but, maybe deprecation is a
> >> safer step.
> >
> > Thank you for the information.
> >
> > Yes, I would be fine to deprecate that for GCC 10.1
>
> “thinking aloud” - would it work to deprecate (or even disallow immediately if no-one is using it) LTO + frepo?
> (so that non-LTO frepo continues as long as anyone needs it)

Does that even work? ;)  It would need an intermediate compile-step to
instantiate templates to
another LTO object.

Richard.

>
> Iain
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Dropping support of repo files (tlink)

Jan Hubicka-2
> > >> I should have been clearer about Darwin:
> > >>
> > >> collect2 is required because it wraps the calling of lto-wrapper and ld.
> > >>
> > >> FWIW Darwin also passes all the “-frepo” testcases, however, I’m not aware of anyone actually
> > >> using case #2 from Jonathan’s post.
> > >>
> > >> So, AFAIK the tlink capability isn’t required for modern C++ on Darwin; but, maybe deprecation is a
> > >> safer step.
> > >
> > > Thank you for the information.
> > >
> > > Yes, I would be fine to deprecate that for GCC 10.1
> >
> > “thinking aloud” - would it work to deprecate (or even disallow immediately if no-one is using it) LTO + frepo?
> > (so that non-LTO frepo continues as long as anyone needs it)
>
> Does that even work? ;)  It would need an intermediate compile-step to
> instantiate templates to
> another LTO object.

It is iterating the linker executions so it definitly makes no sense.
One problem is that in the collect2 at the time of deciding whether
to open temporary file for the linker output (which is the problem
Martin tries to solve) we do not know yet whether we will do -flto
(because that will be decided by linker plugin later) or repo
(because it works by looking for .repo files only after the link-step
failed).

I suppose we could block -frepo when -flto is on the command line that
is most common case for LTO builds arriving to bit odd situation that at
link-time -flto will effect nothing but colors of diagnostics
(I would really like to have this solved for gcc 10 in some way)

Honza
>
> Richard.
>
> >
> > Iain
> >
> >
> >
> >
Reply | Threaded
Open this post in threaded view
|

Re: Dropping support of repo files (tlink)

Iain Sandoe

> On 21 Jun 2019, at 13:49, Jan Hubicka <[hidden email]> wrote:
>
>>>>> I should have been clearer about Darwin:
>>>>>
>>>>> collect2 is required because it wraps the calling of lto-wrapper and ld.
>>>>>
>>>>> FWIW Darwin also passes all the “-frepo” testcases, however, I’m not aware of anyone actually
>>>>> using case #2 from Jonathan’s post.
>>>>>
>>>>> So, AFAIK the tlink capability isn’t required for modern C++ on Darwin; but, maybe deprecation is a
>>>>> safer step.
>>>>
>>>> Thank you for the information.
>>>>
>>>> Yes, I would be fine to deprecate that for GCC 10.1
>>>
>>> “thinking aloud” - would it work to deprecate (or even disallow immediately if no-one is using it) LTO + frepo?
>>> (so that non-LTO frepo continues as long as anyone needs it)
>>
>> Does that even work? ;)  It would need an intermediate compile-step to
>> instantiate templates to
>> another LTO object.
>
> It is iterating the linker executions so it definitly makes no sense.
> One problem is that in the collect2 at the time of deciding whether
> to open temporary file for the linker output (which is the problem
> Martin tries to solve) we do not know yet whether we will do -flto
> (because that will be decided by linker plugin later) or repo
> (because it works by looking for .repo files only after the link-step
> failed).

for “non ELF” (at least for Darwin) we decide by scanning the object files
using simple object - if any LTO section is seen, we spawn lto-wrapper,
else we just proceed with a normal link.

That used to be horribly inefficient (it was a new “nm & grep " process per
object)- but we fixed that during 9 - still too heavy?

> I suppose we could block -frepo when -flto is on the command line that
> is most common case for LTO builds arriving to bit odd situation that at
> link-time -flto will effect nothing but colors of diagnostics
> (I would really like to have this solved for gcc 10 in some way)

the point is - if it can’t work, then it may as well be disallowed - and then the
LTO path knows it doesn’t need to do the tlink stuff.

(and tlink can remain for non-LTO frepo)

Iain

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Deprecate -frepo option.

Jonathan Wakely-4
In reply to this post by Jonathan Wakely-4
On Thu, 27 Jun 2019 at 13:30, Martin Liška <[hidden email]> wrote:

>
> On 6/21/19 4:28 PM, Richard Biener wrote:
> > On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek <[hidden email]> 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?

I don't know. It's nearly 20 years since I've tried it, but apparently
a few people try using it:
https://stackoverflow.com/search?q=frepo+c%2B%2B

The first result was answered by me in 2012 saying nobody uses it:
https://stackoverflow.com/a/11832613/981959
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Deprecate -frepo option.

Jason Merrill
On Thu, Jun 27, 2019 at 10:23 AM Martin Liška <[hidden email]> wrote:

>
> On 6/27/19 2:58 PM, Jonathan Wakely wrote:
> > On Thu, 27 Jun 2019 at 13:30, Martin Liška <[hidden email]> wrote:
> >>
> >> On 6/21/19 4:28 PM, Richard Biener wrote:
> >>> On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek <[hidden email]> 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?
> >
> > I don't know. It's nearly 20 years since I've tried it, but apparently
> > a few people try using it:
> > https://stackoverflow.com/search?q=frepo+c%2B%2B
> >
> > The first result was answered by me in 2012 saying nobody uses it:
> > https://stackoverflow.com/a/11832613/981959
>
> Looks at this, it seems to me very legacy and I would recommend to remove it.

It's useful on targets without COMDAT support.  Are there any such
that we care about at this point?

If the problem is the combination with LTO, why not just prohibit that?

Jason
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Deprecate -frepo option.

Iain Sandoe

> On 27 Jun 2019, at 19:21, Jan Hubicka <[hidden email]> wrote:
>
>>
>> It's useful on targets without COMDAT support.  Are there any such
>> that we care about at this point?
>>
>> If the problem is the combination with LTO, why not just prohibit that?
>
> The problem is that at the collect2 time we want to decide whether to
> hold stderr/stdout of the linker. The issue is that we do not know yet
> if we are going to LTO (because that is decided by linker plugin) or
> whether we do repo files (because we look for those only after linker
> failure).

you could pre-scan for LTO, as is done for the collect2+non-plugin linker.
(similar to the comment below, that would take some time, but probably
small c.f the actual link).
Iain

> We can look for repo files first but that could take some time
> especially for large programs (probably not too bad compared to actual
> linking later) or we may require -frepo to be passed to collect2.
>
> Honza
>>
>> Jason

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Deprecate -frepo option.

Richard Biener-2
In reply to this post by Jonathan Wakely-4
On Mon, Jul 8, 2019 at 2:04 PM Martin Liška <[hidden email]> wrote:

>
> On 6/21/19 4:28 PM, Richard Biener wrote:
> > On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek <[hidden email]> 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?
>
> I've just tested tramp3d, and it does not survive linking:
>
> g++ tramp3d-v4.o
> collect: recompiling tramp3d-v4.cpp
> collect: relinking
> collect: recompiling tramp3d-v4.cpp
> collect: relinking
> collect: recompiling tramp3d-v4.cpp
> collect: relinking
> collect: recompiling tramp3d-v4.cpp
> collect: relinking
> collect: recompiling tramp3d-v4.cpp
> collect: relinking
> collect: recompiling tramp3d-v4.cpp
> collect: relinking
> collect: recompiling tramp3d-v4.cpp
> collect: relinking
> collect: recompiling tramp3d-v4.cpp
> collect: relinking
> collect: recompiling tramp3d-v4.cpp
> collect: relinking
> collect: recompiling tramp3d-v4.cpp
> collect: relinking
> collect: recompiling tramp3d-v4.cpp
> collect: relinking
> collect: recompiling tramp3d-v4.cpp
> collect: relinking
> collect: recompiling tramp3d-v4.cpp
> collect: relinking
> collect: recompiling tramp3d-v4.cpp
> collect: relinking
> collect: recompiling tramp3d-v4.cpp
> collect: relinking
> collect: recompiling tramp3d-v4.cpp
> collect: relinking
> collect: recompiling tramp3d-v4.cpp
> collect: relinking
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: /tmp/ccEeuyj7.ltrans0.ltrans.o: in function `RefCountedBlockPtr<FieldEngineBaseData<3, Vector<3, double, Full>, ViewEngine<3, IndexFunction<GenericURM<MeshTraits<3, double, UniformRectilinearTag, CartesianTag, 3> >::PositionsFunctor> > >, false, RefBlockController<FieldEngineBaseData<3, Vector<3, double, Full>, ViewEngine<3, IndexFunction<GenericURM<MeshTraits<3, double, UniformRectilinearTag, CartesianTag, 3> >::PositionsFunctor> > > > >::RefCountedBlockPtr(RefCountedBlockPtr<FieldEngineBaseData<3, Vector<3, double, Full>, ViewEngine<3, IndexFunction<GenericURM<MeshTraits<3, double, UniformRectilinearTag, CartesianTag, 3> >::PositionsFunctor> > >, false, RefBlockController<FieldEngineBaseData<3, Vector<3, double, Full>, ViewEngine<3, IndexFunction<GenericURM<MeshTraits<3, double, UniformRectilinearTag, CartesianTag, 3> >::PositionsFunctor> > > > > const&)':
> <artificial>:(.text+0x4181b): undefined reference to `RefCountedPtr<RefBlockController<FieldEngineBaseData<3, Vector<3, double, Full>, ViewEngine<3, IndexFunction<GenericURM<MeshTraits<3, double, UniformRectilinearTag, CartesianTag, 3> >::PositionsFunctor> > > > >::RefCountedPtr(RefCountedPtr<RefBlockController<FieldEngineBaseData<3, Vector<3, double, Full>, ViewEngine<3, IndexFunction<GenericURM<MeshTraits<3, double, UniformRectilinearTag, CartesianTag, 3> >::PositionsFunctor> > > > > const&)'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: /tmp/ccEeuyj7.ltrans0.ltrans.o: in function `std::_Vector_base<Node<Range<3>, Interval<3> >, std::allocator<Node<Range<3>, Interval<3> > > >::_Vector_impl::~_Vector_impl()':
> <artificial>:(.text+0xc1890): undefined reference to `std::allocator<Node<Range<3>, Interval<3> > >::~allocator()'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: /tmp/ccEeuyj7.ltrans0.ltrans.o: in function `std::_Vector_base<Node<Range<3>, Interval<3> >, std::allocator<Node<Range<3>, Interval<3> > > >::_Vector_base()':
> <artificial>:(.text+0xc18aa): undefined reference to `std::_Vector_base<Node<Range<3>, Interval<3> >, std::allocator<Node<Range<3>, Interval<3> > > >::_Vector_impl::_Vector_impl()'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: /tmp/ccEeuyj7.ltrans0.ltrans.o: in function `std::vector<INode<3>, std::allocator<INode<3> > >::_S_use_relocate()':
> <artificial>:(.text+0xc496f): undefined reference to `std::vector<INode<3>, std::allocator<INode<3> > >::_S_nothrow_relocate(std::integral_constant<bool, true>)'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: /tmp/ccEeuyj7.ltrans0.ltrans.o: in function `std::_Vector_base<Node<Range<3>, Interval<3> >, std::allocator<Node<Range<3>, Interval<3> > > >::~_Vector_base()':
> <artificial>:(.text+0xc4cc1): undefined reference to `std::_Vector_base<Node<Range<3>, Interval<3> >, std::allocator<Node<Range<3>, Interval<3> > > >::_M_deallocate(Node<Range<3>, Interval<3> >*, unsigned long)'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: /tmp/ccEeuyj7.ltrans0.ltrans.o: in function `DataBlockPtr<double, false>::DataBlockPtr()':
> <artificial>:(.text+0xc6f96): undefined reference to `RefCountedBlockPtr<double, false, DataBlockController<double> >::RefCountedBlockPtr()'
> [... many other undefined references ...]
>
> 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.

> 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).

Also the docs suggest that -frepo is the only way to get template
instantiation commoning
if the target object format doesn't support sth like linkonce or
comdats.  Not sure if we need
to care though.  I don't remember any bugs about -frepo in many last
years but that could
be because it's perfect (well, it is not as seen above, but...).

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.

Jason/Nathan?

Thanks,
Richard.

> Martin
>
> > 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
>
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Deprecate -frepo option.

Nathan Sidwell-2
On 7/9/19 6:39 AM, Richard Biener wrote:
> On Mon, Jul 8, 2019 at 2:04 PM Martin Liška <[hidden email]> 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?  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.

nathan

--
Nathan Sidwell
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Deprecate -frepo option.

Nathan Sidwell-2
On 7/10/19 7:28 AM, Martin Liška wrote:

> Great, thank you.
>
> There's a patch for deprecating of the option in GCC 9 changes.
>
> May I install the patch right now or should I wait?
>

I think there needs to be a code patch so that use of the option gives a
warning.

nathan

--
Nathan Sidwell
12