Simon Kagstrom <simon.kagstrom@xxxxxx> writes:
> Unfortunately there was no difference with -Wa,-O0. It does however
> look like the use of Linux-style syscalls break the
> -fno-delayed-branch behavior. I have code like
>
> #define _syscall1(type,name,atype,a) \
> type name(atype a) \
> { \
> register unsigned long __a0 asm("$4") = (unsigned long) a; \
> register unsigned long __v0 asm("$2"); \
> \
> __asm__ volatile ( \
> ".set\tnoreorder\n\t" \
> "li\t$2, %2\t\t\t# " #name "\n\t" \
> "syscall\n\t" \
> ".set\treorder" \
> : "=&r" (__v0) \
> : "r" (__a0), "i" (__NR_##name) \
> ); \
> \
> return (type) __v0; \
> }
> #define __NR_exit 0
> static inline _syscall1(void,exit , int, code );
>
> and with the call of exit(...), the delay slots are filled with
> instructions. If I just define a plain function and call that,
> -fno-delayed-branch seems to behave correctly.
I see. This is not a bug in the compiler. The ".set reorder"
directive tells the assembler that it should reorder instructions into
branch delay slots when possible. The compiler just copies the ".set
reorder" directly from the asm statement. Both the compiler and the
assembler are acting as expected.
You should rewrite your asm statement to not use .set reorder. Do this instead:
.set push
.set noreorder
...
.set pop
> Anyway, I've submitted a bug report at
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28325
I've closed out this bug report.
Ian
