| Message ID | f2f4f346-4b1c-e576-01a0-a4277f049fe3@suse.cz |
|---|---|
| State | New |
| Headers | show |
| Series | [pushed] analyzer: document new param | expand |
On Fri, 2021-03-12 at 09:45 +0100, Martin Liška wrote: > Identified by my check that compares documentation of params > with content of --help=param output. > > Pushed as obvious. > Martin Thanks. Which check is this, BTW? (presumably this is something I should add to my patch testing workflow) Dave > gcc/ChangeLog: > > * doc/invoke.texi: Add missing param documentation. > --- > gcc/doc/invoke.texi | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi > index 4a3c1e2fa0f..7a368959e5e 100644 > --- a/gcc/doc/invoke.texi > +++ b/gcc/doc/invoke.texi > @@ -14362,6 +14362,10 @@ recurse deeper. > The maximum depth of a symbolic value, before approximating > the value as unknown. > > +@item analyzer-max-infeasible-edges > +The maximum number of infeasible edges to reject before declaring > +a diagnostic as infeasible. > + > @item gimple-fe-computed-hot-bb-threshold > The number of executions of a basic block which is considered hot. > The parameter is used only in GIMPLE FE.
On 3/12/21 2:56 PM, David Malcolm wrote: > On Fri, 2021-03-12 at 09:45 +0100, Martin Liška wrote: >> Identified by my check that compares documentation of params >> with content of --help=param output. >> >> Pushed as obvious. >> Martin > > Thanks. > > Which check is this, BTW? (presumably this is something I should add > to my patch testing workflow) ./gcc/xgcc -Bgcc --help=param &>params.txt ../contrib/check-params-in-docs.py ../gcc/doc/invoke.texi params.txt Cheers, Martin > > Dave > >> gcc/ChangeLog: >> >> * doc/invoke.texi: Add missing param documentation. >> --- >> gcc/doc/invoke.texi | 4 ++++ >> 1 file changed, 4 insertions(+) >> >> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi >> index 4a3c1e2fa0f..7a368959e5e 100644 >> --- a/gcc/doc/invoke.texi >> +++ b/gcc/doc/invoke.texi >> @@ -14362,6 +14362,10 @@ recurse deeper. >> The maximum depth of a symbolic value, before approximating >> the value as unknown. >> >> +@item analyzer-max-infeasible-edges >> +The maximum number of infeasible edges to reject before declaring >> +a diagnostic as infeasible. >> + >> @item gimple-fe-computed-hot-bb-threshold >> The number of executions of a basic block which is considered hot. >> The parameter is used only in GIMPLE FE. > >
On 3/12/21 7:02 AM, Martin Liška wrote: > On 3/12/21 2:56 PM, David Malcolm wrote: >> On Fri, 2021-03-12 at 09:45 +0100, Martin Liška wrote: >>> Identified by my check that compares documentation of params >>> with content of --help=param output. >>> >>> Pushed as obvious. >>> Martin >> >> Thanks. >> >> Which check is this, BTW? (presumably this is something I should add >> to my patch testing workflow) > > ./gcc/xgcc -Bgcc --help=param &>params.txt > ../contrib/check-params-in-docs.py ../gcc/doc/invoke.texi params.txt Any plans to integrate it into the testsuite? (That way we presumably wouldn't need to remember to run it by hand.) Martin > > Cheers, > Martin > >> >> Dave >> >>> gcc/ChangeLog: >>> >>> * doc/invoke.texi: Add missing param documentation. >>> --- >>> gcc/doc/invoke.texi | 4 ++++ >>> 1 file changed, 4 insertions(+) >>> >>> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi >>> index 4a3c1e2fa0f..7a368959e5e 100644 >>> --- a/gcc/doc/invoke.texi >>> +++ b/gcc/doc/invoke.texi >>> @@ -14362,6 +14362,10 @@ recurse deeper. >>> The maximum depth of a symbolic value, before approximating >>> the value as unknown. >>> +@item analyzer-max-infeasible-edges >>> +The maximum number of infeasible edges to reject before declaring >>> +a diagnostic as infeasible. >>> + >>> @item gimple-fe-computed-hot-bb-threshold >>> The number of executions of a basic block which is considered hot. >>> The parameter is used only in GIMPLE FE. >> >> >
On 3/15/21 9:57 PM, Martin Sebor wrote: > Any plans to integrate it into the testsuite? (That way we presumably > wouldn't need to remember to run it by hand.) Likely not, I'm not so big friend with DejaGNU. Are you willing to help me with that? Thanks, Martin
On 3/16/21 3:08 AM, Martin Liška wrote: > On 3/15/21 9:57 PM, Martin Sebor wrote: >> Any plans to integrate it into the testsuite? (That way we presumably >> wouldn't need to remember to run it by hand.) > > Likely not, I'm not so big friend with DejaGNU. > Are you willing to help me with that? I'm not a fan either but that's what we've got. And sure, I'll help if/when I can. I think it should be "straightforward" to rewrite the script in Expect (as much as anything is straightforward in Expect). Or, it could stay as is and be invoked from some .exp file in testsuite. Although is Python a required prerequisite for running the testsuite? If not, it might be better to either rewrite the script in something that is (e.g., AWK) or in Expect. Martin > > Thanks, > Martin
[updating subject for greater visibility] On Tue, 2021-03-16 at 08:51 -0600, Martin Sebor wrote: > On 3/16/21 3:08 AM, Martin Liška wrote: > > On 3/15/21 9:57 PM, Martin Sebor wrote: > > > Any plans to integrate it into the testsuite? (That way we presu > > > mably > > > wouldn't need to remember to run it by hand.) > > > > Likely not, I'm not so big friend with DejaGNU. > > Are you willing to help me with that? > > I'm not a fan either but that's what we've got. And sure, I'll help > if/when I can. I think it should be "straightforward" to rewrite > the script in Expect (as much as anything is straightforward in > Expect). Or, it could stay as is and be invoked from some .exp > file in testsuite. Although is Python a required prerequisite > for running the testsuite? If not, it might be better to either > rewrite the script in something that is (e.g., AWK) or in Expect. I find it painful writing non-trivial logic in Tcl. We already have run-gcov-pytest in gcov.exp which calls out to a python3 script, checking if python3 is supported, and bailing with UNSUPPORTED otherwise. FWIW I think it's reasonable to have something similar for this case. Dave
On 3/16/21 4:09 PM, David Malcolm wrote: > [updating subject for greater visibility] > > On Tue, 2021-03-16 at 08:51 -0600, Martin Sebor wrote: >> On 3/16/21 3:08 AM, Martin Liška wrote: >>> On 3/15/21 9:57 PM, Martin Sebor wrote: >>>> Any plans to integrate it into the testsuite? (That way we presu >>>> mably >>>> wouldn't need to remember to run it by hand.) >>> >>> Likely not, I'm not so big friend with DejaGNU. >>> Are you willing to help me with that? >> >> I'm not a fan either but that's what we've got. And sure, I'll help >> if/when I can. I think it should be "straightforward" to rewrite >> the script in Expect (as much as anything is straightforward in >> Expect). Or, it could stay as is and be invoked from some .exp >> file in testsuite. Although is Python a required prerequisite >> for running the testsuite? If not, it might be better to either >> rewrite the script in something that is (e.g., AWK) or in Expect. > > I find it painful writing non-trivial logic in Tcl. Me too! > > We already have run-gcov-pytest in gcov.exp which calls out to a > python3 script, checking if python3 is supported, and bailing with > UNSUPPORTED otherwise. > > FWIW I think it's reasonable to have something similar for this case. Yep, let's run the existing Python script. Martin > > Dave >
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index 4a3c1e2fa0f..7a368959e5e 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -14362,6 +14362,10 @@ recurse deeper. The maximum depth of a symbolic value, before approximating the value as unknown. +@item analyzer-max-infeasible-edges +The maximum number of infeasible edges to reject before declaring +a diagnostic as infeasible. + @item gimple-fe-computed-hot-bb-threshold The number of executions of a basic block which is considered hot. The parameter is used only in GIMPLE FE.