[Bug c/83139] error: null destination pointer [-Werror=format-truncation=] for second call with same destination pointer

2017-11-24 Thread j...@jak-linux.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83139 --- Comment #2 from Julian Andres Klode <j...@jak-linux.org> --- 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 i

[Bug c/83139] error: null destination pointer [-Werror=format-truncation=] for second call with same destination pointer

2017-11-24 Thread j...@jak-linux.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83139 --- Comment #1 from Julian Andres Klode <j...@jak-linux.org> --- Created attachment 42702 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42702=edit generated .i file

[Bug c/83139] New: error: null destination pointer [-Werror=format-truncation=] for second call with same destination pointer

2017-11-24 Thread j...@jak-linux.org
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=42

[Bug target/81501] Unneccessary calls to __tls_get_addr() in simple thread-singleton pattern

2017-07-20 Thread j...@jak-linux.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81501 --- Comment #1 from Julian Andres Klode <j...@jak-linux.org> --- 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 1000

[Bug target/81501] New: Unneccessary calls to __tls_get_addr() in simple thread-singleton pattern

2017-07-20 Thread j...@jak-linux.org
: 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

[Bug c++/81408] Lots of new -Wunsafe-loop-optimizations warnings with 7 compared to 6

2017-07-12 Thread j...@jak-linux.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81408 --- Comment #4 from Julian Andres Klode <j...@jak-linux.org> --- 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++/81408] Lots of new -Wunsafe-loop-optimizations warnings with 7 compared to 6

2017-07-12 Thread j...@jak-linux.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81408 --- Comment #3 from Julian Andres Klode <j...@jak-linux.org> --- 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

2017-07-12 Thread j...@jak-linux.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81408 --- Comment #2 from Julian Andres Klode <j...@jak-linux.org> --- 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:

[Bug c++/81408] Lots of new -Wunsafe-loop-optimizations warnings with 7 compared to 6

2017-07-12 Thread j...@jak-linux.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81408 --- Comment #1 from Julian Andres Klode <j...@jak-linux.org> --- Created attachment 41727 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41727=edit preprocessed source of a.cc

[Bug c++/81408] New: Lots of new -Wunsafe-loop-optimizations warnings with 7 compared to 6

2017-07-12 Thread j...@jak-linux.org
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=edit Minimized example Compiling a recent apt wit

[Bug c++/79476] New: C++ frontend ignores diagnostic pragma in macro

2017-02-12 Thread j...@jak-linux.org
: 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=edit Reproducer We define three macros in APT: #define APT_IGNORE_DEPRECATED_P

[Bug target/77729] aarch64 inserts unneeded uxtb after ldrb, orr ...32

2016-09-25 Thread j...@jak-linux.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77729 --- Comment #9 from Julian Andres Klode <j...@jak-linux.org> --- (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

[Bug target/77729] aarch64 inserts unneeded uxtb after ldrb, orr ...32

2016-09-25 Thread j...@jak-linux.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77729 --- Comment #6 from Julian Andres Klode <j...@jak-linux.org> --- (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 defau

[Bug target/77729] aarch64 inserts unneeded uxtb after ldrb, orr ...32

2016-09-25 Thread j...@jak-linux.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77729 --- Comment #5 from Julian Andres Klode <j...@jak-linux.org> --- Created attachment 39678 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39678=edit ppc64le Hmm, AFAICT the same seems to happen on powerpc64le:

[Bug target/77729] aarch64 inserts unneeded uxtb after ldrb, orr ...32

2016-09-25 Thread j...@jak-linux.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77729 --- Comment #3 from Julian Andres Klode <j...@jak-linux.org> --- Created attachment 39677 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39677=edit arm (thumb2) output at -O2

[Bug target/77729] aarch64 inserts unneeded uxtb after ldrb, orr ...32

2016-09-25 Thread j...@jak-linux.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77729 --- Comment #2 from Julian Andres Klode <j...@jak-linux.org> --- Created attachment 39676 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39676=edit Aarch64 output at -O2

[Bug target/77729] aarch64 inserts unneeded uxtb after ldrb, orr ...32

2016-09-25 Thread j...@jak-linux.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77729 --- Comment #1 from Julian Andres Klode <j...@jak-linux.org> --- Created attachment 39675 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39675=edit C reproducer

[Bug target/77729] New: aarch64 inserts unneeded uxtb after ldrb, orr ...32

2016-09-25 Thread j...@jak-linux.org
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

[Bug libstdc++/71556] set::get_time() requires leading 0s for %H and friends

2016-06-16 Thread j...@jak-linux.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71556 --- Comment #1 from Julian Andres Klode <j...@jak-linux.org> --- 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 libstdc++/71556] New: set::get_time() requires leading 0s for %H and friends

2016-06-16 Thread j...@jak-linux.org
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=edit C++ reproducer In contrast to strptime(), std::get_time() requires lead

[Bug c/46186] New: Clang creates code running 1600 times faster than gcc's

2010-10-26 Thread j...@jak-linux.org
: 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

[Bug c/46186] Clang creates code running 1600 times faster than gcc's

2010-10-26 Thread j...@jak-linux.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186 --- Comment #1 from Julian Andres Klode j...@jak-linux.org 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

[Bug c/46186] Clang creates code running 1600 times faster than gcc's

2010-10-26 Thread j...@jak-linux.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186 --- Comment #3 from Julian Andres Klode j...@jak-linux.org 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

[Bug c/46186] Clang creates code running 1600 times faster than gcc's

2010-10-26 Thread j...@jak-linux.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186 --- Comment #5 from Julian Andres Klode j...@jak-linux.org 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

[Bug c/46186] Clang creates code running 1600 times faster than gcc's

2010-10-26 Thread j...@jak-linux.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186 --- Comment #7 from Julian Andres Klode j...@jak-linux.org 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

[Bug c/46186] Clang creates code running 1600 times faster than gcc's

2010-10-26 Thread j...@jak-linux.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186 --- Comment #8 from Julian Andres Klode j...@jak-linux.org 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