[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

["dave at hiauly1 dot hia dot nrc dot ca" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #68 from dave at hiauly1 dot hia dot nrc dot ca  2008-08-30 02:48 -------
Subject: Re:  [4.4 Regression]: gcc.dg/weak/weak-1.c

> > If the encoding for function names is getting stripped, then
> > ASM_OUTPUT_EXTERNAL_REAL will fail to type the symbol correctly.
> 
> Not sure what you meant by that comment; that's not what happens here AFAICT.
> I stated that output_operand does not see the same symbol_ref as was passed to
> the rtl insn expander, so target-specific code is needed just like for Darwin
> - or maybe it's just missing in generic code, for the constant pool.

I believe that the only special aspect of symbol_ref processing on the
32-bit hppa port is the symbol name encoding.  There's also some flag
bits.  Other than that, it's not clear why output_operand would see
something different from what was passed to the rtl insn expander.

There's nothing new in the hppa backend wrt symbol references.

Besides the .import issue, function pointers have to point to a
function descriptor (not the real code).  This is done using a plabel
which is a relocation which tells the linker to create a pointer to
a function descriptor.  This happens automatically if the output for
the function pointer output uses assembler_integer (assuming the name
encoding is correct).

Because the output of .import directives is a two stage process, there
might be an issue if a symbol_ref was garbage collected after the
assemble_external call.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170