This is the mail archive of the
mailing list for the binutils project.
Re: RFC & patch: Rework MIPS command-line handling
- From: "Mark D. Baushke" <mdb at gnu dot org>
- To: "Maciej W. Rozycki" <macro at ds2 dot pg dot gda dot pl>
- Cc: Eric Christopher <echristo at redhat dot com>, Richard Sandiford <rsandifo at redhat dot com>, gcc-patches at gcc dot gnu dot org, binutils at sources dot redhat dot com
- Date: Mon, 15 Jul 2002 02:09:40 -0700
- Subject: Re: RFC & patch: Rework MIPS command-line handling
- References: <Pine.GSO.3.96.1020715073320.22261Demail@example.com>
Your comments also make a great deal of sense to me.
"Maciej W. Rozycki" <firstname.lastname@example.org> writes:
> > 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
It is not unreasonable to me.
There are times when backward compatibility is not the issue.
For example, it is sometimes useful for an embedded target to utilize
those kind of configurations for performance reasons.
Such an embedded target may want to utilize a 32bit pointer and still
have access to 64bit integers as well as access to cpu-specific
instructions that are normally not part of the ISA being used by the
rest of the code base. ISA and ABI should be able to be controlled
separately where possible. Right now it is a pain at times to need to
hack the assembler of some kernel source code to use, for example,
'.set mips32; ssnop; .set mips0'
'.set mips64; dmtc0 $zero,$29,2; .set mips0'
when the rest of the entire system is being compiled in -mips4. It is
much nicer to use '-EB -march=sb1250 -mabi=32' if that is what is needed
to get the elf32-bigmips format file desired.
Agreed that there are some combinations that could lead to a bad object
file being generated. Those combinations should probably generate a
warning (that becomes an error under -Werror).
IMO, a warning would be better than silently switching the -mabi=32 in
the case of an -march=R3000 arg on a toolchain that defaults to using a
64-bit ABI. It should only be an error if the user specifies -Werror
too. This is okay for the situation of not overriding all of the needed
defaults. It does not really cover the case of specifying incompatible
options on the command line.
What should be done in with a command line that specified -march=R3000
-mabi=64 ? Should it generate an error and bailout? Or should it also
just be a warning that gets promoted to error on -Werror?