https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65930
--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> --- On December 5, 2017 4:23:17 PM GMT+01:00, "sergey.shalnov at intel dot com" <gcc-bugzi...@gcc.gnu.org> wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65930 > >sergey.shalnov at intel dot com changed: > > What |Removed |Added >---------------------------------------------------------------------------- > CC| |sergey.shalnov at intel dot com > >--- Comment #4 from sergey.shalnov at intel dot com --- >Richard, >I can confirm that the issue exists and it can be solved by make data >types of >accumulator and equation equal. >As I can see you propose to introduce intermediate internal accumulator >in >uint32 type and store it into accumulator (int) later. Please correct >me if I'm >wrong. > >Anyway, may I, please, propose a bit simpler way to solve the issue? >In GIMPLE statement we have (in the place of reduction >tree-vect=loop.c:2877): >"sum_12 = (int) _6;" > >I believe the issue disappears if we change it to: >"sum_12 = _6;" > >I'm not sure but, if I remember correctly, the C standard treat these >types >(uint->int) casting as "undefined behavior". In this case, the compiler >can do >this type cast(it might be under some command line switches). > >What do you think, could it help? This is what the patch tries to do transparent in the vectorizer. Doing it generally isn't valid.