Closed
Bug 1409196
Opened 7 years ago
Closed 7 years ago
[clang] js/src/jit/arm64/AtomicOperations-arm64.h:124:5: error: address argument to atomic operation must be a pointer to a trivially-copyable type ('js::uint8_clamped *' invalid)
Categories
(Core :: JavaScript Engine: JIT, defect, P3)
Tracking
()
RESOLVED
FIXED
mozilla58
Tracking | Status | |
---|---|---|
firefox-esr52 | --- | unaffected |
firefox56 | --- | unaffected |
firefox57 | --- | fixed |
firefox58 | --- | fixed |
People
(Reporter: jbeich, Assigned: lth)
References
Details
(Keywords: regression)
Attachments
(2 files, 2 obsolete files)
23.92 KB,
text/plain
|
Details | |
2.24 KB,
patch
|
jbeich
:
feedback+
jcristau
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
$ c++ -v
FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM 5.0.0svn)
Target: aarch64-unknown-freebsd12.0
Thread model: posix
InstalledDir: /usr/bin
$ pkg install autoconf213 gmake python27 binutils mercurial
$ hg clone https://hg.mozilla.org/mozilla-central
$ cd mozilla-central/js/src
$ autoconf-2.13
$ ./configure --disable-jemalloc
$ gmake
[...]
/usr/bin/c++ -std=gnu++11 -o Unified_cpp_js_src36.o -c -I/tmp/mozilla-central/js/src/dist/system_wrappers -include /tmp/mozilla-central/config/gcc_hidden.h -DNDEBUG=1 -DTRIMMED=1 -DENABLE_BINARYDATA -DENABLE_SIMD -DENABLE_WASM_THREAD_OPS -DJS_CACHEIR_SPEW -DENABLE_SHARED_ARRAY_BUFFER -DEXPORT_JS_API -DMOZ_HAS_MOZGLUE -I/tmp/mozilla-central/js/src -I/tmp/mozilla-central/js/src/js/src -I/tmp/mozilla-central/js/src/dist/include -fPIC -DMOZILLA_CLIENT -include /tmp/mozilla-central/js/src/js/src/js-confdefs.h -MD -MP -MF .deps/Unified_cpp_js_src36.o.pp -Qunused-arguments -Qunused-arguments -Wall -Wc++11-compat -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wunreachable-code-return -Wwrite-strings -Wno-invalid-offsetof -Wclass-varargs -Wloop-analysis -Wc++11-compat-pedantic -Wc++14-compat -Wc++14-compat-pedantic -Wc++1z-compat -Wcomma -Wimplicit-fallthrough -Wstring-conversion -Wno-inline-new-delete -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wformat -Wno-gnu-zero-variadic-macro-arguments -Wformat-security -Wno-noexcept-type -Wno-unknown-warning-option -Wno-return-type-c-linkage -fno-rtti -fno-exceptions -fno-math-errno -pipe -g -O -fno-omit-frame-pointer -Wno-shadow -Werror=format -fno-strict-aliasing /tmp/mozilla-central/js/src/js/src/Unified_cpp_js_src36.cpp
In file included from /tmp/mozilla-central/js/src/js/src/Unified_cpp_js_src36.cpp:29:
In file included from /tmp/mozilla-central/js/src/vm/SelfHosting.cpp:40:
In file included from /tmp/mozilla-central/js/src/jit/AtomicOperations.h:393:
/tmp/mozilla-central/js/src/jit/arm64/AtomicOperations-arm64.h:124:5: error: address argument to
atomic operation must be a pointer to a trivially-copyable type ('js::uint8_clamped *' invalid)
__atomic_load(addr, &v, __ATOMIC_RELAXED);
^ ~~~~
/tmp/mozilla-central/js/src/jit/AtomicOperations.h:232:16: note: in instantiation of function
template specialization 'js::jit::AtomicOperations::loadSafeWhenRacy<js::uint8_clamped>'
requested here
return loadSafeWhenRacy(addr.unwrap());
^
/tmp/mozilla-central/js/src/vm/SelfHosting.cpp:1439:66: note: in instantiation of function template
specialization 'js::jit::AtomicOperations::loadSafeWhenRacy<js::uint8_clamped>' requested here
To(AtomicOperations::loadSafeWhenRacy(src++)));
^
/tmp/mozilla-central/js/src/vm/SelfHosting.cpp:1482:13: note: in instantiation of function template
specialization 'CopyValues<js::uint8_clamped, signed char>' requested here
CopyValues(dest, src.cast<uint8_clamped*>(), count);
^
/tmp/mozilla-central/js/src/vm/SelfHosting.cpp:1500:27: note: in instantiation of function template
specialization 'DisjointElements::copy<signed char>' requested here
DisjointElements::copy(dest.cast<int8_t*>(), src, srcType, count);
^
In file included from /tmp/mozilla-central/js/src/js/src/Unified_cpp_js_src36.cpp:29:
In file included from /tmp/mozilla-central/js/src/vm/SelfHosting.cpp:40:
In file included from /tmp/mozilla-central/js/src/jit/AtomicOperations.h:393:
/tmp/mozilla-central/js/src/jit/arm64/AtomicOperations-arm64.h:133:5: error: address argument to
atomic operation must be a pointer to a trivially-copyable type ('js::uint8_clamped *' invalid)
__atomic_store(addr, &val, __ATOMIC_RELAXED);
^ ~~~~
/tmp/mozilla-central/js/src/jit/AtomicOperations.h:237:16: note: in instantiation of function
template specialization 'js::jit::AtomicOperations::storeSafeWhenRacy<js::uint8_clamped>'
requested here
return storeSafeWhenRacy(addr.unwrap(), val);
^
/tmp/mozilla-central/js/src/vm/SelfHosting.cpp:1438:27: note: in instantiation of function template
specialization 'js::jit::AtomicOperations::storeSafeWhenRacy<js::uint8_clamped>' requested here
AtomicOperations::storeSafeWhenRacy(dest++,
^
/tmp/mozilla-central/js/src/vm/SelfHosting.cpp:1450:13: note: in instantiation of function template
specialization 'CopyValues<signed char, js::uint8_clamped>' requested here
CopyValues(dest, src.cast<int8_t*>(), count);
^
/tmp/mozilla-central/js/src/vm/SelfHosting.cpp:1540:27: note: in instantiation of function template
specialization 'DisjointElements::copy<js::uint8_clamped>' requested here
DisjointElements::copy(dest.cast<uint8_clamped*>(), src, srcType, count);
^
2 errors generated.
Regressed by https://hg.mozilla.org/mozilla-central/rev/48df1dbecdd8
Doesn't affect GCC 6.4.0.
Does automation use Clang on Android at all? For one, "Android 5.0 AArch64 opt" appears to use GCC 6.3.0.
Assignee | ||
Comment 2•7 years ago
|
||
This is a dumb bug that I fixed a couple of other places because of Clang, Aarch64 doesn't get much love though so it went unnoticed here. I'll fix it.
I don't know if we use Clang on Android, but let's ask Nathan; I think he keeps track of these things.
Assignee: nobody → lhansen
Flags: needinfo?(nfroyd)
32bit ARM is also affected:
$ c++ -v
FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM 5.0.0svn)
Target: armv6-unknown-freebsd12.0-gnueabihf
Thread model: posix
InstalledDir: /usr/bin
$ gmake
[...]
/usr/bin/c++ -std=gnu++11 -o Unified_cpp_js_src37.o -c -I/tmp/mozilla-central/js/src/dist/system_wrappers -include /tmp/mozilla-central/config/gcc_hidden.h -DNDEBUG=1 -DTRIMMED=1 -DENABLE_BINARYDATA -DENABLE_SIMD -DENABLE_WASM_THREAD_OPS -DJS_CACHEIR_SPEW -DENABLE_SHARED_ARRAY_BUFFER -DEXPORT_JS_API -DMOZ_HAS_MOZGLUE -I/tmp/mozilla-central/js/src -I/tmp/mozilla-central/js/src/js/src -I/tmp/mozilla-central/js/src/dist/include -fPIC -DMOZILLA_CLIENT -include /tmp/mozilla-central/js/src/js/src/js-confdefs.h -MD -MP -MF .deps/Unified_cpp_js_src37.o.pp -Qunused-arguments -Qunused-arguments -Wall -Wc++11-compat -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wunreachable-code-return -Wwrite-strings -Wno-invalid-offsetof -Wclass-varargs -Wloop-analysis -Wc++11-compat-pedantic -Wc++14-compat -Wc++14-compat-pedantic -Wc++1z-compat -Wcomma -Wimplicit-fallthrough -Wstring-conversion -Wno-inline-new-delete -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wformat -Wno-gnu-zero-variadic-macro-arguments -Wformat-security -Wno-noexcept-type -Wno-unknown-warning-option -Wno-return-type-c-linkage -fno-rtti -fno-exceptions -fno-math-errno -pipe -g -O -Wno-shadow -Werror=format -fno-strict-aliasing /tmp/mozilla-central/js/src/js/src/Unified_cpp_js_src37.cpp
In file included from /tmp/mozilla-central/js/src/js/src/Unified_cpp_js_src37.cpp:29:
In file included from /tmp/mozilla-central/js/src/vm/TypedArrayObject.cpp:7:
In file included from /tmp/mozilla-central/js/src/vm/TypedArrayObject-inl.h:24:
In file included from /tmp/mozilla-central/js/src/jit/AtomicOperations.h:387:
/tmp/mozilla-central/js/src/jit/arm/AtomicOperations-arm.h:153:25: error: cannot initialize a
parameter of type 'signed char *' with an rvalue of type 'volatile signed char *'
__atomic_load(addr, &v, __ATOMIC_RELAXED);
^~
/tmp/mozilla-central/js/src/jit/AtomicOperations.h:232:16: note: in instantiation of function
template specialization 'js::jit::AtomicOperations::loadSafeWhenRacy<volatile signed char>'
requested here
return loadSafeWhenRacy(addr.unwrap());
^
/tmp/mozilla-central/js/src/vm/TypedArrayObject-inl.h:161:43: note: in instantiation of function
template specialization 'js::jit::AtomicOperations::loadSafeWhenRacy<volatile signed char>'
requested here
return js::jit::AtomicOperations::loadSafeWhenRacy(addr);
^
/tmp/mozilla-central/js/src/vm/TypedArrayObject-inl.h:279:58: note: in instantiation of function
template specialization 'js::SharedOps::load<volatile signed char>' requested here
Ops::store(dest++, ConvertNumber<T>(Ops::load(src++)));
^
/tmp/mozilla-central/js/src/vm/TypedArrayObject.cpp:1466:47: note: in instantiation of member
function 'js::ElementSpecific<signed char, js::SharedOps>::setFromTypedArray' requested here
return ElementSpecific<T, SharedOps>::setFromTypedArray(target, source, offset);
^
/tmp/mozilla-central/js/src/vm/TypedArrayObject.cpp:1567:25: note: in instantiation of function
template specialization 'SetFromTypedArray<signed char>' requested here
JS_FOR_EACH_TYPED_ARRAY(SET_FROM_TYPED_ARRAY)
^
In file included from /tmp/mozilla-central/js/src/js/src/Unified_cpp_js_src37.cpp:29:
In file included from /tmp/mozilla-central/js/src/vm/TypedArrayObject.cpp:7:
In file included from /tmp/mozilla-central/js/src/vm/TypedArrayObject-inl.h:24:
In file included from /tmp/mozilla-central/js/src/jit/AtomicOperations.h:387:
/tmp/mozilla-central/js/src/jit/arm/AtomicOperations-arm.h:153:25: error: cannot initialize a
parameter of type 'unsigned char *' with an rvalue of type 'volatile unsigned char *'
__atomic_load(addr, &v, __ATOMIC_RELAXED);
^~
/tmp/mozilla-central/js/src/jit/AtomicOperations.h:232:16: note: in instantiation of function
template specialization 'js::jit::AtomicOperations::loadSafeWhenRacy<volatile unsigned char>'
requested here
return loadSafeWhenRacy(addr.unwrap());
^
/tmp/mozilla-central/js/src/vm/TypedArrayObject-inl.h:161:43: note: in instantiation of function
template specialization 'js::jit::AtomicOperations::loadSafeWhenRacy<volatile unsigned char>'
requested here
return js::jit::AtomicOperations::loadSafeWhenRacy(addr);
^
/tmp/mozilla-central/js/src/vm/TypedArrayObject-inl.h:286:58: note: in instantiation of function
template specialization 'js::SharedOps::load<volatile unsigned char>' requested here
Ops::store(dest++, ConvertNumber<T>(Ops::load(src++)));
^
/tmp/mozilla-central/js/src/vm/TypedArrayObject.cpp:1466:47: note: in instantiation of member
function 'js::ElementSpecific<signed char, js::SharedOps>::setFromTypedArray' requested here
return ElementSpecific<T, SharedOps>::setFromTypedArray(target, source, offset);
^
/tmp/mozilla-central/js/src/vm/TypedArrayObject.cpp:1567:25: note: in instantiation of function
template specialization 'SetFromTypedArray<signed char>' requested here
JS_FOR_EACH_TYPED_ARRAY(SET_FROM_TYPED_ARRAY)
^
In file included from /tmp/mozilla-central/js/src/js/src/Unified_cpp_js_src37.cpp:29:
In file included from /tmp/mozilla-central/js/src/vm/TypedArrayObject.cpp:7:
In file included from /tmp/mozilla-central/js/src/vm/TypedArrayObject-inl.h:24:
In file included from /tmp/mozilla-central/js/src/jit/AtomicOperations.h:387:
/tmp/mozilla-central/js/src/jit/arm/AtomicOperations-arm.h:153:25: error: cannot initialize a
parameter of type 'short *' with an rvalue of type 'volatile short *'
__atomic_load(addr, &v, __ATOMIC_RELAXED);
^~
/tmp/mozilla-central/js/src/jit/AtomicOperations.h:232:16: note: in instantiation of function
template specialization 'js::jit::AtomicOperations::loadSafeWhenRacy<volatile short>' requested
here
return loadSafeWhenRacy(addr.unwrap());
^
/tmp/mozilla-central/js/src/vm/TypedArrayObject-inl.h:161:43: note: in instantiation of function
template specialization 'js::jit::AtomicOperations::loadSafeWhenRacy<volatile short>' requested
here
return js::jit::AtomicOperations::loadSafeWhenRacy(addr);
^
/tmp/mozilla-central/js/src/vm/TypedArrayObject-inl.h:292:58: note: in instantiation of function
template specialization 'js::SharedOps::load<volatile short>' requested here
Ops::store(dest++, ConvertNumber<T>(Ops::load(src++)));
^
/tmp/mozilla-central/js/src/vm/TypedArrayObject.cpp:1466:47: note: in instantiation of member
function 'js::ElementSpecific<signed char, js::SharedOps>::setFromTypedArray' requested here
return ElementSpecific<T, SharedOps>::setFromTypedArray(target, source, offset);
^
/tmp/mozilla-central/js/src/vm/TypedArrayObject.cpp:1567:25: note: in instantiation of function
template specialization 'SetFromTypedArray<signed char>' requested here
JS_FOR_EACH_TYPED_ARRAY(SET_FROM_TYPED_ARRAY)
^
In file included from /tmp/mozilla-central/js/src/js/src/Unified_cpp_js_src37.cpp:29:
In file included from /tmp/mozilla-central/js/src/vm/TypedArrayObject.cpp:7:
In file included from /tmp/mozilla-central/js/src/vm/TypedArrayObject-inl.h:24:
In file included from /tmp/mozilla-central/js/src/jit/AtomicOperations.h:387:
/tmp/mozilla-central/js/src/jit/arm/AtomicOperations-arm.h:153:25: error: cannot initialize a
parameter of type 'unsigned short *' with an rvalue of type 'volatile unsigned short *'
__atomic_load(addr, &v, __ATOMIC_RELAXED);
^~
/tmp/mozilla-central/js/src/jit/AtomicOperations.h:232:16: note: in instantiation of function
template specialization 'js::jit::AtomicOperations::loadSafeWhenRacy<volatile unsigned short>'
requested here
return loadSafeWhenRacy(addr.unwrap());
^
/tmp/mozilla-central/js/src/vm/TypedArrayObject-inl.h:161:43: note: in instantiation of function
template specialization 'js::jit::AtomicOperations::loadSafeWhenRacy<volatile unsigned short>'
requested here
return js::jit::AtomicOperations::loadSafeWhenRacy(addr);
^
/tmp/mozilla-central/js/src/vm/TypedArrayObject-inl.h:298:58: note: in instantiation of function
template specialization 'js::SharedOps::load<volatile unsigned short>' requested here
Ops::store(dest++, ConvertNumber<T>(Ops::load(src++)));
^
/tmp/mozilla-central/js/src/vm/TypedArrayObject.cpp:1466:47: note: in instantiation of member
function 'js::ElementSpecific<signed char, js::SharedOps>::setFromTypedArray' requested here
return ElementSpecific<T, SharedOps>::setFromTypedArray(target, source, offset);
^
/tmp/mozilla-central/js/src/vm/TypedArrayObject.cpp:1567:25: note: in instantiation of function
template specialization 'SetFromTypedArray<signed char>' requested here
JS_FOR_EACH_TYPED_ARRAY(SET_FROM_TYPED_ARRAY)
^
In file included from /tmp/mozilla-central/js/src/js/src/Unified_cpp_js_src37.cpp:29:
In file included from /tmp/mozilla-central/js/src/vm/TypedArrayObject.cpp:7:
In file included from /tmp/mozilla-central/js/src/vm/TypedArrayObject-inl.h:24:
In file included from /tmp/mozilla-central/js/src/jit/AtomicOperations.h:387:
/tmp/mozilla-central/js/src/jit/arm/AtomicOperations-arm.h:153:25: error: cannot initialize a
parameter of type 'int *' with an rvalue of type 'volatile int *'
__atomic_load(addr, &v, __ATOMIC_RELAXED);
^~
/tmp/mozilla-central/js/src/jit/AtomicOperations.h:232:16: note: in instantiation of function
template specialization 'js::jit::AtomicOperations::loadSafeWhenRacy<volatile int>' requested
here
return loadSafeWhenRacy(addr.unwrap());
^
/tmp/mozilla-central/js/src/vm/TypedArrayObject-inl.h:161:43: note: in instantiation of function
template specialization 'js::jit::AtomicOperations::loadSafeWhenRacy<volatile int>' requested
here
return js::jit::AtomicOperations::loadSafeWhenRacy(addr);
^
/tmp/mozilla-central/js/src/vm/TypedArrayObject-inl.h:304:58: note: in instantiation of function
template specialization 'js::SharedOps::load<volatile int>' requested here
Ops::store(dest++, ConvertNumber<T>(Ops::load(src++)));
^
/tmp/mozilla-central/js/src/vm/TypedArrayObject.cpp:1466:47: note: in instantiation of member
function 'js::ElementSpecific<signed char, js::SharedOps>::setFromTypedArray' requested here
return ElementSpecific<T, SharedOps>::setFromTypedArray(target, source, offset);
^
/tmp/mozilla-central/js/src/vm/TypedArrayObject.cpp:1567:25: note: in instantiation of function
template specialization 'SetFromTypedArray<signed char>' requested here
JS_FOR_EACH_TYPED_ARRAY(SET_FROM_TYPED_ARRAY)
^
In file included from /tmp/mozilla-central/js/src/js/src/Unified_cpp_js_src37.cpp:29:
In file included from /tmp/mozilla-central/js/src/vm/TypedArrayObject.cpp:7:
In file included from /tmp/mozilla-central/js/src/vm/TypedArrayObject-inl.h:24:
In file included from /tmp/mozilla-central/js/src/jit/AtomicOperations.h:387:
/tmp/mozilla-central/js/src/jit/arm/AtomicOperations-arm.h:153:25: error: cannot initialize a
parameter of type 'unsigned int *' with an rvalue of type 'volatile unsigned int *'
__atomic_load(addr, &v, __ATOMIC_RELAXED);
^~
/tmp/mozilla-central/js/src/jit/AtomicOperations.h:232:16: note: in instantiation of function
template specialization 'js::jit::AtomicOperations::loadSafeWhenRacy<volatile unsigned int>'
requested here
return loadSafeWhenRacy(addr.unwrap());
^
/tmp/mozilla-central/js/src/vm/TypedArrayObject-inl.h:161:43: note: in instantiation of function
template specialization 'js::jit::AtomicOperations::loadSafeWhenRacy<volatile unsigned int>'
requested here
return js::jit::AtomicOperations::loadSafeWhenRacy(addr);
^
/tmp/mozilla-central/js/src/vm/TypedArrayObject-inl.h:310:58: note: in instantiation of function
template specialization 'js::SharedOps::load<volatile unsigned int>' requested here
Ops::store(dest++, ConvertNumber<T>(Ops::load(src++)));
^
/tmp/mozilla-central/js/src/vm/TypedArrayObject.cpp:1466:47: note: in instantiation of member
function 'js::ElementSpecific<signed char, js::SharedOps>::setFromTypedArray' requested here
return ElementSpecific<T, SharedOps>::setFromTypedArray(target, source, offset);
^
/tmp/mozilla-central/js/src/vm/TypedArrayObject.cpp:1567:25: note: in instantiation of function
template specialization 'SetFromTypedArray<signed char>' requested here
JS_FOR_EACH_TYPED_ARRAY(SET_FROM_TYPED_ARRAY)
^
In file included from /tmp/mozilla-central/js/src/js/src/Unified_cpp_js_src37.cpp:29:
In file included from /tmp/mozilla-central/js/src/vm/TypedArrayObject.cpp:7:
In file included from /tmp/mozilla-central/js/src/vm/TypedArrayObject-inl.h:24:
In file included from /tmp/mozilla-central/js/src/jit/AtomicOperations.h:387:
/tmp/mozilla-central/js/src/jit/arm/AtomicOperations-arm.h:153:25: error: cannot initialize a
parameter of type 'float *' with an rvalue of type 'volatile float *'
__atomic_load(addr, &v, __ATOMIC_RELAXED);
^~
/tmp/mozilla-central/js/src/jit/AtomicOperations.h:232:16: note: in instantiation of function
template specialization 'js::jit::AtomicOperations::loadSafeWhenRacy<volatile float>' requested
here
return loadSafeWhenRacy(addr.unwrap());
^
/tmp/mozilla-central/js/src/vm/TypedArrayObject-inl.h:161:43: note: in instantiation of function
template specialization 'js::jit::AtomicOperations::loadSafeWhenRacy<volatile float>' requested
here
return js::jit::AtomicOperations::loadSafeWhenRacy(addr);
^
/tmp/mozilla-central/js/src/vm/TypedArrayObject-inl.h:316:58: note: in instantiation of function
template specialization 'js::SharedOps::load<volatile float>' requested here
Ops::store(dest++, ConvertNumber<T>(Ops::load(src++)));
^
/tmp/mozilla-central/js/src/vm/TypedArrayObject.cpp:1466:47: note: in instantiation of member
function 'js::ElementSpecific<signed char, js::SharedOps>::setFromTypedArray' requested here
return ElementSpecific<T, SharedOps>::setFromTypedArray(target, source, offset);
^
/tmp/mozilla-central/js/src/vm/TypedArrayObject.cpp:1567:25: note: in instantiation of function
template specialization 'SetFromTypedArray<signed char>' requested here
JS_FOR_EACH_TYPED_ARRAY(SET_FROM_TYPED_ARRAY)
^
In file included from /tmp/mozilla-central/js/src/js/src/Unified_cpp_js_src37.cpp:29:
In file included from /tmp/mozilla-central/js/src/vm/TypedArrayObject.cpp:7:
In file included from /tmp/mozilla-central/js/src/vm/TypedArrayObject-inl.h:24:
In file included from /tmp/mozilla-central/js/src/jit/AtomicOperations.h:387:
/tmp/mozilla-central/js/src/jit/arm/AtomicOperations-arm.h:153:25: error: cannot initialize a
parameter of type 'double *' with an rvalue of type 'volatile double *'
__atomic_load(addr, &v, __ATOMIC_RELAXED);
^~
/tmp/mozilla-central/js/src/jit/AtomicOperations.h:232:16: note: in instantiation of function
template specialization 'js::jit::AtomicOperations::loadSafeWhenRacy<volatile double>'
requested here
return loadSafeWhenRacy(addr.unwrap());
^
/tmp/mozilla-central/js/src/vm/TypedArrayObject-inl.h:161:43: note: in instantiation of function
template specialization 'js::jit::AtomicOperations::loadSafeWhenRacy<volatile double>'
requested here
return js::jit::AtomicOperations::loadSafeWhenRacy(addr);
^
/tmp/mozilla-central/js/src/vm/TypedArrayObject-inl.h:322:58: note: in instantiation of function
template specialization 'js::SharedOps::load<volatile double>' requested here
Ops::store(dest++, ConvertNumber<T>(Ops::load(src++)));
^
/tmp/mozilla-central/js/src/vm/TypedArrayObject.cpp:1466:47: note: in instantiation of member
function 'js::ElementSpecific<signed char, js::SharedOps>::setFromTypedArray' requested here
return ElementSpecific<T, SharedOps>::setFromTypedArray(target, source, offset);
^
/tmp/mozilla-central/js/src/vm/TypedArrayObject.cpp:1567:25: note: in instantiation of function
template specialization 'SetFromTypedArray<signed char>' requested here
JS_FOR_EACH_TYPED_ARRAY(SET_FROM_TYPED_ARRAY)
^
8 errors generated.
Regressed by https://hg.mozilla.org/mozilla-central/rev/b6401fe90774
![]() |
||
Comment 4•7 years ago
|
||
We don't use clang on Android (yet), but I'm guessing https://bugzilla.mozilla.org/attachment.cgi?id=8910424 -- from the bug that will add the appropriate support -- would fix this.
Flags: needinfo?(nfroyd)
(In reply to Nathan Froyd [:froydnj] from comment #4)
> https://bugzilla.mozilla.org/attachment.cgi?id=8910424
Thanks. With the patch JS standalone built fine on armv6 but still failed on aarch64.
![]() |
||
Updated•7 years ago
|
status-firefox56:
unaffected → ---
status-firefox57:
affected → ---
status-firefox58:
affected → ---
status-firefox-esr52:
unaffected → ---
Priority: -- → P3
> status-firefox-esr52: unaffected → ---
> status-firefox56: unaffected → ---
> status-firefox57: affected → ---
> status-firefox58: affected → ---
Is bug 1146817 going to be backed out? GCC is dangerous to use on FreeBSD because it forces libstdc++ which can lead to crashes if mixed with dependencies built with Clang which uses libc++.
I already set Platform bugzilla field appropriately. Why do you need to pretend this is not a regression? Just setting Priority should have been enough.
Assignee | ||
Comment 7•7 years ago
|
||
(In reply to Jan Beich from comment #6)
> > status-firefox-esr52: unaffected → ---
> > status-firefox56: unaffected → ---
> > status-firefox57: affected → ---
> > status-firefox58: affected → ---
>
> Is bug 1146817 going to be backed out?
It will not be backed out.
The appropriate fix is to resolve this problem. There are ways to do that, I just need to find the time to put the patch together.
Assignee | ||
Comment 8•7 years ago
|
||
(In reply to Jan Beich from comment #5)
> (In reply to Nathan Froyd [:froydnj] from comment #4)
> > https://bugzilla.mozilla.org/attachment.cgi?id=8910424
>
> Thanks. With the patch JS standalone built fine on armv6 but still failed on
> aarch64.
Yeah, these are two different problems entirely.
Assignee | ||
Comment 9•7 years ago
|
||
Jan, can you see if this fixes your problem on ARM64? Thanks.
Attachment #8919912 -
Flags: feedback?(jbeich)
Reporter | ||
Comment 10•7 years ago
|
||
Comment on attachment 8919912 [details] [diff] [review]
bug1409196-arm64-atomics-fix.patch
In file included from objdir/js/src/Unified_cpp_js_src43.cpp:2:
In file included from js/src/wasm/WasmSignalHandlers.cpp:25:
In file included from js/src/jit/AtomicOperations.h:393:
js/src/jit/arm64/AtomicOperations-arm64.h:130:8: error: unknown type name
'uint8_clamped'
inline uint8_clamped
^
js/src/jit/arm64/AtomicOperations-arm64.h:131:45: error: unknown type name
'uint8_clamped'
js::jit::AtomicOperations::loadSafeWhenRacy(uint8_clamped* addr)
^
js/src/jit/arm64/AtomicOperations-arm64.h:135:12: error: use of undeclared
identifier 'uint8_clamped'
return uint8_clamped(v);
^
js/src/jit/arm64/AtomicOperations-arm64.h:149:46: error: unknown type name
'uint8_clamped'
js::jit::AtomicOperations::storeSafeWhenRacy(uint8_clamped* addr, uint8_clamped val)
^
js/src/jit/arm64/AtomicOperations-arm64.h:149:67: error: unknown type name
'uint8_clamped'
js::jit::AtomicOperations::storeSafeWhenRacy(uint8_clamped* addr, uint8_clamped val)
^
In file included from objdir/js/src/Unified_cpp_js_src0.cpp:2:
In file included from js/src/builtin/AtomicsObject.cpp:60:
In file included from js/src/jit/AtomicOperations.h:393:
js/src/jit/arm64/AtomicOperations-arm64.h:130:8: error: unknown type name
'uint8_clamped'
inline uint8_clamped
^
js/src/jit/arm64/AtomicOperations-arm64.h:131:45: error: use of undeclared
identifier 'uint8_clamped'; did you mean 'Scalar::Uint8Clamped'?
js::jit::AtomicOperations::loadSafeWhenRacy(uint8_clamped* addr)
^~~~~~~~~~~~~
Scalar::Uint8Clamped
js/src/jsfriendapi.h:1611:5: note: 'Scalar::Uint8Clamped' declared here
Uint8Clamped,
^
In file included from objdir/js/src/Unified_cpp_js_src0.cpp:2:
In file included from js/src/builtin/AtomicsObject.cpp:60:
In file included from js/src/jit/AtomicOperations.h:393:
js/src/jit/arm64/AtomicOperations-arm64.h:129:1: error: extraneous 'template<>'
in declaration of variable 'loadSafeWhenRacy'
template<>
^~~~~~~~~~
js/src/jit/arm64/AtomicOperations-arm64.h:130:1: warning: inline variables are a
C++17 extension [-Wc++17-extensions]
inline uint8_clamped
^
js/src/jit/arm64/AtomicOperations-arm64.h:131:60: error: use of undeclared
identifier 'addr'
js::jit::AtomicOperations::loadSafeWhenRacy(uint8_clamped* addr)
^
js/src/jit/arm64/AtomicOperations-arm64.h:131:65: error: expected ';' at end of
declaration
js::jit::AtomicOperations::loadSafeWhenRacy(uint8_clamped* addr)
^
;
js/src/jit/arm64/AtomicOperations-arm64.h:132:1: error: expected unqualified-id
{
^
js/src/jit/arm64/AtomicOperations-arm64.h:149:46: error: use of undeclared
identifier 'uint8_clamped'; did you mean 'Scalar::Uint8Clamped'?
js::jit::AtomicOperations::storeSafeWhenRacy(uint8_clamped* addr, uint8_clamped val)
^~~~~~~~~~~~~
Scalar::Uint8Clamped
js/src/jsfriendapi.h:1611:5: note: 'Scalar::Uint8Clamped' declared here
Uint8Clamped,
^
In file included from objdir/js/src/Unified_cpp_js_src0.cpp:2:
In file included from js/src/builtin/AtomicsObject.cpp:60:
In file included from js/src/jit/AtomicOperations.h:393:
js/src/jit/arm64/AtomicOperations-arm64.h:147:1: error: extraneous 'template<>'
in declaration of variable 'storeSafeWhenRacy'
template<>
^~~~~~~~~~
js/src/jit/arm64/AtomicOperations-arm64.h:148:1: warning: inline variables are a
C++17 extension [-Wc++17-extensions]
inline void
^
js/src/jit/arm64/AtomicOperations-arm64.h:149:28: error: variable has incomplete
type 'void'
js::jit::AtomicOperations::storeSafeWhenRacy(uint8_clamped* addr, uint8_clamped val)
^
js/src/jit/arm64/AtomicOperations-arm64.h:149:81: error: expected ')'
js::jit::AtomicOperations::storeSafeWhenRacy(uint8_clamped* addr, uint8_clamped val)
^
js/src/jit/arm64/AtomicOperations-arm64.h:149:45: note: to match this '('
js::jit::AtomicOperations::storeSafeWhenRacy(uint8_clamped* addr, uint8_clamped val)
^
js/src/jit/arm64/AtomicOperations-arm64.h:149:61: error: use of undeclared
identifier 'addr'
js::jit::AtomicOperations::storeSafeWhenRacy(uint8_clamped* addr, uint8_clamped val)
^
js/src/jit/arm64/AtomicOperations-arm64.h:149:67: error: use of undeclared
identifier 'uint8_clamped'
js::jit::AtomicOperations::storeSafeWhenRacy(uint8_clamped* addr, uint8_clamped val)
^
js/src/jit/arm64/AtomicOperations-arm64.h:149:85: error: expected ';' at end of
declaration
js::jit::AtomicOperations::storeSafeWhenRacy(uint8_clamped* addr, uint8_clamped val)
^
;
js/src/jit/arm64/AtomicOperations-arm64.h:150:1: error: expected unqualified-id
{
^
5 errors generated.
In file included from js/src/vm/Interpreter.cpp:37:
In file included from js/src/jit/AtomicOperations.h:393:
js/src/jit/arm64/AtomicOperations-arm64.h:130:8: error: unknown type name
'uint8_clamped'; did you mean 'js::uint8_clamped'?
inline uint8_clamped
^~~~~~~~~~~~~
js::uint8_clamped
js/src/vm/ArrayBufferObject.h:458:8: note: 'js::uint8_clamped' declared here
struct uint8_clamped {
^
Attachment #8919912 -
Flags: feedback?(jbeich) → feedback-
Reporter | ||
Comment 11•7 years ago
|
||
(In reply to Lars T Hansen [:lth] from comment #7)
> (In reply to Jan Beich from comment #6)
> > > status-firefox-esr52: unaffected → ---
> > > status-firefox56: unaffected → ---
> > > status-firefox57: affected → ---
> > > status-firefox58: affected → ---
> >
> > Is bug 1146817 going to be backed out?
>
> It will not be backed out.
>
> The appropriate fix is to resolve this problem. There are ways to do that,
> I just need to find the time to put the patch together.
Well, I'm not rushing. P3 is perfectly fine for a Tier3 platform but unsetting status-firefox* is counter-productive when trying to track why Firefox doesn't build on the specific configuration. Ideally, the build fix would be backported to Firefox 57.
On FreeBSD side aarch64 is going to be a Tier1 architecture soon. It doesn't carry a lot of legacy baggage (e.g. NEON detection), so easier to make complex apps like Firefox build. And Firefox did build fine up until 56.0* when someone downstream broke Rust bootstrap on older FreeBSD releases. This means until the package builders switch to newer FreeBSD release after 2017-10-26 I don't even know if 56.0 builts fine on aarch64 but 57.0 certainly wouldn't until this bug is fixed.
http://thunderx1.nyi.freebsd.org/data/latest-per-pkg/firefox/55.0.3_1%2C1/110arm64-quarterly.log
(In reply to Lars T Hansen [:lth] from comment #8)
> (In reply to Jan Beich from comment #5)
> > (In reply to Nathan Froyd [:froydnj] from comment #4)
> > > https://bugzilla.mozilla.org/attachment.cgi?id=8910424
> >
> > Thanks. With the patch JS standalone built fine on armv6 but still failed on
> > aarch64.
>
> Yeah, these are two different problems entirely.
OK. Should I file a separate bug for comment 3 to explicitly track that regression? Bug 1163171 isn't clear when it will land and would probably have no chance being backported to Firefox 57.
Assignee | ||
Comment 12•7 years ago
|
||
Sorry about that, I botched the test compilation locally. I hope this works better.
Attachment #8919912 -
Attachment is obsolete: true
Attachment #8919926 -
Flags: feedback?(jbeich)
Assignee | ||
Comment 13•7 years ago
|
||
(In reply to Jan Beich from comment #11)
>
> Ideally, the build fix
> would be backported to Firefox 57.
If we get it to build I'll request an uplift; the risk to Tier-1 platforms is zero.
> OK. Should I file a separate bug for comment 3 to explicitly track that
> regression? Bug 1163171 isn't clear when it will land and would probably
> have no chance being backported to Firefox 57.
IMO since the patch has been r+'d on that bug and is a very localized fix we should just try to get that patch landed, even if the rest of the patches on that bug may not be ready. Nathan, any objections to my landing it?
Flags: needinfo?(nfroyd)
Reporter | ||
Comment 14•7 years ago
|
||
Comment on attachment 8919926 [details] [diff] [review]
bug1409196-arm64-atomics-fix-v2.patch
I confirm, this version fixes build on FreeBSD aarch64. jsapi-tests runs fine but crashes just after testIntlAvailableLocales, probably unrelated.
Attachment #8919926 -
Flags: feedback?(jbeich) → feedback+
Reporter | ||
Comment 15•7 years ago
|
||
> jsapi-tests runs fine but crashes just after testIntlAvailableLocales, probably unrelated.
After building on the oldest supported FreeBSD release the issue went away. Attaching jsapi-tests output for reference.
![]() |
||
Comment 16•7 years ago
|
||
(In reply to Jan Beich from comment #6)
> > status-firefox-esr52: unaffected → ---
> > status-firefox56: unaffected → ---
> > status-firefox57: affected → ---
> > status-firefox58: affected → ---
>
> Is bug 1146817 going to be backed out? GCC is dangerous to use on FreeBSD
> because it forces libstdc++ which can lead to crashes if mixed with
> dependencies built with Clang which uses libc++.
>
> I already set Platform bugzilla field appropriately. Why do you need to
> pretend this is not a regression? Just setting Priority should have been
> enough.
Bugs tagged as regressions and affected for various Firefox releases show up in release management queries, so I'm guessing Jim was basically removing this from such queries, since it's a Tier3 platform from a release management point of view. I don't think the Platform field factors into such queries...so I'm unsure if there's a good way to track things that FreeBSD would like to see fixed for the new release.
(In reply to Lars T Hansen [:lth] from comment #13)
> (In reply to Jan Beich from comment #11)
> > OK. Should I file a separate bug for comment 3 to explicitly track that
> > regression? Bug 1163171 isn't clear when it will land and would probably
> > have no chance being backported to Firefox 57.
>
> IMO since the patch has been r+'d on that bug and is a very localized fix we
> should just try to get that patch landed, even if the rest of the patches on
> that bug may not be ready. Nathan, any objections to my landing it?
I have no objections to that.
Flags: needinfo?(nfroyd)
Reporter | ||
Comment 17•7 years ago
|
||
(In reply to Nathan Froyd [:froydnj] from comment #16)
> Bugs tagged as regressions and affected for various Firefox releases show up
> in release management queries, so I'm guessing Jim was basically removing
> this from such queries, since it's a Tier3 platform from a release
> management point of view. I don't think the Platform field factors into
> such queries...so I'm unsure if there's a good way to track things that
> FreeBSD would like to see fixed for the new release.
Would "fix-optional" have worked instead? See bug 1384423 as an example. I'm just not sure bug reporters (like me) are supposed to touch Priority or set "fix-optional".
![]() |
||
Comment 18•7 years ago
|
||
(In reply to Jan Beich from comment #17)
> (In reply to Nathan Froyd [:froydnj] from comment #16)
> > Bugs tagged as regressions and affected for various Firefox releases show up
> > in release management queries, so I'm guessing Jim was basically removing
> > this from such queries, since it's a Tier3 platform from a release
> > management point of view. I don't think the Platform field factors into
> > such queries...so I'm unsure if there's a good way to track things that
> > FreeBSD would like to see fixed for the new release.
>
> Would "fix-optional" have worked instead? See bug 1384423 as an example. I'm
> just not sure bug reporters (like me) are supposed to touch Priority or set
> "fix-optional".
fix-optional definitely gets it off the tracking queries that I'm aware of. It looks like you have editbugs privileges, which means that you have the power to twiddle any fields you like on bugs, and that we trust you to use those powers for good. :) Priority is usually set by the triage owner of the component; if you'd like to set it yourself, P3 is a good choice.
status-firefox56:
--- → unaffected
status-firefox57:
--- → fix-optional
status-firefox58:
--- → fix-optional
status-firefox-esr52:
--- → unaffected
Assignee | ||
Comment 19•7 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/617d05862317a1eec424fc4d13d29b1e32b4bb63
Bug 1409196 - Specialize loadSafeWhenRacy and storeSafeWhenRacy on arm64 for uint8_clamped to pacify Clang. f=jbeich, r=me
Comment 20•7 years ago
|
||
Pushed by lhansen@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/617d05862317
Specialize loadSafeWhenRacy and storeSafeWhenRacy on arm64 for uint8_clamped to pacify Clang. f=jbeich, r=me
Assignee | ||
Comment 21•7 years ago
|
||
Also pushed the ARM fix, see comment 11 et seq.
Comment 22•7 years ago
|
||
I have backed out this for failing js/src/jit/arm64/AtomicOperations-arm64.h
https://hg.mozilla.org/integration/mozilla-inbound/rev/4ab3e3cccd1fe5481247d93d6e190f05f1beb6f5
https://treeherder.mozilla.org/logviewer.html#?job_id=138208743&repo=mozilla-inbound&lineNumber=4656
Flags: needinfo?(lhansen)
Assignee | ||
Comment 23•7 years ago
|
||
Weird error about specializing in the wrong namespace, which is weird. I sort of see why that can be an issue, but it's still a mystery. More testing needed locally then on our build systems and then again on the freebsd build systems before I can try to land this again. May be a few days before I have time.
Flags: needinfo?(lhansen)
Assignee | ||
Comment 24•7 years ago
|
||
Reporter | ||
Comment 25•7 years ago
|
||
https://hg.mozilla.org/try/rev/fe715ddc38cf also built fine on FreeBSD aarch64 with Clang 4.0/5.0
Assignee | ||
Comment 26•7 years ago
|
||
The problem is that technically the specializations have to appear within the namespace of the template they are specializing, it is not sufficient to annotate the specialization with the correct namespace qualification. I had forgotten this. Compilers allow this rule to be broken but since we build with warnings-as-errors I could not land the patch.
Attached is the same patch as before but with the specializations properly wrapped in namespaces, it builds properly on our build systems. Jan, can you check that this still compiles for you?
Attachment #8919926 -
Attachment is obsolete: true
Attachment #8920528 -
Flags: feedback?(jbeich)
Reporter | ||
Comment 27•7 years ago
|
||
Comment on attachment 8920528 [details] [diff] [review]
bug1409196-arm64-atomics-fix-v3.patch
> Jan, can you check that this still compiles for you?
The patch looks the same as what hit Try, see comment 25. It does fix the error in comment 0. I did double-check, though.
--enable-warnings-as-errors is also clean apart from unrelated bug 1379523.
Attachment #8920528 -
Flags: feedback?(jbeich) → feedback+
Assignee | ||
Comment 28•7 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/820a0316d83d7988f0f83f154c5381f688c103f8
Bug 1409196 - Specialize loadSafeWhenRacy and storeSafeWhenRacy on arm64 for uint8_clamped to pacify Clang. f=jbeich, r=me
![]() |
||
Comment 29•7 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
Assignee | ||
Comment 30•7 years ago
|
||
Comment on attachment 8920528 [details] [diff] [review]
bug1409196-arm64-atomics-fix-v3.patch
Approval Request Comment
[Feature/Bug causing the regression]:
Bug 1146817.
[User impact if declined]:
FreeBSD will have to maintain a fork in order to compile FF57 on ARM64.
[Is this code covered by automated tests?]:
Compilation failure only, no tests needed.
[Has the fix been verified in Nightly?]:
We're not directly affected because this is a Clang-only problem and we don't compile with Clang on ARM64 yet.
[Needs manual test from QE? If yes, steps to reproduce]:
No.
[List of other uplifts needed for the feature/fix]:
None.
[Is the change risky?]:
No.
[Why is the change risky/not risky?]:
We don't ship ARM64 FF yet and this is an ARM64-only file.
[String changes made/needed]:
None.
Attachment #8920528 -
Flags: approval-mozilla-beta?
Comment 31•7 years ago
|
||
Comment on attachment 8920528 [details] [diff] [review]
bug1409196-arm64-atomics-fix-v3.patch
build fix for tier3 clang/arm64, beta57+
Attachment #8920528 -
Flags: approval-mozilla-beta? → approval-mozilla-beta+
Comment 32•7 years ago
|
||
bugherder uplift |
You need to log in
before you can comment on or make changes to this bug.
Description
•