From: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
To: abenson@carnegiescience.edu
Cc: gfortran <fortran@gcc.gnu.org>, GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [patch, fortan] PR87103 - [OOP] ICE in gfc_new_symbol() due to overlong symbol name
Date: Tue, 04 Sep 2018 17:43:00 -0000 [thread overview]
Message-ID: <CAC1BbcRSrUrOSWtAWK8pkOwPRwE7my5OJrdjhaYYfWjh01+bnw@mail.gmail.com> (raw)
In-Reply-To: <5056833.bhCz5HFUgy@andrew-precision-3520>
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/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?
thanks and cheers,
next prev parent reply other threads:[~2018-09-04 17:43 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-25 20:51 Andrew Benson
2018-09-04 16:43 ` [patch, fortan] PR87103 - [OOP] " Andrew Benson
2018-09-04 17:43 ` Bernhard Reutner-Fischer [this message]
[not found] ` <5aa0135b-1bdd-46de-e235-daed0a9a97e1@charter.net>
2018-09-05 10:35 ` Bernhard Reutner-Fischer
2018-09-05 14:24 ` Andrew Benson
2019-08-24 21:15 ` Andrew Benson
2019-08-28 22:48 ` Bernhard Reutner-Fischer
2019-08-30 8:22 ` Andrew Benson
2020-01-29 20:19 ` Andrew Benson
2020-01-30 16:28 ` Bernhard Reutner-Fischer
2020-01-30 17:50 ` Andrew Benson
2020-01-27 20:57 ` [patch, fortran] PR93461 - Bogus "symbol is already defined" with long subroutine names in submodule Andrew Benson
2020-01-28 8:21 ` Tobias Burnus
2020-01-28 16:41 ` Andrew Benson
2020-01-28 17:50 ` Tobias Burnus
2020-01-28 18:14 ` Andrew Benson
2020-01-29 0:45 ` [patch, fortran, wwwdocs] " Andrew Benson
2020-01-29 9:08 ` Gerald Pfeifer
2020-01-29 10:57 ` Tobias Burnus
2020-01-29 16:37 ` Andrew Benson
2020-01-27 23:41 ` [patch, fortran] PR93473 - ICE on valid with long module + submodule names Andrew Benson
2020-01-28 8:28 ` Tobias Burnus
2020-01-28 16:41 ` Andrew Benson
2020-01-28 17:32 ` Tobias Burnus
2020-01-28 18:05 ` Andrew Benson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAC1BbcRSrUrOSWtAWK8pkOwPRwE7my5OJrdjhaYYfWjh01+bnw@mail.gmail.com \
--to=rep.dot.nop@gmail.com \
--cc=abenson@carnegiescience.edu \
--cc=fortran@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).