|
From: Christian B. <bor...@de...> - 2011-12-14 03:05:41
Attachments:
diffs.txt
|
valgrind revision: 12305 VEX revision: 2233 GCC version: gcc (GCC) 4.5.3 20110121 (Red Hat 4.5.3-3) C library: GNU C Library stable release version 2.12.1, by Roland McGrath et al. uname -mrs: Linux 3.1.0-rc9-andreas-gde346b6-dirty s390x Vendor version: unknown Nightly build on fedora390 ( Fedora 13/14/15 mix with gcc 3.5.3 on z196 (s390x) ) Started at 2011-12-14 03:45:01 CET Ended at 2011-12-14 04:05:37 CET Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 510 tests, 6 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc20_verifywrap (stderr) drd/tests/annotate_trace_memory (stderr) drd/tests/annotate_trace_memory_xml (stderr) drd/tests/tc04_free_lock (stderr) drd/tests/tc09_bad_unlock (stderr) |
|
From: Christian B. <bor...@de...> - 2011-12-14 07:48:22
|
Florian,
this is a real bug in our code.
We should be able to handle ReinterpF32asI32 but we dont.
I have attached the backtrace, can you have a look?
-- t13 = LDbe:F32(t11)
v-load %vF43,0(%vR11) 4 bytes
v-move %vF13,%vF43 4 bytes
-- ------ IMark(0x80000B30, 4, 0) ------
-- PUT(336) = 0x80000B30:I64
v-loadi %vR44,0x80000B30 8 bytes
v-store %vR44,336(%r13) 8 bytes
-- DIRTY 1:I1 ::: drd_trace_mem_store[rp=3]{0x401007c28}(0x8000306C:I64,0x4:I64,0x0:I64,32Uto64(ReinterpF32asI32(t13)))
v-loadi %vR45,0x8000306C 8 bytes
v-loadi %vR46,4 8 bytes
v-loadi %vR47,0 8 bytes
vex: priv/host_s390_isel.c:1339 (s390_isel_int_expr_RMI): Assertion `ty == Ity_I8 || ty == Ity_I16 || ty == Ity_I32 || ty == Ity_I64' failed.
vex storage: T total 101646040 bytes allocated
vex storage: P total 0 bytes allocated
valgrind: the 'impossible' happened:
LibVEX called failure_exit().
==10434== at 0x40101E880: report_and_quit (m_libcassert.c:210)
==10434== by 0x40101E8F1: panic (m_libcassert.c:294)
==10434== by 0x40101E953: vgPlain_core_panic_at (m_libcassert.c:299)
==10434== by 0x40101E967: vgPlain_core_panic (m_libcassert.c:304)
==10434== by 0x40103C12B: failure_exit (m_translate.c:700)
==10434== by 0x4010C6933: vex_assert_fail (main_util.c:219)
==10434== by 0x401253F09: s390_isel_int_expr_RMI (host_s390_isel.c:1338)
==10434== by 0x401252725: s390_isel_int_expr (host_s390_isel.c:1094)
==10434== by 0x401253DF5: s390_isel_int_expr_RMI (host_s390_isel.c:1366)
==10434== by 0x401252725: s390_isel_int_expr (host_s390_isel.c:1094)
==10434== by 0x401254669: doHelperCall (host_s390_isel.c:384)
==10434== by 0x40125504D: iselSB_S390 (host_s390_isel.c:2241)
==10434== by 0x4010C4F39: LibVEX_Translate (main_main.c:658)
==10434== by 0x401039891: vgPlain_translate (m_translate.c:1544)
==10434== by 0x40106A693: vgPlain_scheduler (scheduler.c:929)
==10434== by 0x401095BBD: run_a_thread_NORETURN (syswrap-linux.c:98)
==10434== by 0xFFFFFFFFFFFFFFFF: ???
|
|
From: Florian K. <br...@ac...> - 2011-12-15 15:17:22
|
On 12/14/2011 02:48 AM, Christian Borntraeger wrote: > > Florian, > > this is a real bug in our code. > We should be able to handle ReinterpF32asI32 but we dont. > > > I have attached the backtrace, can you have a look? > I'll try to get to it this weekend. Florian |
|
From: Christian B. <bor...@de...> - 2011-12-18 08:05:51
|
On 15/12/11 16:17, Florian Krohm wrote: > On 12/14/2011 02:48 AM, Christian Borntraeger wrote: >> >> Florian, >> >> this is a real bug in our code. >> We should be able to handle ReinterpF32asI32 but we dont. >> >> >> I have attached the backtrace, can you have a look? >> > > I'll try to get to it this weekend. > > Florian > According to the nightly runs the bug itself is gone. Only leftover is to find out why we have 0 instead of the real values for the two 4 byte floats on s390. Christian |
|
From: Florian K. <br...@ac...> - 2011-12-18 14:55:37
|
On 12/18/2011 03:05 AM, Christian Borntraeger wrote: >> > According to the nightly runs the bug itself is gone. Only leftover > is to find out why we have 0 instead of the real values for the two > 4 byte floats on s390. > I think I know what is going on. When we reinterp a 32-bit value we need to copy if from gpr[32:63] to fpr[0:31] and vice versa. Because that is where a 4-byte value wold be stored if we loaded it into a gpr/fpr. Right now we just copy the value from fpr to gpr which is OK for 8 byte but not for 4 byte. I'll check in a patch for that in time for the next nightly build. Florian |