From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by sourceware.org (Postfix) with ESMTPS id C6F7D384AB6D; Thu, 9 May 2024 20:30:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C6F7D384AB6D Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=gmx.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmx.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C6F7D384AB6D Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=212.227.17.22 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1715286608; cv=none; b=eSHCvsGiFxoAnrOCFIXnOOAJ/3eUQNBO+LcFrHzF1vzRLkMBcqIO4X7lkoizScy2UFL+IRa1AubPOvakx+kz6pLO47RElBcpXKgPmfh/sXAtdsHGGs6sH4Uu4mS1v/6FHujQOYAtGUSHAgcOBjIItYxenEgKRmcZmd6j0ZVXbAQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1715286608; c=relaxed/simple; bh=t8TIGbCYChxwzXqafApENDkuk7bXa9R1JF2ivx77Ju8=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=F6UIIG6Z4kkANg/5NgPdvYVlP5pnZORNf+3+ArdITF31aE9D24BuvFpH7AZUqAc2InHQj/N0qCsJqPqadTcF59ehjExgjjV2LrD7R2Yp29Gvj5DmIEhg7hXw39z8++Ke1i8CEPxiP3W0E6vS6vOOr+HdWzRdWmnxr+W91RJYppw= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1715286603; x=1715891403; i=anlauf@gmx.de; bh=F9znZlZ9kmr2iZ1ZTAEND/Ncd2MTVAsyIooGGJQCuMc=; h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:Subject:To: References:From:In-Reply-To:Content-Type: Content-Transfer-Encoding:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=Jw5DSUrH0gIj17X/2kTU6AJy6y+fkBUIygQgRkmOpHbLMSWWvbNpx87EkGb5UR5R TTySG17TkAL99RDiXfTEQmAVHDAxcDNH6t3IkcPtk6pAIlJKWWr7iPgYAZSU4of65 Jri2gK7SQjdE/6+OoxGHML4TXPWYaTbRuqloRlVUXf2yKNockBuYBDsC9CSCXzULe KIZqN6sAuCw5NC2qRay1BL3Bt0gfluhSynUeN/tbYqjQtml8xlKjvkkOuUqf6L3Vi V6TUXXBhnvkDyml1hqkmrsNNcvfzcFZfaMbDrX+A+AcwgoCHnHeHCat5iARebsxc5 GnoKDoPuwkk3/DtzwQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [192.168.178.29] ([79.232.151.93]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N63VY-1sgjCd2vsG-016RDk; Thu, 09 May 2024 22:30:03 +0200 Message-ID: <993e753f-9562-48e7-8334-141fa97e6866@gmx.de> Date: Thu, 9 May 2024 22:30:00 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Fortran: improve attribute conflict checking [PR93635] To: Mikael Morin , fortran , gcc-patches Newsgroups: gmane.comp.gcc.patches,gmane.comp.gcc.fortran References: <3e378dec-109f-44b2-92c1-50a0f3866ab7@orange.fr> Content-Language: en-US From: Harald Anlauf In-Reply-To: <3e378dec-109f-44b2-92c1-50a0f3866ab7@orange.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:a9a5yE6ooOoWHZKanbI/nLzeRfdfKgDeoYGeHqjJ6/a9GWkFE+N MsaPsjiGG1Bl9L7GsxJydxuxXngiF4lKoDCSUwbZqvTw9fN7KwdCUg1zGsScgGzKfVaqQrk d9l4rwiuozWkqitsL1MS7ODPvojzsn9woUPLoy0LVA8JWyy4ex3H840i/P5Juk6OVgFRKE5 QE0ot6YSc0iR+gZRLOcXg== UI-OutboundReport: notjunk:1;M01:P0:T/mWJBzkpQo=;MYRn9U+ZEcw9ICQTLFHKMjvl7m5 GkTIYVR5Z+pzGdm2YN7kFVN5yTgeitPrHwxyRKfifET5/xZvPTK+oR7WcbP4h9/PQaxo7EjHC ooriZtibfWeHKt/f5RRuMGaAVc5GyvOFFkhyNDcw7VeusHIPYUKilNLfQ0vp9n/NB9c9TEvD5 abT6n9qawvkJn6gkf/ZXvYs+o0EZqThU1GTNGSIkNP16dNpN+Ix7VSFfJfK0z4AspO3eEpNeN G+g7ayh6reufbgTFdzvGsR6Lr6/007w3R6I/H6tsXToAvy5u2SNhaFISDfJ3oajfnYKdG0SxI 1TnRelt0qpTfL2dVH7FoB3pvhKEKmz0Vl65clHOcxPO/Ojy5/dTRcpRcpzqOjvJ3/rEiPBwn+ PLFxn/W0ohzC8batZhH9XrgWfj8wy2GaHvbYxVwmtcRMQ6Ay+ubxTdOIx/3ZvmzeHWXjhp++O 3bjaf0kj0S5vwbjHvbrSYRFVZKpvgzUyEV+LzjDieGsmRaPWrQJMIf2vUfCMg3SXm/phfffIx DtdT57iZNgzageD5ZvlIS1Q5Nsm8ox6H361PgIaDXsAOJxOG5K//TaqWfWd6/OoE2x0zOeNuP jGSPxLJXmJ5MeTG38/ixyeAtyPugK1dfHFw632MJRNJrVd9ZkBNuCSd6vvDqVjQTd4QK+AfJW bLObEuz7E9puPp+Btkm18LckDMQeOCotSzP4SiAJonsx/v02ClDkznEUoopbh+pmr6io5N01U 9zAoQLlTO9ztRrcZB8dWsyuTr8m6M1RM+28AI2evdQQhnhoEq9ulm6ZXFWaqrcJVDywlvEgwN MUN+VaBR9sDsk/fc4fD//Vcf4iII2cobD5VyZPBwwxpcs= X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP,URIBL_BLACK,WEIRD_PORT autolearn=no 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 Mikael, Am 09.05.24 um 21:51 schrieb Mikael Morin: > Hello, > > Le 06/05/2024 =C3=A0 21:33, Harald Anlauf a =C3=A9crit=C2=A0: >> Dear all, >> >> I've been contemplating whether to submit the attached patch. >> It addresses an ICE-on-invalid as reported in the PR, and also >> fixes an accepts-invalid (see testcase), plus maybe some more, >> related due to incomplete checking of symbol attribute conflicts. >> >> The fix does not fully address the general issue, which is >> analyzed by Steve: some of the checks do depend on the selected >> Fortran standard, and under circumstances such as in the testcase >> the checking of other, standard-version-independent conflicts >> simply does not occur. >> >> Steve's solution would fix that, but unfortunately leads to issues >> with error recovery in notoriously fragile parts of the FE: e.g. >> testcase pr87907.f90 needs adjusting, and minor variations >> of it will lead to various other horrendous ICEs that remind >> of existing PRs where parsing or resolution goes sideways. >> >> I therefore propose a much simpler approach: move - if possible - >> selected of the standard-version-dependent checks after the >> version-independent ones.=C2=A0 I think this could help in getting more >> consistent error reporting and recovery.=C2=A0 However, I did *not* >> move those checks that are critical when processing interfaces. >> (-> pr87907.f90 / (sub)modules) >> > Your patch looks clean, but I'm concerned that the order of the checks > should be the important ones first, regardless of their standard > version.=C2=A0 I'm trying to look at the ICE caused by your other tentat= ive > patch at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D93635#c6 but I > can't reproduce the problem.=C2=A0 Do you by any chance have around some= of > the variations causing "horrendous" ICEs? Oh, that's easy. Just move the block conf_std (allocatable, dummy, GFC_STD_F2003); conf_std (allocatable, function, GFC_STD_F2003); conf_std (allocatable, result, GFC_STD_F2003); towards the end of the gfc_check_conflict before the return true. While the error messages for the original gfortran.dg/pr87907.f90 look harmless, commenting out the main program p I get: pr87907.f90:15:18: 15 | subroutine g(x) ! { dg-error "mismatch in argument" } | 1 Error: FUNCTION attribute conflicts with SUBROUTINE attribute in 'g' at (1= ) f951: internal compiler error: Segmentation fault 0x13b8ec2 crash_signal ../../gcc-trunk/gcc/toplev.cc:319 0xba530e free_sym_tree ../../gcc-trunk/gcc/fortran/symbol.cc:4026 0xba5319 free_sym_tree ../../gcc-trunk/gcc/fortran/symbol.cc:4026 0xba5319 free_sym_tree ../../gcc-trunk/gcc/fortran/symbol.cc:4026 0xba5319 free_sym_tree ../../gcc-trunk/gcc/fortran/symbol.cc:4026 0xba5609 gfc_free_namespace(gfc_namespace*&) ../../gcc-trunk/gcc/fortran/symbol.cc:4168 0xba39c1 gfc_free_symbol(gfc_symbol*&) ../../gcc-trunk/gcc/fortran/symbol.cc:3173 0xba3b89 gfc_release_symbol(gfc_symbol*&) ../../gcc-trunk/gcc/fortran/symbol.cc:3216 0xba5339 free_sym_tree ../../gcc-trunk/gcc/fortran/symbol.cc:4029 0xba5609 gfc_free_namespace(gfc_namespace*&) ../../gcc-trunk/gcc/fortran/symbol.cc:4168 0xba58ef gfc_symbol_done_2() ../../gcc-trunk/gcc/fortran/symbol.cc:4236 0xb12ec8 gfc_done_2() ../../gcc-trunk/gcc/fortran/misc.cc:387 0xb4ac7f clean_up_modules ../../gcc-trunk/gcc/fortran/parse.cc:7057 0xb4af02 translate_all_program_units ../../gcc-trunk/gcc/fortran/parse.cc:7122 0xb4b735 gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.cc:7413 0xbb626f gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.cc:241 Restoring the main program but simply adding "end subroutine g" where it is naively expected gives: pr87907.f90:15:18: 15 | subroutine g(x) ! { dg-error "mismatch in argument" } | 1 Error: FUNCTION attribute conflicts with SUBROUTINE attribute in 'g' at (1= ) pr87907.f90:16:9: 16 | end subroutine g | 1 Error: Expecting END SUBMODULE statement at (1) pr87907.f90:20:7: 20 | use m ! { dg-error "has a type" } | 1 21 | integer :: x =3D 3 22 | call g(x) ! { dg-error "which is not consistent with" } | 2 Error: 'g' at (1) has a type, which is not consistent with the CALL at (2) f951: internal compiler error: in gfc_free_namespace, at fortran/symbol.cc:4164 0xba55e1 gfc_free_namespace(gfc_namespace*&) ../../gcc-trunk/gcc/fortran/symbol.cc:4164 0xba39c1 gfc_free_symbol(gfc_symbol*&) ../../gcc-trunk/gcc/fortran/symbol.cc:3173 0xba3b89 gfc_release_symbol(gfc_symbol*&) ../../gcc-trunk/gcc/fortran/symbol.cc:3216 0xba5339 free_sym_tree ../../gcc-trunk/gcc/fortran/symbol.cc:4029 0xba5609 gfc_free_namespace(gfc_namespace*&) ../../gcc-trunk/gcc/fortran/symbol.cc:4168 0xba58ef gfc_symbol_done_2() ../../gcc-trunk/gcc/fortran/symbol.cc:4236 0xb12ec8 gfc_done_2() ../../gcc-trunk/gcc/fortran/misc.cc:387 0xb4ac7f clean_up_modules ../../gcc-trunk/gcc/fortran/parse.cc:7057 0xb4af02 translate_all_program_units ../../gcc-trunk/gcc/fortran/parse.cc:7122 0xb4b735 gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.cc:7413 0xbb626f gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.cc:241 Now adding -std=3Df2018 to the compiler flags I get: pr87907.f90:15:18: 15 | subroutine g(x) ! { dg-error "mismatch in argument" } | 1 Error: FUNCTION attribute conflicts with SUBROUTINE attribute in 'g' at (1= ) pr87907.f90:16:9: 16 | end subroutine g | 1 Error: Expecting END SUBMODULE statement at (1) pr87907.f90:20:7: 20 | use m ! { dg-error "has a type" } | 1 21 | integer :: x =3D 3 22 | call g(x) ! { dg-error "which is not consistent with" } | 2 Error: 'g' at (1) has a type, which is not consistent with the CALL at (2) free(): invalid pointer f951: internal compiler error: Aborted 0x13b8ec2 crash_signal ../../gcc-trunk/gcc/toplev.cc:319 0xba584f gfc_free_namespace(gfc_namespace*&) ../../gcc-trunk/gcc/fortran/symbol.cc:4207 0xba39c1 gfc_free_symbol(gfc_symbol*&) ../../gcc-trunk/gcc/fortran/symbol.cc:3173 0xba3b89 gfc_release_symbol(gfc_symbol*&) ../../gcc-trunk/gcc/fortran/symbol.cc:3216 0xba5339 free_sym_tree ../../gcc-trunk/gcc/fortran/symbol.cc:4029 0xba5609 gfc_free_namespace(gfc_namespace*&) ../../gcc-trunk/gcc/fortran/symbol.cc:4168 0xba58ef gfc_symbol_done_2() ../../gcc-trunk/gcc/fortran/symbol.cc:4236 0xb12ec8 gfc_done_2() ../../gcc-trunk/gcc/fortran/misc.cc:387 0xb4ac7f clean_up_modules ../../gcc-trunk/gcc/fortran/parse.cc:7057 0xb4af02 translate_all_program_units ../../gcc-trunk/gcc/fortran/parse.cc:7122 0xb4b735 gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.cc:7413 0xbb626f gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.cc:241 I'll stop here... We currently do not recover well from errors, and the prevention of corrupted namespaces is apparently a goal we aim at. Cheers, Harald >> The patch therefore does not require any testsuite update and >> should not give any other surprises, so it should be very safe. >> The plan is also to leave the PR open for the time being. >> >> Regtesting on x86_64-pc-linux-gnu.=C2=A0 OK for mainline? >> >> Thanks, >> Harald >> > > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214]) by sourceware.org (Postfix) with ESMTPS id CEA3D38449C0 for ; Thu, 9 May 2024 20:30:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CEA3D38449C0 Authentication-Results: sourceware.org; dmarc=fail (p=quarantine dis=none) header.from=gmx.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=m.gmane-mx.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org CEA3D38449C0 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=116.202.254.214 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1715286615; cv=none; b=c4hmAF+tAK9CY2uFezFj37mroEI+ZcN8dM5wYU6pPYhLaGzWpfmN1N4veauN1mLotnuz+Fs9Z4cDPF2H1Wv4ZxelgNQUcchUf86BdKEqkOij6PSodZEgxZjpT6+3wsBnr1c2WO5expsqUlwh+tyEMVdUvQr9lxv7l0oA2KAdj4E= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1715286615; c=relaxed/simple; bh=XWnLGQ5zB8WOCKSmCPqHxt5B7/3GK22Xc503kcgcM2o=; h=To:From:Subject:Date:Message-ID:Mime-Version; b=JtTb6dic9ZaKmUXwsyA+aygo5WrZ9gYVdX2MCM+QNIS84gvZNytlD43qKFWwr0xAP7qmxIR4zNd4QSRumQrXT9J+Sg9JJ7aT9oRH9retiBYMBlwYbRJIQmxTSUHUFr5ul9AY91aq6FTM0FdcUadO8OQy1KCZb/f4G2sZzKdhSlM= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1s5AP4-0008N0-Vt for gcc-patches@gcc.gnu.org; Thu, 09 May 2024 22:30:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gcc-patches@gcc.gnu.org From: Harald Anlauf Subject: Re: [PATCH] Fortran: improve attribute conflict checking [PR93635] Date: Thu, 9 May 2024 22:30:00 +0200 Message-ID: <993e753f-9562-48e7-8334-141fa97e6866@gmx.de> References: <3e378dec-109f-44b2-92c1-50a0f3866ab7@orange.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit User-Agent: Mozilla Thunderbird Content-Language: en-US In-Reply-To: <3e378dec-109f-44b2-92c1-50a0f3866ab7@orange.fr> Cc: fortran@gcc.gnu.org X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,KAM_SHORT,SPF_HELO_NONE,SPF_PASS,TXREP,URIBL_BLACK,WEIRD_PORT autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Message-ID: <20240509203000.1d3CYoGavW7oOf5UOr1biQ7oWCMHEzFQiH79-LhrYTA@z> Hi Mikael, Am 09.05.24 um 21:51 schrieb Mikael Morin: > Hello, > > Le 06/05/2024 à 21:33, Harald Anlauf a écrit : >> Dear all, >> >> I've been contemplating whether to submit the attached patch. >> It addresses an ICE-on-invalid as reported in the PR, and also >> fixes an accepts-invalid (see testcase), plus maybe some more, >> related due to incomplete checking of symbol attribute conflicts. >> >> The fix does not fully address the general issue, which is >> analyzed by Steve: some of the checks do depend on the selected >> Fortran standard, and under circumstances such as in the testcase >> the checking of other, standard-version-independent conflicts >> simply does not occur. >> >> Steve's solution would fix that, but unfortunately leads to issues >> with error recovery in notoriously fragile parts of the FE: e.g. >> testcase pr87907.f90 needs adjusting, and minor variations >> of it will lead to various other horrendous ICEs that remind >> of existing PRs where parsing or resolution goes sideways. >> >> I therefore propose a much simpler approach: move - if possible - >> selected of the standard-version-dependent checks after the >> version-independent ones.  I think this could help in getting more >> consistent error reporting and recovery.  However, I did *not* >> move those checks that are critical when processing interfaces. >> (-> pr87907.f90 / (sub)modules) >> > Your patch looks clean, but I'm concerned that the order of the checks > should be the important ones first, regardless of their standard > version.  I'm trying to look at the ICE caused by your other tentative > patch at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93635#c6 but I > can't reproduce the problem.  Do you by any chance have around some of > the variations causing "horrendous" ICEs? Oh, that's easy. Just move the block conf_std (allocatable, dummy, GFC_STD_F2003); conf_std (allocatable, function, GFC_STD_F2003); conf_std (allocatable, result, GFC_STD_F2003); towards the end of the gfc_check_conflict before the return true. While the error messages for the original gfortran.dg/pr87907.f90 look harmless, commenting out the main program p I get: pr87907.f90:15:18: 15 | subroutine g(x) ! { dg-error "mismatch in argument" } | 1 Error: FUNCTION attribute conflicts with SUBROUTINE attribute in 'g' at (1) f951: internal compiler error: Segmentation fault 0x13b8ec2 crash_signal ../../gcc-trunk/gcc/toplev.cc:319 0xba530e free_sym_tree ../../gcc-trunk/gcc/fortran/symbol.cc:4026 0xba5319 free_sym_tree ../../gcc-trunk/gcc/fortran/symbol.cc:4026 0xba5319 free_sym_tree ../../gcc-trunk/gcc/fortran/symbol.cc:4026 0xba5319 free_sym_tree ../../gcc-trunk/gcc/fortran/symbol.cc:4026 0xba5609 gfc_free_namespace(gfc_namespace*&) ../../gcc-trunk/gcc/fortran/symbol.cc:4168 0xba39c1 gfc_free_symbol(gfc_symbol*&) ../../gcc-trunk/gcc/fortran/symbol.cc:3173 0xba3b89 gfc_release_symbol(gfc_symbol*&) ../../gcc-trunk/gcc/fortran/symbol.cc:3216 0xba5339 free_sym_tree ../../gcc-trunk/gcc/fortran/symbol.cc:4029 0xba5609 gfc_free_namespace(gfc_namespace*&) ../../gcc-trunk/gcc/fortran/symbol.cc:4168 0xba58ef gfc_symbol_done_2() ../../gcc-trunk/gcc/fortran/symbol.cc:4236 0xb12ec8 gfc_done_2() ../../gcc-trunk/gcc/fortran/misc.cc:387 0xb4ac7f clean_up_modules ../../gcc-trunk/gcc/fortran/parse.cc:7057 0xb4af02 translate_all_program_units ../../gcc-trunk/gcc/fortran/parse.cc:7122 0xb4b735 gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.cc:7413 0xbb626f gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.cc:241 Restoring the main program but simply adding "end subroutine g" where it is naively expected gives: pr87907.f90:15:18: 15 | subroutine g(x) ! { dg-error "mismatch in argument" } | 1 Error: FUNCTION attribute conflicts with SUBROUTINE attribute in 'g' at (1) pr87907.f90:16:9: 16 | end subroutine g | 1 Error: Expecting END SUBMODULE statement at (1) pr87907.f90:20:7: 20 | use m ! { dg-error "has a type" } | 1 21 | integer :: x = 3 22 | call g(x) ! { dg-error "which is not consistent with" } | 2 Error: 'g' at (1) has a type, which is not consistent with the CALL at (2) f951: internal compiler error: in gfc_free_namespace, at fortran/symbol.cc:4164 0xba55e1 gfc_free_namespace(gfc_namespace*&) ../../gcc-trunk/gcc/fortran/symbol.cc:4164 0xba39c1 gfc_free_symbol(gfc_symbol*&) ../../gcc-trunk/gcc/fortran/symbol.cc:3173 0xba3b89 gfc_release_symbol(gfc_symbol*&) ../../gcc-trunk/gcc/fortran/symbol.cc:3216 0xba5339 free_sym_tree ../../gcc-trunk/gcc/fortran/symbol.cc:4029 0xba5609 gfc_free_namespace(gfc_namespace*&) ../../gcc-trunk/gcc/fortran/symbol.cc:4168 0xba58ef gfc_symbol_done_2() ../../gcc-trunk/gcc/fortran/symbol.cc:4236 0xb12ec8 gfc_done_2() ../../gcc-trunk/gcc/fortran/misc.cc:387 0xb4ac7f clean_up_modules ../../gcc-trunk/gcc/fortran/parse.cc:7057 0xb4af02 translate_all_program_units ../../gcc-trunk/gcc/fortran/parse.cc:7122 0xb4b735 gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.cc:7413 0xbb626f gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.cc:241 Now adding -std=f2018 to the compiler flags I get: pr87907.f90:15:18: 15 | subroutine g(x) ! { dg-error "mismatch in argument" } | 1 Error: FUNCTION attribute conflicts with SUBROUTINE attribute in 'g' at (1) pr87907.f90:16:9: 16 | end subroutine g | 1 Error: Expecting END SUBMODULE statement at (1) pr87907.f90:20:7: 20 | use m ! { dg-error "has a type" } | 1 21 | integer :: x = 3 22 | call g(x) ! { dg-error "which is not consistent with" } | 2 Error: 'g' at (1) has a type, which is not consistent with the CALL at (2) free(): invalid pointer f951: internal compiler error: Aborted 0x13b8ec2 crash_signal ../../gcc-trunk/gcc/toplev.cc:319 0xba584f gfc_free_namespace(gfc_namespace*&) ../../gcc-trunk/gcc/fortran/symbol.cc:4207 0xba39c1 gfc_free_symbol(gfc_symbol*&) ../../gcc-trunk/gcc/fortran/symbol.cc:3173 0xba3b89 gfc_release_symbol(gfc_symbol*&) ../../gcc-trunk/gcc/fortran/symbol.cc:3216 0xba5339 free_sym_tree ../../gcc-trunk/gcc/fortran/symbol.cc:4029 0xba5609 gfc_free_namespace(gfc_namespace*&) ../../gcc-trunk/gcc/fortran/symbol.cc:4168 0xba58ef gfc_symbol_done_2() ../../gcc-trunk/gcc/fortran/symbol.cc:4236 0xb12ec8 gfc_done_2() ../../gcc-trunk/gcc/fortran/misc.cc:387 0xb4ac7f clean_up_modules ../../gcc-trunk/gcc/fortran/parse.cc:7057 0xb4af02 translate_all_program_units ../../gcc-trunk/gcc/fortran/parse.cc:7122 0xb4b735 gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.cc:7413 0xbb626f gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.cc:241 I'll stop here... We currently do not recover well from errors, and the prevention of corrupted namespaces is apparently a goal we aim at. Cheers, Harald >> The patch therefore does not require any testsuite update and >> should not give any other surprises, so it should be very safe. >> The plan is also to leave the PR open for the time being. >> >> Regtesting on x86_64-pc-linux-gnu.  OK for mainline? >> >> Thanks, >> Harald >> > >