Closed Bug 1827566 Opened 3 years ago Closed 3 years ago

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)

defect

Tracking

()

RESOLVED FIXED
114 Branch
Tracking Status
firefox-esr102 --- unaffected
firefox112 --- wontfix
firefox113 --- wontfix
firefox114 --- fixed

People

(Reporter: glandium, Assigned: sergesanspaille)

References

(Regression)

Details

(Keywords: regression)

Attachments

(2 files)

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);
      |                       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~
Flags: needinfo?(sguelton)

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.

Component: General → DOM: Core & HTML

Set release status flags based on info from the regressing bug 1811184

:kmag could you please set the severity on this to evaluate it for 112?

Flags: needinfo?(kmaglione+bmo)

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.

Severity: -- → S3
Flags: needinfo?(kmaglione+bmo)

(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.

Mike, can you share the flags used to compile that file? Looks like our headers think we have sse2 but xsimd disagrees.

Flags: needinfo?(sguelton) → needinfo?(mh+mozilla)

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.

Flags: needinfo?(mh+mozilla)

Only provide forward declaration to the generic code.

Assignee: nobody → sguelton
Status: NEW → ASSIGNED
Attached patch m32.patchSplinter Review

Note: to test my change, I had to apply the attached patch m32.patch , which involves more than the patch you quoted

(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.

Pushed by sguelton@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/5055804013a2 Isolate SSE2 requirements to SSE-compiled file r=glandium
Attachment #9329005 - Attachment description: Bug 1827566 - Isolate SSE2 requirements to SSE-compiled file r=glandium,padenot → Bug 1827566 - Isolate SSE2 requirements to SSE-compiled file r=glandium
Pushed by sguelton@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/db920151d68a Isolate SSE2 requirements to SSE-compiled file r=glandium

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)

Flags: needinfo?(sguelton)
Pushed by sguelton@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/66811b9fe888 Isolate SSE2 requirements to SSE-compiled file r=glandium
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 114 Branch

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-firefox113 to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(sguelton)
Flags: needinfo?(sguelton)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: