[SDCC 4.3.0][MCS51] bug adding int64_t constants using liblonglong

[Adrian Studer]

I think I ran into a bug in SDCC and/or liblonglong on 8051. When using the code below, the term ((int64_t)1)<<47 is treated like 0.

var2 = ((((int64_t)1) << 47) + var1);

The addition works as expected when storing the constant in a global variable memory:

int64_t _sh47 = ((int64_t)1) << 47;
func() {
   ...
    var2 = (_sh47 + var1);
    ...
}

The shift operation is where I ran into the issue, but I can reproduce the same (wrong) result when using 0x800000000000 instead.

[Philipp Klaus Krause]

Could this be related to [bugs:#3634]?

[Adrian Studer]

I don't think this issue is related to that bug for a few reasons:

1) the shift is using two constants (1<<47), so it should be evaluated by SDCC at compile time and not generate mcs51 code (which it doesn't)
2) the issue also happens when replacing the shift with the actual value (0x800000000000)
3) the shift works fine when assigning the result to a variable, instead of using it in the addition
4) the code around it has several int64_t shifts that worked as expected

For more context, this is the code that I ported to an 8051 MCU:
https://github.com/adafruit/Adafruit_BMP280_Library/blob/master/Adafruit_BMP280.cpp#L284
The problematic shift occurs in line 294

PS: As for #4: While the int64_t shifts worked as expected, they generate a LOT of mcs51 code. I saved several kilobytes of code space by replacing all shifts with calls to:

static int64_t _i64_shl(int64_t l, uint8_t s) {
  while (s > 0)
  {
    l <<= 1;
    s--;
  }
    return(l);
}

static int64_t _i64_shr(int64_t r, uint8_t s) {
  while (s > 0)
  {
    r >>= 1;
    s--;
  }
    return(r);
}

IMHO, SDCC should go that route when compiling with --opt-code-size.

[Maarten Brock]

This not related to [#3634].
Could you please open a bug report in the Bugs Ticket tracker?
And if you like you can also open a Feature Request for the proposed optimization.