public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/65752] Too strong optimizations int -> pointer casts
Date: Fri, 22 May 2015 08:52:00 -0000	[thread overview]
Message-ID: <bug-65752-4-RcBV8U5a4I@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-65752-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at gcc dot gnu.org

--- Comment #32 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Chung-Kil Hur from comment #29)
> Dear Richard,
> 
> This time, I think I constructed a real bug.
> Please have a look and correct me if I am wrong.
> 
> =====================
> #include <stdio.h>
> 
> int main() {
>   int x = 0;
>   uintptr_t xp = (uintptr_t) &x;
>   uintptr_t i;
> 
>   for (i = 0; i < xp; i++) { }
> 
>   *(int*)xp = 15;
> 
>   printf("%d\n", x);
> }
> =====================
> 
> This program prints "15" and I do not think this raises UB.
> 
> Now I add an if-statement to the program.
> 
> =====================
> #include <stdio.h>
> 
> int main() {
>   int x = 0;
>   uintptr_t xp = (uintptr_t) &x;
>   uintptr_t i;
> 
>   for (i = 0; i < xp; i++) { }
> 
>   /*** begin ***/
>   if (xp != i) {
>     printf("hello\n");
>     xp = i;
>   }
>   /*** end ***/
> 
>   *(int*)xp = 15;
> 
>   printf("%d\n", x);
> }
> =====================
> 
> This program just prints "0".
> 
> Since "hello" is not printed, the if-statement is not executed.
> However, it prints a different result than before, which I think is a bug.

It indeed is a more unfortunate case but you are still breaking the dependency
chain in the if (xp != i) code by assigning i to xp.  The code is never
executed (which is why this is unfortunate) and I am less than 100% sure
it still invokes undefined behavior.

The unfortunate thing is that the equivalence you build on the 'else'
path (xp == i) is used by the compiler to replace xp by i on the
*(int*)xp = 15 line getting us into the very same situation as in all
other cases.  That is, we have

  if (xp != i)
...
  # xp = PHI <xp, i>
  *(int *)xp = 15;

because of the conditional and in this case our phiopt pass optimizes that
to

  # xp = PHI <i, i>

instead of the equally valid

  # xp = PHI <xp, xp>

other passes (dom) may end up doing a similar thing (at least for GCC 5 and
the particular testcase we are lucky here though), but for GCC 5
-fdisable-tree-phiopt1 -fdisable-tree-phiopt2 avoids the issue.

Generally there is no good way to determine which choice is better.

What the PTA code does is sensible btw.  For

  # xp_20 = PHI <0(2), xp_7(7)>
  xp_7 = xp_20 + 1;
  if (xp_6 > xp_7)
    goto <bb 7>;
  else
    goto <bb 4>;

  <bb 7>:
  goto <bb 3>;

the PTA constraints are

xp_6 = &x
xp_20 = &NULL
xp_20 = xp_7
xp_7 = xp_20
xp_7 = &NONLOCAL

which means PTA considers that all pointers coming from integer constants
point to global memory only (that's to support fixed address objects).
That helps to avoid false aliasing to stack objects and avoids the need
to make all locals escaped when you have code passing an integer to a
function (that integer, converted to a pointer _could_ point to a stack
slot in the caller, no?!).

So 'i' is considered to eventually point to arbitrary global memory.
But _not_ to arbitrary address-taken locals.


  parent reply	other threads:[~2015-05-22  8:52 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-13 14:04 [Bug c/65752] New: " gcc at robbertkrebbers dot nl
2015-04-13 17:38 ` [Bug c/65752] " joseph at codesourcery dot com
2015-04-13 23:25 ` gcc at robbertkrebbers dot nl
2015-04-13 23:25 ` gcc at robbertkrebbers dot nl
2015-04-14  8:39 ` rguenth at gcc dot gnu.org
2015-04-14  8:46 ` gcc at robbertkrebbers dot nl
2015-04-14  9:01 ` rguenth at gcc dot gnu.org
2015-04-14  9:06 ` rguenth at gcc dot gnu.org
2015-04-14  9:23 ` gcc at robbertkrebbers dot nl
2015-04-14  9:26 ` gcc at robbertkrebbers dot nl
2015-04-14 10:50 ` rguenth at gcc dot gnu.org
2015-04-20 13:45 ` [Bug tree-optimization/65752] " mpolacek at gcc dot gnu.org
2015-04-20 13:53 ` gcc at robbertkrebbers dot nl
2015-05-18 17:13 ` gil.hur at sf dot snu.ac.kr
2015-05-19  9:21 ` rguenth at gcc dot gnu.org
2015-05-19 12:08 ` gil.hur at sf dot snu.ac.kr
2015-05-19 12:33 ` rguenth at gcc dot gnu.org
2015-05-19 13:14 ` gil.hur at sf dot snu.ac.kr
2015-05-19 14:21 ` rguenther at suse dot de
2015-05-19 14:29 ` gil.hur at sf dot snu.ac.kr
2015-05-19 14:32 ` mpolacek at gcc dot gnu.org
2015-05-19 15:12 ` gil.hur at sf dot snu.ac.kr
2015-05-19 15:23   ` Andreas Schwab
2015-05-19 15:23 ` schwab at suse dot de
2015-05-19 15:29 ` gil.hur at sf dot snu.ac.kr
2015-05-20  8:01 ` rguenth at gcc dot gnu.org
2015-05-20 10:55 ` gil.hur at sf dot snu.ac.kr
2015-05-20 11:20 ` gil.hur at sf dot snu.ac.kr
2015-05-20 11:33 ` rguenther at suse dot de
2015-05-22  4:55 ` mail at robbertkrebbers dot nl
2015-05-22  4:57 ` gcc at robbertkrebbers dot nl
2015-05-22  8:52 ` rguenth at gcc dot gnu.org [this message]
2015-05-23  8:14 ` gil.hur at sf dot snu.ac.kr
2015-05-26 11:26 ` rguenther at suse dot de
2015-05-26 13:55 ` gil.hur at sf dot snu.ac.kr
2015-05-26 14:00 ` rguenther at suse dot de
2015-05-26 14:06 ` gil.hur at sf dot snu.ac.kr
2020-08-04 21:31 ` tavianator at gmail dot com
2020-08-05  7:07 ` rguenther at suse dot de

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-65752-4-RcBV8U5a4I@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).