Can't reproduce that with a cross.  The tree optimizers definitely don't optimize it into abort, and neither the assembly looks like what you are mentioning above.

On 20-Nov-12, at 7:06 AM, jakub at gcc dot gnu.org wrote:

> Can't reproduce that with a cross.  The tree optimizers definitely  
> don't
> optimize it into abort, and neither the assembly looks like what you  
> are
> mentioning above.

I'll recheck.  I definitely remember looking at the RTL from the  
expand pass.
That's why I marked it as a tree optimizer bug.

Dave
--
John David Anglin	dave.anglin@bell.net

Created attachment 28753 [details]
Tree dump

Created attachment 28754 [details]
Tree dump

Get the same with stage1 compiler.  Maybe this is a HWI32 issue?

Reproduced with
extern void abort (void);

__attribute__ ((noinline))
unsigned __int128
foo (__int128 ixi, unsigned ctr)
{
  unsigned __int128 irslt = 1;
  __int128 ix = ixi;

  for (; ctr; ctr--)
    {
      irslt *= ix;
      ix *= ix;
    }

  if (irslt != 14348907)
    abort ();
  return irslt;
}

int
main ()
{
  unsigned __int128 res;

  res = foo (3, 4);
  return 0;
}

on x86_64-linux at -O2, seems to be a VRP bug.

Caused by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190125

Created attachment 28755 [details]
gcc48-pr54471.patch

Untested fix.  I believe the bug is in invalid canonicalization.  When
sizem1 is { -1, -1 } double_int, sizem1 + double_int_one is { 0, 0 }, as it wrapped, instead of { 0, 0, 1, 0 } quad_int.  And if min0 or min1 is zero, then
size - min{0,1} is also zero, and so is very likely smaller than max{0,1} (unless min{0,1} == max{0,1}), but we still don't want to "canonicalize" that to signed.  IMHO testing min2.is_zero () is sufficient, as min0 or min1 should be a valid double_int in the range 0 to { -1, -1 }, which is always smaller than the maximum unsigned integer + 1 in infinite precision and thus min2 should never be zero, unless size overflowed to 0 and min{0,1} is zero.

Jakub, your patch makes sense to me (or min0.is_zero() and min1.is_zero()). I am ashamed I managed to get products with [0,n] (with n larger than MAX/2) wrong. Good thing Kenneth Zadeck's wide_int will soon allow us to remove most of this horrible code.

Another test that shows the error (optimizes away the call to g):

void g();
void h();
void f(unsigned __int128 x){
  if(x>(unsigned __int128)(-3))return;
  unsigned __int128 y=2*x;
  if(y==42) g();
  else h();
}

Thanks, I'm going to include your test too then:
--- gcc/testsuite/gcc.dg/tree-ssa/vrp86.c.jj	2012-11-21 18:27:53.389280736 +0100
+++ gcc/testsuite/gcc.dg/tree-ssa/vrp86.c	2012-11-21 18:27:47.000000000 +0100
@@ -0,0 +1,26 @@
+/* PR tree-optimization/54471 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-vrp1" } */
+
+#ifdef __SIZEOF_INT128__
+#define T __int128
+#else
+#define T long long
+#endif
+
+void fn1call ();
+void fn2call ();
+void f (unsigned T x)
+{
+  if (x > (unsigned T) -3)
+    return;
+  unsigned T y = 2 * x;
+  if (y == 42)
+    fn1call ();
+  else
+    fn2call ();
+}
+
+/* { dg-final { scan-tree-dump "fn1call" "vrp1"} } */
+/* { dg-final { scan-tree-dump "fn2call" "vrp1"} } */
+/* { dg-final { cleanup-tree-dump "vrp1" } } */

Author: jakub
Date: Mon Nov 26 09:19:30 2012
New Revision: 193806

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193806
Log:
	PR tree-optimization/54471
	* tree-vrp.c (extract_range_from_binary_expr_1): For MULT_EXPR,
	don't canonicalize range if min2 is zero.

	* gcc.dg/tree-ssa/vrp86.c: New test.
	* gcc.c-torture/execute/pr54471.c: New test.

Added:
    trunk/gcc/testsuite/gcc.c-torture/execute/pr54471.c
    trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp86.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-vrp.c

Fixed.