[Bug target/100354] [9/10/11/12 regression] aarch64: non-deligitimized UNSPEC UNSPEC_TLS (76) found in variable location

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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.