|
|
Home » Community » U++ community news and announcements » 2020.1 officially released
Re: 2020.1 officially released [message #54088 is a reply to message #54086] |
Sat, 30 May 2020 22:52 |
Novo
Messages: 1358 Registered: December 2006
|
Ultimate Contributor |
|
|
Problem is solved. I was able to reproduce this crash on Linux.
Clang is crashing in a third-party library, which requires C++17, but the code was compiled with -std=c++14.
Instead of reporting an error Clang just crashes.
Life is going on.
Regards,
Novo
|
|
|
|
Re: 2020.1 officially released [message #54098 is a reply to message #54096] |
Mon, 01 June 2020 00:36 |
Novo
Messages: 1358 Registered: December 2006
|
Ultimate Contributor |
|
|
mirek wrote on Sun, 31 May 2020 17:13
What about those compile times?
Nothing has changed.
The worst case I've seen is reference/Eigen_demo. I never saw end of compilation in Debug conf. Release compiles in 1.5 minutes.
I cannot check compilation speed at the moment because your last commit broke compilation of reference/EscApp with Clang on Windows.
Regards,
Novo
[Updated on: Mon, 01 June 2020 00:37] Report message to a moderator
|
|
|
|
|
|
Re: 2020.1 officially released [message #54113 is a reply to message #54109] |
Mon, 01 June 2020 21:35 |
Novo
Messages: 1358 Registered: December 2006
|
Ultimate Contributor |
|
|
There is another unexpected problem with Clang on Windows.
If I add "-std=c++17" to cpp options, then in case of GUI app (example: tutorial/Gui01) in Debug configuration I get this (Release is fine):
Linking...
lld-link: error: duplicate symbol: std::__throw_bad_alloc()
>>> defined at c:\local\apps\upp\uppsrc\Core\heap.cpp:315
>>> c:/local/apps/upp/out/tutorial/Core/CLANGx64cpp17.Debug.Debug_Full.Gui\heap.o
>>> defined at libc++.a(new.cpp.obj)
lld-link: error: duplicate symbol: operator new(unsigned long long)
>>> defined at c:\local\apps\upp\uppsrc\Core\heap.cpp:301
>>> c:/local/apps/upp/out/tutorial/Core/CLANGx64cpp17.Debug.Debug_Full.Gui\heap.o
>>> defined at libc++.a(new.cpp.obj)
lld-link: error: duplicate symbol: operator new(unsigned long long, std::nothrow_t const&)
>>> defined at c:\local\apps\upp\uppsrc\Core\heap.cpp:307
>>> c:/local/apps/upp/out/tutorial/Core/CLANGx64cpp17.Debug.Debug_Full.Gui\heap.o
>>> defined at libc++.a(new.cpp.obj)
lld-link: error: duplicate symbol: operator new[](unsigned long long)
>>> defined at c:\local\apps\upp\uppsrc\Core\heap.cpp:304
>>> c:/local/apps/upp/out/tutorial/Core/CLANGx64cpp17.Debug.Debug_Full.Gui\heap.o
>>> defined at libc++.a(new.cpp.obj)
lld-link: error: duplicate symbol: operator new[](unsigned long long, std::nothrow_t const&)
>>> defined at c:\local\apps\upp\uppsrc\Core\heap.cpp:310
>>> c:/local/apps/upp/out/tutorial/Core/CLANGx64cpp17.Debug.Debug_Full.Gui\heap.o
>>> defined at libc++.a(new.cpp.obj)
lld-link: error: duplicate symbol: operator delete(void*)
>>> defined at c:\local\apps\upp\uppsrc\Core\heap.cpp:302
>>> c:/local/apps/upp/out/tutorial/Core/CLANGx64cpp17.Debug.Debug_Full.Gui\heap.o
>>> defined at libc++.a(new.cpp.obj)
lld-link: error: duplicate symbol: operator delete(void*, std::nothrow_t const&)
>>> defined at c:\local\apps\upp\uppsrc\Core\heap.cpp:308
>>> c:/local/apps/upp/out/tutorial/Core/CLANGx64cpp17.Debug.Debug_Full.Gui\heap.o
>>> defined at libc++.a(new.cpp.obj)
lld-link: error: duplicate symbol: operator delete[](void*)
>>> defined at c:\local\apps\upp\uppsrc\Core\heap.cpp:305
>>> c:/local/apps/upp/out/tutorial/Core/CLANGx64cpp17.Debug.Debug_Full.Gui\heap.o
>>> defined at libc++.a(new.cpp.obj)
lld-link: error: duplicate symbol: operator delete[](void*, std::nothrow_t const&)
>>> defined at c:\local\apps\upp\uppsrc\Core\heap.cpp:311
>>> c:/local/apps/upp/out/tutorial/Core/CLANGx64cpp17.Debug.Debug_Full.Gui\heap.o
>>> defined at libc++.a(new.cpp.obj)
clang-10: error: linker command failed with exit code 1 (use -v to see invocation)
Because STD_NEWDELETE is defined, and it gets defined in config.h here:
#ifdef flagCLR
#define flagUSEMALLOC
#define STD_NEWDELETE
#endif
I have no idea where flagCLR is coming from ...
wine umk tutorial Gui01 CLANGx64cpp17 -bu
Regards,
Novo
|
|
|
Re: 2020.1 officially released [message #54114 is a reply to message #54104] |
Mon, 01 June 2020 21:41 |
Novo
Messages: 1358 Registered: December 2006
|
Ultimate Contributor |
|
|
mirek wrote on Mon, 01 June 2020 04:23OK, eigen_demo.cpp alone (Alt+F7) takes 24s to compile with CLANGx64. That's a lot.
However, if I use Visual C++, it takes to compile.... 24s. So perhaps it is simply the complexity of eigen...
Mirek
In my case it takes 1.5 minutes to compile plugins/sqlite3. IMHO, this is unacceptable ...
P.S. I compile with BLITZ enabled even in Release.
Regards,
Novo
|
|
|
Re: 2020.1 officially released [message #54115 is a reply to message #54114] |
Mon, 01 June 2020 21:46 |
|
mirek
Messages: 13975 Registered: November 2005
|
Ultimate Member |
|
|
Novo wrote on Mon, 01 June 2020 21:41mirek wrote on Mon, 01 June 2020 04:23OK, eigen_demo.cpp alone (Alt+F7) takes 24s to compile with CLANGx64. That's a lot.
However, if I use Visual C++, it takes to compile.... 24s. So perhaps it is simply the complexity of eigen...
Mirek
In my case it takes 1.5 minutes to compile plugins/sqlite3. IMHO, this is unacceptable ...
P.S. I compile with BLITZ enabled even in Release.
OK, indeed release with blitz, it is 1 minute. Interesting... That said, I do not see what we can do here...
|
|
|
Re: 2020.1 officially released [message #54116 is a reply to message #54115] |
Mon, 01 June 2020 21:53 |
|
mirek
Messages: 13975 Registered: November 2005
|
Ultimate Member |
|
|
The problematic file is plugin/sqlite3/lib.c. It definitely depends on O level
O1 15s
O2 42s
O3 55s
It is 200K lines file. Maybe the issue is that clang is trying to perform some global optimisations that go exponential with the file size?
[Updated on: Mon, 01 June 2020 21:54] Report message to a moderator
|
|
|
|
|
Re: 2020.1 officially released [message #54119 is a reply to message #54118] |
Mon, 01 June 2020 23:07 |
Novo
Messages: 1358 Registered: December 2006
|
Ultimate Contributor |
|
|
It takes only 23 sec. to compile the same code in Linux using same version of Clang.
----- Eigen_demo ( MAIN GCC DEBUG SHARED DEBUG_FULL BLITZ POSIX LINUX ) (3 / 3)
BLITZ: eigen_demo.cpp non-linear.cpp fft.cpp
Core: 68 file(s) built in (0:02.42), 35 msecs / file
plugin/Eigen: 1 file(s) built in (0:03.34), 3346 msecs / file
Eigen_demo: 3 file(s) built in (0:22.95), 7651 msecs / file
Linking...
/home/ssg/.local/soft/bb-worker/worker/l-upp/build/.cache/upp.out/CLANG.Debug.Debug_Full.Shared/Eigen_demo (78994008 B) linked in (0:02.03)
OK. (0:31.83)
$ ./umk reference Eigen_demo CLANG -busa
IMHO, something isn't right with the Clang bundled with Upp.
It, probably, has been compiled differently ...
Regards,
Novo
|
|
|
|
|
Re: 2020.1 officially released [message #54122 is a reply to message #54113] |
Mon, 01 June 2020 23:31 |
Novo
Messages: 1358 Registered: December 2006
|
Ultimate Contributor |
|
|
Novo wrote on Mon, 01 June 2020 15:35I have no idea where flagCLR is coming from ...
wine umk tutorial Gui01 CLANGx64cpp17 -bu
It would be great to get this fixed ...
Regards,
Novo
|
|
|
|
|
|
Re: 2020.1 officially released [message #54129 is a reply to message #54125] |
Tue, 02 June 2020 16:24 |
Novo
Messages: 1358 Registered: December 2006
|
Ultimate Contributor |
|
|
mirek wrote on Tue, 02 June 2020 04:31Novo wrote on Mon, 01 June 2020 23:27I'm afraid it is wine to blame in my case.
Clang-10 spends ~75% of its time calling one function in ntdll.dll.so
BTW, which function is that? Maybe there could be done something about it...
Mirek
I cannot tell that. There is no debug information in wine.
What I can see is just an address.
Regards,
Novo
|
|
|
Goto Forum:
Current Time: Sun Apr 28 23:09:19 CEST 2024
Total time taken to generate the page: 0.04101 seconds
|
|
|