[Bug libstdc++/71556] New: set::get_time() requires leading 0s for %H and friends
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71556 Bug ID: 71556 Summary: set::get_time() requires leading 0s for %H and friends Product: gcc Version: 6.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: j...@jak-linux.org Target Milestone: --- Created attachment 38713 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38713&action=edit C++ reproducer In contrast to strptime(), std::get_time() requires leading zeroes for %H and friends, so times with " 9" (%k formatting) instead of "09" cannot be parsed. The C++ standard requires get_time() to work like strptime(), as far as I can tell, and cppreference tells us that leading 0s are permitted, but optional. This means we cannot parse a date like: "Thu, 16 Jun 2016 9:35:47 UTC" which in turn breaks date parsing for recent APT versions when we switched from strptime to std::get_time().
[Bug libstdc++/71556] set::get_time() requires leading 0s for %H and friends
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71556 --- Comment #1 from Julian Andres Klode --- To be clear, while the attachment uses the (I assume still) non-standard C.UTF-8, the same also happens with the C locale, and the "" locale in an en_IE.UTF-8 environment.
[Bug target/81501] New: Unneccessary calls to __tls_get_addr() in simple thread-singleton pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81501
Bug ID: 81501
Summary: Unneccessary calls to __tls_get_addr() in simple
thread-singleton pattern
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: j...@jak-linux.org
Target Milestone: ---
I only tested this on amd64, but see for yourself:
+ cat t.cc
struct foo {
foo();
~foo();
};
foo *test() {
static thread_local foo foo_tls;
return &foo_tls;
}
+ g++-7 -std=c++14 -v -pthread -fPIC -shared -O2 -o gcc.so t.cc
Using built-in specs.
COLLECT_GCC=/usr/bin/g++-7
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 7.1.0-9'
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.1.0 (Debian 7.1.0-9)
COLLECT_GCC_OPTIONS='-std=c++14' '-v' '-pthread' '-fPIC' '-shared' '-O2' '-o'
'gcc.so' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/7/cc1plus -quiet -v -imultiarch x86_64-linux-gnu
-D_GNU_SOURCE -D_REENTRANT t.cc -quiet -dumpbase t.cc -mtune=generic
-march=x86-64 -auxbase t -O2 -std=c++14 -version -fPIC -o /tmp/ccdUrCDS.s
GNU C++14 (Debian 7.1.0-9) version 7.1.0 (x86_64-linux-gnu)
compiled by GNU C version 7.1.0, GMP version 6.1.2, MPFR version 3.1.5,
MPC version 1.0.3, isl version isl-0.18-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/7"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/7
/usr/include/x86_64-linux-gnu/c++/7
/usr/include/c++/7/backward
/usr/lib/gcc/x86_64-linux-gnu/7/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/7/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
GNU C++14 (Debian 7.1.0-9) version 7.1.0 (x86_64-linux-gnu)
compiled by GNU C version 7.1.0, GMP version 6.1.2, MPFR version 3.1.5,
MPC version 1.0.3, isl version isl-0.18-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 3681302eda59faba4e53a905eca4bf72
COLLECT_GCC_OPTIONS='-std=c++14' '-v' '-pthread' '-fPIC' '-shared' '-O2' '-o'
'gcc.so' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
as -v --64 -o /tmp/ccI2B3TO.o /tmp/ccdUrCDS.s
GNU assembler version 2.28 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Debian) 2.28
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-std=c++14' '-v' '-pthread' '-fPIC' '-shared' '-O2' '-o'
'gcc.so' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/7/collect2 -plugin
/usr/lib/gcc/x86_64-linux-gnu/7/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
-plugin-opt=-fresolution=/tmp/cc9S0zbL.res -plugin-opt=-pass-through=-lgcc_s
[Bug target/81501] Unneccessary calls to __tls_get_addr() in simple thread-singleton pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81501 --- Comment #1 from Julian Andres Klode --- To qualify the performance overhead, I added empty constructors and destructors with noinline, and compiled the code with g++ and clang++, and then ran a loop 1 over the function. The clang code took 6 nanosecond, the g++ code 8 nanosecond per iteration, that's 33% worse. I think it's probably a neglectable overhead after all, but it seems like that would be a sensible and maybe an easy optimization to do.
[Bug c++/81408] New: Lots of new -Wunsafe-loop-optimizations warnings with 7 compared to 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81408 Bug ID: 81408 Summary: Lots of new -Wunsafe-loop-optimizations warnings with 7 compared to 6 Product: gcc Version: 7.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: j...@jak-linux.org Target Milestone: --- Created attachment 41726 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41726&action=edit Minimized example Compiling a recent apt with g++-7 causes a lot more unsafe loop optimizations warnings than g++ 6 did (134 vs 8). That's a massive regression. 7.1.0 build log: https://launchpadlibrarian.net/327296659/buildlog_ubuntu-artful-i386.apt_1.5~beta1_BUILDING.txt.gz 6.3.0 build log: https://launchpadlibrarian.net/326714445/buildlog_ubuntu-artful-i386.apt_1.5~beta1_BUILDING.txt.gz It seems these are for-each kind of loops. I attached a simple minimized example from one of the cases mentioned in the log.
[Bug c++/81408] Lots of new -Wunsafe-loop-optimizations warnings with 7 compared to 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81408 --- Comment #1 from Julian Andres Klode --- Created attachment 41727 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41727&action=edit preprocessed source of a.cc
[Bug c++/81408] Lots of new -Wunsafe-loop-optimizations warnings with 7 compared to 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81408 --- Comment #2 from Julian Andres Klode --- Build log with -v: Using built-in specs. COLLECT_GCC=/usr/bin/g++-7 OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 7.1.0-9' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 7.1.0 (Debian 7.1.0-9) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-O2' '-Wunsafe-loop-optimizations' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/7/cc1plus -E -quiet -v -imultiarch x86_64-linux-gnu -D_GNU_SOURCE a.cc -mtune=generic -march=x86-64 -Wunsafe-loop-optimizations -O2 -fpch-preprocess -o a.ii ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/7" ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/include/c++/7 /usr/include/x86_64-linux-gnu/c++/7 /usr/include/c++/7/backward /usr/lib/gcc/x86_64-linux-gnu/7/include /usr/local/include /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed /usr/include/x86_64-linux-gnu /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-O2' '-Wunsafe-loop-optimizations' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/7/cc1plus -fpreprocessed a.ii -quiet -dumpbase a.cc -mtune=generic -march=x86-64 -auxbase a -O2 -Wunsafe-loop-optimizations -version -o a.s GNU C++14 (Debian 7.1.0-9) version 7.1.0 (x86_64-linux-gnu) compiled by GNU C version 7.1.0, GMP version 6.1.2, MPFR version 3.1.5, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++14 (Debian 7.1.0-9) version 7.1.0 (x86_64-linux-gnu) compiled by GNU C version 7.1.0, GMP version 6.1.2, MPFR version 3.1.5, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 3681302eda59faba4e53a905eca4bf72 a.cc: In function ‘void ShowHelpListCommands(const std::vector&)’: a.cc:11:24: warning: missed loop optimization, the loop counter may overflow [-Wunsafe-loop-optimizations] for (auto const &c: Cmds) ^~~~ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-O2' '-Wunsafe-loop-optimizations' '-shared-libgcc' '-mtune=generic' '-march=x86-64' as -v --64 -o a.o a.s GNU assembler version 2.28 (x86_64-linux-gnu) using BFD version (GNU Binutils for Debian) 2.28 COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-O2' '-Wunsafe-loop-optimizations' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
[Bug c++/81408] Lots of new -Wunsafe-loop-optimizations warnings with 7 compared to 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81408 --- Comment #3 from Julian Andres Klode --- 7.1.0-9 corresponds to "SVN 20170705 (r250006) from the gcc-7-branch."
[Bug c++/81408] Lots of new -Wunsafe-loop-optimizations warnings with 7 compared to 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81408 --- Comment #4 from Julian Andres Klode --- Note that apt has 1219 loops, so 134 is almost 11% of the loops causing the warning, compared to about 0.7% (8) before.
[Bug c++/79476] New: C++ frontend ignores diagnostic pragma in macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79476
Bug ID: 79476
Summary: C++ frontend ignores diagnostic pragma in macro
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: j...@jak-linux.org
Target Milestone: ---
Created attachment 40721
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40721&action=edit
Reproducer
We define three macros in APT:
#define APT_IGNORE_DEPRECATED_PUSH \
_Pragma("GCC diagnostic push") \
_Pragma("GCC diagnostic ignored \"-Wdeprecated-declarations\"")
#define APT_IGNORE_DEPRECATED_POP \
_Pragma("GCC diagnostic pop")
#define APT_IGNORE_DEPRECATED(XXX) \
APT_IGNORE_DEPRECATED_PUSH \
XXX \
APT_IGNORE_DEPRECATED_POP
So you can do stuff like APT_IGNORE_DEPRECATED(f();). This does not work
correctly however. Compiling the attached file with the C compiler results in
no warnings, with the C++ compiler a warning is emitted for
APT_IGNORE_DEPRECATED(f();) but not for using push/pop macros explicitly around
the f(); in the other functions:
$ gcc -c -Wdeprecated-declarations a.c
$ g++ -c -Wdeprecated-declarations a.c
a.c: In function ‘int a()’:
a.c:15:27: warning: ‘int f()’ is deprecated [-Wdeprecated-declarations]
APT_IGNORE_DEPRECATED(f();)
^
a.c:8:3: note: in definition of macro ‘APT_IGNORE_DEPRECATED’
XXX \
^~~
a.c:11:5: note: declared here
int f() __attribute__((deprecated));
^
a.c:15:29: warning: ‘int f()’ is deprecated [-Wdeprecated-declarations]
APT_IGNORE_DEPRECATED(f();)
^
a.c:8:3: note: in definition of macro ‘APT_IGNORE_DEPRECATED’
XXX \
^~~
a.c:11:5: note: declared here
int f() __attribute__((deprecated));
^
According to cpp, all functions expand to the same code.
This used to work at some point a long time ago, but I can't remember when.
[Bug c/83139] New: error: null destination pointer [-Werror=format-truncation=] for second call with same destination pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83139 Bug ID: 83139 Summary: error: null destination pointer [-Werror=format-truncation=] for second call with same destination pointer Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: j...@jak-linux.org Target Milestone: --- Created attachment 42701 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42701&action=edit Example In the attached example (minified proxychains common.c), there are two cases of snprintf(pbuf, bufsize, in a function. The second one causes an error, at -O2 or higher: $ gcc -Wall -Werror -O2 -c -v -save-temps common.c Using built-in specs. COLLECT_GCC=/usr/bin/gcc OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 7.2.0-16' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 7.2.0 (Debian 7.2.0-16) COLLECT_GCC_OPTIONS='-Wall' '-Werror' '-O2' '-c' '-v' '-save-temps' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/7/cc1 -E -quiet -v -imultiarch x86_64-linux-gnu common.c -mtune=generic -march=x86-64 -Wall -Werror -O2 -fpch-preprocess -o common.i ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/x86_64-linux-gnu/7/include /usr/local/include /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed /usr/include/x86_64-linux-gnu /usr/include End of search list. COLLECT_GCC_OPTIONS='-Wall' '-Werror' '-O2' '-c' '-v' '-save-temps' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/7/cc1 -fpreprocessed common.i -quiet -dumpbase common.c -mtune=generic -march=x86-64 -auxbase common -O2 -Wall -Werror -version -o common.s GNU C11 (Debian 7.2.0-16) version 7.2.0 (x86_64-linux-gnu) compiled by GNU C version 7.2.0, GMP version 6.1.2, MPFR version 3.1.6, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C11 (Debian 7.2.0-16) version 7.2.0 (x86_64-linux-gnu) compiled by GNU C version 7.2.0, GMP version 6.1.2, MPFR version 3.1.6, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 4f65f393f8f34cf4758c10c601ec207f common.c: In function ‘get_config_path’: common.c:29:2: error: null destination pointer [-Werror=format-truncation=] snprintf(pbuf, bufsize, "%s/.proxychains/%s", path, PROXYCHAINS_CONF_FILE); ^~~ cc1: all warnings being treated as errors If the pointer was not NULL before, and there is no char** pointer at all, there seems to be no way it could suddenly become NULL, so the error is wrong.
[Bug c/83139] error: null destination pointer [-Werror=format-truncation=] for second call with same destination pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83139 --- Comment #1 from Julian Andres Klode --- Created attachment 42702 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42702&action=edit generated .i file
[Bug c/83139] error: null destination pointer [-Werror=format-truncation=] for second call with same destination pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83139 --- Comment #2 from Julian Andres Klode --- Apparently, this is because check_path() is being inlined and checks that the argument is NULL. Then when it sees the second use of pbuf, it considers it possible that it is NULL. I'm not sure it's really a bug. It depends on whether it would do the same if check_path() were used elsewhere where the !pbuf check is actually important.
[Bug target/77729] New: aarch64 inserts unneeded uxtb after ldrb, orr ...32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77729 Bug ID: 77729 Summary: aarch64 inserts unneeded uxtb after ldrb, orr ...32 Product: gcc Version: 6.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: j...@jak-linux.org Target Milestone: --- In the attached test case, the aarch64 target inserts a uxtb instruction that is not needed: ldrbw1, [x0] orr w1, w1, 32 uxtbw1, w1 cmp w1, 116 The arm backend handles that just fine: ldrbr3, [r0]@ zero_extendqisi2 orr r3, r3, #32 cmp r3, #116 It also works with 33 or 34 instead of 32 for whatever reasons.
[Bug target/77729] aarch64 inserts unneeded uxtb after ldrb, orr ...32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77729 --- Comment #2 from Julian Andres Klode --- Created attachment 39676 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39676&action=edit Aarch64 output at -O2
[Bug target/77729] aarch64 inserts unneeded uxtb after ldrb, orr ...32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77729 --- Comment #1 from Julian Andres Klode --- Created attachment 39675 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39675&action=edit C reproducer
[Bug target/77729] aarch64 inserts unneeded uxtb after ldrb, orr ...32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77729 --- Comment #3 from Julian Andres Klode --- Created attachment 39677 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39677&action=edit arm (thumb2) output at -O2
[Bug target/77729] aarch64 inserts unneeded uxtb after ldrb, orr ...32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77729 --- Comment #5 from Julian Andres Klode --- Created attachment 39678 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39678&action=edit ppc64le Hmm, AFAICT the same seems to happen on powerpc64le: lbz 9,0(3) # Load zero ori 9,9,0x20# ors in 32 rlwinm 9,9,0,0xff # zero extend value AFAICT cmpwi 7,9,116 So far tested: good: mipsel, x86_64, armhf (thumb2) bad: aarch64, powerpc64le
[Bug target/77729] aarch64 inserts unneeded uxtb after ldrb, orr ...32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77729
--- Comment #6 from Julian Andres Klode ---
(In reply to Andrew Pinski from comment #4)
> Note this testcase needs to be improved as I have a patch which converts a
> switch with just one case and a default into anew if statement.
FWIW, The issue is exactly the same with if statements, like in:
int TrieCase3(const char *string)
{
if((string[0] | 32) == 't') {
if((string[1] | 32) == 'a') {
if((string[2] | 32) == 'g') {
return 42;
}
}
}
return -1;
}
[Bug target/77729] aarch64 inserts unneeded uxtb after ldrb, orr ...32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77729 --- Comment #9 from Julian Andres Klode --- (In reply to Andrew Pinski from comment #8) > This looks like missing removal of casts. > > Note in C, char_var|32 is really the same as ((int)char_var)|32 Well. The loads of the byte are already zero-extend loads. The current code is like saying: (int) ((int)char|32) :)
[Bug c/46186] New: Clang creates code running 1600 times faster than gcc's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186 Summary: Clang creates code running 1600 times faster than gcc's Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: j...@jak-linux.org Created attachment 22161 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22161 C file The attached code compiles into an executable that takes 1.6 seconds to run, when compiled with clang, it takes 0.001 seconds (both with -O2 as the only compiler option).
[Bug c/46186] Clang creates code running 1600 times faster than gcc's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186 --- Comment #1 from Julian Andres Klode 2010-10-26 14:30:24 UTC --- Created attachment 22162 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22162 Clang's assember Attaching the assembler output from clang, it should help understand which optimizations clang does (and improve gcc to do them as well).
[Bug c/46186] Clang creates code running 1600 times faster than gcc's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186 --- Comment #3 from Julian Andres Klode 2010-10-26 14:32:27 UTC --- System information: Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.4.5 (Debian 4.4.5-5)
[Bug c/46186] Clang creates code running 1600 times faster than gcc's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186 --- Comment #5 from Julian Andres Klode 2010-10-26 14:53:24 UTC --- (In reply to comment #4) > GCC's output is significantly faster at -O3 or without the noinline attribute I just tested and at -O3, gcc-4.4 creates slow code and gcc-4.5 fast code. At -O2, both are equally fast. The clang 1.1 code at -O2 is as fast as GCC 4.5's code at -O3.
[Bug c/46186] Clang creates code running 1600 times faster than gcc's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186 --- Comment #7 from Julian Andres Klode 2010-10-26 15:00:37 UTC --- (In reply to comment #5) > (In reply to comment #4) > > GCC's output is significantly faster at -O3 or without the noinline > > attribute > > I just tested and at -O3, gcc-4.4 creates slow code and gcc-4.5 fast code. At > -O2, both are equally fast. The clang 1.1 code at -O2 is as fast as GCC 4.5's > code at -O3. Using gcc 4.5 with -O3 may work for the C code, but it does not optimize the C++ code posted at http://lwn.net/Articles/411776/: g++-4.5 -O3: real 0m1.608s clang++ -O2: real 0m0.003s clang++ -Os: real 0m0.003s But I guess the C++ problem might be a different one.
[Bug c/46186] Clang creates code running 1600 times faster than gcc's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186 --- Comment #8 from Julian Andres Klode 2010-10-26 15:25:56 UTC --- (In reply to comment #6) > You get this kind of speedup if the compiler knows that the result of the loop > is > > sum=(b*(b-1)-a*(a-1))/2 > > In which case the timing is meaningless (it is 0.000s on my laptop), so is the > ratio with the execution of the loop. > > The basic question is: how much the user's ignorance should be repaired by the > optimizer? (A colleague of mine told me that he once audited a CFD code and > found that \int_a^b dx/x was evaluated numerically instead of using > log(b)-log(a)!-) Since the optimization seems to be mostly there in -O3, it's just a matter of enabling it in -O2. I just found out that it does not optimize if you call f() via a global function pointer, it still takes 1.6 seconds despite being compiled at -O3, whereas clang can optimize it to 0.001s.
