From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) by sourceware.org (Postfix) with ESMTPS id BD9243858D20 for ; Sun, 18 Jun 2023 07:54:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BD9243858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oi1-x22e.google.com with SMTP id 5614622812f47-39ed11d6a50so182695b6e.2 for ; Sun, 18 Jun 2023 00:54:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687074856; x=1689666856; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=rS61vpf/tddYUOTT37JxpbCBOnak3ypIIjFN6dTdu50=; b=mdS2/JJxbvvKZHtrm/Kk35SjNSVjfbAgYrLErTYDHz5vG0/fDO3h0OGMOt+c30XYe+ Zh2i09fnGyRZt/zAgXkjN/3fTJdRhfM8qNXiBuwDy1wkzbMawJ3Sgcx8+42dmaxrMZ1Y EAnhshWIscwQ9YShq8WwJ+OI++wbslMYK9FzYurRdLIspeYMcXssGBo3aqMKBa3/Y93G F2uQa+U0nMuGLf31tinNU8iJhlzeuu5KXhn6ZYRy3MyUaYMxUiXJC1HPpEUdsC02bdJs IT9otPZyB4aDvC48hl9AuXz1mRzr6WnmjXo+wL/OMfZpQvZ+PSO7XVb7MEYMtQOVj7da Ex6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687074856; x=1689666856; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=rS61vpf/tddYUOTT37JxpbCBOnak3ypIIjFN6dTdu50=; b=ikgd8SKXtsNArGIwYECv5wQlhAWDD84UZNJws5u1gkriqJ5cKvFqDz4IjYm9uOFl/7 zBkl0/Fuyh25KiK3yDMC8qbxZCHSzyup3/GNhk9UiLiN0q8eZC+0XTPDkLiE/NxAY3Lb nhZsfRrizQSI5B43l1LMToDhElySFV1X4pugFNjCgedJ7vI5Xp9bOBsc4K8Ny/cz6OFG blXS41sHC9S/pSDkyWzSxDmQ29PgKhM1vVHQZpylFKfGAj6X9bBgSVYb3R6QGOcXvLPl pTST6lIlVrks+vGlCNJVeai8WJJpRgKnfGcSN6ss+renfeamszsIyjmpvSDz4/K5ou0f 8hnw== X-Gm-Message-State: AC+VfDxDJnhOF6vChWiLzTKiMGa5q4FXq1fl5vP34eIx5DM7FN46ZIbi J6/NnQyJOXkkBoqTALPbcIUrbj4i1jc0xl/8LwI= X-Google-Smtp-Source: ACHHUZ5/tq7ecj15Cc4fvxIAF69+BOzATUTUpn8BRhcYPcQjeXeuGruhdwFlP/6LC5kKnwgdQilqQLcpkqbCIVDgi+4= X-Received: by 2002:a05:6808:1704:b0:39e:d59a:8275 with SMTP id bc4-20020a056808170400b0039ed59a8275mr512580oib.25.1687074855892; Sun, 18 Jun 2023 00:54:15 -0700 (PDT) MIME-Version: 1.0 References: <358e8e69-8fc9-8d00-7fde-9aaa86371c87@gmx.de> In-Reply-To: <358e8e69-8fc9-8d00-7fde-9aaa86371c87@gmx.de> From: Paul Richard Thomas Date: Sun, 18 Jun 2023 08:54:04 +0100 Message-ID: Subject: Re: [Patch, fortran] PR107900 Select type with intrinsic type inside associate causes ICE / Segmenation fault To: Harald Anlauf Cc: "fortran@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,WEIRD_PORT autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Harald, Well, at least you found the testcase :-) Thanks for pointing out the obvious; ie. that I had deviated from the original testcase. This is an important clue for some of the PRs that come up under the "select type flag". What is surprising is that it is gcc_assert (st->n.sym->assoc) that triggers the ICE. One would think that the assoc field would be filled twice over. This and the two new associate PRs that Steve pointed out have deflated me a bit. Still, I'll press on. I will create a select-type meta-bug when I return to my desk. Thanks Paul On Sat, 17 Jun 2023 at 19:01, Harald Anlauf wrote: > > Hi Paul, > > On 6/17/23 11:14, Paul Richard Thomas via Gcc-patches wrote: > > Hi All, > > > > The attached patch is amply described by the comments and the > > changelog. It also includes the fix for the memory leak in decl.cc, as > > promised some days ago. > > > > OK for trunk? > > I hate to say it, but you forgot to add the testcase again... :-( > > The patch fixes your "extended" testcase in > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107900#c2 > > but the original one in comment ICEs for me here: > > % gfc-14 pr107900.f90 > f951: internal compiler error: Segmentation fault > 0x1025c2f crash_signal > ../../gcc-trunk/gcc/toplev.cc:314 > 0x9d31d3 resolve_select_type > ../../gcc-trunk/gcc/fortran/resolve.cc:9791 > 0x9cef5e gfc_resolve_code(gfc_code*, gfc_namespace*) > ../../gcc-trunk/gcc/fortran/resolve.cc:12588 > 0x9d2431 resolve_codes > ../../gcc-trunk/gcc/fortran/resolve.cc:18057 > 0x9d24fe gfc_resolve(gfc_namespace*) > ../../gcc-trunk/gcc/fortran/resolve.cc:18092 > 0x9cf0ee gfc_resolve(gfc_namespace*) > ../../gcc-trunk/gcc/fortran/resolve.cc:18077 > 0x9cf0ee resolve_block_construct > ../../gcc-trunk/gcc/fortran/resolve.cc:10971 > 0x9cf0ee gfc_resolve_code(gfc_code*, gfc_namespace*) > ../../gcc-trunk/gcc/fortran/resolve.cc:12596 > 0x9d2431 resolve_codes > ../../gcc-trunk/gcc/fortran/resolve.cc:18057 > 0x9d24fe gfc_resolve(gfc_namespace*) > ../../gcc-trunk/gcc/fortran/resolve.cc:18092 > 0x9b11f1 resolve_all_program_units > ../../gcc-trunk/gcc/fortran/parse.cc:6864 > 0x9b11f1 gfc_parse_file() > ../../gcc-trunk/gcc/fortran/parse.cc:7120 > 0xa033ef gfc_be_parse_file > ../../gcc-trunk/gcc/fortran/f95-lang.cc:229 > > It hits an assert here: > > 9790 st = gfc_find_symtree (ns->sym_root, name); > 9791 gcc_assert (st->n.sym->assoc); > > My tree is slightly modified, but the changes should not have > any effect here. > > Can you please have a look, too? > > Thanks, > Harald > > > Regards > > > > Paul > > > > PS This leaves 89645 and 99065 as the only real blockers to PR87477. > > These will take a little while to fix. They come about because the > > type of the associate name is determined by that of a derived type > > function that hasn't been parsed at the time that component references > > are being parsed. If the order of the contained procedures is > > reversed, both test cases compile correctly. The fix will comprise > > matching the component name to the accessible derived types, while > > keeping track of all the references in case the match is ambiguous and > > has to be fixed up later. > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein