https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63342
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 33612
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33612&action=edit
gcc5-pr63342.patch
Untested fix. When because of r214899 mem_loc_descriptor (correctly) gives up
(previously we were generating wrong debug info), we retry by trying to
generate debug info from the MEM_EXPR of the MEM, but in this case it contains
a TARGET_MEM_REF which we weren't handling at all.
Perhaps we should just return NULL for TARGET_MEM_REF though, because we can't
do anything for SSA_NAMEs anyway, and I doubt there could be a TARGET_MEM_REF
in MEM_EXPR which would not mention SSA_NAMEs.
The ultimate reason for not generating debug info is that the TLSLD model base
address is precomputed into some register (as it is used multiple times in the
function) and ix86_delegitimize_tls_address can't know which hard register
holds the base address, so the delegitimization fails. In theory we probably
could emit the symbol@DTPOFF into assembly, but as we right now reject all
UNSPECs that weren't successfully delegitimized, we reject it anyway.
