[PATCH][pushed] analyzer: document new param

[PATCH][pushed] analyzer: document new param

[Martin Liška]

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(+)

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.
-- 
2.30.1

Re: [PATCH][pushed] analyzer: document new param

[David Malcolm]

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.

Re: [PATCH][pushed] analyzer: document new param

[Martin Liška]

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.
> 
> 

Re: [PATCH][pushed] analyzer: document new param

[Martin Sebor]

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.
>>
>>
> 

Re: [PATCH][pushed] analyzer: document new param

[Martin Liška]

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

Re: [PATCH][pushed] analyzer: document new param

[Martin Sebor]

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

testsuite: automatically checking for param documentation

[David Malcolm]

[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

Re: testsuite: automatically checking for param documentation

[Martin Liška]

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
>