Hi Sandra,
On 21.07.21 20:01, Sandra Loosemore wrote:
Hmmm. CFI_establish explicitly says that the elem_len has to be
greater than zero. It seems somewhat confusing that it's inconsistent
with the other functions that take an elem_len argument.
Congratulation – we have found a bug in the spec
On 16.07.21 05:46, Sandra Loosemore wrote:
When I was reading code in conjunction with fixing PR101317, I noticed
an unrelated bug in the implementation of CFI_allocate and
CFI_select_part: they were mis-handling the CFI_signed_char type as
if it were a Fortran character type for the purposes o
Hi Harald,
On 21.07.21 22:22, Harald Anlauf via Fortran wrote:
Another one of Gerhard's infamous testcases. We did not properly detect
and reject array elements of type CLASS as argument to an intrinsic when
it should be an array.
Regtested on x86_64-pc-linux-gnu. OK for mainline / 11-branch
On 21.07.21 22:36, Harald Anlauf via Gcc-patches wrote:
Anyway, here's a straightforward fix for a NULL pointer dereference for
an invalid argument to STAT. For an alternative patch by Steve see PR.
Regtested on x86_64-pc-linux-gnu. OK for mainline / 11-branch when it
reopens?
..
Fortran: I
Hi Tobias,
you are right in that I was barking up the wrong tree.
I was focussed too much on the testcase in the PR.
> I think that one is wrong. While CLASS_DATA (e) accesses
> e->ts.u.derived->components,
> which always works, your code assumes that there is only 'c' and not 'x%c'
> where
> '
Hi Tobias,
I am afraid we're really opening a can of worms here
> Additionally, I wonder whether that will work with:
>
> integer, pointer :: ptr
> integer function f()
>pointer :: f
>f = ptr
> end
> allocate(A, stat=f())
>
> The f() is a variable and definable – but I am currently
