[Bug c++/19797] [4.0 Regression] g++.dg/abi/inline1.C fails on hppa*-*-hpux*

["joseph at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From joseph at codesourcery dot com  2005-02-13 02:10 -------
Subject: Re:  [4.0 Regression] g++.dg/abi/inline1.C fails on
 hppa*-*-hpux*

On Sun, 13 Feb 2005, danglin at gcc dot gnu dot org wrote:

> 1) In the past, we haven't worried about the presence of unnecessary
>    .IMPORT directives as they are harmless.  There are several places
>    in the testsuite where we work around this problem.

This bug is, however, a regression, and as such should be fixed for 4.0.

> 2) I don't believe that putting this fix in the PA backend is the best
>    fix.  In December, Zack introduced a mechanism to defer emission of
>    assemble externals:
> 
> 2004-12-08  Zack Weinberg  <zack@codesourcery.com>
> 
>         PR 17982
>         * varasm.c (pending_assemble_externals): New static.
>         (assemble_external_real): Meat of assemble_external split out
>         to this new function.
>         (process_pending_assemble_externals): New function.
>         (assemble_external): Use gcc_assert.  If flag_unit_at_a_time
>         is true and the basic test passes, merely cons the decl onto
>         the pending list to be handled later.
>         * tree.h: Declare process_pending_assemble_externals.
>         * cgraphunit.c (cgraph_optimize): Call it.
> 
>    Thus, we are adding a hppa fix on top of an ia64 fix to the main code.

Zack's view was that changing the core code to defer this until the end of 
assembler output for all platforms would be appropriate for 4.1 - but 
fixing in the PA backend, as is done in the IA64 backend, though not an 
ideal place and involving double deferral by both core code and backend, 
makes more sense in the context of fixing a regression for 4.0.

> 3) I'm concerned that the proposed fix requires a linker fix.  There won't
>    be a fix for HP-UX 10 and possibly 11.00.  There's still interest in these
>    system versions for a number of older machines that are still in fairly
>    wide use.  

We don't know whether a linker fix is required for those versions (or 
indeed for 11.11, as when testing I tested the patch for 64-bit 11.11 and 
32-bit 11.23 simultaneously on different systems).  The linker problem 
could just happen to be triggered some combination of circumstances that 
happen to arise for libstdc++ on a particular HP-UX release after this 
patch; or when the linker bug is fixed it could turn out that actually 
there is something wrong with the object files generated (which however 
should never cause the linker to crash), whether because of a bug in this 
patch or a bug in the GNU assembler, either of which can be fixed.  I 
don't know whether GCC mainline does in fact work on those old HP-UX 
versions - I can only test on PA 11.11 and 11.23 and IA64 11.22 and 11.23 
- but there must always be a risk if the GNU tools do not support a system 
well enough and the system tools are no longer maintained that new GCC 
versions will run into bugs with the system tools.

If necessary, with the deferral in the back end it is possible to arrange 
for 11.00 and 10.x to use the old behavior while more recent versions 
expect a linker fix - something not so readily possible with deferral 
until end of output happening unconditionally for all targets in the core 
code.



-- 


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