This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Hi Janus,

The patch is good - OK for trunk.

Thanks

Paul

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]