From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_ADSP_CUSTOM_MED,
	DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM autolearn=no autolearn_force=no
	version=3.4.4
Received: (qmail 26860 invoked from network); 17 Jan 2021 22:05:42 -0000
Received: from 1ess.inri.net (216.126.196.35)
  by inbox.vuxu.org with ESMTPUTF8; 17 Jan 2021 22:05:42 -0000
Received: from mail-vs1-f50.google.com ([209.85.217.50]) by 1ess; Sun Jan 17 16:36:28 -0500 2021
Received: by mail-vs1-f50.google.com with SMTP id o125so6889973vsc.6
        for <9front@9front.org>; Sun, 17 Jan 2021 13:36:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20161025;
        h=mime-version:from:date:message-id:subject:to;
        bh=r/1jdltaTRgIYKssdFRHLsUdzMOg6qANtKXP1YE1NOM=;
        b=hj/CuaoRMdcBDwi8kr4Oy1VOQSisU7zJVNxevRHDYCjXv1fglsZCEmXwvVVMJgOE+e
         br3bGXNftaf86QkM8hlJhTpTAFAVMLK0Vi7xhq8EPa8hhvajr0YRiPLG41NCglFHR+UY
         NZcyMm0C+7VIG9oA3dZsjZyaqnTiRreXYgobcTn7tDXvzx9G4ZKLEuj7G4GB1L9e+4f5
         AkdBpz5OW+Nsp0QJCLQIz1tvGgmIdxJB/+ZLExD7ScUTn/WjF1QvgDcbLfXazQ4inJ05
         3eZIwnVUSO6NAdlxFYjqcJ4p9n2bDCRFv7rmuI2stPooW1AFhrx6IFa48DzzCrXoWMwx
         Hb0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
        bh=r/1jdltaTRgIYKssdFRHLsUdzMOg6qANtKXP1YE1NOM=;
        b=O3HVBe3ZQY+kjnhn3uWypTWazee4tUonqxgcgAy+Bq4OAxzMakU6di7edK+BXsDIaB
         i8qrD4bvHLrygF/EoUdyXJHB2XDXJC1wtGJpNrl6pZsQEIIiP873IyVc51U1o1uALyMn
         EVOtVLbAxyfXvtb+O6MLCi0IorD0v5Jmj7VGxkZOVKU2lkzYvqyEVz9//eJZCpdOwENp
         3OzpEU4P7YfTp2X2ZkHXuLBricWB8QUbwPhbCJkCHDfxMwbZgFxLdJvkS2/ieP+Uq+Jw
         bUndkOFVEmToHKQe6GdKw/fvl+aod01EquD6lW6BdruxboVfEWWKfvdpMl6krbzN6stu
         B7DQ==
X-Gm-Message-State: AOAM5333g8GiOLeJ8aD28GZs69peHs/A51cOCfpfS2f84q7QnKG5tJaL
	eI5xNqvHxqgkMhQuOqz4M+tBkPQhPTZSvduPZiP5owtYHgg=
X-Google-Smtp-Source: ABdhPJyl2kUph2tI6a169cDZCI58VOciJ0qNPvenxm8aFSVIkv6q4lwoMWqCSymhv4baj4JWSyOLgCz6+PZ/ZlG1WOw=
X-Received: by 2002:a67:f991:: with SMTP id b17mr16345048vsq.0.1610919379375;
 Sun, 17 Jan 2021 13:36:19 -0800 (PST)
MIME-Version: 1.0
From: Jonas Amoson <jonas.amoson@gmail.com>
Date: Sun, 17 Jan 2021 23:36:08 +0200
Message-ID: <CAF46DJ74p1mmkjbN4wavNW+VeLGQiA-XJ2Ohg0hT=LO2FZdmOg@mail.gmail.com>
To: 9front@9front.org
Content-Type: text/plain; charset="UTF-8"
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: XML software storage-scale database 
Subject: [9front] Weird >>= operator behaviour in 5c/5l
Reply-To: 9front@9front.org
Precedence: bulk

Dear list,

It looks to me that the operation x >>= 0 doesn't generate the
correct result with 5c/5l (32-bit arm on Rpi 1b+). Example:

x = 2;
x >>= 0;

Gives x == 0 on arm, but on 386 it yields x == 2 as expected.
The non shorted form: x = x >> 0; Gives the correct result.
Is this a known issue, or I am missing something?

Looking at the assembly, the operation seems to be eliminated
if using the long form (giving the correct result) but using the
shorted form generates an instruction SRL $0, R1, R2, which
doesn't seem to work. Other shifts (e.g. x>>=1) do work (e.g.
generating SRL $1, R1, R2).

//Jonas Amoson

#include <u.h>
#include <libc.h>

void
main()
{
        unsigned int x = 2;
        print("%ud\n", x >>= 0);
        exits(nil);
}