On Thu, Jan 19, 2017 at 10:38 AM, Bob Rorschach <rfr@xxxxxxxxx> wrote:
[...]
> long ov = ((long)(1)) << ((iv & 0x3f) + 1);
> if (ov == 1)
> ov = 0;
[...]
> for(i=60;i<65;i++)
> printf("%d=>0x%lx\n",i&63,badexample(i&63));
[...]
> The "if (ov==1)..." test is failing when the compilation is optimized,
> but not when compiled without optimization, as shown below.
> The 63=>0x1 line should be 63=>0x0.
[...]
> code below. The shift argument is 64, which acts like an argument of
> 0 on the 64-bit x86, but the test is only looking for a shift
Last time I checked in C, as well as in C++, standards -- shifting by
the number of bits greater *or equal* to the size of the type is
undefined behavior...
e.g. something like "An expression is shifted by a negative number or
by an amount greater than or equal to the width of the promoted
expression (6.5.7)." from
https://www.securecoding.cert.org/confluence/display/c/CC.+Undefined+Behavior#CC.UndefinedBehavior-ub_51
The exact place in C++14 and or latest C standards escape me right
now, but the thesis of this UB stands correct I think...
what is sizeof(long) on your target?
