This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: PR middle-end/20297: #pragma GCC visibility isn't properlyhandled for builtin functions
- From: Roger Sayle <roger at eyesopen dot com>
- To: "H. J. Lu" <hjl at lucon dot org>
- Cc: gcc-patches at gcc dot gnu dot org, <rth at redhat dot com>
- Date: Fri, 4 Mar 2005 11:11:45 -0700 (MST)
- Subject: Re: PATCH: PR middle-end/20297: #pragma GCC visibility isn't properlyhandled for builtin functions
On Fri, 4 Mar 2005, H. J. Lu wrote:
> Do we have a flag to tell build_decl that we aren't in front-end.
> If we do, can we add `default_front_visibility' and
> `visibility_options.front_inpragma'? build_decl can use
> default_front_visibility/visibility_options.front_inpragma in front-end
> and default_visibility/visibility_options.inpragma for others. Callers
> of build_decl should set default_visibility/visibility_options.inpragma
> properly.
"Callers of build_decl should set default_visibility properly"?!
Is this documented above build_decl or did you just make that up?
By my reckoning there are currently just under 400 calls to build_decl
in the CVS tree. Almost all of these calls predate the introduction
of default_visibility in July last year. Expecting these callers to
forsee the requirement to "set visibility_options.inpragma" upto 15
years before that variable was introduced is just crazy talk. My
best guess is that there are probably about ten places total between
all the front-ends, that are responsible for creating the tree's
corresponding to user identifiers.
Keeping with the crazy suggestions, one approach would be to add an
additional "in_front_end" parameter to build_decl, update all 400
callers such that 390 pass false, and the ten? we care about pass
true. A more reasonable suggestion may be to introduce a new function
build_user_decl that is called from the handful of places that require
non-default behaviour. However, my prediction is that the C and C++
front-ends are well structured enough that there are only two or three
places that require special handling, in which case it's as easy to
cut-n-paste, the appropriate two assignments there.
What ever happened to the "common sense" they had when I was a child?
Perhaps I should take a few stupid pills and suggest a new build_decl
language hook, or split from the front-ends and introduce fold_build_decl
for use in language independent code. :-)
I'm currently investigating which are the relevant minimal number of
calls to build_decl in the C-family front-ends to allow us pass all
of the current visibility testsuite, yet still return build_decl to
building "vanilla" tree nodes. Any help/suggestions from the
appropriate maintainers would be much appreciated.
Roger
--