This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch, mips] Allow users to avoid promoting prototypes.
- From: Steve Ellcey <sellcey at imgtec dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 3 May 2013 09:21:41 -0700
- Subject: Re: [patch, mips] Allow users to avoid promoting prototypes.
- References: <1f914dfd-e5c4-46fd-a1b2-e0c2ad32da38 at BAMAIL02 dot ba dot imgtec dot org> <871u9p588j dot fsf at talisman dot default>
On Thu, 2013-05-02 at 23:26 +0100, Richard Sandiford wrote:
> >
> > 2013-05-02 Steve Ellcey <sellcey@imgtec.com>
> >
> > * config/mips/mips.c (mips_promote_prototypes) :New.
> > (TARGET_PROMOTE_PROTOTYPES): Change to use mips_promote_prototypes.
> > * config/mips/mips.opt (mpromote-prototypes): New.
>
> It'd need an invoke.texi change too.
>
> The ABI thing is a problem though. Unlike the recent -mimadd option,
> this isn't something a user could reasonably turn on and off for
> individual files to see what happens. They'd need to rebuild all
> their libraries with it. And as written, the patch provides no way
> to compile gcc's own libraries that way, so they'd need to patch the
> gcc sources locally.
I wasn't looking at providing an extra set of libraries, my assumption
was that the libraries would be compiled with the default setting of
promoting prototypes they way they are now and that these would still
work with objects that were compiled with -mno-promote-prototypes.
> If you want to change the TARGET_PROMOTE_PROTOTYPES part of the
> ABI for mips*-mti-elf then that would be OK with me. It would
> be better done without a command-line option.
I don't think I want to change the ABI for mips*-mti-elf at this point.
> I'm less keen on adding -mpromote-prototypes to mips*-mti-elf,
> both because of the large number of variations there already,
> and because continuing to have -mno-promote-prototypes multilibs
> would give the impression that the change isn't much of a win.
I definitely don't want to create another set of multilibs.
>
> Ideally we'd also have a .gnu_attribute to record which promotion
> rules are being used, so that the linker can pick up incompatibilities.
>
> Sorry to be a pain...
>
> Thanks,
> Richard
That's alright, I will drop this idea for now and perhaps look at
Richard Biener's idea (optimizing out the promotion on local calls)
later.
Steve Ellcey
sellcey@imgtec.com