This is the mail archive of the
mailing list for the GCC project.
Re: [Call for middle-end reviewer] Oustanding visibility PR 20218
- From: Roger Sayle <roger at eyesopen dot com>
- To: Paolo Carlini <pcarlini at suse dot de>
- Cc: "'gcc-patches at gcc dot gnu dot org'" <gcc-patches at gcc dot gnu dot org>, Michael Matz <matz at suse dot de>, <pluto at agmk dot net>
- Date: Mon, 23 May 2005 14:00:24 -0600 (MDT)
- Subject: Re: [Call for middle-end reviewer] Oustanding visibility PR 20218
On Fri, 20 May 2005, Paolo Carlini wrote:
> 3- Middle-end (middle-end/20218 proper). A patch is available here:
> 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.