--- Comment #13 from dorit at gcc dot gnu dot org 2007-07-01 08:32 ---
Fix committed, PR can be closed.
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from dorit at gcc dot gnu dot org 2007-02-12 13:15 ---
Subject: Bug 29145
Author: dorit
Date: Mon Feb 12 13:14:52 2007
New Revision: 121844
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121844
Log:
PR tree-optimization/29145
* tree-data-ref.c
--- Comment #11 from dorit at il dot ibm dot com 2007-02-06 08:18 ---
(In reply to comment #10)
One thing I can think of that this description misses is that the two
pointers must be based-on *different* restrict-qualified pointers, unless
that case is already handled elsewhere.
--- Comment #10 from djg at cray dot com 2007-01-26 21:09 ---
(In reply to comment #8)
I'm testing this patch, that makes us more conservative, and concludes that
two
pointers don't overlap only if both are based on restricted pointers, with
based on trivially implemented as the
--- Comment #9 from patchapp at dberlin dot org 2007-01-09 09:35 ---
Subject: Bug number PR29145
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00648.html
--
--- Comment #8 from dorit at il dot ibm dot com 2007-01-07 20:22 ---
I'm testing this patch, that makes us more conservative, and concludes that two
pointers don't overlap only if both are based on restricted pointers, with
based on trivially implemented as the pointer used in the
--- Comment #6 from dorit at il dot ibm dot com 2006-11-05 15:48 ---
(In reply to comment #5)
This was something that slipped in, IIRC. I was of Ian's viewpoint, that
may_alias_p should handle it, and it shouldn't be special to data-references.
yes, it was originally added as a
--- Comment #7 from djg at cray dot com 2006-11-05 16:50 ---
(In reply to comment #5)
based on basically means copied from, and possibly incremented or
decremented, though not necessarily in obvious ways. Your example is
legal; q is based on p.
BTW, I made a mistake in my earlier
--- Comment #5 from dberlin at gcc dot gnu dot org 2006-11-04 04:15 ---
This was something that slipped in, IIRC. I was of Ian's viewpoint, that
may_alias_p should handle it, and it shouldn't be special to data-references.
But it can't, at least in it's current state, because it somehow
--- Comment #3 from ian at airs dot com 2006-11-02 16:07 ---
This looks like a compiler bug to me. The code in base_addr_differ_p seems
dubious anyhow: in principle,may_alias_p should handle restrict, it shouldn't
be handled by the caller.
It looks like this code has been there since
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-11-02 16:10 ---
Confirmed. (this is also why effective restrict is hard to do without better
PTA)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from djg at cray dot com 2006-09-20 23:49 ---
The definition of restrict in C99 6.7.3.1 doesn't say that only the original
restrict-qualified pointer can be used to access the object it points to; it
says that any pointer based on the original restrict-qualified pointer
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-19 16:43 ---
Actually restrict is weird and you might be violating one of the rules for
restrict, I always forget those rules and don't really understand them that
well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29145
13 matches
Mail list logo