[Bug c++/51559] New: decimal128 operates incorrectly compared to decimal32 and decimal64

2011-12-14 Thread mingodad at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51559 Bug #: 51559 Summary: decimal128 operates incorrectly compared to decimal32 and decimal64 Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED

[Bug c++/51559] decimal128 operates incorrectly compared to decimal32 and decimal64

2011-12-14 Thread mingodad at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51559 --- Comment #1 from Domingo Alvarez 2011-12-14 23:41:16 UTC --- Created attachment 26094 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26094 A c program that demonstrate the same problem Here is a c program that exibits the same problem, s

[Bug c++/51559] decimal128 operates incorrectly compared to decimal32 and decimal64

2011-12-15 Thread mingodad at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51559 Domingo Alvarez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|

[Bug c++/51364] C++ interoperability with ISO-C extension DFP types requires explicit typedefs.

2011-12-17 Thread mingodad at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51364 Domingo Alvarez changed: What|Removed |Added CC||mingodad at gmail dot com --- Comment

[Bug c++/51364] C++ interoperability with ISO-C extension DFP types requires explicit typedefs.

2011-12-18 Thread mingodad at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51364 --- Comment #8 from Domingo Alvarez 2011-12-18 23:30:43 UTC --- (In reply to comment #7) > An executable with decimal float support is very big because the runtime > support is in static libraries, not in shared libraries (DLLs). That will > pro

[Bug c++/51364] C++ interoperability with ISO-C extension DFP types requires explicit typedefs.

2011-12-18 Thread mingodad at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51364 --- Comment #10 from Domingo Alvarez 2011-12-19 02:25:16 UTC --- Created attachment 26131 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26131 Program to show that gcc doesn't generate good code size Here is a program and a batch file that

[Bug c/51622] New: GCC generates bad code that generate big executable sizes when using _Decimal*

2011-12-19 Thread mingodad at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51622 Bug #: 51622 Summary: GCC generates bad code that generate big executable sizes when using _Decimal* Classification: Unclassified Product: gcc Version: 4.6.1 Status:

[Bug c/51622] GCC generates bad code that generate big executable sizes when using _Decimal*

2011-12-19 Thread mingodad at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51622 --- Comment #1 from Domingo Alvarez 2011-12-19 12:17:28 UTC --- If code generation is solved probably we can have better results with the following: lua 5.1.4 with double -> 150KB lua 5.1.4 with _Decimal64 -> 2.4MB *with ***bad code generation l

[Bug c/51622] GCC generates bad code that generate big executable sizes when using _Decimal*

2011-12-19 Thread mingodad at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51622 --- Comment #4 from Domingo Alvarez 2011-12-19 14:30:26 UTC --- Created attachment 26143 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26143 Another program to demonstrate gcc bad code generation On the previous example program my conclusi

[Bug c/51622] GCC generates bad code that generate big executable sizes when using _Decimal*

2011-12-19 Thread mingodad at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51622 --- Comment #5 from Domingo Alvarez 2011-12-19 14:34:11 UTC --- (In reply to comment #2) > Which architecture are you compiling for? gcc mingw32 4.6.1 32bits

[Bug c/51622] GCC generates bad code that generate big executable sizes when using _Decimal*

2011-12-19 Thread mingodad at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51622 --- Comment #6 from Domingo Alvarez 2011-12-19 14:40:45 UTC --- Rewrite expected executable sizes with a realistic better code generation by gcc. If code generation is solved probably we can have better results with the following: lua 5.1.4 wit

[Bug c/51622] GCC generates bad code that generate big executable sizes when using _Decimal*

2011-12-19 Thread mingodad at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51622 --- Comment #8 from Domingo Alvarez 2011-12-19 21:19:40 UTC --- Here is my contribution of bid_decimal.c splitted into several parts to allow better link size and easy edit/view. http://code.google.com/p/luafltk/downloads/detail?name=bid_decimal

[Bug c/51622] GCC generates bad code that generate big executable sizes when using _Decimal*

2011-12-20 Thread mingodad at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51622 --- Comment #9 from Domingo Alvarez 2011-12-20 17:30:55 UTC --- Some mistakes corrected and it was compiled with mingw 4.6.1 and wotk as expected. The results: lua 5.1.4 with _Decimal64 from 2.4MB to 681KB sqlite3 with _Decimal64 from 3MB to 1.2

[Bug c/51622] GCC generates bad code that generate big executable sizes when using _Decimal*

2011-12-21 Thread mingodad at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51622 --- Comment #10 from Domingo Alvarez 2011-12-21 10:36:45 UTC --- Now looking on the net I found that libbid history and could see that the actual one monolithic bid_decimalbinary file is a recent creation before it was splited over several files,

[Bug c++/91859] New: Optnization -O2 removes valid and necessary code

2019-09-23 Thread mingodad at gmail dot com
: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mingodad at gmail dot com Target Milestone: --- When compiling the sample bellow with g++9 (9.1 and 9.2) with optmization -O2 the generated code eliminates a valid and necessary code: = #include #include struct

[Bug c++/91859] Optnization -O2 removes valid and necessary code

2019-09-23 Thread mingodad at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91859 --- Comment #3 from Domingo Alvarez --- Thank you ! I was suspecting it after report this problem and added a destructor to the sample and then the code behaves as you describe. Sorry by the noise and thank you again !