AIX exception-handling vs. builtin_return_address

[David Edelsohn]

	Even though AIX always is PIC, GCC flag_pic implies the ELF PIC
machinery (elf_high, lo_sum, finalize_pic, etc.).  There was concern about
what enabling flag_pic would influence when AIX worked just fine before
all of that infrastructure was developed.

	As far as __builtin_extract_return_addr(), Franz converted the
rs6000 port to follow the style of the alpha port on January 23.  I am
guessing that he only tested it on PowerPC Linux and not AIX.

	The rs6000.h code was

#define RETURN_ADDR_RTX(count, frame)                   \
  ((count == -1)                                        \
   ? gen_rtx_REG (Pmode, 65)                            \
   : gen_rtx_MEM (Pmode,                                \
              memory_address (Pmode,                    \
                              plus_constant (copy_to_reg (gen_rtx_MEM (Pmode, \
                                                                   memory_address (Pmode, frame))), \
                                             RETURN_ADDRESS_OFFSET))))

When Franz posted the patch, I looked through the calls to
RETURN_ADDR_RTX, but it looks like it only is called with count of 0, 1,
2,... -- not a negative number.

	My first question is whether the count == -1 test ever had any
purpose.  Does GCC use -1 to refer to a function in which a stack frame
was not pushed?

	My second question is whether this macro/function can test
rs6000_info->lr_save_p.  I am guessing that the need to push a frame is
not known at the time this macro is called which is why the macro forces a
stack frame.  If it could know, then it should test whether a frame will
be created instead of testing flag_pic and forcing a frame.

	I think that the best short-term solution is to expand the
rs6000_return_addr() test to:

  if (DEFAULT_ABI == AIX || count != 0 || flag_pic != 0)

As the comment above the test says, "don't try to be too clever here".

David