Re: try_finally_expr in must_not_throw_expr

[Richard Sandiford via Gcc]

Philipp Rimmele via Gcc  writes:
> Hi,
>
> i'm developing a GCC-Plugin. And i don't understand why there is a 
> "try_finally_expr" in a must_not_throw-Area in my AST. It happens in the 
> destructors.
> Here is my AST:
> function_decl Exception::__dt_base
>   1: must_not_throw_expr(->void_type{void})[42]
> 0: statement_list(->void_type{void})
>   0: bind_expr(->void_type{void})[42]
> 1: statement_list(->void_type{void})
>   0: cleanup_point_expr(->void_type{void})[42]
> 0: expr_stmt(->void_type{void})
>   0: convert_expr(->void_type{void})
> 0: 
> modify_expr(->pointer_type->pointer_type{__vtbl_ptr_type}->function_type->integer_type{int})
>   0: 
> component_ref(->pointer_type->pointer_type{__vtbl_ptr_type}->function_type->integer_type{int})
> 0: indirect_ref(->record_type{Exception})
>   0: nop_expr(->pointer_type->record_type{Exception})
> 0: parm_decl(->pointer_type->record_type{Exception}) 
> : this
> 1: 
> field_decl(->pointer_type->pointer_type{__vtbl_ptr_type}->function_type->integer_type{int})
>   1: 
> pointer_plus_expr(->pointer_type->pointer_type{__vtbl_ptr_type}->function_type->integer_type{int})
> 0: 
> addr_expr(->pointer_type->pointer_type{__vtbl_ptr_type}->function_type->integer_type{int})
>   0: 
> var_decl(->array_type->pointer_type{__vtbl_ptr_type}->function_type->integer_type{int})
>  : _ZTV9Exception
> 1: integer_cst : 16 : 1
>   0: try_finally(->void_type{void})[42]
> 0: statement_list(->void_type{void})
> 1: modify_expr(->void_type{void})
>   0: indirect_ref(->record_type)
> 0: nop_expr(->reference_type->record_type)
>   0: parm_decl(->pointer_type->record_type{Exception}) : this
>   1: constructor(->record_type)
> 2: block
>   0: label_expr(->void_type{void})[42]
> 0: label_decl(->void_type{void}) : 
>
> What is the reason for this? There should no Exception be thrown, so why 
> handle it with a try_finally-Expression? I'm currently using GCC-8.2.0.
> I would be realy glad if you could answer me this question. And if you can 
> give me some examples, where the try_finally-expression is also used, it 
> would be realy helpfull.

I'm not an expert on this by any means, but since no-one else has
replied yet... I suspect it's simpler to use try_finally whenever
something needs to be run at the end of a scope, regardless of whether
the scope ends through fallthrough, breaking, continuing, or exceptions.

To put it another way: try_finally at this stage doesn't guarantee
that exception handling will actually be needed.  For example:

  try
{
  int i = 1;
  int j = 2;
  if (i == j)
foo ();
}
  finally ...

starts out with a potentially-throwing call to foo, but it (and the
possibility of an exception) will get optimised away later.  It probably
didn't seem worthwhile having the frontend do a similar but separate
analysis of whether statements might throw.

Thanks,
Richard

Re: Porting the Docs to Sphinx - project status

[Martin Liška]

On 1/31/22 15:06, Martin Liška wrote:
> Hello.
> 
> It's about 5 months since the last project status update:
> https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577108.html
> Now it's pretty clear that it won't be merged before GCC 12.1 gets released.
> 
> So where we are? I contacted documentation maintainers (Gerald, Sandra and 
> Joseph) at the
> end of the year in a private email, where I pinged the patches. My take away 
> is that both
> Gerald and Joseph are fine with the porting, while Sandra has some concerns. 
> Based on her
> feedback, I was able to improve the PDF generated output significantly and 
> I'm pleased by the
> provided feedback. That led to the following 2 Sphinx pulls requests that 
> need to be merged
> before we can migrate the documentation: [1], [2].
> 
> Since the last time I also made one more round of proofreading and the layout 
> was improved
> (mainly for PDF part). Current version of the documentation can be seen here:
> https://splichal.eu/scripts/sphinx/
> 
> I would like to finish the transition once GCC 12.1 gets released in May/June 
> this year.
> There are still some minor regressions, but overall the Sphinx-based 
> documentation should
> be a significant improvement over what we've got right now.
> 
> Please take this email as urgent call for a feedback!
> 
> Thank you,
> Martin
> 
> [1] https://github.com/sphinx-doc/sphinx/pull/10087
> [2] https://github.com/sphinx-doc/sphinx/pull/10001

Hello.

It's been another 5 months since the last project status update. In order to 
address some Sandra comments
I had to work with upstream in order to merge a few pull requests. That has 
been achieved and Sphinx 5.1.0
can built the converted documentation.

What has changed since the last time:
1) I made a couple of proof-reading rounds and the documentation should not 
contain any significant defects.
2) I used a more responsive HTML template Furo that works nicely on mobile 
devices as well.
3) Number of Sphinx warnings has been reduced.
4) configure script supports not --with-sphinx-build ([1]) that can be used 
when Sphinx is installed into pip env.
5) Building Documentation chapter was added to gccint manual ([2]).
6) I made a couple of screenshot that show up how is the docs better ([3], 
Chapter 1).

I'm not planning sending a patchset as most of the patches would not fit in the 
email limit, so please fetch the following
branch (the last 2 fixme commits will not be installed):

$ git fetch origin refs/users/marxin/heads/sphinx-v7
$ git checkout FETCH_HEAD

The generated documentation (built from GCC source based on the git branch) can 
be seen here:
https://splichal.eu/gccsphinx-final/

I would like to merge the documentation during the summer if possible before a 
bigger changes will land in fall.

Thank you,
Martin

[1] 
https://splichal.eu/gccsphinx-final/html/install/configuration.html#cmdoption-with-sphinx-build
[2] 
https://splichal.eu/gccsphinx-final/html/gccint/source-tree-structure-and-build-system/the-gcc-subdirectory/building-documentation.html
[3] https://splichal.eu/scripts/sphinx/demo/_build/latex/demo.pdf

[RFC] Drafting a formal v1.0 release for RVV C Intrinsic API

[eop Chen]

Hi all,

We (SiFive) are going to draft out a formal v1.0 release for the RVV C
intrinsic API. Next week we are going to provide a roadmap, including time
reserved for comments on what is left on the table and needs to be cleared
before the release. All existing issue will be settled. The ones that have
converged will be closed and opening ones will be tagged as "resolve for v1.0"
or "resolve after v1.0" that we can bring up for discussion in future
meeting(s).

Here are some initial thoughts on items before the release:

Release a generator script that produces the current C intrinsic API. Other
languages that seek to implement the intrinsics will able to leverage this.
Release a pdf version, better formatted document for the RVV C intrinsic API.
We hope to expand RVV users by providing a better conditioned document.
Schedule out timelines on requesting for comments on current items. Maybe
a monthly meeting? We hope to gather more inputs and reach consensus.
Our take on the release is to consider the completeness of current intrinsic
API-s and do minimal fixes and leave the current implementation "as-is" for
v1.0.

Looking forward for input and hope we can close this by the end of this year.
[Link to RFC issue under rvv-intrinsic-doc 
]
https://github.com/riscv-non-isa/rvv-intrinsic-doc/issues/157