Am 09.08.2015 um 20:08 schrieb Jose Fonseca: > On 09/08/15 17:47, Matt Turner wrote: >> On Sun, Aug 9, 2015 at 3:57 AM, Jose Fonseca <jfons...@vmware.com> wrote: >>> Neither MSVC nor MinGW defines LONG_BIT. For MSVC this was not a >>> problem as >>> it doesn't define __x86_64__ macro (it's GCC specific.) >>> >>> However on Windows long type is guaranteed to be 32bits. >>> >>> Also add an #error, as GCC will just warn, not throw any error, when no >>> value is returned. >>> >>> Trivial. >>> --- >>> src/util/rounding.h | 8 ++++++-- >>> 1 file changed, 6 insertions(+), 2 deletions(-) >>> >>> diff --git a/src/util/rounding.h b/src/util/rounding.h >>> index b0c9918..ec31b47 100644 >>> --- a/src/util/rounding.h >>> +++ b/src/util/rounding.h >>> @@ -96,8 +96,10 @@ _mesa_lroundevenf(float x) >>> #ifdef __x86_64__ >>> #if LONG_BIT == 64 >>> return _mm_cvtss_si64(_mm_load_ss(&x)); >>> -#elif LONG_BIT == 32 >>> +#elif LONG_BIT == 32 || defined(_WIN32) >> >> Not clear to me that you want to do this, since on x86-32 using SSE >> intrinsics will force a few memory transfers to and from the x87 FPU. > > Our Windows builds use SSE math for x86. (ie., -fpmath=sse for GCC, no > option required for MSVC, as it's the standard.) So no x87 should be > ever used. > > (Probably it should make sense to use -msse2 and -fpmath=sse on all > 32bits x86.) > >> >>> return _mm_cvtss_si32(_mm_load_ss(&x)); >>> +#else >>> +#error "Unsupported or undefined LONG_BIT" >> >> MSVC... sigh. > > The problem was actually with MinGW, not MSVC. As the commit > description said, MSVC was fine (because it doesn't define __x86_64__). > > AFAICT, LONG_BIT is not standard C. So I don't think that MSVC or MinGW > is at fault. > > Jose
Apparently it's not even always defined on linux... I wonder if soething like #if LONG_MAX == 0x7FFFFFFFL would be more portable... Roland _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
