> Yes, I received it too.
>
> If you want me to add/remove any address of yours to/from the mailing
> list, just ask.
>
> Benoit
>
> 2010/3/2 Eamon Nerbonne <
emn13@xxxxxxxxxxxx>:
>> Can anybody confirm they actually received this? I'm a little confused
>> about whether this email address is a member of the list or not, at the
>> moment.
>>
>> --
eamon@xxxxxxxxxxxx - Tel#:+31-6-15142163
>>
>>
>> On Tue, Mar 2, 2010 at 15:25, Eamon Nerbonne <
emn13@xxxxxxxxxxxx> wrote:
>>>
>>> I get the impression the previous mail never arrived. There seems to be
>>> something slightly odd going on with listmaster; it claims I'm subscribed
>>> with my normally primary email address eamon[at]..., but won't let me
>>> unsubscribe nor post. On the other hand, sending from this email address
>>> works.
>>>
>>> In any case; the patch...
>>>
>>>
>>> --
eamon@xxxxxxxxxxxx - Tel#:+31-6-15142163
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: Eamon Nerbonne <
eamon@xxxxxxxxxxxx>
>>> Date: Tue, Mar 2, 2010 at 09:21
>>> Subject: BenchTimer: small patch to avoid compiler warnings and add
>>> missing include
>>> To:
eigen@xxxxxxxxxxxxxxxxxxx
>>>
>>>
>>> Hi everyone,
>>>
>>> In the process of looking for a few perf. regressions, I came across two
>>> minor issues in BenchTimer.h:
>>> - in windows, it defines the NOMINMAX and WIN32_LEAN_AND_MEAN. Those are
>>> common preprocessor symbols and may already be defined. To avoid warnings
>>> in gcc on windows, I wrapped them in an #ifndef.
>>> - BenchTimer uses Vector2d but doesn't include Eigen/Core; so if you
>>> include BenchTimer before Eigen/Core (or without it), it won't compile. I
>>> added the appropriate include.
>>>
>>> It also turns out gcc on windows throws a fit if you try to include
>>> Eigen/Core before BenchTimer.h; I'm not sure that's worth fixing (or even
>>> how to). What happens is that it complains about the various sse
>>> intrinsics; these are obviously being included by eigen, but they're also
>>> included by windows.h via BenchTimer. However, windows.h includes windef,
>>> which in turn has an extern "C" section that includes the intrinsics. GCC
>>> then complains that this new definition uses "C" linkage rather than the
>>> previous C++ linkage, eg:
>>>
>>>
>>> c:\gcc\equation443\bin\../lib/gcc/x86_64-pc-mingw32/4.4.3/include/emmintrin.h:234:
>>> error: previous declaration of 'double __vector__ _mm_add_sd(double
>>> __vector__, double __vector__)' with 'C++' linkage
>>>
>>> c:\gcc\equation443\bin\../lib/gcc/x86_64-pc-mingw32/4.4.3/../.../../../x86_64-pc-mingw32/include/intrin.h:599:
>>> error: conflicts with new declaration with 'C' linkage
>>>
>>>
>>>
>>> --
eamon@xxxxxxxxxxxx - Tel#:+31-6-15142163
>>>
>>
>>
>