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.tho...@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 <ve...@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: ve...@gmx.de * Tel.: +49 241 9291018
