This is the mail archive of the
mailing list for the GCC project.
RE: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: Richard Sandiford <rdsandiford at googlemail 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: Wed, 5 Mar 2014 18:55:40 +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> <87r46hbybi dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534B572B at LEMAIL01 dot le dot imgtec dot org> <87mwh5bslv dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534B581D at LEMAIL01 dot le dot imgtec dot org> <8761nsbj9w dot fsf at talisman dot default>
Richard Sandiford <firstname.lastname@example.org> writes:
> Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
> > Are you're OK with automatically selecting fpxx if no -mfp option, no
> > .module and no .gnu_attribute exists? Such code would currently end up
> > as FP ABI Any even if FP code was present, I don't suppose anything
> > would get worse if this existing behaviour simply continued though.
> The -mfp setting is usually implied by the -mabi setting. I don't think
> we should change that. Since this is a new mode, and since the fpxx
> markup will be available from the start, everyone using fpxx should say
> so explicitly.
> E.g. maybe the rules should be:
> (1) Any explicit .gnu_attribute 4 is always used, although we might
> give a diagnostic if it's incompatible with the module-level
> (2) Otherwise, if the code does not use FP then the attribute is left
> at the default of 0.
> (3) Otherwise, a nonzero .gnu_attribute 4 is implied from the module-
> (4) For compatibility, -mabi=32 continues to imply -mfp32. fpxx mode
> be selected explicitly.
> Which was supposed to be simple, but maybe isn't so much.
This sounds OK. I'd rather (4) permitted transition to fpxx for 'safe' FP code but let's see if we can do without it. Setjmp/longjmp are the only obvious candidates for using FP code in assembly files and these need to transition to fpxx.
The glibc implementation of setjmp/longjmp is in C so the new defaults from the compiler will lead to this being fpxx as -mips32r2 will imply -mfpxx so that is OK, these modules will be tagged as fpxx.
Currently newlib's implementation is assembly code with no .gnu_attributes. Under the rules above this would start to be implicitly tagged as gnu_attribute 4,1 (fp32). Any thoughts on how we transition this to fpxx and still have the modules buildable with old tools as well? I'm not sure if it will be acceptable to say that it has to be rewritten in C.
There will also be uclibc and bionic to deal with too for setjmp/longjmp but I don't have their source to hand.