Hi Tobias, hi Paul, hi all,
sorry, for the mess. I did not understand the meaning of
build_fold_indirect_ref in the circumstances Paul pointed out. So if no
objections exist, I like to propose the previous patch from:
https://gcc.gnu.org/ml/fortran/2015-01/msg00056.html
to address the issue in p
Hi Paul and Andre, hi all,
Paul Richard Thomas wrote:
...
[From Andre's patch]
> + is a pointer to the variable holding the length. Therefore
> + remove the deref on call. */
> +parmse.string_length = TREE_OPERAND (parmse.string_length, 0);
> This is OK but I would u
Hi,
please don't commit this patch yet. I am seeing non-explainable ICEs and wrong
code now. Just have to investigate.
- Andre
On Tue, 13 Jan 2015 12:42:13 +0100 Andre Vehreschild wrote:
> Hi Paul,
>
> thanks for the reviewed and the valued comments.
>
> Just for completeness I have attache
Hi Paul,
thanks for the reviewed and the valued comments.
Just for completeness I have attached the patch with the changes requested.
Bootstraps and regtests ok on x86_64-linux-gnu.
Regards,
Andre
On Mon, 12 Jan 2015 22:07:29 +0100
Paul Richard Thomas wrote:
> Hi Andre,
>
> +
Hi Andre,
+ if (INDIRECT_REF_P (parmse.string_length))
+/* In chains of functions/procedure calls the string_length already
+ is a pointer to the variable holding the length. Therefore
+ remove the deref on call. */
+parmse.string_length = TREE_OPERAND (p
Hi Paul,
thanks for the review. I do not have commits rights.
Unfortunately is the patch not ok. I figured today, that it needs an extension
when function calls that return deferred char len arrays are nested. In this
special case the string length would have been lost. The attached extended
vers
Dear Andre,
This is OK for trunk. I have not been keeping track of whether or not
you have commit rights yet. If not, I will get to it sometime this
week.
Thanks for the patch.
Paul
On 10 January 2015 at 15:59, Andre Vehreschild wrote:
> Hi all,
>
> attached patch fixes the bug reported in pr
