* Makefile.in (symfile.o): Add gdb-stabs.h to dependencies list.

[deliverable/binutils-gdb.git] / gdb / valops.c

diff --git a/gdb/valops.c b/gdb/valops.c
index df1e9ee2bcddf6c4ac7a5a8c7a615aeb335fc0e5..918398493bcc7ad95388ddd7fc700e243bae6979 100644 (file)
--- a/gdb/valops.c
+++ b/gdb/valops.c
@@ -286,8 +286,8 @@ value_cast (struct type *type, register value_ptr arg2)
                                 (LONGEST) (longest ? 1 : 0) : longest);
     }
   else if (code1 == TYPE_CODE_PTR && (code2 == TYPE_CODE_INT  ||
-                                    code2 == TYPE_CODE_ENUM ||
-                                    code2 == TYPE_CODE_RANGE))
+                                     code2 == TYPE_CODE_ENUM ||
+                                     code2 == TYPE_CODE_RANGE))
     {
       int ptr_bit = HOST_CHAR_BIT * TYPE_LENGTH (type);
       LONGEST longest = value_as_long (arg2);
@@ -1249,12 +1249,7 @@ find_function_addr (value_ptr function, struct type **retval_type)
       if (TYPE_CODE (ftype) == TYPE_CODE_FUNC
          || TYPE_CODE (ftype) == TYPE_CODE_METHOD)
        {
-#ifdef CONVERT_FROM_FUNC_PTR_ADDR
-         /* FIXME: This is a workaround for the unusual function
-            pointer representation on the RS/6000, see comment
-            in config/rs6000/tm-rs6000.h  */
          funaddr = CONVERT_FROM_FUNC_PTR_ADDR (funaddr);
-#endif
          value_type = TYPE_TARGET_TYPE (ftype);
        }
       else
@@ -1581,27 +1576,27 @@ You must use a pointer to function type variable. Command ignored.", arg_name);
        }
     }
 
-/* elz: on HPPA no need for this extra alignment, maybe it is needed
-   on other architectures. This is because all the alignment is taken care
-   of in the above code (ifdef REG_STRUCT_HAS_ADDR) and in
-   hppa_push_arguments */
-#ifndef NO_EXTRA_ALIGNMENT_NEEDED
-
-  /* MVS 11/22/96: I think at least some of this stack_align code is
-     really broken.  Better to let PUSH_ARGUMENTS adjust the stack in
-     a target-defined manner.  */
-  if (STACK_ALIGN_P () && INNER_THAN (1, 2))
+  /* elz: on HPPA no need for this extra alignment, maybe it is needed
+     on other architectures. This is because all the alignment is
+     taken care of in the above code (ifdef REG_STRUCT_HAS_ADDR) and
+     in hppa_push_arguments */
+  if (EXTRA_STACK_ALIGNMENT_NEEDED)
     {
-      /* If stack grows down, we must leave a hole at the top. */
-      int len = 0;
-
-      for (i = nargs - 1; i >= 0; i--)
-       len += TYPE_LENGTH (VALUE_ENCLOSING_TYPE (args[i]));
-      if (CALL_DUMMY_STACK_ADJUST_P)
-       len += CALL_DUMMY_STACK_ADJUST;
-      sp -= STACK_ALIGN (len) - len;
+      /* MVS 11/22/96: I think at least some of this stack_align code
+        is really broken.  Better to let PUSH_ARGUMENTS adjust the
+        stack in a target-defined manner.  */
+      if (STACK_ALIGN_P () && INNER_THAN (1, 2))
+       {
+         /* If stack grows down, we must leave a hole at the top. */
+         int len = 0;
+
+         for (i = nargs - 1; i >= 0; i--)
+           len += TYPE_LENGTH (VALUE_ENCLOSING_TYPE (args[i]));
+         if (CALL_DUMMY_STACK_ADJUST_P)
+           len += CALL_DUMMY_STACK_ADJUST;
+         sp -= STACK_ALIGN (len) - len;
+       }
     }
-#endif /* NO_EXTRA_ALIGNMENT_NEEDED */
 
   sp = PUSH_ARGUMENTS (nargs, args, sp, struct_return, struct_addr);
 
@@ -1942,10 +1937,7 @@ value_bitstring (char *ptr, int len)
    requested operation is type secure, shouldn't we?  FIXME.  */
 
 static int
-typecmp (staticp, t1, t2)
-     int staticp;
-     struct type *t1[];
-     value_ptr t2[];
+typecmp (int staticp, struct type *t1[], value_ptr t2[])
 {
   int i;