[patch, fortan] PR87103 - [OOP] ICE in gfc_new_symbol() due to overlong symbol name

[Bernhard Reutner-Fischer]

On 29 January 2020 21:19:52 CET, Andrew Benson <abenson@carnegiescience.edu> wrote:
>I think this patch is still waiting to be applied. I checked that it
>applies 
>against trunk (with line offsets) and reg tests cleanly and posted an
>updated 
>version (diff'd against current trunk) at:
>
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87103#c7
>
>I'm happy to go ahead and commit this if Bernhard is ok with me doing
>so.

Please go ahead and push it.
Many thanks in advance and sorry for the delay!
thanks,
>
>-Andrew
>
>On Wednesday, August 28, 2019 9:00:36 PM PST Bernhard Reutner-Fischer
>wrote:
>> On Fri, 23 Aug 2019 17:17:37 -0700
>> 
>> Andrew Benson <abenson@carnegiescience.edu> 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
><jvdelisle@charter.net> 
>wrote:
>> > > > On 09/04/2018 10:43 AM, Bernhard Reutner-Fischer wrote:
>> > > > > On Tue, 4 Sep 2018 at 18:43, Andrew Benson
>> > > > > <abenson@carnegiescience.edu>
>> > 
>> > 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/for
>> > > > > tran
>> > > > > -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  <aldot@gcc.gnu.org>
>> > > 
>> > > 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.