This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Re: fix multilib generation for sparc64-linux
- To: Jakub Jelinek <jakub at redhat dot com>
- Subject: Re: [PATCH] Re: fix multilib generation for sparc64-linux
- From: Ben Collins <bcollins at debian dot org>
- Date: Mon, 13 Dec 1999 13:59:33 -0500
- Cc: "David S. Miller" <davem at redhat dot com>, gcc-patches at gcc dot gnu dot org
- References: <19991212111820.F1441@lappy.djj.state.va.us> <19991213161214.J822@mff.cuni.cz>
On Mon, Dec 13, 1999 at 04:12:14PM +0100, Jakub Jelinek wrote:
> On Sun, Dec 12, 1999 at 11:18:20AM -0500, Ben Collins wrote:
> > When generating the multilib options for sparc64-linux I noticed a few
> > problems. The current options allow for an "alt" that uses the
> > "-mcmodel=medany -mno-app-regs" options. Under a normal compile we end up
> > with a 'alt/' and '64/alt' multilib directory that are identical.
>
> Have you seen it actually? It should not be ever generated twice. 64/alt is
> not generated because MULTILIB_DEFAULTS contain m64 and thus the same
> options are assumed already for alt/.
> I always get 32/ and alt/ subdirs when configuring a compiler defaulting to
> -m64.
Ok, looking it over I see how that works.
> I was trying to convince genmultilib to generate multilib.h which would do
> what I'd like it to, ie. build only 3 different directories, 32, 64 and alt,
> but let e.g. -m32 -mno-app-regs go into the 32/ directory, but it turns out
> that genmultilib is not able to generate it unless it would be hacked up
> further. So, rather than fighting genmultilib, I took the approach of
> providing a hand edited linux64 multilib.h, which should work well for both
> cases (compiler defaulting to 32 or 64bits), create only 3 different
> multilibes and work right with all the options passed to it.
Is there some mechanism that could be implemented where genmultilib will
be able to know the multilib_default or a better syntax that gcc could
parse internally to generate the proper specs? Seems it could solve the
problem. That way you end up with a '64/:64/alt/' on -m32 compiles and
'32/:alt/' on -m64 compiles. I'll see what I can come up with.
--
-----------=======-=-======-=========-----------=====------------=-=------
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` bcollins@debian.org - collinbm@djj.state.va.us - bmc@visi.net '
`---=========------=======-------------=-=-----=-===-======-------=--=---'