<html>
<head>
<base href="https://llvm.org/bugs/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - typeinfo structure badly generated for MinGW-w64/x86_64 makes dynamic_cast<>() fail"
href="https://llvm.org/bugs/show_bug.cgi?id=29116">29116</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>typeinfo structure badly generated for MinGW-w64/x86_64 makes dynamic_cast<>() fail
</td>
</tr>
<tr>
<th>Product</th>
<td>clang
</td>
</tr>
<tr>
<th>Version</th>
<td>3.8
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Windows XP
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>C++
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedclangbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>eric.paire@st.com
</td>
</tr>
<tr>
<th>CC</th>
<td>dgregor@apple.com, llvm-bugs@lists.llvm.org
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>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</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>