* [Bug fortran/109861] Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault.
2023-05-15 14:00 [Bug fortran/109861] New: Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault brtnfld at hdfgroup dot org
@ 2023-05-15 18:23 ` anlauf at gcc dot gnu.org
2023-05-15 18:49 ` anlauf at gcc dot gnu.org
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: anlauf at gcc dot gnu.org @ 2023-05-15 18:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109861
anlauf at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2023-05-15
Status|UNCONFIRMED |WAITING
Ever confirmed|0 |1
CC| |anlauf at gcc dot gnu.org
--- Comment #1 from anlauf at gcc dot gnu.org ---
I believe the sample code is misleading, and the behavior is expected:
SUBROUTINE h5aread_async_f(buf)
TYPE(C_PTR), INTENT(OUT) :: buf
You can see what happens if you specify the flag -fdump-tree-original as
part of F90FLAGS.
Now compare the dump-tree for INTENT(INOUT) vs. INTENT(OUT):
--- fcode.F90.005t.original.inout 2023-05-15 20:03:07.292148948 +0200
+++ fcode.F90.005t.original.out 2023-05-15 20:03:36.292208016 +0200
@@ -19,6 +19,7 @@
D.4223 = (void *) &attr_rdata0;
f_ptr = D.4223;
}
+ f_ptr = {CLOBBER};
h5aread_async_f (&f_ptr);
{
struct __st_parameter_dt dt_parm.0;
When the dummy argument buf is declared with INTENT(OUT), we mark the
actual argument in the caller with CLOBBER, which means that the optimizer
may throw away previous calculations and assignments as they do not matter.
If you add a line
print '(Z16.16)', buf
into that subroutine, you'll see that the clobber annotation serves its
purpose once optimization is enabled.
I think that you might want to cross-check your testcase with the NAG
compiler, or some other compiler which provides a means to initialize
INTENT(OUT) arguments to detect such code.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug fortran/109861] Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault.
2023-05-15 14:00 [Bug fortran/109861] New: Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault brtnfld at hdfgroup dot org
2023-05-15 18:23 ` [Bug fortran/109861] " anlauf at gcc dot gnu.org
@ 2023-05-15 18:49 ` anlauf at gcc dot gnu.org
2023-05-15 20:08 ` brtnfld at hdfgroup dot org
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: anlauf at gcc dot gnu.org @ 2023-05-15 18:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109861
--- Comment #2 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #1)
> I think that you might want to cross-check your testcase with the NAG
> compiler, or some other compiler which provides a means to initialize
> INTENT(OUT) arguments to detect such code.
I've just checked: NAG behaves similarly to gfortran; the code crashes
with INTENT(OUT) and works with INTENT(INOUT) as well as INTENT(IN).
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug fortran/109861] Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault.
2023-05-15 14:00 [Bug fortran/109861] New: Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault brtnfld at hdfgroup dot org
2023-05-15 18:23 ` [Bug fortran/109861] " anlauf at gcc dot gnu.org
2023-05-15 18:49 ` anlauf at gcc dot gnu.org
@ 2023-05-15 20:08 ` brtnfld at hdfgroup dot org
2023-05-15 21:22 ` anlauf at gcc dot gnu.org
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: brtnfld at hdfgroup dot org @ 2023-05-15 20:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109861
--- Comment #3 from Scot Breitenfeld <brtnfld at hdfgroup dot org> ---
I see the same issue with NAG, regardless of the optimization level. Our CI
testing had missed it because this was a parallel test, and we don't test
parallel with NAG.
I guess the issue is whether marking TYPE(C_PTR) as CLOBBER is correct. I
looked through the 2018 standard and could not locate anything that addresses
this use case. Are you interpreting the possibility that a TYPE(C_PTR) should
not be declared INTENT(OUT)?
I can instead change the subroutine to declare buf as
INTEGER(C_INT), INTENT(OUT), TARGET :: buf
and f_ptr = C_LOC(buf) and there is no issue. So it seems to depend on the TYPE
of the argument being passed.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug fortran/109861] Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault.
2023-05-15 14:00 [Bug fortran/109861] New: Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault brtnfld at hdfgroup dot org
` (2 preceding siblings ...)
2023-05-15 20:08 ` brtnfld at hdfgroup dot org
@ 2023-05-15 21:22 ` anlauf at gcc dot gnu.org
2023-05-15 21:25 ` kargl at gcc dot gnu.org
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: anlauf at gcc dot gnu.org @ 2023-05-15 21:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109861
--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to Scot Breitenfeld from comment #3)
> I guess the issue is whether marking TYPE(C_PTR) as CLOBBER is correct. I
> looked through the 2018 standard and could not locate anything that
> addresses this use case. Are you interpreting the possibility that a
> TYPE(C_PTR) should not be declared INTENT(OUT)?
Maybe I am missing your intention, but I interpret your code that you
want to pass a (C) pointer to variable attr_rdata0 to return your result.
But that needs to be intent(in). Your subroutine is not really supposed
to return a pointer but a result in the location the pointer dereferences.
Feel free to correct me.
> I can instead change the subroutine to declare buf as
>
> INTEGER(C_INT), INTENT(OUT), TARGET :: buf
>
> and f_ptr = C_LOC(buf) and there is no issue.
I cannot confirm this with my gcc installations, and there is no reason
that this should make a difference.
> So it seems to depend on the
> TYPE of the argument being passed.
There are cases where no clobber is currently generated. For example,
if the dummy variable is a Fortran pointer, which has a completely
different semantics from TYPE(C_PTR).
Still I don't understand why you don't use INTENT(IN) for the pointer.
In that case you could do things in the main like:
CALL H5Aread_async_f(C_LOC(attr_rdata0))
which appears to represent what I am guessing, and which gets rejected for
INTENT /= IN with a possibly more helpful error message.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug fortran/109861] Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault.
2023-05-15 14:00 [Bug fortran/109861] New: Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault brtnfld at hdfgroup dot org
` (3 preceding siblings ...)
2023-05-15 21:22 ` anlauf at gcc dot gnu.org
@ 2023-05-15 21:25 ` kargl at gcc dot gnu.org
2023-05-16 13:27 ` brtnfld at hdfgroup dot org
2023-05-16 13:29 ` brtnfld at hdfgroup dot org
6 siblings, 0 replies; 8+ messages in thread
From: kargl at gcc dot gnu.org @ 2023-05-15 21:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109861
kargl at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kargl at gcc dot gnu.org
--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to Scot Breitenfeld from comment #3)
> I see the same issue with NAG, regardless of the optimization level. Our CI
> testing had missed it because this was a parallel test, and we don't test
> parallel with NAG.
>
> I guess the issue is whether marking TYPE(C_PTR) as CLOBBER is correct. I
> looked through the 2018 standard and could not locate anything that
> addresses this use case. Are you interpreting the possibility that a
> TYPE(C_PTR) should not be declared INTENT(OUT)?
Fortran 2023, 8.5.10
The INTENT (OUT) attribute for a nonpointer dummy argument specifies
that the dummy argument becomes undefined on invocation of the procedure,
except for any subcomponents that are default-initialized (7.5.4.6).
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug fortran/109861] Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault.
2023-05-15 14:00 [Bug fortran/109861] New: Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault brtnfld at hdfgroup dot org
` (4 preceding siblings ...)
2023-05-15 21:25 ` kargl at gcc dot gnu.org
@ 2023-05-16 13:27 ` brtnfld at hdfgroup dot org
2023-05-16 13:29 ` brtnfld at hdfgroup dot org
6 siblings, 0 replies; 8+ messages in thread
From: brtnfld at hdfgroup dot org @ 2023-05-16 13:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109861
--- Comment #6 from Scot Breitenfeld <brtnfld at hdfgroup dot org> ---
Thanks for the standard reference. That is indeed what I was looking for. I
understand now that, in this case, the INTENT refers to whether C_PTR can be
changed and does not relate to the INTENT state of the target. I should change
all my usage cases to INTENT(IN) since none of the Fortran wrappers allow
changes to the pointer itself.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug fortran/109861] Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault.
2023-05-15 14:00 [Bug fortran/109861] New: Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault brtnfld at hdfgroup dot org
` (5 preceding siblings ...)
2023-05-16 13:27 ` brtnfld at hdfgroup dot org
@ 2023-05-16 13:29 ` brtnfld at hdfgroup dot org
6 siblings, 0 replies; 8+ messages in thread
From: brtnfld at hdfgroup dot org @ 2023-05-16 13:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109861
Scot Breitenfeld <brtnfld at hdfgroup dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |RESOLVED
Resolution|--- |INVALID
^ permalink raw reply [flat|nested] 8+ messages in thread