aboutsummaryrefslogtreecommitdiff
path: root/gprof
diff options
context:
space:
mode:
authorIan Lance Taylor <ian@airs.com>1992-10-09 15:49:16 +0000
committerIan Lance Taylor <ian@airs.com>1992-10-09 15:49:16 +0000
commitb5ddc1014c557cb2b69bccc3144c680fb0c81686 (patch)
tree362f7d538e5a24b19d403dcc9fc3a3e377487336 /gprof
parent0e35d2f37e3478fa69b9fc98d115b1d08a731834 (diff)
downloadgdb-b5ddc1014c557cb2b69bccc3144c680fb0c81686.zip
gdb-b5ddc1014c557cb2b69bccc3144c680fb0c81686.tar.gz
gdb-b5ddc1014c557cb2b69bccc3144c680fb0c81686.tar.bz2
Fri Oct 9 08:41:11 1992 Ian Lance Taylor (ian@cygnus.com)
* xm-hppah.h: if __STDC__ is not defined, define HPPA_COMPILER_BUG. symtab.c (decode_line_1): avoid a bug in the HP9000/700 native compiler; see the comment in the file. Here's the comment from the file: /* 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. */
Diffstat (limited to 'gprof')
0 files changed, 0 insertions, 0 deletions