From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=dALs=55=orcam.me.uk=macro@sourceware.org>
Received: from angie.orcam.me.uk (angie.orcam.me.uk [78.133.224.34])
	by sourceware.org (Postfix) with ESMTP id 395D03858D39
	for <binutils@sourceware.org>; Wed,  1 Feb 2023 10:40:26 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 395D03858D39
Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orcam.me.uk
Authentication-Results: sourceware.org; spf=none smtp.mailfrom=orcam.me.uk
Received: by angie.orcam.me.uk (Postfix, from userid 500)
	id 414BB92009C; Wed,  1 Feb 2023 11:40:25 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by angie.orcam.me.uk (Postfix) with ESMTP id 3E07792009B;
	Wed,  1 Feb 2023 10:40:25 +0000 (GMT)
Date: Wed, 1 Feb 2023 10:40:25 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: Andrew Burgess <aburgess@redhat.com>
cc: binutils@sourceware.org
Subject: Re: [PATCH 1/2] opcodes/mips: use .word/.short for undefined
 instructions
In-Reply-To: <87o7qguzzx.fsf@redhat.com>
Message-ID: <alpine.DEB.2.21.2301312350580.4010@angie.orcam.me.uk>
References: <cover.1667483581.git.aburgess@redhat.com> <e53fbf5025e59fe6a3481b9c1fe37e4f6cf6e03d.1667483581.git.aburgess@redhat.com> <alpine.DEB.2.21.2301061545130.54090@angie.orcam.me.uk> <87fscny5tr.fsf@redhat.com> <alpine.DEB.2.21.2301081539290.2259@angie.orcam.me.uk>
 <87a62hfoa5.fsf@redhat.com> <alpine.DEB.2.21.2301270155510.8022@angie.orcam.me.uk> <87o7qguzzx.fsf@redhat.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-Spam-Status: No, score=-1163.1 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_INFOUSMEBIZ,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <binutils.sourceware.org>

Andrew,

> I've updated the patch.  Let me know what you think.

 I'd say it's OK, except that I put your change through my MIPS regression 
tester and that revealed failures from your new case for numerous targets, 
e.g.:

mips-elf  +FAIL: microMIPS source file contains reserved encoding (o32)
mips-img-elf  +FAIL: microMIPS source file contains reserved encoding (o32)
mips-img-elf  +FAIL: microMIPS source file contains reserved encoding (n32)

etc.  The usual suspect is section padding owing to different alignments 
used with individual MIPS targets, e.g.:

extra regexps in 
.../binutils/testsuite/binutils-all/mips/micromips-reserved-enc-o32.d starting with "^
\.\.\.$"
EOF from tmpdir/dump.out
FAIL: microMIPS source file contains reserved encoding (o32)

See e.g. binutils/testsuite/binutils-all/mips/micromips-branch-alias.s for 
how to add suitable padding at the end.

 And then:

mipsisa32r6-elf  +FAIL: microMIPS source file contains reserved encoding (o32)
mipsisa32r6-linux  +FAIL: microMIPS source file contains reserved encoding (o32)
mipsisa32r6el-elf  +FAIL: microMIPS source file contains reserved encoding (o32)

etc., due to:

.../binutils/testsuite/binutils-all/mips/micromips-reserved-enc.s: Assembler messages:
.../binutils/testsuite/binutils-all/mips/micromips-reserved-enc.s:3: Fatal error: `micromips' cannot be used with `mips32r6'

We don't care about different ISA levels here, so let's set a reasonable 
one, as in binutils/testsuite/binutils-all/mips/micromips-branch-alias.s 
again:

	.module	mips64r3

(it could be `.set' too, but let's be consistent, and it has to be a 
64-bit one for the n32/n64 ABIs).

 OK with these updates, thank you for your contribution.

  Maciej