Hi Tobias, Thanks for taking care of this so rapidly :-)
OK for trunk and for 9-branch. Cheers Paul On Tue, 12 Nov 2019 at 14:42, Tobias Burnus <tob...@codesourcery.com> wrote: > > Regarding the uncontroversial part: CFI_address. This has been reported > by Vipul Parekh a few hours ago and the problem is: The lower bounds > stored in a bind(C) descriptor are either 0 – or, for > pointer/allocatable arrays, the value used during allocation/pointer > association (cf. F2018, 18.5.3, para 3, quoted in the PR). > > But CFI_address was always assuming 0. > > When fixing it, ISO_Fortran_binding_1.f90 started to fail – and looking > through the code, I run in two problems related to the "lower_bound"s: > > (1) CFI_section: Nothing in the standard states, which 'lower_bound's > shall be used for 'result'. Creating a section in Fortran always gives > .true. for "any(lbound(array(<section>)) == 1)" – and the CFI array > descriptors often uses '0' when Fortran has '1'. Another option would be > to propagate the specified array section on to the CFI descriptor (i.e. > the specified lower_bounds if not NULL or the "source"'s lower bounds > (if lower_bound is NULL) – gfortran does the latter. > > (2) CFI_establish: For allocatables, it is clear – base_addr == NULL. > For pointers, it is clear as well – it has to be '0' according to the > standard. But for CFI_attribute_other … > > I have now asked at > https://mailman.j3-fortran.org/pipermail/j3/2019-November/thread.html#11740 > – Bob thinks there might be an issue for (2) but both Bob and Bill claim > that it is well-defined for (1). But I am not convinced. However, as it > is unclear, I have now reverted my local changes and only kept the non > lower_bound changes for CFI_establish/CFI_section. > > Additionally, the 'dv' value of CFI_establish is some pointer to memory > which can hold an array descriptor. This memory can contain any garbage > (e.g. via dv = malloc(…) with glibc's MALLOC_PERTURB_ set). Hence, it > does not make sense to check 'dv' for a certain value. > > Build + regtested on x86_64-gnu-linux. > OK for the trunk? Should it be backported to GCC 9? > > Cheers, > > Tobias > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
