2016-12-12 18:37 GMT+01:00 Paul Richard Thomas <paul.richard.tho...@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 <ja...@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 <ja...@gcc.gnu.org>: >>> 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. > > > > -- > If you're walking down the right path and you're willing to keep > walking, eventually you'll make progress. > > Barack Obama