public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.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	[thread overview]
Message-ID: <bug-53667-4-jKtXqPflyt@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-53667-4@http.gcc.gnu.org/bugzilla/>

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53667

Tobias Burnus <burnus at gcc dot gnu.org> 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 <burnus at gcc dot gnu.org> 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)


  parent reply	other threads:[~2012-06-14  9:07 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-14  7:05 [Bug fortran/53667] New: " burnus at gcc dot gnu.org
2012-06-14  8:36 ` [Bug fortran/53667] " rguenth at gcc dot gnu.org
2012-06-14  9:07 ` burnus at gcc dot gnu.org [this message]
2012-06-21  6:32 ` [Bug middle-end/53667] [4.6/4.7/4.8 Regression] " burnus at gcc dot gnu.org
2012-09-06 15:11 ` rguenth at gcc dot gnu.org
2012-09-07  9:01 ` rguenth at gcc dot gnu.org
2012-09-07  9:39 ` burnus at gcc dot gnu.org
2012-09-07 10:27 ` rguenth at gcc dot gnu.org
2012-09-07 10:30 ` rguenth at gcc dot gnu.org
2012-09-07 10:32 ` [Bug middle-end/53667] [4.6 " rguenth at gcc dot gnu.org
2013-04-12 16:27 ` jakub 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-53667-4-jKtXqPflyt@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: link
Be 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).