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