--- 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=gcc&view=rev&rev=121844
Log:
PR tree-optimization/29145
* tree-data-ref.c (ba
--- 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
--- 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
--
http://gcc.gnu.org/bugzilla/sh
--- 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 re
--- 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 sug
--- 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 temp
--- 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 #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 #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 t
--- 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
