[m68k] Fix PR target/13292: -msoft-float seems to corrupt builtin defines

[m68k] Fix PR target/13292: -msoft-float seems to corrupt builtin defines

[Bernardo Innocenti]

The -msoft-float option incorrectly removed MASK_68040_ONLY
in addition to MASK_68881.  This leads to incorrect
predefines and unwanted degradation of integer code.

There was just one place where we were using
TARGET_68040_ONLY to generate a floating-point
instruction without taking TARGET_68881 into account.

Tested on m68k-unknown-uclinux by comparing assembly
output of some selected testcases from gcc.c-torture.

OK for mainline?  3_4-branch?


2004-06-12  Bernardo Innocenti  <bernie@develer.com>

	PR target/13292
	* config/m68k/m68k.h (TARGET_SWITCHES): Don't remove MASK_68040_ONLY
	on -msoft-float.
	* config/m68k/m68k.md (truncdfsf2): Explicitly require TARGET_68881
	in the TARGET_68040_ONLY case.


Index: gcc/config/m68k/m68k.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/m68k/m68k.h,v
retrieving revision 1.114
diff -u -p -r1.114 m68k.h
--- gcc.orig/gcc/config/m68k/m68k.h	5 Jun 2004 06:49:00 -0000	1.114
+++ gcc/gcc/config/m68k/m68k.h	12 Jun 2004 01:47:51 -0000
@@ -257,7 +257,7 @@ extern int target_flags;
     { "noshort", - MASK_SHORT,						\
       N_("Consider type `int' to be 32 bits wide") },			\
     { "68881", MASK_68881, "" },					\
-    { "soft-float", - (MASK_68040_ONLY|MASK_68881),			\
+    { "soft-float", - MASK_68881,					\
       N_("Generate code with library calls for floating point") },	\
     { "68020-40", -(MASK_ALL_CF_BITS|MASK_68060|MASK_68040_ONLY),	\
       N_("Generate code for a 68040, without any new instructions") },	\
Index: gcc/config/m68k/m68k.md
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/m68k/m68k.md,v
retrieving revision 1.76
diff -u -p -r1.76 m68k.md
--- gcc.orig/gcc/config/m68k/m68k.md	29 May 2004 15:10:41 -0000	1.76
+++ gcc/gcc/config/m68k/m68k.md	12 Jun 2004 01:47:58 -0000
@@ -1498,7 +1498,7 @@
   [(set (match_operand:SF 0 "nonimmediate_operand" "=f")
 	(float_truncate:SF
 	  (match_operand:DF 1 "general_operand" "fmG")))]
-  "TARGET_68040_ONLY"
+  "TARGET_68881 && TARGET_68040_ONLY"
 {
   if (FP_REG_P (operands[1]))
     return "f%$move%.x %1,%0";

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: [m68k] Fix PR target/13292: -msoft-float seems to corrupt builtin defines

[Mark Mitchell]

Bernardo Innocenti wrote:

> 
> The -msoft-float option incorrectly removed MASK_68040_ONLY
> in addition to MASK_68881.  This leads to incorrect
> predefines and unwanted degradation of integer code.
> 
> There was just one place where we were using
> TARGET_68040_ONLY to generate a floating-point
> instruction without taking TARGET_68881 into account.
> 
> Tested on m68k-unknown-uclinux by comparing assembly
> output of some selected testcases from gcc.c-torture.
> 
> OK for mainline?  3_4-branch?

OK for 3.4 branch if approved for mainline.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: [m68k] Fix PR target/13292: -msoft-float seems to corrupt builtin defines

[Gunther Nikl]

On Sat, Jun 12, 2004 at 04:40:11AM +0200, Bernardo Innocenti wrote:
> 
> The -msoft-float option incorrectly removed MASK_68040_ONLY
> in addition to MASK_68881.  This leads to incorrect
> predefines and unwanted degradation of integer code.
> 
> There was just one place where we were using
> TARGET_68040_ONLY to generate a floating-point
> instruction without taking TARGET_68881 into account.
> 
> Tested on m68k-unknown-uclinux by comparing assembly
> output of some selected testcases from gcc.c-torture.
> 
> OK for mainline?  3_4-branch?

  Shouldn't this go to the 3.3 branch as well?

  Gunther

Re: [m68k] Fix PR target/13292: -msoft-float seems to corrupt builtin defines

[Bernardo Innocenti]

Gunther Nikl wrote:
> On Sat, Jun 12, 2004 at 04:40:11AM +0200, Bernardo Innocenti wrote:
> 
>>The -msoft-float option incorrectly removed MASK_68040_ONLY
>>in addition to MASK_68881.  This leads to incorrect
>>predefines and unwanted degradation of integer code.
>>
>>There was just one place where we were using
>>TARGET_68040_ONLY to generate a floating-point
>>instruction without taking TARGET_68881 into account.
>>
>>Tested on m68k-unknown-uclinux by comparing assembly
>>output of some selected testcases from gcc.c-torture.
>>
>>OK for mainline?  3_4-branch?
> 
>   Shouldn't this go to the 3.3 branch as well?

I clearly remember posting the patch to reorganize
the m68k predefines during the 3.4 timeframe.

Before that patch, we had that mess with CPP_SPEC
which used to set all of the __m680x0__ predefines
even in the 68040 case, which was inappropriate but
consistent with previous versions of GCC.

I'd not change 3.3.4 to the new 3.4 semantics
because it would be quite a large change which
has the potential to break old code relying on
our former misbehavior.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: [m68k] Fix PR target/13292: -msoft-float seems to corrupt builtin defines

[Gunther Nikl]

On Tue, Jun 15, 2004 at 02:21:34PM +0200, Bernardo Innocenti wrote:
> Gunther Nikl wrote:
> >On Sat, Jun 12, 2004 at 04:40:11AM +0200, Bernardo Innocenti wrote:
> >
> >>The -msoft-float option incorrectly removed MASK_68040_ONLY
> >>in addition to MASK_68881.  This leads to incorrect
> >>predefines and unwanted degradation of integer code.
> >>
> >>There was just one place where we were using
> >>TARGET_68040_ONLY to generate a floating-point
> >>instruction without taking TARGET_68881 into account.
> >>
> >>Tested on m68k-unknown-uclinux by comparing assembly
> >>output of some selected testcases from gcc.c-torture.
> >>
> >>OK for mainline?  3_4-branch?
> >
> >  Shouldn't this go to the 3.3 branch as well?
> 
> I clearly remember posting the patch to reorganize the m68k predefines
> during the 3.4 timeframe.

  I didn't notice that this reorganization affects this patch.

> Before that patch, we had that mess with CPP_SPEC which used to set
> all of the __m680x0__ predefines even in the 68040 case, which was
> inappropriate but consistent with previous versions of GCC.

  I thought this patch corrects an inapproriate usage of
  TARGET_68040_ONLY where GCC didn't generate valid 68040 integer
  instructions. Where is the conflicht with the predefines?

  Gunther

Re: [m68k] Fix PR target/13292: -msoft-float seems to corrupt builtin defines

[Gunther Nikl]

On Sat, Jun 12, 2004 at 04:40:11AM +0200, Bernardo Innocenti wrote:
> The -msoft-float option incorrectly removed MASK_68040_ONLY
> in addition to MASK_68881.  This leads to incorrect
> predefines and unwanted degradation of integer code.
> 
> There was just one place where we were using
> TARGET_68040_ONLY to generate a floating-point
> instruction without taking TARGET_68881 into account.

  What about TARGET_FLT_EVAL_METHOD?

  Gunther

Re: [m68k] Fix PR target/13292: -msoft-float seems to corrupt builtin defines

[Bernardo Innocenti]

Gunther Nikl wrote:
> On Tue, Jun 15, 2004 at 02:21:34PM +0200, Bernardo Innocenti wrote:
> 
>>Gunther Nikl wrote:
>>
>>>On Sat, Jun 12, 2004 at 04:40:11AM +0200, Bernardo Innocenti wrote:
>>>
>>>
>>>>The -msoft-float option incorrectly removed MASK_68040_ONLY
>>>>in addition to MASK_68881.  This leads to incorrect
>>>>predefines and unwanted degradation of integer code.
>>>>
>>>>There was just one place where we were using
>>>>TARGET_68040_ONLY to generate a floating-point
>>>>instruction without taking TARGET_68881 into account.
>>>>
>>>>Tested on m68k-unknown-uclinux by comparing assembly
>>>>output of some selected testcases from gcc.c-torture.
>>>>
>>>>OK for mainline?  3_4-branch?
>>>
>>> Shouldn't this go to the 3.3 branch as well?
>>
>>I clearly remember posting the patch to reorganize the m68k predefines
>>during the 3.4 timeframe.
> 
>   I didn't notice that this reorganization affects this patch.

[See below]


>>Before that patch, we had that mess with CPP_SPEC which used to set
>>all of the __m680x0__ predefines even in the 68040 case, which was
>>inappropriate but consistent with previous versions of GCC.
> 
> 
>   I thought this patch corrects an inapproriate usage of
>   TARGET_68040_ONLY where GCC didn't generate valid 68040 integer
>   instructions. Where is the conflicht with the predefines?

The patch was primary meant to fix PR13292, which is about
the __m680x0__ (with x=1,2,3) predefines magically appearing
when one specifies -msoft-float along with -m68040.

The problem was caused by -msoft-float removing
MASK_68040_ONLY to be absolutely sure no FP instructions
would be generated.

This would leave target flags with MASK_68040, which
is a superset of MASK_68030 (and hence MASK_68020...).

So I changed -msoft-float to only touch MASK_68881 and
examined the places where (TARGET|MASK)_68040_ONLY were
used to generate FP code.  As turned out, there was only
one such places in m68k.md.

Now -msoft-float is the exact opposite of -m68881, which
is good :)

I vaguely remember you objecting that the new predefines
made it hard to do something useful in math-68881.h.  Is
it still the case with this patch applied?  If so, what
was the original workaround you had suggested?

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: [m68k] Fix PR target/13292: -msoft-float seems to corrupt builtin defines

[Bernardo Innocenti]

Gunther Nikl wrote:
> On Sat, Jun 12, 2004 at 04:40:11AM +0200, Bernardo Innocenti wrote:
> 
>>The -msoft-float option incorrectly removed MASK_68040_ONLY
>>in addition to MASK_68881.  This leads to incorrect
>>predefines and unwanted degradation of integer code.
>>
>>There was just one place where we were using
>>TARGET_68040_ONLY to generate a floating-point
>>instruction without taking TARGET_68881 into account.
> 
>   What about TARGET_FLT_EVAL_METHOD?

Uh?  What would that supposed to do?

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: [m68k] Fix PR target/13292: -msoft-float seems to corrupt builtin defines

[Gunther Nikl]

On Tue, Jun 15, 2004 at 08:30:41PM +0200, Bernardo Innocenti wrote:
> Gunther Nikl wrote:
> >On Sat, Jun 12, 2004 at 04:40:11AM +0200, Bernardo Innocenti wrote:
> >
> >>The -msoft-float option incorrectly removed MASK_68040_ONLY
> >>in addition to MASK_68881.  This leads to incorrect
> >>predefines and unwanted degradation of integer code.
> >>
> >>There was just one place where we were using
> >>TARGET_68040_ONLY to generate a floating-point
> >>instruction without taking TARGET_68881 into account.
> >
> >  What about TARGET_FLT_EVAL_METHOD?
> 
> Uh?  What would that supposed to do?

 What do you want to know? All I see is that its used to initialize
 __FLT_EVAL_METHOD__ in c-cppbuiltin.c and it tests TARGET_68040_ONLY.
 The comment in m68k.h talks about fp instructions. Thus I assumed
 this place needs a change too.

 Gunther

Re: [m68k] Fix PR target/13292: -msoft-float seems to corrupt builtin defines

[Gunther Nikl]

On Tue, Jun 15, 2004 at 07:46:27PM +0200, Bernardo Innocenti wrote:
> Gunther Nikl wrote:
> >On Tue, Jun 15, 2004 at 02:21:34PM +0200, Bernardo Innocenti wrote:
> >
> >>Gunther Nikl wrote:
> >>
> >>>On Sat, Jun 12, 2004 at 04:40:11AM +0200, Bernardo Innocenti wrote:
> >>>
> >>>
> >>>>The -msoft-float option incorrectly removed MASK_68040_ONLY
> >>>>in addition to MASK_68881.  This leads to incorrect
> >>>>predefines and unwanted degradation of integer code.
> >>>>
> >>>>There was just one place where we were using
> >>>>TARGET_68040_ONLY to generate a floating-point
> >>>>instruction without taking TARGET_68881 into account.
> >>>>
> >>>>Tested on m68k-unknown-uclinux by comparing assembly
> >>>>output of some selected testcases from gcc.c-torture.
> >>>>
> >>>>OK for mainline?  3_4-branch?
> >>>
> >>>Shouldn't this go to the 3.3 branch as well?
> >>
> >>I clearly remember posting the patch to reorganize the m68k predefines
> >>during the 3.4 timeframe.
> >
> >  I didn't notice that this reorganization affects this patch.
> 
> [See below]
> 
> >>Before that patch, we had that mess with CPP_SPEC which used to set
> >>all of the __m680x0__ predefines even in the 68040 case, which was
> >>inappropriate but consistent with previous versions of GCC.
> >
> >
> >  I thought this patch corrects an inapproriate usage of
> >  TARGET_68040_ONLY where GCC didn't generate valid 68040 integer
> >  instructions. Where is the conflicht with the predefines?
> 
> The patch was primary meant to fix PR13292, which is about
> the __m680x0__ (with x=1,2,3) predefines magically appearing
> when one specifies -msoft-float along with -m68040.

  Ah ok. Since on 3.3+ most (all?) targets still uses CPP_SPEC and friends
  this problem isn't there. With the AmigaOS port the effect is slightly
  different because the port uses TARGET_CPU_CPP_BUILTINS since 3.3 and it
  doesn't handle -m68020-[46]0 the way its done in 3.4/mainline. In my
  case -m680[46]0 -msoft-float defines mc68020.

> I vaguely remember you objecting that the new predefines made it hard
> to do something useful in math-68881.h. Is it still the case with this
> patch applied?

  I think so because math-68881.h is conditionalized on HAVE_68881 which
  is defined by -m680[46]0.

> If so, what was the original workaround you had suggested?

  I decided to keep the definizion of HAVE_68881 in CPP_SPEC. This has
  other problems :-/

  Gunther

Re: [m68k] Fix PR target/13292: -msoft-float seems to corrupt builtin defines

[Bernardo Innocenti]

Gunther Nikl wrote:
> On Tue, Jun 15, 2004 at 08:30:41PM +0200, Bernardo Innocenti wrote:
>>Gunther Nikl wrote:
>>>
>>> What about TARGET_FLT_EVAL_METHOD?
>>
>>Uh?  What would that supposed to do?
> 
>  What do you want to know? All I see is that its used to initialize
>  __FLT_EVAL_METHOD__ in c-cppbuiltin.c and it tests TARGET_68040_ONLY.
>  The comment in m68k.h talks about fp instructions. Thus I assumed
>  this place needs a change too.

Good catch.  I didn't see that on my previous search.
From what I see in c-cppbuiltin.c, it's only used to
set the __FLT_EVAL_METHOD__ predefine.  This definition
appears in float.h to set FLT_EVAL_METHOD for use by
the standard system headers.  Curiously, glibc's
headers don't ever do anything with it.

My guess is that we don't need to care about this
for -msoft-float.  Whatever was the intended use
of this macro, hardware floating-point instructions
would use whatever precision has been set in the
FPU control register, and fp emulation routines
called by compiler-generated code have no way to
see the definition.

I just wonder who's using this stuff.  Perhaps it's
just something mandated by C99 and not yet fully
implemented in glibc.

rth certainly knows something about it :-)


2002-09-03  Richard Henderson  <rth@redhat.com>

        * Makefile.in (USER_H): Add ginclude/float.h.
        (FLOAT_H): Remove.
        (stmp-int-hdrs, install-mkheaders): Don't handle FLOAT_H.
        (mostlyclean): Don't remove float.h intermediate files.
        (distclean): Don't remove float.h.
        * config.gcc: Remove all float_format references.
        * configure.in (float_format, float_h_file): Remove.

        * c-common.c: Include tree-inline.h.
        (builtin_define_with_int_value): New.
        (builtin_define_type_precision): Use it.
        (builtin_define_float_constants): New.
        (cb_register_builtins): Use it.  Define __FLT_RADIX__ and
        __FLT_EVAL_METHOD__.
        * defaults.h (TARGET_FLT_EVAL_METHOD): New.
        * config/i386/i386.h (TARGET_FLT_EVAL_METHOD): New.
        * config/m68k/m68k.h (TARGET_FLT_EVAL_METHOD): New.
        * doc/tm.texi (INTEL_EXTENDED_IEEE_FORMAT): Mention moto 96-bit format.
        (TARGET_FLT_EVAL_METHOD): New.

        * config/float-c4x.h, config/float-i128.h, config/float-i32.h,
        config/float-i386.h, config/float-i64.h, config/float-m68k.h,
        config/float-sh.h, config/float-sparc.h, config/float-vax.h: Remove.
        * ginclude/float.h: New.


-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: [m68k] Fix PR target/13292: -msoft-float seems to corrupt builtin defines

[Richard Henderson]

On Wed, Jun 16, 2004 at 08:51:43PM +0200, Bernardo Innocenti wrote:
> I just wonder who's using this stuff.  Perhaps it's
> just something mandated by C99 and not yet fully
> implemented in glibc.

Glibc has nothing to do with it.  FLT_EVAL_METHOD is something
c99 gives to the user.  If you're doing normal soft-float, the
setting should be zero.


r~

Re: [m68k] Fix PR target/13292: -msoft-float seems to corrupt builtin defines

[Joseph S. Myers]

On Wed, 16 Jun 2004, Bernardo Innocenti wrote:

> I just wonder who's using this stuff.  Perhaps it's
> just something mandated by C99 and not yet fully
> implemented in glibc.

glibc is much nearer implementing C99 than GCC.  The problems that I know
of are all documented in glibc's CONFORMANCE file
<http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/libc/CONFORMANCE?rev=1.10&content-type=text/plain&cvsroot=glibc>
(some need compiler support to fix, some don't).  But in this case,
<float.h> is a header required of freestanding implementations, so GCC
provides it rather than glibc.  If the documentation explaining
freestanding and hosted implementations and environments in standards.texi
is insufficiently clear, please say how it can be improved.  (A C++ expert
writing the missing corresponding information about C++ standards and
GCC's support for them would be nice.)

-- 
Joseph S. Myers
jsm@polyomino.org.uk

Re: [m68k] Fix PR target/13292: -msoft-float seems to corrupt builtin defines

[Bernardo Innocenti]

Richard Henderson wrote:
> On Wed, Jun 16, 2004 at 08:51:43PM +0200, Bernardo Innocenti wrote:
> 
>>I just wonder who's using this stuff.  Perhaps it's
>>just something mandated by C99 and not yet fully
>>implemented in glibc.
> 
> 
> Glibc has nothing to do with it.  FLT_EVAL_METHOD is something
> c99 gives to the user.  If you're doing normal soft-float, the
> setting should be zero.

Always?  Currently, it would be 2 except with -m68040:

 #define TARGET_FLT_EVAL_METHOD (TARGET_68040_ONLY ? 0 : 2)

Should I change it like this in my original patch
(or perhaps in a followup patch)?


2004-06-12  Bernardo Innocenti  <bernie@develer.com>

	PR target/13292
	* config/m68k/m68k.h (TARGET_SWITCHES): Don't remove MASK_68040_ONLY
	on -msoft-float.
	(TARGET_FLT_EVAL_METHOD): Don't advertise extended precision for
	68040 and soft-float.
	* config/m68k/m68k.md (truncdfsf2): Explicitly require TARGET_68881
	in the TARGET_68040_ONLY case.


Index: gcc/config/m68k/m68k.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/m68k/m68k.h,v
retrieving revision 1.114
diff -u -p -r1.114 m68k.h
--- gcc/config/m68k/m68k.h	5 Jun 2004 06:49:00 -0000	1.114
+++ gcc/config/m68k/m68k.h	16 Jun 2004 21:27:55 -0000
@@ -257,7 +257,7 @@ extern int target_flags;
     { "noshort", - MASK_SHORT,						\
       N_("Consider type `int' to be 32 bits wide") },			\
     { "68881", MASK_68881, "" },					\
-    { "soft-float", - (MASK_68040_ONLY|MASK_68881),			\
+    { "soft-float", - MASK_68881,					\
       N_("Generate code with library calls for floating point") },	\
     { "68020-40", -(MASK_ALL_CF_BITS|MASK_68060|MASK_68040_ONLY),	\
       N_("Generate code for a 68040, without any new instructions") },	\
@@ -355,7 +355,7 @@ extern int target_flags;
 /* target machine storage layout */
 
 #define LONG_DOUBLE_TYPE_SIZE 96
-#define TARGET_FLT_EVAL_METHOD (TARGET_68040_ONLY ? 0 : 2)
+#define TARGET_FLT_EVAL_METHOD ((TARGET_68040_ONLY || ! TARGET_68881) ? 0 : 2)
 
 #define BITS_BIG_ENDIAN 1
 #define BYTES_BIG_ENDIAN 1
Index: gcc/config/m68k/m68k.md
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/m68k/m68k.md,v
retrieving revision 1.76
diff -u -p -r1.76 m68k.md
--- gcc/config/m68k/m68k.md	29 May 2004 15:10:41 -0000	1.76
+++ gcc/config/m68k/m68k.md	16 Jun 2004 21:28:02 -0000
@@ -1498,7 +1498,7 @@
   [(set (match_operand:SF 0 "nonimmediate_operand" "=f")
 	(float_truncate:SF
 	  (match_operand:DF 1 "general_operand" "fmG")))]
-  "TARGET_68040_ONLY"
+  "TARGET_68881 && TARGET_68040_ONLY"
 {
   if (FP_REG_P (operands[1]))
     return "f%$move%.x %1,%0";


-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: [m68k] Fix PR target/13292: -msoft-float seems to corrupt builtin defines

[Richard Henderson]

On Wed, Jun 16, 2004 at 11:35:28PM +0200, Bernardo Innocenti wrote:
> -#define TARGET_FLT_EVAL_METHOD (TARGET_68040_ONLY ? 0 : 2)
> +#define TARGET_FLT_EVAL_METHOD ((TARGET_68040_ONLY || ! TARGET_68881) ? 0 
> : 2)

This definition is fine.


r~

Re: [m68k] Fix PR target/13292: -msoft-float seems to corrupt builtin defines

[Bernardo Innocenti]

Richard Henderson wrote:
> On Wed, Jun 16, 2004 at 11:35:28PM +0200, Bernardo Innocenti wrote:
> 
>>-#define TARGET_FLT_EVAL_METHOD (TARGET_68040_ONLY ? 0 : 2)
>>+#define TARGET_FLT_EVAL_METHOD ((TARGET_68040_ONLY || ! TARGET_68881) ? 0 
>>: 2)
> 
> 
> This definition is fine.

I take it for an approval of the whole patch, thus
I'm committing it to mainline and 3_4-branch (as
approved by Mark earlier).


PS: I guess I'm very, *very* tired :-)

 $ gcc commit gcc/config/m68k/m68k.h gcc/config/m68k/m68k.md
 gcc: commit: No such file or directory
 $ gcc commit gcc/config/m68k/m68k.h gcc/config/m68k/m68k.md gcc/ChangeLog
 gcc: commit: No such file or directory
 $ cvs gcc commit gcc/config/m68k/m68k.h gcc/config/m68k/m68k.md gcc/ChangeLog
 Unknown command: `gcc'
 [...]
 $ cvs commit gcc/config/m68k/m68k.h gcc/config/m68k/m68k.md gcc/ChangeLog
 cvs commit: [22:10:06] waiting for anoncvs's lock in /cvs/gcc/gcc/gcc
 cvs commit: [22:10:36] obtained lock in /cvs/gcc/gcc/gcc
 Checking in gcc/config/m68k/m68k.h;
 /cvs/gcc/gcc/gcc/config/m68k/m68k.h,v  <--  m68k.h
 new revision: 1.115; previous revision: 1.114
 done
 Checking in gcc/config/m68k/m68k.md;
 /cvs/gcc/gcc/gcc/config/m68k/m68k.md,v  <--  m68k.md
 new revision: 1.78; previous revision: 1.77
 done
 Checking in gcc/ChangeLog;
 /cvs/gcc/gcc/gcc/ChangeLog,v  <--  ChangeLog
 new revision: 2.4003; previous revision: 2.4002
 done

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: [m68k] Fix PR target/13292: -msoft-float seems to corrupt builtin defines

[Bernardo Innocenti]

Joseph S. Myers wrote:
> On Wed, 16 Jun 2004, Bernardo Innocenti wrote:
> 
> 
>>I just wonder who's using this stuff.  Perhaps it's
>>just something mandated by C99 and not yet fully
>>implemented in glibc.
> 
> glibc is much nearer implementing C99 than GCC.  The problems that I know
> of are all documented in glibc's CONFORMANCE file
> <http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/libc/CONFORMANCE?rev=1.10&content-type=text/plain&cvsroot=glibc>
> (some need compiler support to fix, some don't).  But in this case,
> <float.h> is a header required of freestanding implementations, so GCC
> provides it rather than glibc.  If the documentation explaining
> freestanding and hosted implementations and environments in standards.texi
> is insufficiently clear, please say how it can be improved.  (A C++ expert
> writing the missing corresponding information about C++ standards and
> GCC's support for them would be nice.)

I had the (wrong) impression that FLT_EVAL_METHOD was meant
to be used in the C support library to switch between different
implementations of fp support functions.

Since there were no users of that symbol in any glibc headers,
I concluded that it was probably unimplemented.

RTH clarified this by explaining that FLT_EVAL_METHOD
is for use by client applications (hence the lack of
leading underscores ;-).

So our documentation in standards.texi is OK.  Is the C99
standard available in electronic form?

[of course not... why would an ISO standard be freely
available for reference by developers trying to use or
even implement it? <grin>]

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: [m68k] Fix PR target/13292: -msoft-float seems to corrupt builtin defines

[Joseph S. Myers]

On Thu, 17 Jun 2004, Bernardo Innocenti wrote:

> So our documentation in standards.texi is OK.  Is the C99
> standard available in electronic form?
> 
> [of course not... why would an ISO standard be freely
> available for reference by developers trying to use or
> even implement it? <grin>]

You mean <http://www.nirvani.net/docs/ansi_c.pdf>?  (URL from libc-alpha
in January; I have no information as to whether this distribution is
authorised under a licence from ISO, IEC or a National Body; note that
this does not include TC1, unlike the printed book from Wiley which solved
the problem of the printed standard previously being very expensive (and
at least some cheaper electronic copies having many strings attached about
paying ANSI's legal fees), but ISO or IEC will provide the official PDF of
TC1 free of charge on request.)  Acquiring the proper four documents of
the old standard (C90, TC1, TC2 and AMD1) in any form may be more
difficult (given the doubts over quite what the version of C90 BSI are
selling is, but that it reportedly doesn't include AMD1 in any form), but
when it was available before C99 came out it also was very expensive.

When BSI surveyed panel members about how BSI could help their standards
development I asked them to license free distribution of ISO 9899 but
they've shown no sign of doing so.

-- 
Joseph S. Myers
jsm@polyomino.org.uk

Re: [m68k] Fix PR target/13292: -msoft-float seems to corrupt builtin defines

[Richard Henderson]

On Thu, Jun 17, 2004 at 12:34:35AM +0200, Bernardo Innocenti wrote:
> So our documentation in standards.texi is OK.  Is the C99
> standard available in electronic form?

No, but C99 is a quite reasonable $18 or so in pdf format from ISO.
Unlike C90, which was like $130.


r~

Re: [m68k] Fix PR target/13292: -msoft-float seems to corrupt builtin defines

[Bernardo Innocenti]

Joseph S. Myers wrote:
> On Thu, 17 Jun 2004, Bernardo Innocenti wrote:
> 
> You mean <http://www.nirvani.net/docs/ansi_c.pdf>?  (URL from libc-alpha
> in January; I have no information as to whether this distribution is
> authorised under a licence from ISO, IEC or a National Body;

Thank you, I've downloaded it.  I'll make sure to destroy all copies
in case I get a cease & desist from ISO ;-)

> <snip>

> When BSI surveyed panel members about how BSI could help their standards
> development I asked them to license free distribution of ISO 9899 but
> they've shown no sign of doing so.

Thank your for your good will.  I wonder whether they noticed that all
standards by W3C, IEFT and ECMA are published on their sites and
freely available to anybody.

<flame-bait>Is it time to fork C and C++ standardization?</flame-bait>

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/