This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/65930] Reduction with sign-change not handled


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-bugzilla@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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]