[clang] [llvm] Add DW_ATE_GNU_complex_signed to fix assertion (PR #161695)

[David Blaikie via cfe-commits]

dwblaikie wrote:

> Ah looking in gcc source from whatever version I have lying around that I last built I can see this -
> 
> ```
>       /* Dwarf2 doesn't know anything about complex ints, so use
> 	 a user defined type for it.  */
>     case COMPLEX_TYPE:
>       if (SCALAR_FLOAT_TYPE_P (TREE_TYPE (type)))
> 	encoding = DW_ATE_complex_float;
>       else
> 	encoding = DW_ATE_lo_user; //< Orlando: complex int ATE encoding
>       break;
> ```

I mean... I /guess/ some extension has to start at `DW_ATE_lo_user`... (looks like the change dates back to the last millennium: https://gcc.gnu.org/pipermail/gcc-patches/1999-September/018578.html - though looking through the code near there, it seems `DW_ATE_lo_user` was used for a bunch of different cases where there wasn't a standard encoding... so maybe it's more "we give up, look at the name to figure out what this thing is")

(apparently we did get standardized ATEs for these uses approved for DWARFv6 ( https://dwarfstd.org/issues/210218.2.html ) and seems GCC's might've already tentatively added them ( https://inbox.sourceware.org/gcc-bugs/bug-93988-4-fGbPGouz1h@http.gcc.gnu.org%2Fbugzilla%2F/T/ ))

And the LLVM implementation dates back to even before I was working on LLVM... https://github.com/llvm/llvm-project/commit/7b0344f6567bd60527366083b76829053490c4c5 

> I have no context or history as to why both GCC and Clang are using "raw" `DW_ATE_lo_user` for this. I'm happy to leave it as `DW_ATE_lo_user`, I just thought naming it made sense while fixing the assertion. If we don't name it, maybe a better fix is to not check encodings between lo_ and hi_user in the assert? wdyt?

Oh, llvm-dwarfdump/libDebugInfoDWARF asserts if it doesn't recognize an enumerator in a DWARF enumeration (or specifically in the DW_ATE enumeration)? Yeah, that seems wrong in general - we'll always be behind some other implementations extension usage, etc - and being able to dump unknown stuff is important when investigating bugs, cross-toolchain behavior, etc. 

Ideally, I'd guess - we'd dump what we think the extension name is for an enumerator, and failing that (or perhaps in addition) we might print the absolute number, and something like `DW_ATE_lo_user+NNNN` to give a sense of where it is in the user extension space)

Given that it looks like this use of lo_user wasn't "here's the first extension, and this value has a specific meaning between GCC and Clang" but maybe more "if you see this value, give up on DW_ATE_* and use the name instead" (judging by GCC's use of it for a variety of fallback cases in nearby code, if I'm reading it correctly) - maybe best to not add an explicit name for it, at least not on this basis.

> (I have no stake in this really, I was just doing some cleaning up / scanning of my inbox as I've been neglecting it a bit, and this looked like an easy fix)

*nod* appreciate the looking, for sure

https://github.com/llvm/llvm-project/pull/161695