On 20/03/15 14:36, Brian Paul wrote:
On 03/20/2015 07:59 AM, Jose Fonseca wrote:
Most cases seem harmless, though that might not always be the case.
Maybe
one day we can get gcc to complain about these and fix them throughout
the code, but until then let's silence them.
---
scons/gallium.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/scons/gallium.py b/scons/gallium.py
index 52f1b8d..bf6d605 100755
--- a/scons/gallium.py
+++ b/scons/gallium.py
@@ -507,6 +507,7 @@ def generate(env):
'/wd4018', # signed/unsigned mismatch
'/wd4056', # overflow in floating-point constant arithmetic
'/wd4244', # conversion from 'type1' to 'type2',
possible loss of data
+ '/wd4267', # 'var' : conversion from 'size_t' to 'type',
possible loss of data
'/wd4305', # truncation from 'type1' to 'type2'
'/wd4351', # new behavior: elements of array 'array'
will be default initialized
'/wd4756', # overflow in constant arithmetic
Would this silence cases of casting pointers to uint32, for example? I
don't think we'd want to silence that kind of warning.
I've just tested that, and it triggers a different warning -- C4047 (
https://msdn.microsoft.com/en-us/library/3t92260h.aspx ) --, which we
still get.
Anyway, the series looks good.
Reviewed-by: Brian Paul <bri...@vmware.com>
Thanks.
With the series pretty much all MSVC C++ warnings (with /W3) are gone
(thought I haven't tried all MSVC version and release type combinations.)
Left are linker warnings:
...: warning LNK4221: This object file does not define any previously
undefined public symbols, so it will not be used by any link operation
that consumes this library
which is totally bening, impossible to turn off, and hard to address,
particularly for release builds where a lot of debug code gets turned off.
And
warning LNK4197: export 'glClear' specified multiple times; using
first specification
...
Which we should address -- either by stop using
__declspec(dllimport/export) -- or stop using .DEFs. My prefering would
be to stop using __declspec, as .DEFs are good to spot bugs when symbols
are missing.
Jose
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
