/external/v8/test/mjsunit/regress/ |
regress-351624.js | 11 var prod = val * big; 12 backup[0] = prod; 13 var rounded = Math.round(prod); 14 assertEquals(prod, backup[0]);
|
/external/autotest/apache/ |
apache-prod-conf | 1 # This is the "prod" conf file directly referenced by the AFE running in our 4 # machines for developer servers), and adds in prod-only directives.
|
/external/eigen/doc/snippets/ |
MatrixBase_prod.cpp | 3 cout << "Here is the product of all the coefficients:" << endl << m.prod() << endl;
|
PartialRedux_prod.cpp | 3 cout << "Here is the product of each row:" << endl << m.rowwise().prod() << endl;
|
/external/eigen/doc/examples/ |
tut_arithmetic_redux_basic.cpp | 11 cout << "Here is mat.prod(): " << mat.prod() << endl;
|
/external/webrtc/webrtc/modules/audio_coding/codecs/isac/fix/source/ |
filters_neon.c | 26 int64_t prod = 0; local 48 prod = vaddvq_s64(tmpb_v); 50 prod = vget_lane_s64(vadd_s64(vget_low_s64(tmpb_v), vget_high_s64(tmpb_v)), 54 temp = (uint32_t)(prod >> 31); 57 r[0] = (int32_t)(prod >> scaling); 94 prod = vaddvq_s64(tmpb_v); 96 prod = vget_lane_s64(vadd_s64(vget_low_s64(tmpb_v), vget_high_s64(tmpb_v)), 107 r[i] = (int32_t)((prod + prod_tail) >> scaling);
|
/external/skia/src/core/ |
SkMathPriv.h | 60 unsigned prod = a*b + 1; local 61 return (prod + (prod >> 8)) >> 8; 70 unsigned prod = a*b + 255; local 71 return (prod + (prod >> 8)) >> 8; 76 static inline unsigned SkDiv255Round(unsigned prod) { 77 prod += 128; 78 return (prod + (prod >> 8)) >> 8 [all...] |
/external/skia/src/opts/ |
SkColor_opts_SSE2.h | 37 __m128i prod = _mm_mullo_epi16(a, b); local 38 prod = _mm_add_epi32(prod, _mm_set1_epi32(128)); 39 prod = _mm_add_epi32(prod, _mm_srli_epi32(prod, 8)); 40 prod = _mm_srli_epi32(prod, 8); 42 return prod; 109 __m128i prod = _mm_mullo_epi16(a, b) local [all...] |
/external/llvm/test/CodeGen/AArch64/ |
mul-lohi.ll | 17 %prod = mul i128 %lhs, %rhs 18 ret i128 %prod 32 %prod = mul i128 %lhs, %rhs 33 ret i128 %prod 44 %prod = mul i128 %lhs, %rhs 45 ret i128 %prod
|
/external/chromium-trace/catapult/trace_processor/trace_uploader/ |
index.yaml | 9 - name: prod 21 - name: prod
|
/external/llvm/test/CodeGen/ARM/ |
neon-v8.1a.ll | 23 %prod = call <4 x i16> @llvm.arm.neon.vqrdmulh.v4i16(<4 x i16> %mhs, <4 x i16> %rhs) 24 %retval = call <4 x i16> @llvm.arm.neon.vqadds.v4i16(<4 x i16> %acc, <4 x i16> %prod) 31 %prod = call <8 x i16> @llvm.arm.neon.vqrdmulh.v8i16(<8 x i16> %mhs, <8 x i16> %rhs) 32 %retval = call <8 x i16> @llvm.arm.neon.vqadds.v8i16(<8 x i16> %acc, <8 x i16> %prod) 39 %prod = call <2 x i32> @llvm.arm.neon.vqrdmulh.v2i32(<2 x i32> %mhs, <2 x i32> %rhs) 40 %retval = call <2 x i32> @llvm.arm.neon.vqadds.v2i32(<2 x i32> %acc, <2 x i32> %prod) 47 %prod = call <4 x i32> @llvm.arm.neon.vqrdmulh.v4i32(<4 x i32> %mhs, <4 x i32> %rhs) 48 %retval = call <4 x i32> @llvm.arm.neon.vqadds.v4i32(<4 x i32> %acc, <4 x i32> %prod) 55 %prod = call <4 x i16> @llvm.arm.neon.vqrdmulh.v4i16(<4 x i16> %mhs, <4 x i16> %rhs) 56 %retval = call <4 x i16> @llvm.arm.neon.vqsubs.v4i16(<4 x i16> %acc, <4 x i16> %prod) [all...] |
/ndk/tests/device/test-gnustl-full/unit/ |
accum_test.cpp | 44 int prod = accumulate(v.begin(), v.end(), 1, mult); local 45 CPPUNIT_ASSERT(prod==120);
|
/ndk/tests/device/test-stlport/unit/ |
accum_test.cpp | 44 int prod = accumulate(v.begin(), v.end(), 1, mult); local 45 CPPUNIT_ASSERT(prod==120);
|
/external/guava/guava-gwt/src/com/google/common/annotations/ |
Annotations.gwt.xml | 13 <!-- We used to set this only for packages that had manual supersource. That worked everywhere that I know of except for one place: when running the GWT util.concurrent tests under Guava. The problem is that GWT responds poorly to two .gwt.xml files in the same Java package: http://goo.gl/CO7dLB The summary is that it ignores one file in favor of the other. util.concurrent, like nearly all our packages, has two .gwt.xml files: one for prod and one for tests. util.concurrent, unlike our other packages, has, as of this writing, test supersource but no prod supersource. GWT happens to use the prod .gwt.xml, so it looks for no supersource for tests, either. This causes it to fail to find AtomicLongMapTest. Our workaround is to tell GWT that util.concurrent and all other packages have prod supersource, even if they have none. GWT is happy to ignore us when we specify a nonexistent path. (I hope that this workaround does not cause its own problems in the future.) -->
|
/external/guava/guava-gwt/src/com/google/common/base/ |
Base.gwt.xml | 13 <!-- We used to set this only for packages that had manual supersource. That worked everywhere that I know of except for one place: when running the GWT util.concurrent tests under Guava. The problem is that GWT responds poorly to two .gwt.xml files in the same Java package: http://goo.gl/CO7dLB The summary is that it ignores one file in favor of the other. util.concurrent, like nearly all our packages, has two .gwt.xml files: one for prod and one for tests. util.concurrent, unlike our other packages, has, as of this writing, test supersource but no prod supersource. GWT happens to use the prod .gwt.xml, so it looks for no supersource for tests, either. This causes it to fail to find AtomicLongMapTest. Our workaround is to tell GWT that util.concurrent and all other packages have prod supersource, even if they have none. GWT is happy to ignore us when we specify a nonexistent path. (I hope that this workaround does not cause its own problems in the future.) -->
|
/external/guava/guava-gwt/src/com/google/common/cache/ |
Cache.gwt.xml | 13 <!-- We used to set this only for packages that had manual supersource. That worked everywhere that I know of except for one place: when running the GWT util.concurrent tests under Guava. The problem is that GWT responds poorly to two .gwt.xml files in the same Java package: http://goo.gl/CO7dLB The summary is that it ignores one file in favor of the other. util.concurrent, like nearly all our packages, has two .gwt.xml files: one for prod and one for tests. util.concurrent, unlike our other packages, has, as of this writing, test supersource but no prod supersource. GWT happens to use the prod .gwt.xml, so it looks for no supersource for tests, either. This causes it to fail to find AtomicLongMapTest. Our workaround is to tell GWT that util.concurrent and all other packages have prod supersource, even if they have none. GWT is happy to ignore us when we specify a nonexistent path. (I hope that this workaround does not cause its own problems in the future.) -->
|
/external/guava/guava-gwt/src/com/google/common/collect/ |
Collect.gwt.xml | 13 <!-- We used to set this only for packages that had manual supersource. That worked everywhere that I know of except for one place: when running the GWT util.concurrent tests under Guava. The problem is that GWT responds poorly to two .gwt.xml files in the same Java package: http://goo.gl/CO7dLB The summary is that it ignores one file in favor of the other. util.concurrent, like nearly all our packages, has two .gwt.xml files: one for prod and one for tests. util.concurrent, unlike our other packages, has, as of this writing, test supersource but no prod supersource. GWT happens to use the prod .gwt.xml, so it looks for no supersource for tests, either. This causes it to fail to find AtomicLongMapTest. Our workaround is to tell GWT that util.concurrent and all other packages have prod supersource, even if they have none. GWT is happy to ignore us when we specify a nonexistent path. (I hope that this workaround does not cause its own problems in the future.) -->
|
/external/guava/guava-gwt/src/com/google/common/escape/ |
Escape.gwt.xml | 13 <!-- We used to set this only for packages that had manual supersource. That worked everywhere that I know of except for one place: when running the GWT util.concurrent tests under Guava. The problem is that GWT responds poorly to two .gwt.xml files in the same Java package: http://goo.gl/CO7dLB The summary is that it ignores one file in favor of the other. util.concurrent, like nearly all our packages, has two .gwt.xml files: one for prod and one for tests. util.concurrent, unlike our other packages, has, as of this writing, test supersource but no prod supersource. GWT happens to use the prod .gwt.xml, so it looks for no supersource for tests, either. This causes it to fail to find AtomicLongMapTest. Our workaround is to tell GWT that util.concurrent and all other packages have prod supersource, even if they have none. GWT is happy to ignore us when we specify a nonexistent path. (I hope that this workaround does not cause its own problems in the future.) -->
|
/external/guava/guava-gwt/src/com/google/common/html/ |
Html.gwt.xml | 15 util.concurrent, like nearly all our packages, has two .gwt.xml files: one for prod and one for tests. 16 util.concurrent, unlike our other packages, has, as of this writing, test supersource but no prod supersource. 17 GWT happens to use the prod .gwt.xml, so it looks for no supersource for tests, either. 19 Our workaround is to tell GWT that util.concurrent and all other packages have prod supersource, even if they have none.
|
/external/guava/guava-gwt/src/com/google/common/io/ |
Io.gwt.xml | 13 <!-- We used to set this only for packages that had manual supersource. That worked everywhere that I know of except for one place: when running the GWT util.concurrent tests under Guava. The problem is that GWT responds poorly to two .gwt.xml files in the same Java package: http://goo.gl/CO7dLB The summary is that it ignores one file in favor of the other. util.concurrent, like nearly all our packages, has two .gwt.xml files: one for prod and one for tests. util.concurrent, unlike our other packages, has, as of this writing, test supersource but no prod supersource. GWT happens to use the prod .gwt.xml, so it looks for no supersource for tests, either. This causes it to fail to find AtomicLongMapTest. Our workaround is to tell GWT that util.concurrent and all other packages have prod supersource, even if they have none. GWT is happy to ignore us when we specify a nonexistent path. (I hope that this workaround does not cause its own problems in the future.) -->
|
/external/guava/guava-gwt/src/com/google/common/math/ |
Math.gwt.xml | 13 <!-- We used to set this only for packages that had manual supersource. That worked everywhere that I know of except for one place: when running the GWT util.concurrent tests under Guava. The problem is that GWT responds poorly to two .gwt.xml files in the same Java package: http://goo.gl/CO7dLB The summary is that it ignores one file in favor of the other. util.concurrent, like nearly all our packages, has two .gwt.xml files: one for prod and one for tests. util.concurrent, unlike our other packages, has, as of this writing, test supersource but no prod supersource. GWT happens to use the prod .gwt.xml, so it looks for no supersource for tests, either. This causes it to fail to find AtomicLongMapTest. Our workaround is to tell GWT that util.concurrent and all other packages have prod supersource, even if they have none. GWT is happy to ignore us when we specify a nonexistent path. (I hope that this workaround does not cause its own problems in the future.) -->
|
/external/guava/guava-gwt/src/com/google/common/primitives/ |
Primitives.gwt.xml | 13 <!-- We used to set this only for packages that had manual supersource. That worked everywhere that I know of except for one place: when running the GWT util.concurrent tests under Guava. The problem is that GWT responds poorly to two .gwt.xml files in the same Java package: http://goo.gl/CO7dLB The summary is that it ignores one file in favor of the other. util.concurrent, like nearly all our packages, has two .gwt.xml files: one for prod and one for tests. util.concurrent, unlike our other packages, has, as of this writing, test supersource but no prod supersource. GWT happens to use the prod .gwt.xml, so it looks for no supersource for tests, either. This causes it to fail to find AtomicLongMapTest. Our workaround is to tell GWT that util.concurrent and all other packages have prod supersource, even if they have none. GWT is happy to ignore us when we specify a nonexistent path. (I hope that this workaround does not cause its own problems in the future.) -->
|
/external/guava/guava-gwt/src/com/google/common/util/concurrent/ |
Concurrent.gwt.xml | 13 <!-- We used to set this only for packages that had manual supersource. That worked everywhere that I know of except for one place: when running the GWT util.concurrent tests under Guava. The problem is that GWT responds poorly to two .gwt.xml files in the same Java package: http://goo.gl/CO7dLB The summary is that it ignores one file in favor of the other. util.concurrent, like nearly all our packages, has two .gwt.xml files: one for prod and one for tests. util.concurrent, unlike our other packages, has, as of this writing, test supersource but no prod supersource. GWT happens to use the prod .gwt.xml, so it looks for no supersource for tests, either. This causes it to fail to find AtomicLongMapTest. Our workaround is to tell GWT that util.concurrent and all other packages have prod supersource, even if they have none. GWT is happy to ignore us when we specify a nonexistent path. (I hope that this workaround does not cause its own problems in the future.) -->
|
/external/guava/guava-gwt/src/com/google/common/xml/ |
Xml.gwt.xml | 15 util.concurrent, like nearly all our packages, has two .gwt.xml files: one for prod and one for tests. 16 util.concurrent, unlike our other packages, has, as of this writing, test supersource but no prod supersource. 17 GWT happens to use the prod .gwt.xml, so it looks for no supersource for tests, either. 19 Our workaround is to tell GWT that util.concurrent and all other packages have prod supersource, even if they have none.
|
/external/guava/guava-gwt/src/com/google/thirdparty/publicsuffix/ |
PublicSuffixPatterns.gwt.xml | 15 util.concurrent, like nearly all our packages, has two .gwt.xml files: one for prod and one for tests. 16 util.concurrent, unlike our other packages, has, as of this writing, test supersource but no prod supersource. 17 GWT happens to use the prod .gwt.xml, so it looks for no supersource for tests, either. 19 Our workaround is to tell GWT that util.concurrent and all other packages have prod supersource, even if they have none.
|