From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28416 invoked by alias); 14 Jun 2012 09:07:43 -0000 Received: (qmail 28392 invoked by uid 22791); 14 Jun 2012 09:07:41 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 14 Jun 2012 09:07:28 +0000 From: "burnus at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/53667] Cray pointer: Wrong result with optimizations Date: Thu, 14 Jun 2012 09:07:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: burnus at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Status CC Component Resolution Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 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 X-SW-Source: 2012-06/txt/msg00880.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53667 Tobias Burnus changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED CC| |burnus at gcc dot gnu.org Component|fortran |middle-end Resolution|INVALID | --- Comment #2 from Tobias Burnus 2012-06-14 09:07:25 UTC --- (In reply to comment #1) > Looks like undefined code to me. The storage is not large enough. I disagree: "oh" is 64 bits which should be enough to store a pointer - as is the Cray pointer "pobj". And "obj", the Cray pointee, is with 3*8 bytes large enough to store three 8-byte values. My guess had been that the ME should be able to see that the assignments modify "object_holder" - thus I assigned the PR to the middle-end. Note: As Cray pointers are a (Fortran 77) vendor extension, there is no specification. Thus, it is impossible to tell whether the code is valid or not. Additionally, "TARGET" (which removes the "restrict") does not exist in Fortran 77. The program successfully runs with ifort, openf95, pathf95, but it fails with PGI and Cray at the "print" line (illegal instruction) - even without optimization. Thus, if it is not trivially fixable, one can really consider to close it as WONTFIX. [Or to apply in the Fortran FE as mitigating bugfix something like http://gcc.gnu.org/ml/fortran/2012-06/msg00082.html, which marks the integer variables as TARGET in the most common cases. One should probably additionally handle "oh = malloc(...)" and "free(oh)".] The same issue also occurs with -O1 if one replaces the main program by manually inlining "set_vals": integer*8 :: object_holder integer*8 :: obj(3) pointer(pobj, obj) call object_holder_init(object_holder) pobj = object_holder obj(1) = 900 obj(2) = 800 obj(3) = 700 call print_vals(object_holder)