* [Bug fortran/53667] Cray pointer: Wrong result with optimizations
2012-06-14 7:05 [Bug fortran/53667] New: Cray pointer: Wrong result with optimizations burnus at gcc dot gnu.org
@ 2012-06-14 8:36 ` rguenth at gcc dot gnu.org
2012-06-14 9:07 ` [Bug middle-end/53667] " burnus at gcc dot gnu.org
` (8 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-06-14 8:36 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug middle-end/53667] Cray pointer: Wrong result with optimizations
2012-06-14 7:05 [Bug fortran/53667] New: Cray pointer: Wrong result with optimizations 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
2012-06-21 6:32 ` [Bug middle-end/53667] [4.6/4.7/4.8 Regression] " burnus at gcc dot gnu.org
` (7 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-06-14 9:07 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug middle-end/53667] [4.6/4.7/4.8 Regression] Cray pointer: Wrong result with optimizations
2012-06-14 7:05 [Bug fortran/53667] New: Cray pointer: Wrong result with optimizations 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 ` [Bug middle-end/53667] " burnus at gcc dot gnu.org
@ 2012-06-21 6:32 ` burnus at gcc dot gnu.org
2012-09-06 15:11 ` rguenth at gcc dot gnu.org
` (6 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-06-21 6:32 UTC (permalink / raw)
To: gcc-bugs
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.)
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug middle-end/53667] [4.6/4.7/4.8 Regression] Cray pointer: Wrong result with optimizations
2012-06-14 7:05 [Bug fortran/53667] New: Cray pointer: Wrong result with optimizations burnus at gcc dot gnu.org
` (2 preceding siblings ...)
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
` (5 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-09-06 15:11 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug middle-end/53667] [4.6/4.7/4.8 Regression] Cray pointer: Wrong result with optimizations
2012-06-14 7:05 [Bug fortran/53667] New: Cray pointer: Wrong result with optimizations burnus at gcc dot gnu.org
` (3 preceding siblings ...)
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
` (4 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-09-07 9:01 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug middle-end/53667] [4.6/4.7/4.8 Regression] Cray pointer: Wrong result with optimizations
2012-06-14 7:05 [Bug fortran/53667] New: Cray pointer: Wrong result with optimizations burnus at gcc dot gnu.org
` (4 preceding siblings ...)
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
` (3 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-09-07 9:39 UTC (permalink / raw)
To: gcc-bugs
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.)
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug middle-end/53667] [4.6/4.7/4.8 Regression] Cray pointer: Wrong result with optimizations
2012-06-14 7:05 [Bug fortran/53667] New: Cray pointer: Wrong result with optimizations burnus at gcc dot gnu.org
` (5 preceding siblings ...)
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
` (2 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-09-07 10:27 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug middle-end/53667] [4.6/4.7/4.8 Regression] Cray pointer: Wrong result with optimizations
2012-06-14 7:05 [Bug fortran/53667] New: Cray pointer: Wrong result with optimizations burnus at gcc dot gnu.org
` (6 preceding siblings ...)
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
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-09-07 10:30 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug middle-end/53667] [4.6 Regression] Cray pointer: Wrong result with optimizations
2012-06-14 7:05 [Bug fortran/53667] New: Cray pointer: Wrong result with optimizations burnus at gcc dot gnu.org
` (7 preceding siblings ...)
2012-09-07 10:30 ` rguenth at gcc dot gnu.org
@ 2012-09-07 10:32 ` rguenth at gcc dot gnu.org
2013-04-12 16:27 ` jakub at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-09-07 10:32 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug middle-end/53667] [4.6 Regression] Cray pointer: Wrong result with optimizations
2012-06-14 7:05 [Bug fortran/53667] New: Cray pointer: Wrong result with optimizations burnus at gcc dot gnu.org
` (8 preceding siblings ...)
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
9 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2013-04-12 16:27 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 11+ messages in thread