This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
RE: [PATCHv2, MIPS] Add support for O32 FPXX and program header based ABI information
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- Cc: Will Newton <will dot newton at linaro dot org>, Andrew Pinski <pinskia at gmail dot com>, Richard Sandiford <rdsandiford at googlemail dot com>, Rich Fuhler <Rich dot Fuhler at imgtec dot com>, "macro at codesourcery dot com" <macro at codesourcery dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Thu, 15 May 2014 20:18:51 +0000
- Subject: RE: [PATCHv2, MIPS] Add support for O32 FPXX and program header based ABI information
- Authentication-results: sourceware.org; auth=none
- References: <6D39441BF12EF246A7ABCE6654B0235352F38D at LEMAIL01 dot le dot imgtec dot org> <Pine dot LNX dot 4 dot 64 dot 1405141549300 dot 16785 at digraph dot polyomino dot org dot uk> <6D39441BF12EF246A7ABCE6654B0235352FF45 at LEMAIL01 dot le dot imgtec dot org> <Pine dot LNX dot 4 dot 64 dot 1405142119340 dot 21615 at digraph dot polyomino dot org dot uk> <6D39441BF12EF246A7ABCE6654B0235353041B at LEMAIL01 dot le dot imgtec dot org> <Pine dot LNX dot 4 dot 64 dot 1405151517380 dot 3155 at digraph dot polyomino dot org dot uk> <6D39441BF12EF246A7ABCE6654B02353531C1D at LEMAIL01 dot le dot imgtec dot org>
On Thu, 15 May 2014, Matthew Fortune wrote:
> > That indicates to me that the GCC -mmsa option should not imply the
> > assembler -mmsa option, so that users can use -mmsa with GCC exactly the
> > same way they use -mavx (for example) - that is, -mmsa should result in
> > the push/pop in the .s file. Otherwise, how do you expect users compiling
> > one source file with -mmsa and one without to get their final binary not
> > marked as requiring MSA?
>
> I don't currently expect an object built with -mmsa and one without to result
> in an executable that does not say it requires MSA. If someone wishes to hide
> the usage of an extended architecture feature then that it must be enabled on
> a per function basis so that it is clear that they are special. For MSA this
I consider that a key feature of the GNU toolchain is consistency between
different architectures - meaning that if this sort of thing works on
pretty much all architectures, MIPS shouldn't be doing something
different. (And it *certainly* shouldn't be requiring things to be done
on a per-function basis. Even if the command-line option acts
differently, there should be a command-line option to say that the object
isn't marked as needing MSA - though I'd say it should be the other way
round, with a -m option to say to mark the object for runtime
compatibility checks.)
I suppose that, to the extent that LTO options merging may already cause
issues when different objects are built with different options, there may
be a case for a -f option meaning "this object uses instruction set
extensions in functions that may or may not be used at runtime, do not
automatically use those options for other objects in this link and do not
count those extensions for runtime compatibility checks".
--
Joseph S. Myers
joseph@codesourcery.com