This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/79191] potentially truncating unsigned conversion defeats range propagation
- From: "egallager at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 28 Aug 2017 20:12:29 +0000
- Subject: [Bug tree-optimization/79191] potentially truncating unsigned conversion defeats range propagation
- Auto-submitted: auto-generated
- References: <bug-79191-4@http.gcc.gnu.org/bugzilla/>
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