>"mis-compiling" and "work around" are wrong words, the code had undefined
>behavior (there is no sequence point between evaluation of ptr and
>get_uleb128(&ptr, end) and ptr is modified twice, so the compiler can
>evaluate it e.g. as:
>temp = ptr;
>temp = temp + get_uleb128(&ptr, end);
>ptr = temp;
>or
>temp = get_uleb128(&ptr, end);
>ptr += temp;
>While gcc has some warnings for sequence point semantics violations
>(-Wsequence-point), this can't be one of the cases at least until IPA moves
>much further, because get_uleb128 might very well not modify the variable
>and at that point the code would be ok).
I disagree - the standard says there's a sequence point at a function
call after evaluating all function arguments. To me this means that any
(parts of an) expression the function call is contained in must be
evaluated after the function call. Otherwise it would be illegal to e.g.
modify a variable in both operands of && or ||.
I consider my opinion supported by the fact that the problem doesn't
happen with any non-Os optimization, where it is obvious that it would
in all cases be beneficial to load the variable's value into a register early.
(And, btw., after the change the code generated is significantly smaller -
hinting at questionable effects of -Os.)
Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
