|
From: Keith R. <Kei...@nt...> - 2007-01-25 07:57:12
|
I'm seeing an error: vex: the `impossible' happened: eqIRConst vex storage: T total 2047426320 bytes allocated valgrind: the 'impossible' happened: LibVEX called failure_exit(). ==1701== at 0x380177D0: report_and_quit (m_libcassert.c:136) ==1701== by 0x38017AAB: panic (m_libcassert.c:210) ==1701== by 0x38017ACE: vgPlain_core_panic_at (m_libcassert.c:215) ==1701== by 0x38017AEC: vgPlain_core_panic (m_libcassert.c:220) ==1701== by 0x38029809: failure_exit (m_translate.c:487) ==1701== by 0x3806DAF8: vpanic (vex_util.c:225) ==1701== by 0x3806C072: eqIRConst (irdefs.c:2576) ==1701== by 0x380F8509: eq_AvailExpr (libvex_basictypes.h:88) ==1701== by 0x380F8CC0: do_cse_BB (iropt.c:2594) ==1701== by 0x380FB014: do_iropt_BB (iropt.c:4208) ==1701== by 0x3806C85D: LibVEX_Translate (vex_main.c:478) ==1701== by 0x38029E9B: vgPlain_translate (m_translate.c:1097) ==1701== by 0x38035DF7: handle_tt_miss (scheduler.c:693) ==1701== by 0x380362FD: vgPlain_scheduler (scheduler.c:865) ==1701== by 0x38047A36: thread_wrapper (syswrap-linux.c:87) ==1701== by 0x38047B0F: run_a_thread_NORETURN (syswrap-linux.c:120) sched status: running_tid=1 Is this something unhandled? The application is running on AMD Opteron in 64-bit mode; the unhandled error apparently arises from inside the Goto BLAS library, which is handcoded assembler. (http://www.tacc.utexas.edu/~kgoto/) Is this an unhandled instruction? Or just a bug? Or is libgoto doing something unexpected. Keith Refson |
|
From: Julian S. <js...@ac...> - 2007-01-25 08:04:27
|
What version of valgrind is this with? J On Thursday 25 January 2007 07:55, Keith Refson wrote: > I'm seeing an error: > > vex: the `impossible' happened: > eqIRConst > vex storage: T total 2047426320 bytes allocated > > valgrind: the 'impossible' happened: > LibVEX called failure_exit(). > ==1701== at 0x380177D0: report_and_quit (m_libcassert.c:136) > ==1701== by 0x38017AAB: panic (m_libcassert.c:210) > ==1701== by 0x38017ACE: vgPlain_core_panic_at (m_libcassert.c:215) > ==1701== by 0x38017AEC: vgPlain_core_panic (m_libcassert.c:220) > ==1701== by 0x38029809: failure_exit (m_translate.c:487) > ==1701== by 0x3806DAF8: vpanic (vex_util.c:225) > ==1701== by 0x3806C072: eqIRConst (irdefs.c:2576) > ==1701== by 0x380F8509: eq_AvailExpr (libvex_basictypes.h:88) > ==1701== by 0x380F8CC0: do_cse_BB (iropt.c:2594) > ==1701== by 0x380FB014: do_iropt_BB (iropt.c:4208) > ==1701== by 0x3806C85D: LibVEX_Translate (vex_main.c:478) > ==1701== by 0x38029E9B: vgPlain_translate (m_translate.c:1097) > ==1701== by 0x38035DF7: handle_tt_miss (scheduler.c:693) > ==1701== by 0x380362FD: vgPlain_scheduler (scheduler.c:865) > ==1701== by 0x38047A36: thread_wrapper (syswrap-linux.c:87) > ==1701== by 0x38047B0F: run_a_thread_NORETURN (syswrap-linux.c:120) > > sched status: > running_tid=1 > > Is this something unhandled? The application is running on AMD Opteron > in 64-bit mode; the unhandled error apparently arises from inside the > Goto BLAS library, which is handcoded assembler. > (http://www.tacc.utexas.edu/~kgoto/) > > Is this an unhandled instruction? Or just a bug? Or is libgoto doing > something unexpected. > > Keith Refson > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Julian S. <js...@ac...> - 2007-01-25 08:21:33
|
(I have a bad feeling it is a regression I introduced into the just-released 3.2.2.) On Thursday 25 January 2007 08:15, Julian Seward wrote: > What version of valgrind is this with? > > J > > On Thursday 25 January 2007 07:55, Keith Refson wrote: > > I'm seeing an error: > > > > vex: the `impossible' happened: > > eqIRConst > > vex storage: T total 2047426320 bytes allocated > > > > valgrind: the 'impossible' happened: > > LibVEX called failure_exit(). > > ==1701== at 0x380177D0: report_and_quit (m_libcassert.c:136) > > ==1701== by 0x38017AAB: panic (m_libcassert.c:210) > > ==1701== by 0x38017ACE: vgPlain_core_panic_at (m_libcassert.c:215) > > ==1701== by 0x38017AEC: vgPlain_core_panic (m_libcassert.c:220) > > ==1701== by 0x38029809: failure_exit (m_translate.c:487) > > ==1701== by 0x3806DAF8: vpanic (vex_util.c:225) > > ==1701== by 0x3806C072: eqIRConst (irdefs.c:2576) > > ==1701== by 0x380F8509: eq_AvailExpr (libvex_basictypes.h:88) > > ==1701== by 0x380F8CC0: do_cse_BB (iropt.c:2594) > > ==1701== by 0x380FB014: do_iropt_BB (iropt.c:4208) > > ==1701== by 0x3806C85D: LibVEX_Translate (vex_main.c:478) > > ==1701== by 0x38029E9B: vgPlain_translate (m_translate.c:1097) > > ==1701== by 0x38035DF7: handle_tt_miss (scheduler.c:693) > > ==1701== by 0x380362FD: vgPlain_scheduler (scheduler.c:865) > > ==1701== by 0x38047A36: thread_wrapper (syswrap-linux.c:87) > > ==1701== by 0x38047B0F: run_a_thread_NORETURN (syswrap-linux.c:120) > > > > sched status: > > running_tid=1 > > > > Is this something unhandled? The application is running on AMD Opteron > > in 64-bit mode; the unhandled error apparently arises from inside the > > Goto BLAS library, which is handcoded assembler. > > (http://www.tacc.utexas.edu/~kgoto/) > > > > Is this an unhandled instruction? Or just a bug? Or is libgoto doing > > something unexpected. > > > > Keith Refson > > > > > > ------------------------------------------------------------------------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share > > your opinions on IT & business topics through brief surveys - and earn > > cash > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > > Valgrind-users mailing list > > Val...@li... > > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Keith R. <Kei...@nt...> - 2007-01-25 09:38:01
|
Julian Seward wrote: > (I have a bad feeling it is a regression I introduced into the > just-released 3.2.2.) > > On Thursday 25 January 2007 08:15, Julian Seward wrote: >> What version of valgrind is this with? Yes, this is with a just-compiled 3.2.2 I'm afraid. Keith Refson |
|
From: Julian S. <js...@ac...> - 2007-01-25 09:44:05
|
On Thursday 25 January 2007 09:37, Keith Refson wrote: > Julian Seward wrote: > > (I have a bad feeling it is a regression I introduced into the > > just-released 3.2.2.) > > > > On Thursday 25 January 2007 08:15, Julian Seward wrote: > >> What version of valgrind is this with? > > Yes, this is with a just-compiled 3.2.2 I'm afraid. In function eqIRConst in VEX/priv/ir/irdefs.c line 2500 ish, try adding this in the obvious place case Ico_V128: return toBool( (0xFFFF & c1->Ico.V128) == (0xFFFF & c2->Ico.V128) ); rebuild (at the top level, do "make clean install"), and see if that fixes it. J |
|
From: Julian S. <js...@ac...> - 2007-01-25 18:33:45
|
On Thursday 25 January 2007 09:55, Julian Seward wrote:
> On Thursday 25 January 2007 09:37, Keith Refson wrote:
> > Julian Seward wrote:
> > > (I have a bad feeling it is a regression I introduced into the
> > > just-released 3.2.2.)
Unfortunately this is indeed the case:
int main ( void )
{
__asm__ __volatile__(
"pxor %%xmm0,%%xmm0\n\t"
"movaps %%xmm1,%%xmm2\n\t"
"addps %%xmm0,%%xmm1\n\t"
"addps %%xmm0,%%xmm2\n\t"
"addps %%xmm1,%%xmm2\n\t"
: : : "xmm0","xmm1", "st"
);
return 0;
}
now causes the IR optimiser to bomb (both in 32-bit and 64-bit mode)
whereas it runs ok on 3.2.1.
J
|