dom/base/nsTextFragmentGeneric.h:16:70: error: incomplete type ‘xsimd::batch<short int, xsimd::sse2>’ used in nested name specifier
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr102 | --- | unaffected |
| firefox112 | --- | wontfix |
| firefox113 | --- | wontfix |
| firefox114 | --- | fixed |
People
(Reporter: glandium, Assigned: sergesanspaille)
References
(Regression)
Details
(Keywords: regression)
Attachments
(2 files)
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
5.53 KB,
patch
|
Details | Diff | Splinter Review |
Similar to bug 1822901, but for i386 Linux after bug 1811184.
/<<PKGBUILDDIR>>/dom/base/nsTextFragmentGeneric.h: In function ‘int32_t mozilla::FirstNon8Bit(const char16_t*, const char16_t*)’:
/<<PKGBUILDDIR>>/dom/base/nsTextFragmentGeneric.h:38:16: error: ‘any’ is not a member of ‘xsimd’
38 | if (xsimd::any((vect & vectmask) != 0)) return i;
| ^~~
/<<PKGBUILDDIR>>/dom/base/nsTextFragmentGeneric.h: In instantiation of ‘int32_t mozilla::FirstNon8Bit(const char16_t*, const char16_t*) [with Arch = xsimd::sse2; int32_t = int]’:
/<<PKGBUILDDIR>>/dom/base/nsTextFragment.cpp:183:46: required from here
/<<PKGBUILDDIR>>/dom/base/nsTextFragmentGeneric.h:16:70: error: incomplete type ‘xsimd::batch<short int, xsimd::sse2>’ used in nested name specifier
16 | const uint32_t numUnicharsPerVector = xsimd::batch<int16_t, Arch>::size;
| ^~~~
/<<PKGBUILDDIR>>/dom/base/nsTextFragmentGeneric.h:35:31: error: ‘xsimd::batch<short int, xsimd::sse2> vectmask’ has incomplete type
35 | xsimd::batch<int16_t, Arch> vectmask(static_cast<int16_t>(shortMask));
| ^~~~~~~~
/<<PKGBUILDDIR>>/dom/base/nsTextFragmentGeneric.h:37:64: error: incomplete type ‘xsimd::batch<short int, xsimd::sse2>’ used in nested name specifier
37 | const auto vect = xsimd::batch<int16_t, Arch>::load_aligned(str + i);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 2•3 years ago
|
||
Set release status flags based on info from the regressing bug 1811184
Comment 3•3 years ago
|
||
:kmag could you please set the severity on this to evaluate it for 112?
Comment 4•3 years ago
|
||
We typically don't assign severities to bugs that don't directly affect end users, but I suppose if this is preventing us from shipping to i386 Linux, it qualifies.
That said, if the failure landed and wasn't backed out, it presumably isn't breaking builds on automation, and therefore doesn't affect any of our tier 1 or 2 platforms. Let me know if I'm wrong.
Comment 5•3 years ago
|
||
(In reply to Kris Maglione [:kmag] from comment #4)
We typically don't assign severities to bugs that don't directly affect end users, but I suppose if this is preventing us from shipping to i386 Linux, it qualifies.
That said, if the failure landed and wasn't backed out, it presumably isn't breaking builds on automation, and therefore doesn't affect any of our tier 1 or 2 platforms. Let me know if I'm wrong.
Thank you! This answers my question regarding 112, so I'm marking this as wontfix for 112.
My understanding is that all defect bugs should have the severity set.
| Assignee | ||
Comment 6•3 years ago
|
||
Mike, can you share the flags used to compile that file? Looks like our headers think we have sse2 but xsimd disagrees.
| Reporter | ||
Comment 7•3 years ago
|
||
It's reproducible with the following mozconfig:
ac_add_options --target=i686
export CXXFLAGS=-no-sse
(You need to apply the patch from https://bugzilla.mozilla.org/show_bug.cgi?id=1729459#c25 too)
The problem is that xsimd does want sse enabled, but the code that uses it is not compiled with SSE_FLAGS (because it's not SSE-specific code), while being behind the ifdef that works for code that may use sse via runtime detection.
| Assignee | ||
Comment 8•3 years ago
|
||
Only provide forward declaration to the generic code.
Updated•3 years ago
|
| Assignee | ||
Comment 9•3 years ago
|
||
| Assignee | ||
Comment 10•3 years ago
|
||
Note: to test my change, I had to apply the attached patch m32.patch , which involves more than the patch you quoted
| Reporter | ||
Comment 11•3 years ago
|
||
(In reply to [:sergesanspaille] from comment #10)
Note: to test my change, I had to apply the attached patch
m32.patch, which involves more than the patch you quoted
Probably because of the CXXFLAGS=-no-sse, which is an unnatural way to reproduce.
Updated•3 years ago
|
Comment 12•3 years ago
|
||
Comment 13•3 years ago
|
||
Backed out changeset 5055804013a2 (bug 1827566) for causing build bustage at nsTextFragmentGenericFwd.h
Backout: https://hg.mozilla.org/integration/autoland/rev/c0289365efbe4dea3bdf9de486e272051132f650
Failure log: https://treeherder.mozilla.org/logviewer?job_id=413553109&repo=autoland&lineNumber=7274
Updated•3 years ago
|
Comment 14•3 years ago
|
||
Comment 15•3 years ago
|
||
Backed out changeset db920151d68a (bug 1827566) for causing build bustages at nsTextFragmentGenericFwd.h
Backout: https://hg.mozilla.org/integration/autoland/rev/7b8dc255cf898f693e00bb4209b02c15722ac1d1
Failure log: https://treeherder.mozilla.org/logviewer?job_id=413588125&repo=autoland&lineNumber=7556
| Assignee | ||
Comment 16•3 years ago
|
||
Sorry Cristina, I relanded a version that passes OSX build a few minutes ago (associated try build: https://treeherder.mozilla.org/jobs?repo=try&revision=28a845ad3d970e9a871157ad3e9146acc0611949)
Comment 17•3 years ago
|
||
Comment 18•3 years ago
|
||
| bugherder | ||
Comment 19•3 years ago
|
||
The patch landed in nightly and beta is affected.
:sergesanspaille, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- If no, please set
status-firefox113towontfix.
For more information, please visit auto_nag documentation.
| Assignee | ||
Updated•3 years ago
|
Description
•