[Bug tree-optimization/79191] potentially truncating unsigned conversion defeats range propagation

[egallager at gcc dot gnu.org]

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

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2017-08-28
                 CC|                            |egallager at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #2 from Eric Gallager <egallager at gcc dot gnu.org> ---
Looks like h is optimized the same as g when compiling for 32-bits:

$ /usr/local/bin/gcc -c -O2 -S -Wall -fdump-tree-optimized=/dev/stdout -Wextra
-pedantic -Wconversion 79191.c

;; Function f (f, funcdef_no=0, decl_uid=1769, cgraph_uid=0, symbol_order=0)

f (long unsigned int n)
{
  <bb 2> [100.00%] [count: INV]:
  if (n_1(D) > 3)
    goto <bb 3>; [0.04%] [count: 0]
  else
    goto <bb 4>; [99.96%] [count: INV]

  <bb 3> [0.04%] [count: 0]:
  __builtin_abort ();

  <bb 4> [99.96%] [count: INV]:
  return;

}



;; Function g (g, funcdef_no=1, decl_uid=1772, cgraph_uid=1, symbol_order=1)

g (unsigned int n)
{
  <bb 2> [100.00%] [count: INV]:
  return;

}



;; Function h (h, funcdef_no=4, decl_uid=1775, cgraph_uid=2, symbol_order=2)

h (long unsigned int m)
{
  <bb 2> [100.00%] [count: INV]:
  return;

}


$

When I add an explicit "-m64" to the compile command I get the same results as
you, though. Also, it'd be nice if there were a warning from -Wconversion for
the assignment from m to n in h. Or a warning from -Wimplicit-int for uses of
bare "unsigned" without the "int" in general (I've actually been meaning to
file a separate bug for that, but haven't gotten around to it yet).

Anyways, confirming for LP64