This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- Cc: "gcc\ at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Rich Fuhler <Rich dot Fuhler at imgtec dot com>, "macro\ at codesourcery dot com" <macro at codesourcery dot com>, "Joseph Myers \(joseph\ at codesourcery dot com\)" <joseph at codesourcery dot com>, "Moore\, Catherine \(Catherine_Moore\ at mentor dot com\)" <Catherine_Moore at mentor dot com>
- Date: Tue, 04 Mar 2014 18:42:09 +0000
- Subject: Re: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
- Authentication-results: sourceware.org; auth=none
- References: <6D39441BF12EF246A7ABCE6654B023534AAE6E at LEMAIL01 dot le dot imgtec dot org> <87mwhhg9e5 dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534AC1F0 at LEMAIL01 dot le dot imgtec dot org> <878ut0fj45 dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534AD16E at LEMAIL01 dot le dot imgtec dot org> <87ppmbdobm dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534AEB92 at LEMAIL01 dot le dot imgtec dot org> <6D39441BF12EF246A7ABCE6654B023534B4C29 at LEMAIL01 dot le dot imgtec dot org>
Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
>> > Sorry, forgot about that. In that case maybe program headers would be
>> > best, like you say. I.e. we could use a combination of GNU attributes
>> > and a new program header, with the program header hopefully being more
>> > general than for just this case. I suppose this comes back to the
>> > thread from binutils@ last year about how to manage the dwindling
>> > number of free flags:
>> >
>> > https://www.sourceware.org/ml/binutils/2013-09/msg00039.html
>> > to https://www.sourceware.org/ml/binutils/2013-09/msg00099.html
>> >
>
> There are a couple of issues to resolve in order to use gnu attributes
> to record FP requirements at the module level. As it currently stands
> gnu attributes are controlled via the .gnu_attribute directive and these
> are emitted explicitly by the compiler. I think it is important that a
> more meaningful directive is available but it will need to interact
> nicely with the .gnu_attribute as well.
>
> The first problem is that there will be new ways to influence whether a
> gnu attribute is emitted or not. i.e. the command line options -mfp32,
> -mfpxx, -mfp64 will infer the relevant attribute Tag_GNU_MIPS_ABI_FP and
> if the .module directive is present then that would override it. Will
> there be any problems with a new ways to generate a gnu attribute?
I think we should just give an error if any .gnu_attributes are inconsistent
with the module-level setting (whether that comes from .module or command-line
flags).
> The second problem is that in order to support relaxing a mode
> requirement then any up-front directive/command line option that sets a
> specific fp32/fp64 requirement needs to be updated to fpxx. With gnu
> attributes this would mean updating an existing Tag_GNU_MIPS_ABI_FP
> setting to be modeless.
Not sure what you mean here, sorry.
Thanks,
Richard