This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, Fortran] PR fortran/45776: More variable definition checks
- From: Daniel Kraft <d at domob dot eu>
- To: Jerry DeLisle <jvdelisle at frontier dot com>
- Cc: Fortran List <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Sat, 25 Sep 2010 09:45:41 +0200
- Subject: Re: [Patch, Fortran] PR fortran/45776: More variable definition checks
- References: <4C9CD37E.2020602@domob.eu> <4C9D12C7.40500@domob.eu> <4C9D2312.30909@frontier.com>
Jerry DeLisle wrote:
On 09/24/2010 02:06 PM, Daniel Kraft wrote:
Here's an updated patch with the suggestions and IRC discussion
incorporated --
earlier than I expected, but anyways ;)
What do you think about the new solution? I will run a fresh regtest
tomorrow,
but at least the io_*, write_*, read_* and namelist_* tests seem to
pass. Ok?
Looking pretty good. What about this?
- /* Free this pointer now so that a warning/error is not
triggered
- below for the "Extension". */
- gfc_free_expr (dt->extra_comma);
+ /* Nullify this pointer now so that a warning/error is not
+ triggered below for the "Extension". */
dt->extra_comma = NULL;
If the *expr extra_comma is not already NULL then how can it's memory be
freed later if it is set to NULL here?
Because extra_comma is always (if it is present) a pointer to dt_io_kind
-- so dt_io_kind is free'ed always, and extra_comma can just be set to
NULL if we want the information "that it is not present". As I saw it,
extra_comma is (if it is set) always just the same expr as dt_io_kind is
-- thus I'd like to share it.
Of course, if you like it better, I can allocate a new gfc_expr* for
both of them and keep the old free'ing logic.
Yours,
Daniel
--
http://www.pro-vegan.info/
--
Done: Arc-Bar-Cav-Kni-Ran-Rog-Sam-Tou-Val-Wiz
To go: Hea-Mon-Pri