From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) by sourceware.org (Postfix) with ESMTPS id 08CAC3858006; Thu, 4 Nov 2021 09:06:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 08CAC3858006 Received: by mail-wr1-x429.google.com with SMTP id d3so7460189wrh.8; Thu, 04 Nov 2021 02:06:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=q4CvxItIcTNk47DjCPQeVdrXmvfgJ76+L0/jI1GtU5Q=; b=HPuJ2Oxba3/SMJnjSUSAiyGKeD+V+d7MXS3C9vbGp5oBsQkuBEAqHDTCCCH0TeF3Ht mWhi30293qwLWFJGV/MYLxwLuyWPPbBWkiXk7U3Ys2V9WsjDzO6jU7UkVIPYiDs9g+va O1G6x3mXpgKWxv6FxJ35kBVLiGYNyqhnovWajeJNNBVbIiOepAfM5ZGKooNg2LA4xRZV oTeXCvo7YdZ+sklhF98ZFbeuk5qSaNBcu8pz9Tt0WihQWZ6FyduTjRtxW2kyARm8dBaB ErAzaKVSCvk1PyCmnKFNpE8mQBUFBmJaZKekdqe5Aeqtq+jrl5VlnBYDQqfvO7NZT5Os 83nA== X-Gm-Message-State: AOAM531pfjZGTEofuw8DtFxYULqyPTvHL9ssWGfgZ5CEJr1UOdPe1Ux/ H/4e7lKAeKVkgH9wNqQVLuw= X-Google-Smtp-Source: ABdhPJyYfQ7nWc7FPeWCOvbtsnYDNKKvF2MopDrARsvnBuO++T3ERnaMYKcC0sNmtdfgwYTn7SWIwQ== X-Received: by 2002:a5d:4882:: with SMTP id g2mr61720202wrq.399.1636016802099; Thu, 04 Nov 2021 02:06:42 -0700 (PDT) Received: from nbbrfq (91-119-98-250.dsl.dynamic.surfer.at. [91.119.98.250]) by smtp.gmail.com with ESMTPSA id t11sm4359334wrz.97.2021.11.04.02.06.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Nov 2021 02:06:41 -0700 (PDT) Date: Thu, 4 Nov 2021 10:06:37 +0100 From: Bernhard Reutner-Fischer To: Harald Anlauf via Fortran Cc: rep.dot.nop@gmail.com, Harald Anlauf , gcc-patches@gcc.gnu.org Subject: Re: *PING* [PATCH] PR fortran/69419 - ICE: tree check: expected array_type, have real_type in gfc_conv_array_initializer, at fortran/trans-array.c:5618 Message-ID: <20211104100637.6faeee6d@nbbrfq> In-Reply-To: <20c557a7-3769-b8ba-aa53-bd977146e348@gmx.de> References: <20c557a7-3769-b8ba-aa53-bd977146e348@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_NUMSUBJECT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: fortran@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Fortran mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2021 09:06:44 -0000 On Wed, 3 Nov 2021 21:00:41 +0100 Harald Anlauf via Fortran wrote: > *PING* >=20 > Am 27.10.21 um 21:09 schrieb Harald Anlauf via Fortran: > > Dear Fortranners, > >=20 > > when debugging the testcase, I noticed that a coarray declaration in > > a COMMON statement wrongly set the dimension attribute instead of the > > codimension. As a consequence, subsequent checks that catch this > > invalid situation would not trigger. > >=20 > > I see two possible solutions: > >=20 > > - in gfc_match_common, replace > >=20 > > /* Deal with an optional array specification after the > > symbol name. */ > > m =3D gfc_match_array_spec (&as, true, true); If coarrays are generally forbidden in commons then.. > >=20 > > by > >=20 > > m =3D gfc_match_array_spec (&as, true, false); .. this sounds right to me. > >=20 > > which in turn would lead to a syntax error. Interestingly, the Intel > > compiler also takes this route and gives a syntax error. > >=20 > > - check the resulting as->corank and emit an error as in the attached > > patch. If we want to be more helpful than a mere syntax error (and we should be) then yes. Otherwise we'd have to explicitly @@ -5275,9 +5275,19 @@ gfc_match_common (void) =20 /* Deal with an optional array specification after the symbol name. */ - m =3D gfc_match_array_spec (&as, true, true); + m =3D gfc_match_array_spec (&as, true, false); if (m =3D=3D MATCH_ERROR) goto cleanup; + if (m =3D=3D MATCH_NO) + { + /* See if it is a coarray and diagnose it nicely. */ + if (gfc_match_array_spec (&as, false, true) =3D=3D MATCH_YES) + { + gfc_error ("Symbol %qs in COMMON at %C cannot be a " + "coarray", sym->name); + goto cleanup; + } + } where your patch works equally well and is more concise. Maybe you want to add a test for the double-colon variant too? common /c2/ y[:] ! { dg-error "cannot be a coarray" } A type with a coarray seems to require to be allocatable so is rejected (properly, but not mentioning the coarray) with Error: Derived type variable =E2=80=98comm_ty1=E2=80=99 in COMMON at (1) ha= s an ultimate component that is allocatable When reading gfc_match_array_spec i thought that it might have been cleaner to split the coarray handling out to a separate gfc_match_coarray_spec but that's what we have. > >=20 > > The attached patch regtests fine on x86_64-pc-linux-gnu. OK for mainli= ne? LGTM but i cannot approve it. Thanks for the patch!