This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, fortran] PR24311 - MERGE with character arguments causingICE in IO statements.
- From: Tobias Schlüter <tobias dot schlueter at physik dot uni-muenchen dot de>
- To: Paul Thomas <paulthomas2 at wanadoo dot fr>
- Cc: "'fortran at gcc dot gnu dot org'" <fortran at gcc dot gnu dot org>,patch <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 12 Oct 2005 12:00:25 +0200
- Subject: Re: [Patch, fortran] PR24311 - MERGE with character arguments causingICE in IO statements.
- References: <20051008234615.5F7331DC0BB@bromo.msbb.uc.edu> <1128860483.43490b43db2e4@www.cip.physik.uni-muenchen.de> <43493C51.2000000@wanadoo.fr> <434BE8EF.1080306@wanadoo.fr> <434C4505.9090400@wanadoo.fr>
Paul Thomas wrote:
> + /* Merge is unusual in that tsource can be a character constant, whose typespec
> + is transferred to that of the output array. This will not have had a charlen
> + created, so it is done here to prevent the middle-end being hit by an
> + apparently incomplete character array(PR24311). */
Wouldn't this be true for all other array transformational functions as well?
> + if (tsource->expr_type == EXPR_CONSTANT
> + && tsource->ts.type == BT_CHARACTER
> + && tsource->ts.cl == NULL)
> + {
> + tsource->ts.cl = gfc_get_charlen ();
> + tsource->ts.cl->next = gfc_current_ns->cl_list;
> + gfc_current_ns->cl_list = tsource->ts.cl;
> + tsource->ts.cl->length = gfc_int_expr (tsource->value.character.length);
> + }
Shouldn't this have happened much earlier? I.e. expr->ts.cl->length should be
expr->value.character.length, at least after constant substrings have been
evaluated?
- Tobi