[CMake] try_compile generates assertion failure in MSVC 2010

[Dominik Szczerba]

No, I was wrong. It DOES work with ADD_EXECUTABLE but in MSVC2008, but
not MSVC 2010. It also fails with ADD_EXECUTABLE equally in the
latter, so try_run is probably innocent.

So it really looks like another MSVC 2010 improvement. I guess I
should file a bug with MSVC.
But I also guess I can equally talk to a wall.

Sorry to bother you and thanks for all your support,
Dominik

On Fri, Feb 4, 2011 at 5:39 PM, Dominik Szczerba <dominik at itis.ethz.ch> wrote:
> Hmmm, there IS still something cmake related...
> If I just ADD_EXECUTABLE on my configure file, and add its building
> and execution as a depedance to building my library
> (add_custom_target, add_dependencies), it will compile and run with no
> crash... (only each time, which should not be the case for efficiency)
> I am passing my CMAKE_CXX_FLAGS to try_compile, what else can make a
> difference to add_executable?
>
> Dominik
>
> On Fri, Feb 4, 2011 at 4:23 PM, Dominik Szczerba <dominik at itis.ethz.ch> wrote:
>> Many thanks for your feedback. Update:
>>
>> - the proposed compiler switches do not solve the issue. Neither does /fp:strict
>> - bluntly ignoring the failing assertion (need to click twice) seems
>> to still produce some output. A bit scary though, no idea if the
>> numbers can be trusted...
>> - Indeed, the underlying problem is related to the exact predicates I
>> need to use (Shewchuk & co). As can be found in google, to force
>> double (and not extended) precision one needs:
>>
>> fpu_init = _controlfp (0, 0), _controlfp (_PC_53, MCW_PC)
>>
>> // do my fp computations to calculate various epsilons
>>
>> _controlfp (fpu_init, 0xfffff)
>>
>> So this clearly goes beyond cmake now, but of course if you have any
>> more ideas you are more than welcome to share them...
>>
>> Regards,
>> Dominik
>>
>