https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #31 from Robbert ---
[oops, that was meant to be private, please remove my last comment]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #12 from Robbert ---
(In reply to Richard Biener from comment #10)
> and see how this will make PTA useless (all pointers passed to a function
> whose result might be used in a way to take advantage of an equality relation
> need to b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #9 from Robbert ---
(In reply to Richard Biener from comment #6)
> which fixes the testcase (but is incomplete - equivalences built on
> gimple assignment RHS need to be considered as well).
Can you give an example?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #8 from Robbert ---
(In reply to Richard Biener from comment #7)
> Other testcase:
>
> int main()
> {
> int *p;
> int x = 0;
> if (p == &x)
>*p = 1;
> return x;
> }
>
> we optimize this to return 0. You probably wouldn'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #5 from Robbert ---
(In reply to Richard Biener from comment #4)
> as the address is not "live" after that.
Why doesn't gcc consider casting a pointer to an integer as making it "live"?
The concrete representation of address has escap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #3 from Robbert ---
(In reply to Robbert from comment #2)
> * Writing the representation of a chunk of memory containing pointers to
> memory.
"to memory" should be "to disk"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #2 from Robbert ---
This example may seem academic, but there is a real problem underneath.
Of course, I do agree that optimizations based on pointer origins are useful,
but it is not an "all or nothing situation". As long as repres
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at robbertkrebbers dot nl
The following program prints "0" instead of the expected "15":
#include
#include
#include
int main() {
int x = 0, *p = 0;
for (uintptr_t i = 0; ; i++) {
if (
: unassigned at gcc dot gnu.org
Reporter: gcc at robbertkrebbers dot nl
Consider the following example:
#include
#include
int main() {
int x = 1, y = 2, *p = &y, *q = &x + 1;
if ((intptr_t)p == (intptr_t)q) {
*q = 10;
printf("%d %d %d\n&q
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54945
--- Comment #12 from gcc at robbertkrebbers dot nl 2012-10-18 15:59:00 UTC ---
What do you mean by invalid? It is certainly not undefined behavior. The
pointer "&x + 1" is allowed by (6.5.6p8 of C11), and the equality operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54945
Bug #: 54945
Summary: Too strong non-aliasing analysis?
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Prior
11 matches
Mail list logo
