[Bug testsuite/102944] Many gcc.dg/Wstringop-overflow-*.c failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102944 --- Comment #4 from Hongtao.liu --- > I'm seeing it on 64-bit sparc, and there are also reports for > s390x-ibm-linux-gnu and m68k-unknown-linux-gnu. It may be a > coincidance, but those are all big-endian targets. There seems to be a miss optimization issue, open pr103076 to track that. If the miss optimization isssue is fixed in vectorizer, those testcase would pass, if not, i'll adjust my patch.
[Bug tree-optimization/103076] New: slp vectorizer failed to try smaller lenth.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103076
Bug ID: 103076
Summary: slp vectorizer failed to try smaller lenth.
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: s390x-ibm-linux-gnu
struct Ax
{
int n;
short a[4];
};
void
foo4_2 (struct Ax *p)
{
p->a[0] = 0;
p->a[1] = 1;
p->a[2] = 2;
p->a[3] = 3;
}
Struct is 4-byte aligned, and gcc failed to vectorize it since s390 backend
doesn't support unaligned vector(4) short store. But it can be splitted into 2
vector(2) short store, i.e.
struct Ax
{
int n;
short a[4];
};
void
foo4_2 (struct Ax *p)
{
p->a[0] = 0;
p->a[1] = 1;
}
void
foo4_3 (struct Ax *p)
{
p->a[2] = 2;
p->a[3] = 3;
}
Gcc can vectorize both foo4_2 and foo4_3 with
add new stmt: MEM [(short int *)vectp.5_5] = { 0, 1 };
add new stmt: MEM [(short int *)vectp.10_5] = { 2, 3 }
[Bug rtl-optimization/103075] New: [12 Regression] ICE in exact_int_to_float_conversion_p, at simplify-rtx.c:905
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103075
Bug ID: 103075
Summary: [12 Regression] ICE in
exact_int_to_float_conversion_p, at simplify-rtx.c:905
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-12.0.0-alpha20211031 snapshot (g:ca84f39399fda80c770306465276ffd66d3766ed)
ICEs when compiling the following testcase w/ -O1 -frounding-math:
float
foo (void)
{
return (float) 0x1699925 * 1.1;
}
% gcc-12.0.0 -O1 -frounding-math -c bohjhgb9.c
during RTL pass: combine
bohjhgb9.c: In function 'foo':
bohjhgb9.c:5:1: internal compiler error: in exact_int_to_float_conversion_p, at
simplify-rtx.c:905
5 | }
| ^
0x70c80e exact_int_to_float_conversion_p
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211031/work/gcc-12-20211031/gcc/simplify-rtx.c:905
0xe75fc9 simplify_context::simplify_unary_operation_1(rtx_code, machine_mode,
rtx_def*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211031/work/gcc-12-20211031/gcc/simplify-rtx.c:1348
0x1b438b6 simplify_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211031/work/gcc-12-20211031/gcc/rtl.h:3459
0x1b438b6 combine_simplify_rtx
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211031/work/gcc-12-20211031/gcc/combine.c:5605
0x1b45f26 subst
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211031/work/gcc-12-20211031/gcc/combine.c:5545
0x1b45e54 subst
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211031/work/gcc-12-20211031/gcc/combine.c:5478
0x1b48ffe try_combine
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211031/work/gcc-12-20211031/gcc/combine.c:3272
0x1b4fa89 combine_instructions
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211031/work/gcc-12-20211031/gcc/combine.c:1411
0x1b4fa89 rest_of_handle_combine
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211031/work/gcc-12-20211031/gcc/combine.c:14904
0x1b4fa89 execute
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211031/work/gcc-12-20211031/gcc/combine.c:14949
[Bug target/103074] New: [11/12 Regression] ICE in lra_assign, at lra-assigns.c:1649
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103074
Bug ID: 103074
Summary: [11/12 Regression] ICE in lra_assign, at
lra-assigns.c:1649
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: x86_64-unknown-linux-gnu
gcc-12.0.0-alpha20211031 snapshot (g:ca84f39399fda80c770306465276ffd66d3766ed)
ICEs when compiling the following testcase, which could expose UB in run time,
w/ -march=bonnell -Os -fPIC -fschedule-insns:
void
serialize_collection (char *ptr, int a, int need_owner)
{
if (need_owner)
__builtin_sprintf(ptr, "%d:%d", 0, a);
else
{
static char buff[32];
__builtin_sprintf(buff, "%d:%d", a >> 32, a);
__builtin_sprintf(ptr, "%d:%d:\"%s\"", 0, 0, buff);
}
}
% x86_64-unknown-linux-gnu-gcc-12.0.0 -march=bonnell -Os -fPIC -fschedule-insns
-c jmolltrp.c
jmolltrp.c: In function 'serialize_collection':
jmolltrp.c:10:42: warning: right shift count >= width of type
[-Wshift-count-overflow]
10 | __builtin_sprintf(buff, "%d:%d", a >> 32, a);
| ^~
during RTL pass: reload
jmolltrp.c:13:1: internal compiler error: in lra_assign, at lra-assigns.c:1649
13 | }
| ^
0xce9af3 lra_assign(bool&)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211031/work/gcc-12-20211031/gcc/lra-assigns.c:1649
0xce3da4 lra(_IO_FILE*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211031/work/gcc-12-20211031/gcc/lra.c:2387
0xc9c029 do_reload
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211031/work/gcc-12-20211031/gcc/ira.c:5932
0xc9c029 execute
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211031/work/gcc-12-20211031/gcc/ira.c:6118
[Bug ipa/103073] [12 Regression] ICE in insert_access, at ipa-modref-tree.h:578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103073 --- Comment #1 from Andrew Pinski --- >I'm not sure about the component. It is the correct one.
[Bug ipa/103073] [12 Regression] ICE in insert_access, at ipa-modref-tree.h:578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103073 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug ipa/103073] New: [12 Regression] ICE in insert_access, at ipa-modref-tree.h:578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103073
Bug ID: 103073
Summary: [12 Regression] ICE in insert_access, at
ipa-modref-tree.h:578
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: vsevolod.livinskij at frtk dot ru
CC: marxin at gcc dot gnu.org
Target Milestone: ---
I'm not sure about the component. Would you mind checking and fixing it in case
it is wrong?
Link to the Compiler Explorer: https://godbolt.org/z/K17Grnez9
Reproducer:
int a;
void b(bool c[], char d[], bool g[][55][21]) {
for (signed e = 0; e < 11; e += 3)
for (unsigned f = c[0] + 1; f < d[0]; f += 3)
a = g[0][e][f + 2];
}
Error:
>$ g++ -c func.cpp -O3
during GIMPLE pass: modref
func.cpp: In function 'void b(bool*, char*, bool (*)[55][21])':
func.cpp:2:6: internal compiler error: in insert_access, at
ipa-modref-tree.h:578
2 | void b(bool c[], char d[], bool g[][55][21]) {
| ^
0x103ae7a modref_ref_node::insert_access(modref_access_node, unsigned
long, bool)
/testing/gcc/gcc_src_master/gcc/ipa-modref-tree.h:578
0x103b16d modref_tree::insert(int, int, modref_access_node, bool)
/testing/gcc/gcc_src_master/gcc/ipa-modref-tree.h:848
0x102cafe record_access
/testing/gcc/gcc_src_master/gcc/ipa-modref.c:758
0x102d7ff analyze_load
/testing/gcc/gcc_src_master/gcc/ipa-modref.c:1262
0xf84246 walk_stmt_load_store_addr_ops(gimple*, void*, bool (*)(gimple*,
tree_node*, tree_node*, void*), bool (*)(gimple*, tree_node*, tree_node*,
void*), bool (*)(gimple*, tree_node*, tree_node*, void*))
/testing/gcc/gcc_src_master/gcc/gimple-walk.c:800
0x1034872 analyze_stmt
/testing/gcc/gcc_src_master/gcc/ipa-modref.c:1313
0x1034872 analyze_function
/testing/gcc/gcc_src_master/gcc/ipa-modref.c:2366
0x1035e21 execute
/testing/gcc/gcc_src_master/gcc/ipa-modref.c:3213
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
GCC version:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/testing/gcc/bin_master/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /testing/gcc/gcc_src_master/configure --enable-multilib
--prefix=/testing/gcc/bin_master --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211103 (62af7d9402f551fa708125fafed2950d8912b25e) (GCC)
[Bug middle-end/103071] Missed optimization for symmetric subset: (a & b) == a || (a & b) == b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103071 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug middle-end/85614] Documentation: -fdump-tree should mention "original"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85614 --- Comment #3 from Daniel Le --- Created attachment 51733 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51733=edit List -fdump-tree pass options that are no longer discoverable Here's the code again without any formatting issues that can be copy-pasted and run to list -fdump-tree pass options that are no longer discoverable.
[Bug middle-end/85614] Documentation: -fdump-tree should mention "original"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85614 --- Comment #2 from Daniel Le --- (In reply to Daniel Le from comment #1) > $ for i in $(!!); do \ > > if g++ -fdump-"$i" -S -o /dev/null a.cpp; then \ > > echo "$i: works."; \ > > else \ > > echo "$i: fails."; \ > > fi \ > > done !! should really be "ruby tree-passes-presence-in-fdump-passes-output.rb | ag -F 'no match' | cut -d ':' -f 1".
[Bug tree-optimization/103072] New: Folding common switch code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103072
Bug ID: 103072
Summary: Folding common switch code
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: llvm at rifkin dot dev
Target Milestone: ---
In the following code, GCC can optimize foo but not bar:
void foo(int x) {
switch(x) {
case 1: func1(); break;
case 2: func1(); break;
case 3: func1(); break;
case 4: func1(); break;
case 5: func1(); break;
default: __builtin_unreachable();
}
}
void bar(int x) {
switch(x) {
case 1: func2(x); break;
case 2: func2(x); break;
case 3: func2(x); break;
case 4: func2(x); break;
case 5: func2(x); break;
default: __builtin_unreachable();
}
}
https://godbolt.org/z/3eqnG71f5 (LLVM optimizes both)
[Bug middle-end/85614] Documentation: -fdump-tree should mention "original"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85614
Daniel Le Duc Khoi Nguyen changed:
What|Removed |Added
CC||greenrecyclebin at gmail dot
com
--- Comment #1 from Daniel Le Duc Khoi Nguyen ---
(In reply to krblock from comment #0)
> In the -fdump-tree option a "switch" is specified to select when you want
> the dump. To determine the "switch", it suggests "-fdump-passes" be used.
> However, this does not list "original" which is also a possible choice. This
> should be explicitly listed in the documentation. Not sure if there are
> other not listed "switches". Also the term "switch" is odd. "pass" might be
> a more intuitive name.
I noticed the same thing too. In other words, some options are no longer
discoverable after the changes in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32003#c8.
The below code lists the options that were previously documented but have since
become no longer discoverable:
$ g++ --version | head -n 1
g++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
$ ruby --version | head -n 1
ruby 2.7.0p0 (2019-12-25 revision 647ee6f091) [x86_64-linux-gnu]
$ touch a.cpp
$ cat <<'EOF' > tree-passes-presence-in-fdump-passes-output.rb
> all_passes = `g++ -S -fdump-passes -o /dev/null a.cpp 2>&1 > /dev/null`
>
> tree_passes =
> %w(split-paths original optimized gimple cfg ch ssa alias ccp storeccp pre
> fre
> copyprop store_copyprop dce sra sink dom dse phiopt backprop forwprop
> nrv vect
> slp vrp evrp oaccdevlow all)
>
> tree_passes.each do |pass|
> tree_pass = "tree-#{pass}"
>
> i = all_passes.index(tree_pass)
>
> print "#{tree_pass}: "
>
> if i
> next_char = all_passes[i + tree_pass.size]
>
> if next_char.match?('\d')
> puts 'prefix match (followed by a digit).'
> elsif next_char == ' '
> puts 'exact match.'
> else
> puts 'prefix match.'
> end
> else
> puts 'no match.'
> end
> end
> EOF
$ ruby tree-passes-presence-in-fdump-passes-output.rb | ag -F 'no match'
tree-original: no match.
tree-gimple: no match.
tree-storeccp: no match.
tree-store_copyprop: no match.
tree-all: no match.
$ for i in $(!!); do \
> if g++ -fdump-"$i" -S -o /dev/null a.cpp; then \
> echo "$i: works."; \
> else \
> echo "$i: fails."; \
> fi \
> done
tree-original: works.
tree-gimple: works.
cc1plus: error: unrecognized command line option ‘-fdump-tree-storeccp’
tree-storeccp: fails.
cc1plus: error: unrecognized command line option ‘-fdump-tree-store_copyprop’
tree-store_copyprop: fails.
tree-all: works.
Improvements:
1. Change "switch" to "pass" to be more accurate
2. Make default passes, e.g., tree-original (is this considered a pass?),
tree-gimple and tree-all (already documented) discoverable by:
2.1. Adding them in -fdump-passes output
2.2. Or documenting them explicitly
2.3. Or some other options?
I prefer 2.1. since it improves things in the direction set out in the previous
changes. Let me know your thoughts and I will consider submitting a patch.
Thank you.
[Bug c++/96780] debuginfo for std::move and std::forward isn't useful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96780 --- Comment #5 from Jonathan Wakely --- Yes, from a very quick test, it does exactly what I want. As discussed on IRC, we might not want to do this folding at -O0 (although I'd personally be happy with it unconditionally).
[Bug rtl-optimization/103071] New: Missed optimization for symmetric subset: (a & b) == a || (a & b) == b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103071
Bug ID: 103071
Summary: Missed optimization for symmetric subset: (a & b) == a
|| (a & b) == b
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: steinar+gcc at gunderson dot no
Target Milestone: ---
This is a bit of a long shot, but I'll file it anyway :-)
I have this function in a hot path (of course, in the real project, it's
inlined):
#include
#include
void foo();
void bar();
void EitherIsSubset(uint64_t v0, uint64_t v1) {
if ((v0 & v1) == v0 || (v0 & v1) == v1) {
foo();
} else {
bar();
}
}
It is intended to treat v0 and v1 as bit sets, and then test whether either v0
or v1 is a subset of each other (or that they are equal). (An equivalent
formulation happens to be replacing & with |.)
GCC compiles (with -O2, x86-64) this to:
EitherIsSubset:
movq%rdi, %rax
andq%rsi, %rax
cmpq%rsi, %rax
je .L4
cmpq%rdi, %rax
je .L4
xorl%eax, %eax
jmp bar@PLT
.L4:
xorl%eax, %eax
jmp foo@PLT
This is pretty straight-forward, but feels like it's using two (relatively
hard-to-predict) branches where it should be possible to deal with one. And
indeed, GNU superopt (!) found this amazing sequence instead, with v0 in eax
and v1 in edx (this is, of course, trivially portable to 64-bit):
14: mov %edx,%ecx
or %eax,%edx
cmp %edx,%eax
sbb %ebx,%ebx
sbb %ecx,%edx
adc $1,%ebx
I can't claim to understand fully what it does, but after this, ebx contains
either 0 or 1 with the right answer, and one would assume that after this, the
zero flag is also usable to branch on (leaving us with one branch instead of
two, in all).
Is it possible to teach GCC this sequence? I tried using it as inline
assembler, and while it works, it seems it becomes suboptimal and slower,
because I can't return a condition code (so I get a redundant test):
inline bool EitherIsSubsetAsm(uint64_t v0, uint64_t v1) {
uint64_t tmp = v0 | v1;
bool result;
asm("cmp %1, %2 ; sbb %0, %0 ; sbb %3, %1 ; adc $1, %0"
: "=r"(result), "+"(tmp)
: "r"(v0), "r"(v1)
: "cc");
return result;
}
void EitherIsSubset(uint64_t v0, uint64_t v1) {
if (EitherIsSubsetAsm(v0, v1)) {
foo();
} else {
bar();
}
}
[Bug middle-end/103070] [12 regression] ICE in gimple_call_static_chain_flags, at gimple.c:1669
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103070 Rainer Orth changed: What|Removed |Added Target Milestone|--- |12.0
[Bug middle-end/103070] New: [12 regression] ICE in gimple_call_static_chain_flags, at gimple.c:1669
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103070 Bug ID: 103070 Summary: [12 regression] ICE in gimple_call_static_chain_flags, at gimple.c:1669 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: hubicka at gcc dot gnu.org Target Milestone: --- Target: i386-pc-solaris2.11, sparc-sun-solaris2.11 Between 20211102 (c33a5cc9e7f1475108892abb147f9382ecbaec12) and 20211103 (600dcd74b8e614c996b492d97878660faf484094), gnat.dg/lto21.adb started to FAIL: +FAIL: gnat.dg/lto21.adb (internal compiler error) +FAIL: gnat.dg/lto21.adb (test for excess errors) Seen on Solaris 11/SPARC and x86 (32 and 64-bit). during GIMPLE pass: alias /var/gcc/regression/master/11.4-gcc/build/sparc-sun-solaris2.11/./libada/adainclude/a-cohama.adb: In function 'lto21_pkg2__proc__maps__reserve_capacity': /var/gcc/regression/master/11.4-gcc/build/sparc-sun-solaris2.11/./libada/adainclude/a-cohama.adb:1104:4: internal compiler error: in gimple_call_static_chain_flags, at gimple.c:1669 0x862a37 gimple_call_static_chain_flags(gcall const*) /vol/gcc/src/hg/master/local/gcc/gimple.c:1669 0xecc987 handle_rhs_call /vol/gcc/src/hg/master/local/gcc/tree-ssa-structalias.c:4258 0xed03a7 find_func_aliases_for_call /vol/gcc/src/hg/master/local/gcc/tree-ssa-structalias.c:4921 0xed03a7 find_func_aliases /vol/gcc/src/hg/master/local/gcc/tree-ssa-structalias.c:5024 0xed25cf compute_points_to_sets /vol/gcc/src/hg/master/local/gcc/tree-ssa-structalias.c:7440 0xed25cf compute_may_aliases() /vol/gcc/src/hg/master/local/gcc/tree-ssa-structalias.c:7948 0xb16b03 execute_function_todo /vol/gcc/src/hg/master/local/gcc/passes.c:2014 0xb17573 do_per_function /vol/gcc/src/hg/master/local/gcc/passes.c:1687 0xb1772b execute_todo /vol/gcc/src/hg/master/local/gcc/passes.c:2096 This was probably caused by commit a70c05120ae6f15f204a04a7df7d19941ab33ef1 Author: Jan Hubicka Date: Tue Nov 2 18:57:51 2021 +0100 Static chain support in ipa-modref
[Bug c++/96780] debuginfo for std::move and std::forward isn't useful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96780 --- Comment #4 from Patrick Palka --- Created attachment 51732 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51732=edit rough patch that folds calls to std::move/forward Does the attached rough patch help?
[Bug target/103069] cmpxchg isn't optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103069
--- Comment #1 from Thiago Macieira ---
(the assembly doesn't match the source code, but we got your point)
Another possible improvement for the __atomic_fetch_{and,nand,or} functions is
that it can check whether the fetched value is already correct and branch out.
In your example, the __atomic_fetch_or with 0x4000 can check if that bit is
already set and, if so, not execute the CMPXCHG at all.
This is a valid solution for x86 on memory orderings up to acq_rel. For other
architectures, they may still need barriers. For seq_cst, we either need a
barrier or we need to execute the CMPXCHG at least once.
Therefore, the emitted code might want to optimistically execute the operation
once and, if it fails, enter the load loop. That's a slightly longer codegen.
Whether we want that under -Os or not, you'll have to be the judge.
Prior art: glibc/sysdeps/x86_64/nptl/pthread_spin_lock.S:
ENTRY(__pthread_spin_lock)
1: LOCK
decl0(%rdi)
jne 2f
xor %eax, %eax
ret
.align 16
2: rep
nop
cmpl$0, 0(%rdi)
jg 1b
jmp 2b
END(__pthread_spin_lock)
This does the atomic operation once, hoping it'll succeed. If it fails, it
enters the PAUSE+CMP+JG loop until the value is suitable.
[Bug fortran/35276] Doc should described how to compile mixed-language programs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35276 sandra at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |sandra at gcc dot gnu.org --- Comment #9 from sandra at gcc dot gnu.org --- Well, it looks to me like we currently do not document exactly how to link mixed-language programs, although chapter 7 does cover related concepts like what you have to do to initialize libgfortran if you are linking e.g. a fortran library with a main in some other language. I think this topic does belong in chapter 7 and not any other part of the manual, and that we should not close it. I'll add it to my queue.
[Bug fortran/52274] [Meta-bug] Fortran translation related issues: Typos and more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52274 --- Comment #4 from Eric Gallager --- *** Bug 52279 has been marked as a duplicate of this bug. ***
[Bug fortran/52279] Fortran translation issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52279 Eric Gallager changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE CC||egallager at gcc dot gnu.org --- Comment #13 from Eric Gallager --- Closing as a dup of bug 52274 due to discussion in that bug *** This bug has been marked as a duplicate of bug 52274 ***
[Bug fortran/52274] [Meta-bug] Fortran translation related issues: Typos and more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52274
Eric Gallager changed:
What|Removed |Added
Depends on|52279 |38573, 52232, 52234, 52245,
||52246, 52262, 52273
Blocks|38573, 52232, 52234, 52245, |
|52246, 52262, 52273 |
CC||egallager at gcc dot gnu.org
--- Comment #3 from Eric Gallager ---
(In reply to Thomas Koenig from comment #2)
> (In reply to Eric Gallager from comment #1)
> > Are the "Depends on" and "Blocks" fields swapped here? Normally meta-bugs
> > depend on more bugs than they block
>
> Looks a bit confused, please rearrange if you think this is worth it.
Ok.
>
> Also, I am also not sure how this is different from 52279.
>
> Close either this or 52279 as duplicate?
I'll close 52279 as a duplicate of this, just to keep things in chronological
order.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38573
[Bug 38573] Missing markers for translation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52232
[Bug 52232] translatable string typos: "conindexed" (should be "coindexed")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52234
[Bug 52234] translatable string typo: "argument argument"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52245
[Bug 52245] translatable string: "Fortran F2003"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52246
[Bug 52246] translatable string typo: plural use ("one translatable objects")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52262
[Bug 52262] translatable string typos (3): "REAl"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52273
[Bug 52273] translatable string typo: "at at %L"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52279
[Bug 52279] Fortran translation issues
[Bug fortran/35276] Doc should described how to compile mixed-language programs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35276 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org, ||juergen.reuter at desy dot de, ||marxin at gcc dot gnu.org, ||sandra at gcc dot gnu.org --- Comment #8 from Eric Gallager --- Sandra Loosemore and Martin Liska have been discussing how to update the fortran docs on gcc-patches lately; cc-ing them
[Bug c++/103067] Tautological compare warning not appearing if the self-comparison is on object members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103067 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-11-03 Ever confirmed|0 |1 --- Comment #3 from Jonathan Wakely --- The warning could be smarter and assume that operator== has the usual semantics, and therefore 'age == age' would warn, even though *in theory* the operator== could do something meaningful when called like that. But in practice, warning would be helpful a lot more often than anybody writes weird operator== definitions where 'age == age' is actually what the developer meant to write. 99.999% of operator== functions do what you expect, and so 'age == age' is probably a mistake and should warn. Related to that, it would be nice if calls to operator== functions also gave -Wunused-value warnings, like the built-in == for scalars. Again, 99.999% of operator== functions have no side effects and are only called for the result, so if it's unused, the compiler should warn.
[Bug c++/70796] [DR 1030] Initialization order with braced-init-lists still broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70796
--- Comment #6 from Jakub Jelinek ---
cp_gimplify_expr uses for CALL_EXPR_REVERSE_ARGS and CALL_EXPR_ORDERED_ARGS
(and for !CALL_EXPR_OPERATOR_SYNTAX method calls) gimplify_arg, but that
clearly isn't enough once there are any TREE_SIDE_EFFECTS on any of the
arguments.
Because e.g. for the ++i, ++i arguments for scalar non-addressable VAR_DECL i,
we end up with:
i = i + 1;
i = i + 1;
C::C (, i, i);
which is wrong, is_gimple_val is true on i, but we really need to gimplify the
argument using gimplify_to_rvalue with is_gimple_val test if is_gimple_reg_type
(TREE_TYPE (arg)) and any of the args that are supposed to be evaluated after
it has TREE_SIDE_EFFECTS set.
That seems an easy change and would be (except for -O0) even cheap.
This would fix foo in the #c5 testcase.
bar works because i is addressable and thus gimplification already forces it
into SSA_NAME or temporary.
baz works because the (int &) casts also force
C::C (, *( ++i;, (int &) ), *( ++i;, (int &) ))
before gimplification, so it is again gimplified into SSA_NAMEs or temporaries.
But, qux needs some other fix.
B::B (, TARGET_EXPR ,
TARGET_EXPR )
The problem is that gimplify_arg optimizes:
/* In general, we allow lvalues for function arguments to avoid
extra overhead of copying large aggregates out of even larger
aggregates into temporaries only to copy the temporaries to
the argument list. Make optimizers happy by pulling out to
temporaries those types that fit in registers. */
if (is_gimple_reg_type (TREE_TYPE (*arg_p)))
test = is_gimple_val, fb = fb_rvalue;
else
{
test = is_gimple_lvalue, fb = fb_either;
/* Also strip a TARGET_EXPR that would force an extra copy. */
if (TREE_CODE (*arg_p) == TARGET_EXPR)
{
tree init = TARGET_EXPR_INITIAL (*arg_p);
if (init
&& !VOID_TYPE_P (TREE_TYPE (init)))
*arg_p = init;
}
}
where the stripping of the TARGET_EXPR avoids the copy that is needed.
So perhaps add some ordered argument to gimplify_arg, in calls from gimplify.c
pass false, and in calls from cp_gimplify_expr pass true if the current
argument in the desired evaluation order is followed by any TREE_SIDE_EFFECTS
arguments.
[Bug c++/101906] Constant evaluation failure in concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101906
Patrick Palka changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
CC||ppalka at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2021-11-03
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
--- Comment #1 from Patrick Palka ---
Reduced rejects-valid C++20 testcase:
template using voidify = void;
template
concept constant_value_initializable
= requires { typename voidify<(T(), 0)>; };
struct bar {
int x = -1;
};
static_assert(constant_value_initializable);
Started with r10-3735 aka the C++20 concepts merge.
[Bug target/103069] New: cmpxchg isn't optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103069
Bug ID: 103069
Summary: cmpxchg isn't optimized
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com, wwwhhhyyy333 at gmail dot com
Blocks: 103065
Target Milestone: ---
Target: i386,x86-64
>From the CPU's point of view, getting a cache line for writing is more
expensive than reading. See Appendix A.2 Spinlock in:
https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/xeon-lock-scaling-analysis-paper.pdf
The full compare and swap will grab the cache line exclusive and causes
excessive cache line bouncing.
[hjl@gnu-cfl-2 pr102566]$ cat e.c
int
f3 (int *a)
{
return __atomic_fetch_or (a, 0x4000, __ATOMIC_RELAXED);
}
[hjl@gnu-cfl-2 pr102566]$ gcc -S -O2 x.c
[hjl@gnu-cfl-2 pr102566]$ cat x.s
.file "x.c"
.text
.p2align 4
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
movlv(%rip), %eax
.L2:
movl%eax, %ecx
movl%eax, %edx
orl $1, %ecx
lock cmpxchgl %ecx, v(%rip)
GCC should first emit a normal load, check and jump to .L2 if cmpxchgl
may fail. Before jump to .L2, PAUSE should be inserted to to yield the
CPU to another hyperthread and to save power. It also serves to slightly
limit the rate of accesses on the processor interconnect.
jne .L2
movl%edx, %eax
andl$1, %eax
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.ident "GCC: (GNU) 11.2.1 20211019 (Red Hat 11.2.1-6)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-2 pr102566]$
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103065
[Bug 103065] [meta] atomic operations aren't optimized
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 82110, which changed state. Bug 82110 Summary: Concept for default constructing works with new T, not with new T[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82110 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/82110] Concept for default constructing works with new T, not with new T[1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82110 Patrick Palka changed: What|Removed |Added Target Milestone|--- |12.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Patrick Palka --- Fixed only for GCC 12, seems a little too risky to backport..
[Bug c++/102479] segfault when deducing class template arguments for tuple with libc++-14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102479 Patrick Palka changed: What|Removed |Added CC||kimhappy at hanyang dot ac.kr --- Comment #4 from Patrick Palka --- *** Bug 98475 has been marked as a duplicate of this bug. ***
[Bug c++/98475] Class template argument deduction for alias templates fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98475 Patrick Palka changed: What|Removed |Added Resolution|--- |DUPLICATE CC||ppalka at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #2 from Patrick Palka --- This is a dup of the recently fixed PR102479 it seems *** This bug has been marked as a duplicate of bug 102479 ***
[Bug c++/70796] [DR 1030] Initialization order with braced-init-lists still broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70796
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
#c3 in a single testcase without headers:
struct A
{
int x = 0;
A & operator ++ () { ++x; return *this; }
};
struct B
{
A first, second;
B (A x, A y) : first{x}, second{y} {}
};
struct C
{
int first, second;
C (int x, int y) : first{x}, second{y} {}
};
void
foo ()
{
int i = 0;
C p{++i, ++i};
if (p.first != 1 || p.second != 2)
__builtin_abort ();
}
void
bar ()
{
int i = 0;
C p{++i, ++i};
if (p.first != 1 || p.second != 2)
__builtin_abort ();
int = i;
C q{++j, ++j};
if (q.first != 3 || q.second != 4)
__builtin_abort ();
}
void
baz ()
{
int i = 0;
C p{(int &) ++i, (int &) ++i};
if (p.first != 1 || p.second != 2)
__builtin_abort ();
}
void
qux ()
{
A i;
B p{++i, ++i};
if (p.first.x != 1 || p.second.x != 2)
__builtin_abort ();
}
int
main ()
{
bar ();
baz ();
foo ();
qux ();
}
Passes with clang++.
Looking at the CALL, e.g. on C::C (, ++i, ++i) call CALL_EXPR_ORDERED_ARGS
is set and neither CALL_EXPR_REVERSE_ARGS nor CALL_EXPR_OPERATOR_SYNTAX is set.
[Bug c++/101219] [12 Regression] ice in perform_or_defer_access_check since r12-1804-g65870e75616ee435
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101219 Patrick Palka changed: What|Removed |Added Target Milestone|--- |12.0 CC||ppalka at gcc dot gnu.org
[Bug libgomp/103068] New: gomp_mutex_lock_slow isn't optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103068
Bug ID: 103068
Summary: gomp_mutex_lock_slow isn't optimized
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com, jakub at gcc dot gnu.org,
wwwhhhyyy333 at gmail dot com
Target Milestone: ---
Target: i386,x86-64
>From the CPU's point of view, getting a cache line for writing is more
expensive than reading. See Appendix A.2 Spinlock in:
https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/xeon-lock-scaling-analysis-paper.pdf
The full compare and swap will grab the cache line exclusive and causes
excessive cache line bouncing.
gomp_mutex_lock_slow has
void
gomp_mutex_lock_slow (gomp_mutex_t *mutex, int oldval)
{
/* First loop spins a while. */
while (oldval == 1)
{
if (do_spin (mutex, 1))
{
/* Spin timeout, nothing changed. Set waiting flag. */
oldval = __atomic_exchange_n (mutex, -1, MEMMODEL_ACQUIRE);
if (oldval == 0)
return;
futex_wait (mutex, -1);
break;
}
else
{
/* Something changed. If now unlocked, we're good to go. */
oldval = 0;
Add a normal check for *mutex == 1 and continue if
__atomic_compare_exchange_n may fail.
if (__atomic_compare_exchange_n (mutex, , 1, false,
MEMMODEL_ACQUIRE, MEMMODEL_RELAXED))
return;
}
}
/* Second loop waits until mutex is unlocked. We always exit this
loop with wait flag set, so next unlock will awaken a thread. */
while ((oldval = __atomic_exchange_n (mutex, -1, MEMMODEL_ACQUIRE)))
do_wait (mutex, -1);
}
[Bug c++/100102] [9 Regression] ICE in tsubst, at cp/pt.c:15310
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100102 Patrick Palka changed: What|Removed |Added CC||henrik.nortamo at csc dot fi --- Comment #27 from Patrick Palka --- *** Bug 100737 has been marked as a duplicate of this bug. ***
[Bug c++/100737] g++ segfaults in template substitution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100737 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Patrick Palka --- dup *** This bug has been marked as a duplicate of bug 100102 ***
[Bug c++/100739] Definition of function template doesn't match declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100739
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #1 from Patrick Palka ---
Reduced C++11 rejects-valid testcase:
template struct array { };
template
using debug_t = T;
template
struct X {
auto f(T i) -> array>;
};
template
auto X::f(T i) -> array> {
return {};
};
Not a regression AFAICT
[Bug c++/102876] GCC fails to use constant initialization even when it knows the value to initialize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102876
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Status|NEW |ASSIGNED
--- Comment #15 from Jakub Jelinek ---
Created attachment 51731
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51731=edit
gcc12-pr102876.patch
Untested implementation of the optimization.
So far a little bit limited, either it handles initialization of the whole var
at once (usually scalar vars), or uses native_{encode,interpret}*
infrastructure
and in that case it can't handle unions or anything that needs relocations in
the initializers. I guess in some cases it could be improved, but especially
unions can be harder or very hard if the access path is not visible in the
stores.
[Bug c++/103067] Tautological compare warning not appearing if the self-comparison is on object members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103067
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #2 from Jonathan Wakely ---
This is "correct" in that each function is compiled in isolation, and within
the body of the function you are comparing two different objects, this->a and
rhs.a
The fact that rhs and *this actually alias each other **in your specific
example** is not visible when compiling that function (and is not always going
to be true for other alls to the function).
You'll get just the same for something like:
bool f(int& i, int& j) { return i == j; }
int i = 0;
bool b = f(i, i);
[Bug c++/100557] [concepts] Internal compiler error: Error reporting routines re-entered.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100557 Patrick Palka changed: What|Removed |Added Blocks||67491 Ever confirmed|0 |1 CC||ppalka at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2021-11-03 Summary|[ICE] Internal compiler |[concepts] Internal |error: Error reporting |compiler error: Error |routines re-entered.|reporting routines ||re-entered. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 [Bug 67491] [meta-bug] concepts issues
[Bug c++/103067] Tautological compare warning not appearing if the self-comparison is on object members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103067 --- Comment #1 from crillion at tiscali dot it --- in object_member the comparison operator signature is bool operator==(const object_member& rhs) const
[Bug c++/103067] New: Tautological compare warning not appearing if the self-comparison is on object members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103067
Bug ID: 103067
Summary: Tautological compare warning not appearing if the
self-comparison is on object members
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: crillion at tiscali dot it
Target Milestone: ---
Hi,
I've found that on gcc 11.2 (tested on windows 10, with msys2), and
compiling with :
g++ -std=c++20 -pedantic -Wall -Wextra -Werror=return-type -Wshadow=local
-Wempty-body -fdiagnostics-color -s -Os program.cpp -o program_gpp.exe
-LC:/programs/msys64/mingw64/lib
(I have also tried adding -Wtautological-compare but with the same effect
described below).
if I have a code with a struct person that in operator== erroneously compares
one of its members, of an object type, with itself as in the following example
:
// this is a struct for field members, here comparison is implemented correctly
struct object_member
{
int a = 20;
bool operator==(const m& rhs) const
{
return a == rhs.a;
}
};
// this struct has the error in the operator==
struct person
{
bool operator==(const person& rhs) const
{
// comparing this instance member with itself!
return age == age; // instead of age == rhs.age
}
object_member age;
};
int main()
{
person p1, p2;
if(p1 == p2) std::cout << "equal!\n";
}
I don't get the tautological compare warning. The behavior seems to occur only
with struct/class types (also with string and optional), but not with primitive
numeric types (i.e. : if age is an int, I get normally the tautological-compare
warning. It occurs also if the expression is in AND with other correct
comparisons. The causing part seems to be an operator== involving an object
member (struct, class) compared with itself.
In case of a single member I get instead the warning "rhs parameter not used",
but if I add to the struct and comparison another field (ex.: int a), comparing
it correctly, no warning shows at all:
(...)
operator==(const person& rhs)
{
return a == rhs.a && age == age;
}
(...)
int a = 0;
object_member age;
(...)
Is this correct ? or should I get this important warning also if the member is
an object ?
Note : I see clang 11.0 does not issue the warning either.
Thanks,
Marco
[Bug rtl-optimization/102842] [10/11/12 Regression] ICE in cselib_record_set at -O2 or greater
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102842 --- Comment #16 from CVS Commits --- The releases/gcc-10 branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:b7faffdb05aea6448b62b5d3b13009fc68dd103b commit r10-10251-gb7faffdb05aea6448b62b5d3b13009fc68dd103b Author: Vladimir N. Makarov Date: Tue Oct 26 14:03:42 2021 -0400 [PR102842] Consider all outputs in generation of matching reloads Without considering all output insn operands (not only processed before), in rare cases LRA can use the same hard register for different outputs of the insn on different assignment subpasses. The patch fixes the problem. gcc/ChangeLog: PR rtl-optimization/102842 * lra-constraints.c (match_reload): Ignore out in checking values of outs. (curr_insn_transform): Collect outputs before doing reloads of operands. gcc/testsuite/ChangeLog: PR rtl-optimization/102842 * g++.target/arm/pr102842.C: New test.
[Bug rtl-optimization/102842] [10/11/12 Regression] ICE in cselib_record_set at -O2 or greater
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102842 --- Comment #15 from CVS Commits --- The releases/gcc-11 branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:41bea618a77dca8c1c13a3d7b883976a25d83373 commit r11-9202-g41bea618a77dca8c1c13a3d7b883976a25d83373 Author: Vladimir N. Makarov Date: Tue Oct 26 14:03:42 2021 -0400 [PR102842] Consider all outputs in generation of matching reloads Without considering all output insn operands (not only processed before), in rare cases LRA can use the same hard register for different outputs of the insn on different assignment subpasses. The patch fixes the problem. gcc/ChangeLog: PR rtl-optimization/102842 * lra-constraints.c (match_reload): Ignore out in checking values of outs. (curr_insn_transform): Collect outputs before doing reloads of operands. gcc/testsuite/ChangeLog: PR rtl-optimization/102842 * g++.target/arm/pr102842.C: New test.
[Bug target/103066] New: __sync_val_compare_and_swap/__sync_bool_compare_and_swap aren't optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103066
Bug ID: 103066
Summary: __sync_val_compare_and_swap/__sync_bool_compare_and_sw
ap aren't optimized
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com, wwwhhhyyy333 at gmail dot com
Blocks: 103065
Target Milestone: ---
Target: i386,x86-64
>From the CPU's point of view, getting a cache line for writing is more
expensive than reading. See Appendix A.2 Spinlock in:
https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/xeon-lock-scaling-analysis-paper.pdf
The full compare and swap will grab the cache line exclusive and causes
excessive cache line bouncing.
[hjl@gnu-cfl-1 tmp]$ cat x.c
extern int m;
int test(int oldv, int newv)
{
return __sync_val_compare_and_swap (, oldv, newv);
}
[hjl@gnu-cfl-1 tmp]$ gcc -S -O2 x.c
[hjl@gnu-cfl-1 tmp]$ cat x.s
.file "x.c"
.text
.p2align 4
.globl test
.type test, @function
test:
.LFB0:
.cfi_startproc
movl%edi, %eax
lock cmpxchgl %esi, m(%rip)
GCC should first emit a normal load, check and return immediately if cmpxchgl
may fail.
ret
.cfi_endproc
.LFE0:
.size test, .-test
.ident "GCC: (GNU) 11.2.1 20211019 (Red Hat 11.2.1-6)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-1 tmp]$
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103065
[Bug 103065] [meta] atomic operations aren't optimized
[Bug libgcc/103004] [12 regression] r12-4416 breaks backtrace on PPC64 Big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103004 David Edelsohn changed: What|Removed |Added CC||dje at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2021-11-03 Status|UNCONFIRMED |NEW --- Comment #1 from David Edelsohn --- Confirmed.
[Bug tree-optimization/103062] [12 Regression] ICE: SIGSEGV in gimple_simplify_CONVERT_EXPR with -O2 -fno-tree-forwprop since r12-4694-gcb153222404e2e14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103062 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||amacleod at redhat dot com, ||marxin at gcc dot gnu.org Target Milestone|--- |12.0 Summary|[12 Regression] ICE:|[12 Regression] ICE: |SIGSEGV in |SIGSEGV in |gimple_simplify_CONVERT_EXP |gimple_simplify_CONVERT_EXP |R with -O2 |R with -O2 |-fno-tree-forwprop |-fno-tree-forwprop since ||r12-4694-gcb153222404e2e14 Last reconfirmed||2021-11-03 --- Comment #1 from Martin Liška --- Confirmed, started with r12-4694-gcb153222404e2e14.
[Bug ipa/103058] [12 Regression] ICE in gimple_call_static_chain_flags, at gimple.c:1669 when building 527.cam4_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103058 --- Comment #3 from Andrew Pinski --- (In reply to Martin Liška from comment #2) > It's a fortran benchmark where I was able to reduce it to 4 object files: > radae.fppized.o quicksort.fppized.o radlw.fppized.o radsw.fppized.o Hmm, this would mean the nested function might be split into a different object file.
[Bug tree-optimization/103063] [9/10/11/12 Regression] Wrong code while using -O3 since r7-2373-g69b806f6a60efcf1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103063 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.5 Summary|Wrong code while using -O3 |[9/10/11/12 Regression] |since |Wrong code while using -O3 |r7-2373-g69b806f6a60efcf1 |since ||r7-2373-g69b806f6a60efcf1
[Bug target/103065] New: [meta] atomic operations aren't optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103065 Bug ID: 103065 Summary: [meta] atomic operations aren't optimized Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: meta-bug Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: crazylht at gmail dot com, wwwhhhyyy333 at gmail dot com Target Milestone: --- Target: i386,x86-64 >From the CPU's point of view, getting a cache line for writing is more expensive than reading. See Appendix A.2 Spinlock in: https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/xeon-lock-scaling-analysis-paper.pdf The full compare and swap will grab the cache line exclusive and causes excessive cache line bouncing.
[Bug tree-optimization/103063] Wrong code while using -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103063 Martin Liška changed: What|Removed |Added CC||amker at gcc dot gnu.org, ||marxin at gcc dot gnu.org Last reconfirmed||2021-11-03 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=100499 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords||wrong-code --- Comment #1 from Martin Liška --- Started with r7-2373-g69b806f6a60efcf1.
[Bug tree-optimization/102988] ICE with -fharden-conditional-branches and C++ and pass by reference return value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102988 Andrew Pinski changed: What|Removed |Added CC||zsojka at seznam dot cz --- Comment #3 from Andrew Pinski --- *** Bug 103064 has been marked as a duplicate of this bug. ***
[Bug middle-end/103064] ICE: verify_ssa failed: RESULT_DECL should be read only when DECL_BY_REFERENCE is set with -fharden-conditional-branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103064 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 102988. *** This bug has been marked as a duplicate of bug 102988 ***
[Bug ipa/103058] [12 Regression] ICE in gimple_call_static_chain_flags, at gimple.c:1669 when building 527.cam4_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103058 --- Comment #2 from Martin Liška --- It's a fortran benchmark where I was able to reduce it to 4 object files: radae.fppized.o quicksort.fppized.o radlw.fppized.o radsw.fppized.o
[Bug middle-end/103064] New: ICE: verify_ssa failed: RESULT_DECL should be read only when DECL_BY_REFERENCE is set with -fharden-conditional-branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103064
Bug ID: 103064
Summary: ICE: verify_ssa failed: RESULT_DECL should be read
only when DECL_BY_REFERENCE is set with
-fharden-conditional-branches
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Created attachment 51730
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51730=edit
reduced testcase
Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -fharden-conditional-branches -fno-tree-pta
testcase.C
testcase.C: In function 'S f()':
testcase.C:14:3: error: RESULT_DECL should be read only when DECL_BY_REFERENCE
is set
14 | S f() {
| ^
while verifying SSA_NAME s_7 in statement
__asm__("" : "=g" s_7 : "0" s_2(D));
during GIMPLE pass: hardcbr
testcase.C:14:3: internal compiler error: verify_ssa failed
0x184ac8f verify_ssa(bool, bool)
/repo/gcc-trunk/gcc/tree-ssa.c:1212
0x1517c3d execute_function_todo
/repo/gcc-trunk/gcc/passes.c:2049
0x151857b execute_todo
/repo/gcc-trunk/gcc/passes.c:2096
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-4872-20211103145922-g600dcd74b8e-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r12-4872-20211103145922-g600dcd74b8e-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20211103 (experimental) (GCC)
[Bug libstdc++/66742] abort on sorting list with custom allocator that is not stateless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66742 --- Comment #19 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:1e7a269856fd67aff78ac874bec96d31a54b2fd9 commit r12-4873-g1e7a269856fd67aff78ac874bec96d31a54b2fd9 Author: Jonathan Wakely Date: Tue Nov 2 10:21:01 2021 + libstdc++: Fix regression in std::list::sort [PR66742] The standard does not require const-correct comparisons in list::sort. libstdc++-v3/ChangeLog: PR libstdc++/66742 * include/bits/list.tcc (list::sort): Use mutable iterators for comparisons. * include/bits/stl_list.h (_Scratch_list::_Ptr_cmp): Likewise. * testsuite/23_containers/list/operations/66742.cc: Check non-const comparisons.
[Bug libstdc++/102962] shared locks / mutexes differ between linux and windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102962 --- Comment #4 from Jonathan Wakely --- FWIW, POSIX says this for its equivalent of lock_shared: If the Thread Execution Scheduling option is not supported, it is implementation-defined whether the calling thread acquires the lock when a writer does not hold the lock and there are writers blocked on the lock. https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_rwlock_rdlock.html The C++ proposals for shared mutex said: An implementation is strongly encouraged to block other threads requesting shared ownership while this thread is blocked waiting for exclusive ownership, lest the blocked thread be starved by readers. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3568.html However, that was for the upgrade lock functionality, which never made it into the standard. The final wording for shared_mutex (and shared_timed_mutex) do not even have that encouragement.
[Bug libstdc++/102962] shared locks / mutexes differ between linux and windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102962 --- Comment #3 from Jonathan Wakely --- (In reply to Marco Mengelkoch from comment #2) > I would understand if just the order is different or if one is much faster > than the other. We have two completely different implementations of std::shared_mutex, one based on pthread_rwlock_t and one based on std::condition_variable. That they have different ordering and queueing behaviour is not surprising. > While I would prefer the behavior of windows, it seems that the > documentation doesn't look accurate for windows > > > // https://en.cppreference.com/w/cpp/thread/shared_mutex > > If one thread has acquired the shared lock (through lock_shared, > > try_lock_shared), no other thread can acquire the exclusive lock, but can > > acquire the shared lock. If we read "but can acquire the shared lock" as being unconditional, i.e. even if there is a blocking call to lock() to acquire an exclusive lock, then that means that readers (shared locks) are given priority over writers (exclusive locks). https://en.wikipedia.org/wiki/Readers%E2%80%93writer_lock#Priority_policies > On windows, no shared lock can be acquired anymore once a UniqueLock > requested a lock. That means that writers (exclusive locks) are given priority over readers (shared locks). But as far as I can tell the C++ standard does not specify or guarantee either behaviour, so both are valid. To be portable your code should not assume that shared locks get priority over exclusive locks, or vice versa.
[Bug c/103056] attribute access "none" is not ignored as it should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103056
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords||diagnostic
Last reconfirmed||2021-11-03
Ever confirmed|0 |1
CC||mpolacek at gcc dot gnu.org
--- Comment #1 from Martin Sebor ---
I don't think -Wignored-attributes was ever meant to suppress errors for
invalid specifications of known attributes. The documentation sounds like it
should but the change that introduced it, r234433, makes it clear that the
option's effect is limited to just a single C++ warning. Below is a test case
showing errors for other attributes that can't be suppressed by the either
option.
At a minimum, the documentation of the option should be updated to reflect that
(i.e., that it's a C++ warning for templates). At the same time, having just
one option (-Wattributes) control all aspects of attribute validation isn't
good enough as users have occasionally asked for finer-grained control. So it
might be useful to extend -Wignored-attributes to other attributes and
situations (and to C as well).
So confirmed.
$ cat pr103056.c && gcc -S -Wall -Wno-attributes -Wno-ignored-attributes
pr103056.c
__attribute__ ((access (none, 1))) int foo (const void *);
__attribute__ ((alias ("foo"))) int bar (const void *);
__attribute__ ((weakref)) int bar (const void *);
void baz (void)
{
int i __attribute__ ((section ("foobar"))) = 0;
(void)
}
pr103056.c:1:1: error: attribute ‘access’ invalid mode ‘none’; expected one of
‘read_only’, ‘read_write’, or ‘write_only’
1 | __attribute__ ((access (none, 1))) int foo (const void *);
| ^
pr103056.c:3:37: error: ‘weakref’ symbol ‘bar’ must have static linkage
3 | __attribute__ ((alias ("foo"))) int bar (const void *);
| ^~~
pr103056.c: In function ‘baz’:
pr103056.c:8:7: error: section attribute cannot be specified for local
variables
8 | int i __attribute__ ((section ("foobar"))) = 0;
| ^
[Bug libstdc++/59675] -D_GLIBCXX_DEBUG asserts to stdout (it should stderr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59675 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |12.0 Keywords||patch --- Comment #9 from Jonathan Wakely --- Patch available now: https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582682.html
[Bug tree-optimization/103063] New: Wrong code while using -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103063
Bug ID: 103063
Summary: Wrong code while using -O3
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: stefansf at linux dot ibm.com
Target Milestone: ---
int a = 0;
unsigned char b = 0;
int main() {
a - 6;
for (; a >= -13; a = a - 8)
while((unsigned char)(b-- * 6))
;
if (b != 127)
__builtin_abort();
return 0;
}
Running the example while compiled with -O{0,1,2} works fine whereas it fails
with -O{3,fast} using gcc-12-4860-g73658e70d9e. Couldn't find a good commit so
far. Fails on IBM Z as well as x64.
Still not sure where it fails. ifcvt looks good to me.
[Bug tree-optimization/103062] New: [12 Regression] ICE: SIGSEGV in gimple_simplify_CONVERT_EXPR with -O2 -fno-tree-forwprop
691==at 0x48413EF: operator new[](unsigned long) (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==10691==by 0x165365F: pointer_equiv_analyzer::pointer_equiv_analyzer(gimple_ranger*) (value-pointer-equiv.cc:118) ==10691==by 0x161A16A: rvrp_folder (tree-vrp.c:4269) ==10691==by 0x161A16A: execute_ranger_vrp(function*, bool) (tree-vrp.c:4348) ==10691==by 0x124343C: execute_one_pass(opt_pass*) (passes.c:2567) ==10691==by 0x1243CAF: execute_pass_list_1(opt_pass*) (passes.c:2656) ==10691==by 0x1243CC1: execute_pass_list_1(opt_pass*) (passes.c:2657) ==10691==by 0x1243CE8: execute_pass_list(function*, opt_pass*) (passes.c:2667) ==10691==by 0x124461C: do_per_function_toporder(void (*)(function*, void*), void*) [clone .part.0] (passes.c:1773) ==10691==by 0x124481E: do_per_function_toporder (passes.c:1740) ==10691==by 0x124481E: execute_ipa_pass_list(opt_pass*) (passes.c:3001) ==10691==by 0xE86C6E: ipa_passes (cgraphunit.c:2154) ==10691==by 0xE86C6E: symbol_table::compile() [clone .part.0] (cgraphunit.c:2289) ==10691==by 0xE89767: compile (cgraphunit.c:2269) ==10691==by 0xE89767: symbol_table::finalize_compilation_unit() (cgraphunit.c:2537) ==10691==by 0x134CF4A: compile_file() (toplev.c:477) ==10691== during GIMPLE pass: evrp testcase.c: In function 'foo': testcase.c:4:1: internal compiler error: in operator[], at vec.h:889 4 | } | ^ 0x7f91ec vec::operator[](unsigned int) /repo/gcc-trunk/gcc/vec.h:889 0x7f92f6 vec::operator[](unsigned int) /repo/gcc-trunk/gcc/value-pointer-equiv.cc:132 0x7f92f6 vec::operator[](unsigned int) const /repo/gcc-trunk/gcc/vec.h:1486 0x7f92f6 ssa_equiv_stack::get_replacement(tree_node*) const /repo/gcc-trunk/gcc/value-pointer-equiv.cc:112 0x7f92f6 pointer_equiv_analyzer::get_equiv(tree_node*) const /repo/gcc-trunk/gcc/value-pointer-equiv.cc:154 0x165381e pta_valueize /repo/gcc-trunk/gcc/value-pointer-equiv.cc:242 0x185a185 do_valueize(tree_node* (*)(tree_node*), tree_node*) /repo/gcc-trunk/gcc/gimple-match-head.c:1105 0x185a185 do_valueize(tree_node* (*)(tree_node*), tree_node*) /repo/gcc-trunk/gcc/gimple-match-head.c:1101 0x185a185 gimple_simplify_CONVERT_EXPR /repo/build-gcc-trunk-amd64/gcc/gimple-match.c:29983 0x17e6e92 gimple_resimplify1 /repo/gcc-trunk/gcc/gimple-match-head.c:244 0x1011499 gimple_fold_stmt_to_constant_1(gimple*, tree_node* (*)(tree_node*), tree_node* (*)(tree_node*)) /repo/gcc-trunk/gcc/gimple-fold.c:7350 0x1653930 pointer_equiv_analyzer::visit_stmt(gimple*) /repo/gcc-trunk/gcc/value-pointer-equiv.cc:269 0x14ffd74 substitute_and_fold_dom_walker::before_dom_children(basic_block_def*) /repo/gcc-trunk/gcc/tree-ssa-propagate.c:803 0x21c3b87 dom_walker::walk(basic_block_def*) /repo/gcc-trunk/gcc/domwalk.c:309 0x14fee95 substitute_and_fold_engine::substitute_and_fold(basic_block_def*) /repo/gcc-trunk/gcc/tree-ssa-propagate.c:987 0x161a17b execute_ranger_vrp(function*, bool) /repo/gcc-trunk/gcc/tree-vrp.c:4349 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-4872-20211103145922-g600dcd74b8e-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r12-4872-20211103145922-g600dcd74b8e-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.0 20211103 (experimental) (GCC)
[Bug c++/102670] Erroneous "missing template arguments" message for wrapper of ADL function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102670 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-11-03 --- Comment #1 from Patrick Palka --- Confirmed.
[Bug c/103031] [12 Regression] Missing static initializer folding with -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103031 Joseph S. Myers changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Joseph S. Myers --- Fixed for GCC 12.
[Bug c/103031] [12 Regression] Missing static initializer folding with -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103031 --- Comment #3 from CVS Commits --- The master branch has been updated by Joseph Myers : https://gcc.gnu.org/g:600dcd74b8e614c996b492d97878660faf484094 commit r12-4872-g600dcd74b8e614c996b492d97878660faf484094 Author: Joseph Myers Date: Wed Nov 3 14:58:25 2021 + c: Fold implicit integer-to-floating conversions in static initializers with -frounding-math [PR103031] Recent fixes to avoid inappropriate folding of some conversions to floating-point types with -frounding-math also prevented such folding in C static initializers, when folding (in the default rounding mode, exceptions discarded) is required for correctness. Folding for static initializers is handled via functions in fold-const.c calling START_FOLD_INIT and END_FOLD_INIT to adjust flags such as flag_rounding_math that should not apply in static initializer context, but no such function was being called for the folding of these implicit conversions to the type of the object being initialized, only for explicit conversions as part of the initializer. Arrange for relevant folding (a fold call in convert, in particular) to use this special initializer handling (via a new fold_init function, in particular). Because convert is used by language-independent code but defined in each front end, this isn't as simple as just adding a new default argument to it. Instead, I added a new convert_init function; that then gets called by c-family code, and C and C++ need convert_init implementations (the C++ one does nothing different from convert and will never actually get called because the new convert_and_check argument will never be true from C++), but other languages don't. Bootstrapped with no regressions for x86_64-pc-linux-gnu. gcc/ PR c/103031 * fold-const.c (fold_init): New function. * fold-const.h (fold_init): New prototype. gcc/c-family/ PR c/103031 * c-common.c (convert_and_check): Add argument init_const. Call convert_init if init_const. * c-common.h (convert_and_check): Update prototype. (convert_init): New prototype. gcc/c/ PR c/103031 * c-convert.c (c_convert): New function, based on convert. (convert): Make into wrapper of c_convert. (convert_init): New function. * c-typeck.c (enum impl_conv): Add ic_init_const. (convert_for_assignment): Handle ic_init_const like ic_init. Add new argument to convert_and_check call. (digest_init): Pass ic_init_const to convert_for_assignment for initializers required to be constant. gcc/cp/ PR c/103031 * cvt.c (convert_init): New function. gcc/testsuite/ PR c/103031 * gcc.dg/init-rounding-math-1.c: New test.
[Bug ipa/103055] [12 Regression] ICE: in get_ssa_name_flags, at ipa-modref.c:1660 with --param=modref-max-depth=0 since r12-4852-g18f0873d1e595dc2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103055 --- Comment #2 from hubicka at kam dot mff.cuni.cz --- > Confirmed, started with r12-4852-g18f0873d1e595dc2. Depth=0 means that we do no analysis at all and the assert test that some analysis was done. I suppose we could ignore depth 0 and start bouding recursion only for depth 1 and more. I will implement that. Honza
[Bug ipa/103058] [12 Regression] ICE in gimple_call_static_chain_flags, at gimple.c:1669 when building 527.cam4_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103058 --- Comment #1 from hubicka at kam dot mff.cuni.cz --- > One can see it with -O2 -flto=auto -march=znver2: > > radsw.fppized.f90:39:19: internal compiler error: in > gimple_call_static_chain_flags, at gimple.c:1669 >39 | subroutine radcswmx(lchnk ,ncol, & > | ^ > 0x6a0183 gimple_call_static_chain_flags(gcall const*) > /home/marxin/Programming/gcc/gcc/gimple.c:1669 Interesting, I added the check to verify that we do not produce interposable calls to nested functions. Doing so does not make very good sense since they do not have stable API, so they can not really be called cross-module. What is a motivation to produce them at first place? Honza
[Bug tree-optimization/102943] [12 Regression] Jump threader compile-time hog with 521.wrf_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943 --- Comment #14 from rguenther at suse dot de --- On Wed, 3 Nov 2021, amacleod at redhat dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943 > > --- Comment #13 from Andrew Macleod --- > > > > > > > > This is a large CFG, so a linear search of a BB, is bound to be slow. > > > > Indeed, vec should never have gotten ::contains () ... I'd have > > used a regular bitmap, not sbitmap, because we do > > > > bb = m_update_list.pop (); > > > > and bitmap_first_set_bit is O(n) for an sbitmap bit O(1) for a bitmap. > > > > If we replaced the current vector with just the bitmap implementation, then > this would be the ideal way to do it. > > However, the propagation engine is suppose to call add_to_update in a (mostly) > breadth-first way so that changes being pushed minimize turmoil. As I look > closer, I see that this code doesn't really end up doing that properly now > anyway. I'll do some experiments and either fix the current code to do > breadth > right, or just switch to the bitmap solution you suggest which will then be > quasi-random. In other places we use one level indirection when we want to visit in a particular CFG order. We have a mapping bb-index to CFG-order and a back-mapping CFG-order to bb-index, then the bitmap is set up to contain CFG-order[bb_index] and the bitmap_first_set_bit result is indirected via bb_index[CFG-order]. That gives the desired ordering of the bitmap based worklist at the expense of two int->int maps.
[Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061 --- Comment #2 from Martin Liška --- There's dump file diff (search for 'dbgcnt'): https://gist.github.com/marxin/7eadc43d12fdefac6f5b8151a47a8684
[Bug tree-optimization/102943] [12 Regression] Jump threader compile-time hog with 521.wrf_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943 --- Comment #13 from Andrew Macleod --- > > > > This is a large CFG, so a linear search of a BB, is bound to be slow. > > Indeed, vec should never have gotten ::contains () ... I'd have > used a regular bitmap, not sbitmap, because we do > > bb = m_update_list.pop (); > > and bitmap_first_set_bit is O(n) for an sbitmap bit O(1) for a bitmap. > If we replaced the current vector with just the bitmap implementation, then this would be the ideal way to do it. However, the propagation engine is suppose to call add_to_update in a (mostly) breadth-first way so that changes being pushed minimize turmoil. As I look closer, I see that this code doesn't really end up doing that properly now anyway. I'll do some experiments and either fix the current code to do breadth right, or just switch to the bitmap solution you suggest which will then be quasi-random. And you are right.. that contains should never have gotten in there, let alone been used by me. :-) Must have been in a hurry that day.
[Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061 --- Comment #1 from Martin Liška --- The following file is miscompiled: gfortran -c -o m_MergeSorts.fppized.o -I. -Iinclude -Inetcdf/include -O2 -march=native -g -std=legacy m_MergeSorts.fppized.f90 where first bad debug counter value is: -fdbg-cnt=back_threadfull2:6
[Bug testsuite/103051] [12 regression] new test case gcc.dg/vect/tsvc/vect-tsvc-s112.c fails in r12-4840
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103051 --- Comment #3 from seurer at gcc dot gnu.org --- vect_hw_misalign is one way though it is used in the dg-final instead of dg-skip. There are lots of examples in other vect tests.
[Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Blocks||26163 Last reconfirmed||2021-11-03 Priority|P3 |P1 Ever confirmed|0 |1 Target Milestone|--- |12.0 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug tree-optimization/103061] New: [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061 Bug ID: 103061 Summary: [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4 Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: aldyh at gcc dot gnu.org Target Milestone: --- Since the revision, the benchmark fails: 527.cam4_r: copy 0 non-zero return code (exit code=139, signal=0) Contents of cam4_r_peak.gcc-m64.err Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x779e279f in ??? at /usr/src/debug/glibc-2.34-2.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0 #1 0x4cb5a4 in merge_ at /home/marxin/Programming/cpu2017/benchspec/CPU/527.cam4_r/build/build_peak_gcc-m64.0001/m_MergeSorts.fppized.f90:586 #2 0x4cb5a4 in mergesort_ at /home/marxin/Programming/cpu2017/benchspec/CPU/527.cam4_r/build/build_peak_gcc-m64.0001/m_MergeSorts.fppized.f90:562 #3 0x4cb5a4 in __m_mergesorts_MOD_dsort_ at /home/marxin/Programming/cpu2017/benchspec/CPU/527.cam4_r/build/build_peak_gcc-m64.0001/m_MergeSorts.fppized.f90:543 #4 0x4cbee2 in __m_mergesorts_MOD_dsortn_ at /home/marxin/Programming/cpu2017/benchspec/CPU/527.cam4_r/build/build_peak_gcc-m64.0001/m_MergeSorts.fppized.f90:225 #5 0x4d2cb3 in __phys_grid_MOD_phys_grid_init at /home/marxin/Programming/cpu2017/benchspec/CPU/527.cam4_r/build/build_peak_gcc-m64.0001/phys_grid.fppized.f90:399 #6 0x75af58 in __inital_MOD_cam_initial at /home/marxin/Programming/cpu2017/benchspec/CPU/527.cam4_r/build/build_peak_gcc-m64.0001/inital.fppized.f90:98 #7 0x7892e2 in __cam_comp_MOD_cam_init at /home/marxin/Programming/cpu2017/benchspec/CPU/527.cam4_r/build/build_peak_gcc-m64.0001/cam_comp.fppized.f90:130 #8 0x7a4a2c in __atm_comp_mct_MOD_atm_init_mct at /home/marxin/Programming/cpu2017/benchspec/CPU/527.cam4_r/build/build_peak_gcc-m64.0001/atm_comp_mct.fppized.f90:263 #9 0x7ea59d in __ccsm_comp_mod_MOD_ccsm_init at /home/marxin/Programming/cpu2017/benchspec/CPU/527.cam4_r/build/build_peak_gcc-m64.0001/ccsm_comp_mod.fppized.f90:928 #10 0x40379c in ccsm_driver at /home/marxin/Programming/cpu2017/benchspec/CPU/527.cam4_r/build/build_peak_gcc-m64.0001/ccsm_driver.fppized.f90:57 #11 0x40379c in main at /home/marxin/Programming/cpu2017/benchspec/CPU/527.cam4_r/build/build_peak_gcc-m64.0001/ccsm_driver.fppized.f90:25
[Bug c++/103060] New: Argument initialization side-effects missing: delegating from base constructor to inherited constructor from virtual base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103060
Bug ID: 103060
Summary: Argument initialization side-effects missing:
delegating from base constructor to inherited
constructor from virtual base
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
The "only for the constructor of the most-derived class, virtual bases are
initialized" wording applies only to the non-delegating case. For a delegating
constructor, the target constructor is called even if it is inherited from a
virtual base and the constructor is not for the most-derived class.
### ONLINE COMPILER LINK:
https://godbolt.org/z/h7TnGxxv7
### SOURCE ():
struct NonTriv {
NonTriv(int);
~NonTriv();
};
struct V { V() = default; V(NonTriv); };
struct Q { Q(); };
int bar();
struct A : virtual V, Q {
using V::V;
A() : A(bar()) { }
};
struct B : A { };
void foo() { B b; }
### COMPILER INVOCATION:
g++ -O -S -o - -xc++ -std=c++20 -
### Assembly output (snippet):
_Z3foov:
.LFB6:
.cfi_startproc
subq$24, %rsp
.cfi_def_cfa_offset 32
leaq8(%rsp), %rdi
call_ZN1QC2Ev
addq$24, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
### OBSERVATIONS:
The constructor for the direct base is being called; the wording mechanism for
that call comes from the inherited constructor invocation. That is, GCC does
invoke the inherited constructor; however, it does not process the argument.
Clang and ICC does process the argument (and also the initialization of the
corresponding parameter).
### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210721 (experimental) (GCC)
[Bug middle-end/102970] [11 Regression] stable_sort uninitialized value with -funroll-loops -fno-tree-vectorize since r11-2963-gd6a05b494b4b714e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102970 Richard Biener changed: What|Removed |Added Summary|[11/12 Regression] |[11 Regression] stable_sort |stable_sort uninitialized |uninitialized value with |value with -funroll-loops |-funroll-loops |-fno-tree-vectorize since |-fno-tree-vectorize since |r11-2963-gd6a05b494b4b714e |r11-2963-gd6a05b494b4b714e Known to work||12.0 --- Comment #7 from Richard Biener --- Fixed on trunk sofar.
[Bug middle-end/102970] [11/12 Regression] stable_sort uninitialized value with -funroll-loops -fno-tree-vectorize since r11-2963-gd6a05b494b4b714e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102970 --- Comment #6 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:1967fd8f2197f2b0334ab0fbc26abc3d9efe56c9 commit r12-4865-g1967fd8f2197f2b0334ab0fbc26abc3d9efe56c9 Author: Richard Biener Date: Wed Nov 3 13:26:48 2021 +0100 tree-optimization/102970 - remap cliques when translating over backedges The following makes sure to remap (or rather drop for simplicity) dependence info encoded in MR_DEPENDENCE_CLIQUE when PRE PHI translation translates a reference over a backedge since that ends up interleaving two different loop iterations which boils down to two different inline copies. 2021-11-03 Richard Biener PR tree-optimization/102970 * tree-ssa-pre.c (phi_translate_1): Drop clique and base when translating a MEM_REF over a backedge. * g++.dg/opt/pr102970.C: New testcase.
[Bug target/102986] [12 Regression] ICE: in expand_shift_1, at expmed.c:2671 with a negative shift of a vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102986 Roger Sayle changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Roger Sayle --- This is now fixed on mainline. Sorry again for the breakage.
[Bug middle-end/103059] [10 regression][VAX] ICE in postreload with the ASHIFT form of scaled indexed addressing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103059 Maciej W. Rozycki changed: What|Removed |Added Last reconfirmed||2021-11-03 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1
[Bug middle-end/103059] New: [10 regression][VAX] ICE in postreload with the ASHIFT form of scaled indexed addressing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103059
Bug ID: 103059
Summary: [10 regression][VAX] ICE in postreload with the ASHIFT
form of scaled indexed addressing
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: macro at orcam dot me.uk
Reporter: macro at orcam dot me.uk
Target Milestone: ---
Target: vax-netbsdelf
We have a `vax-netbsdelf' target regression ultimately caused by commit
c605a8bf9270 ("VAX: Accept ASHIFT in address expressions") (needed for
LRA) and as of commit 4a960d548b7d ("Avoid invalid loop transformations
in jump threading registry.") causing a build error in libgcc:
.../libgcc/libgcov-driver.c: In function 'gcov_do_dump':
.../libgcc/libgcov-driver.c:686:1: error: insn does not satisfy its
constraints:
686 | }
| ^
(insn 2051 2050 2052 185 (set (reg/f:SI 0 %r0 [555])
(plus:SI (ashift:SI (mem/c:SI (plus:SI (reg/f:SI 13 %fp)
(const_int -28 [0xffe4])) [40 %sfp+-28 S4
A32])
(const_int 3 [0x3]))
(plus:SI (reg/v/f:SI 9 %r9 [orig:176 fn_buffer ] [176])
(const_int 24 [0x18] ".../libgcc/libgcov-driver.c":172:40
614 {movaddrdi}
(nil))
during RTL pass: postreload
.../libgcc/libgcov-driver.c:686:1: internal compiler error: in
extract_constrain_insn, at recog.c:2670
0x1122a5ff _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
.../gcc/rtl-error.c:108
0x1122a697 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
.../gcc/rtl-error.c:118
0x111b5f2f extract_constrain_insn(rtx_insn*)
.../gcc/recog.c:2670
0x11143eef reload_cse_simplify_operands
.../gcc/postreload.c:407
0x11142fdb reload_cse_simplify
.../gcc/postreload.c:132
0x11143533 reload_cse_regs_1
.../gcc/postreload.c:238
0x11142ce7 reload_cse_regs
.../gcc/postreload.c:66
0x1114af33 execute
.../gcc/postreload.c:2355
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See ,
and commit 6b3034eaba83 ("lra: Canonicalize mult to shift in address
reloads").
Bug filed for tracking purposes, posting a fix right away.
[Bug c++/103057] Internal compiler error: Error reporting routines re-entered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103057 --- Comment #3 from Dennis Lubert --- Yes, the original testcase is valid code that compiles fine with -w
[Bug c++/70796] [DR 1030] Initialization order with braced-init-lists still broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70796 Jason Merrill changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||jason at gcc dot gnu.org Last reconfirmed||2021-11-03 --- Comment #4 from Jason Merrill --- The CALL_EXPR_ORDERED_ARGS code is supposed to make this work properly.
[Bug ipa/103058] ICE in gimple_call_static_chain_flags, at gimple.c:1669 when building 527.cam4_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103058 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Target Milestone|--- |12.0 Ever confirmed|0 |1 Blocks||26163 Last reconfirmed||2021-11-03 Priority|P3 |P1 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug ipa/103058] New: ICE in gimple_call_static_chain_flags, at gimple.c:1669 when building 527.cam4_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103058 Bug ID: 103058 Summary: ICE in gimple_call_static_chain_flags, at gimple.c:1669 when building 527.cam4_r Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- One can see it with -O2 -flto=auto -march=znver2: radsw.fppized.f90:39:19: internal compiler error: in gimple_call_static_chain_flags, at gimple.c:1669 39 | subroutine radcswmx(lchnk ,ncol, & | ^ 0x6a0183 gimple_call_static_chain_flags(gcall const*) /home/marxin/Programming/gcc/gcc/gimple.c:1669 0xfe7959 handle_rhs_call /home/marxin/Programming/gcc/gcc/tree-ssa-structalias.c:4258 0xfeaaa2 find_func_aliases_for_call /home/marxin/Programming/gcc/gcc/tree-ssa-structalias.c:4921 0xfeaaa2 find_func_aliases /home/marxin/Programming/gcc/gcc/tree-ssa-structalias.c:5024 0xfec63a compute_points_to_sets /home/marxin/Programming/gcc/gcc/tree-ssa-structalias.c:7440 0xfec63a compute_may_aliases() /home/marxin/Programming/gcc/gcc/tree-ssa-structalias.c:7948 0xce40cc execute_function_todo /home/marxin/Programming/gcc/gcc/passes.c:2014 0xce461b execute_todo /home/marxin/Programming/gcc/gcc/passes.c:2096 Started with g:a70c05120ae6 where the assert was introduced.
[Bug fortran/103054] [f18] Gfortran accepts invalid and rejects valid co_reduce argument keyword name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103054 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- diff --git a/gcc/fortran/intrinsic.c b/gcc/fortran/intrinsic.c index 219f04f2317..0e3dfd9e5e6 100644 --- a/gcc/fortran/intrinsic.c +++ b/gcc/fortran/intrinsic.c @@ -3805,7 +3805,7 @@ add_subroutines (void) BT_UNKNOWN, 0, GFC_STD_F2018, gfc_check_co_reduce, NULL, NULL, a, BT_REAL, dr, REQUIRED, INTENT_INOUT, - "operator", BT_INTEGER, di, REQUIRED, INTENT_IN, + "operation", BT_INTEGER, di, REQUIRED, INTENT_IN, result_image, BT_INTEGER, di, OPTIONAL, INTENT_IN, stat, BT_INTEGER, di, OPTIONAL, INTENT_OUT, errmsg, BT_CHARACTER, dc, OPTIONAL, INTENT_INOUT);
[Bug tree-optimization/103033] [12 regression] c-c++-common/auto-init-4.c ICEs starting with r12-4829
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103033 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Richard Biener --- Fixed.
[Bug tree-optimization/103033] [12 regression] c-c++-common/auto-init-4.c ICEs starting with r12-4829
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103033 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:c081d0a3b0291297f04a05c833d2ffa8de3a7a1a commit r12-4859-gc081d0a3b0291297f04a05c833d2ffa8de3a7a1a Author: Richard Biener Date: Wed Nov 3 11:10:19 2021 +0100 middle-end/103033 - drop native_interpret_expr with .DEFERRED_INIT expansion This drops the use of native_interpret_expr which can fail even though can_native_interpret_expr_p returns true in favor of simply folding the VIEW_CONVERT_EXPR punning. 2021-11-03 Richard Biener PR middle-end/103033 * internal-fn.c (expand_DEFERRED_INIT): Elide the native_interpret_expr path in favor of folding the VIEW_CONVERT_EXPR generated when punning the RHS.
[Bug tree-optimization/103037] [11/12 Regression] Wrong code with -O2 since r11-6100-gd41b097350d3c5d0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103037 --- Comment #7 from Richard Biener --- So we value number iftmp.0_15 to _3 and things start to go downhill when we PHI translate _25 / iftmp.0_10 5 -> 7 as _24 / _3 since there's too much sharing of the PRE IL used for PHI translation and the VN tables used for value-numbering. I did try to untangle this mess a few times already. I will see what I can do during stage3.
[Bug target/103028] ICE in extract_constrain_insn, at recog.c:2670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103028 --- Comment #2 from Andreas Krebbel --- IF-convert generates the compare *after* reload. The operands get checked for validity only by invoking the predicates. That means everything which is accepted by TARGET_LEGITIMATE_CONSTANT_P is ok for a general_operand. However, we have several patterns where the union of all constraints would accept less operands than the predicate assuming that reload is able to sort this out. The ICE is triggered by emitting a pattern which actually would need to be fixed by reload. The problem could easily be avoided by e.g. enforcing operand1 to satisfy the constraint used in the pattern. However, I'm wondering how this is supposed to work in general. Couldn't this trigger all sorts of problems? Are we the only backend relying on LRA sorting out these kind of issues for us? Btw. I couldn't trigger the problem without -fharden-conditional-branches so far.
[Bug c++/70792] Incorrect sequence point warning with uniform initializer syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70792 --- Comment #13 from Jonathan Wakely --- Thanks!
[Bug c++/70796] [DR 1030] Initialization order with braced-init-lists still broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70796
Matthijs van Duin changed:
What|Removed |Added
CC||matthijsvanduin at gmail dot
com
--- Comment #3 from Matthijs van Duin ---
This specifically appears to happen when the constructor has parameters of
trivially copyable non-reference types, e.g. this fails:
#include
struct IntWrap {
int x = 0;
IntWrap ++() { ++x; return *this; }
};
struct Pair {
IntWrap first, second;
Pair( IntWrap x, IntWrap y ) : first{ x }, second{ y } { }
};
int main() {
IntWrap i;
Pair p{ ++i, ++i };
assert( p.first.x == 1 && p.second.x == 2 ); // FAIL (p.first.x is 2)
}
but adding a destructor to IntWrap suffices to make it pass.
Interestingly, when using simple ints there also appear to be very narrow
constraints on the initializer arguments to trigger the bug:
#include
struct IntPair {
int first, second;
IntPair( int x, int y ) : first{ x }, second{ y } { }
};
void testcase_fail() {
int i = 0;
IntPair p{ ++i, ++i };
assert( p.first == 1 && p.second == 2 ); // FAIL (p.first is 2)
}
void testcase_ok_1() {
int i = 0;
IntPair p{ ++i, ++i };
assert( p.first == 1 && p.second == 2 ); // ok
int = i;
IntPair q{ ++j, ++j };
assert( q.first == 3 && q.second == 4 ); // ok
}
void testcase_ok_2() {
int i = 0;
IntPair p{ (int &)++i, (int &)++i };
assert( p.first == 1 && p.second == 2 ); // ok
}
int main() {
testcase_ok_1();
testcase_ok_2();
testcase_fail();
}
even though the analogous testcases for IntWrap all fail.
Related:
bug 51253 (was supposed to have fixed this but evidently missed some cases)
bug 65866 (incorrect -Wsequence-point diagnostic still being emitted)
bug 70792 (dup of bug 65866 but discussion in comments covered this case)
[Bug driver/100937] configure: Add --enable-default-semantic-interposition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100937 --- Comment #9 from Jonathan Wakely --- (In reply to frankhb1989 from comment #7) > GCC and the GNU toolchain are not ELF-specific. Nor are they responsible to > the authority of the specification. That seems like nonsense to me. The toolchain might not be ELF-specific, but on targets that *do* use ELF, of course the ELF specification is relevant, and deviating from it should not be done lightly. > The "ELF assumptions" have no natural > position to be the default at the very first glance from the users' view. More nonsense. Just because portability between ELF and PE/COFF is difficult and requires care, doesn't mean we should also make it difficult to guarantee portability across different linux distros that are all using ELF. That's just silly. You don't make anything better by making everything equally bad.
[Bug c++/70792] Incorrect sequence point warning with uniform initializer syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70792 --- Comment #11 from Jonathan Wakely --- (In reply to Matthijs van Duin from comment #10) > I'm assuming this means a new bug should be opened > about the wrong code generation? Yes please. This one is too confusing now.
[Bug c++/65866] Wrong warning when using list-initialization: operation on 'b' may be undefined [-Wsequence-point]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65866 Matthijs van Duin changed: What|Removed |Added CC||matthijsvanduin at gmail dot com --- Comment #6 from Matthijs van Duin --- (In reply to Jonathan Wakely from comment #4) Note that this testcase, where the constructor takes trivially copyable prvalue arguments, actually still generates wrong code (so the diagnostic is technically still appropriate), while the original testcase in this bug generates correct code but emits a wrong diagnostic.
[Bug ipa/103055] [12 Regression] ICE: in get_ssa_name_flags, at ipa-modref.c:1660 with --param=modref-max-depth=0 since r12-4852-g18f0873d1e595dc2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103055 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-11-03 Priority|P3 |P1 Ever confirmed|0 |1 CC||hubicka at gcc dot gnu.org Target Milestone|--- |12.0 Summary|[12 Regression] ICE: in |[12 Regression] ICE: in |get_ssa_name_flags, at |get_ssa_name_flags, at |ipa-modref.c:1660 with |ipa-modref.c:1660 with |--param=modref-max-depth=0 |--param=modref-max-depth=0 ||since ||r12-4852-g18f0873d1e595dc2 Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- Confirmed, started with r12-4852-g18f0873d1e595dc2.
[Bug middle-end/102970] [11/12 Regression] stable_sort uninitialized value with -funroll-loops -fno-tree-vectorize since r11-2963-gd6a05b494b4b714e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102970
--- Comment #5 from Richard Biener ---
So it looks like while we copy the array to an allocated array successfully
the call
movl$10, %edx
movq%rbp, %rsi
leaq32(%rsp), %rdi
movq%r12, 8(%rsp)
call
_ZNSt17_Temporary_bufferIN9__gnu_cxx17__normal_iteratorIP3boxSt6vectorIS2_SaIS2_S2_EC1ES7_l
clobbers part of the vRects data on the stack. (it is at 32(%rsp))
This is the function that is appearantly miscomplied I think. We have there
[local count: 3804909251]:
# PT = { D.54048 } (escaped, escaped heap)
# __cur_76 = PHI <__cur_43(11), __cur_36(8)>
# prephitmp_81 = PHI
# prephitmp_83 = PHI
# prephitmp_31 = PHI
# prephitmp_28 = PHI
[t.C:14:9] MEM[(int *)__cur_76 clique 4 base 1] = prephitmp_81;
[t.C:15:9] MEM[(int *)__cur_76 + 4B clique 4 base 1] = prephitmp_83;
[t.C:16:9] MEM[(int *)__cur_76 + 8B clique 4 base 1] = prephitmp_31;
[t.C:17:9] MEM[(int *)__cur_76 + 12B clique 4 base 1] = prephitmp_28;
[/home/rguenther/install/gcc-11/usr/local/include/c++/11.2.1/bits/stl_tempbuf.h:212:8]
# PT = { D.54048 } (escaped, escaped heap)
__cur_43 = __cur_76 + 16;
[/home/rguenther/install/gcc-11/usr/local/include/c++/11.2.1/bits/stl_tempbuf.h:212:20]
if (_3 != __cur_43)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 418540015]:
# RANGE ~[18446744073709551600, 18446744073709551600]
_37 = 18446744073709551600 - _56;
_41 = _37 + _42;
[/home/rguenther/install/gcc-11/usr/local/include/c++/11.2.1/bits/stl_tempbuf.h:212:8]
# PT = { D.54048 } (escaped, escaped heap)
__prev_27 = _26 + _41;
goto ; [100.00%]
[local count: 3386369236]:
[t.C:14:18] pretmp_80 = MEM[(int *)__cur_43 + -16B clique 4 base 0];
[t.C:15:18] pretmp_82 = MEM[(int *)__cur_43 + -12B clique 4 base 0];
[t.C:16:18] pretmp_78 = MEM[(int *)__cur_43 + -8B clique 4 base 0];
[t.C:17:18] pretmp_45 = MEM[(int *)__cur_43 + -4B clique 4 base 0];
goto ; [100.00%]
note how PRE manages to "leak" the clique from one iteration to the previous
by translating the references across the backedge but the references
do actually conflict.
So we get to changes that are invalid done by sched2. Both disabling
sched2 and PRE avoids this situation.
-fdbg-cnt=treepre_insert:10-10 is enough to trigger it (on the 11 branch).
[Bug ipa/103055] New: [12 Regression] ICE: in get_ssa_name_flags, at ipa-modref.c:1660 with --param=modref-max-depth=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103055 Bug ID: 103055 Summary: [12 Regression] ICE: in get_ssa_name_flags, at ipa-modref.c:1660 with --param=modref-max-depth=0 Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz CC: marxin at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Created attachment 51727 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51727=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -fipa-modref --param=modref-max-depth=0 testcase.c during IPA pass: modref testcase.c: In function 'foo': testcase.c:5:1: internal compiler error: in get_ssa_name_flags, at ipa-modref.c:1660 5 | } | ^ 0x6fdd23 get_ssa_name_flags /repo/gcc-trunk/gcc/ipa-modref.c:1660 0x6fdd23 analyze_parms /repo/gcc-trunk/gcc/ipa-modref.c:2179 0x6fdd23 analyze_function /repo/gcc-trunk/gcc/ipa-modref.c:2351 0x10deaae modref_generate /repo/gcc-trunk/gcc/ipa-modref.c:2444 0x123af82 execute_ipa_summary_passes(ipa_opt_pass_d*) /repo/gcc-trunk/gcc/passes.c:2248 0xe801f0 ipa_passes /repo/gcc-trunk/gcc/cgraphunit.c:2179 0xe801f0 symbol_table::compile() /repo/gcc-trunk/gcc/cgraphunit.c:2289 0xe82887 symbol_table::compile() /repo/gcc-trunk/gcc/cgraphunit.c:2269 0xe82887 symbol_table::finalize_compilation_unit() /repo/gcc-trunk/gcc/cgraphunit.c:2537 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-4857-20211103014547-g62af7d9402f-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r12-4857-20211103014547-g62af7d9402f-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.0 20211103 (experimental) (GCC)
[Bug testsuite/103051] [12 regression] new test case gcc.dg/vect/tsvc/vect-tsvc-s112.c fails in r12-4840
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103051 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2021-11-03 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org
[Bug testsuite/103051] [12 regression] new test case gcc.dg/vect/tsvc/vect-tsvc-s112.c fails in r12-4840
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103051 --- Comment #1 from Martin Liška --- Mine.
[Bug ipa/103052] [9/10/11/12 Regression] Function is found to be pure looping but has a call to a noreturn function in it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103052 Jan Hubicka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #9 from Jan Hubicka --- mine.
