public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug rtl-optimization/61657] New: Undefined behavior in loop-iv.c
@ 2014-06-30 11:29 jakub at gcc dot gnu.org
  2014-09-28  9:07 ` [Bug rtl-optimization/61657] " trippels at gcc dot gnu.org
                   ` (10 more replies)
  0 siblings, 11 replies; 12+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-06-30 11:29 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 61657
           Summary: Undefined behavior in loop-iv.c
           Product: gcc
           Version: 4.10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
                CC: rakdver at gcc dot gnu.org, rguenth at gcc dot gnu.org

Seen during bootstrap-ubsan bootstrap/regtest.  E.g.
./cc1 -O3 -fomit-frame-pointer -funroll-loops gcc.c-torture/compile/pr42049.c
../../gcc/loop-iv.c:2626:14: runtime error: signed integer overflow:
9223372036854775806 - -9223372036854775808 cannot be represented in type 'long
int'
../../gcc/loop-iv.c:2288:24: runtime error: signed integer overflow:
9223372036854775807 - -9223372036854775808 cannot be represented in type 'long
int'
but seen also during the bootstrap itself.
E.g. on line 2626:
          inc = INTVAL (iv0.step) - INTVAL (iv1.step);
          if (CONST_INT_P (iv1.base))
            up = INTVAL (iv1.base);
          else
            up = INTVAL (mode_mmax) - inc;
          down = INTVAL (CONST_INT_P (iv0.base)
                         ? iv0.base
                         : mode_mmin);
          max = (up - down) / inc + 1;
inc is 1, both iv0.base and iv1.base are non-CONST_INT and thus up is
0x7ffffffffffffffeLL and down is 0x8000000000000000LL (-LONG_MIN).
The subtraction and division surely can be performed in UHWI, or perhaps
widest_int, just not sure what is the right thing if there is any overflow or
if max is negative in the end - shall we just not record the bound at all?


^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2015-08-21 16:51 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-06-30 11:29 [Bug rtl-optimization/61657] New: Undefined behavior in loop-iv.c jakub at gcc dot gnu.org
2014-09-28  9:07 ` [Bug rtl-optimization/61657] " trippels at gcc dot gnu.org
2014-09-28  9:09 ` trippels at gcc dot gnu.org
2014-09-28  9:09 ` trippels at gcc dot gnu.org
2015-07-21 18:44 ` zeccav at gmail dot com
2015-07-21 19:13 ` zeccav at gmail dot com
2015-08-21 11:17 ` zeccav at gmail dot com
2015-08-21 11:22 ` trippels at gcc dot gnu.org
2015-08-21 13:43 ` zeccav at gmail dot com
2015-08-21 13:51 ` trippels at gcc dot gnu.org
2015-08-21 16:45 ` trippels at gcc dot gnu.org
2015-08-21 16:51 ` trippels at gcc dot gnu.org

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).