[patch] zap HPPA_COMPILER_BUG and friends

Andrew Cagney ac131313@cygnus.com
Thu Mar 22 16:40:00 GMT 2001


Follow this carefully :-)

GDB compiles with ISO-C compilers
ISO-C compilers define __STDC__
HPPA_COMPILER_BUG is defined when !__STDC__

=> HPPA_COMPILER_BUG is never defined
=> can delete #define HPPA_COMPILER_BUG
=> can delete #ifdef HPPA_COMPILER_BUG

MALLOC_INCOMPATIBLE is similar.

	Andrew
2001-03-22  Andrew Cagney  <ac131313@redhat.com>

	* config/pa/xm-hppah.h (HPPA_COMPILER_BUG): Delete. GDB only
	compiles using an ISO-C compiler.
	(MALLOC_INCOMPATIBLE): Ditto.
	* linespec.c (decode_line_1): Delete hack to work around
	HPPA_COMPILER_BUG.

Index: linespec.c
===================================================================
RCS file: /cvs/src/src/gdb/linespec.c,v
retrieving revision 1.9
diff -p -r1.9 linespec.c
*** linespec.c	2001/03/21 20:51:15	1.9
--- linespec.c	2001/03/23 00:30:27
*************** decode_line_1 (char **argptr, int funfir
*** 459,494 ****
  	       int default_line, char ***canonical)
  {
    struct symtabs_and_lines values;
- #ifdef HPPA_COMPILER_BUG
-   /* FIXME: The native HP 9000/700 compiler has a bug which appears
-      when optimizing this file with target i960-vxworks.  I haven't
-      been able to construct a simple test case.  The problem is that
-      in the second call to SKIP_PROLOGUE below, the compiler somehow
-      does not realize that the statement val = find_pc_line (...) will
-      change the values of the fields of val.  It extracts the elements
-      into registers at the top of the block, and does not update the
-      registers after the call to find_pc_line.  You can check this by
-      inserting a printf at the end of find_pc_line to show what values
-      it is returning for val.pc and val.end and another printf after
-      the call to see what values the function actually got (remember,
-      this is compiling with cc -O, with this patch removed).  You can
-      also examine the assembly listing: search for the second call to
-      skip_prologue; the LDO statement before the next call to
-      find_pc_line loads the address of the structure which
-      find_pc_line will return; if there is a LDW just before the LDO,
-      which fetches an element of the structure, then the compiler
-      still has the bug.
- 
-      Setting val to volatile avoids the problem.  We must undef
-      volatile, because the HPPA native compiler does not define
-      __STDC__, although it does understand volatile, and so volatile
-      will have been defined away in defs.h.  */
- #undef volatile
-   volatile struct symtab_and_line val;
- #define volatile		/*nothing */
- #else
    struct symtab_and_line val;
- #endif
    register char *p, *p1;
    char *q, *pp, *ii, *p2;
  #if 0
--- 459,465 ----
Index: config/pa/xm-hppah.h
===================================================================
RCS file: /cvs/src/src/gdb/config/pa/xm-hppah.h,v
retrieving revision 1.5
diff -p -r1.5 xm-hppah.h
*** xm-hppah.h	2001/03/20 00:54:43	1.5
--- xm-hppah.h	2001/03/23 00:30:27
***************
*** 29,39 ****
  
  #define USG
  
- #ifndef __STDC__
- /* This define is discussed in decode_line_1 in symtab.c  */
- #define HPPA_COMPILER_BUG
- #endif
- 
  #define HAVE_TERMIOS
  
  /* HP defines malloc and realloc as returning void *, even for non-ANSI
--- 29,34 ----


More information about the Gdb-patches mailing list