search for: __clang_major__

After this patch, all FLAC__SSEN_SUPPORTED variables are undefined for GCC, so intrinsic versions of functions are not compiled into libFLAC. Previously, the code was: #if defined __INTEL_COMPILER // definitions for ICC #elif defined _MSC_VER // definitions for MSVC #elif defined __GNUC__ || defined __clang__ #if defined __clang__ && __has_attribute(__target__) //

...FILE_MAGIC_32 (uint64_t)255 << 56 | (uint64_t)'l' << 48 | \ + (uint64_t)'p' << 40 | (uint64_t)'r' << 32 | (uint64_t)'o' << 24 | \ + (uint64_t)'f' << 16 | (uint64_t)'R' << 8 | (uint64_t)129 + +#if __clang_major__ >= 4 || (__clang_major__ == 3 && __clang_minor__ == 9) +#define LLVM_PROFILE_VERSION 4 +#define LLVM_PROFILE_NUM_KINDS 2 +#else +#error "clang version not supported with coverage" +#endif + +struct llvm_profile_data { + uint64_t name_ref; + uint64_t function_hash; +...

...ng an #if checking the version (which of course ought to be avoided when possible, but is sometimes the best answer), it is more difficult than it needs to be to do the right thing. E.g., a check like this will erroneously think that trunk, now, is Clang 7, and has fixed this hypothetical bug. #if __clang_major__ >= 7 // Do something which was buggy before Clang 7. #endif I see a couple alternatives for improving this: 1. Change the way we version trunk. After creating release branch for X.0, change trunk to version X.99 instead of (X+1).0. Thus, trunk would always have a .99 minor release. The releas...

...ing the version (which of course ought to be avoided when possible, but is sometimes the best answer), it is more difficult than it needs to be to do the right thing. > > E.g., a check like this will erroneously think that trunk, now, is Clang 7, and has fixed this hypothetical bug. > #if __clang_major__ >= 7 > // Do something which was buggy before Clang 7. > #endif > > I see a couple alternatives for improving this: > > 1. Change the way we version trunk. > > After creating release branch for X.0, change trunk to version X.99 instead of (X+1).0. Thus, trunk would...

Erik de Castro Lopo wrote: > the bug *before* the logic is evaluated. My current solution in > the above PR is to avoid `__has_attribute` and use this: > > #elif defined __clang__ && (__clang_major__ > 3 || \ > (__clang_major__ == 3 && __clang_minor__ >= 6)) /* clang */ > > which I have tested with clang 3.6. If someone has an earlier version > of clang and can verify that it work, I'll drop the version number. Maybe it's simpler to add #ifndef __h...

Hello, The following patch series enables LLVM coverage support for the Xen hypervisor. This first patches are a re-organization of the gcov support, in order to make the support generic for all coverage technologies. This is mostly a name change from gcov -> cov in several places and files, together with the addition of a Kconfig option in order to enable LLVM coverage. Patch 7 introduces

...ught to be > avoided when possible, but is sometimes the best answer), it is > more difficult than it needs to be to do the right thing. > > E.g., a check like this will erroneously think that trunk, now, is > Clang 7, and has fixed this hypothetical bug. > #if __clang_major__ >= 7 > // Do something which was buggy before Clang 7. > #endif > > I see a couple alternatives for improving this: > > 1. Change the way we version trunk. > > After creating release branch for X.0, change trunk to version > X.99 instead of (X+1...

...n (which of course ought to be avoided when possible, > but is sometimes the best answer), it is more difficult than it needs to be > to do the right thing. > > E.g., a check like this will erroneously think that trunk, now, is Clang > 7, and has fixed this hypothetical bug. > #if __clang_major__ >= 7 > // Do something which was buggy before Clang 7. > #endif > > I see a couple alternatives for improving this: > > 1. Change the way we version trunk. > > After creating release branch for X.0, change trunk to version X.99 > instead of (X+1).0. Thus, trunk would a...

...ut the libFLAC macros.h. It checks for GNUC 4.3+, but emcc is apparently based on a clang 3.9.0 which identifies itself as GNUC 4.2.1. It does support the statement expression used for flac_max. So perhaps you could add a different condition; something like (…) || (defined(__clang__) && (__clang_major__ > 3 || \ (__clang_major__ == 3 && __clang_minor__ >= 9))) 2. Min and max macros I'm also surprised by the degree of variation here. flac_max uses a statement expression. flac_min relies on some preprocessor magic and the __COUNTER__ macro instead. For non-gcc-4.3...

...ng an #if checking the version (which of course ought to be avoided when possible, but is sometimes the best answer), it is more difficult than it needs to be to do the right thing. E.g., a check like this will erroneously think that trunk, now, is Clang 7, and has fixed this hypothetical bug. #if __clang_major__ >= 7 // Do something which was buggy before Clang 7. #endif I see a couple alternatives for improving this: 1. Change the way we version trunk. After creating release branch for X.0, change trunk to version X.99 instead of (X+1).0. Thus, trunk would always have a .99 minor release. The releas...

...ing the version (which of course ought to be avoided when possible, but is sometimes the best answer), it is more difficult than it needs to be to do the right thing. > > E.g., a check like this will erroneously think that trunk, now, is Clang 7, and has fixed this hypothetical bug. > #if __clang_major__ >= 7 > // Do something which was buggy before Clang 7. > #endif Yes, this is often done in the FreeBSD ports system, sometimes using the major version in the source, but more often in Makefiles, where the X.Y.Z version is condensed to just 'XY', as shown in https://github.com/free...

...ng alignment faults on the movdqa instructions. For reference, the clang version I used for this is: | Android clang version 5.0.300080 (based on LLVM 5.0.300080) | Target: x86_64-unknown-linux If we think enough people use older versions of clang, a version of the patch that looked at __clang_major__ and friends seems fair. -- Ray 826% diff -c *old *new *** pitch_sse4_1.s-old 2017-08-18 13:51:39.359084637 -0700 --- pitch_sse4_1.s-new 2017-08-18 13:51:54.595106450 -0700 *************** *** 73,80 **** cmpl $4, %eax jl .LBB0_8 # BB#7: ! movdqa (%edx,%edi,2), %xmm2 ! movdqa (%esi,%edi,2), %...

...rse ought to be avoided when > possible, but is sometimes the best answer), it is more difficult than it > needs to be to do the right thing. > > > > E.g., a check like this will erroneously think that trunk, now, is Clang > 7, and has fixed this hypothetical bug. > > #if __clang_major__ >= 7 > > // Do something which was buggy before Clang 7. > > #endif > > Yes, this is often done in the FreeBSD ports system, sometimes using the > major version in the source, but more often in Makefiles, where the X.Y.Z > version is condensed to just 'XY', as sho...

We see the MOVQ instruction but this patch deliberately uses it rather than MOVQDA (load 128-bits aligned). We were seeing that with the trace below, the final invocation is not 128-bit aligned but MOVQDA insists on it (the calling function was pitch_sse4_1.c:90, in the 4-way N - i >= 4 loop). 07-31 11:00:13.469 210 2540 <(469)%20210-2540> D opus_sse1: RBE celt_inner_prod_sse4_1: x

...sion (which of course ought to be avoided when possible, but is sometimes the best answer), it is more difficult than it needs to be to do the right thing. >> >> E.g., a check like this will erroneously think that trunk, now, is Clang 7, and has fixed this hypothetical bug. >> #if __clang_major__ >= 7 >> // Do something which was buggy before Clang 7. >> #endif >> > > >> I see a couple alternatives for improving this: >> >> 1. Change the way we version trunk. >> >> After creating release branch for X.0, change trunk to version X.99 in...

...ng alignment faults on the movdqa instructions. For reference, the clang version I used for this is: | Android clang version 5.0.300080 (based on LLVM 5.0.300080) | Target: x86_64-unknown-linux If we think enough people use older versions of clang, a version of the patch that looked at __clang_major__ and friends seems fair. -- Ray 826% diff -c *old *new *** pitch_sse4_1.s-old 2017-08-18 13:51:39.359084637 -0700 --- pitch_sse4_1.s-new 2017-08-18 13:51:54.595106450 -0700 *************** *** 73,80 **** cmpl $4, %eax jl .LBB0_8 # BB#7: ! movdqa (%edx,%edi,2), %xmm2 ! movdqa (%esi,%edi,2), %...

...es Y Knight [suggests](http://lists.llvm.org/pipermail/llvm-dev/2018-January/120087.html) changing the versioning scheme for the current 'trunk' version. He observes that incrementing the major version immediately upon branching means it's difficult to write reliable checks such as `#if __clang_major__ >= 7`. * Hideki Saito is [looking](http://lists.llvm.org/pipermail/llvm-dev/2018-January/120164.html) for feedback on moving the `isLegalMasked*` checks to LoopVectorizationCostModel. * Nemanja Ivanovic is [seeking feedback](http://lists.llvm.org/pipermail/llvm-dev/2018-January/120171.html) on...