double-ping!

2016-11-26 10:45 GMT+01:00 Janus Weil <ja...@gcc.gnu.org>:
> ping!
>
>
> 2016-11-19 10:12 GMT+01:00 Janus Weil <ja...@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  <ja...@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  <ja...@gcc.gnu.org>
>>
>>     PR fortran/78392
>>     * gfortran.dg/constant_shape.f90: New test case.

Reply via email to