public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/112459] New: gfortran -w option causes derived-type finalization at creation time
@ 2023-11-09 13:50 bardeau at iram dot fr
  2023-11-09 17:46 ` [Bug fortran/112459] " anlauf at gcc dot gnu.org
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: bardeau at iram dot fr @ 2023-11-09 13:50 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112459

            Bug ID: 112459
           Summary: gfortran -w option causes derived-type finalization at
                    creation time
           Product: gcc
           Version: 13.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bardeau at iram dot fr
  Target Milestone: ---

Hi everyone,

with gfortran version 13.2.0, the -w compilation switch modifies the code
behavior at execution time. This was not the case with e.g. gfortran 12.1.0.

~> gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/bardeau/Softs/gcc-13.2.0/libexec/gcc/x86_64-pc-linux-gnu/13.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../srcdir/configure --with-gmp=/home/bardeau/Softs/gcc-deps
--prefix=/home/bardeau/Softs/gcc-13.2.0 --enable-languages=c,c++,fortran
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.2.0 (GCC)

Code example:

module mymod
  type mysubtype
    integer(kind=4), allocatable :: a(:)
  end type mysubtype
  type :: mytype
    integer :: i
    type(mysubtype) :: sub
  contains
    final :: mytype_final
  end type mytype
contains
  subroutine mysubtype_final(sub)
    type(mysubtype), intent(inout) :: sub
    print *,'MYSUBTYPE>FINAL'
    if (allocated(sub%a)) deallocate(sub%a)
  end subroutine mysubtype_final
  subroutine mytype_final(typ)
    type(mytype), intent(inout) :: typ
    print *,"MYTYPE>FINAL"
    call mysubtype_final(typ%sub)
  end subroutine mytype_final
end module mymod
!
program myprog
  use mymod
  type(mytype), pointer :: c
  print *,"Before allocation"
  allocate(c)
  print *,"After allocation"
end program myprog

Compilation and execution:

~> gfortran -w test1.f90 -o test1 && ./test1
 Before allocation
 MYTYPE>FINAL
 MYSUBTYPE>FINAL
 After allocation

The problem is that the FINAL procedure (mytype_final) is invoked at the time
the c variable is allocated, which is unexpected. Plus, this behavior is
random. If the "sub" component is removed from "mytype", mytype_final is not
invoked anymore. I also have a much more complex example where the program
crashes because the evaluation "allocated(sub%a)" is incorrect and leads to
deallocation of the unallocated "sub%a". All these behaviors are correlated to
the presence of the -w option.

In order to be complete, I must say that the -w option is not described in
https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gfortran/Error-and-Warning-Options.html
but it is suggested in -fallow-argument-mismatch (documented here:
https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gfortran/Fortran-Dialect-Options.html
). In practice it can be used for example with:

subroutine test
  call foo()
  call foo(1)
end subroutine test

~> gfortran -c -fallow-argument-mismatch -w test2.f90

which shows no warning thanks to -w.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug fortran/112459] gfortran -w option causes derived-type finalization at creation time
  2023-11-09 13:50 [Bug fortran/112459] New: gfortran -w option causes derived-type finalization at creation time bardeau at iram dot fr
@ 2023-11-09 17:46 ` anlauf at gcc dot gnu.org
  2023-11-09 18:18 ` pault at gcc dot gnu.org
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: anlauf at gcc dot gnu.org @ 2023-11-09 17:46 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112459

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pault at gcc dot gnu.org

--- Comment #1 from anlauf at gcc dot gnu.org ---
When I compile the code with -std=f2008, I get:

pr112459.f90:28:13:

   28 |   allocate(c)
      |             1
Warning: The structure constructor at (1) has been finalized. This feature was
removed by f08/0011. Use -std=f2018 or -std=gnu to eliminate the finalization.

It behaves as you expect if I specify -std=gnu or -std=f2018.

Trying several combinations, it appears the following variants work:

-std=gnu
-std=f2018
-std=f2018 -w

and these "fail":

-w
-std=f2008
-std=f2008 -w
-std=gnu -w

Note that default is -std=gnu .

Now I wonder how -w interferes with -std=gnu ...

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug fortran/112459] gfortran -w option causes derived-type finalization at creation time
  2023-11-09 13:50 [Bug fortran/112459] New: gfortran -w option causes derived-type finalization at creation time bardeau at iram dot fr
  2023-11-09 17:46 ` [Bug fortran/112459] " anlauf at gcc dot gnu.org
@ 2023-11-09 18:18 ` pault at gcc dot gnu.org
  2023-11-11 10:17 ` pault at gcc dot gnu.org
  2023-12-16 13:59 ` cvs-commit at gcc dot gnu.org
  3 siblings, 0 replies; 5+ messages in thread
From: pault at gcc dot gnu.org @ 2023-11-09 18:18 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112459

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-11-09
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
             Blocks|                            |37336

--- Comment #2 from Paul Thomas <pault at gcc dot gnu.org> ---
It has been on my TODO list to partially revert the finalization of structure
and array constructors so that gfortran behaves like nagfor and only "knows"
about F2018. Finalization of constructors per se was removed in F2018 for very
good reasons!

I am still working on the CLASS variants of PR99065. Perhaps I should put that
on one side and clean up finalization?

@Sebastien - I will have to see what the -w switch does and why it should
affect the code behaviour. I can confirm the behaviour that you describe, as
Harald has already done. The F2003 and F2008 specific parts are blocked by:

if (!gfc_notification_std (GFC_STD_F2018_DEL) && .... Evidently switching off
the warnings with -w causes this to return true!

Cheers

Paul


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
[Bug 37336] [F03] Finish derived-type finalization

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug fortran/112459] gfortran -w option causes derived-type finalization at creation time
  2023-11-09 13:50 [Bug fortran/112459] New: gfortran -w option causes derived-type finalization at creation time bardeau at iram dot fr
  2023-11-09 17:46 ` [Bug fortran/112459] " anlauf at gcc dot gnu.org
  2023-11-09 18:18 ` pault at gcc dot gnu.org
@ 2023-11-11 10:17 ` pault at gcc dot gnu.org
  2023-12-16 13:59 ` cvs-commit at gcc dot gnu.org
  3 siblings, 0 replies; 5+ messages in thread
From: pault at gcc dot gnu.org @ 2023-11-11 10:17 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112459

--- Comment #3 from Paul Thomas <pault at gcc dot gnu.org> ---
Hi Sebastien,

I have posted the patch to the gfortran list. Hopefully, the bug will be fixed
this weekend.

Thanks for the report.

Paul

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug fortran/112459] gfortran -w option causes derived-type finalization at creation time
  2023-11-09 13:50 [Bug fortran/112459] New: gfortran -w option causes derived-type finalization at creation time bardeau at iram dot fr
                   ` (2 preceding siblings ...)
  2023-11-11 10:17 ` pault at gcc dot gnu.org
@ 2023-12-16 13:59 ` cvs-commit at gcc dot gnu.org
  3 siblings, 0 replies; 5+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-12-16 13:59 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112459

--- Comment #4 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Paul Thomas <pault@gcc.gnu.org>:

https://gcc.gnu.org/g:9a1105b770df9a9b485705398abbb74b5c487a25

commit r14-6621-g9a1105b770df9a9b485705398abbb74b5c487a25
Author: Paul Thomas <pault@gcc.gnu.org>
Date:   Sat Dec 16 13:59:45 2023 +0000

    Fortran: Prevent unwanted finalization with -w option [PR112459]

    2023-12-16  Paul Thomas  <pault@gcc.gnu.org>

    gcc/fortran
            PR fortran/112459
            * trans-array.cc (gfc_trans_array_constructor_value): Replace
            gfc_notification_std with explicit logical expression that
            selects F2003/2008 and excludes -std=default/gnu.
            * trans-expr.cc (gfc_conv_expr): Ditto.

    gcc/testsuite/
            PR fortran/112459
            * gfortran.dg/pr112459.f90: New test.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2023-12-16 13:59 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-11-09 13:50 [Bug fortran/112459] New: gfortran -w option causes derived-type finalization at creation time bardeau at iram dot fr
2023-11-09 17:46 ` [Bug fortran/112459] " anlauf at gcc dot gnu.org
2023-11-09 18:18 ` pault at gcc dot gnu.org
2023-11-11 10:17 ` pault at gcc dot gnu.org
2023-12-16 13:59 ` cvs-commit 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).