From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31095 invoked by alias); 20 May 2014 21:41:02 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 31074 invoked by uid 89); 20 May 2014 21:41:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mailapp01.imgtec.com Received: from mailapp01.imgtec.com (HELO mailapp01.imgtec.com) (195.59.15.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 20 May 2014 21:40:59 +0000 Received: from KLMAIL01.kl.imgtec.org (unknown [192.168.5.35]) by Websense Email Security Gateway with ESMTPS id 513CBD055C9F8; Tue, 20 May 2014 22:40:51 +0100 (IST) Received: from KLMAIL02.kl.imgtec.org (192.168.5.97) by KLMAIL01.kl.imgtec.org (192.168.5.35) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 20 May 2014 22:40:55 +0100 Received: from LEMAIL01.le.imgtec.org (192.168.152.62) by klmail02.kl.imgtec.org (192.168.5.97) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 20 May 2014 22:40:55 +0100 Received: from LEMAIL01.le.imgtec.org ([fe80::5ae:ee16:f4b9:cda9]) by LEMAIL01.le.imgtec.org ([fe80::5ae:ee16:f4b9:cda9%17]) with mapi id 14.03.0174.001; Tue, 20 May 2014 22:40:54 +0100 From: Matthew Fortune To: Richard Sandiford CC: "binutils@sourceware.org" , Rich Fuhler Subject: RE: [PATCH][MIPS] Implement .module directive Date: Tue, 20 May 2014 21:41:00 -0000 Message-ID: <6D39441BF12EF246A7ABCE6654B023535390A7@LEMAIL01.le.imgtec.org> References: <6D39441BF12EF246A7ABCE6654B02353538578@LEMAIL01.le.imgtec.org> <87tx8kib4k.fsf@talisman.default> In-Reply-To: <87tx8kib4k.fsf@talisman.default> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00187.txt.bz2 Richard Sandiford writes: > Matthew Fortune writes: > > + if (file_mips_opts.fp < 0) > > + { > > + /* No user specified float register size. > > + ??? GAS treats single-float processors as though they had 64-bit > > + float registers (although it complains when double-precision > > + instructions are used). As things stand, saying they have 32-bit > > + registers would lead to spurious "register must be even" messages. > > + So here we assume float registers are never smaller than the > > + integer ones. */ > > + if (file_mips_opts.gp =3D=3D 64) > > + /* 64-bit integer registers implies 64-bit float registers. */ > > + file_mips_opts.fp =3D 64; > > + else if ((file_mips_opts.ase & FP64_ASES) > > + && ISA_HAS_64BIT_FPRS (file_mips_opts.isa)) > > + /* -mips3d and -mdmx imply 64-bit float registers, if possible. */ > > + file_mips_opts.fp =3D 64; >=20 > I assume you'll update this for the other patch. Or we could just > make the comment vaguer: Handle ASEs that imply 64-bit float registers. Yes, I thought I'd done these but clearly not. > > + /* MIPS3D and MDMX require 64-bit FPRs, so -mfp32 should stop those > > + ASEs from being selected implicitly. */ > > + if (file_mips_opts.fp !=3D 64) > > + file_ase_explicit |=3D ASE_MIPS3D | ASE_MDMX | ASE_MSA; >=20 > Same here. > > > @@ -787,7 +787,7 @@ if { [istarget mips*-*-vxworks*] } { > > run_dump_test "relax-swap1-mips2" > > run_dump_test "relax-swap2" > > run_dump_test_arches "relax-swap3" [mips_arch_list_all] > > - run_list_test_arches "relax-bc1any" "-mips3d -relax-branch" \ > > + run_list_test_arches "relax-bc1any" "-mips3d -64 -relax-branch" \ > > [mips_arch_list_matching mips64 \ > > !micromips] > > run_list_test_arches "relax-bposge" "-mdsp -relax-branch" \ >=20 > Not all targets compile in support for n32 and n64, so -mabi=3Do64 would > be better than -64. Will do. I had only run the assembler tests for this patch but on running the linker tests it showed a problem with .dc.a which is dependent on TC_ADDRESS_BYTES and that in turn is dependent on the GPR size. The mips_address_bytes function therefore has to finalise the options (because that is where the inferred GP register width is set up). This means that .dc.a is another pseudo that prevents further .module directives. Is that OK? (patch below to be applied along with the overall patch if approved) Regards, Matthew diff --git a/gas/config/tc-mips.c b/gas/config/tc-mips.c index 0f89bb9..6a26b99 100644 --- a/gas/config/tc-mips.c +++ b/gas/config/tc-mips.c @@ -1307,6 +1307,7 @@ static bfd_boolean pic_need_relax (symbolS *, asectio= n *); static int relaxed_branch_length (fragS *, asection *, int); static int relaxed_micromips_16bit_branch_length (fragS *, asection *, int= ); static int relaxed_micromips_32bit_branch_length (fragS *, asection *, int= ); +static void file_mips_check_options (void); /* Table and functions used to map between CPU/ISA names, and ISA levels, and CPU numbers. */ @@ -1760,6 +1761,7 @@ static const pseudo_typeS mips_nonecoff_pseudo_table[= ] =3D int mips_address_bytes (void) { + file_mips_check_options (); return HAVE_64BIT_ADDRESSES ? 8 : 4; } @@ -3676,7 +3678,7 @@ mips_check_options (struct mips_set_options *opts, bf= d_boolean abi_checks) /* Perform consistency checks on the module level options exactly once. This is a deferred check that happens: at the first .set directive - or, at the first pseudo op that generates code + or, at the first pseudo op that generates code (inc .dc.a) or, at the first instruction or, at the end. */