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: 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
--


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