From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31754 invoked by alias); 8 Nov 2017 21:01:57 -0000 Mailing-List: contact fortran-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: fortran-owner@gcc.gnu.org Received: (qmail 31728 invoked by uid 89); 8 Nov 2017 21:01:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-9.3 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,GIT_PATCH_3,KAM_ASCII_DIVIDERS,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=1hi X-Spam-User: qpsmtpd, 2 recipients X-HELO: troutmask.apl.washington.edu Received: from troutmask.apl.washington.edu (HELO troutmask.apl.washington.edu) (128.95.76.21) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 08 Nov 2017 21:01:56 +0000 Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id vA8L1sRQ052032 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 8 Nov 2017 13:01:54 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id vA8L1sds052031; Wed, 8 Nov 2017 13:01:54 -0800 (PST) (envelope-from sgk) Date: Wed, 08 Nov 2017 21:01:00 -0000 From: Steve Kargl To: fortran@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: [PATCH, committed] Fix PR fortran/82884 Message-ID: <20171108210154.GA51940@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.7.2 (2016-11-26) X-IsSubscribed: yes X-SW-Source: 2017-11/txt/msg00053.txt.bz2 Once the bug is found, the fix is obvious. Briefly, in a typespec, ts.u.cl and ts.u.pad are in the same union. When parsing a Hollerith, ts.u.pad is is set to a nonzero value. Later, when resolving the array constructor with Hollerith entities, a reference to ts.u.cl is made which is a mangled non-NULL pointer. The fix is to clear ts.u.pad in the hollerith to character conversion function. Regression tested on x86_64-*-freebsd. 2017-11-08 Steven G. Kargl PR fortran/82884 * arith.c (gfc_hollerith2character): Clear pad. 2017-11-08 Steven G. Kargl PR fortran/82884 * gfortran.dg/hollerith_character_array_constructor.f90: New test. Index: gcc/fortran/arith.c =================================================================== --- gcc/fortran/arith.c (revision 254461) +++ gcc/fortran/arith.c (working copy) @@ -2604,6 +2604,7 @@ gfc_hollerith2character (gfc_expr *src, int kind) result = gfc_copy_expr (src); result->ts.type = BT_CHARACTER; result->ts.kind = kind; + result->ts.u.pad = 0; result->value.character.length = result->representation.length; result->value.character.string Index: gcc/testsuite/gfortran.dg/hollerith_character_array_constructor.f90 =================================================================== --- gcc/testsuite/gfortran.dg/hollerith_character_array_constructor.f90 (nonexistent) +++ gcc/testsuite/gfortran.dg/hollerith_character_array_constructor.f90 (working copy) @@ -0,0 +1,11 @@ +! { dg-do run } +! { dg-options "-w" } +! PR fortran/82884 +! Original code contributed by Gerhard Steinmetz +program p + character :: c(4) = [1h(, 1hi, 1h4, 1h)] + if (c(1) /= '(') call abort + if (c(2) /= 'i') call abort + if (c(3) /= '4') call abort + if (c(4) /= ')') call abort +end -- Steve