wrong processing of uint64

[ricardomsmonteiro]

When manipulating uint64_t, variables declared in a class in a translation unit, the results of operations are wrong if there is an access to other same class variables.

3 files were used for the purpose of showing this in the same arduino sketch:
issue.ino:

#include "Arduino.h"
#include "tu.h"

#define ISSUE_HAPPENS

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

void loop()
{
  foo.baz = 2;

#if defined(ISSUE_HAPPENS)
  if( (foo.bar  & (1ULL << 9)) && (foo.bar  & (1ULL << 10)) )
    Serial.println("right");
  else
    Serial.println("wrong");
#else
  uint64_t a = 0x8000000010000602;
  uint64_t b = 0x8000000010000602;
  
  if( (a  & (1ULL << 9)) && (b  & (1ULL << 10)) )
    Serial.println("right");
  else
    Serial.println("wrong");
#endif
  
  delay(1000);
}

tu.cpp:

#include "tu.h"

Foo foo;

tu.h

#include <Arduino.h>

#pragma once

class Foo
{
public:
  uint64_t bar = 0x8000000010000602;

  uint8_t baz = 4;
};

extern Foo foo;

The output, when #define ISSUE_HAPPENS is uncommented, is wrong. When it is commented it is right as it is supposed to be.

This happens in arduino 1.8.8 but not in arduino 1.8.5. Using a different tool, sloeber arduino plugin for eclipse, it happens when the toolchain has gcc version 5.4.0 but not when it has the version 4.9.2.

[facchinm]

Hi @ricardomsmonteiro ,
thanks for the bug reporting. I just checked with toolchain 7.3.0 too and the bug is indeed still there (arduino/Arduino#7949 (comment)).
If the check is performed in 2 different steps

  if  (foo.bar  & (1ULL << 9)) {
    if (foo.bar  & (1ULL << 10))  {
      Serial.println("right");
    } else {
      Serial.println("wrong1");
    }
  }
  else {
    Serial.println("wrong2");
  }

the result is correct, so must check the produced assembly before filing a gcc bug.
Thanks you again for finding it!

[facchinm]

The disassembly shows that all the check is being stripped if both the shifted "immediate" are bigger than 8.
In fact, this works as expected and produces much more code.
if( (foo.bar & (1ULL << 1)) && (foo.bar & (1ULL << 12)) )
I'll investigate a little bit before reporting to gcc maintainers

[matthijskooijman]

Weird. I had a hard look over the code and did not find anything wrong in there, so I also suspect a compiler problem here.

[facchinm]

Replacing << 9 with << 1 gives this disassembly output diff:

d82:	20 91 0c 01 	lds	r18, 0x010C	; 0x80010c <foo>
 d86:	22 70       	andi	r18, 0x02	; 2
 d88:	30 91 0d 01 	lds	r19, 0x010D	; 0x80010d <foo+0x1>
 d8c:	30 71       	andi	r19, 0x10	; 16
 d8e:	40 e0       	ldi	r20, 0x00	; 0
 d90:	50 e0       	ldi	r21, 0x00	; 0
 d92:	60 e0       	ldi	r22, 0x00	; 0
 d94:	70 e0       	ldi	r23, 0x00	; 0
 d96:	80 e0       	ldi	r24, 0x00	; 0
 d98:	90 e0       	ldi	r25, 0x00	; 0
 d9a:	22 30       	cpi	r18, 0x02	; 2
 d9c:	30 41       	sbci	r19, 0x10	; 16
 d9e:	41 05       	cpc	r20, r1
 da0:	51 05       	cpc	r21, r1
 da2:	61 05       	cpc	r22, r1
 da4:	71 05       	cpc	r23, r1
 da6:	81 05       	cpc	r24, r1
 da8:	91 05       	cpc	r25, r1
 daa:	b1 f4       	brne	.+44     	; 0xdd8 <main+0x198>

(only in the correct execution).
It looks like the compiler is stripping a (const?) check it think is always false. I'll go ahead and produce a very minimal test case before reporting in mainline.

[Alexivia]

I have faced this same issue on a different situation. If using the Arduino 1.8.5 the OP code works as expected, i.e., no 64 bit operation error. However, if I change the code to if( (a & (1ULL << 32)) && (b & (1ULL << 62)) ) it breaks again, which means that on avr-gcc 4.9.2 the issue may manifest only if the operands larger than 1<<32

Are there any ongoing efforts to solve this?

[matthijskooijman]

The recently released 1.8.1 AVR core contains a newer gcc (7.something). Perhaps someone could test these cases with that compiler, see if this is still broken?