Re: [PATCH] Fix PR41357

[Richard Guenther <richard dot guenther at gmail dot com>]

On Wed, Sep 16, 2009 at 9:34 AM, Dave Korn
<dave.korn.cygwin@googlemail.com> wrote:
>
> ? ?Hi all,
>
> ?PR41357 is a bootstrap failure in libgomp. ?There are undefined references
> to the untransformed names of TLS emulation variables making their way into
> the debug info, and this turns out to be because the thread-local status of
> the decl is never reflected in the thread-local type bits of the derived
> sym_ref's flags. ?This ends up confusing the debug info generation, which
> thinks that since the var is not thread-local it can predict the var's
> constant value from the DECL_INITIAL.
>
> ?The obvious-seeming fix would be for default_encode_section_info to set
> TLS_MODEL_EMULATED on sym_refs when the decl is thread-local and the backend
> doesn't have_tls. ?This certainly resolves the testcase and fixes bootstrap
> with libgomp enabled on i686-pc-cygwin. ?I'm now bootstrapping and testing it
> on i686-pc-linux-gnu as well (since it takes several days for a full testsuite
> run on cygwin).
>
> ?I'm not sure if I remember right, but isn't there a convention that we often
> don't worry about adding testcases for bootstrap failures because the compiler
> source itself acts as the testcase? ?Otherwise there's a fairly reduced
> testcase in the PR that I could add as a compile test; please advise.
>
> gcc/ChangeLog:
>
> ? ? ? ?* varasm.c (default_encode_section_info): Set SYMBOL_REF_TLS_MODEL
> ? ? ? ?even for emulated tls.
>
> ?If there are no regressions, OK for HEAD?

Isn't it enough to remove the targetm.have_tls check?  Thus, DECL_TLS_MODEL
should already be TLS_MODEL_EMULATED, no?

Thanks,
Richard.

> ? ?cheers,
> ? ? ?DaveK
>