From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) by sourceware.org (Postfix) with ESMTPS id 1ADF03858C83 for ; Wed, 26 Jan 2022 21:29:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1ADF03858C83 Received: by mail-qt1-x82e.google.com with SMTP id j12so592249qtr.2 for ; Wed, 26 Jan 2022 13:29:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=j7opuCZcrQ4GfQg0Qd4ZFt4w7mUskoBjPyn/fH9ECAk=; b=BcGqTCrl+ODmqUIzOfJU5ksBncr5tlASTcoBBSJaF8OJg/SWSBrHf12RzE6QXvp9+H dUHLyey8k3IZoaTNfaCidsmiu0ii61z9ycdCcf6dgKaXFx65M6TayZbIBGG9iinYsclO CgtU9YxVTh50135elaHzOv5hCiWfv4++pQOqEapKUgRKDwW8xOClt+tz0Vla7HhYOGwB BhVK3h10NqsbYTMrNDz3whWj8yfU9wuTMZhubHRzPunxbGrBuNP77kOWEtWJ/BhZFZMd 7VCt+9vApMGpMvXh+PPNgEOFy0sftU2aSnB9ROBlY6je+HGNYWwepYbcLEAi9ThVZ9he +BDQ== X-Gm-Message-State: AOAM532z37HQp/uTMrC1/empL3O1zXtmMo6QXclh6duZW9aL1XRapFQ4 fD1iloRJdX8eDQj/mRXAFaYXWMg3b5xCMw== X-Google-Smtp-Source: ABdhPJxqjne3nzrd/d/Ro5YX9S8YYRx4vUQhJkIXFOrt6rFJnGWCZ+NYj3QZto+C87rlMv8qiX90qA== X-Received: by 2002:a05:622a:50b:: with SMTP id l11mr574415qtx.24.1643232552936; Wed, 26 Jan 2022 13:29:12 -0800 (PST) Received: from ?IPV6:2601:6c5:8101:fd30::e1c6? ([2601:6c5:8101:fd30::e1c6]) by smtp.gmail.com with ESMTPSA id a16sm296925qtx.7.2022.01.26.13.29.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 26 Jan 2022 13:29:12 -0800 (PST) Message-ID: <6d037812-1395-3bf6-3de9-5ba331cdaf14@gmail.com> Date: Wed, 26 Jan 2022 13:29:09 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: FINAL subroutines Content-Language: en-US To: Salvatore Filippone , Andrew Benson Cc: Damian Rouson , Fortran List References: <4449972.oeqMtR4stF@abensonca-precision-7540> From: Jerry D In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, KAM_ASCII_DIVIDERS, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: fortran@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Fortran mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2022 21:29:16 -0000 Is there any reason these patches can not be applied and use this test as a test case? Regards, Jerry On 1/24/22 8:11 AM, Salvatore Filippone via Fortran wrote: > Thanks a lot > (yes, I suspected both gfortran and intel were wrong, precisely because I > could see why you'd need two FINAL calls, but not three). > > Salvatore > > On Mon, Jan 24, 2022 at 4:45 PM Andrew Benson > wrote: > >> Hi Salvatore, >> >> This looks like it's related to some of the missing finalization >> functionality >> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336). Paul has some >> patches >> (e.g. https://gcc.gnu.org/pipermail/fortran/2022-January/057415.html) >> which >> implement most of the missing functionality. With those patches >> incorporated >> your code gives the following output with gfortran: >> >> $ ./testfinal >> Allocating wrapper >> Calling new_outer_type >> Assigning outer%test_item >> Called delete_test_type >> End of new_outer_type >> DeAllocating wrapper >> Called delete_test_type >> >> So there is one more call to the finalizer than you found - I haven't >> checked >> carefully but I would guess this is a deallocation of LHS on assignment. >> >> In testing these patches using the Intel compiler we found that it seems >> to >> call the finalization wrapper more than it should, sometimes on objects >> that >> have already been deallocated. Your code, compiled with the Intel compiler >> and >> then run under valgrind shows the following: >> >> $ valgrind ./testfinal >> ==7340== Memcheck, a memory error detector >> ==7340== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. >> ==7340== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info >> ==7340== Command: ./testfinal >> ==7340== >> ==7340== Conditional jump or move depends on uninitialised value(s) >> ==7340== at 0x493A51: __intel_sse2_strcpy (in /home/abensonca/Scratch/ >> ifortTests/testfinal) >> ==7340== by 0x45D70E: for__add_to_lf_table (in /home/abensonca/Scratch/ >> ifortTests/testfinal) >> ==7340== by 0x4410CB: for__open_proc (in /home/abensonca/Scratch/ >> ifortTests/testfinal) >> ==7340== by 0x423A64: for__open_default (in /home/abensonca/Scratch/ >> ifortTests/testfinal) >> ==7340== by 0x4305A9: for_write_seq_lis (in /home/abensonca/Scratch/ >> ifortTests/testfinal) >> ==7340== by 0x4047E1: MAIN__ (testfinal.f90:62) >> ==7340== by 0x403CE1: main (in /home/abensonca/Scratch/ifortTests/ >> testfinal) >> ==7340== >> Allocating wrapper >> Calling new_outer_type >> Assigning outer%test_item >> Called delete_test_type >> ==7340== Conditional jump or move depends on uninitialised value(s) >> ==7340== at 0x40572A: do_alloc_copy (in >> /home/abensonca/Scratch/ifortTests/ >> testfinal) >> ==7340== by 0x406B9A: do_alloc_copy (in >> /home/abensonca/Scratch/ifortTests/ >> testfinal) >> ==7340== by 0x4084ED: for_alloc_assign_v2 (in /home/abensonca/Scratch/ >> ifortTests/testfinal) >> ==7340== by 0x404474: target_mod_mp_new_outer_type_ (testfinal.f90:48) >> ==7340== by 0x40485E: MAIN__ (testfinal.f90:65) >> ==7340== by 0x403CE1: main (in /home/abensonca/Scratch/ifortTests/ >> testfinal) >> ==7340== >> Called delete_test_type >> End of new_outer_type >> DeAllocating wrapper >> Called delete_test_type >> ==7340== >> ==7340== HEAP SUMMARY: >> ==7340== in use at exit: 48 bytes in 1 blocks >> ==7340== total heap usage: 14 allocs, 13 frees, 12,879 bytes allocated >> ==7340== >> ==7340== LEAK SUMMARY: >> ==7340== definitely lost: 48 bytes in 1 blocks >> ==7340== indirectly lost: 0 bytes in 0 blocks >> ==7340== possibly lost: 0 bytes in 0 blocks >> ==7340== still reachable: 0 bytes in 0 blocks >> ==7340== suppressed: 0 bytes in 0 blocks >> ==7340== Rerun with --leak-check=full to see details of leaked memory >> ==7340== >> ==7340== For counts of detected and suppressed errors, rerun with: -v >> ==7340== Use --track-origins=yes to see where uninitialised values come >> from >> ==7340== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0) >> >> so there are some cases of what look like incorrect accesses (and some >> leaked >> memory). >> >> Your code compiled with gfortran (with Paul's patches in place) shows no >> errors or leaks from valgrind. >> >> So, in summary, in this case I think the current gfortran is missing some >> finalizations (which are fixed by Paul's patches), and ifort is likely >> doing >> something wrong and probably calling the finalizer more times than it >> should. >> >> -Andrew >> >> On Monday, January 24, 2022 6:49:23 AM PST Salvatore Filippone via Fortran >> wrote: >>> And here is the code embedded as text............ sorry about sending an >>> attachment that was purged >>> ------------------------- testfinal.f90 --------------------- >>> module test_type_mod >>> >>> type :: my_test_type >>> integer, allocatable :: i >>> contains >>> final :: delete_test_type >>> end type my_test_type >>> >>> interface my_test_type >>> module procedure new_test_type_object >>> end interface my_test_type >>> >>> contains >>> >>> subroutine delete_test_type(this) >>> type(my_test_type) :: this >>> >>> write(*,*) 'Called delete_test_type' >>> if (allocated(this%i)) deallocate(this%i) >>> >>> end subroutine delete_test_type >>> >>> >>> function new_test_type_object(item) result(res) >>> type(my_test_type) :: res >>> integer, intent(in) :: item >>> !Allocation on assignment >>> res%i=item >>> end function new_test_type_object >>> >>> >>> end module test_type_mod >>> >>> module target_mod >>> use test_type_mod >>> type :: outer_type >>> type(my_test_type), allocatable :: test_item >>> end type outer_type >>> >>> contains >>> >>> subroutine new_outer_type(outer,item) >>> type(outer_type), intent(out) :: outer >>> integer :: item >>> >>> allocate(outer%test_item) >>> write(*,*) 'Assigning outer%test_item' >>> outer%test_item = my_test_type(itemi) >>> write(*,*) 'End of new_outer_type' >>> end subroutine new_outer_type >>> >>> end module target_mod >>> >>> program testfinal >>> use target_mod >>> >>> implicit none >>> >>> integer :: i=10 >>> type(outer_type), allocatable :: wrapper >>> >>> write(*,*) 'Allocating wrapper ' >>> allocate(wrapper) >>> write(*,*) 'Calling new_outer_type ' >>> call new_outer_type(wrapper,i) >>> write(*,*) 'DeAllocating wrapper ' >>> deallocate(wrapper) >>> >>> end program testfinal >>> >>> On Mon, Jan 24, 2022 at 2:50 PM Salvatore Filippone < >>> >>> filippone.salvatore@gmail.com> wrote: >>>> Hi all >>>> The attached code compiles and runs fine under both GNU and Intel, but >> it >>>> produces different results, in particular the FINAL subroutine is >> invoked >>>> just once with GNU, three times with Intel. >>>> >>>> It seems to me that they cannot both be right; I am not sure what the >>>> standard is mandating in this case. >>>> Any ideas? >>>> Salvatore >>>> --------------- Intel >>>> [pr1eio03@login1: newstuff]$ ifort -v >>>> ifort version 19.1.1.217 >>>> [pr1eio03@login1: newstuff]$ ifort -o testfinal testfinal.f90 >>>> [pr1eio03@login1: newstuff]$ ./testfinal >>>> >>>> Allocating wrapper >>>> Calling new_outer_type >>>> Assigning outer%test_item >>>> Called delete_test_type >>>> Called delete_test_type >>>> End of new_outer_type >>>> DeAllocating wrapper >>>> Called delete_test_type >>>> >>>> ----------------------------- GNU >>>> sfilippo@lagrange newstuff]$ gfortran -v >>>> Using built-in specs. >>>> COLLECT_GCC=gfortran >>>> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/11/lto-wrapper >>>> OFFLOAD_TARGET_NAMES=nvptx-none >>>> OFFLOAD_TARGET_DEFAULT=1 >>>> Target: x86_64-redhat-linux >>>> Configured with: ../configure --enable-bootstrap >>>> --enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto >> --prefix=/usr >>>> --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl= >>>> http://bugzilla.redhat.com/bugzilla --enable-shared >>>> --enable-threads=posix --enable-checking=release --enable-multilib >>>> --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions >>>> --enable-gnu-unique-object --enable-linker-build-id >>>> --with-gcc-major-version-only --with-linker-hash-style=gnu >> --enable-plugin >>>> --enable-initfini-array >>>> >> --with-isl=/builddir/build/BUILD/gcc-11.2.1-20210728/obj-x86_64-redhat-lin >>>> ux/isl-install --enable-offload-targets=nvptx-none >> --without-cuda-driver >>>> --enable-gnu-indirect-function --enable-cet --with-tune=generic >>>> --with-arch_32=i686 --build=x86_64-redhat-linux >>>> Thread model: posix >>>> Supported LTO compression algorithms: zlib zstd >>>> gcc version 11.2.1 20210728 (Red Hat 11.2.1-1) (GCC) >>>> [sfilippo@lagrange newstuff]$ gfortran -o testfinal testfinal.f90 >>>> [sfilippo@lagrange newstuff]$ ./testfinal >>>> >>>> Allocating wrapper >>>> Calling new_outer_type >>>> Assigning outer%test_item >>>> End of new_outer_type >>>> DeAllocating wrapper >>>> Called delete_test_type >>>> >>>> --------------------- >> >> -- >> >> * Andrew Benson: https://abensonca.github.io >> >> * Galacticus: https://github.com/galacticusorg/galacticus >> >> >> >>