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: [GSoC-19] Implementing narrowing functions like fadd
Hello.
I have added fadd variants in builtins.def. For fadd and faddl
variants, I had to introduce builtin function types in
builtin-types.def :
+DEF_FUNCTION_TYPE_2 (BT_FN_FLOAT_DOUBLE_DOUBLE,
+BT_FLOAT, BT_DOUBLE, BT_DOUBLE)
+DEF_FUNCTION_TYPE_2 (BT_FN_FLOAT_LONGDOUBLE_LONGDOUBLE,
+BT_FLOAT, BT_LONGDOUBLE, BT_LONGDOUBLE)
and used them to define function in builtins.def. At this point, only
faddf variant is getting called by test program :
int main ()
{
double z = __builtin_faddf (3.5, 1.4);
}
faddf variant is using BT_FN_FLOAT_FLOAT_FLOAT which is already
defined in builtin-types.def means I need not to introduce it. Why
fadd and faddl are not getting called in this patch? I don't find any
other place where these function types needs to be added.
Thanks,
-Tejas
On Sat, 6 Jul 2019 at 18:29, Tejas Joshi wrote:
>
> Hello.
> I am trying to add fadd function variants and as fadd takes two
> arguments, the function should be called from fold_const_call_sss ().
> The function is closely modeled on function calls and cases according
> to real_nextafter (), also used gdb to look at backtrace. Although I
> have made changes according to real_nextafter, the function real_fadd
> is not called by the test program but real_nextafter does get called.
> I cant find any other places to add calls for fadd. What is missing?
> The patch is attached herewith.
>
> int
> main ()
> {
> float x;
> x = __builtin_fadd (3.5,1.4);
> }
>
> Also, fadd function should not have faddf variant, but is introduced
> only for the sake.
>
> Thanks,
> -Tejas
>
> On Wed, 3 Jul 2019 at 18:29, Tejas Joshi wrote:
> >
> > Hello.
> > Functions like fadd, faddl take two arguments, do the addition and
> > return the answer in narrower precision than the argument type. The
> > thing that might be helpful is using the do_add function directly, if
> > appropriate?
> > The thing to consider about narrowed down return type is how it can be
> > achieved. The functions that operate on real numbers like real_round
> > and so on, do not consider the return type and do calculations on the
> > entire real number representation. So just defining these functions
> > and their return type in builtins.def and other appropriate places
> > would do the trick?
> > like:
> > BT_FN_FLOAT_DOUBLE_DOUBLE as return and argument type for FADD
> >
> > Or it has to be narrowed down by zeroing down the trailing
> > out-of-precision bits?
> > Also, if the addition or any one of the argument exceeds the return
> > size, the integer part of the addition would not fit in the narrowed
> > type. Like, 2^32 would easily fit in double but will lose its least
> > significant bit in float and become 2^31. How these types are supposed
> > to be handled?
> >
> > Thanks,
> > -Tejas
diff --git a/gcc/builtin-types.def b/gcc/builtin-types.def
index e5c9e063c48..87ecd2e9218 100644
--- a/gcc/builtin-types.def
+++ b/gcc/builtin-types.def
@@ -387,6 +387,10 @@ DEF_FUNCTION_TYPE_2 (BT_FN_VOID_UINT_PTR,
BT_VOID, BT_UINT, BT_PTR)
DEF_FUNCTION_TYPE_2 (BT_FN_FLOAT_FLOAT_FLOAT,
BT_FLOAT, BT_FLOAT, BT_FLOAT)
+DEF_FUNCTION_TYPE_2 (BT_FN_FLOAT_DOUBLE_DOUBLE,
+ BT_FLOAT, BT_DOUBLE, BT_DOUBLE)
+DEF_FUNCTION_TYPE_2 (BT_FN_FLOAT_LONGDOUBLE_LONGDOUBLE,
+ BT_FLOAT, BT_LONGDOUBLE, BT_LONGDOUBLE)
DEF_FUNCTION_TYPE_2 (BT_FN_DOUBLE_DOUBLE_DOUBLE,
BT_DOUBLE, BT_DOUBLE, BT_DOUBLE)
DEF_FUNCTION_TYPE_2 (BT_FN_LONGDOUBLE_LONGDOUBLE_LONGDOUBLE,
diff --git a/gcc/builtins.c b/gcc/builtins.c
index f61f10422fd..471c7918abb 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -2006,6 +2006,7 @@ mathfn_built_in_2 (tree type, combined_fn fn)
CASE_MATHFN (EXP2)
CASE_MATHFN (EXPM1)
CASE_MATHFN (FABS)
+CASE_MATHFN (FADD)
CASE_MATHFN (FDIM)
CASE_MATHFN_FLOATN (FLOOR)
CASE_MATHFN_FLOATN (FMA)
diff --git a/gcc/builtins.def b/gcc/builtins.def
index 8bb7027aac7..afc482f38dc 100644
--- a/gcc/builtins.def
+++ b/gcc/builtins.def
@@ -352,6 +352,9 @@ DEF_C99_C90RES_BUILTIN (BUILT_IN_FABSL, "fabsl", BT_FN_LONGDOUBLE_LONGDOUBLE, AT
#define FABS_TYPE(F) BT_FN_##F##_##F
DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_FABS, "fabs", FABS_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
#undef FABS_TYPE
+DEF_EXT_LIB_BUILTIN(BUILT_IN_FADD, "fadd", BT_FN_FLOAT_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN(BUILT_IN_FADDF, "faddf", BT_FN_FLOAT_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN(BUILT_IN_FADDL, "faddl", BT_FN_FLOAT_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
DEF_GCC_BUILTIN(BUILT_IN_FABSD32, "fabsd32", BT_FN_DFLOAT32_DFLOAT32, ATTR_CONST_NOTHROW_LEAF_LIST)
DEF_GCC_BUILTIN(BUILT_IN_FABSD64, "fabsd64", BT_FN_DFLOAT64_DFLOAT64, ATTR_CONST_NOTHROW_LEAF_LIST)
DEF_GCC_BUILTIN(BUILT_IN_FABSD128, "fabsd128", BT_FN_DFLOAT128_DFLOAT128, ATTR_CONST_NOTHROW_LEAF_LIST)
diff --git a/gcc/fold-const-call.c b/gcc/fold-const-call.c
index d9b546e6803..ee939f85005 100644
Re: [GSoC-19] Implementing narrowing functions like fadd
Tejas Joshi writes:
> Hello.
> I have added fadd variants in builtins.def. For fadd and faddl
> variants, I had to introduce builtin function types in
> builtin-types.def :
>
> +DEF_FUNCTION_TYPE_2 (BT_FN_FLOAT_DOUBLE_DOUBLE,
> +BT_FLOAT, BT_DOUBLE, BT_DOUBLE)
> +DEF_FUNCTION_TYPE_2 (BT_FN_FLOAT_LONGDOUBLE_LONGDOUBLE,
> +BT_FLOAT, BT_LONGDOUBLE, BT_LONGDOUBLE)
>
> and used them to define function in builtins.def. At this point, only
> faddf variant is getting called by test program :
>
> int main ()
> {
> double z = __builtin_faddf (3.5, 1.4);
> }
> faddf variant is using BT_FN_FLOAT_FLOAT_FLOAT which is already
> defined in builtin-types.def means I need not to introduce it. Why
> fadd and faddl are not getting called in this patch? I don't find any
> other place where these function types needs to be added.
This is because of:
if (mode == arg0_mode
&& real_cst_p (arg0)
&& real_cst_p (arg1))
in fold_const_call_1. The reason for that check is that usually
the format passed in to fold_const_call_sss applies to both arguments
and the return type. There's already an exception for CASE_CFN_NEXTTOWARD
though. I guess you'll need something similar here.
Thanks,
Richard
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/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 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 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
[PATCH] Deprecate -frepo on gcc-9 branch (PR c++/91125).
Hi.
This is a patch for GCC9 branch that warns when a user
tries to use the option.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
>From 6dcfb47ca7f7674c2913ba45e85f11426311bb4e Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Wed, 10 Jul 2019 15:20:28 +0200
Subject: [PATCH] Deprecate -frepo on gcc-9 branch (PR c++/91125).
gcc/c-family/ChangeLog:
2019-07-10 Martin Liska
PR c++/91125
* c-opts.c (c_common_handle_option): Warn the -frepo
will be removed in the future.
gcc/testsuite/ChangeLog:
2019-07-10 Martin Liska
PR c++/91125
* g++.dg/parse/repo1.C: Add scan for the new warning.
* 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-opts.c| 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 | 1 +
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 +
20 files changed, 21 insertions(+)
diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index 454cfa0ee3e..d0ea93af57e 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -501,6 +501,8 @@ c_common_handle_option (size_t scode, const char *arg, HOST_WIDE_INT value,
flag_use_repository = value;
if (value)
flag_implicit_templates = 0;
+ warning (0, "%<-frepo%> is deprecated and will be removed "
+ "in a future release");
break;
case OPT_ftabstop_:
diff --git a/gcc/testsuite/g++.dg/parse/repo1.C b/gcc/testsuite/g++.dg/parse/repo1.C
index efadd58723e..dacf59a494b 100644
--- a/gcc/testsuite/g++.dg/parse/repo1.C
+++ b/gcc/testsuite/g++.dg/parse/repo1.C
@@ -1,5 +1,6 @@
// { dg-options "-frepo" }
// { dg-require-host-local "" }
+// { dg-warning "is deprecated and will be removed in a future release" "" { target *-*-* } 0 }
extern "C" inline void f() {}
diff --git a/gcc/testsuite/g++.dg/rtti/repo1.C b/gcc/testsuite/g++.dg/rtti/repo1.C
index f72a9730ab9..36a8f086763 100644
--- a/gcc/testsuite/g++.dg/rtti/repo1.C
+++ b/gcc/testsuite/g++.dg/rtti/repo1.C
@@ -2,6 +2,7 @@
// { dg-options "-frepo" }
// { dg-require-host-local "" }
// { dg-skip-if "dkms are not final links" { vxworks_kernel } }
+// { dg-warning "is deprecated and will be removed in a future release" "" { target *-*-* } 0 }
#include
template
diff --git a/gcc/testsuite/g++.dg/template/repo1.C b/gcc/testsuite/g++.dg/template/repo1.C
index 342993eca14..fe18c467cf4 100644
--- a/gcc/testsuite/g++.dg/template/repo1.C
+++ b/gcc/testsuite/g++.dg/template/repo1.C
@@ -1,6 +1,7 @@
// { dg-options "-frepo" }
// { dg-require-host-local "" }
// { dg-skip-if "dkms are not final links" { vxworks_kernel } }
+// { dg-warning "is deprecated and will be removed in a future release" "" { target *-*-* } 0 }
struct A {
A();
diff --git a/gcc/testsuite/g++.dg/template/repo10.C b/gcc/testsuite/g++.dg/template/repo10.C
index c92f7a52b60..42497a2810a 100644
--- a/gcc/testsuite/g++.dg/template/repo10.C
+++ b/gcc/testsuite/g++.dg/template/repo10.C
@@ -3,6 +3,7 @@
// { dg-require-host-local "" }
// { dg-skip-if "dkms are not final links" { vxworks_kernel } }
// { dg-final cleanup-repo-files }
+// { dg-warning "is deprecated and will be removed in a future release" "" { target *-*-* } 0 }
template
struct Foo
diff --git a/gcc/testsuite/g++.dg/template/repo11.C b/gcc/testsuite/g++.dg/template/repo11.C
index 5cabfd452ed..54edad05f9e
