This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, fortran, pr66578, v1] [F2008] Invalid free on allocate(...,source=a(:)) in block
- From: Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>
- To: Andre Vehreschild <vehre at gmx dot de>
- Cc: GCC-Patches-ML <gcc-patches at gcc dot gnu dot org>, GCC-Fortran-ML <fortran at gcc dot gnu dot org>, Mikael Morin <mikael dot morin at sfr dot fr>
- Date: Mon, 6 Jul 2015 21:55:51 +0200
- Subject: Re: [Patch, fortran, pr66578, v1] [F2008] Invalid free on allocate(...,source=a(:)) in block
- Authentication-results: sourceware.org; auth=none
- References: <20150706145823 dot 7e58cba2 at vepi2> <CAGkQGi+pw12_3y-Erb0T5E21zM8RcLPC1hUQHEabjPxczkC0gw at mail dot gmail dot com> <8551C1A9-7974-47F1-8F9D-F4CD5C611637 at gmx dot de>
Andre,
Forget my comment. I was seeing arrows all pointing in one direction !
Cheers
Paul
On 6 July 2015 at 21:42, Andre Vehreschild <vehre@gmx.de> wrote:
> Hi Paul,
>
> Thanks for the review, but I don't understand the regexp. rank_remap = ss->dimen < ndim != 0 in my eyes is not a legal expression. Did you mean something like rank_remap = ss->dimen < ndim && ndim != 0, or the like?
>
> Regards,
> Andre
>
> Am 6. Juli 2015 21:36:18 MESZ, schrieb Paul Richard Thomas <paul.richard.thomas@gmail.com>:
>>Dear Andre,
>>
>>Whilst it is probably OK in most circumstances, I would change:
>>s/rank_remap = ss->dimen < ndim/rank_remap = ss->dimen < ndim != 0
>>
>>Apart from that, it is indeed OK for trunk, in spite of your
>>expectations :-)
>>
>>Thanks for the patch
>>
>>Paul
>>
>>On 6 July 2015 at 14:58, Andre Vehreschild <vehre@gmx.de> wrote:
>>> Hi all,
>>>
>>> this is a proposal to patch PR 66578
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66578 . It extends work
>>of Mikael
>>> Morin. The patch fixes two issues:
>>>
>>> 1. a source'd allocate in a block: allocate(c, source=a(:)). The
>>issues occurs
>>> because due to the new handling of source-expressions in
>>trans_allocate() an
>>> array descriptor is created where previously just a plain array was
>>used. I.e.,
>>> GFC_DESCRIPTOR_TYPE_P (source) is true now and GFC_ARRAY_TYPE_P
>>(source) false,
>>> which made gfortran use the wrong bounds for the descriptor
>>(zero-based instead
>>> of one-based). This was fixed by Mikael's proposal.
>>>
>>> 2. a two-level array addressing lead to a segfault. I.e., when in a
>>> source-expression an array was used to index another object, then the
>>offset
>>> was computed incorrectly.
>>>
>>> Bootstraps and regtests fine on x86_64-linux-gnu/f21.
>>>
>>> Comments welcome!
>>>
>>> Regards,
>>> Andre
>>>
>>> PS: Experience shows that asking whether this ok for trunk is useless
>>;-) There
>>> is always something that could be improved. Open for suggestions.
>>> --
>>> Andre Vehreschild * Email: vehre ad gmx dot de
>
> --
> Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
> Mail: vehre@gmx.de * Tel.: +49 241 9291018
--
Outside of a dog, a book is a man's best friend. Inside of a dog it's
too dark to read.
Groucho Marx
- References:
- [Patch, fortran, pr66578, v1] [F2008] Invalid free on allocate(...,source=a(:)) in block
- Re: [Patch, fortran, pr66578, v1] [F2008] Invalid free on allocate(...,source=a(:)) in block
- From: Paul Richard Thomas
- Re: [Patch, fortran, pr66578, v1] [F2008] Invalid free on allocate(...,source=a(:)) in block