------- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-13 13:31 ------- (In reply to comment #11) > (In reply to comment #10) > One thing that I notice about this is that -msoft-float and -mhard-float are > no longer inverses. Good point. How about these alternatives:
1. Systematically substitute all occurences of MASK_80387 with (MASK_80387|MASK_FLOAT_RETURN) in i386.h. This would keep -msoft-float and -mno-80387, rsp. -mno-soft-float, -mhard-float and -m80387 as synonyms. IMO, this would be the least intrusive way of a proper fix. 2. Completely eliminate MASK_FLOAT_RETURN and to use MASK_80837, instead. This would be a pretty radical way, I am not sure about its consquences, but I don't expect it to do much harm. 3. Keep -[no-]hard-float, -m[no-]80387 and -m[no-]fp-ret-in-387 as they currently are, but only change soft-float to (MASK_80387|MASK_FLOAT_RETURN) and -mno-soft-float to -(MASK_80387|MASK_FLOAT_RETURN). This would satisfy RTEMS without disturbing other targets/OSes (We'd have to change our multilibs, but this wouldn't be an issue). I'd consider this to be a more a hack than an actual fix ;) 4. Fix the cause of this PR. I.e. prevent GCC from generating FPU code in the case this breakdown occurred. Unfortunately, I don't know the cause nor how to work around it. > Perhaps it would be better to modify override_options to > notice when, after all options are processed, that MASK_80387 is off and then > turn off MASK_FLOAT_RETURNS to match. I don't understand. Could you elaborate? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19379
