This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Call for middle-end reviewer] Oustanding visibility PR 20218


Hi Paolo,

On Fri, 20 May 2005, Paolo Carlini wrote:
> 3- Middle-end (middle-end/20218 proper). A patch is available here:
> http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00391.html
>
> Unreviewed to date, but *carefully and extensively tested on many
> arches* by PR submitter together with the other two patches.

Unfortunately, to contradict the above comment, it looks like HJ
has only tested this potentially destablizing patch on Intel
architectures; i386, x86_64 and ia64, and then only under Linux.

Given that the patch touches config/ia64/hpux.h, I initially thought
I'd help out by also testing it on ia64-hp-hpux11.22 (bootstrap and
regression test in progress).

But investigating further it looks like this patch will break every
ELF target backend that currently defines either ASM_OUTPUT_EXTERNAL
or TARGET_ASM_FILE_END, including mips, pa, s390, 68hc11, m68k, sh,
m32r and c4x.  The problem is that elfos.h now uses these two hooks
for its own purposes, so any target that (incompatibly) overrides
these macros will either accumulate symbols without outputing them
or fail to accumulate them and output nothing.

You'll notice that every platform that HJ had tested on required a
compensating back-end change.  It looks like many of the targets
that weren't tested will also require such a change.


I completely agree that this change to track symbol visibility inside
the compiler for elfos.h targets, and then emit the appropriate
directives to the end of the assembly file (as is currently done
for HPUX) is a reasonable/good thing.  Alas, the scale of this
change requires more backend modifications and more testing than
has been done to date.


My sympathies to the libstdc++ folks (who require this for PR19664),
as clearly this change will help resolve their problems.  But it was
perhaps a mistake to refer to it as "*carefully and extensively tested
on many arches*".


We need to figure out a way to either introduce these changes
incrementally or get the patch revised and tested on the affected
backends, possibly with help from their maintainers.

Roger
--


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]