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: unassignedclangb...@nondot.org
Reporter: eric.pa...@st.com
CC: dgre...@apple.com, llvm-bugs@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.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
