Fixed cross compilation with mingw.

Fixed cross compilation with mingw.

Tested in Mozilla source tree. I tried to use skia build system, but it's up to the task for cross compilation.

SkHRESULT.cpp - Use proper file name (that matters on case sensitive OSes)

SkAtomics_win.h - Don't use pragma intrinsic on GCC (this causes massive warnings)

SkOSFile_win.cpp - This one is tricky. GCC doesn't allow (void*) casts in template argument constants and INVALID_HANDLE_VALUE looks like this:
((HANDLE)(LONG_PTR)-1)
where HANDLE is typedefed to void*. Changed the code to use LONG_PTR as template argument and cast it when needed.

BUG=skia:

Committed: http://code.google.com/p/skia/source/detail?r=13862

[bungeman-skia, 2014-03-14 14:50:37]

https://codereview.chromium.org/198643004/diff/1/src/ports/SkAtomics_win.h
File src/ports/SkAtomics_win.h (right):

https://codereview.chromium.org/198643004/diff/1/src/ports/SkAtomics_win.h#ne...
src/ports/SkAtomics_win.h:16: #ifdef _MSC_VER
Why are you using this file at all? Why not #define SK_ATOMICS_PLATFORM_H to the
_sync version? If gcc does not support the MSDN stated way of doing this, one
should use gcc's way of doing it if building with gcc.

https://codereview.chromium.org/198643004/diff/1/src/ports/SkOSFile_win.cpp
File src/ports/SkOSFile_win.cpp (right):

https://codereview.chromium.org/198643004/diff/1/src/ports/SkOSFile_win.cpp#n...
src/ports/SkOSFile_win.cpp:53: template <typename HandleType, LONG_PTR
InvalidValue, BOOL (WINAPI * Close)(HandleType)>
Ick, ack, uck. So technically... in the C++ specification 14.3.2 it appears that
it used to be the case that pointer template arguments had to be addresses of
real objects. C++11 extended this to include NULL. The rationale for this is
that some systems don't have flat pointers into which random stuff like -1 can
be stuffed (in fact it seemed like there was some debate about NULL for this
reason as well). VC++ lets this slide, but it is against the spec to have a

template <void* P> struct A { };
typedef A<-1> a;  //  -1 doesn't isn't the address of an object.

I'll have to think about this a bit.

https://codereview.chromium.org/198643004/diff/1/src/utils/win/SkHRESULT.cpp
File src/utils/win/SkHRESULT.cpp (right):

https://codereview.chromium.org/198643004/diff/1/src/utils/win/SkHRESULT.cpp#...
src/utils/win/SkHRESULT.cpp:10: #include "SkHRESULT.h"
This looks like a good fix.

[cjacek, 2014-03-14 15:59:17]

Thank you for review. The new set uses SkAtomics_sync.h on mingw. BTW, mingw
uses always_inline wrappers to forward Interlocked* calls to __builtin_*
functions, so the resulting binaries should be the same, but it's more compiler
friendly now.

[bungeman-skia, 2014-03-14 17:50:18]

https://codereview.chromium.org/198643004/diff/20001/include/core/SkPostConfig.h
File include/core/SkPostConfig.h (right):

https://codereview.chromium.org/198643004/diff/20001/include/core/SkPostConfi...
include/core/SkPostConfig.h:377: #  if defined(_MSC_VER)
Mike will probably want to consider this.

https://codereview.chromium.org/198643004/diff/20001/src/ports/SkOSFile_win.cpp
File src/ports/SkOSFile_win.cpp (right):

https://codereview.chromium.org/198643004/diff/20001/src/ports/SkOSFile_win.c...
src/ports/SkOSFile_win.cpp:53: template <typename HandleType, LONG_PTR
InvalidValue, BOOL (WINAPI * Close)(HandleType)>
So I thought maybe I could replace this with some traits, but that means that
the static const <trait>::InvalidValue would need to be initialized in a
translation unit, which I'd like to avoid (I just want to compare directly,
avoiding any possible loads).

Since we're not actually using SkAutoWinFile anyway (anymore), the only user is
actually SkAutoWinMMap, so it would be preferred at this time to just write that
one explicitly.

class SkAutoNullKernelHandle : SkNoncopyable {
public:
    SkAutoNullKernelHandle(const HANDLE handle) : fHandle(handle) { }
    ~SkAutoNullKernelHandle() { CloseHandle(fHandle); }
    operator HANDLE() const { return fHandle; }
    bool isValid() const { return NULL != fHandle; }
private:
    HANDLE fHandle;
};
typedef SkAutoNullKernelHandle SkAutoWinMMap;

Frankly, specializing isn't much more code that the traiting anyway.

[cjacek, 2014-03-18 15:37:21]

Thank you for review. I uploaded a new version containing your new version of
SkAutoNullKernelHandle/SkAutoWinMMap.

[bungeman-skia, 2014-03-18 16:14:30]

lgtm, but I think you'll need reed to give his lgtm for the PostConfig.h change.

[reed1, 2014-03-18 17:08:15]

lgtm

[bungeman-skia, 2014-03-19 17:47:38]

The CQ bit was checked by bungeman@google.com

[commit-bot: I haz the power, 2014-03-19 17:47:47]

CQ is trying da patch. Follow status at
https://skia-tree-status.appspot.com/cq/cjacek@gmail.com/198643004/30001

[commit-bot: I haz the power, 2014-03-19 17:47:50]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-03-19 17:47:51]

Presubmit check for 198643004-30001 failed and returned exit status 1.

Running presubmit commit checks ...

** Presubmit ERRORS **
The email cjacek@gmail.com is not in Skia's AUTHORS file.
Issue owner, this CL must include an addition to the Skia AUTHORS file.
Googler reviewers, please check that the AUTHORS entry corresponds to an email
address in http://goto/cla-signers. If it does not then ask the issue owner to
sign the CLA at https://developers.google.com/open-source/cla/individual
(individual) or https://developers.google.com/open-source/cla/corporate
(corporate).

[bungeman-skia, 2014-03-19 17:54:56]

On 2014/03/19 17:47:51, I haz the power (commit-bot) wrote:
> Presubmit check for 198643004-30001 failed and returned exit status 1.
> 
> Running presubmit commit checks ...
> 
> ** Presubmit ERRORS **
> The email mailto:cjacek@gmail.com is not in Skia's AUTHORS file.
> Issue owner, this CL must include an addition to the Skia AUTHORS file.
> Googler reviewers, please check that the AUTHORS entry corresponds to an email
> address in http://goto/cla-signers. If it does not then ask the issue owner to
> sign the CLA at https://developers.google.com/open-source/cla/individual
> (individual) or https://developers.google.com/open-source/cla/corporate
> (corporate).

I see you on the list of signers (twice, in fact), so that should be ok. If you
upload a new CL the same as Patch Set 3, but add yourself to the AUTHORS file,
we'll get this in.

[cjacek, 2014-03-19 18:01:13]

On 2014/03/19 17:54:56, bungeman1 wrote:
> I see you on the list of signers (twice, in fact), so that should be ok. If
you
> upload a new CL the same as Patch Set 3, but add yourself to the AUTHORS file,
> we'll get this in.

OK, uploaded. Thank you.

[bungeman-skia, 2014-03-19 18:29:46]

The CQ bit was checked by bungeman@google.com

[commit-bot: I haz the power, 2014-03-19 18:29:55]

CQ is trying da patch. Follow status at
https://skia-tree-status.appspot.com/cq/cjacek@gmail.com/198643004/50001

[commit-bot: I haz the power, 2014-03-19 19:28:06]

Change committed as 13862