Thanks Bernhard. On Wednesday, August 28, 2019 9:00:36 PM PDT 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.
-- * Andrew Benson: http://users.obs.carnegiescience.edu/abenson/contact.html * Galacticus: https://bitbucket.org/galacticusdev/galacticus
