[pushed] Remove some obsolete comments

[pushed] Remove some obsolete comments

[Tom Tromey]

While working on complex number support, I found a couple of
apparently obsolete coments.  This removes them.

2020-03-07  Tom Tromey  <tom@tromey.com>

	* valops.c (value_literal_complex): Remove obsolete comment.
	* gdbtypes.h (enum type_code) <TYPE_CODE_FLT>: Remove obsolete
	comment.
---
 gdb/ChangeLog  | 6 ++++++
 gdb/gdbtypes.h | 4 +---
 gdb/valops.c   | 4 +---
 3 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/gdb/gdbtypes.h b/gdb/gdbtypes.h
index 74498435822..cb674dbc1e8 100644
--- a/gdb/gdbtypes.h
+++ b/gdb/gdbtypes.h
@@ -120,9 +120,7 @@ enum type_code
     TYPE_CODE_FUNC,		/**< Function type */
     TYPE_CODE_INT,		/**< Integer type */
 
-    /* * Floating type.  This is *NOT* a complex type.  Beware, there
-       are parts of GDB which bogusly assume that TYPE_CODE_FLT can
-       mean complex.  */
+    /* * Floating type.  This is *NOT* a complex type.  */
     TYPE_CODE_FLT,
 
     /* * Void type.  The length field specifies the length (probably
diff --git a/gdb/valops.c b/gdb/valops.c
index 7fc555a8108..d48474665c3 100644
--- a/gdb/valops.c
+++ b/gdb/valops.c
@@ -3856,9 +3856,7 @@ value_slice (struct value *array, int lowbound, int length)
 
 /* Create a value for a FORTRAN complex number.  Currently most of the
    time values are coerced to COMPLEX*16 (i.e. a complex number
-   composed of 2 doubles.  This really should be a smarter routine
-   that figures out precision intelligently as opposed to assuming
-   doubles.  FIXME: fmb  */
+   composed of 2 doubles.  */
 
 struct value *
 value_literal_complex (struct value *arg1, 
-- 
2.17.2

Re: [pushed] Remove some obsolete comments

[Christian Biesinger]

On Sat, Mar 7, 2020 at 9:03 AM Tom Tromey <tom@tromey.com> wrote:
>
> While working on complex number support, I found a couple of
> apparently obsolete coments.  This removes them.
>
> 2020-03-07  Tom Tromey  <tom@tromey.com>
>
>         * valops.c (value_literal_complex): Remove obsolete comment.
>         * gdbtypes.h (enum type_code) <TYPE_CODE_FLT>: Remove obsolete
>         comment.
> ---
>  gdb/ChangeLog  | 6 ++++++
>  gdb/gdbtypes.h | 4 +---
>  gdb/valops.c   | 4 +---
>  3 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/gdb/gdbtypes.h b/gdb/gdbtypes.h
> index 74498435822..cb674dbc1e8 100644
> --- a/gdb/gdbtypes.h
> +++ b/gdb/gdbtypes.h
> @@ -120,9 +120,7 @@ enum type_code
>      TYPE_CODE_FUNC,            /**< Function type */
>      TYPE_CODE_INT,             /**< Integer type */
>
> -    /* * Floating type.  This is *NOT* a complex type.  Beware, there
> -       are parts of GDB which bogusly assume that TYPE_CODE_FLT can
> -       mean complex.  */
> +    /* * Floating type.  This is *NOT* a complex type.  */
>      TYPE_CODE_FLT,
>
>      /* * Void type.  The length field specifies the length (probably
> diff --git a/gdb/valops.c b/gdb/valops.c
> index 7fc555a8108..d48474665c3 100644
> --- a/gdb/valops.c
> +++ b/gdb/valops.c
> @@ -3856,9 +3856,7 @@ value_slice (struct value *array, int lowbound, int length)
>
>  /* Create a value for a FORTRAN complex number.  Currently most of the
>     time values are coerced to COMPLEX*16 (i.e. a complex number
> -   composed of 2 doubles.  This really should be a smarter routine
> -   that figures out precision intelligently as opposed to assuming
> -   doubles.  FIXME: fmb  */
> +   composed of 2 doubles.  */

Is this missing a closing parenthesis?

>
>  struct value *
>  value_literal_complex (struct value *arg1,
> --
> 2.17.2
>

Re: [pushed] Remove some obsolete comments

[Tom Tromey]

>>>>> "Christian" == Christian Biesinger <cbiesinger@google.com> writes:

>> time values are coerced to COMPLEX*16 (i.e. a complex number
>> -   composed of 2 doubles.  This really should be a smarter routine
>> -   that figures out precision intelligently as opposed to assuming
>> -   doubles.  FIXME: fmb  */
>> +   composed of 2 doubles.  */

Christian> Is this missing a closing parenthesis?

Yeah, I didn't notice that.  The comment really needs a rewrite anyway.
And, it could be moved to value.h.  I'll do that soon; I may want to
change this function a bit in another way.

Tom