[Bug target/65780] [5/6 Regression] Uninitialized common handling in executables

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

--- Comment #31 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Jeffrey A. Law from comment #29)
> Oh how I wish all this stuff was better documented, both in the GCC sources
> and at a higher level in some linkers/loaders documentation.
> 
> ix86_binds_local_p needs a function comment.  I think with a function
> comment, no comments would be needed in the function body.

Updated.

> I think it's also advisable to get a function comment for the
> default_binds_local* that don't currently have one. 

That can be done in a flow-up patch.

> What I'm trying to wrap my head around is what "defined_locally" really
> means.  Is it a "must" or "maybe" property when it gets set in
> default_binds_local_p_3?
> 
> If it's a must property, then "common_maybe_local" seems mis-named and/or
> mis-used (the former seems most likely to me).
> 
> If it's a maybe property, then why is a common uninit local filtered out? 
> At this point we don't know if a common uninit local will be defined locally
> or not, so it's a maybe.
> 
> I can probably go forward with an approval or specific change
> recommendations that would lead to approval once someone can tell me if
> defined_locally is a maybe or must property.

A common symbol in PIC will never be local, for any targets, unless
it has hidden/internal visibility.