This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Deprecate -frepo option.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]