I get a similar crash with Valgrind 3.11 in libcrypto at the same function call, ecp_nistz256_avx2_select_w7.  I'm running Kubuntu 15.10.

I get a similar crash on Arch. valgrind 3.11

==26955==    at 0x5EAAF40: ecp_nistz256_avx2_select_w7 (in /usr/lib/libcrypto.so.1.0.0)
==26955==    by 0x5E7A5CF: EC_POINT_mul (in /usr/lib/libcrypto.so.1.0.0)
==26955==    by 0x5E79416: EC_POINT_new (in /usr/lib/libcrypto.so.1.0.0)
==26955==    by 0x5E82E89: EC_KEY_generate_key (in /usr/lib/libcrypto.so.1.0.0)
==26955==    by 0x78092A4: ssl3_send_client_key_exchange (in /usr/lib/libssl.so.1.0.0)
==26955==    by 0x780CF67: ssl3_connect (in /usr/lib/libssl.so.1.0.0)
==26955==    by 0x7817E9B: ssl23_connect (in /usr/lib/libssl.so.1.0.0)
==26955==    by 0x6265A03: ??? (in /usr/lib/libcurl.so.4.4.0)
==26955==    by 0x6265FB9: ??? (in /usr/lib/libcurl.so.4.4.0)
==26955==    by 0x626967F: ??? (in /usr/lib/libcurl.so.4.4.0)
==26955==    by 0x622276D: ??? (in /usr/lib/libcurl.so.4.4.0)
==26955==    by 0x6248535: ??? (in /usr/lib/libcurl.so.4.4.0)
==26955==    by 0x624915C: curl_multi_perform (in /usr/lib/libcurl.so.4.4.0)
==26955==    by 0x623FBFA: curl_easy_perform (in /usr/lib/libcurl.so.4.4.0)

I'm getting the same crash on Kubuntu 15.10 with Vlagrind 3.11.0 while trying to analyze the application that uses libcurl:

vex: the `impossible' happened:
   isZeroU
vex storage: T total 15579834320 bytes allocated
vex storage: P total 640 bytes allocated

valgrind: the 'impossible' happened:
   LibVEX called failure_exit().

host stacktrace:
==6282==    at 0x38083F98: show_sched_status_wrk (m_libcassert.c:343)
==6282==    by 0x380840B4: report_and_quit (m_libcassert.c:415)
==6282==    by 0x380842F1: panic (m_libcassert.c:491)
==6282==    by 0x380842F1: vgPlain_core_panic_at (m_libcassert.c:496)
==6282==    by 0x3808431A: vgPlain_core_panic (m_libcassert.c:501)
==6282==    by 0x3809F6B2: failure_exit (m_translate.c:740)
==6282==    by 0x38148078: vpanic (main_util.c:231)
==6282==    by 0x381551DD: isZeroU.isra.16.part.17 (ir_opt.c:1226)
==6282==    by 0x38159302: isZeroU (ir_opt.c:1525)
==6282==    by 0x38159302: fold_Expr (ir_opt.c:2308)
==6282==    by 0x38159F36: subst_and_fold_Stmt (ir_opt.c:2585)
==6282==    by 0x38159F36: cprop_BB (ir_opt.c:2794)
==6282==    by 0x3815BE48: cheap_transformations (ir_opt.c:6414)
==6282==    by 0x3815CE96: do_iropt_BB (ir_opt.c:6608)
==6282==    by 0x38145E7C: LibVEX_Translate (main_main.c:916)
==6282==    by 0x380A1C3B: vgPlain_translate (m_translate.c:1765)
==6282==    by 0x380D294B: handle_chain_me (scheduler.c:1076)
==6282==    by 0x380D45AF: vgPlain_scheduler (scheduler.c:1420)
==6282==    by 0x380E3926: thread_wrapper (syswrap-linux.c:102)
==6282==    by 0x380E3926: run_a_thread_NORETURN (syswrap-linux.c:155)
==6282==    by 0x380E3DFA: vgModuleLocal_start_thread_NORETURN (syswrap-linux.c:324)
==6282==    by 0x3810C60D: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==6282==    by 0xDEADBEEFDEADBEEE: ???
==6282==    by 0xDEADBEEFDEADBEEE: ???
==6282==    by 0xDEADBEEFDEADBEEE: ???

sched status:
  running_tid=8

[...]

Thread 8: status = VgTs_Runnable (lwpid 6351)
==6282==    at 0x9AF5980: ecp_nistz256_avx2_select_w7 (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==6282==    by 0x9AD4CEF: EC_POINT_mul (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==6282==    by 0x9AD3B36: EC_POINT_new (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==6282==    by 0x9ADD029: EC_KEY_generate_key (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==6282==    by 0x11775D94: ssl3_send_client_key_exchange (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==6282==    by 0x11779857: ssl3_connect (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==6282==    by 0x11782F3D: ssl23_connect (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==6282==    by 0xDC4FE83: ossl_connect_step2 (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==6282==    by 0xDC50999: ossl_connect_common (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==6282==    by 0xDC5433F: Curl_ssl_connect_nonblocking (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==6282==    by 0xDC1118C: Curl_http_connect (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==6282==    by 0xDC222C0: Curl_protocol_connect (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==6282==    by 0xDC3636D: multi_runsingle (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==6282==    by 0xDC36F5C: curl_multi_perform (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==6282==    [...]

(In reply to Darshit Shah from comment #0)
> vex: the `impossible' happened:
>    isZeroU
> vex storage: T total 983714392 bytes allocated
> vex storage: P total 640 bytes allocated
> 
> valgrind: the 'impossible' happened:
>    LibVEX called failure_exit().
> 
> host stacktrace:
> ==16723==    at 0x38083FA8: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
> ==16723==    by 0x380840C4: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
> ==16723==    by 0x38084301: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
> ==16723==    by 0x3808432A: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
> ==16723==    by 0x3809F6C2: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
> ==16723==    by 0x38148008: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
> ==16723==    by 0x3815516D: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
> ==16723==    by 0x38159292: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
> ==16723==    by 0x38159EC6: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
> ==16723==    by 0x3815BDD8: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
> ==16723==    by 0x3815CE26: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
> ==16723==    by 0x38145E0C: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
> ==16723==    by 0x380A1C4B: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
> ==16723==    by 0x380D295B: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
> ==16723==    by 0x380D45BF: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
> ==16723==    by 0x380E3936: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
> 
> sched status:
>   running_tid=1
> 
> Thread 1: status = VgTs_Runnable (lwpid 16723)
> ==16723==    at 0x5EA6F40: ecp_nistz256_avx2_select_w7 (in
> /usr/lib/libcrypto.so.1.0.0)
> ==16723==    by 0x5E765CF: EC_POINT_mul (in /usr/lib/libcrypto.so.1.0.0)
> ==16723==    by 0x5E75416: EC_POINT_new (in /usr/lib/libcrypto.so.1.0.0)
> ==16723==    by 0x5E7EE89: EC_KEY_generate_key (in
> /usr/lib/libcrypto.so.1.0.0)
> ==16723==    by 0x5B422A4: ssl3_send_client_key_exchange (in
> /usr/lib/libssl.so.1.0.0)
> ==16723==    by 0x5B45F67: ssl3_connect (in /usr/lib/libssl.so.1.0.0)
> ==16723==    by 0x5B50E9B: ssl23_connect (in /usr/lib/libssl.so.1.0.0)
> ==16723==    by 0x452B2F: ssl_connect_with_timeout_callback (openssl.c:506)
> ==16723==    by 0x44DDF3: run_with_timeout (utils.c:2046)
> ==16723==    by 0x4529A9: ssl_connect_wget (openssl.c:559)
> ==16723==    by 0x429A0F: establish_connection (http.c:2144)
> ==16723==    by 0x425BAE: gethttp (http.c:3055)
> ==16723==    by 0x4243C5: http_loop (http.c:3971)
> ==16723==    by 0x43FE0E: retrieve_url (retr.c:817)
> ==16723==    by 0x4365C2: main (main.c:1868)
> 
> Valgrind crashed with the following message when trying to test GNU Wget.
> The issue is triggered only by two specific tests that require Wget to
> connect to a proxy server over HTTPS. It does not happen during normal
> connections to HTTPS servers. Also, the issue occurs only when compiled with
> OpenSSL. With GnuTLS there are no problems.
> 
> P.S.: I'm using Valgrind 3.11 on Arch Linux. The version option is not
> available in the form. The issue seems to be a regression since it doesn't
> come up on an older version (3.7.0) during the CI builds on Travis.
> 
> Reproducible: Always
> 
> Steps to Reproduce:
> 1. git clone http://git.savannah.gnu.org/r/wget.git
> 2. cd wget
> 3. ./bootstrap && ./configure --enable-valgrind-tests --with-ssl=openssl
> 4. make check
> 
> Actual Results:  
> The output present above

I just built wget according those instructions on my x86-64. With stock valgrind 3.11.0 I do not get any errors:
============================================================================
Testsuite summary for wget 1.17.1.11-b305
============================================================================
# TOTAL: 85
# PASS:  71
# SKIP:  14
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0
============================================================================
and
============================================================================
Testsuite summary for wget 1.17.1.11-b305
============================================================================
# TOTAL: 28
# PASS:  28
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0

Perhaps it's one of those skipped tests that is failing:

SKIP: Test-ftp-iri.px
SKIP: Test-ftp-iri-fallback.px
SKIP: Test-ftp-iri-recursive.px
SKIP: Test-ftp-iri-disabled.px
SKIP: Test-idn-headers.px
SKIP: Test-idn-meta.px
SKIP: Test-idn-cmd.px
SKIP: Test-idn-cmd-utf8.px
SKIP: Test-idn-robots.px
SKIP: Test-idn-robots-utf8.px
SKIP: Test-iri.px
SKIP: Test-iri-percent.px
SKIP: Test-iri-forced-remote.px
SKIP: Test-iri-list.px

If it's one of these that is failing can you explain what needs to be done to enable those tests?

Ah yes, just to make sure: from config.log:

configure:4427: checking for valgrind
configure:4443: found /home/florian/valgrind/bugzilla/356393/bin/valgrind
configure:4455: result: yes

The suite runs somewhat fast given that it is supposed to run under valgrind. On my 5 year old laptop I get for "make check"
real	2m30.001s
user	2m17.587s
sys	0m6.500s
does that look OK ?

This is the guilty code:

            case Iop_Xor8:
            case Iop_Xor16:
            case Iop_Xor32:
            case Iop_Xor64:
            case Iop_XorV128:
            case Iop_XorV256:    //   <==== selecting this case
               /* Xor8/16/32/64/V128(t,t) ==> 0, for some IRTemp t */
               if (sameIRExprs(env, e->Iex.Binop.arg1, e->Iex.Binop.arg2)) {  // <=== false
                  e2 = mkZeroOfPrimopResultType(e->Iex.Binop.op);
                  break;
               }
               /* XorV128(t,0) ==> t */
               if (e->Iex.Binop.op == Iop_XorV128) {
                  if (isZeroV128(e->Iex.Binop.arg2)) {
                     e2 = e->Iex.Binop.arg1;
                     break;
                  }
                  //Disabled because there's no known test case right now.
                  //if (isZeroV128(e->Iex.Binop.arg1)) {
                  //   e2 = e->Iex.Binop.arg2;
                  //   break;
                  //}
               } else {
                  /* Xor8/16/32/64(0,t) ==> t */
                  if (isZeroU(e->Iex.Binop.arg1)) {     //  <=== arriving here

BANG. isZeroU cannot handle Iop_XorV256  hence the assert.

This patch is likely going to fix it (still testing):
Index: VEX/priv/ir_opt.c
===================================================================
--- VEX/priv/ir_opt.c	(revision 3206)
+++ VEX/priv/ir_opt.c	(working copy)
@@ -2292,8 +2292,15 @@
                   e2 = mkZeroOfPrimopResultType(e->Iex.Binop.op);
                   break;
                }
+               /* XorV256(t,0) ==> t */
+               if (e->Iex.Binop.op == Iop_XorV256) {
+                  if (isZeroV256(e->Iex.Binop.arg2)) {
+                     e2 = e->Iex.Binop.arg1;
+                     break;
+                  }
+               }
                /* XorV128(t,0) ==> t */
-               if (e->Iex.Binop.op == Iop_XorV128) {
+               else if (e->Iex.Binop.op == Iop_XorV128) {
                   if (isZeroV128(e->Iex.Binop.arg2)) {
                      e2 = e->Iex.Binop.arg1;
                      break;

but the code is UGLY. Comments are out of date and the Boolean IRops And/Or/Xor are handled differently. We really should keep as much code in common as possible. 
Extending isZeroU and isOneU to also handle V128 and V256 values makes sense to me.Even if the function name then no longer exactly describes the set of allowed values. Or we can change the function name as there are only aboout 10 invocations. So the ripple is acceptable IMHO.

Arrrgh!  Didn't we fix this yet?

valgrind 3.11.0
ArchLinux up to date as of today
this bug shows up when running valgrind against QML application

I just built r15831 and got the same crash when I hit libcurl + ssl. When I comment the network code, valgrind works just fine.

vex: the `impossible' happened:
   isZeroU
vex storage: T total 4426865440 bytes allocated
vex storage: P total 640 bytes allocated

valgrind: the 'impossible' happened:
   LibVEX called failure_exit().

Thread 3: status = VgTs_Runnable (lwpid 20263)
==20256==    at 0x9BB6DC0: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==20256==    by 0x9B9607F: EC_POINT_mul (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==20256==    by 0x9B94EC6: EC_POINT_new (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==20256==    by 0x9B9E439: EC_KEY_generate_key (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==20256==    by 0x9876C64: ??? (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==20256==    by 0x987A8A7: ??? (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==20256==    by 0x9884045: ??? (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==20256==    by 0x69AC273: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.4.0)
==20256==    by 0x69AC819: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.4.0)
==20256==    by 0x69AFCFF: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.4.0)
==20256==    by 0x696C3CD: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.4.0)
==20256==    by 0x6992175: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.4.0)
==20256==    by 0x6993163: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.4.0)
==20256==    by 0x6993276: curl_multi_socket_action (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.4.0)
==20256==    by 0x57A7C3: mbgl::HTTPCURLContext::perform(int, mbgl::util::RunLoop::Event) (http_request_curl.cpp:191)
==20256==    by 0x54E30A: operator() (functional:2267)
==20256==    by 0x54E30A: mbgl::util::Watch::onEvent(uv_poll_s*, int, int) (run_loop.cpp:44)
==20256==    by 0x5F089D: uv__io_poll (linux-core.c:345)
==20256==    by 0x5E7972: uv_run (core.c:341)
==20256==    by 0x563814: void mbgl::util::Thread<mbgl::OnlineFileSource::Impl>::run<std::tuple<int>, 0ul>(mbgl::util::ThreadContext, std::tuple<int>&&, std::integer_sequence<unsigned long, 0ul>) (thread.hpp:124)
==20256==    by 0x563E09: operator() (thread.hpp:106)
==20256==    by 0x563E09: _M_invoke<> (functional:1531)
==20256==    by 0x563E09: operator() (functional:1520)
==20256==    by 0x563E09: std::thread::_Impl<std::_Bind_simple<mbgl::util::Thread<mbgl::OnlineFileSource::Impl>::Thread<int>(mbgl::util::ThreadContext const&, int&&)::{lambda()#1} ()> >::_M_run() (thread:115)
==20256==    by 0x6C83C2F: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==20256==    by 0x5FEB669: start_thread (pthread_create.c:333)
==20256==    by 0x726A01C: clone (clone.S:109)

Fixed, vex r3213.  Sorry it took so long to get around to this entirely trivial fix.

(In reply to Julian Seward from comment #9)
> Fixed, vex r3213.  Sorry it took so long to get around to this entirely
> trivial fix.

Works for me now, thanks for fixing.

*** Bug 363497 has been marked as a duplicate of this bug. ***

*** Bug 364497 has been marked as a duplicate of this bug. ***