[PATCH] MIPS: Add a GNU attribute for -mips32 -mfp64 objects

[Thiemo Seufer]

Hello All,

the appended patch extends the exisiting GNU attribute which tags the
MIPS floating point ABI variant. The new tag is used for MIPS32 R2
CPUs which allow to run the FPU in a mode with 64-bit wide registers.
I failed to come up with a better name than "-mips32r2 -mfp64", which
are the command line options to select this mode.

While I wrote this patch I noticed that the tagging takes only place
when the respective gnu_attribute is found in the source code. This
leaves objects created from assembly untagged. I wonder if it is a good
idea to generally add a FP ABI attribute, derived from the assembler's
command line flags, unless this is overridden by a gnu_attribute
directive in the source. Is there a backward compatibility issue I fail
to see, or some other effect which makes this a bad idea?


Thiemo


2007-11-14 Thiemo Seufer <***@mips.com>

[ld/testsuite/ChangeLog]
* ld-mips-elf/attr-gnu-4-14.d, ld-mips-elf/attr-gnu-4-41.d:
Adjust warning message for -mfp64 flag.
* ld-mips-elf/attr-gnu-4-5.s, ld-mips-elf/attr-gnu-4-04.d,
ld-mips-elf/attr-gnu-4-51.d, ld-mips-elf/attr-gnu-4-05.d,
ld-mips-elf/attr-gnu-4-15.d, ld-mips-elf/attr-gnu-4-24.d,
ld-mips-elf/attr-gnu-4-25.d, ld-mips-elf/attr-gnu-4-34.d,
ld-mips-elf/attr-gnu-4-35.d, ld-mips-elf/attr-gnu-4-42.d,
ld-mips-elf/attr-gnu-4-43.d, ld-mips-elf/attr-gnu-4-44.d,
ld-mips-elf/attr-gnu-4-45.d, ld-mips-elf/attr-gnu-4-40.d,
ld-mips-elf/attr-gnu-4-14.d: New testcases files.
* ld-mips-elf/mips-elf.exp: Run new testcases.

[binutils/ChangeLog]
* readelf.c (display_mips_gnu_attribute): Recognize -mips32r2 -mfp64
objects.

[include/ChangeLog]
* elf/mips.h (Tag_GNU_MIPS_ABI_FP): Mention -mips32r2 -mfp64 variant
in comment.

[bfd/ChangeLog]
* elfxx-mips.c (mips_elf_merge_obj_attributes): Handle -mips32r2
-mfp64 attribute.


Index: head/bfd/elfxx-mips.c
===================================================================
--- head.orig/bfd/elfxx-mips.c 2007-11-14 19:15:45.000000000 +0000
+++ head/bfd/elfxx-mips.c 2007-11-14 19:15:49.000000000 +0000
@@ -11055,11 +11055,11 @@
out_attr[Tag_GNU_MIPS_ABI_FP].i = in_attr[Tag_GNU_MIPS_ABI_FP].i;
else if (in_attr[Tag_GNU_MIPS_ABI_FP].i == 0)
;
- else if (in_attr[Tag_GNU_MIPS_ABI_FP].i > 3)
+ else if (in_attr[Tag_GNU_MIPS_ABI_FP].i > 4)
_bfd_error_handler
(_("Warning: %B uses unknown floating point ABI %d"), ibfd,
in_attr[Tag_GNU_MIPS_ABI_FP].i);
- else if (out_attr[Tag_GNU_MIPS_ABI_FP].i > 3)
+ else if (out_attr[Tag_GNU_MIPS_ABI_FP].i > 4)
_bfd_error_handler
(_("Warning: %B uses unknown floating point ABI %d"), obfd,
out_attr[Tag_GNU_MIPS_ABI_FP].i);
@@ -11081,6 +11081,12 @@
obfd, ibfd);
break;

+ case 4:
+ _bfd_error_handler
+ (_("Warning: %B uses -msingle-float, %B uses -mips32r2 -mfp64"),
+ obfd, ibfd);
+ break;
+
default:
abort ();
}
@@ -11101,6 +11107,12 @@
obfd, ibfd);
break;

+ case 4:
+ _bfd_error_handler
+ (_("Warning: %B uses -mdouble-float, %B uses -mips32r2 -mfp64"),
+ obfd, ibfd);
+ break;
+
default:
abort ();
}
@@ -11111,6 +11123,7 @@
{
case 1:
case 2:
+ case 4:
_bfd_error_handler
(_("Warning: %B uses hard float, %B uses soft float"),
ibfd, obfd);
@@ -11121,6 +11134,32 @@
}
break;

+ case 4:
+ switch (in_attr[Tag_GNU_MIPS_ABI_FP].i)
+ {
+ case 1:
+ _bfd_error_handler
+ (_("Warning: %B uses -msingle-float, %B uses -mips32r2 -mfp64"),
+ ibfd, obfd);
+ break;
+
+ case 2:
+ _bfd_error_handler
+ (_("Warning: %B uses -mdouble-float, %B uses -mips32r2 -mfp64"),
+ ibfd, obfd);
+ break;
+
+ case 3:
+ _bfd_error_handler
+ (_("Warning: %B uses hard float, %B uses soft float"),
+ obfd, ibfd);
+ break;
+
+ default:
+ abort ();
+ }
+ break;
+
default:
abort ();
}
Index: head/include/elf/mips.h
===================================================================
--- head.orig/include/elf/mips.h 2007-11-14 19:01:30.000000000 +0000
+++ head/include/elf/mips.h 2007-11-14 19:15:49.000000000 +0000
@@ -1012,9 +1012,9 @@
/* 0-3 are generic. */
Tag_GNU_MIPS_ABI_FP = 4, /* Value 1 for hard-float -mdouble-float, 2
for hard-float -msingle-float, 3 for
- soft-float; 0 for not tagged or not
- using any ABIs affected by the
- differences. */
+ soft-float, 4 for -mips32r2 -mfp64; 0 for
+ not tagged or not using any ABIs affected
+ by the differences. */
};

#endif /* _ELF_MIPS_H */
Index: head/binutils/readelf.c
===================================================================
--- head.orig/binutils/readelf.c 2007-11-14 19:01:30.000000000 +0000
+++ head/binutils/readelf.c 2007-11-14 19:15:49.000000000 +0000
@@ -8833,6 +8833,9 @@
case 3:
printf ("Soft float\n");
break;
+ case 4:
+ printf ("64-bit float (-mips32r2 -mfp64)\n");
+ break;
default:
printf ("??? (%d)\n", val);
break;
Index: head/ld/testsuite/ld-mips-elf/attr-gnu-4-5.s
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ head/ld/testsuite/ld-mips-elf/attr-gnu-4-5.s 2007-11-14 19:15:49.000000000 +0000
@@ -0,0 +1 @@
+.gnu_attribute 4,5
Index: head/ld/testsuite/ld-mips-elf/mips-elf.exp
===================================================================
--- head.orig/ld/testsuite/ld-mips-elf/mips-elf.exp 2007-11-14 19:01:30.000000000 +0000
+++ head/ld/testsuite/ld-mips-elf/mips-elf.exp 2007-11-14 19:15:49.000000000 +0000
@@ -285,17 +285,30 @@
run_dump_test "attr-gnu-4-01"
run_dump_test "attr-gnu-4-02"
run_dump_test "attr-gnu-4-03"
+run_dump_test "attr-gnu-4-04"
+run_dump_test "attr-gnu-4-05"
run_dump_test "attr-gnu-4-10"
run_dump_test "attr-gnu-4-11"
run_dump_test "attr-gnu-4-12"
run_dump_test "attr-gnu-4-13"
run_dump_test "attr-gnu-4-14"
+run_dump_test "attr-gnu-4-15"
run_dump_test "attr-gnu-4-20"
run_dump_test "attr-gnu-4-21"
run_dump_test "attr-gnu-4-22"
run_dump_test "attr-gnu-4-23"
+run_dump_test "attr-gnu-4-24"
+run_dump_test "attr-gnu-4-25"
run_dump_test "attr-gnu-4-30"
run_dump_test "attr-gnu-4-31"
run_dump_test "attr-gnu-4-32"
run_dump_test "attr-gnu-4-33"
+run_dump_test "attr-gnu-4-34"
+run_dump_test "attr-gnu-4-35"
+run_dump_test "attr-gnu-4-40"
run_dump_test "attr-gnu-4-41"
+run_dump_test "attr-gnu-4-42"
+run_dump_test "attr-gnu-4-43"
+run_dump_test "attr-gnu-4-44"
+run_dump_test "attr-gnu-4-45"
+run_dump_test "attr-gnu-4-51"
Index: head/ld/testsuite/ld-mips-elf/attr-gnu-4-04.d
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ head/ld/testsuite/ld-mips-elf/attr-gnu-4-04.d 2007-11-14 19:15:49.000000000 +0000
@@ -0,0 +1,10 @@
+#source: attr-gnu-4-0.s
+#source: attr-gnu-4-4.s
+#as: -EB -32
+#ld: -r -melf32btsmip
+#readelf: -A
+#target: mips*-*-*
+
+Attribute Section: gnu
+File Attributes
+ Tag_GNU_MIPS_ABI_FP: 64-bit float \(-mips32r2 -mfp64\)
Index: head/ld/testsuite/ld-mips-elf/attr-gnu-4-51.d
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ head/ld/testsuite/ld-mips-elf/attr-gnu-4-51.d 2007-11-14 19:15:49.000000000 +0000
@@ -0,0 +1,6 @@
+#source: attr-gnu-4-5.s
+#source: attr-gnu-4-1.s
+#as: -EB -32
+#ld: -r -melf32btsmip
+#warning: Warning: .* uses unknown floating point ABI 5
+#target: mips*-*-*
Index: head/ld/testsuite/ld-mips-elf/attr-gnu-4-05.d
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ head/ld/testsuite/ld-mips-elf/attr-gnu-4-05.d 2007-11-14 19:15:49.000000000 +0000
@@ -0,0 +1,10 @@
+#source: attr-gnu-4-0.s
+#source: attr-gnu-4-5.s
+#as: -EB -32
+#ld: -r -melf32btsmip
+#readelf: -A
+#target: mips*-*-*
+
+Attribute Section: gnu
+File Attributes
+ Tag_GNU_MIPS_ABI_FP: \?\?\? \(5\)
Index: head/ld/testsuite/ld-mips-elf/attr-gnu-4-15.d
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ head/ld/testsuite/ld-mips-elf/attr-gnu-4-15.d 2007-11-14 19:15:49.000000000 +0000
@@ -0,0 +1,11 @@
+#source: attr-gnu-4-1.s
+#source: attr-gnu-4-5.s
+#as: -EB -32
+#ld: -r -melf32btsmip
+#readelf: -A
+#warning: Warning: .* uses unknown floating point ABI 5
+#target: mips*-*-*
+
+Attribute Section: gnu
+File Attributes
+ Tag_GNU_MIPS_ABI_FP: Hard float \(-mdouble-float\)
Index: head/ld/testsuite/ld-mips-elf/attr-gnu-4-24.d
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ head/ld/testsuite/ld-mips-elf/attr-gnu-4-24.d 2007-11-14 19:15:49.000000000 +0000
@@ -0,0 +1,6 @@
+#source: attr-gnu-4-2.s
+#source: attr-gnu-4-4.s
+#as: -EB -32
+#ld: -r -melf32btsmip
+#warning: Warning: .* uses -mips32r2 -mfp64
+#target: mips*-*-*
Index: head/ld/testsuite/ld-mips-elf/attr-gnu-4-25.d
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ head/ld/testsuite/ld-mips-elf/attr-gnu-4-25.d 2007-11-14 19:15:49.000000000 +0000
@@ -0,0 +1,11 @@
+#source: attr-gnu-4-2.s
+#source: attr-gnu-4-5.s
+#as: -EB -32
+#ld: -r -melf32btsmip
+#readelf: -A
+#warning: Warning: .* uses unknown floating point ABI 5
+#target: mips*-*-*
+
+Attribute Section: gnu
+File Attributes
+ Tag_GNU_MIPS_ABI_FP: Hard float \(-msingle-float\)
Index: head/ld/testsuite/ld-mips-elf/attr-gnu-4-34.d
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ head/ld/testsuite/ld-mips-elf/attr-gnu-4-34.d 2007-11-14 19:15:49.000000000 +0000
@@ -0,0 +1,6 @@
+#source: attr-gnu-4-3.s
+#source: attr-gnu-4-4.s
+#as: -EB -32
+#ld: -r -melf32btsmip
+#warning: Warning: .* uses hard float, .* uses soft float
+#target: mips*-*-*
Index: head/ld/testsuite/ld-mips-elf/attr-gnu-4-35.d
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ head/ld/testsuite/ld-mips-elf/attr-gnu-4-35.d 2007-11-14 19:15:49.000000000 +0000
@@ -0,0 +1,11 @@
+#source: attr-gnu-4-3.s
+#source: attr-gnu-4-5.s
+#as: -EB -32
+#ld: -r -melf32btsmip
+#readelf: -A
+#warning: Warning: .* uses unknown floating point ABI 5
+#target: mips*-*-*
+
+Attribute Section: gnu
+File Attributes
+ Tag_GNU_MIPS_ABI_FP: Soft float
Index: head/ld/testsuite/ld-mips-elf/attr-gnu-4-42.d
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ head/ld/testsuite/ld-mips-elf/attr-gnu-4-42.d 2007-11-14 19:15:49.000000000 +0000
@@ -0,0 +1,6 @@
+#source: attr-gnu-4-4.s
+#source: attr-gnu-4-2.s
+#as: -EB -32
+#ld: -r -melf32btsmip
+#warning: Warning: .* uses -mips32r2 -mfp64
+#target: mips*-*-*
Index: head/ld/testsuite/ld-mips-elf/attr-gnu-4-43.d
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ head/ld/testsuite/ld-mips-elf/attr-gnu-4-43.d 2007-11-14 19:15:49.000000000 +0000
@@ -0,0 +1,6 @@
+#source: attr-gnu-4-4.s
+#source: attr-gnu-4-3.s
+#as: -EB -32
+#ld: -r -melf32btsmip
+#warning: Warning: .* uses hard float, .* uses soft float
+#target: mips*-*-*
Index: head/ld/testsuite/ld-mips-elf/attr-gnu-4-44.d
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ head/ld/testsuite/ld-mips-elf/attr-gnu-4-44.d 2007-11-14 19:15:49.000000000 +0000
@@ -0,0 +1,10 @@
+#source: attr-gnu-4-4.s
+#source: attr-gnu-4-4.s
+#as: -EB -32
+#ld: -r -melf32btsmip
+#readelf: -A
+#target: mips*-*-*
+
+Attribute Section: gnu
+File Attributes
+ Tag_GNU_MIPS_ABI_FP: 64-bit float \(-mips32r2 -mfp64\)
Index: head/ld/testsuite/ld-mips-elf/attr-gnu-4-45.d
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ head/ld/testsuite/ld-mips-elf/attr-gnu-4-45.d 2007-11-14 19:15:49.000000000 +0000
@@ -0,0 +1,10 @@
+#source: attr-gnu-4-4.s
+#source: attr-gnu-4-5.s
+#as: -EB -32
+#ld: -r -melf32btsmip
+#warning: Warning: .* uses unknown floating point ABI 5
+#target: mips*-*-*
+
+Attribute Section: gnu
+File Attributes
+ Tag_GNU_MIPS_ABI_FP: 64-bit float \(-mips32r2 -mfp64\)
Index: head/ld/testsuite/ld-mips-elf/attr-gnu-4-40.d
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ head/ld/testsuite/ld-mips-elf/attr-gnu-4-40.d 2007-11-14 19:15:49.000000000 +0000
@@ -0,0 +1,10 @@
+#source: attr-gnu-4-4.s
+#source: attr-gnu-4-0.s
+#as: -EB -32
+#ld: -r -melf32btsmip
+#readelf: -A
+#target: mips*-*-*
+
+Attribute Section: gnu
+File Attributes
+ Tag_GNU_MIPS_ABI_FP: 64-bit float \(-mips32r2 -mfp64\)
Index: head/ld/testsuite/ld-mips-elf/attr-gnu-4-14.d
===================================================================
--- head.orig/ld/testsuite/ld-mips-elf/attr-gnu-4-14.d 2007-11-14 19:01:30.000000000 +0000
+++ head/ld/testsuite/ld-mips-elf/attr-gnu-4-14.d 2007-11-14 19:15:49.000000000 +0000
@@ -2,5 +2,5 @@
#source: attr-gnu-4-4.s
#as: -EB -32
#ld: -r -melf32btsmip
-#warning: Warning: .* uses unknown floating point ABI 4
+#warning: Warning: .* uses -msingle-float, .* uses -mips32r2 -mfp64
#target: mips*-*-*
Index: head/ld/testsuite/ld-mips-elf/attr-gnu-4-41.d
===================================================================
--- head.orig/ld/testsuite/ld-mips-elf/attr-gnu-4-41.d 2007-11-14 19:01:30.000000000 +0000
+++ head/ld/testsuite/ld-mips-elf/attr-gnu-4-41.d 2007-11-14 19:15:49.000000000 +0000
@@ -2,5 +2,5 @@
#source: attr-gnu-4-1.s
#as: -EB -32
#ld: -r -melf32btsmip
-#warning: Warning: .* uses unknown floating point ABI 4
+#warning: Warning: .* uses -msingle-float, .* uses -mips32r2 -mfp64
#target: mips*-*-*

[Joseph S. Myers]

Post by Thiemo Seufer
While I wrote this patch I noticed that the tagging takes only place
when the respective gnu_attribute is found in the source code. This
leaves objects created from assembly untagged. I wonder if it is a good
idea to generally add a FP ABI attribute, derived from the assembler's
command line flags, unless this is overridden by a gnu_attribute
directive in the source. Is there a backward compatibility issue I fail
to see, or some other effect which makes this a bad idea?

I didn't think the compiler passed the -msoft-float/-mhard-float ABI
information to the assembler, so this could cause problems with incorrect
tagging when older compilers are used with newer assemblers. The ABI is a
separate matter from what instructions are enabled, and a valid ABI is
being compatible with both hard and soft float; a file with purely integer
instructions could be a soft-float file if the functions are taking
floating-point parameters, or a file compatible with both if they are
taking integer parameters. How would you deduce the C language function
call compatibility of an object (which is what the attributes describe)
from the assembler source and command line options?

[Thiemo Seufer]

Post by Joseph S. Myers

Post by Thiemo Seufer
While I wrote this patch I noticed that the tagging takes only place
when the respective gnu_attribute is found in the source code. This
leaves objects created from assembly untagged. I wonder if it is a good
idea to generally add a FP ABI attribute, derived from the assembler's
command line flags, unless this is overridden by a gnu_attribute
directive in the source. Is there a backward compatibility issue I fail
to see, or some other effect which makes this a bad idea?

I didn't think the compiler passed the -msoft-float/-mhard-float ABI
information to the assembler, so this could cause problems with incorrect
tagging when older compilers are used with newer assemblers.

The compiler currently doesn't pass down the -m*-float options. So
the assembler won't see the option, and therefore won't tag the object.
The -mfp64 is passed, but it is AFAICS unlikely to generate invalid
tagging: Presumably the reason to use the compiler's -mfp64 option is
to generate 64-bit FP code, which isn't compatible to the other variants
as soon as e.g. a mfhc1 instruction is used.

The idea is to pass the relevent options to the assembler (at least for
.s/.S source files, for compiler generated files it would be redundant).

Post by Joseph S. Myers
The ABI is a
separate matter from what instructions are enabled, and a valid ABI is
being compatible with both hard and soft float; a file with purely integer
instructions could be a soft-float file if the functions are taking
floating-point parameters, or a file compatible with both if they are
taking integer parameters. How would you deduce the C language function
call compatibility of an object (which is what the attributes describe)
from the assembler source and command line options?

I think of all those, soft-float and "no-float" are the only compatible
ones. They would stay link compatible, as "no FP option" means tag 0.

A hard-float object which happens not to use floating point at all wouldn't
be link compatible any more, this is the same effect which was evidently
regarded as acceptable in newer GCC compilers.


Thiemo

[Joseph S. Myers]

Post by Thiemo Seufer
The -mfp64 is passed, but it is AFAICS unlikely to generate invalid
tagging: Presumably the reason to use the compiler's -mfp64 option is
to generate 64-bit FP code, which isn't compatible to the other variants
as soon as e.g. a mfhc1 instruction is used.

This tagging in the assembler would need of course to be conditioned on
generating O32 code, since as I understand it -mfp64 only selects a novel
ABI variant for O32, N32 and N64 are covered by the normal hard-float ABI
setting.

Post by Thiemo Seufer
The idea is to pass the relevent options to the assembler (at least for
.s/.S source files, for compiler generated files it would be redundant).

Indeed - for compiler generated files, if you need to modify the compiler
to pass down the option, you may as well modify it to set the attribute
itself.

Post by Thiemo Seufer
A hard-float object which happens not to use floating point at all wouldn't
be link compatible any more, this is the same effect which was evidently
regarded as acceptable in newer GCC compilers.

Acceptable but not ideal; we'd hope in future to make GCC detect whether
the particular source file is or is not affected, and then set the
attribute saying it's unaffected if it's unaffected. I suppose unaffected
assembler files can always explicitly set the attribute to say so.

[Richard Sandiford]

Post by Thiemo Seufer

Post by Joseph S. Myers

Post by Thiemo Seufer
While I wrote this patch I noticed that the tagging takes only place
when the respective gnu_attribute is found in the source code. This
leaves objects created from assembly untagged. I wonder if it is a good
idea to generally add a FP ABI attribute, derived from the assembler's
command line flags, unless this is overridden by a gnu_attribute
directive in the source. Is there a backward compatibility issue I fail
to see, or some other effect which makes this a bad idea?

I didn't think the compiler passed the -msoft-float/-mhard-float ABI
information to the assembler, so this could cause problems with incorrect
tagging when older compilers are used with newer assemblers.

The compiler currently doesn't pass down the -m*-float options. So
the assembler won't see the option, and therefore won't tag the object.
The -mfp64 is passed, but it is AFAICS unlikely to generate invalid
tagging: Presumably the reason to use the compiler's -mfp64 option is
to generate 64-bit FP code, which isn't compatible to the other variants
as soon as e.g. a mfhc1 instruction is used.
The idea is to pass the relevent options to the assembler (at least for
.s/.S source files, for compiler generated files it would be redundant).

I agree with Joseph here. Although it's redundant to specify -mfp64
with -msoft-float, it isn't actively wrong. The options have traditionally
been orthogonal. I don't think the assembler should assume that -mfp64
implies -mhard-float.

I agree that it's a good idea to make -mfp64 -mgp32 a separate value for
the existing attribute (rather than introducing a new attribute, say).
But at the moment, only the compiler or assembly programmer knows the
right value for the attribute.

FWIW, I think it would be perfectly OK to add an extra case to gcc's
attribute code now, even though we're in stage 3. I'll volunteer to
do that if you don't have a patch already.

Richard

[Paul Koning]

Richard> I agree with Joseph here. Although it's redundant to
Richard> specify -mfp64 with -msoft-float, it isn't actively wrong.
Richard> The options have traditionally been orthogonal. I don't
Richard> think the assembler should assume that -mfp64 implies
Richard> -mhard-float.

It seems strange, since -msoft-float means no float registers, while
-mfp64 says there are float registers and they are 64 bits wide.

paul

[Richard Sandiford]

Post by Paul Koning
Richard> I agree with Joseph here. Although it's redundant to
Richard> specify -mfp64 with -msoft-float, it isn't actively wrong.
Richard> The options have traditionally been orthogonal. I don't
Richard> think the assembler should assume that -mfp64 implies
Richard> -mhard-float.
It seems strange, since -msoft-float means no float registers, while
-mfp64 says there are float registers and they are 64 bits wide.

Well, -mhard-float and -msoft-float are ABI options. -mfp64 is
an architectural configuration option, and only affects calling
conventions when combined with -mhard-float. It is perfectly
possible to write code that conforms to the soft-float ABI while
still using FPU instructions within a function. (Strictly speaking,
the use of FPU instructions is also part of the ABI. But it isn't
what this attribute specifies; this attribute is about the calling
conventions.)

The practical example of the difference is MIPS16. -mhard-float
-mips16 doesn't say "use the FPU from MIPS16 code"; you can't.
It says instead that the hard-float ABI is in effect, and that
we need to use special stubs to interface with non-MIPS16 code.

Richard

[Thiemo Seufer]

Post by Richard Sandiford

Post by Paul Koning
Richard> I agree with Joseph here. Although it's redundant to
Richard> specify -mfp64 with -msoft-float, it isn't actively wrong.
Richard> The options have traditionally been orthogonal. I don't
Richard> think the assembler should assume that -mfp64 implies
Richard> -mhard-float.
It seems strange, since -msoft-float means no float registers, while
-mfp64 says there are float registers and they are 64 bits wide.

Well, -mhard-float and -msoft-float are ABI options. -mfp64 is
an architectural configuration option, and only affects calling
conventions when combined with -mhard-float.

But "-mhard-float -mfp64" constitutes a new ABI variant. This is
the case I want to cover. The "-msoft-float -mfp64" should stay
tagged as soft float object.

Post by Richard Sandiford
It is perfectly
possible to write code that conforms to the soft-float ABI while
still using FPU instructions within a function.

I wonder how relevant this possibility is in practice. To me it
sounds too subtle to be of much use.

Post by Richard Sandiford
(Strictly speaking,
the use of FPU instructions is also part of the ABI. But it isn't
what this attribute specifies; this attribute is about the calling
conventions.)
The practical example of the difference is MIPS16. -mhard-float
-mips16 doesn't say "use the FPU from MIPS16 code"; you can't.
It says instead that the hard-float ABI is in effect, and that
we need to use special stubs to interface with non-MIPS16 code.

And, for completeness, we have "-mips32r2 -mips16 -mhard-float -mfp64",
which tells the compiler to generate different stubs than the ones
needed for the standard hard float.


Thiemo

[Richard Sandiford]

Post by Thiemo Seufer

Post by Richard Sandiford

Post by Paul Koning
Richard> I agree with Joseph here. Although it's redundant to
Richard> specify -mfp64 with -msoft-float, it isn't actively wrong.
Richard> The options have traditionally been orthogonal. I don't
Richard> think the assembler should assume that -mfp64 implies
Richard> -mhard-float.
It seems strange, since -msoft-float means no float registers, while
-mfp64 says there are float registers and they are 64 bits wide.

Well, -mhard-float and -msoft-float are ABI options. -mfp64 is
an architectural configuration option, and only affects calling
conventions when combined with -mhard-float.

But "-mhard-float -mfp64" constitutes a new ABI variant. This is
the case I want to cover. The "-msoft-float -mfp64" should stay
tagged as soft float object.

Right. That's why in the other paragraph I agreed that adding a new
value to the current enumeration was the right way to go. I just don't
think GAS has enough information to generate the enumeration value itself.

Post by Thiemo Seufer
And, for completeness, we have "-mips32r2 -mips16 -mhard-float -mfp64",
which tells the compiler to generate different stubs than the ones
needed for the standard hard float.

Right. In theory, -mips16 supports all hard-float and soft-float ABI
combinations for o32 and o64 (including -msingle-float).

Richard

[Joseph S. Myers]

Post by Thiemo Seufer
[ld/testsuite/ChangeLog]
[binutils/ChangeLog]
[include/ChangeLog]
[bfd/ChangeLog]

The attributes are now documented in gas/doc/as.texinfo so that needs
updating as well.