<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in types-integer-old.ll</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>f6a561c4 - DebugInfo: Use clang&apos;s preferred names for integer types</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/DebugInfo/COFF/types-integer-old.ll#f6a561c4</link>
        <description>DebugInfo: Use clang&apos;s preferred names for integer typesThis reverts c7f16ab3e3f27d944db72908c9c1b1b7366f5515 / r109694 - whichsuggested this was done to improve consistency with the gdb test suite.Possible that at the time GCC did not canonicalize integer types, and somatching types was important for cross-compiler validity, or that it wasonly a case of over-constrained test cases that printed out/tested theexact names of integer types.In any case neither issue seems to exist today based on my limitedtesting - both gdb and lldb canonicalize integer types (in a way thathappens to match Clang&apos;s preferred naming, incidentally) and so neverprint the original text name produced in the DWARF by GCC or Clang.This canonicalization appears to be in `integer_types_same_name_p` forGDB and in `TypeSystemClang::GetBasicTypeEnumeration` for lldb.(I tested this with one translation unit defining 3 variables - `long`,`long (*)()`, and `int (*)()`, and another translation unit that hadmain, and a function that took `long (*)()` as a parameter - thencompiled them with mismatched compilers (either GCC+Clang, orClang+(Clang with this patch applied)) and no matter the combination,despite the debug info for one CU naming the type &quot;long int&quot; and theother naming it &quot;long&quot;, both debuggers printed out the name as &quot;long&quot;and were able to correctly perform overload resolution and pass the`long int (*)()` variable to the `long (*)()` function parameter)Did find one hiccup, identified by the lldb test suite - that CodeViewwas relying on these names to map them to builtin types in that format.So added some handling for that in LLVM. (these could be split out intoseparate patches, but seems small enough to not warrant it - will dothat if there ends up needing any reverti/revisiting)Differential Revision: https://reviews.llvm.org/D110455

            List of files:
            /llvm-project-15.0.7/llvm/test/DebugInfo/COFF/types-integer-old.ll</description>
        <pubDate>Fri, 24 Sep 2021 23:13:07 +0000</pubDate>
        <dc:creator>David Blaikie &lt;dblaikie@gmail.com&gt;</dc:creator>
    </item>
</channel>
</rss>
