This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: delay branch bug?


> int mytest ()
> {
>   int a[5];
>   int i;
>   for (i = 0; i < 5; i++)
>   {
>     a[i] = (int) getctrlIn();
>   }
>   switch (a[3])
>   {
>     case 0:
>         return 4;
>     default:
>         return 13;
>   }
> }
>
> The relevant bit of assembly for this compiled at -Os is
>
> _L2:
>         GET 0,R[5:4]    // R[5:4] := PORT(0)
> _picoMark_LBE5=
> _picoMark_LBE4=
>         .loc 1 13 0
>         STW R4,(R3)0            // Mem((R3)0{byte}) := R4
>         ADD.0 R3,2,R3   // R3 := R3 + 2 (HI)
>         .loc 1 11 0
>         SUB.0 R3,R2,r15 // CC := (R3!=R2)
>         BNE _L2
>         =->     LDW (FP)3,R5            // R5 = Mem((FP)6{byte})
>         .loc 1 22 0
>
> =-> is the delay slot marker. Note that the LDW instruction has been
> moved into the delay slot. This corresponds to the load in "switch
> (a[3]" statement above. The first 3 times around this loop, LDW would be
> loading uninitialised memory. The loaded value is ignored until we come
> out of the loop and hence the code is functionally correct, but i am not
> sure introduction of uninitialised memory access by the compiler when
> there was none in the source is good.

You'd need to define what "good" means here.  The generated code looks correct 
since (1) 'a' is on the stack and thus loading from it cannot trap (2) it is 
not marked volatile and (3) the result of the load is unused when the memory 
location is uninitialized.  So, from an external viewpoint, the generated 
code behaves as if there were no "problematic" loads and looks therefore OK.

-- 
Eric Botcazou


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]