U++ framework
Do not panic. Ask here before giving up.

Home » Community » U++ community news and announcements » 2020.1 officially released
2020.1 officially released [message #53839] Fri, 08 May 2020 16:26 Go to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
https://sourceforge.net/p/upp/news/2020/05/u-20201-released/
Re: 2020.1 officially released [message #53842 is a reply to message #53839] Fri, 08 May 2020 19:08 Go to previous messageGo to next message
Tom1
Messages: 1319
Registered: March 2007
Ultimate Contributor
Hi!

Thanks for your hard work! Smile

Best regards,

Tom
Re: 2020.1 officially released [message #53843 is a reply to message #53839] Fri, 08 May 2020 22:09 Go to previous messageGo to next message
forlano is currently offline  forlano
Messages: 1221
Registered: March 2006
Location: Italy
Senior Contributor
Thanks a lot!

Luigi
Re: 2020.1 officially released [message #53855 is a reply to message #53839] Sat, 09 May 2020 16:27 Go to previous messageGo to next message
deep is currently offline  deep
Messages: 281
Registered: July 2011
Location: Bangalore
Experienced Member
Great

Thanks a lot.


Warm Regards

Deepak
Re: 2020.1 officially released [message #53864 is a reply to message #53855] Sat, 09 May 2020 21:41 Go to previous messageGo to next message
BioBytes is currently offline  BioBytes
Messages: 312
Registered: October 2008
Location: France
Senior Member
Great work Smile

Thanks a lot to all contributors to U++

Biobytes
Re: 2020.1 officially released [message #53891 is a reply to message #53839] Wed, 13 May 2020 11:33 Go to previous messageGo to next message
h3l1 is currently offline  h3l1
Messages: 28
Registered: August 2006
Location: Innsbruck, Austria
Promising Member
Hi Mirek,

great work, really looks good with the dark theme and new GTK3 on my 4K 15" notebook running Ubuntu 18.04. Very Happy

Found a small problem: was just testing the Bombs application from examples and the window size does not adapt when selecting a different size.
Maybe also adapt the UNIT size for hidpi...

Greetings
Heli
Re: 2020.1 officially released [message #53893 is a reply to message #53891] Wed, 13 May 2020 14:02 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
h3l1 wrote on Wed, 13 May 2020 11:33
Hi Mirek,

great work, really looks good with the dark theme and new GTK3 on my 4K 15" notebook running Ubuntu 18.04. Very Happy

Found a small problem: was just testing the Bombs application from examples and the window size does not adapt when selecting a different size.
Maybe also adapt the UNIT size for hidpi...

Greetings
Heli


Thanks, good catch, fixed in trunk.
Re: 2020.1 officially released [message #53926 is a reply to message #53893] Fri, 15 May 2020 16:17 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
Thanks for the new release.

It seems to have a couple of issues with Mac.
It is impossible to compile umk using makefile via "make -f uMakefile".
ld: warning: option -s is obsolete and being ignored
ld: unknown option: -O
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Even if you have a prebuilt version of umk, an attempt to build ide via "umk uppsrc ide CLANG +brus" leads to
ld: warning: directory not found for option '-L/opt/local/lib'
ld: library not found for -lcrt0.o
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Interestingly, CLANG.bm, automatically created by umk, contains options below.
INCLUDE = "/opt/local/include;/usr/include";
LIB = "/opt/local/lib;/usr/lib";

Although they are not needed.


Regards,
Novo
Re: 2020.1 officially released [message #53938 is a reply to message #53926] Sat, 16 May 2020 09:33 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
Novo wrote on Fri, 15 May 2020 16:17
Thanks for the new release.

It seems to have a couple of issues with Mac.
It is impossible to compile umk using makefile via "make -f uMakefile".
ld: warning: option -s is obsolete and being ignored
ld: unknown option: -O
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Even if you have a prebuilt version of umk, an attempt to build ide via "umk uppsrc ide CLANG +brus" leads to
ld: warning: directory not found for option '-L/opt/local/lib'
ld: library not found for -lcrt0.o
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Interestingly, CLANG.bm, automatically created by umk, contains options below.
INCLUDE = "/opt/local/include;/usr/include";
LIB = "/opt/local/lib;/usr/lib";

Although they are not needed.


Are you trying with upp-posix.tar.xz?
Re: 2020.1 officially released [message #53940 is a reply to message #53938] Sat, 16 May 2020 13:32 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
mirek wrote on Sat, 16 May 2020 03:33
Are you trying with upp-posix.tar.xz?

All this is based on src from git.
Basically, "git clone" and "make -f uMakefile".


Regards,
Novo
Re: 2020.1 officially released [message #53941 is a reply to message #53940] Sat, 16 May 2020 13:38 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
I'm not the first one who tried to do that. There is a related ticket.

Regards,
Novo
Re: 2020.1 officially released [message #53942 is a reply to message #53941] Sat, 16 May 2020 13:54 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
This is happening on OSX 10.13.
clang is installed via brew.
$which clang++
/usr/bin/clang++


Regards,
Novo
Re: 2020.1 officially released [message #54072 is a reply to message #53942] Sat, 30 May 2020 06:31 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
Another interesting observation, this time about timing with Clang on Windows.
----- GLDrawDemo ( GUI MAIN CLANG SHARED BLITZ WIN32 ) (14 / 14)
main.cpp
plugin/tess2: 8 file(s) built in (0:00.90), 113 msecs / file
GLCtrl: 3 file(s) built in (0:00.58), 194 msecs / file
GLDrawDemo: 1 file(s) built in (0:00.79), 794 msecs / file
GLDraw: 20 file(s) built in (0:01.22), 61 msecs / file
plugin/glew: 1 file(s) built in (1:19.54), 79540 msecs / file <--- !!!

----- ScatterDraw_Demo ( MAIN CLANG DEBUG SHARED DEBUG_FULL BLITZ WIN32 ) (8 / 8)
ScatterDraw_Demo.cpp
ScatterDraw_Demo: 1 file(s) built in (0:02.22), 2225 msecs / file
ScatterDraw: 8 file(s) built in (1:03.92), 7991 msecs / file <--- !!!

Actually, I was using wine on Linux.


Regards,
Novo
Re: 2020.1 officially released [message #54073 is a reply to message #54072] Sat, 30 May 2020 07:13 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
Interesting message when compiling on Windows with CLANGx64:
#0 0x0000000142abaa9c (clang-10+0x2abaa9c)
#1 0x0000000142a52a8c (clang-10+0x2a52a8c)
#2 0x0000000142a6b016 (clang-10+0x2a6b016)
#3 0x0000000142a60146 (clang-10+0x2a60146)
clang-10: error: clang frontend command failed due to signal (use -v to see invocation)
clang version 10.0.0 (https://github.com/llvm/llvm-project.git d32170dbd5b0d54436537b6b75beaf44324e0c28)
Target: x86_64-w64-windows-gnu
Thread model: posix
InstalledDir: c:\local\apps\upp\bin\clang\bin
clang-10: note: diagnostic msg: PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
heapdbg.cpp
CharSet.cpp
t.cpp
z.cpp
lz4.c
xxhash.c
clang-10: note: diagnostic msg: 
********************
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-10: note: diagnostic msg: C:\users\ssg\Temp\wkparser$blitz-44ef80.cpp
clang-10: note: diagnostic msg: C:\users\ssg\Temp\wkparser$blitz-44ef80.sh
clang-10: note: diagnostic msg: 
********************
plugin/bz2: 2 file(s) built in (0:00.37), 186 msecs / file
plugin/bmp: 4 file(s) built in (0:00.30), 76 msecs / file
dvlp/ctrl/about: 1 file(s) built in (0:00.33), 332 msecs / file
Painter: 28 file(s) built in (0:01.72), 61 msecs / file
dvlp/wiki/wkparser: 6 file(s) built in (0:00.47), 79 msecs / file
Draw: 35 file(s) built in (0:00.47), 13 msecs / file
RichText: 22 file(s) built in (0:00.50), 23 msecs / file
CtrlCore: 62 file(s) built in (0:00.87), 14 msecs / file
CtrlLib: 58 file(s) built in (0:02.91), 50 msecs / file
Core: 68 file(s) built in (0:05.87), 86 msecs / file
There were errors. (0:17.72)
program finished with exit code 1
elapsedTime=18.027474

And this is primarily C++98 code with a lot of templates.
I mean my own app.


Regards,
Novo

[Updated on: Sat, 30 May 2020 07:19]

Report message to a moderator

Re: 2020.1 officially released [message #54074 is a reply to message #54072] Sat, 30 May 2020 08:55 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
Novo wrote on Sat, 30 May 2020 06:31
Another interesting observation, this time about timing with Clang on Windows.
----- GLDrawDemo ( GUI MAIN CLANG SHARED BLITZ WIN32 ) (14 / 14)
main.cpp
plugin/tess2: 8 file(s) built in (0:00.90), 113 msecs / file
GLCtrl: 3 file(s) built in (0:00.58), 194 msecs / file
GLDrawDemo: 1 file(s) built in (0:00.79), 794 msecs / file
GLDraw: 20 file(s) built in (0:01.22), 61 msecs / file
plugin/glew: 1 file(s) built in (1:19.54), 79540 msecs / file <--- !!!

----- ScatterDraw_Demo ( MAIN CLANG DEBUG SHARED DEBUG_FULL BLITZ WIN32 ) (8 / 8)
ScatterDraw_Demo.cpp
ScatterDraw_Demo: 1 file(s) built in (0:02.22), 2225 msecs / file
ScatterDraw: 8 file(s) built in (1:03.92), 7991 msecs / file <--- !!!

Actually, I was using wine on Linux.


Those numbers are real? I mean, is it a problem with clang, or problem with builder printing wrong number?

Mirek
Re: 2020.1 officially released [message #54075 is a reply to message #54073] Sat, 30 May 2020 08:57 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
Novo wrote on Sat, 30 May 2020 07:13
Interesting message when compiling on Windows with CLANGx64:
#0 0x0000000142abaa9c (clang-10+0x2abaa9c)
#1 0x0000000142a52a8c (clang-10+0x2a52a8c)
#2 0x0000000142a6b016 (clang-10+0x2a6b016)
#3 0x0000000142a60146 (clang-10+0x2a60146)
clang-10: error: clang frontend command failed due to signal (use -v to see invocation)
clang version 10.0.0 (https://github.com/llvm/llvm-project.git d32170dbd5b0d54436537b6b75beaf44324e0c28)
Target: x86_64-w64-windows-gnu
Thread model: posix
InstalledDir: c:\local\apps\upp\bin\clang\bin
clang-10: note: diagnostic msg: PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
heapdbg.cpp
CharSet.cpp
t.cpp
z.cpp
lz4.c
xxhash.c
clang-10: note: diagnostic msg: 
********************
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-10: note: diagnostic msg: C:\users\ssg\Temp\wkparser$blitz-44ef80.cpp
clang-10: note: diagnostic msg: C:\users\ssg\Temp\wkparser$blitz-44ef80.sh
clang-10: note: diagnostic msg: 
********************
plugin/bz2: 2 file(s) built in (0:00.37), 186 msecs / file
plugin/bmp: 4 file(s) built in (0:00.30), 76 msecs / file
dvlp/ctrl/about: 1 file(s) built in (0:00.33), 332 msecs / file
Painter: 28 file(s) built in (0:01.72), 61 msecs / file
dvlp/wiki/wkparser: 6 file(s) built in (0:00.47), 79 msecs / file
Draw: 35 file(s) built in (0:00.47), 13 msecs / file
RichText: 22 file(s) built in (0:00.50), 23 msecs / file
CtrlCore: 62 file(s) built in (0:00.87), 14 msecs / file
CtrlLib: 58 file(s) built in (0:02.91), 50 msecs / file
Core: 68 file(s) built in (0:05.87), 86 msecs / file
There were errors. (0:17.72)
program finished with exit code 1
elapsedTime=18.027474

And this is primarily C++98 code with a lot of templates.
I mean my own app.


It would be good to narrow that down to single file / construct and send them report.

For what is worth, for me CLANG was rock stable so far, except maybe some issues with debugger info (but those unfortunately exist with msc as well).

Mirek
Re: 2020.1 officially released [message #54081 is a reply to message #54074] Sat, 30 May 2020 17:10 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
mirek wrote on Sat, 30 May 2020 02:55
Those numbers are real? I mean, is it a problem with clang, or problem with builder printing wrong number?

Mirek

Yes, numbers are real. It is Clang.
Another case with CLANGx64.
----- AddressBookWeb ( MT MAIN CLANG SHARED BLITZ WIN32 ) (10 / 10)
Main.cpp
Pages.icpp
2 warnings generated.
Skylark/Iml: 1 file(s) built in (0:00.16), 160 msecs / file
plugin/jpg: 61 file(s) built in (0:04.61), 75 msecs / file
plugin/png: 3 file(s) built in (0:01.07), 358 msecs / file
AddressBookWeb: 2 file(s) built in (0:01.04), 523 msecs / file
Draw: 35 file(s) built in (0:05.58), 159 msecs / file
plugin/sqlite3: 2 file(s) built in (1:46.72), 53363 msecs / file
Linking...
Z:\home\ssg\.local\soft\bb-worker\worker\wine-upp\build\.cache\upp.out\CLANGx64.Blitz.Mt.Shared\AddressBookWeb.exe (6354432 B) linked in (0:00.72)

As you can see, linking is blazingly fast.
But almost two minutes to compile sqlite3 is unacceptable.


Regards,
Novo
Re: 2020.1 officially released [message #54082 is a reply to message #54081] Sat, 30 May 2020 17:56 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
Another sqlite3 case:
----- SQL_Sqlite3 ( MAIN CLANG SHARED BLITZ WIN32 ) (5 / 5)
simple.cpp
In file included from Z:\home\ssg\.local\soft\bb-worker\worker\wine-upp\build\uppsrc\plugin\sqlite3\lib.c:8:
Z:\home\ssg\.local\soft\bb-worker\worker\wine-upp\build\uppsrc\plugin\sqlite3/lib/sqleet.c:113138:38: warning: implicit conversion from 'long long' to 'double' changes value from 9223372036854775806 to 9223372036854775808 [-Wimplicit-int-float-conversion]
  if( n==0 && r>=0 && r<LARGEST_INT64-1 ){
                       ~~~~~~~~~~~~~~^~
Z:\home\ssg\.local\soft\bb-worker\worker\wine-upp\build\uppsrc\plugin\sqlite3/lib/sqleet.c:113140:46: warning: implicit conversion from 'long long' to 'double' changes value from 9223372036854775806 to 9223372036854775808 [-Wimplicit-int-float-conversion]
  }else if( n==0 && r<0 && (-r)<LARGEST_INT64-1 ){
                               ~~~~~~~~~~~~~~^~
2 warnings generated.
SQL_Sqlite3: 1 file(s) built in (0:00.93), 938 msecs / file
plugin/sqlite3: 2 file(s) built in (2:00.78), 60390 msecs / file
Linking...
Z:\home\ssg\.local\soft\bb-worker\worker\wine-upp\build\.cache\upp.out\CLANGx64.Blitz.Shared\SQL_Sqlite3.exe (5206016 B) linked in (0:00.71)

This time it ran for exactly two minutes. I watched compilation process in top.


Regards,
Novo
Re: 2020.1 officially released [message #54083 is a reply to message #54082] Sat, 30 May 2020 17:57 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
I need to double-check my BM-files. It is possible that all this is my fault.

Regards,
Novo
Re: 2020.1 officially released [message #54086 is a reply to message #54075] Sat, 30 May 2020 22:16 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
mirek wrote on Sat, 30 May 2020 02:57

It would be good to narrow that down to single file / construct and send them report.

For what is worth, for me CLANG was rock stable so far, except maybe some issues with debugger info (but those unfortunately exist with msc as well).

Mirek

I've updated bm-files. Nothing has really changed.
This compiler crash is still there.
Interestingly, all apps in Upp itself can be built without any problems (x64).
This is just my app causing clang to crash, but the compiler is crashing when compiling Core. This is weird.
I'll double-check situation with i686. Everything was fine with it.


Regards,
Novo
Re: 2020.1 officially released [message #54088 is a reply to message #54086] Sat, 30 May 2020 22:52 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
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 #54096 is a reply to message #54088] Sun, 31 May 2020 23:13 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
Novo wrote on Sat, 30 May 2020 22:52
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.


What about those compile times?
Re: 2020.1 officially released [message #54098 is a reply to message #54096] Mon, 01 June 2020 00:36 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
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 #54103 is a reply to message #54098] Mon, 01 June 2020 10:19 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
Novo wrote on Mon, 01 June 2020 00:36
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.


Fixed...

Well, in Win32 it works more or less fine:

----- Core ( CLANG DEBUG DEBUG_FULL BLITZ WIN32 ) (1 / 4)
----- plugin/Eigen ( CLANG DEBUG DEBUG_FULL BLITZ WIN32 ) (2 / 4)
----- plugin/z ( CLANG DEBUG DEBUG_FULL BLITZ WIN32 ) (3 / 4)
----- Eigen_demo ( MAIN CLANG DEBUG DEBUG_FULL BLITZ WIN32 ) (4 / 4)
eigen_demo.cpp
non-linear.cpp
fft.cpp
Eigen_demo: 3 file(s) built in (0:26.75), 8916 msecs / file
Linking...
C:\upp\out\reference\CLANGx64.Debug.Debug_Full\Eigen_demo.ex e (6641664 B) linked in (0:00.85)

OK. (0:28.09)

It however seems to take a bit longer to compile fft.cpp...
Re: 2020.1 officially released [message #54104 is a reply to message #54103] Mon, 01 June 2020 10:23 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
OK, 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
Re: 2020.1 officially released [message #54109 is a reply to message #54104] Mon, 01 June 2020 14:17 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3458
Registered: August 2008
Senior Veteran
Yes, Eigen uses template metaprogramming to optimize speed handling SSE2 and Altivec. The cost of it is longer compiling time.
Just a simple vector sum like u = v + w, has some black magic inside.
This is explined here.


Best regards
IƱaki

[Updated on: Mon, 01 June 2020 14:19]

Report message to a moderator

Re: 2020.1 officially released [message #54113 is a reply to message #54109] Mon, 01 June 2020 21:35 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
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 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
mirek wrote on Mon, 01 June 2020 04:23
OK, 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 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
Novo wrote on Mon, 01 June 2020 21:41
mirek wrote on Mon, 01 June 2020 04:23
OK, 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 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
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 #54117 is a reply to message #54116] Mon, 01 June 2020 22:16 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
I have just checked linux clang and gcc (different machine).

Linux clang compiles sqlite3 lib.c in 50s, gcc in 30s.

Mirek
Re: 2020.1 officially released [message #54118 is a reply to message #54117] Mon, 01 June 2020 22:40 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
I managed to compile Eigen_demo in Debug ... Smile

$ wine umk reference Eigen_demo CLANGx64 -bu
----- Core ( CLANG DEBUG DEBUG_FULL BLITZ WIN32 ) (1 / 4)
----- plugin/Eigen ( CLANG DEBUG DEBUG_FULL BLITZ WIN32 ) (2 / 4)
----- plugin/z ( CLANG DEBUG DEBUG_FULL BLITZ WIN32 ) (3 / 4)
----- Eigen_demo ( MAIN CLANG DEBUG DEBUG_FULL BLITZ WIN32 ) (4 / 4)
BLITZ: eigen_demo.cpp non-linear.cpp fft.cpp
Eigen_demo: 3 file(s) built in (37:40.15), 753384 msecs / file
Linking...
Z:\home\ssg\.local\soft\bb-worker\worker\wine-upp\build\.cache\upp.out\CLANGx64.Debug.Debug_Full\Eigen_demo.exe (6637568 B) linked in (0:01.46)

OK. (37:42.11)

Less than 40 minutes Smile


Regards,
Novo
Re: 2020.1 officially released [message #54119 is a reply to message #54118] Mon, 01 June 2020 23:07 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
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 #54120 is a reply to message #54118] Mon, 01 June 2020 23:10 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
Novo wrote on Mon, 01 June 2020 16:40
I managed to compile Eigen_demo in Debug ... Smile

$ wine umk reference Eigen_demo CLANGx64 -bu
----- Core ( CLANG DEBUG DEBUG_FULL BLITZ WIN32 ) (1 / 4)
----- plugin/Eigen ( CLANG DEBUG DEBUG_FULL BLITZ WIN32 ) (2 / 4)
----- plugin/z ( CLANG DEBUG DEBUG_FULL BLITZ WIN32 ) (3 / 4)
----- Eigen_demo ( MAIN CLANG DEBUG DEBUG_FULL BLITZ WIN32 ) (4 / 4)
BLITZ: eigen_demo.cpp non-linear.cpp fft.cpp
Eigen_demo: 3 file(s) built in (37:40.15), 753384 msecs / file
Linking...
Z:\home\ssg\.local\soft\bb-worker\worker\wine-upp\build\.cache\upp.out\CLANGx64.Debug.Debug_Full\Eigen_demo.exe (6637568 B) linked in (0:01.46)

OK. (37:42.11)

Less than 40 minutes Smile

Without BLITZ it takes only 20 minutes Smile
----- Eigen_demo ( MAIN CLANG DEBUG DEBUG_FULL WIN32 ) (4 / 4)
eigen_demo.cpp
non-linear.cpp
fft.cpp
Eigen_demo: 3 file(s) built in (20:14.75), 404918 msecs / file
Linking...
Z:\home\ssg\.local\soft\bb-worker\worker\wine-upp\build\.cache\upp.out\CLANGx64.Debug.Debug_Full.Noblitz\Eigen_demo.exe (6253568 B) linked in (0:01.40)

OK. (21:47.23)



Regards,
Novo
Re: 2020.1 officially released [message #54121 is a reply to message #54120] Mon, 01 June 2020 23:27 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
I'm afraid it is wine to blame in my case.
Clang-10 spends ~75% of its time calling one function in ntdll.dll.so


Regards,
Novo
Re: 2020.1 officially released [message #54122 is a reply to message #54113] Mon, 01 June 2020 23:31 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
Novo wrote on Mon, 01 June 2020 15:35
I 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 #54123 is a reply to message #54121] Mon, 01 June 2020 23:32 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
Maybe you can try cross-compilation.

https://github.com/mstorsjo/llvm-mingw/releases

If you do not have ubuntu 18.04, building llvm-mingw for you linux distro should be relatively simple....

It could be interesting experiment. Actually, we can even add a simple support in ide / umake to prepend binary with "wine" for execution... Smile

Mirek
Re: 2020.1 officially released [message #54124 is a reply to message #54122] Mon, 01 June 2020 23:34 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
Novo wrote on Mon, 01 June 2020 23:31
Novo wrote on Mon, 01 June 2020 15:35
I have no idea where flagCLR is coming from ...
wine umk tutorial Gui01 CLANGx64cpp17 -bu


It would be great to get this fixed ...


I will ASAP, but not today. For now in RM. If it is not fixed by the end of week, please ping me.
Re: 2020.1 officially released [message #54125 is a reply to message #54121] Tue, 02 June 2020 10:31 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
Novo wrote on Mon, 01 June 2020 23:27
I'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
Re: 2020.1 officially released [message #54129 is a reply to message #54125] Tue, 02 June 2020 16:24 Go to previous messageGo to previous message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
mirek wrote on Tue, 02 June 2020 04:31
Novo wrote on Mon, 01 June 2020 23:27
I'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
Previous Topic: get_i
Next Topic: theide: New Threads tab in PDB debugger
Goto Forum:
  


Current Time: Sat Apr 25 18:01:18 GMT+2 2026

Total time taken to generate the page: 0.01127 seconds