https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100354
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed|2021-04-30 00:00:00 |2022-1-21
Priority|P3 |P2
CC| |jakub at gcc dot gnu.org
Keywords| |diagnostic
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
This is dwarf2out.cc
/* If delegitimize_address couldn't do anything with the UNSPEC, and
the target hook doesn't explicitly allow it in debug info, assume
we can't express it in the debug info. */
/* Don't complain about TLS UNSPECs, those are just too hard to
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 (flag_checking
&& (XVECLEN (rtl, 0) == 0
|| GET_CODE (XVECEXP (rtl, 0, 0)) != SYMBOL_REF
|| SYMBOL_REF_TLS_MODEL (XVECEXP (rtl, 0, 0)) == TLS_MODEL_NONE))
inform (current_function_decl
? DECL_SOURCE_LOCATION (current_function_decl)
: UNKNOWN_LOCATION,
#if NUM_UNSPEC_VALUES > 0
"non-delegitimized UNSPEC %s (%d) found in variable location",
((XINT (rtl, 1) >= 0 && XINT (rtl, 1) < NUM_UNSPEC_VALUES)
? unspec_strings[XINT (rtl, 1)] : "unknown"),
#else
"non-delegitimized UNSPEC %d found in variable location",
#endif
XINT (rtl, 1));
btw, the following expansion_failed () will just dump to a dumpfile,
maybe the above inform was meant to do the same.
Jakub, you added this in g:eb1fcdaa11c571780374065c383708826624f22d - it's
guarded with -fchecking but I think this is the only place in GCC I know
we have actual debug diagnostics this way.
