search for: __i686__

...x.cmake:125 (message): Cannot compile for i686: CMakeError.log attached On Wed, Jul 22, 2015 at 8:20 AM, Alexey Samsonov <vonosmas at gmail.com> wrote: > The problem is we "guess" that the host architecture is i686, and fail > when we find out that we can't target it (__i686__ is not defined). > This guess originates from get_host_triple() call > in cmake/modules/GetHostTriple.cmake. > Probably, it makes sense to fix that to return i568 on openSUSE, and then > test for i586 in the same way we already test for i386/i686. > > > On Fri, Jul 17, 2015 at...

Seems on OpenSUSE x86, it's called i586, not i686 :-( +Alexey: do you think we can handle this in the compiler-rt cmake files somehow? Maybe try targeting both i686 and i586 unless that would break something else? On Fri, Jul 17, 2015 at 1:31 AM, Nikola Smiljanic <popizdeh at gmail.com> wrote: > CMake Error at projects/compiler-rt/cmake/config-ix.cmake:125 (message): > Cannot

...he developers of rsync seem to assume that only x86 CPUs can handle memory misalignments: ```c /* We know that the x86 can handle misalignment and has the same ?* byte order (LSB-first) as the 32-bit numbers we transmit. */ #if defined __i386__ || defined __i486__ || defined __i586__ || defined __i686__ || __amd64 #define CAREFUL_ALIGNMENT 0 #endif #ifndef CAREFUL_ALIGNMENT #define CAREFUL_ALIGNMENT 1 #endif ``` Thus, when copying 4-bit integers (just an example), rsync uses direct copies on x86: ```c static inline uint32 IVALu(const uchar *buf, int pos) { ?? ?union { ?? ???? const uchar *b...

...ad -- Looking for pthread_create in pthread - found -- Looking for __cxa_throw in c++ -- Looking for __cxa_throw in c++ - not found -- Looking for __cxa_throw in stdc++ -- Looking for __cxa_throw in stdc++ - found The Cmake script does not appear to move on to other tests like "-- Looking for __i686__" (if https://lists.llvm.org/pipermail/llvm-dev/2016-December/108363.html is accurate). Any ideas what might be going sideways? Thanks in advance.

...for shm_open in rt -- Looking for shm_open in rt - found -- Looking for pow in m -- Looking for pow in m - found -- Looking for pthread_create in pthread -- Looking for pthread_create in pthread - found -- Looking for __cxa_throw in stdc++ -- Looking for __cxa_throw in stdc++ - found -- Looking for __i686__ -- Looking for __i686__ - found -- Looking for __i386__ -- Looking for __i386__ - found -- Compiler-RT supported architectures: x86_64 -- Looking for rpc/xdr.h -- Looking for rpc/xdr.h - found -- Looking for tirpc/rpc/xdr.h -- Looking for tirpc/rpc/xdr.h - not found -- Performing Test COMPILER_RT_T...

I had only a quick view on the blog-texts. It might be that a CLANG generated with LTO/PGO speeds up the build. Can you confirm this? Can you confirm binutils-gold speed up the build? Has LLVM an own linker? Can be used? Speedup the build? Yesterday night I loooked through available CMAKE/LLVM variables... ### GOLD # CMAKE_LINKER:FILEPATH=/usr/bin/ld #

Hello, Le 12/12/2016 à 18:29, Hans Wennborg a écrit : > +Sylvestre who knows about these things. > > On Thu, Dec 8, 2016 at 2:24 AM, Kris van Rens via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> L.S., >> >> I'm currently in the process of creating Debian packages for >> clang/llvm release 3.9.0. For this I'm using the steps as explained on

On Mon, Mar 14, 2016 at 5:30 PM, Chris Bieneman <cbieneman at apple.com> wrote: [ brutal-snip ] ... > [ TODO#S: Before doing a 2nd build (and in a 3rd run using more > optimized binaries) ] > > How do I anable LTO via CMAKE? > > > LLVM_ENALBLE_LTO=On > [ v4 of my build-script attached ] Hi Chris, thanks for the response! That seems to work (see below). $ cd

Trying to run a self host "ninja check-clang" with ASan enabled I hit a /lot/ of errors like this (strangely I hit none of these in check-llvm, only in check-clang): Any ideas? ==10525==ERROR: AddressSanitizer failed to deallocate 0x10800 (67584) bytes at address 0x631000014800 ==10525==AddressSanitizer CHECK failed:

...clude/python2.7][v2.7.6()] //Details about finding SWIG FIND_PACKAGE_MESSAGE_DETAILS_SWIG:INTERNAL=[/usr/bin/swig2.0][/usr/share/swig2.0][v2.0.11()] //Details about finding Threads FIND_PACKAGE_MESSAGE_DETAILS_Threads:INTERNAL=[TRUE][v()] //Have symbol __i386__ HAS_i386_DEF:INTERNAL=1 //Have symbol __i686__ HAS_i686_DEF:INTERNAL= //Have symbol backtrace HAVE_BACKTRACE:INTERNAL=1 //Have include CrashReporterClient.h HAVE_CRASHREPORTERCLIENT_H:INTERNAL= //Test HAVE_CXX_ATOMICS64_WITHOUT_LIB HAVE_CXX_ATOMICS64_WITHOUT_LIB:INTERNAL=1 //Test HAVE_CXX_ATOMICS_WITHOUT_LIB HAVE_CXX_ATOMICS_WITHOUT_LIB:INTERNA...