You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@statementreply observed that arm64_neon.h declares a zillion non-_Ugly identifiers and macros.
We should consider doing something about this. Possibilities:
@CaseyCarter suggested extracting a small subheader (possibly into intrin0.h itself) with just what the STL needs. This would also be good for x86/x64 emmintrin.h.
Wait for vNext and after /clr:pure is erased from human memory, go back to @statementreply's original separately compiled design, which avoids this identifier pollution.
Hybrid approach: Continue to use the header-only, non-intrinsic code for /clr:pure, but separately compile the intrinsics for use by native and /clr code. (The only reason I didn't try this was time pressure.)
The text was updated successfully, but these errors were encountered:
While performing surgery on #935 to make it header-only for
/clr:pure
compatibility, I made<complex>
drag inarm64_neon.h
:STL/stl/inc/complex
Lines 23 to 32 in 19c683d
@statementreply observed that
arm64_neon.h
declares a zillion non-_Ugly
identifiers and macros.We should consider doing something about this. Possibilities:
intrin0.h
itself) with just what the STL needs. This would also be good for x86/x64emmintrin.h
./clr:pure
is erased from human memory, go back to @statementreply's original separately compiled design, which avoids this identifier pollution./clr:pure
, but separately compile the intrinsics for use by native and/clr
code. (The only reason I didn't try this was time pressure.)The text was updated successfully, but these errors were encountered: