Re: [Openexr-devel] update for ImathPlatform.h for Win32 (MSVC): 'restrict' support for VC

[Florian Kainz]

Hi Ger,

thank you for your ImathPlatform.h fixes.  I did not apply of your
patches, but I believe I have addressed the issues you have pointed out:

* M_PI_2 and other M_* constantes are not defined in math.h on Windows:
  I applied the part of your patch that defines M_PI_2, but I omitted M_E,
  M_LOG2E etc.  Those constants are not used anywhere in the OpenEXR code
  base.  Fixing broken math.h header files beyond what is necessary to
  make OpenEXR compile is outside the scope of the OpenEXR project.

* restrict keyword: I replaced all instances of restrict in Imath with
  IMATH_RESTRICT.  ImathPlatform.h now defines IMATH_RESTRICT as __restrict
  for GCC and VisualC++, restrict for Intel's and SGI's compilers, and as
  an empty string for all other compilers.

Updated versions of ImathPlatform.h and ImathMatrix.h have been checked
into CVS.

Florian



Ger Hobbelt wrote:
> Here's the addition of 'restrict' support for MSVC(2005 at least), as
> that compiler also supports 'restrict', but there's a cinch. Which is
> taken care of in this fix, though in a rather 'hackish' way. I've a
> few other possbile slutions, but nothing else worked out. See the
> comment in the diff/source code below.
>
> Passes all OpenEXR tests on Win32 (compiled with MSVC2005SP1 on XP
> 32-bit, running on AMD XP (no! SSE2 support, so the project files are
> tweaked; no other change for that). Will test on 64-bit Win platforms
> later on, when I've migrated the project files.
>
> diff included below (note that line numbers will be off, due to
> M_PI/M_PI_2 fix up there in the same file).
>
> Ger
>
>
> --- \\Debbie\ger\prj\1original\OpenEXR\src\IlmBase\Imath\ImathPlatform.h        
> 2006-12-09
> 00:23:08.000000000 +-0200
> +++ \\Debbie\ger\prj\3actual\OpenEXR\IlmBase\Imath\ImathPlatform.h      
> 2008-06-17
> 22:15:23.000000000 +-0200
> @@ -81,12 +159,70 @@
>  #elif defined(__INTEL_COMPILER) || defined(__ICL) || defined(__ICC)
> || defined(__ECC)
>      // supports restrict, do nothing.
>
>  #elif defined __sgi
>      // supports restrict, do nothing.
>
> +#elif defined _MSC_VER
> +       // supports restrict as __restrict.
> +       //
> +       // Unfortunately MSVC also knows 'restrict' in this context:
> +       //   __declspec(restrict)
> +       // which leads to very 'funny' (not!) error reports in stdlib.h when it 
> is
> +       // loaded AFTER this. And it often is... Sigh.
> +       //
> +       // So we do the hack thing and load <stdlib.h> anyway here, so the
> preprocessor
> +       // will prevent it from loading again after we coerce 'restrict' to 
> something
> +       // meaningful for this compiler, e.g. '__restrict'.
> +       //
> +       // Update for the above:
> +       //
> +       // Microsoft encapsulates the 'restrict' in the define '_CRTRESTRICT',
> +       // (Code based on the crtdefs.h definitions by Microsoft.)
> +       // There are multiple system header files using this macro and we don't 
> want
> +       // them to load here all, but we have to if we don't want the compiler 
> to barf
> +       // as there's no simple way to use '__declspec(restrict)' in code
> following this
> +       // section where 'restict' is defined as '__restrict'.
> +       // 'Best' (yech) thing I can think of now is #undef restrict at those 
> spots
> +       // where you want to use __declspec(restrict) yourself. :-((
> +       //
> +       #if (defined(_M_IA64) && (_MSC_FULL_VER >= 13102050)) || (_MSC_VER >= 
> 1400)
> +               /* these compiler versions have __declspec(restrict); load the
> header files which are affected */
> +               #include <stdlib.h>
> +               #include <malloc.h>
> +       #endif
> +
> +    #if !defined(restrict)
> +               /*
> +                       Microsoft says:
> +
> +                       Like the restrict __declspec modifier, the __restrict 
> keyword
> indicates that
> +                       a symbol is not aliased in the current scope. The 
> __restrict
> keyword differs
> +                       from the restrict __declspec modifier in the following 
> ways:
> +
> +                       - The __restrict keyword is valid only on variables, and
> __declspec(restrict)
> +                         is only valid on function declarations and 
> definitions.
> +
> +                       - When __restrict is used, the compiler will not 
> propagate the no-alias
> +                         property of a variable. That is, if you assign a 
> __restrict variable to
> +                         a non-__restrict variable, the compiler will not 
> imply that the
> +                         non-__restrict variable is not aliased.
> +
> +                       Generally, if you affect the behavior of an entire 
> function, it is
> better to
> +                       use the __declspec than the keyword.
> +
> +                       __restrict is similar to restrict from the C99 spec, 
> but __restrict can be
> +                       used in C++ or C programs.
> +
> +                       ----
> +
> +                       Given the use of 'restrict' in OpenEXR, it should be 
> defined as
> '__restrict'.
> +               */
> +       #define restrict __restrict
> +    #endif
> +
>  #else
>      #define restrict
>
>  #endif
>
>  #endif // INCLUDED_IMATHPLATFORM_H