This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, fortran] PR24276 Components of a derived type array not passed as an array
- 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, gcc-patches at gcc dot gnu dot org
- Date: Sat, 21 Jan 2006 05:08:07 +0100
- Subject: Re: [Patch, fortran] PR24276 Components of a derived type array not passed as an array
- References: <1137754093.43d0bfedec230@www.cip.physik.uni-muenchen.de> <43D1524A.1040609@wanadoo.fr>
Paul Thomas wrote:
>>>+ {
>>>+ if (n > 0)
>>>+ {
>>>+ tree tmp_str;
>>>+ tmp = rse.loop->loopvar[n];
>>>+ tmp = fold_build2 (MINUS_EXPR, gfc_array_index_type,
>>>+ tmp, rse.loop->from[n]);
>>>+ tmp = fold_build2 (PLUS_EXPR, gfc_array_index_type,
>>>+ tmp, tmp_index);
>>>
>
> ^here
> this gives tmp = loopvar[n] - from [n] + tmp_index
Sigh. I must have stared at this for too long. Yes, this is of course right.
>> You should pull the
>>else branch out of the loop, and change the termination condition to n > 0.
>>
>
> I tried that - it looked horrible.
I'll take your word for it.
> Could you take a look again, please? I think that you missed a few
> tmp_index's.
Indeed.
> I am being hit again by this business off treating temporaries, in the
> course of sorting out dependencies in elemental subroutines. I note the
> wry note in the code forall about this not being entirely
> straightforward! Still, I will prevail and might propose an improvement
> to this patch subsequently.
You're a brave man!
> In the meantime, I think that this is OK
> and brings the sunshine of functionality, where there was none before.
> It is also so obscure that it is difficult to break anything else!
Agreed.
- Tobi