public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/94221] New: Explicit assignment in type is ignored in some cases
@ 2020-03-19 8:23 r.dilz at tue dot nl
2020-03-19 11:46 ` [Bug fortran/94221] " rguenth at gcc dot gnu.org
0 siblings, 1 reply; 2+ messages in thread
From: r.dilz at tue dot nl @ 2020-03-19 8:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94221
Bug ID: 94221
Summary: Explicit assignment in type is ignored in some cases
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: r.dilz at tue dot nl
Target Milestone: ---
When working with types, I found some unexpected behavior.
It seems that the variables in a type do not get assigned their proper values
reliably. I suspect that the compiler does not check well enough whether a
variable is used or not and the whole assignment is then optimized away.
Below is a minimal example:
module pyimp
use iso_c_binding
type,bind(C) :: container
integer(C_INT) :: val = 3 !assignment here is not reliable in gfortran
end type container
contains
type(container) function test() bind(c,name='test')
print*,"running test"
print*,test%val
end function test
type(container) function test2() bind(c,name='test2')
print*,"running test - here test%val is not initialized"
end function test2
end module pyimp
program main
use pyimp
type(container) :: a
print*,"First: the test%var is initialized by an extra print statement:"
a = test()
print*,a%val
a = test2()
print*,"But in test2 it is not: "
print*,a%val
end program main
Compiled with fortran 4.8 and fortran 9.2.1, both give the same output:
First: the test%var is initialized by an extra print statement:
running test
3
3
running test - here test%val is not initialized
But in test2 it is not:
0
Whereas in test2 it should also output 3. Using ifort, I do get the expected
result for test2.
^ permalink raw reply [flat|nested] 2+ messages in thread
* [Bug fortran/94221] Explicit assignment in type is ignored in some cases
2020-03-19 8:23 [Bug fortran/94221] New: Explicit assignment in type is ignored in some cases r.dilz at tue dot nl
@ 2020-03-19 11:46 ` rguenth at gcc dot gnu.org
0 siblings, 0 replies; 2+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-03-19 11:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94221
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Known to fail| |10.0
Status|UNCONFIRMED |NEW
Last reconfirmed| |2020-03-19
Ever confirmed|0 |1
Keywords| |wrong-code
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
test2 lacks a return stmt and initialization of the return value:
test2 ()
{
{
struct __st_parameter_dt dt_parm.0;
dt_parm.0.common.filename = &"t.f90"[1]{lb: 1 sz: 1};
dt_parm.0.common.line = 15;
dt_parm.0.common.flags = 128;
dt_parm.0.common.unit = 6;
_gfortran_st_write (&dt_parm.0);
_gfortran_transfer_character_write (&dt_parm.0, &"running test - here
test%val is not initialized"[1]{lb: 1 sz: 1}, 47);
_gfortran_st_write_done (&dt_parm.0);
}
}
but the caller still expects one:
a = test ();
indeed a frontend issue.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2020-03-19 11:46 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-19 8:23 [Bug fortran/94221] New: Explicit assignment in type is ignored in some cases r.dilz at tue dot nl
2020-03-19 11:46 ` [Bug fortran/94221] " rguenth at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).