search for: __big_endian__

...universal binaries on Mac. It also highlights the configure-time versus compile-time endianess problem http://developer.apple.com/documentation/Porting/Conceptual/PortingUnix/compiling/chapter_4_section_3.html I have included a patch that applies Apple's recommendation to use the gcc-defined __BIG_ENDIAN__ preprocessor variable to determine endianness at compile-time. This technique works like a champ on Mac. It also works fine on Linux variants with modern a modern gcc. And Windows works like before. The patch was made against the head of the subversion trunk. Hope this helps. Pete --------------...

Well, I don't quite understand why AC_C_BIGENDIAN and the solution you're proposing is likely to break other big endian machines (the ones that don't have __BIG_ENDIAN__). Can you send a patch that addresses that (i.e. still uses AC_C_BIGENDIAN when it works)? Jean-Marc Peter Grayson a ?crit : > Hi all, > > Speex currently decides endianness at configure-time. This causes the > ppc half of Mac universal binaries to have some endianness problems. &gt...

On 5/2/07, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote: > Well, I don't quite understand why AC_C_BIGENDIAN and the solution > you're proposing is likely to break other big endian machines (the ones > that don't have __BIG_ENDIAN__). Can you send a patch that addresses > that (i.e. still uses AC_C_BIGENDIAN when it works)? It is not that AC_C_BIGENDIAN does not work. It is that it determines endianness at configure-time as opposed to compile-time. The process for building universal binaries on Mac demands that the distinc...

On 26 February 2014 14:44, Robert Lytton <robert at xmos.com> wrote: > This is related to a patch I submitted a little while ago (still pending): > http://llvm-reviews.chandlerc.com/D2760 > > If accepted, would it make this patch (and a others) unnecessary? Hi Robert, It is, but hijacking your patch a little, why not use __ORDER_LITTLE_ENDIAN__? Why do we need to create

...; made at compile-time. To enable building universal binaries on Mac in > a single pass, the decision has to be deferred to compile-time. I don't quite see the major difference between doing things at configure time or at compile time, bug anyway... > My strong suspicion is that testing __BIG_ENDIAN__ at compile-time > will work for all relevant unix-like platforms. Even icc supports > this. My suspicion is that I don't want to break things because MacOS X has strange requirements. > The extra thing we could do is set a preprocessor variable at > configure-time that we could us...

...e a cross-compilation endianness issue. Currently, Dovecot assumes that the endianness of the build system is the same as the endianness of the runtime system. This is not necessarily true. We ran into this while compiling for i386 on a ppc machine. The patch switches to using gcc's __BIG_ENDIAN__ macro; see the comment in the patch to configure.in. It also removes the related and unused MAIL_INDEX_COMPAT_FLAGS parameter. This patch may be applicable to other build environments with a little tweaking. -------------- next part -------------- An embedded and charset-unspecified text wa...

No luck there with modifying clang/lib/Basic/Targets.cpp unfortunately. I only modified BigEndian to 'true' and Builder.defineMacro to "__BIG_ENDIAN__" On Sat, Jul 7, 2012 at 2:34 AM, Anton Korobeynikov <anton at korobeynikov.info>wrote: > > Oh sorry, clang. > Then you should modify clang, not backends, look into Basic/Targets.cpp > there. > > PS: Note the "Reply All" button in your email client > >...

I'm trying to change the Endian of X86 from little to big in the TargetData. I only care about the way in which this effects the LLVM IR, not the actual backend code. I've changed the "e-" to "E-" in X86TargetMachine.cpp (where it sets the DataLayout) with no luck. Are there any other obvious places that I need to change this? The TargetData docs were somewhat helpful

...rsal build will only test the native build, not the cross-compiled build. As far as I am concerned, cross-compiled code that isn't tested is worse than native code that isn't tested and I consider native code that isn't tested to be broken code. > My strong suspicion is that testing __BIG_ENDIAN__ at compile-time > will work for all relevant unix-like platforms. Even icc supports > this. Yep, gcc and icc support it. How many others do? Is suspect its very close to zero. Erik -- ----------------------------------------------------------------- Erik de Castro Lopo --------------------...

...nlock_types.h) + */ +#include <linux/irqflags.h> +#include <asm/paravirt.h> +#ifdef CONFIG_PPC64 +#include <asm/paca.h> +#endif +#include <asm/synch.h> +#include <asm/ppc-opcode.h> + +#ifdef CONFIG_PPC64 +/* use 0x800000yy when locked, where yy == CPU number */ +#ifdef __BIG_ENDIAN__ +#define LOCK_TOKEN (*(u32 *)(&get_paca()->lock_token)) +#else +#define LOCK_TOKEN (*(u32 *)(&get_paca()->paca_index)) +#endif +#else +#define LOCK_TOKEN 1 +#endif + +static __always_inline int arch_spin_value_unlocked(arch_spinlock_t lock) +{ + return lock.slock == 0; +} + +static in...

it seems that this check does not work on solaris #if BYTE_ORDER != LITTLE_ENDIAN #define BYTE_SWAP #endif could you please check that BYTE_SWAP is defined in rijndael.c -m

...tested and I consider native code that > isn't tested to be broken code. Is it just the endianess issue or is it other ill-detected CPU features that cause the libsndfile test suite to fail? Again, your experience would be greatly appreciated. > > My strong suspicion is that testing __BIG_ENDIAN__ at compile-time > > will work for all relevant unix-like platforms. Even icc supports > > this. > > Yep, gcc and icc support it. How many others do? Is suspect > its very close to zero. You are probably right. My argument here was bogus. Although, didn't some features get...

I guess I should add this to the long list of things Apple has broken that used to work well on NEXTSTEP (the operating system that has been turned into OS X). Now that you mention it, I remember having a problem getting flac to cross-compile in one build step, so I just did the manual lipo glue that you talked about. I assumed it was only because I was too lazy to figure out how to

This series adds an option to use queued spinlocks for powerpc, and makes it the default for the Book3S-64 subarch. This effort starts with the generic code so it's very simple but still very performant. There are optimisations that can be made to slowpaths, but I think it's better to attack those incrementally if/when we find things, and try to add the improvements to generic code as

v2 is updated to account for feedback from Will, Peter, and Waiman (thank you), and trims off a couple of RFC and unrelated patches. Thanks, Nick Nicholas Piggin (6): powerpc/powernv: must include hvcall.h to get PAPR defines powerpc/pseries: move some PAPR paravirt functions to their own file powerpc: move spinlock implementation to simple_spinlock powerpc/64s: implement queued

Updated with everybody's feedback (thanks all), and more performance results. What I've found is I might have been measuring the worst load point for the paravirt case, and by looking at a range of loads it's clear that queued spinlocks are overall better even on PV, doubly so when you look at the generally much improved worst case latencies. I have defaulted it to N even though

v3 is updated to use __pv_queued_spin_unlock, noticed by Waiman (thank you). Thanks, Nick Nicholas Piggin (6): powerpc/powernv: must include hvcall.h to get PAPR defines powerpc/pseries: move some PAPR paravirt functions to their own file powerpc: move spinlock implementation to simple_spinlock powerpc/64s: implement queued spinlocks and rwlocks powerpc/pseries: implement paravirt

v3 is updated to use __pv_queued_spin_unlock, noticed by Waiman (thank you). Thanks, Nick Nicholas Piggin (6): powerpc/powernv: must include hvcall.h to get PAPR defines powerpc/pseries: move some PAPR paravirt functions to their own file powerpc: move spinlock implementation to simple_spinlock powerpc/64s: implement queued spinlocks and rwlocks powerpc/pseries: implement paravirt

WARNING: This is not compatible with the previous lz4 patchset. If you''re using experimental compression that isn''t in mainline kernels, be prepared to backup and restore or decompress before upgrading, and have backups in case it eats data (which appears not to be a problem any more, but has been during development). These patches add lz4 and lz4hc compression

Hi, so here it is, LZ4 compression method inside btrfs. The patchset is based on top of current Chris'' for-linus + Andi''s snappy implementation + the fixes from Li Zefan. Passes xfstests and stresstests. I haven''t measured performance on wide range of hardware or workloads, rather wanted to publish the patches before I get distracted again. I''d like to ask