|
From: Julian S. <js...@ac...> - 2007-01-28 09:25:56
|
Unfortunately it seems that, despite extensive testing, on obscure
pieces of SSE2 code, 3.2.2 dies with an assertion failure that 3.2.1
succeeds with. Details below. This regression was not picked up in
testing but was discovered by a user less than 48 hours after release,
so it can't be a completely obscure problem.
I'm not happy to continue shipping 3.2.2 with a known regression.
The fix is a one-liner, so I'm proposing to release 3.2.2 with the fix
(plus an unrelated glibc-2.5 fix from Dirk).
That raises the question of what to call it. 3.2.3 is a possibility,
but the changes are so small that doesn't feel right. I prefer 3.2.2.1
as that indicates to people that the changes are small. Does that
sound ok, particularly to package-building folks?
J
-----
The problem is caused by vex r1728/9, which transforms 128-bit XORs of the
same temporary into a 128-bit zero immediate. Unfortunately a later
common-subexpression elimination pass does not handle such immediates,
and so the following piece of code, which contains the CSEs '0 + %xmm1'
and '0 + %xmm2', in the case where it is known that %xmm1 == %xmm2,
kills 3.2.2 both on x86 and amd64:
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;
}
results in
ex: the `impossible' happened:
eqIRConst
vex storage: T total 68337344 bytes allocated
valgrind: the 'impossible' happened:
LibVEX called failure_exit().
==23986== at 0x38017803: report_and_quit (m_libcassert.c:136)
==23986== by 0x38017941: panic (m_libcassert.c:210)
==23986== by 0x38017997: vgPlain_core_panic_at (m_libcassert.c:215)
==23986== by 0x380179B5: vgPlain_core_panic (m_libcassert.c:220)
==23986== by 0x3802A650: failure_exit (m_translate.c:487)
==23986== by 0x38071678: vpanic (vex_util.c:225)
==23986== by 0x3806A1B0: eqIRConst (irdefs.c:2576)
==23986== by 0x3810BB84: do_cse_BB (iropt.c:2279)
==23986== by 0x3810CBBD: do_iropt_BB (iropt.c:4208)
==23986== by 0x3807010B: LibVEX_Translate (vex_main.c:478)
==23986== by 0x38029365: vgPlain_translate (m_translate.c:1097)
==23986== by 0x38037610: vgPlain_scheduler (scheduler.c:693)
==23986== by 0x38052FBE: run_a_thread_NORETURN (syswrap-linux.c:87)
|
|
From: Tom H. <to...@co...> - 2007-01-28 09:29:31
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> That raises the question of what to call it. 3.2.3 is a possibility,
> but the changes are so small that doesn't feel right. I prefer 3.2.2.1
> as that indicates to people that the changes are small. Does that
> sound ok, particularly to package-building folks?
Sounds fine to me.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2007-01-28 12:49:53
|
On Sun, 28 Jan 2007, Julian Seward wrote: > That raises the question of what to call it. 3.2.3 is a possibility, > but the changes are so small that doesn't feel right. I prefer 3.2.2.1 > as that indicates to people that the changes are small. Does that > sound ok, particularly to package-building folks? I slightly prefer 3.2.3, but I can live with 3.2.2.1. N |
|
From: Robert W. <rj...@du...> - 2007-01-28 20:07:41
|
Nicholas Nethercote wrote: > On Sun, 28 Jan 2007, Julian Seward wrote: > >> That raises the question of what to call it. 3.2.3 is a possibility, >> but the changes are so small that doesn't feel right. I prefer 3.2.2.1 >> as that indicates to people that the changes are small. Does that >> sound ok, particularly to package-building folks? > > I slightly prefer 3.2.3, but I can live with 3.2.2.1. I'd prefer 3.2.3, too, but I'm not going to lose any sleep about it. :-) |
|
From: Dirk M. <mu...@kd...> - 2007-01-29 12:48:24
|
On Sunday, 28. January 2007 10:29, Tom Hughes wrote: > > That raises the question of what to call it. 3.2.3 is a possibility, > > but the changes are so small that doesn't feel right. I prefer 3.2.2.1 > > as that indicates to people that the changes are small. Does that > > sound ok, particularly to package-building folks? > Sounds fine to me. Either one is fine with me, I would prefer to call it 3.2.3 though. BTW, the memrchr() patch has been left out, that is on purpose? Dirk |
|
From: Julian S. <js...@ac...> - 2007-01-29 17:01:32
|
> Either one is fine with me, I would prefer to call it 3.2.3 though. Looks like 3.2.3 has more votes than 3.2.2.1. > BTW, the memrchr() patch has been left out, that is on purpose? Yes .. I prefer not to ship redirects which are untested since any problem in the redirections are going to lead to hard-to-find differences between simulated and native execution. It was difficult enough to find a program which uses __stpcpy_chk; rpm was the only one I found (and I searched on google code search). (eg You can run konq, OOo, firefox and none of those use __stpcpy_chk afaics). J |
|
From: Dirk M. <mu...@kd...> - 2007-01-29 17:22:21
|
On Monday, 29. January 2007 18:12, Julian Seward wrote: > only one I found (and I searched on google code search). (eg You can > run konq, OOo, firefox and none of those use __stpcpy_chk afaics). Sure, because they're c++ applications, and fortify doesn't work for them. Thats why ;) Dirk |
|
From: Julian S. <js...@ac...> - 2007-01-29 17:38:02
|
On Monday 29 January 2007 17:21, Dirk Mueller wrote: > On Monday, 29. January 2007 18:12, Julian Seward wrote: > > only one I found (and I searched on google code search). (eg You can > > run konq, OOo, firefox and none of those use __stpcpy_chk afaics). > > Sure, because they're c++ applications, and fortify doesn't work for them. > Thats why ;) Ok, so you're saying maybe I should try some big C apps (Gnome stuff) ? J |
|
From: Dirk M. <mu...@kd...> - 2007-01-30 10:05:43
|
On Monday, 29. January 2007 18:49, Julian Seward wrote: > Ok, so you're saying maybe I should try some big C apps (Gnome stuff) ? openSUSE 10.3 will soon have fortify checks in C++ apps as well, so thats not really necessary. Dirk |
|
From: Julian S. <js...@ac...> - 2007-02-02 02:40:47
|
Dirk, one other thing - please could you add 3.2.2 and 3.2.3 entries to the Version menu at http://bugs.kde.org/enter_valgrind_bug.cgi ? J On Tuesday 30 January 2007 09:24, Dirk Mueller wrote: > On Monday, 29. January 2007 18:49, Julian Seward wrote: > > Ok, so you're saying maybe I should try some big C apps (Gnome stuff) ? > > openSUSE 10.3 will soon have fortify checks in C++ apps as well, so thats > not really necessary. > > > Dirk > > > ------------------------------------------------------------------------- > 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-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Dirk M. <mu...@kd...> - 2007-02-02 10:05:07
|
On Friday, 2. February 2007 03:52, Julian Seward wrote: > Dirk, one other thing - please could you add 3.2.2 and 3.2.3 entries to > the Version menu at http://bugs.kde.org/enter_valgrind_bug.cgi ? sure, done. do you really want to accept bugreports against 3.2.2 though? Dirk |
|
From: Julian S. <js...@ac...> - 2007-02-02 10:09:56
|
On Friday 02 February 2007 08:44, Dirk Mueller wrote: > On Friday, 2. February 2007 03:52, Julian Seward wrote: > > Dirk, one other thing - please could you add 3.2.2 and 3.2.3 entries to > > the Version menu at http://bugs.kde.org/enter_valgrind_bug.cgi ? > > sure, done. Thanks. > do you really want to accept bugreports against 3.2.2 though? Well, not really, but it was available for 7 days, and at least some people downloaded it. So will be confusing if they can't file a bug report for 3.2.2 if they want to. J |