From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13712 invoked by alias); 16 Sep 2013 13:21:33 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 13685 invoked by uid 48); 16 Sep 2013 13:21:30 -0000 From: "ubizjak at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/58416] Incorrect x87-based union copying code Date: Mon, 16 Sep 2013 13:21:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 4.6.3 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ubizjak at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-09/txt/msg01144.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D58416 --- Comment #3 from Uro=C5=A1 Bizjak --- (In reply to Richard Biener from comment #2) > where *movdf_internal simply doesn't properly preserve sNaN. >=20 > It looks wrong for DFmode move instructions to not preserve a IEEE defined > flag. I suppose it would be also wrong to not preserve the exact bit pat= tern > (think of canonicalizing NaNs). As said in PR57484, comment 11: On an x86 target using the legacy x87 instructions and the 80-bit registers= , a load of a 64-bit or 32-bit value in memory into the 80-bit registers counts= as a format conversion and an signaling NaN input will turn into a quiet NaN in the register format. >>From gcc-bugs-return-429905-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Sep 16 13:22:56 2013 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 14684 invoked by alias); 16 Sep 2013 13:22:56 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 14662 invoked by uid 48); 16 Sep 2013 13:22:52 -0000 From: "valeryweber at hotmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/58434] New: no automatic deallocation with trunk Date: Mon, 16 Sep 2013 13:22:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: valeryweber at hotmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-09/txt/msg01145.txt.bz2 Content-length: 2364 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58434 Bug ID: 58434 Summary: no automatic deallocation with trunk Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: valeryweber at hotmail dot com Dear All I noticed a changed of behavior between 4.8.1 and trunk. While the following code produde no memory leaks with 4.8.1 it does with the trunk. Is that a bug? v cat tmp.f90 module mod type t integer,allocatable,dimension(:)::i end type t end module mod program main use mod type(t) :: a allocate(a%i(10000)) end program main gfortran-trunk -g tmp.f90 valgrind ./a.out ==13501== Memcheck, a memory error detector ==13501== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==13501== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==13501== Command: ./a.out ==13501== ==13501== ==13501== HEAP SUMMARY: ==13501== in use at exit: 40,000 bytes in 1 blocks ==13501== total heap usage: 18 allocs, 17 frees, 43,688 bytes allocated ==13501== ==13501== LEAK SUMMARY: ==13501== definitely lost: 0 bytes in 0 blocks ==13501== indirectly lost: 0 bytes in 0 blocks ==13501== possibly lost: 0 bytes in 0 blocks ==13501== still reachable: 40,000 bytes in 1 blocks ==13501== suppressed: 0 bytes in 0 blocks ==13501== Rerun with --leak-check=full to see details of leaked memory ==13501== ==13501== For counts of detected and suppressed errors, rerun with: -v ==13501== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2) gfortran-4.8.1 -g tmp.f90 valgrind ./a.out ==13508== Memcheck, a memory error detector ==13508== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==13508== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==13508== Command: ./a.out ==13508== ==13508== ==13508== HEAP SUMMARY: ==13508== in use at exit: 0 bytes in 0 blocks ==13508== total heap usage: 18 allocs, 18 frees, 43,664 bytes allocated ==13508== ==13508== All heap blocks were freed -- no leaks are possible ==13508== ==13508== For counts of detected and suppressed errors, rerun with: -v ==13508== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)