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/65875] [5/6 Regression] ICE: Segmentation fault
Date: Mon, 27 Apr 2015 09:15:00 -0000	[thread overview]
Message-ID: <bug-65875-4-MFJV9QavDm@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-65875-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #3)
> Created attachment 35395 [details]
> gcc5-pr65875.patch
> 
> Untested fix.  IMHO vrp_visit_phi_node was missing the vr_result VR_VARING
> handling if the value range turned into varying only during
> update_value_range, and also update_value_range wasn't telling the caller if
> it changed it into varying late.
> 
> That said, the testcase has conditionally undefined variable, and checking
> whether all the VRP decisions (first and second pass) are sane, would be
> nice, Richard, could you please have a look?
> E.g. I find it strange that h has VR [0, LONG_MAX] before VRP2, when it
> really has just values 0 or 1, so should be ideally [0, 1].  Or that i has
> value range [1, LONG_MAX] - it is conditionally undefined (that is ignored),
> and conditionally negation of an int variable (only if that int variable is
> negative).  The negated int variable is [1, +INF(OVF)] because INT_MIN might
> overflow, perhaps if we really need to preserve the OVF flag, we have to use
> [1, +INF(OVF)] again rather than just [1, 0x7fffffff] :(.

For h we get into the loop PHI handling code which drops to INF-1 if it
iterates
"too much".  The rest probably ripples down from that.

I can't see where that [1, 0x7ffffff] issue happens.


  parent reply	other threads:[~2015-04-27  9:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-24 12:16 [Bug c/65875] New: internal compiler error with gcc 5.1 megahallon at gmail dot com
2015-04-24 12:29 ` [Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault trippels at gcc dot gnu.org
2015-04-24 16:37 ` jakub at gcc dot gnu.org
2015-04-27  9:15 ` rguenth at gcc dot gnu.org [this message]
2015-04-27 11:26 ` jakub at gcc dot gnu.org
2015-04-27 12:21 ` jakub at gcc dot gnu.org
2015-04-27 12:29 ` jakub at gcc dot gnu.org
2015-04-28  7:51 ` jakub at gcc dot gnu.org
2015-04-28  8:16 ` rguenther at suse dot de
2015-04-28  8:28 ` jakub at gcc dot gnu.org

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-65875-4-MFJV9QavDm@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).