similar to: Failed PPC64 compile when using Power7 loads and stores?

On Thu, Oct 24, 2019 at 2:22 PM Jinsong Ji <jji at us.ibm.com> wrote: > Looks like to me that your clang is too old. > > clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final) > > clang 3.8.0 was released on 08 Mar 2016. > > While vec_xl was added in https://reviews.llvm.org/rL286455 onNov 11 > 2016, which is around half an year later then 3.8.0. > > Can you

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, is there anybody here who has access to such a machine and could test errrr... 'some software' there? Please mail me privately. Thanks & best, Timo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFNQYqAfg746kcGBOwRArE2AJ4+qtS3i0V6a0Y6WocbpGZfne7Q/wCgsphj 1JcOBKH2RuleIQ3X80XFfT4= =AEdz -----END PGP

On 12/31/18 10:00 AM, christian.sonnemans at xs4all.nl wrote: > Is Centos 7 no longer supporter for IBM Power 7 machines witch uses centos > Big Endian 64 bits ? I'm not sure, but ppc64 is mentioned in "special notes" in the most recent release announcement for alt arch: https://lists.centos.org/pipermail/centos-announce/2018-December/023083.html

On 31/12/2018 19:00, christian.sonnemans at xs4all.nl wrote: > Hello Centos fellows, > > I liked to run Centos on my IBM Power7 machine and therefore I used to > download the images form: > > <http://isoredirect.centos.org/altarch/7/isos/ppc64/> > http://isoredirect.centos.org/altarch/7/isos/ppc64/ > > But not it seems that this link is not working: > The

Hello Centos fellows, I liked to run Centos on my IBM Power7 machine and therefore I used to download the images form: <http://isoredirect.centos.org/altarch/7/isos/ppc64/> http://isoredirect.centos.org/altarch/7/isos/ppc64/ But not it seems that this link is not working: The requested branch/release/arch/filename does not seem to be valid, please check your input Is Centos 7

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 Folks, Attached is a patch against the latest svn, plus new source files. This patch allows the specification of c or assembler versions of various functions at run time if _USE_SSE or _USE_ALTIVEC is specified at compile time. The basic concept is to use function pointers and preprocessor trickery to allow for run-time without changing how the other platforms work, esp. the platform function

At the LLVM Developers' Meeting in November, I promised to work on isolating a subset of the current test suite that is useful for benchmarking. Having looked at this in more detail, most of the applications and benchmarks in the test suite are useful for benchmarking, and so I think that a better way of phrasing it is that we should construct a list of programs in the test suite that are not

I'm getting the following error when compiling OpenCV 2.0 with OpenMP and SSE intrinsics enabled with GCC+DragonEgg(newest SVN version): /usr/lib64/ccache/c++ -Wall -Wno-long-long -pthread -ffunction-sections -D_GLIBCXX_PARALLEL -fopenmp -D__STDC_CONSTANT_MACROS -fplugin=/home/John/Documents/Project/DragonEgg/dragonegg/dragonegg.so -O3 -DNDEBUG -fomit-frame-pointer -O3 -ffast-math -mmmx

Jean-Marc, >I'm still not sure I get it. On an Athlon XP, I can do something like >"mulps xmm0, xmm1", which means that the xmm registers are indeed >supported. Besides, without the xmm registers, you can't use much of >SSE. In the Atholon XP 2400+ that we have in our QA lab (Win2000 ) if you run that code it generates an Illegal Instruction Error. In addition,

So we ran the code on a Windows XP based Atholon XP system and the xmm registers work just fine so it appears that Windows 2000 and below does not support them. We agree on not supporting the non-FP version, however the run time flags need to be settable with a non FP SSE mode so that exceptions are avoided. I thus propose a set of defines like this instead of the ones in our initial patch:

This is hopefully fixed in the latest version of dragonegg. Thanks for reporting it! Ciao, Duncan. On 15/02/11 20:54, sabaliauskas g. (gs5g08) wrote: > I'm getting the following error when compiling OpenCV 2.0 with OpenMP and SSE intrinsics enabled with GCC+DragonEgg(newest SVN version): > > /usr/lib64/ccache/c++ -Wall -Wno-long-long -pthread -ffunction-sections

I have downloaded and compiled the latest versions of LLVM and DragonEgg from SVN, but I still seem to get this same problem. I am using 64-bit Linux OS maybe the fix was only for 32-bit OS'es? ________________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] On Behalf Of Duncan Sands [baldrick at free.fr] Sent: Wednesday, February 16, 2011 5:14 PM