Activity for Adrian Studer
-
Adrian Studer modified a comment on discussion Help
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...
-
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 in 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...
-
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.
1