------- 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 <[EMAIL PROTECTED]> > > 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
