Possible compiler bug when using -Os

[Lorandil]

Hi there,

I started playing with arduino-pico some days ago.
I think I just stumbled over a compiler bug...

To reproduce use the following code;

#include <Arduino.h>

class SimpleFIFO
{
public:
  SimpleFIFO() { head = 0; tail = 0; }
public:
  bool isEmpty() { return( head == tail ); }
  uint16_t head{};
  uint16_t tail{};
};

static SimpleFIFO fifo;

void setup() {
  delay( 5000 );
  Serial.begin( 115200 );
}

void loop() {
  Serial.print( F("isEmpty = ") ); Serial.println( fifo.isEmpty() );

  while( fifo.isEmpty() ); // -> while( true ) !!!
  // should *never* come here
  Serial.println( F("NO WAY ! ! !") );
}

Obviously the output should be

isEmpty = 1

But on my machine the output is (and of course repeating):

isEmpty = 1
NO WAY ! ! !

That problem haunted me until I used an Arduino Zero and suddenly everything worked as expected.
I could narrow down the problem to the '-Os' optimization setting.
The code works correct only with -O or -Og, all other options (-Os, -O2, -O3, -Ofast) produce broken code.

Any ideas?

Windows 11 64 bit
Arduino IDE 2.3.2
Raspberry Pi Pico/RP2040 by Earle F. Philhower, III v3.7.2

Stay safe,
Sven

[earlephilhower]

That's pretty neat (in a bad way) and seems like a GCC ARM-specific bug you might want to post on the GNU mailing list/bugzilla (GCC 12.3.0 is what we run).

If you use -Os or -O2 (via the menus) it fails but using -Og it passes and never prints NO WAY.

GDB shows the code in -Os doesn't even have a while loop included...

(gdb) disassemble loop
Dump of assembler code for function loop():
   0x10003210 <+0>:	push	{r4, lr}
   0x10003212 <+2>:	ldr	r4, [pc, #40]	@ (0x1000323c <loop()+44>)
   0x10003214 <+4>:	ldr	r1, [pc, #40]	@ (0x10003240 <loop()+48>)
   0x10003216 <+6>:	movs	r0, r4
   0x10003218 <+8>:	bl	0x10003658 <_ZN7arduino5Print5printEPKNS_19__FlashStringHelperE>
   0x1000321c <+12>:	ldr	r3, [pc, #36]	@ (0x10003244 <loop()+52>)
   0x1000321e <+14>:	movs	r2, #10
   0x10003220 <+16>:	ldrh	r1, [r3, #2]
   0x10003222 <+18>:	ldrh	r3, [r3, #0]
   0x10003224 <+20>:	movs	r0, r4
   0x10003226 <+22>:	subs	r1, r1, r3
   0x10003228 <+24>:	negs	r3, r1
   0x1000322a <+26>:	adcs	r1, r3
   0x1000322c <+28>:	bl	0x1000377a <_ZN7arduino5Print7printlnEii>
   0x10003230 <+32>:	movs	r0, r4
   0x10003232 <+34>:	ldr	r1, [pc, #20]	@ (0x10003248 <loop()+56>)
   0x10003234 <+36>:	bl	0x1000367c <_ZN7arduino5Print7printlnEPKNS_19__FlashStringHelperE>
   0x10003238 <+40>:	pop	{r4, pc}
   0x1000323a <+42>:	nop			@ (mov r8, r8)
   0x1000323c <+44>:	adds	r4, r5, r2
   0x1000323e <+46>:	movs	r0, #0
   0x10003240 <+48>:			@ <UNDEFINED> instruction: 0xf2d01000
   0x10003244 <+52>:	movs	r6, #12
   0x10003246 <+54>:	movs	r0, #0
   0x10003248 <+56>:			@ <UNDEFINED> instruction: 0xf2db1000
End of assembler dump.

While in -Og it does have the beq.n loop:

Dump of assembler code for function loop():
   0x10003230 <+0>:	push	{r4, lr}
   0x10003232 <+2>:	ldr	r1, [pc, #52]	@ (0x10003268 <loop()+56>)
   0x10003234 <+4>:	ldr	r4, [pc, #52]	@ (0x1000326c <loop()+60>)
   0x10003236 <+6>:	movs	r0, r4
   0x10003238 <+8>:	bl	0x10003770 <_ZN7arduino5Print5printEPKNS_19__FlashStringHelperE>
   0x1000323c <+12>:	ldr	r3, [pc, #48]	@ (0x10003270 <loop()+64>)
   0x1000323e <+14>:	ldrh	r2, [r3, #0]
   0x10003240 <+16>:	ldrh	r1, [r3, #2]
   0x10003242 <+18>:	subs	r1, r1, r2
   0x10003244 <+20>:	negs	r3, r1
   0x10003246 <+22>:	adcs	r1, r3
   0x10003248 <+24>:	uxtb	r1, r1
   0x1000324a <+26>:	movs	r2, #10
   0x1000324c <+28>:	movs	r0, r4
   0x1000324e <+30>:	bl	0x100038cc <_ZN7arduino5Print7printlnEii>
   0x10003252 <+34>:	ldr	r3, [pc, #28]	@ (0x10003270 <loop()+64>)
   0x10003254 <+36>:	ldrh	r2, [r3, #0]
   0x10003256 <+38>:	ldrh	r3, [r3, #2]
   0x10003258 <+40>:	cmp	r2, r3
   0x1000325a <+42>:	beq.n	0x10003252 <loop()+34>
   0x1000325c <+44>:	ldr	r1, [pc, #20]	@ (0x10003274 <loop()+68>)
   0x1000325e <+46>:	ldr	r0, [pc, #12]	@ (0x1000326c <loop()+60>)
   0x10003260 <+48>:	bl	0x10003794 <_ZN7arduino5Print7printlnEPKNS_19__FlashStringHelperE>
   0x10003264 <+52>:	pop	{r4, pc}
   0x10003266 <+54>:	nop			@ (mov r8, r8)
   0x10003268 <+56>:			@ <UNDEFINED> instruction: 0xfa901000
   0x1000326c <+60>:	adds	r4, r5, r2
   0x1000326e <+62>:	movs	r0, #0
   0x10003270 <+64>:	adds	r0, r7, r3
   0x10003272 <+66>:	movs	r0, #0
   0x10003274 <+68>:			@ <UNDEFINED> instruction: 0xfa9c1000
End of assembler dump.

[Lorandil]

Hi Earle, thanks for the quick analysis :)

I tried to create a gcc-bugzilla account, but it appears that account creation is restricted.
Would you mind posting the problem there?

Sven

[earlephilhower]

I don't have an account there, either, but did send an email to the address they tell you to. We'll see. I can repro this w/o Arduino at all using the bare compiler and objdump...

#include <stdio.h>
#include <stdint.h>

class SimpleFIFO
{
public:
  SimpleFIFO() { head = 0; tail = 0; }

public:
  bool isEmpty() { return( head == tail ); }

  uint16_t head{};
  uint16_t tail{};
};

static SimpleFIFO fifo;

int main(int argc, char **argv)
{

  printf("isEmpty = %d\n", fifo.isEmpty() );

  while( fifo.isEmpty() ); // -> while( true ) !!!

  // should *never* come here
  printf( "NO WAY ! ! !");
}

Running the arm compiler w/o any link or Arduino on the above and -Os gives no compare and loop

earle@amd:~/Arduino/hardware/pico/rp2040$ ./system/arm-none-eabi/bin/arm-none-eabi-objdump -d a.o

a.o:     file format elf32-littlearm


Disassembly of section .text.startup:

00000000 <main>:
   0:	b510      	push	{r4, lr}
   2:	4b07      	ldr	r3, [pc, #28]	@ (20 <main+0x20>)
   4:	4807      	ldr	r0, [pc, #28]	@ (24 <main+0x24>)
   6:	8859      	ldrh	r1, [r3, #2]
   8:	881b      	ldrh	r3, [r3, #0]
   a:	1ac9      	subs	r1, r1, r3
   c:	424b      	negs	r3, r1
   e:	4159      	adcs	r1, r3
  10:	f7ff fffe 	bl	0 <printf>
  14:	4804      	ldr	r0, [pc, #16]	@ (28 <main+0x28>)
  16:	f7ff fffe 	bl	0 <printf>
  1a:	2000      	movs	r0, #0
  1c:	bd10      	pop	{r4, pc}
  1e:	46c0      	nop			@ (mov r8, r8)
	...
  28:	0000000e 	.word	0x0000000e

0000002c <_GLOBAL__sub_I_main>:
  2c:	2200      	movs	r2, #0
  2e:	4b02      	ldr	r3, [pc, #8]	@ (38 <_GLOBAL__sub_I_main+0xc>)
  30:	801a      	strh	r2, [r3, #0]
  32:	805a      	strh	r2, [r3, #2]
  34:	4770      	bx	lr
  36:	46c0      	nop			@ (mov r8, r8)
  38:	00000000 	.word	0x00000000

Running w/-Og gives the expected loop

 ./system/arm-none-eabi/bin/arm-none-eabi-objdump -d a.o

a.o:     file format elf32-littlearm


Disassembly of section .text:

00000000 <_Z41__static_initialization_and_destruction_0ii>:
   0:	2801      	cmp	r0, #1
   2:	d000      	beq.n	6 <_Z41__static_initialization_and_destruction_0ii+0x6>
   4:	4770      	bx	lr
   6:	4b04      	ldr	r3, [pc, #16]	@ (18 <_Z41__static_initialization_and_destruction_0ii+0x18>)
   8:	4299      	cmp	r1, r3
   a:	d1fb      	bne.n	4 <_Z41__static_initialization_and_destruction_0ii+0x4>
   c:	4b03      	ldr	r3, [pc, #12]	@ (1c <_Z41__static_initialization_and_destruction_0ii+0x1c>)
   e:	2200      	movs	r2, #0
  10:	801a      	strh	r2, [r3, #0]
  12:	805a      	strh	r2, [r3, #2]
  14:	e7f6      	b.n	4 <_Z41__static_initialization_and_destruction_0ii+0x4>
  16:	46c0      	nop			@ (mov r8, r8)
  18:	0000ffff 	.word	0x0000ffff
  1c:	00000000 	.word	0x00000000

00000020 <main>:
  20:	b510      	push	{r4, lr}
  22:	4b0a      	ldr	r3, [pc, #40]	@ (4c <main+0x2c>)
  24:	881a      	ldrh	r2, [r3, #0]
  26:	8859      	ldrh	r1, [r3, #2]
  28:	1a89      	subs	r1, r1, r2
  2a:	424b      	negs	r3, r1
  2c:	4159      	adcs	r1, r3
  2e:	b2c9      	uxtb	r1, r1
  30:	4807      	ldr	r0, [pc, #28]	@ (50 <main+0x30>)
  32:	f7ff fffe 	bl	0 <printf>
  36:	4b05      	ldr	r3, [pc, #20]	@ (4c <main+0x2c>)
  38:	881a      	ldrh	r2, [r3, #0]
  3a:	885b      	ldrh	r3, [r3, #2]
  3c:	429a      	cmp	r2, r3
  3e:	d0fa      	beq.n	36 <main+0x16>
  40:	4804      	ldr	r0, [pc, #16]	@ (54 <main+0x34>)
  42:	f7ff fffe 	bl	0 <printf>
  46:	2000      	movs	r0, #0
  48:	bd10      	pop	{r4, pc}
  4a:	46c0      	nop			@ (mov r8, r8)
	...
  54:	00000010 	.word	0x00000010

00000058 <_GLOBAL__sub_I_main>:
  58:	b510      	push	{r4, lr}
  5a:	4902      	ldr	r1, [pc, #8]	@ (64 <_GLOBAL__sub_I_main+0xc>)
  5c:	2001      	movs	r0, #1
  5e:	f7ff ffcf 	bl	0 <_Z41__static_initialization_and_destruction_0ii>
  62:	bd10      	pop	{r4, pc}
  64:	0000ffff 	.word	0x0000ffff

[Lorandil]

Thank you again for your work (generalizing my code and mailing it to bugzilla).
I would have mailed to the bugzilla registration address myself today, but yesterday it was nearly midnight German time, so I was lacking the energy ;)

[earlephilhower]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114421

[earlephilhower]

Well, big old nothingburger. This trivial example is subject to a C++ undefined behavior (well, C++ is allowed to assume the while() given will terminate).

If you make the class variables volatile it should force G++ to leave in the check. A quick check confirms this...

[Lorandil]

Wow...

ok, so C11 says my code is undefined... I have to let that sink in...
I hope progammers of nuclear power plant controls or military systems have all read their ISO docs...
Nonetheless thanks once again for clarifying this issue, it is much appreciated!

Btw: Does arduino-pico has -fpermissive set?

[pinskia]

https://eel.is/c++draft/intro.progress#1