[Bug other/94629] 10 issues located by the PVS-studio static analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94629 --- Comment #24 from Leo Yuriev --- So, seems that all done and this issue should be closed?
[Bug other/94629] 10 issues located by the PVS-studio static analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94629 --- Comment #19 from Leo Yuriev --- (In reply to CVS Commits from comment #4) > The master branch has been updated by Richard Biener : > > https://gcc.gnu.org/g:a64468a3034dd8e2d0794a5be84b8da544ffe2c3 > > commit r10-7770-ga64468a3034dd8e2d0794a5be84b8da544ffe2c3 > Author: Richard Biener > Date: Fri Apr 17 09:19:32 2020 +0200 > > fix PVS studio reported bugs > > 2020-04-17 Richard Biener [...] > * dwarf2out.c (dw_val_equal_p): Fix pasto in > dw_val_class_vms_delta comparison. > * optabs.c (expand_binop_directly): Fix pasto in commutation [...] Seems the https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80051 should be closed as fixed.
[Bug other/94629] New: 10 issues located by the PVS-studio static analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94629 Bug ID: 94629 Summary: 10 issues located by the PVS-studio static analyzer Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: leo at yuriev dot ru Target Milestone: --- Today Andrey Karpov published a short article with the latest results of checking GCC source code using the PVS-Studio static analyzer. Andrey writes that he received a lot of warnings and presumably a significant part of them are false-positive. However, for this article, he chose and showed 10 very suspicious cases. I am convinced that this is worth a close look. There are clearly errors that are extremely difficult to notice with an eyes. https://habr.com/en/company/pvs-studio/blog/497640/ Regards, Leonid
[Bug target/93243] misoptimization: minor changes of the code leads change up to +/- 30% performance on x86_64, -Os faster than -Ofast/O2/O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93243 --- Comment #5 from Leo Yuriev --- Created attachment 47658 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47658=edit testcase makefile
[Bug target/93243] misoptimization: minor changes of the code leads change up to +/- 30% performance on x86_64, -Os faster than -Ofast/O2/O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93243 --- Comment #4 from Leo Yuriev --- Created attachment 47657 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47657=edit testcase source code
[Bug target/93243] misoptimization: minor changes of the code leads change up to +/- 30% performance on x86_64, -Os faster than -Ofast/O2/O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93243 --- Comment #3 from Leo Yuriev --- > (a) < (b) is not equal to ((a) - (b) < 0) > Compiler will trait them differently. Yes, of course. Moreover, in the second case, correct sorting requires limiting the range of keys to avoid overflow when comparing by subtraction. However, such changes in the code shouldn't cause such a significant performance change. Moreover, this can't be an excuse for generating slower code compared to clang. For clarity: - We look to the benchmark of heapsort, with random data, in the two cases: `small` and `large`. - GCC shown unexpected performance changes by minor code changes. - CLANG shown stable result and better perfomance than GCC's in all cases. - moreover, GCC shown better performance with -Os rather with -Ofast. So, seems this is a misoptimization bug.
[Bug tree-optimization/93243] misoptimization: minor changes of the code leads change up to +/- 30% performance on x86_64, -Os faster than -Ofast/O2/O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93243 Leo Yuriev changed: What|Removed |Added Keywords|missed-optimization | Target|x86_64 | Component|target |tree-optimization --- Comment #1 from Leo Yuriev --- Minor additions: - benchmarks results above made with -Ofast. - one of gcc 9.x -Os result is below. ./heapsort-bench, cc 9.2.1 20191008 pass 1, small: 0.805970 seconds, baseline 0.799507 seconds, case-1, 99.2% of baseline 0.784975 seconds, case-2, 97.4% of baseline 0.789067 seconds, case-1+2, 97.9% of baseline pass 1, large: 2.859491 seconds, baseline 2.779411 seconds, case-1, 97.2% of baseline 2.782386 seconds, case-2, 97.3% of baseline 2.743033 seconds, case-1+2, 95.9% of baseline I.e. gcc 9.2.x with -Os faster then -Ofast.
[Bug tree-optimization/93243] New: misoptimization: minor changes of the code leads change up to +/- 30% performance on x86_64, -Os faster than -Ofast/O2/O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93243
Bug ID: 93243
Summary: misoptimization: minor changes of the code leads
change up to +/- 30% performance on x86_64, -Os faster
than -Ofast/O2/O3
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: leo at yuriev dot ru
Target Milestone: ---
Briefly:
./heapsort-bench, cc 9.2.1 20191008
pass 1, small:
1.138047 seconds, baseline
1.090476 seconds, case-1, 95.8% of baseline
0.957207 seconds, case-2, 84.1% of baseline
1.163323 seconds, case-1+2, 102.2% of baseline
pass 1, large:
2.766881 seconds, baseline
2.677642 seconds, case-1, 96.8% of baseline
3.230149 seconds, case-2, 116.7% of baseline
2.758408 seconds, case-1+2, 99.7% of baseline
./heapsort-bench, cc Clang 9.0.0 (tags/RELEASE_900/final)
pass 1, small:
1.048489 seconds, baseline
1.050220 seconds, case-1, 100.2% of baseline
1.056953 seconds, case-2, 100.8% of baseline
1.050501 seconds, case-1+2, 100.2% of baseline
pass 1, large:
2.588565 seconds, baseline
2.585488 seconds, case-1, 99.9% of baseline
2.610508 seconds, case-2, 100.8% of baseline
2.587282 seconds, case-1+2, 100.0% of baseline
./heapsort-bench, gcc 7.4.0 (ubuntu)
pass 1, small:
0.893917 seconds, baseline
1.135796 seconds, case-1, 127.1% of baseline
0.920338 seconds, case-2, 103.0% of baseline
1.140505 seconds, case-1+2, 127.6% of baseline
pass 1, large:
3.804271 seconds, baseline
2.955773 seconds, case-1, 77.7% of baseline
3.908621 seconds, case-2, 102.7% of baseline
2.925845 seconds, case-1+2, 76.9% of baseline
The diffs in the source code are:
#if CASE & 1
#define CMP(a, b) ((a) < (b))
#else
#define CMP(a, b) (((a) - (b)) < 0)
#endiF
#if CASE & 2
for (size_t root = from; (root + root) <= to;) {
size_t child = root << 1;
#else
for (size_t child, root = from; (child = root + root) <= to;) {
#endif
gcc 9.x and clang 9.x shows (nearly) the same results on Fedora 31 and Ubunto
19.10.
gcc 7.4 probed only on ubuntu, moreover clang 6.0 shown stable results like
clang 9.
Source code of testcase at https://github.com/leo-yuriev/gcc-issues
$ wc heapsort.c
165 528 4309 heapsort.c
Using PGO (included in the testcase) does not significantly change the result.
Basically these words is seems enough, but more ones I will add tomorrow
(likely after afternoon UTC+03).
Regards,
Leonid.
[Bug web/68660] New: "5.2" instead of "5.3" on the main page at https://gcc.gnu.org/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68660
Bug ID: 68660
Summary: "5.2" instead of "5.3" on the main page at
https://gcc.gnu.org/
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: web
Assignee: unassigned at gcc dot gnu.org
Reporter: leo at yuriev dot ru
Target Milestone: ---
"Release Series and Status" on the top of https://gcc.gnu.org/
- now see "GCC 5.2 (changes)"
- but should be "GCC 5.3 (changes)"
[Bug web/68660] "5.2" instead of "5.3" on the main page at https://gcc.gnu.org/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68660 --- Comment #2 from Leo Yuriev --- Hm, it is a devel-status of 5.3, not 5.2
[Bug middle-end/55929] New: lra-constraints-ICE while xg++ compile libitm with -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55929
Bug #: 55929
Summary: lra-constraints-ICE while xg++ compile libitm with -Os
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: l...@yuriev.ru
libtool: compile: /sandbox/stage1/gcc/./gcc/xg++ -B/sandbox/stage1/gcc/./gcc/
-nostdinc++ -nostdinc++
-I/sandbox/stage1/gcc/x86_64-linux-gnu/libstdc++-v3/include/x86_64-linux-gnu
-I/sandbox/stage1/gcc/x86_64-linux-gnu/libstdc++-v3/include
-I/sandbox/gcc-git/libstdc++-v3/libsupc++
-I/sandbox/gcc-git/libstdc++-v3/include/backward
-I/sandbox/gcc-git/libstdc++-v3/testsuite/util
-L/sandbox/stage1/gcc/x86_64-linux-gnu/libstdc++-v3/src
-L/sandbox/stage1/gcc/x86_64-linux-gnu/libstdc++-v3/src/.libs
-B/sandbox/stage1/x86_64-linux-gnu/bin/ -B/sandbox/stage1/x86_64-linux-gnu/lib/
-isystem /sandbox/stage1/x86_64-linux-gnu/include -isystem
/sandbox/stage1/x86_64-linux-gnu/sys-include -DHAVE_CONFIG_H -I.
-I/sandbox/gcc-git/libitm -I/sandbox/gcc-git/libitm/config/linux/x86
-I/sandbox/gcc-git/libitm/config/linux -I/sandbox/gcc-git/libitm/config/x86
-I/sandbox/gcc-git/libitm/config/posix -I/sandbox/gcc-git/libitm/config/generic
-I/sandbox/gcc-git/libitm -mrtm -Wall -pthread -Werror -std=gnu++0x
-funwind-tables -fno-exceptions -fno-rtti -fabi-version=4 -Os -Wno-error -g0
-D_GNU_SOURCE -c /sandbox/gcc-git/libitm/beginend.cc -fPIC -DPIC -o beginend.o
/sandbox/gcc-git/libitm/beginend.cc: In static member function 'static uint32_t
GTM::gtm_thread::begin_transaction(uint32_t, const gtm_jmpbuf*)':
/sandbox/gcc-git/libitm/beginend.cc:346:1: error: unable to generate reloads
for:
}
^
(jump_insn 43 42 44 8 (parallel [
(set (pc)
(if_then_else (ne (unspec [
(const_int 0 [0])
] UNSPEC_XBEGIN_ABORT)
(const_int 0 [0]))
(label_ref 44)
(pc)))
(set (reg:SI 116)
(unspec_volatile:SI [
(reg:SI 116)
] UNSPECV_XBEGIN))
]) /sandbox/stage1/gcc/gcc/include/rtmintrin.h:50 1024 {xbegin_1}
(nil)
- 44)
/sandbox/gcc-git/libitm/beginend.cc:346:1: internal compiler error: in
curr_insn_transform, at lra-constraints.c:2754
[Bug other/55930] New: libatomic build failure if configured with --disable-dependency-tracking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55930 Bug #: 55930 Summary: libatomic build failure if configured with --disable-dependency-tracking Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: l...@yuriev.ru with --disable-dependency-tracking the .deps directory not created, but a *.Ppo files still generated. libtool: compile: /sandbox/stage1/gcc/./gcc/xgcc -B/sandbox/stage1/gcc/./gcc/ -B/sandbox/stage1/x86_64-linux-gnu/bin/ -B/sandbox/stage1/x86_64-linux-gnu/lib/ -isystem /sandbox/stage1/x86_64-linux-gnu/include -isystem /sandbox/stage1/x86_64-linux-gnu/sys-include -DHAVE_CONFIG_H -I/sandbox/gcc-git/libatomic/config/x86 -I/sandbox/gcc-git/libatomic/config/posix -I/sandbox/gcc-git/libatomic -I. -Wall -Werror -pthread -g -O2 -Wno-error -g0 -MT load_1_.lo -MD -MP -MF .deps/load_1_.lo.Ppo -DN=1 -c /sandbox/gcc-git/libatomic/load_n.c -fPIC -DPIC -o load_1_.o /sandbox/gcc-git/libatomic/load_n.c:115:1: fatal error: opening dependency file .deps/load_1_.lo.Ppo: No such file or directory EXPORT_ALIAS (SIZE(load)); ^
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
Leo Yuriev leo at yuriev dot ru changed:
What|Removed |Added
CC||leo at yuriev dot ru
--- Comment #164 from Leo Yuriev leo at yuriev dot ru 2013-01-06 00:31:55 UTC
---
Some trouble while building LLVM with -flto.
../x86_64-linux-gnu/bin/ld.gold: error: /tmp/cc60XH2F.ltrans0.ltrans.o:
requires dynamic R_X86_64_PC32 reloc against 'X86CompilationCallback2' which
may overflow at runtime; recompile with -fPIC
Code:
extern C {
void X86CompilationCallback(void);
asm(
.text\n
.align 8\n
.globl ASMPREFIX X86CompilationCallback\n
TYPE_FUNCTION(X86CompilationCallback)
ASMPREFIX X86CompilationCallback:\n
...
movq8(%rbp), %rdx\n
call ASMPREFIX X86CompilationCallback2\n
addq$32, %rsp\n
...
);
}
void __attribute__((used))
X86CompilationCallback2(intptr_t *StackPtr, intptr_t RetAddr) {
intptr_t *RetAddrLoc = StackPtr[1];
...
}
}
[Bug c++/54277] Template class member referred to with implicit this inside lambda is incorrectly const-qualified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54277 Leo Yuriev leo at yuriev dot ru changed: What|Removed |Added CC||leo at yuriev dot ru --- Comment #2 from Leo Yuriev leo at yuriev dot ru 2012-08-29 14:54:15 UTC --- +1, just confirm
[Bug middle-end/31192] New: functions with __attribute__((externelly_visible)) becomes static when -O -fwhole-program
Problem could be easy reproduced by gcc412 -O1 -fwhole-program -S gcc-4.1.2/gcc/testsuite/gcc.gd/tree-ssa/wholeprogram-2.c. The output file wholeprogram-2.s contains: .file wholeprogram-2.c .text .type externally_visible_function, @function externally_visible_function: pushl %ebp movl%esp, %ebp popl%ebp ret .size externally_visible_function, .-externally_visible_function .ident GCC: (GNU) 4.1.2 .section.note.GNU-stack,,@progbits Can see the line .globl externally_visible_function is absent, so externally_visible_function() become local, but not public. It is may be other solution, but my patch is really simple: diff -Nrcpad gcc-4.1.2-ori/gcc/cgraphunit.c gcc-4.1.2/gcc/cgraphunit.c *** gcc-4.1.2-ori/gcc/cgraphunit.c Fri Jan 5 22:44:10 2007 --- gcc-4.1.2/gcc/cgraphunit.c Fri Mar 16 01:11:24 2007 *** process_function_and_variable_attributes *** 937,942 --- 937,943 if (node-local.finalized) cgraph_mark_needed_node (node); node-externally_visible = true; + node-local.externally_visible = true; } } for (vnode = cgraph_varpool_nodes; vnode != first_var; vnode = vnode-next) -- Summary: functions with __attribute__((externelly_visible)) becomes static when -O -fwhole-program Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: leo at yuriev dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31192
