Is this a quirky compiler bug?

I’m using compiler v5.89 v5.92.

The following code is in use:

   if ( some_condition_or_other )
   {
      int  sizes[26];

      sizes[0] = main_window;
      sizes[3] = -1;
      sizes[4] = -1;
      __asm
      {
         MOV   R0, 11 // Read window size information
         MOV   R1, sizes
         SWI   (SWI_Wimp_Extend + XOS_Bit), {R0,R1}, {}, {PSR}
      } 
      debug("sizes: %d, %d, %d, %d, %d, %d...\n",
            sizes[0], sizes[1], sizes[2], sizes[3], sizes[4], sizes[5]);
      rborder = sizes[3];
      tborder = sizes[4];
      if ( rborder == -1 )
         rborder = 40; // actual value for this window read from my Pi
      if ( tborder == -1 )
         tborder = 40; // ditto

      // ...etc...
   }

What I’m doing is trying to get the sizes of certain parts of the window, specifically the size of the title bar and right scroll bar, in order to provide correction for window opening positions. I’m using -1 to detect cases where this call isn’t supported to push in a default value.

Problem is, this code returns:

sizes: 542164089, 0, 327, -1, -1, 454...

Now, the weird thing is that if I copy the debug call to do it twice in a row, then this happens:

sizes: 542170073, 2, 40, -1, -1, 38...
sizes: 542170073, 2, 40, 40, 40, 38...

Solutions? Several options.

• Insert dummy calls to read the data from the sizes[] array twice.
• Define sizes as int sizes[26] = { main_window, 0, 0, 0, 0, 0, 0, 0 /* etc */ } ;
• Define sizes as int volatile sizes[26]; to force it to be reread. This is the one I went with.
• Ditch any ideas of supporting RISC OS prior to 3.5 and assume that the SWI exists? ;)

Is this normal behaviour?
It seems as if old values from directly setting the values are stored in registers prior to the SWI call which need to be flushed somehow; as using the array in the SWI call doesn’t trigger this (perhaps the compiler treats “sizes” and “sizes[3]” as two different things and there’s no method of telling the compiler that the array itself has changed?

Hmm, just found the DDE archive on my phone, this machine is a few versions out of date.
Let me update the compiler and try again. Latest version, same behaviour.

PS: No comments about using inline assembler please. My DeskLib doesn’t have this call and I’ve not gotten around to adding it. Using inline assembler is, for me, the simplest way to do a SWI call when there’s no corresponding library function to use.

Not a bug. Compiler hasn’t been given a hint that the sizes array content has been modified, so sizes[3],[4] are legit the same values post-asm block as initialised with.

Myself I tend to put trivial asm blocks like this in inline functions; problem never arises.

Get the compiler to spit out assembler listing to see the actual code which has been generated.

Druck – the sort of messy stuff you’d expect from a compiler. I had to go back quite a way to spot where the MVN for -1 was… quite a way back actually.

0000F314 : .‘àã : E3E09000 : MVN     R9,#0
0000F318 : .‘¨å : E5A89008 : STR     R9,[R8,#8]!
0000F31C : ®..ë : EB0007AE : BL      &000111DC          ; call: grid_createcaret
0000F320 : .0 ã : E3A03000 : MOV     R3,#0
0000F324 : .0-å : E52D3004 : STR     R3,[R13,#-4]!      ; all of this guff is for sorting
0000F328 : 0’”í : ED959130 : LDFD    F1,[R5,#192]       ; out the size to send to SetExtent
0000F32C : Ŵ¡flí : ED9FA181 : LDFD    F2,&0000F538
0000F330 : .. ã : E3A01000 : MOV     R1,#0
0000F334 : ŵ1.î : EE113182 : MUFD    F3,F1,F2
0000F338 : s..î : EE100173 : FIXZ    R0,F3
0000F33C : .0ۉ : E2803002 : ADD     R3,R0,#2
0000F340 : ŷ.ŷà : E0860186 : ADD     R0,R6,R6,LSL #3
0000F344 : ..ۈ : E0800206 : ADD     R0,R0,R6,LSL #4
0000F348 : .. á : E1A00100 : MOV     R0,R0,LSL #2
0000F34C : (.ۉ : E2800028 : ADD     R0,R0,#&28         ; ="("
0000F350 : . `â : E2602000 : RSB     R2,R0,#0
0000F354 :  .ӌ : E5950020 : LDR     R0,[R5,#32]
0000F358 : `..ë : EB001660 : BL      &00014CE0          ; call: Window_SetExtent
0000F35C :  .ӌ : E5950020 : LDR     R0,[R5,#32]
0000F360 : .Йâ : E28DD004 : ADD     R13,R13,#4
0000F364 : .. á : E1A0100D : MOV     R1,R13
0000F368 : ...ë : EB001C7F : BL      &0001656C          ; Somewhere around here we should also
0000F36C : Ø..ë : EB001CD8 : BL      &000166D4          ; be calling GetWindowState, turning the
0000F370 :  ӌ : E59520AC : LDR     R2,[R5,#172]       ; Hourglass off, and setting a value TRUE.
0000F374 : .0 ã : E3A03001 : MOV     R3,#1              ; <--- which is probably this ;)
0000F378 : ¤0Ŷå : E58530A4 : STR     R3,[R5,#164]
0000F37C : ..Rã : E3520000 : CMP     R2,#0              ; Now we start the "if (something)" block
0000F380 : Ò... : 0A0000D2 : BEQ     &0000F6D0          ; skip over it if false
0000F384 : ´aflå : E59F61B4 : LDR     R6,&0000F540       ; otherwise here goes the above code
0000F388 : ..„å : E5961000 : LDR     R1,[R6,#0]
0000F38C :  0ӌ : E5953020 : LDR     R3,[R5,#32]
0000F390 : \‘-å : E52D905C : STR     R9,[R13,#-92]!
0000F394 : .0-å : E52D300C : STR     R3,[R13,#-12]!
0000F398 : €@Aâ : E2414080 : SUB     R4,R1,#&80         ; ="€"
0000F39C : .‘™å : E58D9010 : STR     R9,[R13,#16]
0000F3A0 : .. ã : E3A0000B : MOV     R0,#&0B            ; =11
0000F3A4 : .. á : E1A0100D : MOV     R1,R13
0000F3A8 : û..ï : EF0600FB : SWI     XWimp_Extend
0000F3AC : .0‡å : E59D3014 : LDR     R3,[R13,#20]
0000F3B0 : .  á : E1A02009 : MOV     R2,R9
0000F3B4 : .. á : E1A01009 : MOV     R1,R9
0000F3B8 : ..-é : E92D000E : STMDB   R13!,{R1-R3}
0000F3BC : .0™â : E28D300C : ADD     R3,R13,#&0C        ; =12
0000F3C0 : ..ݏ : E893000E : LDMIA   R3,{R1-R3}
0000F3C4 : ^.•â : E28F0F5E : ADR     R0,&0000F544       ; -> string: "%d, %d, %d, %d, %d, %d."
0000F3C8 : ­ãÿë : EBFFE3AD : BL      &00008284          ; call: debug
0000F3CC : .Йâ : E28DD00C : ADD     R13,R13,#&0C       ; =12
0000F3D0 : .€‡å : E59D800C : LDR     R8,[R13,#12]
0000F3D4 : .p‡å : E59D7010 : LDR     R7,[R13,#16]
0000F3D8 : ..xã : E3780001 : CMN     R8,#1
0000F3DC : (€ . : 03A08028 : MOVEQ   R8,#&28            ; ="("
0000F3E0 :  .ӌ : E5950020 : LDR     R0,[R5,#32]
0000F3E4 : ..wã : E3770001 : CMN     R7,#1
0000F3E8 : (p . : 03A07028 : MOVEQ   R7,#&28            ; ="("

If I omit the debug() call, then the compiler over-optimises to this…

0000F3A4 : û..ï : EF0600FB : SWI     XWimp_Extend
0000F3A8 : (‘ ã : E3A09028 : MOV     R9,#&28            ; ="("
0000F3AC : (p ã : E3A07028 : MOV     R7,#&28            ; ="("

;)

That’s what makes me wonder if there’s some sort of quirky bug at play here. I could understand if it decided that the value was -1 and just optimised to that which, as Stuart says, is the compiler not spotting that the values have changed… but differing behaviour on whether or not the value is printed out before it is used? Why…?

PS: No comments about using inline assembler please.

Except the irony here is if you’d just written

_swix(Wimp_Extend, _INR(0,1), 11, sizes);

it would have avoided the problem that for inline assembler the compiler has no clue why you’re passing sizes in R1 nor what side effects the SWI might have so is at liberty to have kept values in its head (unless you explicitly mark them volatile). A quick check here shows it compiles down to 3 instructions just the same as resorting to inline assembler.

A quick check here shows it compiles down to 3 instructions just the same as resorting to inline assembler.

It does now, now that the compiler has been extended to understand swix.
Previously, it was extremely hairy. ;)

(unless you explicitly mark them volatile)

That’s the solution I settled on.