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] Fix ICE in categorize_decl_for_section with TLS decl (PR middle-end/82095)


On 09/05/2017 03:16 PM, Jakub Jelinek wrote:
> Hi!
> 
> If a DECL_THREAD_LOCAL_P decl has NULL DECL_INITIAL and
> -fzero-initialized-in-bss (the default), we ICE starting with
> r251602, which changed bss_initializer_p:
> +  /* Do not put constants into the .bss section, they belong in a readonly
> +     section.  */
> +  return (!TREE_READONLY (decl)
> +	  &&
> to:
>           (DECL_INITIAL (decl) == NULL
>               /* In LTO we have no errors in program; error_mark_node is used
>                  to mark offlined constructors.  */
>               || (DECL_INITIAL (decl) == error_mark_node
>                   && !in_lto_p)
>               || (flag_zero_initialized_in_bss
>                   && initializer_zerop (DECL_INITIAL (decl))))
> Previously because bss_initializer_p for these returned true, ret was
> SECCAT_BSS and therefore we set it to SECCAT_TBSS as intended, but now ret
> is not SECCAT_BSS, but as TLS has only tbss and tdata possibilities, we
> still want to use tbss.  DECL_INITIAL NULL for a decl means implicit zero
> initialization.
> 
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?
> 
> 2017-09-05  Jakub Jelinek  <jakub@redhat.com>
> 
> 	PR middle-end/82095
> 	* varasm.c (categorize_decl_for_section): Use SECCAT_TBSS for TLS vars with
> 	NULL DECL_INITIAL.
> 
> 	* gcc.dg/tls/pr82095.c: New test.
THanks.  Sorry about the breakage.  TLS didn't even cross my mind.
Presumably the TLS initialization sections are readonly and copied into
the actual thread specific locations.

Jeff


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