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] don't presume undelegitimized UNSPEC_TLS SYMBOL_REF is a decl


ping?

On Wed, Jun 6, 2012 at 2:04 PM, Roland McGrath <mcgrathr@google.com> wrote:
> cf this change:
>
> ? ? ? ?2010-11-19 ?Jakub Jelinek ?<jakub@redhat.com>
>
> ? ? ? ? ? ? ? ?PR target/45870
> ? ? ? ? ? ? ? ?* dwarf2out.c (const_ok_for_output_1): Don't complain about
> ? ? ? ? ? ? ? ?non-delegitimized TLS UNSPECs.
>
> This case hit me where the rtx was:
>
> ? ? ? ?(unspec:SI [
> ? ? ? ? ? ? ? ?(symbol_ref:SI ("*.LANCHOR0") [flags 0x1aa])
> ? ? ? ? ? ? ? ?(const_int 4 [0x4])
> ? ? ? ? ? ?] UNSPEC_TLS)
>
> Note:
> 1. The UNSPEC has two operands, not one.
> 2. The SYMBOL_REF does not correspond to any decl.
>
> This corresponds to this ARM code:
>
> ? ? ? ? ? ? ? ?ldr ? ? r3, .L10+4
> ? ? ? ?...
> ? ? ? ?.L10:
> ? ? ? ? ? ? ? ?<something else>
> ? ? ? ? ? ? ? ?.word ? .LANCHOR0(tpoff)
> ? ? ? ?...
> ? ? ? ? ? ? ? ?.section ? ? ? ?.tdata,"awT",%progbits
> ? ? ? ? ? ? ? ?.align ?4
> ? ? ? ?.LANCHOR0 = . + 0
> ? ? ? ? ? ? ? ?.type ? tdata1, %object
> ? ? ? ? ? ? ? ?.size ? tdata1, 4
> ? ? ? ?tdata1:
> ? ? ? ? ? ? ? ?.word ? 1
>
> The only way I know to reproduce this is using a variant ARM target that
> I'm still developing and is not yet ready to be submitted, so I don't have
> a proper test case to offer. ?But I think the principle of the following
> change is fairly sound.
>
> What do you think? ?(Recall that I am not a GCC committer, so if you like
> the change, please commit it for me.)
>
>
> Thanks,
> Roland
>
>
> 2012-06-06 ?Roland McGrath ?<mcgrathr@google.com>
>
> ? ? ? ?* dwarf2out.c (const_ok_for_output_1): Detect a TLS UNSPEC using
> ? ? ? ?SYMBOL_REF_TLS_MODEL rather than DECL_THREAD_LOCAL_P, in case it's
> ? ? ? ?not a VAR_DECL. ?Also don't limit it to UNSPECs with exactly one
> ? ? ? ?operand.
>
> diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
> index 6e4ab76..bc68205 100644
> --- a/gcc/dwarf2out.c
> +++ b/gcc/dwarf2out.c
> @@ -10129,12 +10129,12 @@ const_ok_for_output_1 (rtx *rtlp, void *data ATTRIBUTE_UNUSED)
> ? ? ? ? we can't express it in the debug info. ?*/
> ?#ifdef ENABLE_CHECKING
> ? ? ? /* Don't complain about TLS UNSPECs, those are just too hard to
> - ? ? ? ?delegitimize. ?*/
> - ? ? ?if (XVECLEN (rtl, 0) != 1
> + ? ? ? ?delegitimize. ?Note this could be a non-decl SYMBOL_REF such as
> + ? ? ? ?one in a constant pool entry, so testing SYMBOL_REF_TLS_MODEL
> + ? ? ? ?rather than DECL_THREAD_LOCAL_P is not just an optimization. ?*/
> + ? ? ?if (XVECLEN (rtl, 0) == 0
> ? ? ? ? ?|| GET_CODE (XVECEXP (rtl, 0, 0)) != SYMBOL_REF
> - ? ? ? ? || SYMBOL_REF_DECL (XVECEXP (rtl, 0, 0)) == NULL
> - ? ? ? ? || TREE_CODE (SYMBOL_REF_DECL (XVECEXP (rtl, 0, 0))) != VAR_DECL
> - ? ? ? ? || !DECL_THREAD_LOCAL_P (SYMBOL_REF_DECL (XVECEXP (rtl, 0, 0))))
> + ? ? ? ? || SYMBOL_REF_TLS_MODEL (XVECEXP (rtl, 0, 0)) == TLS_MODEL_NONE)
> ? ? ? ?inform (current_function_decl
> ? ? ? ? ? ? ? ?? DECL_SOURCE_LOCATION (current_function_decl)
> ? ? ? ? ? ? ? ?: UNKNOWN_LOCATION,


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