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.