Re: [Patch, Fortran] PR 78392: ICE in gfc_trans_auto_array_allocation, at fortran/trans-array.c:5979

[Janus Weil <janus at gcc dot gnu dot org>]

2016-12-12 18:37 GMT+01:00 Paul Richard Thomas <paul.richard.thomas@gmail.com>:
> Hi Janus,
>
> The patch is good - OK for trunk.

Thanks, Paul. Committed as r243580.

Cheers,
Janus



> On 12 December 2016 at 16:52, Janus Weil <janus@gcc.gnu.org> wrote:
>> Hi all,
>>
>> I hate to ping this patch once more, but somehow we need to come to a
>> conclusion here.
>>
>> The issue boils down to the fact that there is a piece of code in the
>> gfortran code which claims that specification functions are
>> 'constant', but I doubt that this is true. To my understanding the
>> concept of specification expressions and specification functions (see
>> section 7.1.6 in the F03 standard) was introduced essentially to refer
>> to side-effect-free expressions that can be used e.g. in a
>> type-specification context (array bounds, char-length parameters etc).
>>
>> However I think 'specification functions' do not necessarily need to
>> be 'constants', in the sense that subsequent invocations give always
>> the same (constant) result and their value can be determined at
>> compile time.
>>
>> My patch is at: https://gcc.gnu.org/ml/fortran/2016-11/msg00188.html
>> Further discussion at: https://gcc.gnu.org/ml/fortran/2016-11/msg00243.html
>>
>> Any comments, please!?!
>>
>> Cheers,
>> Janus
>>
>>
>>
>> 2016-12-03 8:05 GMT+01:00 Janus Weil <janus@gcc.gnu.org>:
>>> double-ping!
>>>
>>>
>>> 2016-11-26 10:45 GMT+01:00 Janus Weil <janus@gcc.gnu.org>:
>>>> ping!
>>>>
>>>>
>>>> 2016-11-19 10:12 GMT+01:00 Janus Weil <janus@gcc.gnu.org>:
>>>>> Hi all,
>>>>>
>>>>>> I previously assumed that the test case for this PR would be legal,
>>>>>> but by now I think that's wrong. The test case should be rejected, and
>>>>>> we already have checking mechanisms for this (see
>>>>>> resolve_fl_variable), but apparently they are not working.
>>>>>>
>>>>>> My current suspicion is that 'gfc_is_constant_expr' has a bug, because
>>>>>> it claims the call to the function 'get_i' to be a constant
>>>>>> expression. This is not true, because get_i() can not be reduced to a
>>>>>> compile-time constant.
>>>>>
>>>>> some more reading in the standard confirms this suspicion: In
>>>>> gfc_is_constant_expr there is a piece of code which claims that
>>>>> specification functions are constant. That is certainly not true, and
>>>>> so what I'm doing in the attached fix is to remove that code and add
>>>>> some references to the standard to make things clearer.
>>>>>
>>>>> The code that I'm removing has last been touched in this commit by
>>>>> Jerry six years ago:
>>>>>
>>>>> https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=166520
>>>>>
>>>>> However, this did not introduce the bug in the first place (not sure
>>>>> when that happened).
>>>>>
>>>>> In any case the new patch in the attachment regtests cleanly and
>>>>> correctly rejects the original test case as well as one of the cases
>>>>> mentioned by Dominique. Ok for trunk?
>>>>>
>>>>> Cheers,
>>>>> Janus
>>>>>
>>>>>
>>>>>
>>>>> 2016-11-19  Janus Weil  <janus@gcc.gnu.org>
>>>>>
>>>>>     PR fortran/78392
>>>>>     * expr.c (gfc_is_constant_expr): Specification functions are not
>>>>>     compile-time constants. Update documentation (add reference to F08
>>>>>     standard), add a FIXME.
>>>>>     (external_spec_function): Add reference to F08 standard.
>>>>>     * resolve.c (resolve_fl_variable): Ditto.
>>>>>
>>>>> 2016-11-19  Janus Weil  <janus@gcc.gnu.org>
>>>>>
>>>>>     PR fortran/78392
>>>>>     * gfortran.dg/constant_shape.f90: New test case.
>
>
>
> --
> If you're walking down the right path and you're willing to keep
> walking, eventually you'll make progress.
>
> Barack Obama