Guys,
Small sample below fails (at least on 6.1) for multiple targets. The
difference between two functions start at the very first tree pass...
Please confirm that I'm not crazy and it's not supposed to be like this...
Thanks
--
#include "limits.h"
#include "stdio.h"
int* __attribute__((noinl
On Sun, 11 Sep 2016, Igor Shevlyakov wrote:
Small sample below fails (at least on 6.1) for multiple targets. The
difference between two functions start at the very first tree pass...
You are missing -fsanitize=undefined (and #include ).
Please use the mailing list gcc-h...@gcc.gnu.org next ti
Well, my concern is not what happens with overflow (which in second
case -fsanitize=undefined will address), but rather consistency of
that 2 cases.
p[x+1] generates RTL which leads to better generated code at the
expense of leading to overflow, while p[1+x] never overflows but leads
to worse code
On Mon, 12 Sep 2016, Igor Shevlyakov wrote:
Well, my concern is not what happens with overflow (which in second
case -fsanitize=undefined will address), but rather consistency of
that 2 cases.
p[x+1] generates RTL which leads to better generated code at the
expense of leading to overflow, while
On 12/09/16 20:41, Igor Shevlyakov wrote:
> It would be beneficial to make the behaviour consistent between
> those 2 cases.
You've got two cases of undefined behaviour. What benefit
is there from making two cases of UB consistent with each other?
It's not worth the effort of changing the compil
On 2016-09-14 08:35:34 +0100, Andrew Haley wrote:
> On 12/09/16 20:41, Igor Shevlyakov wrote:
> > It would be beneficial to make the behaviour consistent between
> > those 2 cases.
>
> You've got two cases of undefined behaviour. What benefit
> is there from making two cases of UB consistent with