Re: [Development] 5.7/5.8 gives unusable static ltcg x86 builds on MSVC 2015/2017
> 18 apr. 2017 kl. 04:37 skrev Mikkel Krautz : > > MSVC 2015 has buggy magic statics, see > https://bugreports.qt.io/browse/QTBUG-58318 and > https://connect.microsoft.com/VisualStudio/feedback/details/3121209 > > I worked around the issue by disabling them with -Zc:threadSafeInit-. Wow, thank you! I've definitely hit the snag related to the shortcuts. I'll see if this option fixes it and will report back ASAP. Cheers, Kuba (Why didn't I find the bug report I can't fathom - I did search for these keywords) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 5.7/5.8 gives unusable static ltcg x86 builds on MSVC 2015/2017
MSVC 2015 has buggy magic statics, see https://bugreports.qt.io/browse/QTBUG-58318 and https://connect.microsoft.com/VisualStudio/feedback/details/3121209 I worked around the issue by disabling them with -Zc:threadSafeInit-. On Tue, Apr 18, 2017 at 3:46 AM, Kuba Ober wrote: > Are -static -ltcg -debug-and-release x86 builds tested and supported? It > seems that they are broken on at least MSVC 2015 and 2017, in both 5.7 and > 5.8. That's using most recent production releases of either version of MSVC > (no prereleases etc), and I build using most recent jom. > > For me; 5.8 in a debug build corrupts the heap early during static > initialization and doesn't even get to main's body. A release build is will > generally crash somewhere but due to lack of heap diagnostics it will get to > run first, on a partially corrupted heap. > > 5.7 crashes in the release if you as much as use add a shortcut to a dummy > widget and then return from main. Seems to be a different face of the same > problem, although the debug version didn't crash. > > IIRC 5.6 was also crashing for me. > > Since this is reproducible on 2 different machines, and seems to point to a > persistent problem - did anyone else run into it? > > I will file bug reports but would want to know first whether it's anything > known. To be completely frank, I couldn't get any Qt version between 5.6 and > 5.8, inclusive, to work under either MSVC 2015 or 2017 with -static -ltcg so > it seems like an untested configuration that's exposing undefined behavior > somewhere as the whole thing is globally optimized. > > I kinda need this to work. Unless I hear better ideas, I plan on stripping > away code to see what it takes to make it not crash. With 5.8 it crashes even > with no plugins linked in, the heap corruption is detected in a heap free > from one of the Q_GLOBAL_STATICs in somewhere in Qt. > > Cheers, Kuba Ober > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 5.7/5.8 gives unusable static ltcg x86 builds on MSVC 2015/2017
Em segunda-feira, 17 de abril de 2017, às 18:46:02 PDT, Kuba Ober escreveu: > Are -static -ltcg -debug-and-release x86 builds tested and supported? No and we will not test it. That will create a .lib file with no code. Only during the linking of your application will ALL the code be generated. I don't think we test -static either. > For me; 5.8 in a debug build corrupts the heap early during static > initialization and doesn't even get to main's body. A release build is will > generally crash somewhere but due to lack of heap diagnostics it will get > to run first, on a partially corrupted heap. Does the same problem happen with -static and without -ltcg? If it doesn't happen, then it's either a compiler bug or something completely unsupported. You'll have to debug yourself, sorry. > I will file bug reports but would want to know first whether it's anything > known. To be completely frank, I couldn't get any Qt version between 5.6 > and 5.8, inclusive, to work under either MSVC 2015 or 2017 with -static > -ltcg so it seems like an untested configuration that's exposing undefined > behavior somewhere as the whole thing is globally optimized. Don't file. We'll just close the bug as unsupported. File only if the problem persists when you use only one of -ltcg or -static. Not both. Or I can assign it back to you, if you're willing to work on identifying the problem. > I kinda need this to work. Unless I hear better ideas, I plan on stripping > away code to see what it takes to make it not crash. With 5.8 it crashes > even with no plugins linked in, the heap corruption is detected in a heap > free from one of the Q_GLOBAL_STATICs in somewhere in Qt. That would be welcome. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] 5.7/5.8 gives unusable static ltcg x86 builds on MSVC 2015/2017
Are -static -ltcg -debug-and-release x86 builds tested and supported? It seems that they are broken on at least MSVC 2015 and 2017, in both 5.7 and 5.8. That's using most recent production releases of either version of MSVC (no prereleases etc), and I build using most recent jom. For me; 5.8 in a debug build corrupts the heap early during static initialization and doesn't even get to main's body. A release build is will generally crash somewhere but due to lack of heap diagnostics it will get to run first, on a partially corrupted heap. 5.7 crashes in the release if you as much as use add a shortcut to a dummy widget and then return from main. Seems to be a different face of the same problem, although the debug version didn't crash. IIRC 5.6 was also crashing for me. Since this is reproducible on 2 different machines, and seems to point to a persistent problem - did anyone else run into it? I will file bug reports but would want to know first whether it's anything known. To be completely frank, I couldn't get any Qt version between 5.6 and 5.8, inclusive, to work under either MSVC 2015 or 2017 with -static -ltcg so it seems like an untested configuration that's exposing undefined behavior somewhere as the whole thing is globally optimized. I kinda need this to work. Unless I hear better ideas, I plan on stripping away code to see what it takes to make it not crash. With 5.8 it crashes even with no plugins linked in, the heap corruption is detected in a heap free from one of the Q_GLOBAL_STATICs in somewhere in Qt. Cheers, Kuba Ober ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
