[Bug c++/110186] -Weffc++ does not recognize user defined constructor.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110186 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- -Weffc++ has not been updated for C++11 and it will not be updated for it. It was specific warnings from "Scott Meyers’ Effective C++" book which was created before C++11 was thought of.
[Bug c++/110186] New: -Weffc++ does not recognize user defined constructor.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110186
Bug ID: 110186
Summary: -Weffc++ does not recognize user defined constructor.
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: amir.ahmed.ansari at outlook dot com
Target Milestone: ---
Created attachment 55292
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55292=edit
Code to replicate the problem
Compile the attached code with the following flags:
-std=c++17 -Wall -pedantic -Wextra -Weffc++ -O3 -flto
The following output is generated:
: In constructor 'C::C()':
:23:1: warning: 'C::a' should be initialized in the member
initialization list [-Weffc++]
23 | C::C() = default;
| ^
: In constructor 'D::D()':
:28:5: warning: 'D::a' should be initialized in the member
initialization list [-Weffc++]
28 | D() {}
| ^
The compiler fails to consider B() = default; as a user defined default
constructor and does not generate the warning to initialize a in the member
initialization list.
[Bug target/110170] Sub-optimal conditional jumps in conditional-swap with floating point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110170 --- Comment #5 from Hongtao.liu --- (In reply to Antony Polukhin from comment #2) > -fno-trapping-math had no effect > > Some tests with nans seem to produce the same results for both code > snippets: https://godbolt.org/z/GaKM3EhMq What about infinity, I notice With -ffinite-math-only -funsafe-math-optimizations, gcc now can generate __cond_swap(double*, double*): movsd (%rdi), %xmm0 movsd (%rsi), %xmm1 movapd %xmm0, %xmm2 minsd %xmm1, %xmm0 maxsd %xmm1, %xmm2 movsd %xmm2, (%rsi) movsd %xmm0, (%rdi) ret
[Bug c++/110175] [GCC][Crash] GCC Crash on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110175 --- Comment #2 from Yrong --- Thanks!
[Bug target/110108] [14 Regression] Wrong code from combining VPABSB/VPBLENDVB since g:1ede03e2d0437ea9c2f7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110108 --- Comment #8 from Hongtao.liu --- Fixed for trunk.
[Bug libstdc++/59974] ostream crashes on large numbers under Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59974 jon_y <10walls at gmail dot com> changed: What|Removed |Added CC||10walls at gmail dot com --- Comment #4 from jon_y <10walls at gmail dot com> --- Created attachment 55291 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55291=edit Rebased to the latest gcc git Attached the rebased patch.
[Bug target/110108] [14 Regression] Wrong code from combining VPABSB/VPBLENDVB since g:1ede03e2d0437ea9c2f7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110108 --- Comment #7 from CVS Commits --- The releases/gcc-12 branch has been updated by hongtao Liu : https://gcc.gnu.org/g:887f903ab05ddcac498247384734efbc6cf45147 commit r12-9686-g887f903ab05ddcac498247384734efbc6cf45147 Author: liuhongt Date: Mon Jun 5 12:38:41 2023 +0800 Explicitly view_convert_expr mask to signed type when folding pblendvb builtins. Since mask < 0 will be always false for vector char when -funsigned-char, but vpblendvb needs to check the most significant bit. The patch explicitly VCE to vector signed char. gcc/ChangeLog: PR target/110108 * config/i386/i386.cc (ix86_gimple_fold_builtin): Explicitly view_convert_expr mask to signed type when folding pblendvb builtins. gcc/testsuite/ChangeLog: * gcc.target/i386/pr110108-2.c: New test.
[Bug target/110108] [14 Regression] Wrong code from combining VPABSB/VPBLENDVB since g:1ede03e2d0437ea9c2f7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110108 --- Comment #6 from CVS Commits --- The releases/gcc-13 branch has been updated by hongtao Liu : https://gcc.gnu.org/g:5e01a590aa719d235811c1549547f736de2b5190 commit r13-7430-g5e01a590aa719d235811c1549547f736de2b5190 Author: liuhongt Date: Mon Jun 5 12:38:41 2023 +0800 Explicitly view_convert_expr mask to signed type when folding pblendvb builtins. Since mask < 0 will be always false for vector char when -funsigned-char, but vpblendvb needs to check the most significant bit. The patch explicitly VCE to vector signed char. gcc/ChangeLog: PR target/110108 * config/i386/i386.cc (ix86_gimple_fold_builtin): Explicitly view_convert_expr mask to signed type when folding pblendvb builtins. gcc/testsuite/ChangeLog: * gcc.target/i386/pr110108-2.c: New test.
[Bug target/110108] [14 Regression] Wrong code from combining VPABSB/VPBLENDVB since g:1ede03e2d0437ea9c2f7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110108
--- Comment #4 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:07b86ab138bf8be8cb331015cd2b9775c6856ac6
commit r14-1640-g07b86ab138bf8be8cb331015cd2b9775c6856ac6
Author: liuhongt
Date: Mon Jun 5 11:59:33 2023 +0800
Fold _mm{,256,512}_abs_{epi8,epi16,epi32,epi64} into gimple ABSU_EXPR +
VCE.
r14-1145 fold the intrinsics into gimple ABS_EXPR which has UB for
TYPE_MIN, but PABSB will store unsigned result into dst. The patch
uses ABSU_EXPR + VCE instead of ABS_EXPR.
Also don't fold _mm_abs_{pi8,pi16,pi32} w/o TARGET_64BIT since 64-bit
vector absm2 is guarded with TARGET_MMX_WITH_SSE.
gcc/ChangeLog:
PR target/110108
* config/i386/i386.cc (ix86_gimple_fold_builtin): Fold
_mm{,256,512}_abs_{epi8,epi16,epi32,epi64} into gimple
ABSU_EXPR + VCE, don't fold _mm_abs_{pi8,pi16,pi32} w/o
TARGET_64BIT.
* config/i386/i386-builtin.def: Replace CODE_FOR_nothing with
real codename for __builtin_ia32_pabs{b,w,d}.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr110108.c: New test.
* gcc.target/i386/pr110108-3.c: New test.
* gcc.target/i386/pr109900.c: Adjust testcase.
[Bug target/110108] [14 Regression] Wrong code from combining VPABSB/VPBLENDVB since g:1ede03e2d0437ea9c2f7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110108 --- Comment #5 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:dac73e4c64bf62be18bd5203e4e0f3e6bc64b4dc commit r14-1641-gdac73e4c64bf62be18bd5203e4e0f3e6bc64b4dc Author: liuhongt Date: Mon Jun 5 12:38:41 2023 +0800 Explicitly view_convert_expr mask to signed type when folding pblendvb builtins. Since mask < 0 will be always false for vector char when -funsigned-char, but vpblendvb needs to check the most significant bit. The patch explicitly VCE to vector signed char. gcc/ChangeLog: PR target/110108 * config/i386/i386.cc (ix86_gimple_fold_builtin): Explicitly view_convert_expr mask to signed type when folding pblendvb builtins. gcc/testsuite/ChangeLog: * gcc.target/i386/pr110108-2.c: New test.
[Bug c++/110185] [14 Regression]: Tens of c++ testsuite crashes for cris-elf with r14-1624-g28db36e2cfca1b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110185 --- Comment #1 from Hans-Peter Nilsson --- Created attachment 55290 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55290=edit spaceship-synth13.ii Hm, that attachment was for a test that checked for errors. Here's one for a tests that should compile without errors, /testsuite/g++.dg/cpp2a/spaceship-synth13.C. Repeat with cc1plus -fpreprocessed spaceship-synth13.ii -melf -quiet -dumpbase spaceship-synth13.C -dumpbase-ext .C -pedantic-errors -Wno-long-long -std=c++20 -version -fdiagnostics-color=never -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-urls=never -fdiagnostics-path-format=separate-events -fmessage-length=0 -o spaceship-synth13.s
[Bug c++/110185] New: [14 Regression]: Tens of c++ testsuite crashes for cris-elf with r14-1624-g28db36e2cfca1b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110185 Bug ID: 110185 Summary: [14 Regression]: Tens of c++ testsuite crashes for cris-elf with r14-1624-g28db36e2cfca1b Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hp at gcc dot gnu.org CC: jason at redhat dot com Target Milestone: --- Host: x86_64-pc-linux-gnu Target: cris-elf Created attachment 55289 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55289=edit spaceship-p1186.ii With r14-1624-g28db36e2cfca1b, for cris-elf cross from x86_64-linux, I get tens of regressions: --- regress.prev2023-06-08 03:27:56.0 +0200 +++ regress 2023-06-08 08:50:14.425080243 +0200 @@ -0,0 +1,20 @@ +g++.sum g++.dg/cpp2a/spaceship-p1186.C +g++.sum g++.dg/cpp2a/spaceship-synth1.C +g++.sum g++.dg/cpp2a/spaceship-synth10.C +g++.sum g++.dg/cpp2a/spaceship-synth12.C +g++.sum g++.dg/cpp2a/spaceship-synth13.C +g++.sum g++.dg/cpp2a/spaceship-synth14.C +g++.sum g++.dg/cpp2a/spaceship-synth1a.C +g++.sum g++.dg/cpp2a/spaceship-synth2.C +g++.sum g++.dg/cpp2a/spaceship-synth2a.C +g++.sum g++.dg/cpp2a/spaceship-synth2b.C +g++.sum g++.dg/cpp2a/spaceship-synth4.C +g++.sum g++.dg/cpp2a/spaceship-synth5.C +g++.sum g++.dg/cpp2a/spaceship-weak1.C +libstdc++.sum 25_algorithms/minmax/constrained.cc +libstdc++.sum std/time/month_day/1.cc +libstdc++.sum std/time/month_day_last/1.cc +libstdc++.sum std/time/year_month/1.cc +libstdc++.sum std/time/year_month_day/1.cc +libstdc++.sum std/time/year_month_day/4.cc +libstdc++.sum std/time/year_month_day_last/1.cc Checking the .log files, all seem to be similar crashes. Here's the important bits for spaceship-p1186.C: spawn -ignore SIGHUP /x/gccobj/gcc/testsuite/g++/../../xg++ -B/x/gccobj/gcc/testsuite/g++/../../ /x/gcc/gcc/testsuite/g\ ++.dg/cpp2a/spaceship-p1186.C -fdiagnostics-plain-output -nostdinc++ -I/x/gccobj/cris-elf/libstdc++-v3/include/cris-elf\ -I/x/gccobj/cris-elf/libstdc++-v3/include -I/x/gcc/libstdc++-v3/libsupc++ -I/x/gcc/libstdc++-v3/include/backward -I/x/\ gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++20 -pedantic-errors -Wno-long-long -S -isystem /x/gccobj/cri\ s-elf/./newlib/targ-include -isystem /x/gcc/newlib/libc/include -o spaceship-p1186.s /x/gcc/gcc/testsuite/g++.dg/cpp2a/spaceship-p1186.C: In function 'void foo(A&, A&, B&, B&, D&, D&, F&, F&, I&, I&)': /x/gcc/gcc/testsuite/g++.dg/cpp2a/spaceship-p1186.C:91:17: error: use of deleted function 'constexpr auto A::operator<=\ >(const A&) const' /x/gcc/gcc/testsuite/g++.dg/cpp2a/spaceship-p1186.C:17:8: note: 'constexpr auto A::operator<=>(const A&) const' is impl\ icitly deleted because the default definition would be ill-formed: /x/gcc/gcc/testsuite/g++.dg/cpp2a/spaceship-p1186.C:16:5: error: no match for 'operator<=>' in '((const A*)this)->A::h \ <=> .A::h' (operand types are 'H' and 'H') /x/gcc/gcc/testsuite/g++.dg/cpp2a/spaceship-p1186.C:84:23: note: candidate: 'template std::partial_ordering op\ erator<=>(const N&, T&&)' (reversed) /x/gcc/gcc/testsuite/g++.dg/cpp2a/spaceship-p1186.C:84:23: note: template argument deduction/substitution failed: /x/gcc/gcc/testsuite/g++.dg/cpp2a/spaceship-p1186.C:16:5: note: cannot convert '.A::h' (type 'H') to type \ 'const N&' /x/gcc/gcc/testsuite/g++.dg/cpp2a/spaceship-p1186.C:86:23: note: candidate: 'template std::partial_ordering op\ erator<=>(T&&, const N&)' (reversed) /x/gcc/gcc/testsuite/g++.dg/cpp2a/spaceship-p1186.C:86:23: note: template argument deduction/substitution failed: /x/gcc/gcc/testsuite/g++.dg/cpp2a/spaceship-p1186.C:16:5: note: cannot convert '((const A*)this)->A::h' (type 'H') to\ type 'const N&' /x/gcc/gcc/testsuite/g++.dg/cpp2a/spaceship-p1186.C:17:8: note: changing the return type from 'auto' to a comparison ca\ tegory type will allow the comparison to use 'operator<' and 'operator==' /x/gcc/gcc/testsuite/g++.dg/cpp2a/spaceship-p1186.C: In member function 'constexpr std::strong_ordering B::operator<=>(\ const B&) const': /x/gcc/gcc/testsuite/g++.dg/cpp2a/spaceship-p1186.C:25:24: internal compiler error: Segmentation fault 0x10e034f crash_signal /x/gcc/gcc/toplev.cc:314 0x7ff4199b1d5f ??? ./signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 0xa0f1de tree_check(tree_node*, char const*, int, char const*, tree_code) /x/gcc/gcc/tree.h:3569 0xa0f1de outer_binding(tree_node*, cxx_binding*, bool) /x/gcc/gcc/cp/name-lookup.cc:7394 0xa0f31a decl_in_scope_p(tree_node*) /x/gcc/gcc/cp/name-lookup.cc:7465 0xb3ca65 check_return_expr(tree_node*, bool*) /x/gcc/gcc/cp/typeck.cc:11177 0xae7baf finish_return_stmt(tree_node*) /x/gcc/gcc/cp/semantics.cc:1244 0x9c96f1 build_comparison_op(tree_node*, bool, int)
[Bug modula2/110126] Variables are reported as unused when only referenced by ASM statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110126 Gaius Mulley changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Gaius Mulley --- Closing now patch has been applied - thanks for the report!
[Bug modula2/110126] Variables are reported as unused when only referenced by ASM statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110126 --- Comment #5 from CVS Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:990d10ab23360fef8b5eb6937ac10b4f67f46e2d commit r14-1638-g990d10ab23360fef8b5eb6937ac10b4f67f46e2d Author: Gaius Mulley Date: Fri Jun 9 00:55:50 2023 +0100 PR modula2/110126 variables are reported as unused when referenced by ASM This patches fixes two problems with the asm statement. gm2 -Wall -c fooasm3.mod generates an incorrect warning and gm2 cannot concatenate strings before an ASM statement. The asm statement now accepts a constant expression (rather than a string) and it updates the variable read/write use lists as appropriate. gcc/m2/ChangeLog: PR modula2/110126 * gm2-compiler/M2GenGCC.mod (BuildTreeFromInterface): Remove tokenno parameter. Use object tok instead of tokenno. (BuildTrashTreeFromInterface): Use object tok instead of GetDeclaredMod. (CodeInline): Remove tokenno from parameter list to BuildTreeFromInterface. * gm2-compiler/M2Quads.def (BuildAsmElement): Exported and defined. * gm2-compiler/M2Quads.mod (BuildOptimizeOff): Reformatted. (BuildInline): Reformatted. (BuildLineNo): Reformatted. (UseLineNote): Reformatted. (BuildAsmElement): New procedure. * gm2-compiler/P0SyntaxCheck.bnf (AsmOperands): Use ConstExpression instead of string. (AsmElement): Use ConstExpression instead of string. (TrashList): Use ConstExpression instead of string. * gm2-compiler/P1Build.bnf (AsmOperands): Use ConstExpression instead of string. (AsmElement): Use ConstExpression instead of string. (TrashList): Use ConstExpression instead of string. * gm2-compiler/P2Build.bnf (AsmOperands): Use ConstExpression instead of string. (AsmElement): Use ConstExpression instead of string. (TrashList): Use ConstExpression instead of string. * gm2-compiler/P3Build.bnf (AsmOperands): Rewrite. (AsmOperandSpec): Rewrite. (AsmOutputList): New rule. (AsmInputList): New rule. (TrashList): Rewrite. * gm2-compiler/PCBuild.bnf (AsmOperands): Use ConstExpression instead of string. (AsmElement): Use ConstExpression instead of string. (TrashList): Use ConstExpression instead of string. * gm2-compiler/PHBuild.bnf (AsmOperands): Use ConstExpression instead of string. (AsmElement): Use ConstExpression instead of string. (TrashList): Use ConstExpression instead of string. * gm2-compiler/SymbolTable.def (PutRegInterface): Rewrite interface. (GetRegInterface): Rewrite interface. * gm2-compiler/SymbolTable.mod (SetFirstUsed): New procedure. (PutFirstUsed): New procedure. (PutRegInterface): Rewrite. (GetRegInterface): Rewrite. gcc/testsuite/ChangeLog: PR modula2/110126 * gm2/pim/pass/fooasm3.mod: New test. Signed-off-by: Gaius Mulley
[Bug target/110184] [x86] Missed optimisation: atomic operations should use PF, ZF and SF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110184 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug target/110184] [i386] Missed optimisation: atomic operations should use PF, ZF and SF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110184 --- Comment #1 from Andrew Pinski --- Created attachment 55288 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55288=edit Full testcase
[Bug analyzer/110112] [11/12/13 Regression] gcc -fanalyzer takes an excessive amount of time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110112 David Malcolm changed: What|Removed |Added Last reconfirmed||2023-06-08 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #3 from David Malcolm --- Thanks. I was seeing: real 1m31.214s Adding a cache to region_model::get_initial_value_for_global speeds things up greatly to: real 0m3.677s Adding a further cache to decl_region::get_svalue_for_constructor gives a further slight speedup to: real 0m3.069s I'm working on a fix based on the above.
[Bug target/110184] New: [i386] Missed optimisation: atomic operations should use PF, ZF and SF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110184
Bug ID: 110184
Summary: [i386] Missed optimisation: atomic operations should
use PF, ZF and SF
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
Follow up from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566
The x86 locked ALU operations always set PF, ZF and SF, so the atomic builtins
could use those to emit more optimal code instead of a cmpxchg loop.
Given:
template int atomic_rmw_op(std::atomic_int )
{
int old = Op(i);
if (old == 0)
return 1;
if (old < 0)
return 2;
return 0;
}
---
Starting with the non-standard __atomic_OP_fetch, the current code for
inline int andn_fetch_1(std::atomic_int )
{
return __atomic_and_fetch((int *), ~1, 0);
}
is
L33:
movl%eax, %edx
andl$-2, %edx
lock cmpxchgl %edx, (%rdi)
jne .L33
movl%edx, %eax
shrl$31, %eax
addl%eax, %eax // eax = 2 if edx < 0
testl %edx, %edx
movl$1, %edx
cmove %edx, %eax
But it could be more optimally written as:
movl%ecx, 1
movl%edx, 2
xorl%eax, %eax
lock andl$-2, (%rdi)
cmove %ecx, %eax
cmovs %edx, %eax
The other __atomic_OP_fetch operations are very similar. I note that GCC
already realises that if you perform __atomic_and_fetch(ptr, 1), the result
can't have the sign bit set.
---
For the standard atomic_fetch_OP operations, there are a couple of caveats:
fetch_and: if the retrieved value is ANDed again with the same pattern; for
example:
int pattern = 0x8001;
return i.fetch_and(pattern, std::memory_order_relaxed) & pattern;
This appears to be partially implemented, depending on what the pattern is. For
example, it generates the optimal code for pattern = 3, 15, 0x7fff,
0x8000. It appears to be related to testing for either SF or ZF, but not
both.
fetch_or: always for SF, for the useful case when the pattern being ORed
doesn't already contain the sign bit. If it does (a "non-useful case"), then
the comparison is a constant, and likewise for ZF because it's never set if the
pattern isn't zero.
fetch_xor: always, because the original value is reconstructible. Avoid
generating unnecessary code in case the code already does the XOR itself, as
in:
return i.fetch_xor(1, std::memory_order_relaxed) ^ 1;
See https://gcc.godbolt.org/z/n9bMnaE4e for full results.
[Bug tree-optimization/110177] [12/13/14 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r12-2305-g398572c1544
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110177 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-06-08 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Confirmed. But I don't think r12-2305-g398572c1544 caused it ...
[Bug target/110181] longlong.h for RISCV should define count_leading_zeros and count_trailing_zeros and COUNT_LEADING_ZEROS_0 when ZBB is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110181 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug target/110183] New: ICE in extract_constrain_insn, at recog.cc:2692 on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110183
Bug ID: 110183
Summary: ICE in extract_constrain_insn, at recog.cc:2692 on
s390x-linux-gnu
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux-gnu
Target: s390x-linux-gnu
With a cross compiler (revision r14-1637-gcd9c7f898d6e63)
configured with:
/home/worker/buildworker/tiber-gcc-trunk-s390x/build/configure
--enable-languages=c,c++,fortran,rust,m2 --disable-bootstrap
--disable-libsanitizer --disable-multilib --enable-checking=release
--prefix=/home/worker/cross --target=s390x-linux-gnu
--with-as=/usr/bin/s390x-suse-linux-as
and our existing testcase gcc/testsuite/gcc.c-torture/compile/pr106101.c,
compiling it as
~/cross/bin/s390x-linux-gnu-gcc
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.c-torture/compile/pr106101.c
-fno-tree-ccp -O1 -funroll-loops -w
Results in ICE:
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.c-torture/compile/pr106101.c:
In function ‘yyparse’:
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.c-torture/compile/pr106101.c:61:1:
error: insn does not satisfy its constraints:
61 | }
| ^
(insn 38 48 52 2 (set (mem:SI (const_int 4 [0x4]) [1 MEM[(int *)0B + 4B]+0 S4
A32])
(reg/f:DI 71 [ *_3 ]))
"/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.c-torture/compile/pr106101.c":53:12
1480 {*movsi_zarch}
(nil))
during RTL pass: postreload
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.c-torture/compile/pr106101.c:61:1:
internal compiler error: in extract_constrain_insn, at recog.cc:2692
0x61b34a _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/rtl-error.cc:108
0x61b370 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/rtl-error.cc:118
0x61a871 extract_constrain_insn(rtx_insn*)
/home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/recog.cc:2692
0xaf7266 reload_cse_simplify_operands
/home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/postreload.cc:396
0xaf7cac reload_cse_simplify
/home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/postreload.cc:179
0xaf7cac reload_cse_regs_1
/home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/postreload.cc:227
0xaf9a5b reload_cse_regs
/home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/postreload.cc:65
0xaf9a5b execute
/home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/postreload.cc:2354
[Bug tree-optimization/110176] [10/11/12/13/14 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110176 --- Comment #4 from Andrew Pinski --- 10.4.0: Value numbering stmt = _8 = _7 <= i_19; Applying pattern match.pd:4279, gimple-match.c:13484 Match-and-simplified _7 <= i_19 to 1 RHS _7 <= i_19 simplified to 1 Setting value number of _8 to 1 GCC 10.3.0: Value numbering stmt = _8 = _7 <= i_19; Applying pattern match.pd:4274, gimple-match.c:7895 Match-and-simplified _7 <= i_19 to 1 RHS _7 <= i_19 simplified to 1 Not changing value number of _8 from VARYING to 1 Maybe r10-9757-gec97d2e842022a3f112e27d6d8
[Bug tree-optimization/110176] [10/11/12/13/14 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110176
Andrew Pinski changed:
What|Removed |Added
Summary|wrong code at -Os and above |[10/11/12/13/14 Regression]
|on x86_64-linux-gnu |wrong code at -Os and above
||on x86_64-linux-gnu
Known to fail||10.4.0, 11.1.0
Target Milestone|--- |10.5
Known to work||10.3.0
--- Comment #3 from Andrew Pinski ---
The C++ testcase that is:
```
int a, b;
void c() {}
[[gnu::noipa]]
void h() {__builtin_abort();}
int d() {
unsigned f[1];
int i;
if (a)
goto h;
f[0] = -1;
while (1) {
c();
for (; a < 1; a++) {
if (0) {
j:
continue;
}
i = f[0];
if (a)
break;
b = i >= (b == 0);
}
if (!b) {
if (0) {
h:
goto j;
}
return 0;
}
h();
}
}
int main() {
d();
return 0;
}
```
[Bug tree-optimization/110176] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110176
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2023-06-08
--- Comment #2 from Andrew Pinski ---
Here is a testcase which will abort rather than do an infinite loop:
```
int f(_Bool t)
{
int tt = t;
unsigned x = -1;
int xx = x;
return xx <= tt;
}
int a, b;
void c() {}
[[gnu::noipa]]
void h() {__builtin_abort();}
int d() {
unsigned f[1];
int i;
if (a)
goto h;
f[0] = -1;
while (1) {
c();
for (; a < 1; a++) {
if (0) {
j:
continue;
}
i = f[0];
if (a)
break;
b = i >= (b == 0);
}
if (!b) {
if (0) {
h:
goto j;
}
return 0;
}
h();
}
}
int main() {
d();
return 0;
}
```
[Bug tree-optimization/110176] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110176
--- Comment #1 from Andrew Pinski ---
Fre turns:
b.2_4 = b;
_5 = b.2_4 == 0;
_6 = (int) _5;
_7 = _6 <= i_19;
_8 = (int) _7;
b = _8;
Into:
b.2_4 = b;
_5 = b.2_4 == 0;
_6 = (int) _5;
b = 1;
Which is wrong as _6 <= -1 is always 0.
(simplify
(cmp (convert@0 @00) (convert?@1 @10))
...
tree min = lower_bound_in_type (TREE_TYPE (@10), TREE_TYPE (@00));
tree max = upper_bound_in_type (TREE_TYPE (@10), TREE_TYPE (@00));
bool above = integer_nonzerop (const_binop (LT_EXPR, type, max, @10));
bool below = integer_nonzerop (const_binop (LT_EXPR, type, @10, min));
...
(if (above || below)
...
{ constant_boolean_node (above ? true : false, type); }
[Bug tree-optimization/110182] [11/12/13/14 Regression] Vector(2) cast from double to float and subtraction seems to produce incorrect results at -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110182
Andrew Pinski changed:
What|Removed |Added
Component|target |tree-optimization
Last reconfirmed||2023-06-08
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #3 from Andrew Pinski ---
Reduced testcase:
```
typedef float vec2float __attribute__((vector_size(2*sizeof(float;
typedef double vec2double __attribute__((vector_size(2*sizeof(double;
vec2double f(vec2double a)
{
auto t0 = a[0];
auto t1 = a[1];
float b0 = t0;
float b1 = t1;
double c0 = b0;
double c1 = b1;
auto r0 = t0 - c0;
auto r1 = t1 - c1;
return (vec2double){r0, r1};
}
double f1(double a)
{
auto t0 = a;
float b0 = t0;
double c0 = b0;
auto r0 = t0 - c0;
return r0;
}
```
f should produce a similar results as f1 but does not.
The problem is not SLP directly, it is doing an ok job.
It produces:
_12 = a_1(D);
vect_b0_4.4_13 = (vector(2) float) _12;
vect_c0_6.5_14 = (vector(2) double) vect_b0_4.4_13;
vect_r0_8.6_15 = _12 - vect_c0_6.5_14;
Which is correct.
But then FRE comes along and does:
vect_r0_8.6_15 = a_1(D) - a_1(D);
Because the code in match.pd that handles
/* Handle cases of two conversions in a row. */
Messes up and uses TYPE_PRECISION for vector types but that stores the number
of elements in the vector .
[Bug target/110182] [11/12/13/14 Regression] Vector(2) cast from double to float and subtraction seems to produce incorrect results at -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110182 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Known to fail||11.1.0 Summary|Vector(2) cast from double |[11/12/13/14 Regression] |to float and subtraction|Vector(2) cast from double |seems to produce incorrect |to float and subtraction |results at -O2 and above|seems to produce incorrect ||results at -O2 and above Known to work||10.4.0 Target||x86_64-linux-gnu Target Milestone|--- |11.5
[Bug target/110182] Vector(2) cast from double to float and subtraction seems to produce incorrect results at -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110182 --- Comment #2 from Andrew Pinski --- >but not -O3. Oh that is because the vectorizer is not enabled at -O2 in GCC 11 but is for GCC 12+.
[Bug target/110182] Vector(2) cast from double to float and subtraction seems to produce incorrect results at -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110182
Andrew Pinski changed:
What|Removed |Added
Component|c++ |target
Summary|GCC generates incorrect |Vector(2) cast from double
|results for simple Eigen|to float and subtraction
|Casts / Subtractions at -O2 |seems to produce incorrect
|or above for a 3|results at -O2 and above
|dimensional vector |
--- Comment #1 from Andrew Pinski ---
Looks like a target issue:
The gimple level looks like this in GCC 12 for low:
vect__178.810_465 = (vector(2) float) _165;
vect__202.814_467 = _165 - _165;
vect__203.815_466 = (vector(2) float) vect__202.814_467;
_172 = SR.808_30 * 6.371e+6;
MEM[(struct plain_array *)] ={v} {CLOBBER};
MEM [(float &)] = vect__178.810_465;
_184 = (float) _172;
MEM[(float &) + 8] = _184;
MEM[(struct plain_array *)] ={v} {CLOBBER};
MEM [(float &)] = vect__203.815_466;
While for GCC 11 we have the casting as scalar:
_173 = (float) _298;
MEM[(float &)] = _173;
_296 = BIT_FIELD_REF <_160, 64, 64>;
_177 = (float) _296;
MEM[(float &) + 4] = _177;
_179 = (float) _167;
MEM[(float &) + 8] = _179;
MEM[(struct plain_array *)] ={v} {CLOBBER};
_192 = (double) _173;
_197 = _298 - _192;
_198 = (float) _197;
MEM[(float &)] = _198;
_224 = (double) _177;
_229 = _296 - _224;
_230 = (float) _229;
MEM[(float &) + 4] = _230;
_208 = (double) _179;
_213 = _167 - _208;
_214 = (float) _213;
MEM[(float &) + 8] = _214;
[Bug tree-optimization/110165] [13/14 Regression] wrong code with signed 1 bit integers sometimes since r13-4459-g6508d5e5a1a8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110165 --- Comment #5 from Andrew Pinski --- Created attachment 55287 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55287=edit Patch for trunk Have the testcases but didn't add them to the patch. Will also Create the GCC 13 patch later today.
[Bug c++/110182] New: GCC generates incorrect results for simple Eigen Casts / Subtractions at -O2 or above for a 3 dimensional vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110182 Bug ID: 110182 Summary: GCC generates incorrect results for simple Eigen Casts / Subtractions at -O2 or above for a 3 dimensional vector Product: gcc Version: 13.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lakin at vividtheory dot com Target Milestone: --- Created attachment 55286 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55286=edit The minimal reproducing example I am attaching a simple example program that shows how gcc is getting an incorrect result for a simple program which is attempting to represent a 1D matrix of doubles as two floating point matrices, one for the closest value as a float and one for the remainder. gcc 11 gets correct results at -O1 and -O2, but not -O3. gcc 12/13 get incorrect results at -O2 and -O3, but not at -O1. I've attached the source file below, and am more than happy to provide more information / intermediate outputs. However, one can reproduce this even at godbolt: https://godbolt.org/z/j7P5of7xo More info here: https://gist.github.com/lakinwecker/9ef9dbde94c018a33f4c33822c6d93ad
[Bug modula2/110126] Variables are reported as unused when only referenced by ASM statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110126 Gaius Mulley changed: What|Removed |Added CC||gaius at gcc dot gnu.org --- Comment #4 from Gaius Mulley --- Created attachment 55285 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55285=edit Proposed fix Here is a proposed fix.
[Bug tree-optimization/110177] [12/13/14 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r12-2305-g398572c1544
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110177 --- Comment #1 from Andrew Pinski --- Hmm, in ccp1, GCC 11.3 does: Visiting statement: # RANGE [0, 0] NONZERO 0 b_33 = (short intD.25) _11; which is likely CONSTANT Applying pattern match.pd:3405, gimple-match.c:27041 Applying pattern match.pd:3322, gimple-match.c:26980 Match-and-simplified (short int) _11 to _10 Lattice value changed to CONSTANT 0. Adding SSA edges to worklist. marking stmt to be not simulated again Visiting statement: if (b_33 != 0) which is likely CONSTANT Adding destination of edge (4 -> 6) to worklist marking stmt to be not simulated again While in GCC 12+ does: Visiting statement: b_33 = (short intD.25) _11; which is likely CONSTANT Applying pattern match.pd:3730, gimple-match.cc:69683 Applying pattern match.pd:3647, gimple-match.cc:69622 Match-and-simplified (short int) _11 to _10 Lattice value changed to CONSTANT _10. Adding SSA edges to worklist. marking stmt to be not simulated again Visiting statement: if (b_33 != 0) which is likely CONSTANT Matching expression match.pd:2118, generic-match.cc:693 Matching expression match.pd:2121, generic-match.cc:753 Matching expression match.pd:2128, generic-match.cc:776 Adding destination of edge (4 -> 5) to worklist Adding destination of edge (4 -> 6) to worklist
[Bug tree-optimization/110177] [12/13/14 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r12-2305-g398572c1544
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110177 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.4 Keywords||missed-optimization
[Bug target/54089] [SH] Refactor shift patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #72 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #71)
>
> > * Do we really need to add that new source file sh_loop.cc with the wrapper
> > classes? Can't we just instantiate the passes that are needed in-place when
> > they are registered?
>
> Unfortunately, no.
> [...]
That's too bad. Thanks for digging. I haven't checked myself recently, I
thought this infrastructure has been improved a little bit, but seems not so.
Perhaps SH is the only backend that wants to do this kind of thing. Let's
leave it at that for now. Later, after everything else has been cleared out we
can ask other GCC developers' opinion on this.
> Yes, of course! I'll add some 'tst #imm,0' presence tests.
That'd be good.
> Should I add hoist test? I do not yet understand how hoisting check should be
> performed, but I hope to find examples.
Also not sure how to do that at the moment. Maybe scanning RTL dumps of the
new extra passes? Or perhaps just a simple example as a start:
void test_func (int* a_ptr, int* b_ptr, unsigned int count)
{
for (unsigned int i = 0; i < count; ++i)
a_ptr[i] >> 5;
for (unsigned int i = 0; i < count; ++i)
b_ptr[i] >> 5;
}
... and then just scan the asm output and check against the expected number of
insns. In this case, mov.l insn to load the function call address.
> Maybe some other tests? If I'm missing something, please tell me.
Right now not that I can think of.
> And as I understand, I should name test file something like
> pr54089-next-free-number.c, right?
Yes, that should be fine.
[Bug target/110181] longlong.h for RISCV should define count_leading_zeros and count_trailing_zeros and COUNT_LEADING_ZEROS_0 when ZBB is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110181
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
More importantly, we don't have __builtin_{clz,ctz,ffs} builtin variant that
would work on __uint128_t (or _BitInt), nor some type-generic variant of it.
[Bug libgcc/81199] fallback definition of count_leading_zeros references hidden symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81199 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-06-08 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #4 from Andrew Pinski --- >[ 88%] Linking CXX executable ../bin/ccmake Can you provide the full linking command line rather than this non-verbose output?
[Bug target/110181] longlong.h for RISCV should define count_leading_zeros and count_trailing_zeros and COUNT_LEADING_ZEROS_0 when ZBB is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110181 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2023-06-08 --- Comment #1 from Andrew Pinski --- My team is working on this. It is more important for RISCV32 rather than RISCV64 due to not as many people use 128bit integers (note this will also improve support for _BitInt too).
[Bug target/110181] New: longlong.h for RISCV should define count_leading_zeros and count_trailing_zeros and COUNT_LEADING_ZEROS_0 when ZBB is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110181 Bug ID: 110181 Summary: longlong.h for RISCV should define count_leading_zeros and count_trailing_zeros and COUNT_LEADING_ZEROS_0 when ZBB is enabled Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Target: riscv I noticed that divdi3 on riscv32 with ZBB extensions always enabled still emits a lookup table but we really should just use __builtin_clzll/__builtin_clz (for the instruction).
[Bug target/110104] gcc produces sub-optimal code for _addcarry_u64 chain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110104 Roger Sayle changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|roger at nextmovesoftware dot com |unassigned at gcc dot gnu.org --- Comment #1 from Roger Sayle --- I proposed a fix at https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620823.html but this was obsoleted by a much more comprehensive patch (for PR79193) proposed by Jakub just an hour earlier: https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620821.html
[Bug analyzer/106392] Support iteration over C++ containers in -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106392 --- Comment #3 from Benjamin Priour --- > I think the unordered containers might be too hard. I would start with > std::vector, as that will probably give the best return on investment of > effort. > Indeed, I just found these slides from clang https://llvm.org/devmtg/2018-04/slides/Balogh-Finding%20Iterator-related%20Errors%20with%20Clang%20Static%20Analyzer.pdf They seem to be dividing the containers into 3 categories, list-like, vector-like and deque-like, thus also sticking to ordered containers. But they also are kind of brute-forcing the checks it seems, as they say upon insertion or deletion, they check every iterator position of the container. It sounds overly expensive to me, particularly for lists. Surely there is a reason they are doing that, I'm looking into it.
[Bug bootstrap/110180] On Fedora 38, egrep is now obsolescent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110180 --- Comment #2 from Jonathan Wakely --- (In reply to David Binderman from comment #0) > Fedora 38 has decided that egrep is obsolescent and grep -E > is preferred. POSIX decided it, not Fedora.
[Bug analyzer/106392] Support iteration over C++ containers in -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106392 --- Comment #2 from Jonathan Wakely --- (In reply to Benjamin Priour from comment #1) > [[gnu::invalidate(swap)]] - Both containers should be invalidated. Name > probably ill-chosen since swapping two lists invalidates nothing. Swapping doesn't invalidate iterators for any standard container. I think the unordered containers might be too hard. I would start with std::vector, as that will probably give the best return on investment of effort. > When invalidating a range, how to determine the "following" iterators, that > should be invalidated, when we are not dealing with random iterators ? > Is there even such a case in the standard library, where a method over a > container without random iterators invalidates a range/ a subset of all > iterators ? erase(first, last) invalidates iterators in the erased range.
[Bug analyzer/106390] Support gsl::owner and/or [[gnu::owner]] attribute in -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106390 --- Comment #5 from Benjamin Priour --- > I agree that this would be a problem, but instead of implying that we need > two attributes, I think this implies that we should not try to use > [[gsl::owner]] for shared ownership. If you don't try to use it for both, > the problem doesn't exist. If we discard tracking shared ownership, it indeed removes a lot of complexity, and I agree we can stick to [[gsl::owner]], and tracking moves of resources becomes much simpler. I'll go with that for now, see what tests I can do, dig a little bit.
[Bug target/110170] Sub-optimal conditional jumps in conditional-swap with floating point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110170
Andrew Pinski changed:
What|Removed |Added
Target||x86_64-linux-gnu
--- Comment #4 from Andrew Pinski ---
Note for aarch64, we do produce conditional moves but only when there is a
loop.
That is:
```
__attribute__((noinline))
void __cond_swap(double* __x, double* __y) {
for(int i = 0; i < 100; i++, __x++, __y++) {
double __r = (*__x < *__y);
double __tmp = __r ? *__x : *__y;
*__y = __r ? *__y : *__x;
*__x = __tmp;
}
}
```
Produces:
```
.L3:
ldr d31, [x0, x2]
ldr d30, [x1, x2]
fcmpe d31, d30
fcsel d29, d30, d31, mi
fcsel d31, d31, d30, mi
str d29, [x1, x2]
str d31, [x0, x2]
add x2, x2, 8
cmp x2, 800
bne .L3
```
Otherwise it will duplicate the return basic block (which is expected).
So this is a x86_64 specific issue.
[Bug analyzer/106390] Support gsl::owner and/or [[gnu::owner]] attribute in -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106390 --- Comment #4 from Jonathan Wakely --- I'm not sure that's worthwhile. Unique ownership is orders of magnitude more common, and lifetime is managed in smaller scopes. Tracking unique ownership within a single function is tractable, and useful. The lifetime can be analyzed for each function in isolation, without interprocedural analysis. Separate functions that correctly manage unique lifetimes compose into larger components which also correctly manage those lifetimes. Analyzing a shared lifetime pointer means also tracking reference counts, and the lifetime typically extends across functions, maybe even across shared library boundaries. Checking for correct code cannot be done for a single function in isolation. If std::shared_ptr is the main example of shared ownership, we don't need to support that in the analyzer, users should not be worrying about its correctness. But users frequently *do* write their own types that manage pointers directly with unique ownership. That's what the analyzer can help with. (In reply to Benjamin Priour from comment #3) > Let's say we only had [[gnu::owner]] for ownership, whether unique or shared. > If so, annotating [[gnu::owner]] would mean "I am becoming A (not THE) owner > of the given resource", i.e. it would always mean "shared" ownership. I agree that this would be a problem, but instead of implying that we need two attributes, I think this implies that we should not try to use [[gsl::owner]] for shared ownership. If you don't try to use it for both, the problem doesn't exist. I would caution against inventing new attributes here. The reason I suggested [[gsl::owner]] is because it is already supported by other analysers and so can be used in portable code.
[Bug ipa/109886] UBSAN error: shift exponent 64 is too large for 64-bit type when compiling gcc.c-torture/compile/pr96796.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886 --- Comment #8 from Andrew Macleod --- I just checked in: commit cd9c7f898d6e6313465f78227e566f27dce5e5a3 Author: Andrew MacLeod Date: Wed May 31 13:10:31 2023 -0400 Provide a new dispatch mechanism for range-ops. As a side effect it should make range_cast simply return varying if the RHS is an unsupported type or unimplemented cast. Check if this resolves this PR.
[Bug tree-optimization/110173] [13/14 Regression] Missed Dead Code Elimination when using __builtin_unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110173 Andrew Pinski changed: What|Removed |Added Summary|Missed Dead Code|[13/14 Regression] Missed |Elimination when using |Dead Code Elimination when |__builtin_unreachable since |using __builtin_unreachable |r14-569-g21e2ef2dc25| Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-06-08 Target Milestone|--- |13.2 --- Comment #6 from Andrew Pinski --- s/j();/j(0);/ Actually worked in GCC 12.3.0 but failed in GCC 13.1.0 so that is a regression there. But definitely unrelated to that GCC 14 change.
[Bug tree-optimization/110173] Missed Dead Code Elimination when using __builtin_unreachable since r14-569-g21e2ef2dc25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110173 Andrew Pinski changed: What|Removed |Added Summary|[14 Regression] Missed Dead |Missed Dead Code |Code Elimination when using |Elimination when using |__builtin_unreachable since |__builtin_unreachable since |r14-569-g21e2ef2dc25|r14-569-g21e2ef2dc25 --- Comment #5 from Andrew Pinski --- Note initializing gives the same missing jump threading opportunity.
[Bug tree-optimization/110173] [14 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r14-569-g21e2ef2dc25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110173 --- Comment #4 from Andrew Pinski --- So CCP2 now removes: Removing dead stmt:iftmp.4_9 = PHI <1(5), 0(6)> Which allows to remove all of this: [local count: 1073441178]: if (t_4(D) != 0) goto ; [50.00%] else goto ; [50.00%] [local count: 536720589]: [local count: 1073441178]: # iftmp.4_9 = PHI <1(5), 0(6)> And then jump threading happens (threadfull1) but leaves behind some extra jump threading it seems. ``` [local count: 751619281]: if (g.1_6 == 0B) goto ; [99.96%] else goto ; [0.04%] [local count: 751318634]: n = 0; goto ; [100.00%] [local count: 751408828]: if (g.1_6 == 0B) goto ; [30.00%] else goto ; [70.00%] ``` No other block can enter `bb 5`. So not my issue.
[Bug tree-optimization/110173] [14 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r14-569-g21e2ef2dc25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110173
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> Hmm
> static void i() { *h = j(); }
> static int *j(unsigned o) {
>
> I suspect this is just might be another one of these cases where a variable
> is uninitialized gets a different value now.
Yes it is definitely related to that variable being uninitialized.
if you replace o with either 1 or 0, the call to foo is there even in GCC 13.
I think this can be marked as a non-regression.
[Bug bootstrap/110180] On Fedora 38, egrep is now obsolescent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110180 --- Comment #1 from Andrew Pinski --- https://inbox.sourceware.org/gcc-patches/74ea0c62ebe19db186263053e4051f81d46e9da4.ca...@xry111.site/
[Bug c++/110175] [GCC][Crash] GCC Crash on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110175 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-06-08 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed. --- a/gcc/cp/typeck.cc +++ b/gcc/cp/typeck.cc @@ -7561,7 +7561,8 @@ cp_build_unary_op (enum tree_code code, tree xarg, bool noconvert, /* [depr.volatile.type] "Postfix ++ and -- expressions and prefix ++ and -- expressions of volatile-qualified arithmetic and pointer types are deprecated." */ - if (TREE_THIS_VOLATILE (arg) || CP_TYPE_VOLATILE_P (TREE_TYPE (arg))) + if ((TREE_THIS_VOLATILE (arg) || CP_TYPE_VOLATILE_P (TREE_TYPE (arg))) + && (complain & tf_warning)) warning_at (location, OPT_Wvolatile, "%qs expression of %-qualified type is " "deprecated", @@ -7592,7 +7593,7 @@ cp_build_unary_op (enum tree_code code, tree xarg, bool noconvert, return error_mark_node; } /* Otherwise, [depr.incr.bool] says this is deprecated. */ - else + else if (complain & tf_warning) warning_at (location, OPT_Wdeprecated, "use of an operand of type %qT " "in % is deprecated",
[Bug c++/96868] C++20 designated initializer erroneous warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96868
--- Comment #7 from Marek Polacek ---
A similar test. I'm not sure how we want -Wm-f-i to behave here.
#include
struct A {
int a;
std::optional b;
};
int main()
{
auto x = A {
.a = 123 // warns
};
}
[Bug libstdc++/108490] circle compiler support for libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108490 Jonathan Wakely changed: What|Removed |Added Resolution|--- |MOVED Status|UNCONFIRMED |RESOLVED --- Comment #11 from Jonathan Wakely --- I'm closing this because as explained above, this is a bug in circle and we can't use a different syntax to avoid it.
[Bug target/109800] [11/12 Regression] arm: ICE (segfault) loading double with -mpure-code -mbig-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109800 --- Comment #4 from CVS Commits --- The releases/gcc-12 branch has been updated by Alex Coplan : https://gcc.gnu.org/g:43619dc6e120a80305d4a52d7f9b8833c110a7db commit r12-9684-g43619dc6e120a80305d4a52d7f9b8833c110a7db Author: Alex Coplan Date: Thu May 25 13:34:46 2023 +0100 arm: Fix ICE due to infinite splitting [PR109800] In r11-966-g9a182ef9ee011935d827ab5c6c9a7cd8e22257d8 we introduce a simplification to emit_move_insn that attempts to simplify moves of the form: (set (subreg:M1 (reg:M2 ...)) (constant C)) where M1 and M2 are of equal mode size. That is problematic for the splitter vfp.md:no_literal_pool_df_immediate in the arm backend, which tries to pun an lvalue DFmode pseudo into DImode and assign a constant to it with emit_move_insn, as the new transformation simply undoes this, and we end up splitting indefinitely. This patch changes things around in the arm backend so that we use a DImode temporary (instead of DFmode) and first load the DImode constant into the pseudo, and then pun the pseudo into DFmode as an rvalue in a reg -> reg move. I believe this should be semantically equivalent but avoids the pathalogical behaviour seen in the PR. gcc/ChangeLog: PR target/109800 * config/arm/arm.md (movdf): Generate temporary pseudo in DImode instead of DFmode. * config/arm/vfp.md (no_literal_pool_df_immediate): Rather than punning an lvalue DFmode pseudo into DImode, use a DImode pseudo and pun it into DFmode as an rvalue. gcc/testsuite/ChangeLog: PR target/109800 * gcc.target/arm/pure-code/pr109800.c: New test. (cherry picked from commit f5298d9969b4fa34ff3aecd54b9630e22b2984a5)
[Bug analyzer/106392] Support iteration over C++ containers in -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106392 Benjamin Priour changed: What|Removed |Added CC||vultkayn at gcc dot gnu.org --- Comment #1 from Benjamin Priour --- Access to end iterator should be flagged as undefined behavior. Detecting invalidation is a difficult problem, as many methods are only sometimes invalidating. Checking a reallocation of the underlying container, e.g. for vectors, is (always?) a good check, but it is not sufficient, e.g. consider unordered_map.rehash(0) Additionally, flagging all calls to "possibly invalidating operations" will obviously lead to too many false positive. Thus, it might be relevant to have multiple attributes that keep track of different kinds of invalidation. Invalidating operations not only differ on their certainty, but on the iterator(s) they invalidate. Some will invalidate every iterators, while some [[gnu::invalidate]] - always invalidate [[gnu::invalidate(resize[, size_varname, capacity_varname, factor_varname ])]] - All iterators are invalidated ? Examples of such case is a vector's size exceeding its capacity, or a hashmap too loaded. Would be detected by keeping track of push*, emplace*, insert* methods, as well as clear, extract, erase. If size_, capacity_ and factor_varname are provided, the invalidation is done only if size/capacity >= factor. [[gnu::invalidate(swap)]] - Both containers should be invalidated. Name probably ill-chosen since swapping two lists invalidates nothing. [[gnu::invalidate(rehash)]] - Generic remapping of every key -> element. This one I think could be entirely replaced by the following. [[gnu::invalidate(adaptor)]] - Look at the underlying container invalidation rule. [[gnu::invalidate(_from_[, _to_[, _step_]])]] - Invalidate all iterators from _from_ to _to_ (default end()), with a jump of _step_ (default 1). Or combine them. For adaptors, we must look at their underlying containers. What policy to take for unknown parameters ? Typically if the load factor is determined at runtime, we simply cannot precisely determine the event. I believe that in such case, either the previous known value is used by the analyzer as a heuristic, or if no other known user-provided value was given, we use the implementation's default value. When invalidating a range, how to determine the "following" iterators, that should be invalidated, when we are not dealing with random iterators ? Is there even such a case in the standard library, where a method over a container without random iterators invalidates a range/ a subset of all iterators ? I didn't find any, and it is also counter-intuitive, and std::*_list certainly are not. More research needed.
[Bug c/110168] Security issue on FORTIFY_SOURCE for strcpy function (tested on i386/32 bits)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110168 Jakub Jelinek changed: What|Removed |Added Resolution|--- |INVALID CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #3 from Jakub Jelinek --- At least -O is intentionally required, without that while e.g. always_inline inline functions are inlined, arguments to them aren't really forward propagated, so __builtin_object_size (x, [01]) would pretty much always return -1, as it couldn't track what the pointer points to.
[Bug analyzer/106390] Support gsl::owner and/or [[gnu::owner]] attribute in -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106390 Benjamin Priour changed: What|Removed |Added CC||vultkayn at gcc dot gnu.org --- Comment #3 from Benjamin Priour --- I think gsl::owner might be insufficient and we should rather introduce [[gnu::owner(unique)]] and [[gnu::owner(shared)]] Let's say we only had [[gnu::owner]] for ownership, whether unique or shared. If so, annotating [[gnu::owner]] would mean "I am becoming A (not THE) owner of the given resource", i.e. it would always mean "shared" ownership. Yet doing so would make the attribute only useful to check spurious deallocations of non-owned resource, as well as detect the resource has been released in the destructor, but otherwise useless to check move operations, as we cannot require a move upon acquiring a shared resource. Thus an additional attribute will be necessary anyway, either to differentiate "shared" and "unique" ownership, or to annotate a move operation. I believe [[gnu::owner(unique|shared)]] to be preferable, as we can use it to deduce a move operation, whereas a flagged move does not induce the quality of ownership.
[Bug target/93768] Use vpternlog for composite logical operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93768 jbeulich at suse dot com changed: What|Removed |Added CC||jbeulich at suse dot com --- Comment #3 from jbeulich at suse dot com --- (In reply to ak from comment #2) > Most of it is already done as part of PR101989 "Most" really is just one 3rd of what was reported here, isn't it? 101989 is solely about "Three-input simple logicals" (beyond the small set mentioned here). In particular I haven't seen gcc do what is requested here as "Two-input inverted logicals" (I don't think I properly understand the 3rd item about ?:, as I can't imagine it's meant to apply to a vector of individual bits), prompting me to start working on some patches. Was marking the report here as duplicate really appropriate?
[Bug libgcc/110179] unwind-dw2-fde-dip.c:406: assignment makes integer from pointer without a cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110179 David Binderman changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #1 from David Binderman --- Adding author of code.
[Bug target/110180] New: On Fedora 38, egrep is now obsolescent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110180 Bug ID: 110180 Summary: On Fedora 38, egrep is now obsolescent Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Fedora 38 has decided that egrep is obsolescent and grep -E is preferred. I tried a gcc trunk build of c, c++ and fortran. $ grep -E "^Config|egrep is obsolescent" mk.out Configuring in build-x86_64-pc-linux-gnu/libiberty Configuring in ./fixincludes Configuring in ./libiberty Configuring in ./libcody Configuring in build-x86_64-pc-linux-gnu/fixincludes Configuring in build-x86_64-pc-linux-gnu/libcpp Configuring in ./zlib Configuring in ./intl Configuring in ./c++tools Configuring in ./libdecnumber Configuring in ./lto-plugin Configuring in ./libbacktrace checking if the linker (/usr/bin/ld) is GNU ld... egrep: warning: egrep is obsol escent; using grep -E checking for shared library run path origin... egrep: warning: egrep is obsolesc ent; using grep -E checking if the linker (/usr/bin/ld) is GNU ld... egrep: warning: egrep is obsol escent; using grep -E checking for shared library run path origin... egrep: warning: egrep is obsolesc ent; using grep -E Configuring in ./libcpp Configuring in ./gcc checking if the linker (/usr/bin/ld) is GNU ld... egrep: warning: egrep is obsol escent; using grep -E checking whether clang++ accepts -g... egrep: warning: egrep is obsolescent; usi ng grep -E checking if the linker (/usr/bin/ld) is GNU ld... egrep: warning: egrep is obsol escent; using grep -E checking for shared library run path origin... egrep: warning: egrep is obsolesc ent; using grep -E Configuring in ./libcc1 Configuring in x86_64-pc-linux-gnu/libgcc checking if the linker (/home/dcb38/gcc/working/./gcc/collect-ld) is GNU ld... e grep: warning: egrep is obsolescent; using grep -E Configuring in x86_64-pc-linux-gnu/libgomp Configuring in x86_64-pc-linux-gnu/libbacktrace Configuring in x86_64-pc-linux-gnu/libssp Configuring in x86_64-pc-linux-gnu/libatomic Configuring in x86_64-pc-linux-gnu/libquadmath Configuring in x86_64-pc-linux-gnu/libstdc++-v3 Configuring in x86_64-pc-linux-gnu/libgfortran checking if the linker (/home/dcb38/gcc/working/./gcc/collect-ld) is GNU ld... e grep: warning: egrep is obsolescent; using grep -E checking for shared library run path origin... egrep: warning: egrep is obsolesc ent; using grep -E Configuring in x86_64-pc-linux-gnu/libsanitizer Configuring in x86_64-pc-linux-gnu/libvtv Configuring in x86_64-pc-linux-gnu/libitm $ This might be worth fixing. OTOH, I am sure there are many systems where egrep is very much not obsolescent.
[Bug libgcc/110179] New: unwind-dw2-fde-dip.c:406: assignment makes integer from pointer without a cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110179
Bug ID: 110179
Summary: unwind-dw2-fde-dip.c:406: assignment makes integer
from pointer without a cast
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
I just tried a build of gcc trunk with clang 16.04 on x86_64.
It said:
libgcc/unwind-dw2-fde-dip.c:406:16: warning: assignment to ‘_Unwind_Ptr’ {aka
‘long unsigned int’} from ‘const unsigned char *’ makes integer from pointer
without a cast [-Wint-conversion]
Git blame says:
49310a9933 (Florian Weimer 2023-06-06 11:01:07 +0200 406) eh_frame = p +
value;
This warning might be worth fixing. I suspect a cast will do it.
[Bug other/110178] New: [14 regression] gfortran.dg/gomp/target-update-1.f90 fails after r14-1579-g4ede915d5dde93
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110178 Bug ID: 110178 Summary: [14 regression] gfortran.dg/gomp/target-update-1.f90 fails after r14-1579-g4ede915d5dde93 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:4ede915d5dde935a16df2c6640aee5ab22348d30, r14-1579-g4ede915d5dde93 make -k check-gcc RUNTESTFLAGS="gomp.exp=gfortran.dg/gomp/target-update-1.f90" FAIL: gfortran.dg/gomp/target-update-1.f90 -O scan-tree-dump gimple "#pragma omp target update to\\(c \\[len: [0-9]+\\]\\) to\\(present:a \\[len: [0-9]+\\]\\) to\\(e \\[len: [0-9]+\\]\\) from\\(present:b \\[len: [0-9]+\\]\\) from\\(d \\[len: [0-9]+\\]\\)" # of expected passes1 # of unexpected failures1 commit 4ede915d5dde935a16df2c6640aee5ab22348d30 (HEAD) Author: Tobias Burnus Date: Tue Jun 6 16:47:16 2023 +0200 openmp: Add support for the 'present' modifier
[Bug libstdc++/110167] excessive compile time for std::to_array with huge arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110167
--- Comment #10 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #6)
> if constexpr (_Nm > 1024 && is_trivially_default_constructible_v<_Tp>
> && is_trivially_assignable_v<_Tp&, _Tp&>)
> {
> array<_Tp, _Nm> __arr;
> for (size_t __i = 0; __i < _Nm; ++i)
> __arr[__i] = __a[__i];
> return __arr;
I wonder if we should do this for any N, and rely on the compiler to DTRT for
the loop.
[Bug c/110168] Security issue on FORTIFY_SOURCE for strcpy function (tested on i386/32 bits)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110168 --- Comment #2 from José Ramón Méndez Reboredo --- I have checked it. And you are right. Source fortification is only enabled when using -O* options (optimization). Al also checked that the usage of the option -D_FORTIFY_SOURCE=1 is not enough to enable it (-O* is required). I do not know if -O* should be mandatory for this purpose. I'm afraid we should close this ticket/bug (feel free to do it). Perhaps we could close this one and create another one stating that optimization options should not be required to enable code fortification. Thanks for your time. Best regards.
[Bug libstdc++/110167] excessive compile time for std::to_array with huge arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110167 Jonathan Wakely changed: What|Removed |Added Summary|excessive compile time when |excessive compile time for |optimizing std::to_array|std::to_array with huge ||arrays --- Comment #9 from Jonathan Wakely --- Adjusting the misleading title though, as optimization makes it worse, but the problem exists even at -O0
[Bug libstdc++/110167] excessive compile time when optimizing std::to_array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110167 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Component|c++ |libstdc++ Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #8 from Jonathan Wakely --- Changing back to component=libstdc++, since I don't think the compiler can really help here, but libstdc++ can avoid asking the compiler to perform miracles.
[Bug target/54089] [SH] Refactor shift patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089 --- Comment #71 from Alexander Klepikov --- > There are some formatting nits in your patch, please check again: Thanks for pointing that out, I'll check again. > But more interestingly: > * Do we really need to add that new source file sh_loop.cc with the wrapper > classes? Can't we just instantiate the passes that are needed in-place when > they are registered? Unfortunately, no. First of all, classes are defined in loop-init.cc and thus cannot be accessed directly. There are wrappers called 'make_pass_rtl_blah_bla_blah' which create class instances, but. Class .name field is hardcoded, there's no option to set it when initializing, and pass manager checks if new pass name differs from any already existing. Here's the code from passes.cc: if (pass->type == new_pass_info->pass->type && pass->name && !strcmp (pass->name, new_pass_info->reference_pass_name) //Name check ... Moreover, pass_rtl_loop_init::execute method calls a function that do the following check: gcc_assert (current_ir_type () == IR_RTL_CFGLAYOUT); And in our pass (that goes after split1 pass), current_ir_type()!=IR_RTL_CFGLAYOUT, so we will get ICE. And even if we could inherit the class, 'execute' method is final. I'm not so good at C++, so may be there's another way. I know that the less code is the better, but I'm afraid, not this time. > > * Can you add some tests to the SH specific tests? Yes, of course! I'll add some 'tst #imm,0' presence tests. Should I add hoist test? I do not yet understand how hoisting check should be performed, but I hope to find examples. Maybe some other tests? If I'm missing something, please tell me. And as I understand, I should name test file something like pr54089-next-free-number.c, right? Thank you.
[Bug c++/110167] excessive compile time when optimizing std::to_array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110167 --- Comment #7 from Jonathan Wakely --- For some value of 1024
[Bug c++/110167] excessive compile time when optimizing std::to_array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110167
--- Comment #6 from Jonathan Wakely ---
The bottom line, however, is that this use of std::to_array is not really
reasonable.
You're asking the compiler to create a variadic pack of 262144 integers, and
then create a pack expansion for std::array{arr[i]...} where i...
has 262144 elements in the pack.
That's going to be insanely large.
Maybe we can do this though:
template
[[nodiscard]]
constexpr array, _Nm>
to_array(_Tp (&__a)[_Nm])
noexcept(is_nothrow_constructible_v<_Tp, _Tp&>)
{
static_assert(!is_array_v<_Tp>);
static_assert(is_constructible_v<_Tp, _Tp&>);
if constexpr (_Nm > 1024 && is_trivially_default_constructible_v<_Tp>
&& is_trivially_assignable_v<_Tp&, _Tp&>)
{
array<_Tp, _Nm> __arr;
for (size_t __i = 0; __i < _Nm; ++i)
__arr[__i] = __a[__i];
return __arr;
}
else if constexpr (is_constructible_v<_Tp, _Tp&>)
return [&__a](index_sequence<_Idx...>) {
return array, _Nm>{{ __a[_Idx]... }};
}(make_index_sequence<_Nm>{});
__builtin_unreachable(); // FIXME: see PR c++/91388
}
[Bug tree-optimization/110177] New: [12/13/14 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r12-2305-g398572c1544
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110177
Bug ID: 110177
Summary: [12/13/14 Regression] Missed Dead Code Elimination
when using __builtin_unreachable since
r12-2305-g398572c1544
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: theodort at inf dot ethz.ch
Target Milestone: ---
https://godbolt.org/z/d6zscbYYh
void foo(void);
static int c, *d = , *f, *i;
static unsigned e;
static int **g = , **j = ,***h =
static short k;
void __assert_fail() __attribute__((__noreturn__));
static short(a)(short b) {
if (b != 0) {
__builtin_unreachable();
}
return 0;
}
int main() {
c = 0;
for (; c <= 20; c = c + 9) {
k = c << e;
c &(c >> k);
i = **h;
*j = i;
if (f)
;
else
__assert_fail();
}
e = 0;
if (f);
else
foo();
}
gcc-11.4 -Os generates:
main:
movqg(%rip), %rax
movl$0, c(%rip)
movq(%rax), %rdx
movq%rdx, f(%rip)
testq %rdx, %rdx
je .L2
movq(%rax), %rax
movq%rax, f(%rip)
testq %rax, %rax
jne .L8
movl$9, c(%rip)
.L2:
pushq %rax
xorl%eax, %eax
call__assert_fail
.L8:
movl$27, c(%rip)
xorl%eax, %eax
movl$0, e(%rip)
ret
gcc-trunk -Os generates:
main:
xorl%edi, %edi
pushq %rsi
movqg(%rip), %r8
xorl%eax, %eax
movl%edi, c(%rip)
movle(%rip), %edi
xorl%edx, %edx
.L2:
movl%eax, %esi
cmpl$27, %eax
je .L23
testl %eax, %eax
je .L3
movl%edi, %ecx
movl%eax, %r9d
movl%eax, %r10d
sall%cl, %r9d
movl%r9d, %ecx
sarl%cl, %r10d
testl %r10d, %r10d
je .L3
movl%eax, c(%rip)
.L3:
movq(%r8), %rcx
addl$9, %eax
movq%rcx, f(%rip)
testq %rcx, %rcx
jne .L8
testb %dl, %dl
je .L4
movl%esi, c(%rip)
.L4:
xorl%eax, %eax
call__assert_fail
.L8:
movb$1, %dl
jmp .L2
.L23:
testb %dl, %dl
je .L6
movl$27, c(%rip)
.L6:
xorl%ecx, %ecx
cmpq$0, f(%rip)
movl%ecx, e(%rip)
jne .L7
callfoo
.L7:
xorl%eax, %eax
popq%rdx
ret
Bisects to r12-2305-g398572c1544
[Bug tree-optimization/110176] New: wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110176
Bug ID: 110176
Summary: wrong code at -Os and above on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
It seems to affect GCC 10.4 and later.
Compiler Explorer: https://godbolt.org/z/aKfvfxa63
[504] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/software/local/gcc-trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230607 (experimental) (GCC)
[505] %
[505] % gcctk -O1 small.c; ./a.out
[506] %
[506] % gcctk -O2 small.c
[507] % timeout -s 9 5 ./a.out
Killed
[508] %
[508] % cat small.c
int a, b;
void c() {}
int d() {
unsigned f[1];
int i;
if (a)
goto h;
f[0] = -1;
while (1) {
c();
for (; a < 1; a++) {
if (0) {
j:
continue;
}
i = f[0];
if (a)
break;
b = i >= (b == 0);
}
if (!b) {
if (0) {
h:
goto j;
}
return 0;
}
}
}
int main() {
d();
return 0;
}
[Bug c++/110175] New: [GCC][Crash] GCC Crash on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110175
Bug ID: 110175
Summary: [GCC][Crash] GCC Crash on valid code
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: yronglin777 at gmail dot com
Target Milestone: ---
https://godbolt.org/z/Wf7M89v8x
```
template auto f(T t) -> decltype(++t) { return t; }
void f(...) {}
void g() { f(true); }
```
```
internal compiler error: error reporting routines re-entered.
0x23b8691 warning_at(unsigned int, int, char const*, ...)
???:0
0xd39208 cp_build_unary_op(tree_code, tree_node*, bool, int)
???:0
0xacd484 build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node**, int)
???:0
0xd370e3 build_x_unary_op(unsigned int, tree_code, cp_expr, tree_node*, int)
???:0
0xcb685f tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x23d8a2c pp_format(pretty_printer*, text_info*)
???:0
0x23d9c3d pp_format_verbatim(pretty_printer*, text_info*)
???:0
0x23d9d25 pp_verbatim(pretty_printer*, char const*, ...)
???:0
0x23b7895 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
???:0
0x23b8691 warning_at(unsigned int, int, char const*, ...)
???:0
0xd45bf1 check_return_expr(tree_node*, bool*)
???:0
0xcef6a3 finish_return_stmt(tree_node*)
???:0
0xcaf2f8 instantiate_decl(tree_node*, bool, bool)
???:0
0xcda84b instantiate_pending_templates(int)
???:0
0xb8e905 c_parse_final_cleanups()
???:0
0xdbe998 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug modula2/110174] New: Using illegal constraints for builtin return_address gives ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110174
Bug ID: 110174
Summary: Using illegal constraints for builtin return_address
gives ICE
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: modula2
Assignee: gaius at gcc dot gnu.org
Reporter: ad...@tho-otto.de
Target Milestone: ---
When compiling the the following module with -O2
MODULE foo;
FROM Builtins IMPORT return_address;
FROM SYSTEM IMPORT ADDRESS;
VAR x: ADDRESS;
PROCEDURE test();
BEGIN
ASM VOLATILE("" : "=m"(x) : "m"(return_address(0)) : );
END test;
BEGIN
test();
END foo.
I get an ICE:
during RTL pass: expand
In function ‘test’,
inlined from ‘_M2_foo_init’ at foo.mod:13:3:
foo.mod:9:56: internal compiler error: in expand_asm_stmt, at cfgexpand.cc:3419
9 | ASM VOLATILE("" : "=m"(x) : "m"(return_address(0)) : );
|^
The ICE is triggered at
https://github.com/gcc-mirror/gcc/blob/9589a46ddadc8b93c224c3f84fa94746c04596bf/gcc/cfgexpand.cc#L3419
Using "m" as constraint is actually wrong, however the C backend handles that
correctly:
foo.c:5:39: error: memory input 1 is not directly addressable
5 | __asm__ volatile("" : "=m"(x) : "m"(__builtin_return_address(0)) : );
[Bug tree-optimization/110173] [14 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r14-569-g21e2ef2dc25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110173
--- Comment #2 from Andrew Pinski ---
Hmm
static void i() { *h = j(); }
static int *j(unsigned o) {
I suspect this is just might be another one of these cases where a variable is
uninitialized gets a different value now.
[Bug tree-optimization/110173] [14 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r14-569-g21e2ef2dc25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110173 --- Comment #1 from Theodoros Theodoridis --- *The first piece of ASM is generated by gcc 13.1, the second by gcc trunk
[Bug tree-optimization/110173] New: [14 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r14-569-g21e2ef2dc25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110173
Bug ID: 110173
Summary: [14 Regression] Missed Dead Code Elimination when
using __builtin_unreachable since r14-569-g21e2ef2dc25
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: theodort at inf dot ethz.ch
Target Milestone: ---
https://godbolt.org/z/ssja5dKdY
void foo(void);
static int e, f, n, *g, **h =
static short m;
void __assert_fail() __attribute__((__noreturn__));
static short(a)(short b) { return b; }
static short(c)(short d) {
if (!(((d) >= 1) && ((d) <= 1))) {
__builtin_unreachable();
}
return 0;
}
static int *j();
static void k(int *l, char) {
*l = 0;
if (g == || g == 0 || g == );
else {
foo();
__assert_fail();
}
c(f < 5);
}
static void i() { *h = j(); }
static int *j(unsigned o) {
char p;
if (g == || g == 0);
else
__assert_fail();
p = m > (a(1) && o);
k(, p);
if (g == 0);
else
__assert_fail();
return 0;
}
int main() { i(); }
gcc-trunk -Os -S:
main:
movqg(%rip), %rax
testq %rax, %rax
je .L2
cmpq$f, %rax
je .L2
.L3:
pushq %rsi
xorl%eax, %eax
call__assert_fail
.L2:
xorl%ecx, %ecx
movl%ecx, n(%rip)
testq %rax, %rax
jne .L3
xorl%edx, %edx
movq%rdx, g(%rip)
ret
main:
pushq %rsi
movqg(%rip), %rax
cmpq$f, %rax
je .L2
testq %rax, %rax
jne .L13
.L2:
xorl%ecx, %ecx
movl%ecx, n(%rip)
cmpq$f, %rax
je .L3
testq %rax, %rax
je .L11
callfoo
.L13:
xorl%eax, %eax
call__assert_fail
.L3:
testq %rax, %rax
jne .L13
.L11:
xorl%eax, %eax
movq%rax, g(%rip)
xorl%eax, %eax
popq%rdx
ret
Bisects to r14-569-g21e2ef2dc25
[Bug demangler/110147] UBSAN error in rust-demangle.c: NULL pointer passed to memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110147
Mark Wielaard changed:
What|Removed |Added
Last reconfirmed||2023-06-08
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #3 from Mark Wielaard ---
(In reply to Jonathan Wakely from comment #2)
> --- a/libiberty/rust-demangle.c
> +++ b/libiberty/rust-demangle.c
> @@ -1569,8 +1569,11 @@ str_buf_append (struct str_buf *buf, const char
> *data, size_t len)
>if (buf->errored)
> return;
>
> - memcpy (buf->ptr + buf->len, data, len);
> - buf->len += len;
> + if (len)
> + {
> +memcpy (buf->ptr + buf->len, data, len);
> +buf->len += len;
> + }
> }
>
> static void
That is probably the correct fix/workaround. str_buf_append is the
function/callback used to build up the demangled string. If it gets an empty
NULL/0 string it really shouldn't do anything (so you could also do a if (len
== 0) return at the top).
We might want to ping ed...@lyken.rs (who wrote the original v0 rust demangler)
in case he thinks this might also need to raise an error flag. But that would
technically be a separate bug I think.
[Bug c/110168] Security issue on FORTIFY_SOURCE for strcpy function (tested on i386/32 bits)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110168 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #1 from Sam James --- Please note that: 1. _FORTIFY_SOURCE does nothing without optimisation; 2. you're not explicitly enabling _F_S here - I know Debian patches it on (we do in Gentoo too), but for bug reports, it's best to be explicit.
[Bug tree-optimization/110165] [13/14 Regression] wrong code with signed 1 bit integers sometimes since r13-4459-g6508d5e5a1a8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110165 --- Comment #4 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #3) > If zero_one_valued_p is true for [-1, 0] valued cases, then it should be > fixed. I think that is the right appoarch in the end, I will go and implement that.
[Bug analyzer/110172] New: Leak false positives from -fanalyzer with -fexceptions (even on C code)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110172
Bug ID: 110172
Summary: Leak false positives from -fanalyzer with -fexceptions
(even on C code)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
As noted by Reddit user "kr90df" here:
https://www.reddit.com/r/C_Programming/comments/13wl8qi/improvements_to_static_analysis_in_the_gcc_13/jndkr80/
we get a false +ve from -Wanalyzer-va-list-leak on this C code when
-fexceptions is enabled:
#include
#include
int printerr(char *msg, ...)
{
va_list ap;
va_start(ap, msg);
vfprintf(stderr, msg, ap);
va_end(ap);
return(-1);
}
See https://godbolt.org/z/zrxsrYE4j
: In function 'printerr':
:12:1: warning: missing call to 'va_end' [-Wanalyzer-va-list-leak]
12 | }
| ^
'printerr': events 1-2
|
|7 | va_start(ap, msg);
| | ^~~~
| | |
| | (1) 'va_start' called here
|..
| 12 | }
| | ~
| | |
| | (2) missing call to 'va_end' to match 'va_start' at (1)
|
[Bug target/110170] Sub-optimal conditional jumps in conditional-swap with floating point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110170 --- Comment #3 from Andrew Pinski --- So for arm, GCC does produce the code you want: ``` vcmpe.f64 d17, d16 vmrsAPSR_nzcv, FPSCR ite pl vmovpl.f64 d18, d17 vmovmi.f64 d18, d16 it mi vmovmi.f64 d16, d17 ``` RTL CE1 (ifcvt) detects it: if-conversion succeeded through noce_convert_multiple_sets So maybe there is some cost issue. Because arm64 does not do it either.
[Bug target/54089] [SH] Refactor shift patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #70 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #69)
> Created attachment 55284 [details]
> Collapsed libcall and additional loop move invariants patch
Thanks for sharing the patch. I also don't have the GCC SH test environment
setup at the moment, so it will take me some time to get up to speed on that.
There are some formatting nits in your patch, please check again:
* don't add / remove empty lines for no reason
* '{' goes on new line (follow surrounding code style)
* in comments: two spaces after the period
* closing ')' and ']' in the RTL should go on the same line (follow surrounding
style)
But more interestingly:
* Do we really need to add that new source file sh_loop.cc with the wrapper
classes? Can't we just instantiate the passes that are needed in-place when
they are registered?
* Can you add some tests to the SH specific tests?
[Bug c++/110171] New: [[nodiscard]] of await_resume ignored when discarding result of co_await expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110171
Bug ID: 110171
Summary: [[nodiscard]] of await_resume ignored when discarding
result of co_await expression
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lukaslang.bugtracker at outlook dot com
Target Milestone: ---
(Note: The example & bug is very similar to this here:
https://developercommunity.visualstudio.com/t/nodiscard-not-honored-by-co_await/1500944)
It seems that discarding the `co_await`ed result of an awaitable with
`[[nodiscard]]` `await_resume` doesn't lead to the expected warning
([Godbolt](https://godbolt.org/z/o47EdzMj8)):
```
#include
struct must_check_result
{
bool await_ready() { return false; }
void await_suspend(std::coroutine_handle<>) {}
[[nodiscard]] bool await_resume() { return {}; }
};
struct task {};
namespace std
{
template
struct coroutine_traits
{
struct promise_type
{
task get_return_object() { return {}; }
suspend_always initial_suspend() noexcept { return {}; }
suspend_always final_suspend() noexcept { return {}; }
void return_void() {}
void unhandled_exception() {}
};
};
}
task example()
{
co_await must_check_result(); // no warning even though await_ready is
marked [[nodiscard]]
must_check_result().await_resume();
}
```
[Bug c++/109739] bogus warning due to -Wmissing-field-initializers in C++20 with designated initializers on struct with empty base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109739 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=110064 --- Comment #1 from Marek Polacek --- Looks like a dup of bug 110064.
[Bug libstdc++/110149] std::format for pointer arguments allows a '0' option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110149 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Last reconfirmed||2023-06-08 Status|UNCONFIRMED |ASSIGNED Target Milestone|--- |13.2 Ever confirmed|0 |1 --- Comment #4 from Jonathan Wakely --- I plan to support the P2510 changes unconditionally in C++20 mode, i.e. treat it as a DR against C++20. But it should actually work as proposed by P2510, and it seems that I only half implemented it so far.
[Bug ipa/109886] UBSAN error: shift exponent 64 is too large for 64-bit type when compiling gcc.c-torture/compile/pr96796.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886 --- Comment #7 from Martin Jambor --- I see, thanks! But I wonder whether it would make sense to commit the simple fix in the meantime so that the test pass. It is easy to miss new regressions now when I expect the overall result not to be clean.
[Bug target/54089] [SH] Refactor shift patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089 --- Comment #69 from Alexander Klepikov --- Created attachment 55284 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55284=edit Collapsed libcall and additional loop move invariants patch
[Bug modula2/110125] Variables are reported as uninitialized when only set inside WITH statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110125 --- Comment #2 from Thorsten Otto --- Maybe related to this: MODULE foo; TYPE Head = RECORD magic: INTEGER; END; Carrier = RECORD head: Head; tail: Head; END; PROCEDURE test(VAR carrier: Carrier); BEGIN carrier.head.magic := 0; carrier.tail.magic := 0; END test; VAR x: Carrier; BEGIN test(x); END foo. also gives warning about unused parameter "carrier" in function test.
[Bug target/54089] [SH] Refactor shift patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089 --- Comment #68 from Alexander Klepikov --- OK, I finished my patch. Let me remind you briefly, what it does. First, it does not emit library call for ashrsi3 during expand pass. Instead it emits intermediate 'collapsed' libcall insn which is expanded later at split1 pass. Consecutive right arithmetic shifts can be catched at combine pass and converted to 'collapsed' libcall insn. Then 'collapsed' insn splits whether to short sequnce of individual right shifts or to __ashiftrt_r4_N library call during split1 pass. Finally, loop move invariants only pass executed right after split1 pass to hoist library addresses that potentially were emitted during split pass. I ran GCC testsuite and there were 1 new failed test that actually turned out to be an optimization, and 3 tests that failed on clean GCC and passed on patched. I could not set up my environment to test all little endian exec tests, so for those I don't have results. Also I successfully compiled (but not linked due to not fully set environment) Linux kenel 6.1. My homemade performance tests (I timed linux kernel build) showed a slowdown of less then 3%. To reduce slowdown it would be good to run loop move invariants pass only in functions that have expanded libcall, but to do so it is necessary to mark such funcnion when emitting insn and I'm not so sure if insn knows about in what function it is located.
[Bug target/110170] Sub-optimal conditional jumps in conditional-swap with floating point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110170 --- Comment #2 from Antony Polukhin --- -fno-trapping-math had no effect Some tests with nans seem to produce the same results for both code snippets: https://godbolt.org/z/GaKM3EhMq
[Bug c/110169] wrong code with '-Ofast'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110169 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #2 from Alexander Monakov --- It seems csmith was run with the --float argument. Differences under -Ofast are expected (but even without -Ofast, it seems csmith can emit bit manipulation of arbitrary floats, which can lead to unpredictable results when NaNs are involved).
[Bug tree-optimization/110170] Sub-optimal conditional jumps in conditional-swap with floating point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110170 --- Comment #1 from Andrew Pinski --- Is that only valid if not trapping math? Gcc defaults to -ftrapping-math . Try disabling it and see if you get that result. Also is that correct for nans?
[Bug tree-optimization/110170] New: Sub-optimal conditional jumps in conditional-swap with floating point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110170
Bug ID: 110170
Summary: Sub-optimal conditional jumps in conditional-swap with
floating point
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
Some of the C++ algorithms are written in attempt to avoid conditional jumps in
tight loops. For example, code close the following could be seen in libc++:
void __cond_swap(double* __x, double* __y) {
bool __r = (*__x < *__y);
auto __tmp = __r ? *__x : *__y;
*__y = __r ? *__y : *__x;
*__x = __tmp;
}
GCC-14 with -O2 and -march=x86-64 options generates the following code:
__cond_swap(double*, double*):
movsd xmm1, QWORD PTR [rdi]
movsd xmm0, QWORD PTR [rsi]
comisd xmm0, xmm1
jbe .L2
movqrax, xmm1
movapd xmm1, xmm0
movqxmm0, rax
.L2:
movsd QWORD PTR [rsi], xmm1
movsd QWORD PTR [rdi], xmm0
ret
A conditional jump could be probably avoided in the following way:
__cond_swap(double*, double*):
movsd xmm0, qword ptr [rdi]
movsd xmm1, qword ptr [rsi]
movapd xmm2, xmm0
minsd xmm2, xmm1
maxsd xmm1, xmm0
movsd qword ptr [rsi], xmm1
movsd qword ptr [rdi], xmm2
ret
Playground: https://godbolt.org/z/v3jW67x91
[Bug c++/110167] excessive compile time when optimizing std::to_array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110167 --- Comment #5 from Jonathan Wakely --- It's hard to bisect where it got slower between 10 and 11, and between 11 and 12, because for --enable-checking builds the extra assertions slow everything down and the difference between "fast with slow assertions" and "slow with slow assertions" is much less significant than "fast" and "slow".
[Bug c/110169] wrong code with '-Ofast'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110169 --- Comment #1 from CTC <19373742 at buaa dot edu.cn> --- Created attachment 55283 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55283=edit The compiler output
[Bug c/110169] New: wrong code with '-Ofast'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110169 Bug ID: 110169 Summary: wrong code with '-Ofast' Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: 19373742 at buaa dot edu.cn Target Milestone: --- Created attachment 55282 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55282=edit The preprocessed file *** OS and Platform: CentOS Linux release 7.9.2009 (Core), x86_64 GNU/Linux *** gcc version: # /home/gcc-releases/gcc-14-0604/bin/gcc -v Using built-in specs. COLLECT_GCC=/home/gcc-releases/gcc-14-0604/bin/gcc COLLECT_LTO_WRAPPER=/home/gcc-releases/gcc-14-0604/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ./configure --prefix=/home/gcc-releases/gcc-14-0604/ --disable-multilib --enable-languages=c,c++ Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.0 20230604 (experimental) (GCC) *** Command Lines: # gcc -I /home/csmith_record/include/csmith-2.3.0/ -Ofast -fno-aggressive-loop-optimizations -fno-align-functions -fno-align-jumps -fno-align-labels -fno-align-loops -fno-allocation-dce -fno-allow-store-data-races -fno-associative-math -fno-asynchronous-unwind-tables -fno-auto-inc-dec -fno-bit-tests -fno-branch-count-reg -fno-caller-saves -fno-code-hoisting -fno-combine-stack-adjustments -fno-compare-elim -fno-cprop-registers -fno-crossjumping -fno-cse-follow-jumps -fno-cx-limited-range -fno-dce -fno-defer-pop -fno-devirtualize -fno-devirtualize-speculatively -fno-dse -fno-early-inlining -fno-expensive-optimizations -fno-finite-math-only -fno-forward-propagate -fno-fp-int-builtin-inexact -fno-function-cse -fno-gcse -fno-gcse-after-reload -fno-gcse-lm -fno-guess-branch-probability -fno-hoist-adjacent-loads -fno-if-conversion -fno-if-conversion2 -fno-indirect-inlining -fno-inline -fno-inline-atomics -fno-inline-functions -fno-inline-functions-called-once -fno-inline-small-functions -fno-ipa-bit-cp -fno-ipa-cp -fno-ipa-cp-clone -fno-ipa-icf -fno-ipa-icf-functions -fno-ipa-icf-variables -fno-ipa-modref -fno-ipa-profile -fno-ipa-pure-const -fno-ipa-ra -fno-ipa-reference -fno-ipa-reference-addressable -fno-ipa-sra -fno-ipa-stack-alignment -fno-ipa-strict-aliasing -fno-ipa-vrp -fno-ira-hoist-pressure -fno-ira-share-save-slots -fno-ira-share-spill-slots -fno-isolate-erroneous-paths-dereference -fno-ivopts -fno-jump-tables -fno-lifetime-dse -fno-loop-interchange -fno-loop-unroll-and-jam -fno-lra-remat -fno-move-loop-invariants -fno-move-loop-stores -fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-optimize-strlen -fno-partial-inlining -fno-peel-loops -fno-peephole -fno-peephole2 -fno-plt -fno-predictive-commoning -fno-printf-return-value -fno-reciprocal-math -fno-ree -fno-reg-struct-return -fno-reorder-blocks -fno-reorder-blocks-and-partition -fno-reorder-functions -fno-rerun-cse-after-loop -fno-sched-critical-path-heuristic -fno-sched-dep-count-heuristic -fno-sched-group-heuristic -fno-sched-interblock -fno-sched-last-insn-heuristic -fno-sched-rank-heuristic -fno-sched-spec -fno-sched-spec-insn-heuristic -fno-sched-stalled-insns-dep -fno-schedule-fusion -fno-schedule-insns2 -fno-short-enums -fno-shrink-wrap -fno-shrink-wrap-separate -fno-split-ivs-in-unroller -fno-split-loops -fno-split-paths -fno-split-wide-types -fno-ssa-backprop -fno-ssa-phiopt -fno-stdarg-opt -fno-store-merging -fno-strict-aliasing -fno-thread-jumps -fno-toplevel-reorder -fno-tree-bit-ccp -fno-tree-builtin-call-dce -fno-tree-ccp -fno-tree-ch -fno-tree-coalesce-vars -fno-tree-copy-prop -fno-tree-dce -fno-tree-dominator-opts -fno-tree-dse -fno-tree-forwprop -fno-tree-fre -fno-tree-loop-distribute-patterns -fno-tree-loop-distribution -fno-tree-loop-im -fno-tree-loop-ivcanon -fno-tree-loop-optimize -fno-tree-loop-vectorize -fno-tree-partial-pre -fno-tree-phiprop -fno-tree-pre -fno-tree-pta -fno-tree-reassoc -fno-tree-scev-cprop -fno-tree-sink -fno-tree-slp-vectorize -fno-tree-slsr -fno-tree-sra -fno-tree-switch-conversion -fno-tree-tail-merge -fno-tree-ter -fno-tree-vrp -fno-unroll-completely-grow-size -fno-unroll-loops -fno-unsafe-math-optimizations -fno-unswitch-loops -fno-unwind-tables -fno-version-loops-for-strides -fno-aggressive-loop-optimizations -fno-align-functions -falign-jumps -falign-labels -fno-align-loops -fallocation-dce -fallow-store-data-races -fno-associative-math -fno-asynchronous-unwind-tables -fauto-inc-dec -fno-bit-tests -fno-branch-count-reg -fcaller-saves -fno-code-hoisting -fcombine-stack-adjustments -fno-compare-elim -fno-cprop-registers -fcrossjumping -fcse-follow-jumps -fno-cx-limited-range -fdce
[Bug c++/110167] excessive compile time when optimizing std::to_array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110167 --- Comment #4 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #2) > The "obvious" alternative impl using a lambda expression is even slower: Actually for GCC 13 it's faster: $ time ~/gcc/13/bin/g++ 110167.cc -c -O3 real0m9.422s user0m9.232s sys 0m0.170s $ time ~/gcc/13/bin/g++ 110167.cc -c -O3 -DUSE_LAMBDA real0m6.403s user0m6.342s sys 0m0.048s So that's nice.
[Bug c++/110167] excessive compile time when optimizing std::to_array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110167 --- Comment #3 from Jonathan Wakely --- $ time ~/gcc/9/bin/g++ 110167.cc -c -O3 real0m5.568s user0m5.497s sys 0m0.035s $ time ~/gcc/10/bin/g++ 110167.cc -c -O3 real0m5.393s user0m5.355s sys 0m0.028s $ time ~/gcc/11/bin/g++ 110167.cc -c -O3 real0m10.543s user0m10.205s sys 0m0.317s $ time ~/gcc/12/bin/g++ 110167.cc -c -O3 real0m14.042s user0m13.747s sys 0m0.270s $ time ~/gcc/13/bin/g++ 110167.cc -c -O3 real0m9.422s user0m9.232s sys 0m0.170s
