[llvm-bugs] [Bug 29116] New: typeinfo structure badly generated for MinGW-w64/x86_64 makes dynamic_cast<>() fail

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=29116

            Bug ID: 29116
           Summary: typeinfo structure badly generated for
                    MinGW-w64/x86_64 makes dynamic_cast<>() fail
           Product: clang
           Version: 3.8
          Hardware: PC
                OS: Windows XP
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: eric.paire at st.com
                CC: dgregor at apple.com, llvm-bugs at lists.llvm.org
    Classification: Unclassified

Hi all,

I am using clang-3.8.0 under MinGW-w64, and I found a problem of C++ typeinfo
structure generation while targeting 64-bit code generation, that correctly
works while targeting 32-bit one:

Here is a copy of the typeinfo structure generated for a class called
'sc_core::sc_signal_in_if<float>' for x86_64/MinGW-w64 target:

_ZTIN7sc_core15sc_signal_in_ifIfEE:
        .quad   _ZTVN10__cxxabiv121__vmi_class_type_infoE+16
        .quad   _ZTSN7sc_core15sc_signal_in_ifIfEE
        .long   0                       # 0x0
        .long   1                       # 0x1
        .quad   _ZTIN7sc_core12sc_interfaceE
        .long   4294955011              # 0xffffd003
        .zero   4

while the same structure generated by gcc-6.1.0/MinGW-w64 is the following:

_ZTIN7sc_core18sc_signal_write_ifIfEE:
        .quad   _ZTVN10__cxxabiv121__vmi_class_type_infoE+16
        .quad   _ZTSN7sc_core18sc_signal_write_ifIfEE
        .long   0
        .long   1
        .quad   _ZTIN7sc_core12sc_interfaceE
        .quad   -12285

What clearly appears here is that the last '.quad' value of the typeinfo
structure is badly generated for clang-3.8.0/MinGW-w64 because it is not
negative but positive, as the sign is not extended to the most significant 32
bits... which makes some dynamic_cast<>() fail in my application (too complex
to be copied here, although open source, as extracted from Accelera SystemC
package).

Notice also that the clang-3.8.0 generation targeted at x86_64/Linux is correct
(almost same assembler as for gcc-6.1.0/MinGW-w64):

_ZTIN7sc_core15sc_signal_in_ifIfEE:
        .quad   _ZTVN10__cxxabiv121__vmi_class_type_infoE+16
        .quad   _ZTSN7sc_core15sc_signal_in_ifIfEE
        .long   0                       # 0x0
        .long   1                       # 0x1
        .quad   _ZTIN7sc_core12sc_interfaceE
        .quad   -12285                  # 0xffffffffffffd003
        .size   _ZTIN7sc_core15sc_signal_in_ifIfEE, 40

I let someone who knows the Clang back-end generator provide the official fix.

Thanks in advance,
Eric PAIRE

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160824/bf177219/attachment.html>