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
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
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,
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
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
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*
