This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [Patch, fortran] PR15809 (PR19276) - ICE and segfault with au toma tic character, dummy pointer arrays
- From: THOMAS Paul Richard 169137 <paul dot richard dot thomas at cea dot fr>
- To: "'Janne Blomqvist'" <jblomqvi at cc dot hut dot fi>
- Cc: "'gcc-patches at gcc dot gnu dot org'" <gcc-patches at gcc dot gnu dot org>, "'fortran at gcc dot gnu dot org'" <fortran at gcc dot gnu dot org>, "'toon at moene dot indiv dot nluug dot nl'" <toon at moene dot indiv dot nluug dot nl>, "'paulthomas2 at wanadoo dot fr'" <paulthomas2 at wanadoo dot fr>, "'giese025 at tc dot umn dot edu'" <giese025 at tc dot umn dot edu>, "'erik dot edelmann at iki dot fi'" <erik dot edelmann at iki dot fi>, "'Tobias dot Schlueter at Physik dot Uni-Muenchen dot DE'" <Tobias dot Schlueter at Physik dot Uni-Muenchen dot DE>
- Date: Tue, 29 Nov 2005 17:52:53 +0100
- Subject: RE: [Patch, fortran] PR15809 (PR19276) - ICE and segfault with au toma tic character, dummy pointer arrays
Janne,
> > PR19276 (I note that I have not committed the other two
> fixes to gcc-4.1; I
> > will do so in the next 24hours.)
...well, 48 hours.
>
> Thanks, it's a bit cleaner than my original version. See a few
> comments in the patch though.
OK - responses below.
> This is OK I guess.
>
> Actually, I'm not sure this is what we want to do. The problem is that
> there's only 24 bits in the dtype for the length, so it breaks for
> bigger character variables. There was some PR:s about this, and a
> number of intrinsics as well as transfer_array were rewritten to take
> an extra argument for the string length instead of using the
> descriptor. Or perhaps I misunderstood what this part of the patch
> does?
Within the procedure, there is a need for the size information for the array
elements to be available to build the array descriptor dtype. This is needed
in assignments of GFC_DESCRIPTOR_TYPE_Ps and their io, for example,
otherwise segfaults occur. The latter could be fixed, I guess, but I am not
sure that I want to get into the former just yet.
At some stage array representations will have to be reformed. How about I
hang a TODO patch here?
> This comment is not correct. If an intrinsic is a derived type
> component, it is scalarized, even with this patch.
You are quite right. Apologies.
>
> And yes, the updated testcase you sent by private mail works correctly
> on Linux.
Good. I need to understand why the original worked on Cygwin. It should not
have.
Subject to these corrections and comments, is the patch OK to go?
Paul