[Bug target/65780] [5/6 Regression] Uninitialized common handling in executables
hjl.tools at gmail dot com
gcc-bugzilla@gcc.gnu.org
Thu Apr 16 11:46:00 GMT 2015
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #18 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Jakub Jelinek from comment #10)
> (In reply to H.J. Lu from comment #9)
> > Created attachment 35327 [details]
> > A different patch
> >
> > On x86, this issue only shows up with PIE. Here is a different
> > patch to treat common symbol defined locally only if the backend
> > passes true common_maybe_local. For x86-64, it is true only if
> > HAVE_LD_PIE_COPYRELOC is 1. For i386, it is always false. If
> > we aren't building PIE, common_maybe_local is true or false
> > doesn't make a difference for x86 since the common symbol is
> > always referenced normally with copy reloc. For PIE on x86-64,
> > common symbol is local only if HAVE_LD_PIE_COPYRELOC is 1.
>
> +
> + /* For common symbol, it is defined locally only if common_maybe_local
> + is true. */
> + bool defined_locally = (!DECL_EXTERNAL (exp)
> + && (!DECL_COMMON (exp) || common_maybe_local));
>
> I think better would be:
> bool uninited_common = (DECL_COMMON (exp)
> && (DECL_INITIAL (exp) == NULL
> || (!in_lto_p && DECL_INITIAL (exp) ==
> error_mark_node)));
> /* For common symbol, it is defined locally only if common_maybe_local
> is true. */
> bool defined_locally = (!DECL_EXTERNAL (exp) && (!uninited_common ||
> common_maybe_local));
> ...
> and then use
> /* Uninitialized COMMON variable may be unified with symbols
> resolved from other modules. */
> if (uninited_common && !resolved_locally)
> return false;
Here is a testcase:
---
int optopt = 5;
int optopt;
int
main ()
{
optopt = 4;
return 0;
}
----
~
More information about the Gcc-bugs
mailing list