C2220: warning treated as error (64 bit MSVC 2015)

[slacka]

With the LODE environment, I can build the 32-bit binary without any errors. Recently, the 64-bit builds stopped working. For 64-bit I get the following error:

[build CXX] vcl/source/filter/jpeg/Exif.cxx

/core/vcl/source/filter/igif/gifread.cxx(251): error C2220: warning treated as error - no 'object' file generated

/core/vcl/source/filter/igif/gifread.cxx(251): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)

/core/vcl/source/filter/igif/gifread.cxx(462): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)

[build CXX] vcl/source/filter/jpeg/jpeg.cxx

/core/solenv/gbuild/LinkTarget.mk:189: recipe for target '/core/workdir/CxxObject/vcl/source/filter/igif/gifread.o' failed

make[1]: *** [/core/workdir/CxxObject/vcl/source/filter/igif/gifread.o] Error 2

make[1]: *** Waiting for unfinished jobs....

Makefile:257: recipe for target 'build' failed

make: *** [build] Error 2

I tried to bisect it, and couldn't build anything as far back as I tried. Could this be from an update to my OS (Win 10) or MSVC?

The following incorrect/bad hack allowed me to build it:

diff --git a/oox/source/ole/vbainputstream.cxx b/oox/source/ole/vbainputstream.cxx

index 65eb91c..db87aca 100644

--- a/oox/source/ole/vbainputstream.cxx

+++ b/oox/source/ole/vbainputstream.cxx

@@ -157,7 +157,7 @@ bool VbaInputStream::updateChunk()

                     sal_uInt16 nCopyToken = mpInStrm->readuInt16();

                     nChunkPos = nChunkPos + 2;

                     // update bit count used for offset/length in the token

-                    while( static_cast< size_t >( 1 << nBitCount ) < maChunk.size() ) ++nBitCount;

+                    while( static_cast< size_t >( 1i64 << nBitCount ) < maChunk.size() ) ++nBitCount;

                     // extract length from lower (16-nBitCount) bits, plus 3

                     sal_uInt16 nLength = extractValue< sal_uInt16 >( nCopyToken, 0, 16 - nBitCount ) + 3;

                     // extract offset from high nBitCount bits, plus 1

diff --git a/vcl/source/filter/igif/gifread.cxx b/vcl/source/filter/igif/gifread.cxx

index 01060ab..ba3a2fc 100644

--- a/vcl/source/filter/igif/gifread.cxx

+++ b/vcl/source/filter/igif/gifread.cxx

@@ -248,7 +248,7 @@ bool GIFReader::ReadGlobalHeader()

                 bGlobalPalette = ( nRF & 0x80 );

 

                 if( bGlobalPalette )

-                    ReadPaletteEntries( &aGPalette, 1 << ( ( nRF & 7 ) + 1 ) );

+                    ReadPaletteEntries( &aGPalette, 1i64 << ( ( nRF & 7 ) + 1 ) );

                 else

                     nBackgroundColor = 0;

 

@@ -459,7 +459,7 @@ bool GIFReader::ReadLocalHeader()

         if( nFlags & 0x80 )

         {

             pPal = &aLPalette;

-            ReadPaletteEntries( pPal, 1 << ( (nFlags & 7 ) + 1 ) );

+            ReadPaletteEntries( pPal, 1i64 << ( (nFlags & 7 ) + 1 ) );

         }

         else

             pPal = &aGPalette;

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

[slacka]

Even after:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=4a8caa37fe83c389f4fd43219e8ea0f21f03c6fe

With the 64-bit build, I'm still getting the following error:

[build CXX] vcl/source/filter/ixbm/xbmread.cxx
[build CXX] vcl/source/filter/ixpm/xpmread.cxx
E/vcl/source/filter/igif/gifread.cxx(251): error C2220: warning treated as error - no 'object' file generated
E/vcl/source/filter/igif/gifread.cxx(251): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)
E/vcl/source/filter/igif/gifread.cxx(462): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)
[build CXX] vcl/source/filter/jpeg/Exif.cxx
[build CXX] vcl/source/filter/jpeg/jpeg.cxx
E/solenv/gbuild/LinkTarget.mk:189: recipe for target 'E/workdir/CxxObject/vcl/source/filter/igif/gifread.o' failed
make[1]: *** [E/workdir/CxxObject/vcl/source/filter/igif/gifread.o] Error 2
make[1]: *** Waiting for unfinished jobs....
Makefile:257: recipe for target 'build' failed
make: *** [build] Error 2

[sberg]

On 05/21/2016 06:45 PM, slacka wrote:
> Even after:
> https://cgit.freedesktop.org/libreoffice/core/commit/?id=4a8caa37fe83c389f4fd43219e8ea0f21f03c6fe
>
> With the 64-bit build, I'm still getting the following error:

should be fixed now with
<https://cgit.freedesktop.org/libreoffice/core/commit/?id=cffc2471bc7d08f27a995e4e0f6fcf49d74d0f5a>
"Silence C4334: '<<': result of 32-bit shift implicitly converted to 64
bits"

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

[slacka]

With sberg's and Noel's patches, I can now build the 64-bit version again. Nice work team!

To answer my own question, the C4334 warning is new in VS 2015 Update 2.

[slacka]

Within the last day or so, the 64-bit version stop building. Now I'm getting the following error:

[build CXX] canvas/source/directx/dx_canvasbitmap.cxx
cl : Command line warning D9025 : overriding '/DNOMINMAX' with '/UNOMINMAX'
MathMLSolverPrecompiled.o : 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
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: E:\cygwin\home\Hearthstone\lode\dev\core\ridljar\com\sun\star\lib\util\WeakMap.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
[build CXX] canvas/source/directx/dx_canvasfont.cxx
cl : Command line warning D9025 : overriding '/DNOMINMAX' with '/UNOMINMAX'
COLLADASaxFWLPrecompiledHeaders.o : 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
COLLADAFWPrecompiledHeaders.o : 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
E:/core/canvas/source/directx/dx_canvasbitmap.cxx(71): error C2397: conversion from 'size_t' to 'BYTE' requires a narrowing conversion
[build CXX] canvas/source/directx/dx_canvashelper.cxx
cl : Command line warning D9025 : overriding '/DNOMINMAX' with '/UNOMINMAX'
E:/core/solenv/gbuild/LinkTarget.mk:189: recipe for target 'E:/core/workdir/CxxObject/canvas/source/directx/dx_canvasbitmap.o' failed
make[1]: *** [E:/core/workdir/CxxObject/canvas/source/directx/dx_canvasbitmap.o] Error 2
make[1]: *** Waiting for unfinished jobs....
Makefile:257: recipe for target 'build' failed
make: *** [build] Error 2

The following commit looks suspicious:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=03ddce193b3a031d9156775a8ee94206ba5b39ce

Is there any chance we could add a 64-bit Windows platform for Jenkins to build on? I've been trying to bisect a separate older 64-bit Windows bug. What should have been a simple bisect is turning into a project because of all of the cherry-picking/reverting that I've needed to do. A Jenkins bot would save us a lot of work.

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

[Michael Stahl-2]

On 26.05.2016 20:18, Luke Benes wrote:
>
> Within the last day or so, the 64-bit version stop building. Now I'm
> getting the following error:

> E:/core/canvas/source/directx/dx_canvasbitmap.cxx(71): error C2397:
> conversion from 'size_t' to 'BYTE' requires a narrowing conversion

> The following commit looks suspicious:
>
> https://cgit.freedesktop.org/libreoffice/core/commit/?id=03ddce193b3a031d9156775a8ee94206ba5b39ce

odd that my 32-bit build doesn't complain, hopefully commit
f2d039f67743c7588df5cfd725915627b6efb0ba should fix this

> Is there any chance we could add a 64-bit Windows platform for Jenkins
> to build on? I've been trying to bisect a separate older 64-bit Windows
> bug. What should have been a simple bisect is turning into a project
> because of all of the cherry-picking/reverting that I've needed to do. A
> Jenkins bot would save us a lot of work.

hmm that would be nice, probably even better than a clang-plugin box...


_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

[slacka]

Here is another C2220

[build CXX] comphelper/source/misc/threadpool.cxx

c:\\core\comphelper\source\misc\threadpool.cxx(80) : error C2220: warning treated as error - no 'object' file generated

c:\\core\comphelper\source\misc\threadpool.cxx(80) : warning C4702: unreachable code

C:/core/solenv/gbuild/LinkTarget.mk:189: recipe for target 'C:/core/workdir/CxxObject/comphelper/source/misc/threadpool.o' failed

make[1]: *** [C:/core/workdir/CxxObject/comphelper/source/misc/threadpool.o] Error 2

make[1]: *** Waiting for unfinished jobs....

Makefile:264: recipe for target 'build' failed

make: *** [build] Error 2

Looks like the source of the issue is:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=76ad32bec8e2c00c21247041b16d9e09e73d2504

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

[slacka]

Can we trust MSVC 2015 unreachable code analysis like we with this similar issue?


The patch below fixes the build:

diff --git a/comphelper/source/misc/threadpool.cxx b/comphelper/source/misc/threadpool.cxx
index 6846f4b..6a335e0 100644
--- a/comphelper/source/misc/threadpool.cxx
+++ b/comphelper/source/misc/threadpool.cxx
@@ -72,17 +72,7 @@ public:
             {
                 SAL_WARN("comphelper", "exception in thread worker while calling doWork(): " << e.Message);
             }
-            try {
-                delete pTask;
-            }
-            catch (const std::exception &e)
-            {
-                SAL_WARN("comphelper", "exception in thread worker while deleting task: " << e.what());
-            }
-            catch (const css::uno::Exception &e)
-            {
-                SAL_WARN("comphelper", "exception in thread worker while deleting task: " << e.Message);
-            }
+            delete pTask;
             pTag->onTaskWorkerDone();
         }
     }

[jan iversen]

Hi

We prefer patches to be submitted through gerrit, as it gives us a possibility to review them.

Have a look at:

https://wiki.documentfoundation.org/Development/GetInvolved#Prepare_to_submit_patches

Apart from that, your patch changes the way the program works, by removing the try/catch clause, you pass exceptions to higher levels (callers of the function), and that is surely not a good idea.

rgds

jan I.

On 24 Jul 2016, at 20:04, slacka <[hidden email]> wrote:

Can we trust MSVC 2015 unreachable code analysis like we with  this similar
issue?
<http://nabble.documentfoundation.org/New-C2220-warning-treated-as-error-MSVC-2015-build-failure-tc4187644.html#a4189119>  

The patch below fixes the build:

diff --git a/comphelper/source/misc/threadpool.cxx
b/comphelper/source/misc/threadpool.cxx
index 6846f4b..6a335e0 100644
--- a/comphelper/source/misc/threadpool.cxx
+++ b/comphelper/source/misc/threadpool.cxx
@@ -72,17 +72,7 @@ public:
            {
                SAL_WARN("comphelper", "exception in thread worker while
calling doWork(): " << e.Message);
            }
-            try {
-                delete pTask;
-            }
-            catch (const std::exception &e)
-            {
-                SAL_WARN("comphelper", "exception in thread worker while
deleting task: " << e.what());
-            }
-            catch (const css::uno::Exception &e)
-            {
-                SAL_WARN("comphelper", "exception in thread worker while
deleting task: " << e.Message);
-            }
+            delete pTask;
            pTag->onTaskWorkerDone();
        }
    }






--
View this message in context: http://nabble.documentfoundation.org/C2220-warning-treated-as-error-64-bit-MSVC-2015-tp4184053p4189213.html
Sent from the Dev mailing list archive at Nabble.com.
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice