Re: [PATCH] Deprecate -frepo option.
On Mon, Sep 09, 2019 at 01:02:32PM +0200, Martin Liška wrote: > On 9/6/19 4:56 PM, Jakub Jelinek wrote: > > On Fri, Sep 06, 2019 at 10:48:53AM -0400, Marek Polacek wrote: > >> On Fri, Sep 06, 2019 at 08:58:48AM +0200, Martin Liška wrote: > >>> Ok, hopefully nobody is strongly against. I've just retested the > >>> patch and installed it as r275450. > >> > >> --- a/gcc/c-family/c.opt > >> +++ b/gcc/c-family/c.opt > >> @@ -1763,8 +1763,8 @@ ObjC ObjC++ LTO Var(flag_replace_objc_classes) > >> Used in Fix-and-Continue mode to indicate that object files may be > >> swapped in at runtime. > >> > >> frepo > >> -C++ ObjC++ > >> -Enable automatic template instantiation. > >> +C++ ObjC++ Deprecated > >> +Deprecated in GCC 10. This switch has no effect. > > > > The Deprecated keyword is just misnamed, I believe it does the same thing as > > Ignore, except that it also prints a warning that the switch is no longer > > supported, so kind like Ignore Warn(switch %<-frepo%> is no longer > > supported). > > The description should be just This switch has no effect. or > > Does nothing. Preserved for backward compatibility. > > I verified the description and it's fine to me: > > frepo > C++ ObjC++ Deprecated > Deprecated in GCC 10. This switch has no effect. This first part looks wrong to me. "deprecated (computing) Obsolescent; said of a construct in a computing language considered old, and planned to be phased out, but still available for use." That is not the case here in GCC 10, the feature has been removed, it has been deprecated in GCC 9.N for N >= 2 only. Jakub
Re: [PATCH] Deprecate -frepo option.
On 9/6/19 4:56 PM, Jakub Jelinek wrote: > On Fri, Sep 06, 2019 at 10:48:53AM -0400, Marek Polacek wrote: >> On Fri, Sep 06, 2019 at 08:58:48AM +0200, Martin Liška wrote: >>> Ok, hopefully nobody is strongly against. I've just retested the >>> patch and installed it as r275450. >> >> --- a/gcc/c-family/c.opt >> +++ b/gcc/c-family/c.opt >> @@ -1763,8 +1763,8 @@ ObjC ObjC++ LTO Var(flag_replace_objc_classes) >> Used in Fix-and-Continue mode to indicate that object files may be swapped >> in at runtime. >> >> frepo >> -C++ ObjC++ >> -Enable automatic template instantiation. >> +C++ ObjC++ Deprecated >> +Deprecated in GCC 10. This switch has no effect. > > The Deprecated keyword is just misnamed, I believe it does the same thing as > Ignore, except that it also prints a warning that the switch is no longer > supported, so kind like Ignore Warn(switch %<-frepo%> is no longer supported). > The description should be just This switch has no effect. or > Does nothing. Preserved for backward compatibility. I verified the description and it's fine to me: frepo C++ ObjC++ Deprecated Deprecated in GCC 10. This switch has no effect. > > Jakub >
Re: [PATCH] Deprecate -frepo option.
On 9/6/19 4:56 PM, Jakub Jelinek wrote: On Fri, Sep 06, 2019 at 10:48:53AM -0400, Marek Polacek wrote: On Fri, Sep 06, 2019 at 08:58:48AM +0200, Martin Liška wrote: Ok, hopefully nobody is strongly against. I've just retested the patch and installed it as r275450. --- a/gcc/c-family/c.opt +++ b/gcc/c-family/c.opt @@ -1763,8 +1763,8 @@ ObjC ObjC++ LTO Var(flag_replace_objc_classes) Used in Fix-and-Continue mode to indicate that object files may be swapped in at runtime. frepo -C++ ObjC++ -Enable automatic template instantiation. +C++ ObjC++ Deprecated +Deprecated in GCC 10. This switch has no effect. The Deprecated keyword is just misnamed, I believe it does the same thing as Ignore, except that it also prints a warning that the switch is no longer supported, so kind like Ignore Warn(switch %<-frepo%> is no longer supported). Exactly. I'll double check it. The description should be just This switch has no effect. or Does nothing. Preserved for backward compatibility. Yep, I'll update the comment. @Marek: Also, https://gcc.gnu.org/gcc-10/changes.html should be updated, both in Caveats and the C++ section. But I can do that. I'll do it once we'll be close to release of GCC 10. I've got quite some changes that I haven't mentioned in yet in changes or porting_to. Martin Jakub
Re: [PATCH] Deprecate -frepo option.
On Fri, Sep 06, 2019 at 10:48:53AM -0400, Marek Polacek wrote: > On Fri, Sep 06, 2019 at 08:58:48AM +0200, Martin Liška wrote: > > Ok, hopefully nobody is strongly against. I've just retested the > > patch and installed it as r275450. > > --- a/gcc/c-family/c.opt > +++ b/gcc/c-family/c.opt > @@ -1763,8 +1763,8 @@ ObjC ObjC++ LTO Var(flag_replace_objc_classes) > Used in Fix-and-Continue mode to indicate that object files may be swapped > in at runtime. > > frepo > -C++ ObjC++ > -Enable automatic template instantiation. > +C++ ObjC++ Deprecated > +Deprecated in GCC 10. This switch has no effect. The Deprecated keyword is just misnamed, I believe it does the same thing as Ignore, except that it also prints a warning that the switch is no longer supported, so kind like Ignore Warn(switch %<-frepo%> is no longer supported). The description should be just This switch has no effect. or Does nothing. Preserved for backward compatibility. Jakub
Re: [PATCH] Deprecate -frepo option.
On Fri, Sep 06, 2019 at 08:58:48AM +0200, Martin Liška wrote: > Ok, hopefully nobody is strongly against. I've just retested the > patch and installed it as r275450. --- a/gcc/c-family/c.opt +++ b/gcc/c-family/c.opt @@ -1763,8 +1763,8 @@ ObjC ObjC++ LTO Var(flag_replace_objc_classes) Used in Fix-and-Continue mode to indicate that object files may be swapped in at runtime. frepo -C++ ObjC++ -Enable automatic template instantiation. +C++ ObjC++ Deprecated +Deprecated in GCC 10. This switch has no effect. But it's not just deprecated, it's removed now, so shouldn't this be Ignored? Also, https://gcc.gnu.org/gcc-10/changes.html should be updated, both in Caveats and the C++ section. But I can do that. Marek
Re: [PATCH] Deprecate -frepo option.
[CCs trimmed]
On 9/6/19 2:58 AM, Martin Liška wrote:
Ok, hopefully nobody is strongly against. I've just retested the
patch and installed it as r275450.
Martin missed a couple of spots. Installing this. 1 bit freed!
nathan
--
Nathan Sidwell
2019-09-06 Nathan Sidwell
PR c++/91125
* cp-tree.h (IDENTIFIER_REPO_CHOSEN, DECL_REPO_AVAILABLE_P): Delete.
(struct lang_decl_base): Remove repo_available_p.
* decl.c (duplicate_decls): Don't copy DECL_REPO_AVAILABLE_P.
Index: cp-tree.h
===
--- cp-tree.h (revision 275455)
+++ cp-tree.h (working copy)
@@ -466,6 +466,5 @@ extern GTY(()) tree cp_global_trees[CPTI
CALL_EXPR_REVERSE_ARGS (in CALL_EXPR, AGGR_INIT_EXPR)
CONSTRUCTOR_PLACEHOLDER_BOUNDARY (in CONSTRUCTOR)
- 6: IDENTIFIER_REPO_CHOSEN (in IDENTIFIER_NODE)
- TYPE_MARKED_P (in _TYPE)
+ 6: TYPE_MARKED_P (in _TYPE)
DECL_NON_TRIVIALLY_INITIALIZED_P (in VAR_DECL)
RANGE_FOR_IVDEP (in RANGE_FOR_STMT)
@@ -1113,10 +1112,4 @@ enum cp_identifier_kind {
TREE_LANG_FLAG_5 (IDENTIFIER_NODE_CHECK (NODE))
-/* True iff NAME is the DECL_ASSEMBLER_NAME for an entity with vague
- linkage which the prelinker has assigned to this translation
- unit. */
-#define IDENTIFIER_REPO_CHOSEN(NAME) \
- (TREE_LANG_FLAG_6 (IDENTIFIER_NODE_CHECK (NAME)))
-
/* True if this identifier is a reserved word. C_RID_CODE (node) is
then the RID_* value of the keyword. Value 1. */
@@ -2591,5 +2584,4 @@ struct GTY(()) lang_decl_base {
unsigned not_really_extern : 1; /* var or fn */
unsigned initialized_in_class : 1; /* var or fn */
- unsigned repo_available_p : 1; /* var or fn */
unsigned threadprivate_or_deleted_p : 1; /* var or fn */
unsigned anticipated_p : 1; /* fn, type or template */
@@ -2602,5 +2594,5 @@ struct GTY(()) lang_decl_base {
unsigned var_declared_inline_p : 1; /* var */
unsigned dependent_init_p : 1; /* var */
- /* 1 spare bit */
+ /* 2 spare bits */
};
@@ -3163,9 +3155,4 @@ struct GTY(()) lang_decl {
(DECL_NON_THUNK_FUNCTION_P (NODE) && DECL_EXTERN_C_P (NODE))
-/* True iff DECL is an entity with vague linkage whose definition is
- available in this translation unit. */
-#define DECL_REPO_AVAILABLE_P(NODE) \
- (DECL_LANG_SPECIFIC (NODE)->u.base.repo_available_p)
-
/* True if DECL is declared 'constexpr'. */
#define DECL_DECLARED_CONSTEXPR_P(DECL) \
Index: decl.c
===
--- decl.c (revision 275455)
+++ decl.c (working copy)
@@ -2389,5 +2389,4 @@ duplicate_decls (tree newdecl, tree oldd
values we should copy from old to new. */
DECL_IN_AGGR_P (newdecl) = DECL_IN_AGGR_P (olddecl);
- DECL_REPO_AVAILABLE_P (newdecl) = DECL_REPO_AVAILABLE_P (olddecl);
DECL_INITIALIZED_IN_CLASS_P (newdecl)
|= DECL_INITIALIZED_IN_CLASS_P (olddecl);
Re: [PATCH] Deprecate -frepo option.
On 9/5/19 2:51 PM, Martin Liška wrote: > On 9/5/19 2:31 PM, Richard Biener wrote: >> On Thu, Sep 5, 2019 at 2:06 PM Jonathan Wakely wrote: >>> >>> On Thu, 5 Sep 2019 at 12:21, Martin Liška wrote: On 9/5/19 1:09 PM, Richard Biener wrote: > So, let's just remove it now? I'm all for that. May I install the patch? >>> >>> To be clear, I wasn't objecting to installing the patch now, just >>> asking whether it would be possible to revert it later if needed. If >>> installing it is a prerequisite for major changes that will happen >>> soon, then reverting it would be difficult. If that's not the case, it >>> seems fine to remove -frepo now. > > No, I'm not planning to work any changes that will depend on the removal. > >> >> Since -frepo is broken and the way it works cannot be fixed for >> modern C++ code-bases there's no point in preserving it, no? > > You are right how I do understand that. > > That said, I hope the community is fine that I'll install the patch? Ok, hopefully nobody is strongly against. I've just retested the patch and installed it as r275450. Martin > > Martin > >> Maybe I misunderstood people though. >> >> Richard. >> >
Re: [PATCH] Deprecate -frepo option.
On 9/5/19 2:31 PM, Richard Biener wrote: > On Thu, Sep 5, 2019 at 2:06 PM Jonathan Wakely wrote: >> >> On Thu, 5 Sep 2019 at 12:21, Martin Liška wrote: >>> >>> On 9/5/19 1:09 PM, Richard Biener wrote: So, let's just remove it now? >>> >>> I'm all for that. May I install the patch? >> >> To be clear, I wasn't objecting to installing the patch now, just >> asking whether it would be possible to revert it later if needed. If >> installing it is a prerequisite for major changes that will happen >> soon, then reverting it would be difficult. If that's not the case, it >> seems fine to remove -frepo now. No, I'm not planning to work any changes that will depend on the removal. > > Since -frepo is broken and the way it works cannot be fixed for > modern C++ code-bases there's no point in preserving it, no? You are right how I do understand that. That said, I hope the community is fine that I'll install the patch? Martin > Maybe I misunderstood people though. > > Richard. >
Re: [PATCH] Deprecate -frepo option.
On Thu, Sep 5, 2019 at 2:06 PM Jonathan Wakely wrote: > > On Thu, 5 Sep 2019 at 12:21, Martin Liška wrote: > > > > On 9/5/19 1:09 PM, Richard Biener wrote: > > > So, let's just remove it now? > > > > I'm all for that. May I install the patch? > > To be clear, I wasn't objecting to installing the patch now, just > asking whether it would be possible to revert it later if needed. If > installing it is a prerequisite for major changes that will happen > soon, then reverting it would be difficult. If that's not the case, it > seems fine to remove -frepo now. Since -frepo is broken and the way it works cannot be fixed for modern C++ code-bases there's no point in preserving it, no? Maybe I misunderstood people though. Richard.
Re: [PATCH] Deprecate -frepo option.
On Thu, 5 Sep 2019 at 12:21, Martin Liška wrote: > > On 9/5/19 1:09 PM, Richard Biener wrote: > > So, let's just remove it now? > > I'm all for that. May I install the patch? To be clear, I wasn't objecting to installing the patch now, just asking whether it would be possible to revert it later if needed. If installing it is a prerequisite for major changes that will happen soon, then reverting it would be difficult. If that's not the case, it seems fine to remove -frepo now.
Re: [PATCH] Deprecate -frepo option.
On 9/5/19 1:09 PM, Richard Biener wrote: > So, let's just remove it now? I'm all for that. May I install the patch? Martin
Re: [PATCH] Deprecate -frepo option.
On Thu, Sep 5, 2019 at 1:02 PM Nathan Sidwell wrote: > > On 9/5/19 6:03 AM, Martin Liška wrote: > > On 9/5/19 12:01 PM, Richard Biener wrote: > >> On Wed, Sep 4, 2019 at 2:57 PM Nathan Sidwell wrote: > >>> > >>> On 9/4/19 7:20 AM, Martin Liška wrote: > On 9/4/19 11:22 AM, Jonathan Wakely wrote: > >>> > >>> > > The point of the warning was to see if users complain. Three weeks > > isn't a very long time to see if users are going to complain :-) > > > > I see :) That said, I'm going to install the patch close to the end > of stage1. > >>> > >>> I think it'd be ok to install it during stage3 (perhaps early feb?). > >>> More chance of people speaking up. > >> > >> I just checked and trunk doesn't spit out a warning for me so this > >> needs people to use 9.2+ to notice. > > > > Yep, it's intentional. Only GCC 9 branch prints the warning: > > > > $ gcc-9 -frepo main.cpp > > cc1plus: warning: ‘-frepo’ is deprecated and will be removed in a future > > release [-Wdeprecated] > > > > As we plan to remove it for trunk, it does not make sense to print the > > warning for trunk. > > IMHO it very much makes sense for trunk to warn. > > old-gcc: deprecated > trunk: not deprectated > conclusion: it is no longer deprecated Once we remove -frepo it will be an option we simply ignore - correct? Then people won't notice it isn't used anymore (unless it fixes the build for them...). OTOH we figured -frepo is broken beyond repair so unless somebody steps up to actually _fix_ its issues I'm not sure what we should do when some people come around and say they use the option? So, let's just remove it now? Richard. > nathan > > -- > Nathan Sidwell
Re: [PATCH] Deprecate -frepo option.
On 9/5/19 6:03 AM, Martin Liška wrote: On 9/5/19 12:01 PM, Richard Biener wrote: On Wed, Sep 4, 2019 at 2:57 PM Nathan Sidwell wrote: On 9/4/19 7:20 AM, Martin Liška wrote: On 9/4/19 11:22 AM, Jonathan Wakely wrote: The point of the warning was to see if users complain. Three weeks isn't a very long time to see if users are going to complain :-) I see :) That said, I'm going to install the patch close to the end of stage1. I think it'd be ok to install it during stage3 (perhaps early feb?). More chance of people speaking up. I just checked and trunk doesn't spit out a warning for me so this needs people to use 9.2+ to notice. Yep, it's intentional. Only GCC 9 branch prints the warning: $ gcc-9 -frepo main.cpp cc1plus: warning: ‘-frepo’ is deprecated and will be removed in a future release [-Wdeprecated] As we plan to remove it for trunk, it does not make sense to print the warning for trunk. IMHO it very much makes sense for trunk to warn. old-gcc: deprecated trunk: not deprectated conclusion: it is no longer deprecated nathan -- Nathan Sidwell
Re: [PATCH] Deprecate -frepo option.
On 9/5/19 12:01 PM, Richard Biener wrote: > On Wed, Sep 4, 2019 at 2:57 PM Nathan Sidwell wrote: >> >> On 9/4/19 7:20 AM, Martin Liška wrote: >>> On 9/4/19 11:22 AM, Jonathan Wakely wrote: >> >> The point of the warning was to see if users complain. Three weeks isn't a very long time to see if users are going to complain :-) >>> >>> I see :) That said, I'm going to install the patch close to the end >>> of stage1. >> >> I think it'd be ok to install it during stage3 (perhaps early feb?). >> More chance of people speaking up. > > I just checked and trunk doesn't spit out a warning for me so this > needs people to use 9.2+ to notice. Yep, it's intentional. Only GCC 9 branch prints the warning: $ gcc-9 -frepo main.cpp cc1plus: warning: ‘-frepo’ is deprecated and will be removed in a future release [-Wdeprecated] As we plan to remove it for trunk, it does not make sense to print the warning for trunk. Martin > > Richard. > >> nathan >> >> -- >> Nathan Sidwell
Re: [PATCH] Deprecate -frepo option.
On Wed, Sep 4, 2019 at 2:57 PM Nathan Sidwell wrote: > > On 9/4/19 7:20 AM, Martin Liška wrote: > > On 9/4/19 11:22 AM, Jonathan Wakely wrote: > > > >> The point of the warning was to see if users complain. Three weeks > >> isn't a very long time to see if users are going to complain :-) > >> > > > > I see :) That said, I'm going to install the patch close to the end > > of stage1. > > I think it'd be ok to install it during stage3 (perhaps early feb?). > More chance of people speaking up. I just checked and trunk doesn't spit out a warning for me so this needs people to use 9.2+ to notice. Richard. > nathan > > -- > Nathan Sidwell
Re: [PATCH] Deprecate -frepo option.
On 9/4/19 7:20 AM, Martin Liška wrote: On 9/4/19 11:22 AM, Jonathan Wakely wrote: The point of the warning was to see if users complain. Three weeks isn't a very long time to see if users are going to complain :-) I see :) That said, I'm going to install the patch close to the end of stage1. I think it'd be ok to install it during stage3 (perhaps early feb?). More chance of people speaking up. nathan -- Nathan Sidwell
Re: [PATCH] Deprecate -frepo option.
On 9/4/19 11:22 AM, Jonathan Wakely wrote: > On Wed, 4 Sep 2019 at 09:13, Martin Liška wrote: >> >> On 7/9/19 3:00 PM, Martin Liška wrote: >>> Great. Then I'm sending patch that does the functionality removal. >> >> Hi. >> >> The GCC 9.2.0 is released and the version contains a deprecation >> warning for -frepo. >> >> Is it the right time now to remove it from trunk? > > If users upgrade to 9.2 in 6 months, see the new warning, and tell us > they're using the feature, will it be possible to re-enable it? Sure, we'll just revert the patch. > > The point of the warning was to see if users complain. Three weeks > isn't a very long time to see if users are going to complain :-) > I see :) That said, I'm going to install the patch close to the end of stage1. Martin
Re: [PATCH] Deprecate -frepo option.
On Wed, 4 Sep 2019 at 09:13, Martin Liška wrote: > > On 7/9/19 3:00 PM, Martin Liška wrote: > > Great. Then I'm sending patch that does the functionality removal. > > Hi. > > The GCC 9.2.0 is released and the version contains a deprecation > warning for -frepo. > > Is it the right time now to remove it from trunk? If users upgrade to 9.2 in 6 months, see the new warning, and tell us they're using the feature, will it be possible to re-enable it? The point of the warning was to see if users complain. Three weeks isn't a very long time to see if users are going to complain :-)
Re: [PATCH] Deprecate -frepo option.
On 7/9/19 3:00 PM, Martin Liška wrote: Great. Then I'm sending patch that does the functionality removal. Hi. The GCC 9.2.0 is released and the version contains a deprecation warning for -frepo. Is it the right time now to remove it from trunk? Thanks, Martin
Re: [PATCH] Deprecate -frepo option.
On Wed, Jul 10, 2019 at 02:53:35PM +0200, Martin Liška wrote: > On 7/10/19 2:48 PM, Nathan Sidwell wrote: > > 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 > > > That's done by 'Deprecated' keyword put on frepo in *.opt file: > > $ ./gcc/xgcc -Bgcc -frepo /tmp/main.c > xgcc: warning: switch ‘-frepo’ is no longer supported > > I've already used the same mechanism for other deprecated options e.g.: > > $ ./gcc/xgcc -Bgcc -mmpx /tmp/main.c > xgcc: warning: switch ‘-mmpx’ is no longer supported That doesn't seem to be correct for GCC 9 and -frepo though, the option will be still supported, but deprecated and to be removed in the next release. I think the Deprecated *.opt keyword is misnamed. Jakub
Re: [PATCH] Deprecate -frepo option.
On 7/10/19 8:53 AM, Martin Liška wrote: nathan That's done by 'Deprecated' keyword put on frepo in *.opt file: $ ./gcc/xgcc -Bgcc -frepo /tmp/main.c xgcc: warning: switch ‘-frepo’ is no longer supported I've already used the same mechanism for other deprecated options e.g.: $ ./gcc/xgcc -Bgcc -mmpx /tmp/main.c xgcc: warning: switch ‘-mmpx’ is no longer supported Great! I must have missed that patch. All good to go for gcc-9 deprecation nathan -- Nathan Sidwell
Re: [PATCH] Deprecate -frepo option.
On 7/10/19 2:48 PM, Nathan Sidwell wrote: > 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 > That's done by 'Deprecated' keyword put on frepo in *.opt file: $ ./gcc/xgcc -Bgcc -frepo /tmp/main.c xgcc: warning: switch ‘-frepo’ is no longer supported I've already used the same mechanism for other deprecated options e.g.: $ ./gcc/xgcc -Bgcc -mmpx /tmp/main.c xgcc: warning: switch ‘-mmpx’ is no longer supported Martin
Re: [PATCH] Deprecate -frepo option.
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
Re: [PATCH] Deprecate -frepo option.
On 7/9/19 11:14 PM, Jason Merrill wrote: > 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 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. 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? Thanks, Martin > > Jason diff --git a/htdocs/gcc-9/changes.html b/htdocs/gcc-9/changes.html index bf9f6db..bec4754 100644 --- a/htdocs/gcc-9/changes.html +++ b/htdocs/gcc-9/changes.html @@ -57,6 +57,11 @@ You may also want to check out our announcement. + + The automatic template instantiation at link time (https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/C_002b_002b-Dialect-Options.html#index-frepo;>-frepo) has been deprecated and +will be removed in a future release. + +
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 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
Re: [PATCH] Deprecate -frepo option.
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 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
Re: [PATCH] Deprecate -frepo option.
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 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? Martin > > nathan > >From 06a298c3381c204b6ed6cf97b05940ebb8abcbde Mon Sep 17 00:00:00 2001 From: Martin Liska Date: Tue, 9 Jul 2019 14:45:05 +0200 Subject: [PATCH] Remove support for repo files (PR c++/91125). gcc/ChangeLog: 2019-07-09 Martin Liska PR c++/91125 * Makefile.in: Remove tlink.o. * collect2.c (do_link): New function isolated from do_tlink. (main): Use. * collect2.h (do_tlink): Remove declaration of do_tlink. * doc/extend.texi: Remove documentation of -frepo. * doc/invoke.texi: Likewise. * doc/sourcebuild.texi: Remove cleanup-repo-files. * tlink.c: Remove. gcc/c-family/ChangeLog: 2019-07-09 Martin Liska PR c++/91125 * c-common.c: Remove definition of flag_use_repository. * c-common.h: Likewise. * c-opts.c (c_common_handle_option): Do not handle OPT_frepo option. * c.opt: Mark the option with Deprecated. gcc/cp/ChangeLog: 2019-07-09 Martin Liska PR c++/91125 * Make-lang.in: Remove repo.o. * config-lang.in: Likewise. * cp-tree.h (init_repo): Remove declarations of repo-related functions. (repo_emit_p): Likewise. (repo_export_class_p): Likewise. (finish_repo): Likewise. * decl2.c (import_export_class): Always set -1 value/ (mark_needed): Remove -frepo from comment. (import_export_decl): Similarly here. (c_parse_final_cleanups): Remove call of finish_repo. * lex.c (cxx_init): Remove call to init_repo. * optimize.c (can_alias_cdtor): Remove dead condition. * pt.c (push_template_decl_real): Update comment. (instantiate_decl): Remove dead code used for -frepo. * repo.c: Remove. gcc/testsuite/ChangeLog: 2019-07-09 Martin Liska PR c++/91125 * g++.dg/parse/repo1.C: Remove. * g++.dg/rtti/repo1.C: Remove. * g++.dg/template/repo1.C: Remove. * g++.dg/template/repo10.C: Remove. * g++.dg/template/repo11.C: Remove. * g++.dg/template/repo2.C: Remove. * g++.dg/template/repo3.C: Remove. * g++.dg/template/repo4.C: Remove. * g++.dg/template/repo5.C: Remove. * g++.dg/template/repo6.C: Remove. * g++.dg/template/repo7.C: Remove. * g++.dg/template/repo8.C: Remove. * g++.dg/template/repo9.C: Remove. * g++.old-deja/g++.pt/instantiate4.C: Remove. * g++.old-deja/g++.pt/instantiate6.C: Remove. * g++.old-deja/g++.pt/repo1.C: Remove. * g++.old-deja/g++.pt/repo2.C: Remove. * g++.old-deja/g++.pt/repo3.C: Remove. * g++.old-deja/g++.pt/repo4.C: Remove. * lib/g++.exp: Remove removal of repo files. * lib/gcc-dg.exp: Likewise. * lib/obj-c++.exp: Likewise. --- gcc/Makefile.in | 2 +- gcc/c-family/c-common.c | 5 - gcc/c-family/c-common.h | 5 - gcc/c-family/c-opts.c | 6 - gcc/c-family/c.opt| 4 +- gcc/collect2.c| 36 +- gcc/collect2.h| 4 +- gcc/cp/Make-lang.in | 2 +- gcc/cp/config-lang.in | 2 +- gcc/cp/cp-tree.h | 6 - gcc/cp/decl2.c| 37 +- gcc/cp/lex.c | 2 - gcc/cp/optimize.c | 3 - gcc/cp/pt.c | 18 +- gcc/cp/repo.c | 374 gcc/doc/extend.texi | 25 - gcc/doc/invoke.texi | 8 +- gcc/doc/sourcebuild.texi | 3 - gcc/testsuite/g++.dg/parse/repo1.C| 10 -
Re: [PATCH] Deprecate -frepo option.
On 7/9/19 6:39 AM, Richard Biener wrote: On Mon, Jul 8, 2019 at 2:04 PM Martin Liška 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
Re: [PATCH] Deprecate -frepo option.
On Mon, Jul 8, 2019 at 2:04 PM Martin Liška wrote: > > On 6/21/19 4:28 PM, Richard Biener wrote: > > On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek 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, > ViewEngine<3, IndexFunction UniformRectilinearTag, CartesianTag, 3> >::PositionsFunctor> > >, false, > RefBlockController, > ViewEngine<3, IndexFunction UniformRectilinearTag, CartesianTag, 3> >::PositionsFunctor> > > > > >::RefCountedBlockPtr(RefCountedBlockPtr double, Full>, ViewEngine<3, IndexFunction UniformRectilinearTag, CartesianTag, 3> >::PositionsFunctor> > >, false, > RefBlockController, > ViewEngine<3, IndexFunction UniformRectilinearTag, CartesianTag, 3> >::PositionsFunctor> > > > > const&)': > :(.text+0x4181b): undefined reference to > `RefCountedPtr Full>, ViewEngine<3, IndexFunction UniformRectilinearTag, CartesianTag, 3> >::PositionsFunctor> > > > > >::RefCountedPtr(RefCountedPtr Vector<3, double, Full>, ViewEngine<3, IndexFunction 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, > Interval<3> >, std::allocator, Interval<3> > > > >::_Vector_impl::~_Vector_impl()': > :(.text+0xc1890): undefined reference to > `std::allocator, 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, > Interval<3> >, std::allocator, Interval<3> > > > >::_Vector_base()': > :(.text+0xc18aa): undefined reference to > `std::_Vector_base, Interval<3> >, > std::allocator, 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, > std::allocator > >::_S_use_relocate()': > :(.text+0xc496f): undefined reference to `std::vector, > std::allocator > >::_S_nothrow_relocate(std::integral_constant true>)' >
Re: [PATCH] Deprecate -frepo option.
On 6/21/19 4:28 PM, Richard Biener wrote: > On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek 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, ViewEngine<3, IndexFunction >::PositionsFunctor> > >, false, RefBlockController, ViewEngine<3, IndexFunction >::PositionsFunctor> > > > >::RefCountedBlockPtr(RefCountedBlockPtr, ViewEngine<3, IndexFunction >::PositionsFunctor> > >, false, RefBlockController, ViewEngine<3, IndexFunction >::PositionsFunctor> > > > > const&)': :(.text+0x4181b): undefined reference to `RefCountedPtr, ViewEngine<3, IndexFunction >::PositionsFunctor> > > > >::RefCountedPtr(RefCountedPtr, ViewEngine<3, IndexFunction >::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, Interval<3> >, std::allocator, Interval<3> > > >::_Vector_impl::~_Vector_impl()': :(.text+0xc1890): undefined reference to `std::allocator, 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, Interval<3> >, std::allocator, Interval<3> > > >::_Vector_base()': :(.text+0xc18aa): undefined reference to `std::_Vector_base, Interval<3> >, std::allocator, 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, std::allocator > >::_S_use_relocate()': :(.text+0xc496f): undefined reference to `std::vector, std::allocator > >::_S_nothrow_relocate(std::integral_constant)' /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: /tmp/ccEeuyj7.ltrans0.ltrans.o: in function `std::_Vector_base, Interval<3> >, std::allocator, Interval<3> > > >::~_Vector_base()': :(.text+0xc4cc1): undefined reference to `std::_Vector_base, Interval<3> >, std::allocator, Interval<3> > > >::_M_deallocate(Node, 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::DataBlockPtr()': :(.text+0xc6f96): undefined reference to `RefCountedBlockPtr
Re: [PATCH] Deprecate -frepo option.
> > > On 27 Jun 2019, at 19:21, Jan Hubicka 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). the collect2+non-plugin does not handle static archives so it would need more work while I think we should kill that code (and make darwin to use lld) Honza > 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 >
Re: [PATCH] Deprecate -frepo option.
> On 27 Jun 2019, at 19:21, Jan Hubicka 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
Re: [PATCH] Deprecate -frepo option.
> > 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). 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
Re: [PATCH] Deprecate -frepo option.
On Thu, Jun 27, 2019 at 10:23 AM Martin Liška wrote: > > On 6/27/19 2:58 PM, Jonathan Wakely wrote: > > On Thu, 27 Jun 2019 at 13:30, Martin Liška wrote: > >> > >> On 6/21/19 4:28 PM, Richard Biener wrote: > >>> On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek 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
Re: [PATCH] Deprecate -frepo option.
On 6/27/19 2:58 PM, Jonathan Wakely wrote: > On Thu, 27 Jun 2019 at 13:30, Martin Liška wrote: >> >> On 6/21/19 4:28 PM, Richard Biener wrote: >>> On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek 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. Martin
Re: [PATCH] Deprecate -frepo option.
On Thu, 27 Jun 2019 at 13:30, Martin Liška wrote: > > On 6/21/19 4:28 PM, Richard Biener wrote: > > On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek 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
Re: [PATCH] Deprecate -frepo option.
On 6/21/19 4:28 PM, Richard Biener wrote: > On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek 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
Re: [PATCH] Deprecate -frepo option.
On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek 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? 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
Re: [PATCH] Deprecate -frepo option.
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. Jakub
Re: [PATCH] Deprecate -frepo option.
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.
Martin
>
> Jakub
>
>From 2eeaa3bbe9cacf4d3d407797e38c00e062c6bfd5 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Fri, 21 Jun 2019 14:18:11 +0200
Subject: [PATCH] Deprecate -frepo option.
gcc/ChangeLog:
2019-06-21 Martin Liska
* doc/extend.texi: Note that -frepo might
be removed in the future.
* doc/invoke.texi: Likewise.
gcc/c-family/ChangeLog:
2019-06-21 Martin Liska
* c.opt: Deprecate -frepo.
gcc/testsuite/ChangeLog:
2019-06-21 Martin Liska
* g++.dg/parse/repo1.C: Add new warning for the deprecated
option -frepo.
* g++.dg/rtti/repo1.C: Likewise.
* g++.dg/template/repo1.C: Likewise.
* g++.dg/template/repo10.C: Likewise.
* g++.dg/template/repo11.C: Likewise.
* g++.dg/template/repo2.C: Likewise.
* g++.dg/template/repo3.C: Likewise.
* g++.dg/template/repo4.C: Likewise.
* g++.dg/template/repo5.C: Likewise.
* g++.dg/template/repo6.C: Likewise.
* g++.dg/template/repo7.C: Likewise.
* g++.dg/template/repo8.C: Likewise.
* g++.dg/template/repo9.C: Likewise.
* g++.old-deja/g++.pt/instantiate4.C: Likewise.
* g++.old-deja/g++.pt/instantiate6.C: Likewise.
* g++.old-deja/g++.pt/repo1.C: Likewise.
* g++.old-deja/g++.pt/repo2.C: Likewise.
* g++.old-deja/g++.pt/repo3.C: Likewise.
* g++.old-deja/g++.pt/repo4.C: Likewise.
---
gcc/c-family/c.opt | 2 +-
gcc/doc/extend.texi | 2 ++
gcc/doc/invoke.texi | 2 ++
gcc/testsuite/g++.dg/parse/repo1.C | 1 +
gcc/testsuite/g++.dg/rtti/repo1.C| 1 +
gcc/testsuite/g++.dg/template/repo1.C| 1 +
gcc/testsuite/g++.dg/template/repo10.C | 1 +
gcc/testsuite/g++.dg/template/repo11.C | 1 +
gcc/testsuite/g++.dg/template/repo2.C| 1 +
gcc/testsuite/g++.dg/template/repo3.C| 1 +
gcc/testsuite/g++.dg/template/repo4.C| 1 +
gcc/testsuite/g++.dg/template/repo5.C| 1 +
gcc/testsuite/g++.dg/template/repo6.C| 1 +
gcc/testsuite/g++.dg/template/repo7.C| 1 +
gcc/testsuite/g++.dg/template/repo8.C| 1 +
gcc/testsuite/g++.dg/template/repo9.C| 1 +
gcc/testsuite/g++.old-deja/g++.pt/instantiate4.C | 3 ++-
gcc/testsuite/g++.old-deja/g++.pt/instantiate6.C | 1 +
gcc/testsuite/g++.old-deja/g++.pt/repo1.C| 1 +
gcc/testsuite/g++.old-deja/g++.pt/repo2.C| 1 +
gcc/testsuite/g++.old-deja/g++.pt/repo3.C| 1 +
gcc/testsuite/g++.old-deja/g++.pt/repo4.C| 1 +
22 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 572cf186262..963c651019d 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1732,7 +1732,7 @@ ObjC ObjC++ LTO Var(flag_replace_objc_classes)
Used in Fix-and-Continue mode to indicate that object files may be swapped in at runtime.
frepo
-C++ ObjC++
+C++ ObjC++ Deprecated
Enable automatic template instantiation.
frtti
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index f2619e12f93..4495d2787e8 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -24510,6 +24510,8 @@ conflicts if multiple libraries try to provide the same instantiations.
For greater control, use explicit instantiation as described in the next
option.
+The option is deprecated and might be removed in a later GCC release.
+
@item
@opindex fno-implicit-templates
Compile your code with @option{-fno-implicit-templates} to disable the
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index eaef4cd63d2..75f772f1856 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -2722,6 +2722,8 @@ Enable automatic template instantiation at link time. This option also
implies @option{-fno-implicit-templates}. @xref{Template
Instanti
Re: [PATCH] Deprecate -frepo option.
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). Jakub
[PATCH] Deprecate -frepo option.
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. Thanks, Martin > > 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. > >From 103ae184e4f6cb5e11f3777845828e3677bc74b7 Mon Sep 17 00:00:00 2001 From: Martin Liska Date: Fri, 21 Jun 2019 13:39:23 +0200 Subject: [PATCH] Deprecate -frepo option. gcc/ChangeLog: 2019-06-21 Martin Liska * doc/extend.texi: Remove -frepo from documentation. * doc/invoke.texi: Likewise. * doc/sourcebuild.texi: Likewise. gcc/c-family/ChangeLog: 2019-06-21 Martin Liska * c.opt: Mark frepo deprecated. gcc/testsuite/ChangeLog: 2019-06-21 Martin Liska * g++.dg/parse/repo1.C: Remove. * g++.dg/rtti/repo1.C: Remove. * g++.dg/template/repo1.C: Remove. * g++.dg/template/repo10.C: Remove. * g++.dg/template/repo11.C: Remove. * g++.dg/template/repo2.C: Remove. * g++.dg/template/repo3.C: Remove. * g++.dg/template/repo4.C: Remove. * g++.dg/template/repo5.C: Remove. * g++.dg/template/repo6.C: Remove. * g++.dg/template/repo7.C: Remove. * g++.dg/template/repo8.C: Remove. * g++.dg/template/repo9.C: Remove. * g++.old-deja/g++.pt/instantiate4.C: Remove. * g++.old-deja/g++.pt/instantiate6.C: Remove. * g++.old-deja/g++.pt/repo1.C: Remove. * g++.old-deja/g++.pt/repo2.C: Remove. * g++.old-deja/g++.pt/repo3.C: Remove. * g++.old-deja/g++.pt/repo4.C: Remove. * lib/g++.exp: Remove support for -frepo. * lib/gcc-dg.exp: Likewise. * lib/obj-c++.exp: Likewise. --- gcc/c-family/c.opt| 2 +- gcc/doc/extend.texi | 25 -- gcc/doc/invoke.texi | 8 +-- gcc/doc/sourcebuild.texi | 3 -- gcc/testsuite/g++.dg/parse/repo1.C| 10 gcc/testsuite/g++.dg/rtti/repo1.C | 19 --- gcc/testsuite/g++.dg/template/repo1.C | 20 gcc/testsuite/g++.dg/template/repo10.C| 16 -- gcc/testsuite/g++.dg/template/repo11.C| 31 gcc/testsuite/g++.dg/template/repo2.C | 18 --- gcc/testsuite/g++.dg/template/repo3.C | 11 - gcc/testsuite/g++.dg/template/repo4.C | 18 --- gcc/testsuite/g++.dg/template/repo5.C | 14 -- gcc/testsuite/g++.dg/template/repo6.C | 26 -- gcc/testsuite/g++.dg/template/repo7.C | 25 -- gcc/testsuite/g++.dg/template/repo8.C | 24 - gcc/testsuite/g++.dg/template/repo9.C | 49 --- .../g++.old-deja/g++.pt/instantiate4.C| 31 .../g++.old-deja/g++.pt/instantiate6.C| 29 --- gcc/testsuite/g++.old-deja/g++.pt/repo1.C | 24 - gcc/testsuite/g++.old-deja/g++.pt/repo2.C | 28 --- gcc/testsuite/g++.old-deja/g++.pt/repo3.C | 39 --- gcc/testsuite/g++.old-deja/g++.pt/repo4.C | 19 --- gcc/testsuite/lib/g++.exp | 5 -- gcc/testsuite/lib/gcc-dg.exp | 21 gcc/testsuite/lib/obj-c++.exp | 8 +-- 26 files changed, 3 insertions(+), 520 deletions(-) delete mode 100644 gcc/testsuite/g++.dg/parse/repo1.C delete mode 100644 gcc/testsuite/g++.dg/rtti/repo1.C delete mode 100644 gcc/testsuite/g++.dg/template/repo1.C delete mode 100644 gcc/testsuite/g++.dg/template/repo10.C delete mode 100644 gcc/testsuite/g++.dg/template/repo11.C delete mode 100644 gcc/testsuite/g++.dg/template/repo2.C delete mode 100644 gcc/testsuite/g++.dg/template/repo3.C delete mode 100644 gcc/testsuite/g++.dg/template/repo4.C delete mode 100644 gcc/testsuite/g++.dg/template/repo5.C delete mode 100644 gcc/testsuite/g++.dg/template/repo6.C delete mode 100644 gcc/testsuite/g++.dg/template/repo7.C delete mode 100644 gcc/testsuite/g++.dg/template/repo8.C delete mode 100644 gcc/testsuite/g++.dg/template/repo9.C delete mode 100644 gcc/testsuite/g++.old-deja/g++.pt/instantiate4.C delete mode 100644 gcc/testsuite/g++.old-deja/g++.pt/instantiate6.C delete mode 100644 gcc/testsuite/g++.old-deja/g++.pt/repo1.C delete mode 100644 gcc/testsuite/g++.old-deja/g++.pt/repo2.C delete mode 100644 gcc/testsuite/g++.old-deja/g++.pt/repo3.C delete mode 100644 gcc/testsuite/g++.old-deja/g++.pt/repo4.C diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt index 572cf186262..963c651019d 100644 --- a/gcc/c-family/c.opt +++ b/gcc/c-family/c.opt @@ -1732,7 +1732,7 @@
