[pushed] analyzer: document new param

Message ID f2f4f346-4b1c-e576-01a0-a4277f049fe3@suse.cz
State New
Headers show
Series
  • [pushed] analyzer: document new param
Related show

Commit Message

Martin Liška March 12, 2021, 8:45 a.m.
Identified by my check that compares documentation of params
with content of --help=param output.

Pushed as obvious.
Martin

gcc/ChangeLog:

	* doc/invoke.texi: Add missing param documentation.
---
  gcc/doc/invoke.texi | 4 ++++
  1 file changed, 4 insertions(+)

-- 
2.30.1

Comments

H.J. Lu via Gcc-patches March 12, 2021, 1:56 p.m. | #1
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.
Martin Liška March 12, 2021, 2:02 p.m. | #2
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.

> 

>
H.J. Lu via Gcc-patches March 15, 2021, 8:57 p.m. | #3
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.

>>

>>

>
Martin Liška March 16, 2021, 9:08 a.m. | #4
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
H.J. Lu via Gcc-patches March 16, 2021, 2:51 p.m. | #5
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
H.J. Lu via Gcc-patches March 16, 2021, 3:09 p.m. | #6
[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
Martin Liška March 16, 2021, 3:14 p.m. | #7
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

>

Patch

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.