[Bug c++/91636] New: performance regression about const string optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91636
Bug ID: 91636
Summary: performance regression about const string optimization
Product: gcc
Version: 7.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: baiwfg2 at gmail dot com
Target Milestone: ---
Hi. I'm benchmarking const std::string optimization with different gcc version
and find that gcc 7.3.1 is not working well. Here's my benchmark code (I also
put it on wandbox: https://wandbox.org/permlink/vuAZWRp4H6S6Foh2) :
```
#include
#include
#include
#include
#include
using namespace std;
void bad() {
for (int i=0; i<1000; i++) {
string s;
s = "loog";
}
}
void good() {
for (int i=0; i<1000; i++) {
const string s =
"loog";
}
}
typedef void(*fp)();
void timing(fp fn) {
auto begin = std::chrono::high_resolution_clock::now();
fn();
auto end = std::chrono::high_resolution_clock::now();
std::cout <<
std::chrono::duration_cast(end-begin).count() <<
std::endl;
}
int main(int argc, char* argv[])
{
if (argc != 2) {
cout << "wrong args\n";
exit(1);
}
char c = argv[1][0];
if (c == '1')
timing(bad);
else if (c == '2')
timing(good);
}
```
Obviously the good() is better than bad(). But when I try compiling:
g++-7.3.1 a.cc -O2
And run it. It gives much worse result(good() is -7% more efficient than bad())
than any other version does, such as gcc 7.3.0, 7.4.0, 8.3.0( 30-40% more
efficient).
My gcc 7.3.1 version info is:
[root@VM_11_190_centos /data1/ethencao]# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--with-default-libstdcxx-abi=gcc4-compatible --enable-gnu-unique-object
--enable-linker-build-id --with-gcc-major-version-only
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl
--enable-libmpx --enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64
--build=x86_64-redhat-linux
Thread model: posix
gcc version 7.3.1 20180303 (Red Hat 7.3.1-6) (GCC)
By the way, I don't install gcc by source compiling. Instead I use yum,
apt-get, or docker to use it.
[Bug c++/91636] performance regression about const string optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91636 --- Comment #2 from Chan Lewis --- (In reply to Jonathan Wakely from comment #1) > (In reply to Chan Lewis from comment #0) > > My gcc 7.3.1 version info is: > > > > [root@VM_11_190_centos /data1/ethencao]# gcc -v > > Using built-in specs. > > COLLECT_GCC=gcc > > COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper > > OFFLOAD_TARGET_NAMES=nvptx-none > > OFFLOAD_TARGET_DEFAULT=1 > > Target: x86_64-redhat-linux > > Configured with: ../configure --enable-bootstrap > > --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr > > --mandir=/usr/share/man --infodir=/usr/share/info > > --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared > > --enable-threads=posix --enable-checking=release --enable-multilib > > --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions > > --with-default-libstdcxx-abi=gcc4-compatible > > As I already told you by email, you're comparing apples with oranges. Your > GCC 7.3.1 uses the old std::string ABI, as shown by the line above. I'm sorry for that. I'd thought it's different from devtoolset's gcc. It turns out I've been always using Redhat's gcc. You mean the cause is just this: `--with-default-libstdcxx-abi=gcc4-compatible` or is the Redhat gcc itself ? What's the standard output of GNU gcc -v ?
[Bug c/110399] New: pointer substraction causes coredump with ftrapv on edge case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110399
Bug ID: 110399
Summary: pointer substraction causes coredump with ftrapv on
edge case
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: baiwfg2 at gmail dot com
Target Milestone: ---
The demo code is :
```c
#include
#include
#include
#include
int main() {
{
char *p = (char *)0x8001;
char *q = (char *)0x7fff;
uint32_t w = p - q;
printf("32 bit, w1=%u\n", w);
}
{
char *p = (char *)0x7fff;
char *q = (char *)0x7ffd;
uint32_t w2 = p - q;
printf("w2=%u\n", w2);
}
{
char *p = (char *)0x8003;
char *q = (char *)0x8001;
uint32_t w3 = p - q;
printf("w3=%u\n", w3);
}
{
char *p = (char *)0x8001;
char *q = (char *)0x0001;
uint32_t w4 = p - q;
printf("w4=%u\n", w4); // ans is 0, not crash under -ftrapv
}
{
char *p = (char *)0x8001;
char *q = (char *)0x7fff;
uint32_t w5 = (uintptr_t)p - (uintptr_t)q;
printf("w5=%u\n", w5);
}
{
char *p = (char *)0x8001; // use uint8_t also crash
char *q = (char *)0x7fff; // use smaller num
0x0011, also crash
uint32_t w6 = p - q;
printf("w6=%u\n", w6); // crash under gcc -ftrapv, not crash under
clang -ftrapv
}
return 0;
}
```
The statement w6 = p - q cause coredump. But what program actually means do
pointer unsigned arithmetic operation. How can I make it right(that is, output
2) with ftrapv option ? I find it's ok with clang -ftrapv .
This happens on many gcc versions.
[Bug middle-end/110399] pointer substraction causes coredump with ftrapv on edge case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110399 --- Comment #3 from Chan Lewis --- (In reply to Andrew Pinski from comment #2) > Dup of bug 13421. > > *** This bug has been marked as a duplicate of bug 13421 *** I see. I wonder why gcc consider pointer signed and need to abort in this case, whereas clang still works as expected. If we change pointer to unsigned in our codebase, that will be lots of work.
