[Patch] Fortran's gfc_match_char: %S to match symbol with host_assoc

When just matching a symbol, one can use 'gfc_match_symbol (&sym, host_assoc)' and has the option to match with and without host association. However, when matching something more complex via 'gfc_match' like "something ( %s ) , " the match uses host_assoc = false. While it can be combined ("some

Re: [Patch, fortran] PR107900 Select type with intrinsic type inside associate causes ICE / Segmenation fault

Hi Harald, Fixing the original testcase in this PR turned out to be slightly more involved than I expected. However, it resulted in an open door to fix some other PRs and the attached much larger patch. This time, I did remember to include the testcases in the .diff :-) I believe that, between t

Re: [Patch] Fortran's gfc_match_char: %S to match symbol with host_assoc

Hi Tobias, This looks good to me. I'm interested to see it in use :-) OK for trunk Paul On Tue, 20 Jun 2023 at 11:50, Tobias Burnus wrote: > > When just matching a symbol, one can use 'gfc_match_symbol (&sym, host_assoc)' > and has the option to match with and without host association. > > How

[committed] Fortran: Fix parse-dump-tree for OpenMP ALLOCATE clause

A rather obvious fix. The allocator(...) bit showed up with -fdump-parse-tree. Committed as Rev. r14-1988-g99e3214f582b08 Side remark: Regarding the example inside the commit log: OpenMP 5.1 permitted derived-type components. Due to global wording changes, OpenMP 5.2 disabled it for both the ne

[Patch, fortran] PR108961 - Segfault when associating to pointer from C_F_POINTER

Dear All, This patch is verging on obvious. The PR was originally, incorrectly blocking PR87477 and the testcase has remained in my 'associate' directory. I thought that it is time to get shot of it! Is there a better way to detect a type(c_ptr) formal argument? Subject to advice on the question

Re: [Patch, fortran] PR108961 - Segfault when associating to pointer from C_F_POINTER

On 20.06.23 18:19, Paul Richard Thomas via Fortran wrote: Is there a better way to detect a type(c_ptr) formal argument? u.derived->intmod_sym_id == ISOCBINDING_PTR ? Tobias - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft

Re: [PATCH v5 3/5] p1689r5: initial support

On Mon, Jun 19, 2023 at 17:33:58 -0400, Jason Merrill wrote: > On 5/12/23 10:24, Ben Boeckel wrote: > > `file` can be omitted (the `output_stream` will be used then). I *think* > > I see that adding: > > > > %{fdeps_file:-fdeps-file=%{!o:%b.ddi}%{o*:%.ddi%*}} > > %{!fdeps-file: but yes. > >

Re: [PATCH v5 3/5] p1689r5: initial support

On Tue, Feb 14, 2023 at 16:50:27 -0500, Jason Merrill wrote: > On 1/25/23 13:06, Ben Boeckel wrote: > > - header-unit information fields > > > > Header units (including the standard library headers) are 100% > > unsupported right now because the `-E` mechanism wants to import their > > BMIs. A new

Re: [Patch, fortran] PR108961 - Segfault when associating to pointer from C_F_POINTER

Le 20/06/2023 à 18:30, Tobias Burnus a écrit : On 20.06.23 18:19, Paul Richard Thomas via Fortran wrote: Is there a better way to detect a type(c_ptr) formal argument? u.derived->intmod_sym_id == ISOCBINDING_PTR ? && u.derived->from_intmod == INTMOD_ISO_C_BINDING ?

Re: [Patch, fortran] PR107900 Select type with intrinsic type inside associate causes ICE / Segmenation fault

Hi Paul, On 6/20/23 12:54, Paul Richard Thomas via Gcc-patches wrote: Hi Harald, Fixing the original testcase in this PR turned out to be slightly more involved than I expected. However, it resulted in an open door to fix some other PRs and the attached much larger patch. This time, I did reme

PRs 100650 and 49324: intrinsic assignment of reshaped derived type array constructor

I just added a shorter reproducer (below) to PR 100650. Is this also related to PR 49324? Damian % cat reshape-array-constructor.f90 implicit none type foo_t integer, allocatable :: bar(:) end type type(foo_t) foo(2,1) integer :: i, j, n(2,2,1) = reshape([-1,-1,1,1], [2,2,1])