From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1898 invoked by alias); 15 Jul 2002 06:21:41 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 1819 invoked from network); 15 Jul 2002 06:21:40 -0000 Received: from unknown (HELO delta.ds2.pg.gda.pl) (213.192.72.1) by sources.redhat.com with SMTP; 15 Jul 2002 06:21:40 -0000 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id IAA23916; Mon, 15 Jul 2002 08:22:06 +0200 (MET DST) Date: Mon, 15 Jul 2002 01:03:00 -0000 From: "Maciej W. Rozycki" To: Eric Christopher cc: Richard Sandiford , gcc-patches@gcc.gnu.org, binutils@sources.redhat.com Subject: Re: RFC & patch: Rework MIPS command-line handling In-Reply-To: <1026512048.25426.47.camel@ghostwheel.cygnus.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-07/txt/msg00308.txt.bz2 On 12 Jul 2002, Eric Christopher wrote: > > I don't think how settings for e.g. mips64*-*-linux* would affect any > > embedded target if implemented correctly -- each interested party might > > set the default as desired. > > I think you should give an example of what you mean. I don't see how > this is being affected by what's going in. I _think_ what you talking I mean, if I configure for e.g. mips64*-*-linux*, I want e.g. "-march=4000 -mabi=64" be the default and with mips*-*-linux*, I want e.g. "-march=3000 -mabi=32". Someone else might want to configure for mips64*-something-else and get "-march=8000 -mabi=n32" or configure for mips*-something-else and get "-march=4000 -mabi=32". The defaults shouldn't affect one another. > about is having gas be absolutely dumb. Have gcc pass whatever options > it believes that it needs and let users of gas need to pass _everything_ > they want on the command line - otherwise default to the configured > values? I'm simply unsure if guessing any non-defaults is good to have. E.g. with the defaults as proposed above I don't think the ABI should be changed if "-march=R5000" was specified. For "-march=R3000" it would be sane to bail out with an error message for the 64-bit ABIs instead of silently switching to "-mabi=32" which could lead to a bad object file to be generated (which you'd not notice until after a long period, since the file is put in an ar archive an not pulled most of the time, for example). > > How can you guess an ABI from anything else? If I pass the "-march=4000" > > option, then which ABI do I mean? If I pass "-mips4" for conditional > > moves, then why should I add "-32" to keep the ABI unchanged? OK, if done > > carefully, the guess may probably be made harmless to uninterested parties > > -- I'll have to study the proposed changes thorougly to decide if the new > > code does it in an acceptable way. > > 1) -march=4000 > This will be a) ABI by default if it was configured with a compatible > abi. The "next compatible" abi if not. An idea was to warn if we had to > change the ABI. I don't know what people think about this - I do know > that many people get testy if new warnings are produced. Let's assume I have a 32-bit MIPS system running on the R4000 CPU and the toolchain is configured to default to "-mabi=32". And I want to generate optimal binaries. So I add "-march=4000 -mtune=4000" to flags for the toolchain. Should I have to add "-mabi=32" explicitly? > 2) -mips4 -32 > This won't work anyhow. This will produce an error. Why? This is a valid configuration. I may have a 32-bit R8000 system which is, again, configured to default to "-mabi=32". And I want to generate code optimized for this exact CPU (including the "movn" and "movz" instructions), not caring about backward compatibility. Is it unreasonable? Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available +