[Bug tree-optimization/46316] [4.6 regression] incorrect loop optimization

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46316 Eric Botcazou changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

[Bug tree-optimization/46316] [4.6 regression] incorrect loop optimization

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46316 --- Comment #18 from davidxl 2010-11-09 07:22:43 UTC --- PR tree-optimization/46316? I will make the change. Thanks, David On Mon, Nov 8, 2010 at 11:01 PM, ebotcazou at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > http://gcc.gnu.org/

[Bug tree-optimization/46316] [4.6 regression] incorrect loop optimization

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46316 --- Comment #17 from Eric Botcazou 2010-11-09 07:01:26 UTC --- The PR reference in the ChangeLog is wrong so no cross-link to this audit trail has been generated. Please look at the numerous examples in the ChangeLog. The testcase should have b

[Bug tree-optimization/46316] [4.6 regression] incorrect loop optimization

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46316 --- Comment #16 from davidxl 2010-11-08 08:18:31 UTC --- The revised patch: Index: gcc/tree-vrp.c === --- gcc/tree-vrp.c(revision 166426) +++ gcc/tree-vrp.c(working copy) @

[Bug tree-optimization/46316] [4.6 regression] incorrect loop optimization

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46316 --- Comment #15 from davidxl 2010-11-08 07:38:17 UTC --- (In reply to comment #14) > Instead of multiplication followed by division, it would be faster to just use > mul_double_with_sign which returns whether there was an overflow or not. Good i

[Bug tree-optimization/46316] [4.6 regression] incorrect loop optimization

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46316 --- Comment #14 from Jakub Jelinek 2010-11-08 07:34:48 UTC --- Instead of multiplication followed by division, it would be faster to just use mul_double_with_sign which returns whether there was an overflow or not.

[Bug tree-optimization/46316] [4.6 regression] incorrect loop optimization

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46316 --- Comment #13 from davidxl 2010-11-08 07:13:03 UTC --- (In reply to comment #12) > Won't there be similar problem when using TImode IVs on 64-bit targets (e.g. > __int128 or int __attribute__((mode (TI ? > Normally overflows are detected wh

[Bug tree-optimization/46316] [4.6 regression] incorrect loop optimization

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46316 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #12

[Bug tree-optimization/46316] [4.6 regression] incorrect loop optimization

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46316 --- Comment #11 from Eric Botcazou 2010-11-08 00:53:17 UTC --- > For i686 target, the HOST_WIDE_INT is 'long int' -- not 'long long'. Yes, this is the default. By default we don't require a 64-bit type on the host for a 32-bit target, only for

[Bug tree-optimization/46316] [4.6 regression] incorrect loop optimization

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46316 --- Comment #10 from davidxl 2010-11-08 00:08:38 UTC --- Need define need_64bit_host_wide_int in configuration which is not done by default. David

[Bug tree-optimization/46316] [4.6 regression] incorrect loop optimization

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46316 --- Comment #9 from davidxl 2010-11-07 23:22:30 UTC --- For i686 target, the HOST_WIDE_INT is 'long int' -- not 'long long'. David

[Bug tree-optimization/46316] [4.6 regression] incorrect loop optimization

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46316 --- Comment #8 from Eric Botcazou 2010-11-07 21:32:12 UTC --- > Why double_int does not use the widest int type for low/high part on the host? Not clear what you mean; it uses HOST_WIDE_INT like the rest of the compiler.

[Bug tree-optimization/46316] [4.6 regression] incorrect loop optimization

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46316 davidxl changed: What|Removed |Added CC|davidxl at gcc dot gnu.org |xinliangli at gmail dot com --- Comment #7 from

[Bug tree-optimization/46316] [4.6 regression] incorrect loop optimization

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46316 Richard Guenther changed: What|Removed |Added Keywords||wrong-code Target Milestone|---

[Bug tree-optimization/46316] [4.6 regression] incorrect loop optimization

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46316 --- Comment #6 from Eric Botcazou 2010-11-06 10:05:21 UTC --- > It is very likely caused by revision 166280: > > http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg00166.html Indeed, this apparently exposed a bug in the scalar evolution analysis invoked

[Bug tree-optimization/46316] [4.6 regression] incorrect loop optimization

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46316 H.J. Lu changed: What|Removed |Added CC||davidxl at gcc dot gnu.org --- Comment #5 from

[Bug tree-optimization/46316] [4.6 regression] incorrect loop optimization

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46316 --- Comment #4 from H.J. Lu 2010-11-05 18:53:25 UTC --- Revision 166265 is OK.

[Bug tree-optimization/46316] [4.6 regression] incorrect loop optimization

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46316 --- Comment #3 from Eric Botcazou 2010-11-05 18:42:38 UTC --- > It only happens on 32bit host. It doesn't happen with -m32 > on Linux/x86-64. Ah, interesting, thanks. The wrong transformation is done by VRP2 but I fail to see which recent chang

[Bug tree-optimization/46316] [4.6 regression] incorrect loop optimization

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46316 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug tree-optimization/46316] [4.6 regression] incorrect loop optimization

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46316 --- Comment #1 from H.J. Lu 2010-11-05 18:12:25 UTC --- Please show command line passed to cc1.