[Bug fortran/53667] New: Cray pointer: Wrong result with optimizations

[Bug fortran/53667] New: Cray pointer: Wrong result with optimizations

[burnus at gcc dot gnu.org]

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

             Bug #: 53667
           Summary: Cray pointer: Wrong result with optimizations
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: burnus@gcc.gnu.org


Cf. thread at http://gcc.gnu.org/ml/fortran/2012-06/msg00077.html

For the program at http://gcc.gnu.org/ml/fortran/2012-06/txt00004.txt, GCC
generates (original dump) the code:

  object_holder_init (&object_holder);
  set_vals (&object_holder);
  print_vals (&object_holder);

When using -O2, the latter becomes (optimized dump):

  object_holder_init (&object_holder);
  print_vals (&object_holder);
  object_holder ={v} {CLOBBER};


Both set_vals and print_vals contains code of the form:

  subroutine set_vals(oh)
    implicit none
    integer*8, intent(inout):: oh
    integer*8 :: obj(3)
    pointer(pobj, obj)

    pobj = oh

which translates into:

  set_vals (integer(kind=8) & restrict oh)
  {
    integer(kind=8) pobj;
    integer(kind=8) obj[3] [value-expr: *(integer(kind=8)[3] *) pobj];

    pobj = *oh;


If one marks "print_val"'s dummy argument "oh" as "target" (and, hence, removes
the "restrict"), GCC inlines "set_val" and the result is correct.

The program also works (at any optimization level) with
-fno-inline-small-functions. Or if all functions are inlined via
-fwhole-program.


It also works if one has a Cray-pointer dummy argument at:
  subroutine print_vals(pobj)
    integer*8 :: obj(3)
    pointer(pobj, obj)
    ...
    call free(pobj)

 * * *

Related issue: Currently, gfortran calls
    *oh = _gfortran_malloc (&C.1885);
    ...
    _gfortran_free ((integer(kind=8) *) oh);

(Cf. iresolve.c.) If one looks into libgfortran/intrinsics/malloc.c, it uses
the trivial implementation. But then a simple BUILT_IN_MALLOC / BUILT_IN_FREE
would do!

[Bug fortran/53667] Cray pointer: Wrong result with optimizations

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-06-14 08:36:33 UTC ---
Looks like undefined code to me.  The storage is not large enough.

[Bug middle-end/53667] Cray pointer: Wrong result with optimizations

[burnus at gcc dot gnu.org]

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)

[Bug middle-end/53667] [4.6/4.7/4.8 Regression] Cray pointer: Wrong result with optimizations

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.6.4
            Summary|Cray pointer: Wrong result  |[4.6/4.7/4.8 Regression]
                   |with optimizations          |Cray pointer: Wrong result
                   |                            |with optimizations

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-06-21 06:31:53 UTC ---
Mark as regression. (The regression is caused by the enabling of inlining due
to Fortran's -fwhole-file which became the default in 4.6.)

[Bug middle-end/53667] [4.6/4.7/4.8 Regression] Cray pointer: Wrong result with optimizations

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2012-09-06
         AssignedTo|unassigned at gcc dot       |rguenth at gcc dot gnu.org
                   |gnu.org                     |
     Ever Confirmed|0                           |1

--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-09-06 15:11:01 UTC ---
Confirmed.  Must be fortran issue, the equivalent C testcase works:

extern void abort (void);
typedef __SIZE_TYPE__ uintptr_t;
void foo (uintptr_t *u)
{
  static int i;
  *u = (uintptr_t) &i;
}
void bar (uintptr_t *u)
{
  if (*(int *)*u != 1)
    abort ();
}
int main ()
{
  uintptr_t mem;
  foo (&mem);
  *(int *)mem = 1;
  bar (&mem);
  return 0;
}

in particular the call to foo makes mem point to NONLOCAL as can be seen
from the ealias dump:

  foo (&mem);
  mem.0_1 = mem;
  # PT = nonlocal escaped
  mem.1_2 = (int *) mem.0_1;

while for the fortran case I see

  object_holder_init (&object_holder);
  pobj_1 = object_holder;
  # PT =
  pobj.4_2 = (integer(kind=8)[3] *) pobj_1;
  *pobj.4_2[0] = 900;

so object_holder points to nothing.  If I remove the implementations
of object_hoder_init and print_vals then the alias info is correct.
Thus, some attribute on object_holder_init confuses points-to analysis.
I see it has ".w" fnspec, so that must be where the bug lies (nothing
is wrong in specifying ".w" here).

Mine.

[Bug middle-end/53667] [4.6/4.7/4.8 Regression] Cray pointer: Wrong result with optimizations

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-09-07 09:01:10 UTC ---
Ok, so fixing this will pessimize gfortran.dg/c_ptr_tests_16.f90 as

  print '(z8)', a

will now clobber a even though we have

  _gfortran_transfer_integer_write (&dt_parm.1, &a, 8);

marked with ".wR" (that is, &a is specified as to not escape and not be
clobbered).  Still, as &dt_parm.1 is clobbered it possibly gets assigned
&a and by means of being clobbered it will clobber &a ...

Not sure if we can restrict non-escaping to also not escape to other
parameters?  Possibly we should, otherwise this property won't be very
useful.

[Bug middle-end/53667] [4.6/4.7/4.8 Regression] Cray pointer: Wrong result with optimizations

[burnus at gcc dot gnu.org]

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

--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-09-07 09:38:56 UTC ---
(In reply to comment #5)
> Not sure if we can restrict non-escaping to also not escape to other
> parameters?  Possibly we should, otherwise this property won't be very
> useful.

I think that's also what the current setting in Fortran's trans-types.c's
create_fn_spec does: It also sets "." instead of "r" or "w" for TARGET as the
pointer address of those can escape via the argument or otherwise. If an
argument is neither TARGET nor POINTER, I don't see a way how a pointer can
escape.

Thus, I think that interpretation makes sense from the Fortran side. (I haven't
audited the fn spec for the libgfortran functions, but I think for those the
same applies.)

[Bug middle-end/53667] [4.6/4.7/4.8 Regression] Cray pointer: Wrong result with optimizations

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-09-07 10:27:07 UTC ---
Author: rguenth
Date: Fri Sep  7 10:27:02 2012
New Revision: 191064

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191064
Log:
2012-09-07  Richard Guenther  <rguenther@suse.de>

    PR middle-end/53667
    * tree-ssa-structalias.c (handle_rhs_call): Properly clobber
    EAF_NOESCAPED arguments.  Transitively close non-EAF_DIRECT
    arguments separately.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-ssa-structalias.c

[Bug middle-end/53667] [4.6/4.7/4.8 Regression] Cray pointer: Wrong result with optimizations

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-09-07 10:30:00 UTC ---
Author: rguenth
Date: Fri Sep  7 10:29:56 2012
New Revision: 191065

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191065
Log:
2012-09-07  Richard Guenther  <rguenther@suse.de>

    PR middle-end/53667
    * tree-ssa-structalias.c (handle_rhs_call): Properly clobber
    EAF_NOESCAPED arguments.  Transitively close non-EAF_DIRECT
    arguments separately.

Modified:
    branches/gcc-4_7-branch/gcc/ChangeLog
    branches/gcc-4_7-branch/gcc/tree-ssa-structalias.c

[Bug middle-end/53667] [4.6 Regression] Cray pointer: Wrong result with optimizations

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |4.7.2, 4.8.0
            Summary|[4.6/4.7/4.8 Regression]    |[4.6 Regression] Cray
                   |Cray pointer: Wrong result  |pointer: Wrong result with
                   |with optimizations          |optimizations

--- Comment #9 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-09-07 10:32:04 UTC ---
Fixed for 4.7/4.8 sofar, latent on the 4.6 branch but more difficult to
backport.

[Bug middle-end/53667] [4.6 Regression] Cray pointer: Wrong result with optimizations

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|4.6.4                       |4.7.2

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-04-12 16:27:39 UTC ---
The 4.6 branch has been closed, fixed in GCC 4.7.2.