[Bug gold/20642] internal error in get_section_contents, at icf.cc:467 with --icf=safe

[Marco.Leise at gmx dot de]

https://sourceware.org/bugzilla/show_bug.cgi?id=20642

--- Comment #13 from Marco Leise <Marco.Leise at gmx dot de> ---
(In reply to Cary Coutant from comment #12)
> Here's a disassembly of the first part of the function in section 150:
> 
> Disassembly of section
> .text._D3std8encoding__T6decodeTAxEQBbQBa10Latin2CharZQBeFNaNbNiNfKQBjZw:
> [...]
> 
> (Side question: where does this name mangling scheme come from? It's not the
> standard C++ scheme.)

That is Dlang mangling and means "pure nothrow @nogc @safe dchar
std.encoding.decode!(const(std.encoding.Latin2Char)[]).decode(ref
const(std.encoding.Latin2Char)[])", which is an instance of this
generic/template function:
https://github.com/ldc-developers/phobos/blob/91ebe89f3e7fc96594afa84c53f93d3bfcb5be6e/std/encoding.d#L1961
instanced with this type (basically a #typedef ubyte):
https://github.com/ldc-developers/phobos/blob/91ebe89f3e7fc96594afa84c53f93d3bfcb5be6e/std/encoding.d#L957

It boils down to reading a character 'c' off the string and then translating it
through a lookup table to a UTF-16 code point:

    private static immutable dchar m_charMapStart = 0xa1;
    private static immutable dchar m_charMapEnd = 0xff;

    private immutable wstring charMap =
        "\u0104\u02D8\u0141\u00A4\u013D\u015A\u00A7\u00A8"~
        "\u0160\u015E\u0164\u0179\u00AD\u017D\u017B\u00B0"~
        "\u0105\u02DB\u0142\u00B4\u013E\u015B\u02C7\u00B8"~
        "\u0161\u015F\u0165\u017A\u02DD\u017E\u017C\u0154"~
        "\u00C1\u00C2\u0102\u00C4\u0139\u0106\u00C7\u010C"~
        "\u00C9\u0118\u00CB\u011A\u00CD\u00CE\u010E\u0110"~
        "\u0143\u0147\u00D3\u00D4\u0150\u00D6\u00D7\u0158"~
        "\u016E\u00DA\u0170\u00DC\u00DD\u0162\u00DF\u0155"~
        "\u00E1\u00E2\u0103\u00E4\u013A\u0107\u00E7\u010D"~
        "\u00E9\u0119\u00EB\u011B\u00ED\u00EE\u010F\u0111"~
        "\u0144\u0148\u00F3\u00F4\u0151\u00F6\u00F7\u0159"~
        "\u016F\u00FA\u0171\u00FC\u00FD\u0163\u02D9";

    return (c >= m_charMapStart && c <= m_charMapEnd) ?
charMap[c-m_charMapStart] : c;

There is a safety range check in place here. That's where the "cmp   
$0x5e,%ecx" comes from in the assembly before the table 'charMap' is indexed
and the heuristic fails.

-- 
You are receiving this mail because:
You are on the CC list for the bug.