On 29 January 2020 21:19:52 CET, Andrew Benson <aben...@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 <aben...@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 ><jvdeli...@charter.net> >wrote: >> > > > On 09/04/2018 10:43 AM, Bernhard Reutner-Fischer wrote: >> > > > > On Tue, 4 Sep 2018 at 18:43, Andrew Benson >> > > > > <aben...@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 <al...@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.
