[Bug c++/92572] New: Vague linkage does not work reliably when a matching segment is in a dynamically linked libarary on Linux

2019-11-18 Thread wkaras at yahoo dot com
: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: wkaras at yahoo dot com Target Milestone: --- Here is an example: -- (conanrunenv) [root@d761696b8abf VagueDynLink]# bash -x x.sh + cat

[Bug c++/93666] New: Dependence of optimization on use of constexpr seems inappropriate

2020-02-10 Thread wkaras at yahoo dot com
Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: wkaras at yahoo dot com Target Milestone: --- In this example, the optimization behavior changes simply by adding the constexpr keyword: https://gcc.godbolt.org/z/3zWWrH My

[Bug c++/92572] Vague linkage does not work reliably when a matching segment is in a dynamically linked libarary on Linux

2020-02-10 Thread wkaras at yahoo dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92572 --- Comment #3 from Walt Karas --- (conanrunenv) [root@d761696b8abf setup-work]# cc -v Using built-in specs. COLLECT_GCC=cc COLLECT_LTO_WRAPPER=/opt/rh/devtoolset-8/root/usr/libexec/gcc/x86_64-redhat-linux/8/lto-wrapper Target: x86_64-redhat-linu

[Bug c++/92572] Vague linkage does not work reliably when a matching segment is in a dynamically linked libarary on Linux

2020-02-10 Thread wkaras at yahoo dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92572 --- Comment #4 from Walt Karas --- (conanrunenv) [root@d761696b8abf VagueDynLink]# cc -O2 -Wall -Wextra -pedantic -std=c++17 -fno-strict-aliasing -fwrapv -S main.cc (conanrunenv) [root@d761696b8abf VagueDynLink]# cat main.s .file "main.

[Bug c++/92572] Vague linkage does not work reliably when a matching segment is in a dynamically linked libarary on Linux

2020-02-13 Thread wkaras at yahoo dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92572 --- Comment #7 from Walt Karas --- I see this problem running in a Docker container on a MacBook. When I try it on the Mac (clang, Darwin kernel), the output is 2.

[Bug c++/89937] New: For example code, which is valid as either C or C++, optimization seems much better for C

2019-04-02 Thread wkaras at yahoo dot com
Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: wkaras at yahoo dot com Target Milestone: --- I compiled this code with -O2, and with either -x c or -x c++ . The optimization seems to work much better for C

[Bug c++/89937] For example code, which is valid as either C or C++, optimization seems much better for C

2019-04-03 Thread wkaras at yahoo dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89937 --- Comment #2 from Walt Karas --- (In reply to Andrew Pinski from comment #1) > This is because of the way inline have different semantics between the two > langauges. > > If I change TSFastDbg to be static instead of just inline, then the code

[Bug c++/89937] For example code, which is valid as either C or C++, optimization seems much better for C

2019-04-04 Thread wkaras at yahoo dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89937 --- Comment #6 from Walt Karas --- Yes, very sorry, I didn't realize inline was so different in C, and I also didn't read the generated machine code carefully enough. It does seem extremely surprising that, for C, the body of an inline function

[Bug c++/70767] New: std::numeric_limits::digits is wrong unless --std=c++11 used

2016-04-22 Thread wkaras at yahoo dot com
Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: wkaras at yahoo dot com Target Milestone: --- Created attachment 38331 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38331&action=edit bash script, see bug description The v