From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13626 invoked by alias); 28 Aug 2019 19:01:37 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 13610 invoked by uid 89); 28 Aug 2019 19:01:37 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*Ad:U*jvdelisle, tot, beats, sk:jvdelis X-HELO: mail-wr1-f67.google.com Received: from mail-wr1-f67.google.com (HELO mail-wr1-f67.google.com) (209.85.221.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 28 Aug 2019 19:01:35 +0000 Received: by mail-wr1-f67.google.com with SMTP id c3so873375wrd.7; Wed, 28 Aug 2019 12:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=36SKv67ngm1i1IPGKkj4ZnxhuqzXhHRPtX6z5INzV+g=; b=QXi5vfM6CNEvYAhYvoCHqbbyCMX/y0+Zx5GvCF6Y4qFZQ4ghklOD0qWk4zdAdphDy6 AVA63LA7S8UqOCdUANZuBED2yN/KxgSUhZ1Lu72LM3LUGjnGtXFaOfronQa1YG+Y4weF KoRN5zAMo22kXJx2QbI5p3amDsjHBhlCv7P/moX45M7QLIUNmYAyLpgx4iQSiZbZmn+f 5E9jTmpvsw4m374fBv5XDOrZqb+pa2mKTBOmdUcqmagYYyB+bFbzDo1n54dAPd9W68XO LkSJcxjO4NkTAoOWofR+HSB5RHzMnUZorFFeW3lybZ90K71IaiZRIkrgmjw6RnIDyANW ooAQ== Return-Path: Received: from nbbrfq.loc (91-119-224-131.dsl.dynamic.surfer.at. [91.119.224.131]) by smtp.gmail.com with ESMTPSA id a142sm389030wme.2.2019.08.28.12.01.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Aug 2019 12:01:33 -0700 (PDT) Date: Wed, 28 Aug 2019 19:58:00 -0000 From: Bernhard Reutner-Fischer To: Andrew Benson Cc: fortran@gcc.gnu.org, Jerry DeLisle , GCC Patches , Bernhard Reutner-Fischer Subject: Re: [patch, fortan] PR87103 - [OOP] ICE in gfc_new_symbol() due to overlong symbol name Message-ID: <20190828210036.29080178@nbbrfq.loc> In-Reply-To: <12150885.gxExOQqZqa@andrew-precision-3520> References: <1642803.1Q0mUWRIpW@andrew-precision-3520> <5aa0135b-1bdd-46de-e235-daed0a9a97e1@charter.net> <12150885.gxExOQqZqa@andrew-precision-3520> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg01911.txt.bz2 On Fri, 23 Aug 2019 17:17:37 -0700 Andrew Benson wrote: > This PR is still open - I re-tested the patch on the current trunk. The patch > still applies with some line offsets (I've attached the updated patch) and > regtests cleanly. It would be very helpful to me to get this patch committed > if possible. I think Jerry ACKed the patch back then. I'll try to find the time to commit it maybe during one of the coming weekends unless someone else beats me to it.. Thanks for the reminder! Bernhard > > Thanks, > Andrew > > On Wednesday, September 5, 2018 12:35:04 PM PDT Bernhard Reutner-Fischer > wrote: > > On Wed, 5 Sep 2018 at 03:30, Jerry DeLisle wrote: > > > On 09/04/2018 10:43 AM, Bernhard Reutner-Fischer wrote: > > > > On Tue, 4 Sep 2018 at 18:43, Andrew Benson > wrote: > > > >> As suggested by Janus, PR87103 is easily fixed by the attached patch > > > >> which > > > >> increases GFC_MAX_SYMBOL_LEN to 76 (sufficient to hold the maximum > > > >> allowed F08 symbol length of 63, plus a null terminator, plus the > > > >> "__tmp_class_" prefix).> > > > > > This is so much wrong. > > > > Note that this will be fixed properly by the changes contained in the > > > > https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/aldot/fortran > > > > -fe-stringpool branch. > > > > There we keep the GFC_MAX_SYMBOL_LEN at 63 proper but use an internal > > > > buffer double that size which in turn is sufficient to hold all > > > > compiler-generated identifiers. > > > > See gfc_get_string() even in current TOT. > > > > > > > > Maybe we should bite the bullet and start to merge the stringpool > > > > changes now instead of this hack? > > > > > > It all makes sense to me, please proceed. (my 2 cents worth) > > > > Ok so i will reread the fortran-fe-stringpool series and submit it > > here for review. > > > > Let's return to the issue at hand for a moment, though. > > I tested the attached alternate fix on top of the > > fortran-fe-stringpool branch where it fixes PR87103. > > Maybe somebody has spare cycles to test it on top of current trunk? > > > > thanks, > > > > [PATCH,FORTRAN] PR87103: Remove max symbol length check from gfc_new_symbol > > > > gfc_match_name does check for too long names already. Since > > gfc_new_symbol is also called for symbols with internal names containing > > compiler-generated prefixes, these internal names can easily exceed the > > max_identifier_length mandated by the standard. > > > > gcc/fortran/ChangeLog > > > > 2018-09-04 Bernhard Reutner-Fischer > > > > PR fortran/87103 > > * expr.c (gfc_check_conformance): Check vsnprintf for truncation. > > * iresolve.c (gfc_get_string): Likewise. > > * symbol.c (gfc_new_symbol): Remove check for maximum symbol > > name length. Remove redundant 0 setting of new calloc()ed > > gfc_symbol. > >