From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.smtpout.orange.fr (smtp01.smtpout.orange.fr [80.12.242.123]) by sourceware.org (Postfix) with ESMTPS id 72BED3858D20 for ; Mon, 28 Feb 2022 21:32:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 72BED3858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orange.fr Authentication-Results: sourceware.org; spf=none smtp.mailfrom=orange.fr Received: from [192.168.1.17] ([86.253.179.215]) by smtp.orange.fr with ESMTPA id Oncyn32xFu3WEOncznvZw1; Mon, 28 Feb 2022 22:32:21 +0100 X-ME-Helo: [192.168.1.17] X-ME-Auth: MDU4MTIxYWM4YWI0ZGE4ZTUwZWZmNTExZmI2ZWZlMThkM2ZhYiE5OWRkOGM= X-ME-Date: Mon, 28 Feb 2022 22:32:21 +0100 X-ME-IP: 86.253.179.215 Message-ID: <15b8291c-e95c-ce61-2739-a4032905a393@orange.fr> Date: Mon, 28 Feb 2022 22:32:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: [PATCH] PR fortran/104573 - ICE in resolve_structure_cons, at fortran/resolve.cc:1299 Content-Language: en-US To: Harald Anlauf , fortran , gcc-patches References: From: Mikael Morin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-11.2 required=5.0 tests=BAYES_00, FREEMAIL_FROM, GIT_PATCH_0, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, KAM_NUMSUBJECT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE, WEIRD_PORT autolearn=unavailable autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2022 21:32:23 -0000 Le 16/02/2022 à 22:20, Harald Anlauf via Fortran a écrit : > Dear Fortranners, > > while we detect invalid uses of type(*), we may run into other issues > later when the declared variable is used, leading to an ICE due to a > NULL pointer dereference. This is demonstrated by Gerhard's testcase. > > Steve and I came to rather similar fixes, see PR. Mine is attached. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > > Thanks, > Harald > > diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc > index 266e41e25b1..2fa1acdbd6d 100644 > --- a/gcc/fortran/resolve.cc > +++ b/gcc/fortran/resolve.cc > @@ -1288,15 +1288,17 @@ resolve_structure_cons (gfc_expr *expr, int init) > } > } > > - cons = gfc_constructor_first (expr->value.constructor); > - > /* A constructor may have references if it is the result of substituting a > parameter variable. In this case we just pull out the component we > want. */ > if (expr->ref) > comp = expr->ref->u.c.sym->components; > - else > + else if (expr->ts.u.derived) > comp = expr->ts.u.derived->components; These unprotected union accesses always make me nervous. I have tried (hard) to exhibit a case not fixed by your patch, and I have found the case below that almost qualifies, except that there is an ICE before anything can happen. With a minor tweak to prevent the ICE, the problem does appear. program p type t integer :: a end type character(3), parameter :: x = t(2) character(3), parameter :: y = x print *, y end In that case the character length information occupies the same space as a derived type symbol; the else-if condition evaluates to true, and everything breaks from there. So please use a condition on expr->ts.type instead. I think the relevant values associated with ts->u.derived are BT_DERIVED, BT_CLASS and BT_UNION. OK with that change. Thanks, and sorry for the time I took before looking at it.