Clang incorrectly optimizes this negation with -O2 and causes QBE to
emit 0 in place of INT64_MIN.
---
 arm64/isel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arm64/isel.c b/arm64/isel.c
index 062beb3..9ce6adc 100644
--- a/arm64/isel.c
+++ b/arm64/isel.c
@@ -24,7 +24,7 @@ imm(Con *c, int k, int64_t *pn)
 	i = Iplo12;
 	if (n < 0) {
 		i = Inlo12;
-		n = -n;
+		n = -(uint64_t)n;
 	}
 	*pn = n;
 	if ((n & 0x000fff) == n)
-- 
2.46.0

On Fri, Aug 02, 2024 at 02:39:07PM +0300, Alexey Yerin wrote:
> Clang incorrectly optimizes this negation with -O2 and causes QBE to

sorry, but what does clang have to do with QBE? :D

On Fri Aug 2, 2024 at 14:22 +0200, Lorenz (xha) wrote:
> On Fri, Aug 02, 2024 at 02:39:07PM +0300, Alexey Yerin wrote:
> > Clang incorrectly optimizes this negation with -O2 and causes QBE to
>
> sorry, but what does clang have to do with QBE? :D

If QBE is compiled with clang -O2, clang compiles (n = -n) with the
assumption that signed overflow doesn't happen. It happens to be correct
for all n except INT64_MIN, which is turned into 0. All this culminates
in QBE generating incorrect immediates in assembly.

This issue is only present if QBE is compiled using clang with -O2 or
higher, and doesn't happen when a different compiler is used.

> sorry, but what does clang have to do with QBE? :D

clang (and -O2) here is a red herring. The actual point is that the
result of `-INT64_MAX` cannot be representated in `int64_t` and thus
falls under signed overflow - which C standard declares as UB.

- NRK

> result of `-INT64_MAX`

I meant `-INT64_MIN` here.

- NRK

On Fri, Aug 02, 2024 at 06:39:07PM +0300, Alexey Yerin wrote:
> On Fri Aug 2, 2024 at 14:22 +0200, Lorenz (xha) wrote:
> > On Fri, Aug 02, 2024 at 02:39:07PM +0300, Alexey Yerin wrote:
> > > Clang incorrectly optimizes this negation with -O2 and causes QBE to
> >
> > sorry, but what does clang have to do with QBE? :D
> 
> If QBE is compiled with clang -O2, clang compiles (n = -n) with the
> assumption that signed overflow doesn't happen. It happens to be correct
> for all n except INT64_MIN, which is turned into 0. All this culminates
> in QBE generating incorrect immediates in assembly.
> 
> This issue is only present if QBE is compiled using clang with -O2 or
> higher, and doesn't happen when a different compiler is used.

hah! i see, thanks for the explaination. thought there was a clang
backend for QBE or something lol

> result of `-INT64_MAX` cannot be representated in `int64_t`

You also mean -INT64_MIN? :)

On Fri, Aug 2, 2024, at 13:39, Alexey Yerin wrote:
> Clang incorrectly optimizes this negation with -O2 and causes QBE to
> emit 0 in place of INT64_MIN.

I pushed your patch on master.

Clang is not "incorrect" unfortunately, since the overflow is UB.
That being said, wow, spooky! I thought this would never happen.

I'd like to get to the bottom of it. Can you give me some details
on your compilation settings (clang version and target arch)?
On my machine, your patch does not change the assembly generated.

Thanks for reporting and fixing!