similar to: Compiling for IOS and warnings

On Sat, Dec 02, 2023 at 10:24:57PM +0300, Vitaly Chikunov wrote: > JFYI. I am not sure it's worth reporting but, when building 2.5.5 for ALT Talking of small inconsistencies, 2.5.5 isn't a Xapian version... > I noticed small inconsistencies in configure output. > > 1. xapian-binding: > > checking for /usr/bin/rdoc... no > checking for rdoc... /usr/bin/rdoc >

The PowerPC-related changes in FLAC 1.3.3 have caused some portability problems. libFLAC/cpu.c assumes that the <sys/auxv.h> header and the getauxval() function are universally available on PowerPC platforms. They are not. On FreeBSD/powerpc, <sys/auxv.h> is available, but getauxval() is not. Equivalent functionality is provided by elf_aux_info(). On OpenBSD/powerpc, neither is

Hi, I''m trying to configure QoS on my linux in the following manner: I have a main link with 64K, so I divided it in 3 classes of 18K, 14K and 9K with an excess (not used for classified traffic, just to be shared) of 23K. This excess should be distributed proportonally among the 3 classes, that is, the class that has more rate should borrow more bandwidth. What is happening is

Erik de Castro Lopo wrote: > When should FLAC__HAS_X86INTRIN be defined? What header file should I be > checking for? Ah, should be checking for <x86intrin.h>. The rest seems to be coming together. Testing this now. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

1) in config.h FLAC__HAS_X86INTRIN macro is always defined and empty, even if x86intrin.h is not available. 2) sse_os is defined as 'yes' or 'no', but AM_CONDITIONAL tests it for 'true': AM_CONDITIONAL(FLaC__SSE_OS, test "x$sse_os" = xtrue) It seems that it should be changed to AM_CONDITIONAL(FLaC__SSE_OS, test "x$sse_os" = xyes) 3) configure

lvqcl wrote: > lvqcl wrote: > > > 1) in config.h FLAC__HAS_X86INTRIN macro is always defined and empty, > > even if x86intrin.h is not available. > > > > 2) sse_os is defined as 'yes' or 'no', but AM_CONDITIONAL tests it for 'true': > > The patch is attached. Please check it. Looks good. I need to do a little testing. > > 3)

Hi, JFYI. I am not sure it's worth reporting but, when building 2.5.5 for ALT I noticed small inconsistencies in configure output. 1. xapian-binding: checking for /usr/bin/rdoc... no checking for rdoc... /usr/bin/rdoc Looks curious but no problem since it's found anyway. 2. xapian-core when built with GCC: checking whether __builtin_add_overflow is declared... yes ...

Sorry in advance for the limited details. I have a build of a recent (Monday) llvm/clang which I have installed in the expected way in my environment but I am getting failures like this; In file included from <some directory>/lib/clang/stable/include/x86intrin.h:29: In file included from <some directory>/lib/clang/stable/include/immintrin.h:118: <some

Given they in separate repos, is there a way to to verify which revisions go together? Is it enough that the clang (shortly) after llvm in time? On 2/5/19, 1:03 PM, "Eric Christopher" <echristo at gmail.com> wrote: Your clang and your llvm don't match, they're often version locked and you need to make sure both of them are the same-ish revision. -eric

I'm getting compile errors because size_t is getting redefined. My "forced include file" starts with: #if BUILDING_FOR_WINDOWS #define NOMINMAX /* deal with the fact that windef.h also defines BOOL */ #define BOOL WINBOOL #include <windows.h> #include <intrin.h> #undef BOOL #endif Looking at the preprocessor expansion of a typical .cpp file, I see that crtdefs.h

Hi, I love llvm vectors, yet I wonder why some advanced vector operations are specific to some CPU targets? Let me take an example: /// Horizontally adds the adjacent pairs of values contained in two /// 128-bit vectors of [4 x float]. /// /// \headerfile <x86intrin.h> /// /// This intrinsic corresponds to the <c> VHADDPS </c> instruction. /// /// \param __a /// A

Erik de Castro Lopo wrote: > Erik de Castro Lopo wrote: > > > When should FLAC__HAS_X86INTRIN be defined? What header file should I be > > checking for? > > Ah, should be checking for <x86intrin.h>. > > The rest seems to be coming together. Testing this now. There is a segfault happening in the new code when compiling with -DDEBUG. Trying to track it down.

lvqcl wrote: > 1) in config.h FLAC__HAS_X86INTRIN macro is always defined and empty, > even if x86intrin.h is not available. > > 2) sse_os is defined as 'yes' or 'no', but AM_CONDITIONAL tests it for 'true': The patch is attached. Please check it. > 3) configure --disable-sse prints: > " SSE optimizations : ................... no" >

Erik de Castro Lopo wrote: > This is also a little misleading as its not the OS we are checking > for SSE support but the compiler. I'll fix this. How so? ./configure script tests a compiler by checking the existence of x86intrin.h. If the file exist then it is assumed that a compiler supports SSE intrinsics. --enable-sse results in a definition of FLAC__SSE_OS preprocessor variable.

> lvqcl wrote: > >> 1) in config.h FLAC__HAS_X86INTRIN macro is always defined and empty, >> even if x86intrin.h is not available. >> >> 2) sse_os is defined as 'yes' or 'no', but AM_CONDITIONAL tests it for 'true': > > The patch is attached. Please check it. Ping. Is the fix of FLAC__HAS_X86INTRIN definition necessary? Anyway I think

Building 1.3.2 on OpenBSD/i386, I get this error: cpu.c: In function 'ia32_cpu_info': cpu.c:128: error: 'FLAC__CPUINFO_IA32_CPUID_SSE3' undeclared (first use in this function) cpu.c:128: error: (Each undeclared identifier is reported only once cpu.c:128: error: for each function it appears in.) cpu.c:129: error: 'FLAC__CPUINFO_IA32_CPUID_SSSE3' undeclared (first use in

Hi to all. Where can I see workingexamples of the Prototype Javascript framework? Thank you very much. Sergio --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe

Hello all, I would like to propose adding the -mprefer-avx256 and -mprefer-avx128 command line flags supported by latest GCC to clang. These flags will be used to limit the vector register size presented by TTI to the vectorizers. The backend will still be able to use wider registers for code written using the instrinsics in x86intrin.h. And the backend will still be able to use AVX512VL

_mm_lfence was originally documented as a load fence. But in light of speculative execution vulnerabilities it has started being advertised as a way to prevent speculative execution. Current Intel Software Development Manual documents it as "Specifically, LFENCE does not execute until all prior instructions have completed locally, and no later instruction begins execution until LFENCE

Hi Reid, I copied the x64 toolsets by hand; they got installed to C:\Program Files (x86)\LLVM\tools\msbuild\x64; they just didn't get moved correctly by install.bat. I just verified that the LLVM-vs2013 toolset.props is correct. If it is a bitness problem, perhaps I'm failing to define something correctly? Regards, Eric On 9/30/14, 11:29 AM, Reid Kleckner wrote: > This looks