public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org> 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 [thread overview] Message-ID: <bug-58416-4-w8DMkcaVPX@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-58416-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416 --- Comment #3 from Uroš Bizjak <ubizjak at gmail dot com> --- (In reply to Richard Biener from comment #2) > where *movdf_internal simply doesn't properly preserve sNaN. > > 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 pattern > (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: <gcc-bugs-return-429905-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> 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: <gcc-bugs.gcc.gnu.org> List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/> List-Post: <mailto:gcc-bugs@gcc.gnu.org> List-Help: <mailto:gcc-bugs-help@gcc.gnu.org> 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" <gcc-bugzilla@gcc.gnu.org> 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: <bug-58434-4@http.gcc.gnu.org/bugzilla/> 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?idX434 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 =\x13501== Memcheck, a memory error detector =\x13501== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. =\x13501== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info =\x13501== Command: ./a.out =\x13501==\x13501==\x13501== HEAP SUMMARY: =\x13501== in use at exit: 40,000 bytes in 1 blocks =\x13501== total heap usage: 18 allocs, 17 frees, 43,688 bytes allocated =\x13501==\x13501== LEAK SUMMARY: =\x13501== definitely lost: 0 bytes in 0 blocks =\x13501== indirectly lost: 0 bytes in 0 blocks =\x13501== possibly lost: 0 bytes in 0 blocks =\x13501== still reachable: 40,000 bytes in 1 blocks =\x13501== suppressed: 0 bytes in 0 blocks =\x13501== Rerun with --leak-check=full to see details of leaked memory =\x13501==\x13501== For counts of detected and suppressed errors, rerun with: -v =\x13501== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2) gfortran-4.8.1 -g tmp.f90 valgrind ./a.out =\x13508== Memcheck, a memory error detector =\x13508== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. =\x13508== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info =\x13508== Command: ./a.out =\x13508==\x13508==\x13508== HEAP SUMMARY: =\x13508== in use at exit: 0 bytes in 0 blocks =\x13508== total heap usage: 18 allocs, 18 frees, 43,664 bytes allocated =\x13508==\x13508== All heap blocks were freed -- no leaks are possible =\x13508==\x13508== For counts of detected and suppressed errors, rerun with: -v =\x13508== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
next prev parent reply other threads:[~2013-09-16 13:21 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-09-13 19:56 [Bug target/58416] New: " stichnot at google dot com 2013-09-13 20:23 ` [Bug target/58416] " hjl.tools at gmail dot com 2013-09-16 10:28 ` rguenth at gcc dot gnu.org 2013-09-16 13:21 ` ubizjak at gmail dot com [this message] 2013-09-16 15:49 ` joseph at codesourcery dot com 2024-02-20 10:05 ` rguenth at gcc dot gnu.org 2024-02-20 10:07 ` rguenth at gcc dot gnu.org 2024-02-20 10:12 ` pinskia at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-58416-4-w8DMkcaVPX@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).