Hi Jerry,
so contrary to what the name of patch claims (pr120049-final.diff),
it fixes only the case of direct use of iso_c_binding, but not the
indirect one thru the other module, which is the reason for the
original ICE and the PR.
So if you want to push the incremental patch now, go ahead.
Cheers,
Harald
Am 18.05.25 um 23:46 schrieb Jerry D:
On 5/18/25 2:34 PM, Jerry D wrote:
On 5/18/25 2:10 PM, Harald Anlauf wrote:
Hi Jerry,
I found 2 corner invalid cases which are silently accepted with
your patch when iso_c_binding is used indirectly:
print *, c_associated(c_loc(val), C_NULL_FUNPTR)
print *, c_associated(C_NULL_FUNPTR, c_loc(val))
These should get rejected, too. Can you see how to catch these, too?
Thanks,
Harald
Yes, will do! I try to think of cases to run through on. This helps.
Thanks,
Jerry
--- snip ---
Will this was easy. I added those two lines to my current test2.f90 and
they are rejected. I will update the testcase in the ready to commit copy.
OK to push then?
$ gfc test2.f90
test2.f90:46:36:
46 | print *, c_associated(c_loc(val), C_NULL_FUNPTR)
| 1
Error: Argument C_PTR_2 at (1) to C_ASSOCIATED shall have the same type
as C_PTR_1: TYPE(c_ptr) instead of TYPE(c_funptr)
test2.f90:47:39:
47 | print *, c_associated(C_NULL_FUNPTR, c_loc(val))
| 1
Error: Argument C_PTR_2 at (1) to C_ASSOCIATED shall have the same type
as C_PTR_1: TYPE(c_funptr) instead of TYPE(c_ptr)
