On Tuesday 28 November 2006 15:12, Jan Beulich wrote:
> This fixes a problem with gcc4 mis-compiling the stack unwind code under
> -Os, which resulted in 'stuck' messages whenever an assembly routine was
> encountered.
>
> (The second hunk is trivial cleanup.)
Thanks for finally nailing that bug.
On Tue, Nov 28, 2006 at 02:48:15PM +, Jan Beulich wrote:
> 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
That's true, that sequence point makes sure e.g. all side effects such as
pre-{dec,inc}reme
>"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
On Tue, Nov 28, 2006 at 02:12:24PM +, Jan Beulich wrote:
> This fixes a problem with gcc4 mis-compiling the stack unwind code under
> -Os, which resulted in 'stuck' messages whenever an assembly routine was
> encountered.
"mis-compiling" and "work around" are wrong words, the code had undefine
This fixes a problem with gcc4 mis-compiling the stack unwind code under
-Os, which resulted in 'stuck' messages whenever an assembly routine was
encountered.
(The second hunk is trivial cleanup.)
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
--- linux-2.6.19-rc6/kernel/unwind.c2006-11-22 1
5 matches
Mail list logo