[Bug target/102215] New: [GCN offloading] Missing '__atomic_compare_exchange_1' etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102215
Bug ID: 102215
Summary: [GCN offloading] Missing '__atomic_compare_exchange_1'
etc.
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tschwinge at gcc dot gnu.org
CC: ams at gcc dot gnu.org, jakub at gcc dot gnu.org, jules at
gcc dot gnu.org
Target Milestone: ---
Target: GCN
The recent commit 090f0d78f194e3cda23fe904016db77ea36c38fa "openmp: Improve
expand_omp_atomic_pipeline" regresses GCN offloading testing as follows:
[-PASS:-]{+FAIL:+} libgomp.c/../libgomp.c-c++-common/reduction-16.c (test
for excess errors)
[-PASS:-]{+UNRESOLVED:+} libgomp.c/../libgomp.c-c++-common/reduction-16.c
[-execution test-]{+compilation failed to produce executable+}
ld: error: undefined symbol: __atomic_compare_exchange_1
>>> referenced by /tmp/cce2YauE.o:(test_char._omp_fn.1)
>>> referenced by /tmp/cce2YauE.o:(test_char._omp_fn.1)
>>> referenced by /tmp/cce2YauE.o:(test_char._omp_fn.0)
>>> referenced by /tmp/cce2YauE.o:(test_char._omp_fn.0)
ld: error: undefined symbol: __atomic_compare_exchange_2
>>> referenced by /tmp/cce2YauE.o:(test_short._omp_fn.1)
>>> referenced by /tmp/cce2YauE.o:(test_short._omp_fn.1)
>>> referenced by /tmp/cce2YauE.o:(test_short._omp_fn.0)
>>> referenced by /tmp/cce2YauE.o:(test_short._omp_fn.0)
collect2: error: ld returned 1 exit status
mkoffload: fatal error:
[...]/gcc/x86_64-pc-linux-gnu-accel-amdgcn-amdhsa-gcc returned 1 exit status
Similar for 'libgomp.c++/../libgomp.c-c++-common/reduction-16.c'.
And:
[-PASS:-]{+FAIL:+} libgomp.c/target-43.c (test for excess errors)
[-PASS:-]{+UNRESOLVED:+} libgomp.c/target-43.c [-execution
test-]{+compilation failed to produce executable+}
ld: error: undefined symbol: __atomic_compare_exchange_1
>>> referenced by /tmp/cc1Kwlmj.o:(main._omp_fn.0)
>>> referenced by /tmp/cc1Kwlmj.o:(main._omp_fn.0)
collect2: error: ld returned 1 exit status
mkoffload: fatal error:
[...]/gcc/x86_64-pc-linux-gnu-accel-amdgcn-amdhsa-gcc returned 1 exit status
These all do:
{ dg-additional-options "-foffload-options=nvptx-none=-latomic" { target {
offload_target_nvptx } } }
Do we now also need libatomic for GCN or should this be handled in the GCN back
end?
[Bug middle-end/102206] amd zen hosts running zen-optimized gcc: gimplification ICE after r10-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102206 --- Comment #12 from Martin Liška --- I tried bootstrapping the current tip of gcc-11 branch with -O2 -march=native on my model name : AMD Ryzen 7 2700X Eight-Core Processor but I can't reproduce the ICE on the provided boost test-case :/
[Bug c++/102214] [9/10/11/12 Regression] ICE when compiling local class with -fno-weak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102214 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Target Milestone|--- |9.5 Status|UNCONFIRMED |NEW Keywords||ice-on-valid-code Summary|ICE when compiling local|[9/10/11/12 Regression] ICE |class with -fno-weak|when compiling local class ||with -fno-weak Known to fail||6.1.0 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=65811, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=67313, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=69113, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=79176, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=94835 Known to work||5.1.0 Last reconfirmed||2021-09-06 --- Comment #1 from Andrew Pinski --- Confirmed, most likely started with r6-67 (like a few of the linked bugs).
[Bug c++/86303] Constructor is not used for type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86303 --- Comment #2 from Andrew Pinski --- GCC 7+ accepts it for C++17 and C++20 but rejects it for C++11 and C++14. Maybe there was a rule change.
[Bug c++/102214] New: ICE when compiling local class with -fno-weak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102214
Bug ID: 102214
Summary: ICE when compiling local class with -fno-weak
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fxue at os dot amperecomputing.com
Target Milestone: ---
Created attachment 51413
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51413=edit
testcase
Compiling attached testcase with option "-flto -O3 -fno-weak" will get:
during IPA pass: *free_lang_data
ic.cpp:5:11: internal compiler error: in mangle_decl, at cp/mangle.c:4088
5 | class InnerParent {
| ^~~
0xbe3ef2 mangle_decl(tree_node*)
../../gcc/cp/mangle.c:4088
0x17b0ac4 decl_assembler_name(tree_node*)
../../gcc/tree.c:710
0x17bd358 assign_assembler_name_if_needed(tree_node*)
../../gcc/tree.c:6318
0x17bd471 free_lang_data_in_cgraph
../../gcc/tree.c:6366
0x17bd606 free_lang_data
../../gcc/tree.c:6411
0x17bd7ac execute
../../gcc/tree.c:6483
[Bug c++/90390] incorrect list initialization behavior for references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90390 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=81952 Status|UNCONFIRMED |NEW Last reconfirmed||2021-09-06 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug target/96127] ICE in extract_insn, at recog.c:2294
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96127 --- Comment #4 from Andreas Krebbel --- The testcase does not appear to fail on current GCC 10 branch. So I would just close it as fixed in GCC 11.
[Bug middle-end/102206] amd zen hosts running zen-optimized gcc: gimplification ICE after r10-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102206
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #11 from Jakub Jelinek ---
If it is really a buffer overflow in cp_gimplify_expr (which is weird, there
aren't many arrays in there nor anything else that could result in that, there
is
tree *data[4] = { NULL, NULL, NULL, NULL };
but you aren't compiling with -fopenmp and it also uses just those 4 entries),
then perhaps asan built gcc might be more reliable at detecting it.
Of course, if it is miscompiled cp_gimplify_expr, it might be something else...
[Bug target/101505] [10 Regression] ICE: verify_gimple failed (error: incompatible types in 'PHI' argument 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101505 Richard Biener changed: What|Removed |Added Depends on||97706 --- Comment #10 from Richard Biener --- There's more changes/fixes to be backported to fix this on the GCC 10 branch, like PR97706 and related fixes. Not sure if it is worth the trouble, the ICE doesn't seem to reproduce for me on the branch but instead I get t.c: In function 'w7.simdclone.0': t.c:4:1: error: non-trivial conversion in 'ssa_name' 4 | w7 (void) | ^~ vector(8) unsigned char vector(8) vect__18.21_29 = mask__4.19_25; t.c:4: confused by earlier errors, bailing out which may be another issue that's latent there. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97706 [Bug 97706] [11 Regression] ICE with LTO at -O3: verify_gimple failed (incompatible types in 'PHI' argument 0)
[Bug middle-end/102206] amd zen hosts running zen-optimized gcc: gimplification ICE after r10-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102206 --- Comment #10 from Greg Turner --- If you find yourself not readily reproducing, let me know I suspect a pregenerated gentoo prefix might be a nice "drag-and-drop" way to get someone up and running with a fully working reproduction. Of course it'll take a bunch of time to create one. But once done, interested parties could just shove it into their userspace sandboxes and stop scratching their heads. Otherwise, the nondeterminism sort of leads to awful quagmires where you just keep scratching your head and saying "...or maybe I just got lucky..." followed by an unsatisfying period of reading about probability-density-functions and confidence-intervals on Wikipedia :)
[Bug c++/63604] [C++11] A direct-initialization of a reference should use explicit conversion functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63604 Andrew Pinski changed: What|Removed |Added CC||kot.tom97 at gmail dot com --- Comment #4 from Andrew Pinski --- *** Bug 85848 has been marked as a duplicate of this bug. ***
[Bug c++/85848] Incorrect handling of explicit casting to move-only types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85848 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Andrew Pinski --- This is a dup of bug 63604. *** This bug has been marked as a duplicate of bug 63604 ***
[Bug c++/63604] [C++11] A direct-initialization of a reference should use explicit conversion functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63604 Andrew Pinski changed: What|Removed |Added CC||barry.revzin at gmail dot com --- Comment #3 from Andrew Pinski --- *** Bug 66893 has been marked as a duplicate of this bug. ***
[Bug c++/66893] disallowed initialization of reference with explicit user-defined conversion function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66893 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Andrew Pinski --- Dup of bug 63604. *** This bug has been marked as a duplicate of bug 63604 ***
[Bug c++/63604] [C++11] A direct-initialization of a reference should use explicit conversion functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63604 Andrew Pinski changed: What|Removed |Added CC||iluvtrollhd at gmail dot com --- Comment #2 from Andrew Pinski --- *** Bug 83615 has been marked as a duplicate of this bug. ***
[Bug c++/83615] A reference binding involving an explicit conversion operator rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83615 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #5 from Andrew Pinski --- this is actually a dup of bug 63604. *** This bug has been marked as a duplicate of bug 63604 ***
[Bug c++/83615] A reference binding involving an explicit conversion operator rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83615 --- Comment #4 from Andrew Pinski --- *** Bug 98554 has been marked as a duplicate of this bug. ***
[Bug c++/98554] why the explicit conversion function whose return type is a derived class is not a candidate in the context of direct-initialization for an object of class type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98554 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 83615. *** This bug has been marked as a duplicate of bug 83615 ***
[Bug c++/83615] A reference binding involving an explicit conversion operator rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83615 Andrew Pinski changed: What|Removed |Added CC||xmh970252187 at gmail dot com --- Comment #3 from Andrew Pinski --- *** Bug 102212 has been marked as a duplicate of this bug. ***
[Bug c++/102212] The explicit conversion function should be permitted in direct-initialization of a reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102212 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup of bug 83615. *** This bug has been marked as a duplicate of bug 83615 ***
[Bug c++/83615] A reference binding involving a qualification conversion is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83615
--- Comment #2 from Andrew Pinski ---
Even more reduced testcase:
typedef int t;
struct S {
explicit operator t() {
return 0;
}
};
int main() {
S val;
t & (val);
return 0;
}
[Bug c++/102213] New: Incorrect executable produced from valid input code with virtual consteval
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102213
Bug ID: 102213
Summary: Incorrect executable produced from valid input code
with virtual consteval
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
Consider the program
```
#include
struct A {
virtual consteval std::strong_ordering operator <=>(const A &) const =
default;
};
struct B : A {
virtual consteval bool operator==(const A&) const noexcept override {
return false; }
};
int main() {
static constexpr B b;
static constexpr const A & a = b;
static_assert( (a <=> a) == 0 );
static_assert( a != a );
return (a <=> a) == 0;
}
```
It shall return 1, but after making in GCC it fails with return code 139:
https://gcc.godbolt.org/z/EjdWa61W9
[Bug debug/101947] [12 Regression] broken LTO bootstrap in get_base_type_offset at dwarf2out.c:4330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101947 --- Comment #9 from Eric Botcazou --- Obvious kludge: diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c index 07a479f6382..fb436b8c77c 100644 --- a/gcc/dwarf2out.c +++ b/gcc/dwarf2out.c @@ -19484,6 +19491,7 @@ loc_list_from_tree_1 (tree loc, int want_address, else if (!(context && context->strict_signedness) || TYPE_UNSIGNED (TREE_TYPE (loc)) || (dwarf_strict && dwarf_version < 5) + || early_dwarf || !is_a (mode, _mode) || !(type_die = base_type_for_mode (mode, false))) deref = new_loc_descr (DW_OP_deref_size, size, 0);
[Bug c++/83615] A reference binding involving a qualification conversion is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83615
--- Comment #1 from Andrew Pinski ---
const has nothing to do with it:
typedef int **t;
class S {
public:
explicit operator t() {
return 0;
}
};
int main() {
S val;
t & (val);
return 0;
}
is also rejected.
[Bug middle-end/102206] amd zen hosts running zen-optimized gcc: gimplification ICE after r10-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102206 --- Comment #9 from Greg Turner --- Never mind, corrected version is quite equivalent: --- xml_grammar_gcc_-E.cpp 2021-09-06 01:38:48.125773266 -0700 +++ xml_grammar_gcc_-E-try2.cpp 2021-09-06 01:49:24.384875598 -0700 @@ -1,4 +1,5 @@ # 0 "libs/serialization/src/xml_grammar.cpp" +# 1 "/var/tmp/portage/dev-libs/boost-1.76.0-r1/work/boost_1_76_0-abi_x86_64.amd64//" # 0 "" # 0 "" # 1 "/usr/include/stdc-predef.h" 1 3 4 :)
[Bug tree-optimization/102046] [10/11 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.c:87 with -O3 -march=btver2 since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102046 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:57f6800aefdd102cd43f0df53ca8bcbcc7202b41 commit r11-8966-g57f6800aefdd102cd43f0df53ca8bcbcc7202b41 Author: Richard Biener Date: Wed Aug 25 10:06:01 2021 +0200 tree-optimization/102046 - fix SLP build from scalars with patterns When we swap operands for SLP builds we lose track where exactly pattern defs are - but we fail to update the any_pattern member of the operands info. Do so conservatively. 2021-08-25 Richard Biener PR tree-optimization/102046 * tree-vect-slp.c (vect_build_slp_tree_2): Conservatively update ->any_pattern when swapping operands. * gcc.dg/vect/pr102046.c: New testcase. (cherry picked from commit 29c77454e5ab33ce06a741eacdfbd5348fbccc95)
[Bug tree-optimization/101925] [10/11 Regression] reversed storage order when compiling with -O3 only since r10-4742-g9b75f56d4b7951c6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101925 --- Comment #11 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:7f584a309092896bdbe83655fb5f425ac8adc019 commit r11-8965-g7f584a309092896bdbe83655fb5f425ac8adc019 Author: Richard Biener Date: Mon Aug 16 15:17:08 2021 +0200 tree-optimization/101925 - fix VN with reverse storage order This fixes value-numbering breaking reverse storage order accesses due to a missed check. It adds a new overload for reverse_storage_order_for_component_p and sets reversed on the VN IL ops for component and array accesses accordingly. It also compares the reversed reference ops flag on reference lookup. 2021-08-16 Richard Biener PR tree-optimization/101925 * tree-ssa-sccvn.c (copy_reference_ops_from_ref): Set reverse on COMPONENT_REF and ARRAY_REF according to what reverse_storage_order_for_component_p does. (vn_reference_eq): Compare reversed on reference ops. (reverse_storage_order_for_component_p): New overload. (vn_reference_lookup_3): Check reverse_storage_order_for_component_p on the reference looked up. * gcc.dg/sso-16.c: New testcase. (cherry picked from commit 0215b3559e55f39f38e10984a804c53907f7491c)
[Bug tree-optimization/101824] [9/10/11 Regression] VOLATILE not honored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101824 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:3f29e301f299a1b4e2c535affb964f0b97b7639c commit r11-8964-g3f29e301f299a1b4e2c535affb964f0b97b7639c Author: Richard Biener Date: Mon Aug 9 10:19:10 2021 +0200 middle-end/101824 - properly handle volatiles in nested fn lowering When we build the COMPONENT_REF of a formerly volatile local off the FRAME decl we have to make sure to mark the COMPONENT_REF as TREE_THIS_VOLATILE. While the GIMPLE operand scanner looks at the FIELD_DECL this is not how volatile GENERIC refs work. 2021-08-09 Richard Biener PR middle-end/101824 * tree-nested.c (get_frame_field): Mark the COMPONENT_REF as volatile in case the variable was. * gcc.dg/tree-ssa/pr101824.c: New testcase. (cherry picked from commit bb169406cdc9e044eaec500dd742c2fed40f5488)
[Bug middle-end/102206] amd zen hosts running zen-optimized gcc: gimplification ICE after r10-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102206 --- Comment #8 from Greg Turner --- Actually please ignore that one pending replacement, I probably generated it wrong...
[Bug c++/102212] The explicit conversion function should be permitted in direct-initialization of a reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102212 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-09-06 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed, seems GCC has always rejected this code.
[Bug middle-end/102206] amd zen hosts running zen-optimized gcc: gimplification ICE after r10-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102206 --- Comment #7 from Greg Turner --- Created attachment 51412 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51412=edit xml_grammar_gcc_-E.cpp.xz preproc boost cpp file that tends to trigger failure
[Bug middle-end/102206] amd zen hosts running zen-optimized gcc: gimplification ICE after r10-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102206 --- Comment #6 from Martin Liška --- > I would think you'd want the one generated on the bugged compiler, not mine. > But iiuc I guess they'd be identical, assuming all is well until > gimplification? Yes, that's identical, it's a source file.
[Bug target/102205] vec + 1 could be done as vec - (-1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102205 --- Comment #2 from Andrew Pinski --- So ICC does the same as GCC while ICX does the same as LLVM (most likely because it is LLVM based).
[Bug middle-end/102206] amd zen hosts running zen-optimized gcc: gimplification ICE after r10-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102206 --- Comment #5 from Greg Turner --- (In reply to Martin Liška from comment #4) > (use -E option) to this bug. Note Oh, /that/ kind of preprocessed! That's easy... I thought it was some kind of re-usable pre-compiled header file thing, sorry. I would think you'd want the one generated on the bugged compiler, not mine. But iiuc I guess they'd be identical, assuming all is well until gimplification? For a start I'll get you what comes out of my patched gcc, I'll just need a moment.
[Bug target/102205] vec + 1 could be done as vec - (-1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102205 Richard Biener changed: What|Removed |Added Last reconfirmed||2021-09-06 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Are you sure that's always faster? Likewly depends on port congestion. avx512 could use splat from scalar memory as well.
[Bug tree-optimization/65964] [meta-bug] Operand Shortening
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65964 Bug 65964 depends on bug 17935, which changed state. Bug 17935 Summary: Two consecutive movzbl are generated https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17935 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug rtl-optimization/17935] Two consecutive movzbl are generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17935 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.4.0 --- Comment #9 from Andrew Pinski --- GCC 4.4.0 produces (which is like future versions of GCC): bar: movl4(%esp), %eax testb $1, (%eax) je .L2 xorl%eax, %eax ret .L2: movl8(%esp), %eax movb(%eax), %al xorl$1, %eax andl$1, %eax ret So GCC 4.5.0 and 4.6.0 produces: bar: movl4(%esp), %eax testb $1, (%eax) jne .L3 movl8(%esp), %eax testb $1, (%eax) sete%al ret .L3: xorl%eax, %eax ret Which is what we want. GCC 4.7-8.5.0 changed the testb to movb, xor and and: bar: .LFB0: movl4(%esp), %eax testb $1, (%eax) jne .L3 movl8(%esp), %eax movb(%eax), %al xorl$1, %eax andl$1, %eax ret .L3: xorl%eax, %eax ret GCC 9+ changes the xorl to a not: bar: movl4(%esp), %eax testb $1, (%eax) jne .L3 movl8(%esp), %eax movb(%eax), %al notl%eax andl$1, %eax ret .L3: xorl%eax, %eax ret So this was fixed back in GCC 4.4.0. I am not going to look what fixed it either.
[Bug target/102202] Inefficent expansion of memset when range is [0,1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102202 --- Comment #3 from Richard Biener --- We do have machinery (from profiling) to pass along min/max size which we already use, so I wonder if we should use those bounds in more cases. Of course memset (..., [0, 1]) could be constant folded on GIMPLE into a branch as you say. Eventually tree-call-dce.c is a good place to do so (the memset is conditionally dead after all...)
[Bug tree-optimization/102200] [12 Regression] ice in put_ref, at pointer-query.cc:1351 since r12-3300-gece28da924ddda8b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102200 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug debug/101947] [12 Regression] broken LTO bootstrap in get_base_type_offset at dwarf2out.c:4330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101947
--- Comment #8 from Eric Botcazou ---
The problem is that the dwarf2out_early_finish path does not finalize base
types so calc_die_sizes cannot compute the size of DW_OP_deref_type:
case DW_OP_deref_type:
case DW_OP_GNU_deref_type:
{
unsigned long o
= get_base_type_offset (loc->dw_loc_oprnd2.v.val_die_ref.die);
size += 1 + size_of_uleb128 (o);
}
break;
[Bug middle-end/102206] amd zen hosts running zen-optimized gcc: gimplification ICE after r10-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102206 --- Comment #4 from Martin Liška --- > > As for boost, I don't think any special configuration or version is required > to make it happen ... [time passes...] got it, the specific build step that > tends** to cause the failure is: > > /usr/bin/x86_64-pc-linux-gnu-g++ -fvisibility-inlines-hidden -O3 > -march=native -pipe -std=c++14 -fPIC -m64 -pthread -finline-functions > -Wno-inline -Wall -fvisibility=hidden -ftemplate-depth-255 > -fvisibility=hidden -fvisibility-inlines-hidden -DBOOST_ALL_NO_LIB=1 > -DBOOST_SERIALIZATION_DYN_LINK=1 -DNDEBUG -I. -c -o > bin.v2/libs/serialization/build/gcc-10.1/gentoorelease/pch-off/threading- > multi/visibility-hidden/xml_grammar.o libs/serialization/src/xml_grammar.cpp Please attach a pre-processed source file (use -E option) to this bug. Note I don't use Gentoo Linux, so I can't easily build the boost package.
[Bug debug/102195] Missing DW_TAG_typedef when using qualified variable of typedef'd array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102195 Richard Biener changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||jsm28 at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- const qualification of array types is a topic that comes up repeatedly
[Bug target/102186] [12 Regression] Broken bootstrap: soft-fp/half.h:62:1: error: unable to emulate ‘HF’ since r12-3308-ge42d2d2a20f2bb59928bc895ec9f46503a1b5c73
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102186 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- fixed.
[Bug tree-optimization/102207] [12 Regression] wrong code with __builtin_sub_overflow() at -O1 and above with uint128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102207 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed, thanks for the report.
[Bug tree-optimization/102207] [12 Regression] wrong code with __builtin_sub_overflow() at -O1 and above with uint128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102207
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:8a4602c2e0f81895415ba7ee23bf81dc795d1103
commit r12-3365-g8a4602c2e0f81895415ba7ee23bf81dc795d1103
Author: Jakub Jelinek
Date: Mon Sep 6 10:08:16 2021 +0200
match.pd: Fix up __builtin_*_overflow arg demotion [PR102207]
My earlier patch to demote arguments of __builtin_*_overflow unfortunately
caused a wrong-code regression. The builtins operate on infinite precision
arguments, outer_prec > inner_prec signed -> signed, unsigned -> unsigned
promotions there are just repeating the sign or 0s and can be demoted,
similarly unsigned -> signed which also is repeating 0s, but as the
testcase shows, signed -> unsigned promotions need to be preserved (unless
we'd know the inner arguments can't be negative), because for negative
numbers such promotion sets the outer_prec -> inner_prec bits to 1 bit the
bits above that to 0 in the infinite precision.
So, the following patch avoids the demotions for the signed -> unsigned
promotions.
2021-09-06 Jakub Jelinek
PR tree-optimization/102207
* match.pd: Don't demote operands of IFN_{ADD,SUB,MUL}_OVERFLOW if
they
were promoted from signed to wider unsigned type.
* gcc.dg/pr102207.c: New test.
[Bug middle-end/102206] amd zen hosts running zen-optimized gcc: gimplification ICE after r10-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102206
--- Comment #3 from Greg Turner ---
(In reply to Martin Liška from comment #2)
> Can you please show how do you configure and build GCC (gcc -v).
> And can you please attach a pre-processed boost source (and command-line
> used) that can reproduce the issue?
Gentoo does all this heavy lifting. Some of these things I am blissfully
ignorant of although I'm happy to drill into the build process and drag some
artifacts over here if that will help.
I don't have an affected gcc, since I apply the patch to my one system capable
of repro-ing the bug. I might also have a laptop capable of reproing, I
haven't tried.
But here's a gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/11.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-11.2.0/work/gcc-11.2.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/11.2.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.2.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.2.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.2.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include/g++-v11
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/11.2.0/python
--enable-languages=c,c++,go,jit,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=release
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 11.2.0 p1'
--disable-esp --enable-libstdcxx-time --enable-host-shared --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point
--enable-targets=all --enable-libgomp --disable-libssp --disable-libada
--enable-systemtap --enable-valgrind-annotations --disable-vtable-verify
--disable-libvtv --with-zstd --enable-lto --with-isl
--disable-isl-version-check --enable-default-pie --enable-default-ssp
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (Gentoo 11.2.0 p1)
Without the patch the same configuration would of course enable me to repro; I
assume the above would be 100% the same.
Note that this doesn't even capture the most important part of the equation*:
$ portageq envvar CFLAGS
-march=znver1 -mtune=znver1 -O2 -pipe -g
tbh I guess I am not sure if I ever confirmed this applied to 11.2, perhaps it
fixed it and I never noticed. But I very highly doubt it, this bug has been
quite persistent.
As for boost, I don't think any special configuration or version is required to
make it happen ... [time passes...] got it, the specific build step that
tends** to cause the failure is:
/usr/bin/x86_64-pc-linux-gnu-g++ -fvisibility-inlines-hidden -O3 -march=native
-pipe -std=c++14 -fPIC -m64 -pthread -finline-functions -Wno-inline -Wall
-fvisibility=hidden -ftemplate-depth-255 -fvisibility=hidden
-fvisibility-inlines-hidden -DBOOST_ALL_NO_LIB=1
-DBOOST_SERIALIZATION_DYN_LINK=1 -DNDEBUG -I. -c -o
bin.v2/libs/serialization/build/gcc-10.1/gentoorelease/pch-off/threading-multi/visibility-hidden/xml_grammar.o
libs/serialization/src/xml_grammar.cpp
Anyhow since we know for sure my system repro's the bug , here are the
use-flags affecting my boost build:
dev-libs/boost-1.76.0-r1:0/1.76.0::gentoo USE="bzip2 doc icu lzma nls python
threads tools zlib zstd -context -debug -mpi -numpy -static-libs" ABI_X86="(64)
-32 (-x32)" PYTHON_TARGETS="python3_8 python3_9 -python3_10"
This passes "${OPTIONS[@]}" to boost's jam invocation which on my system ends
up looking like:
declare -a OPTIONS=(
[0]="gentoorelease"
[1]="-j52"
[2]="-q"
[3]="-d+2"
[4]="pch=off"
[5]="-sICU_PATH=/usr"
[6]="--without-mpi"
[7]="--without-context"
[8]="--without-coroutine"
[9]="--without-fiber"
[10]="--without-stacktrace"
[11]="--boost-build=/usr/share/boost-build/src"
[12]="--layout=system"
[13]="threading=multi"
[14]="link=shared"
[15]="-sNO_BZIP2=0"
[16]="-sNO_LZMA=0"
[17]="-sNO_ZLIB=0"
[18]="-sNO_ZSTD=0"
)
See comment 12-14 of the Gentoo bug for some talk/examples of preproc headers.
I do not have an affected compiler at my disposal and am not even sure how all
this preproc header stuff works... let me know if that's really a serious need
& I'll build a bugged compiler & hit the books or w/e is required to figure out
the preproc header things.
--
* if using Gentoo or Gentoo-prefix to repro this (possibly the path of least
confusion ime) the use flag "custom-cflags" must be set on sys-devel/gcc to
repro (otherwise the c{,xx}flags do not actually apply to gcc).
** rarely, I think I observed similar gimplification failures elsewhere in the
build during my
[Bug driver/13071] no easy way to exclude backward C++ headers from include path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13071 Harald van Dijk changed: What|Removed |Added CC||harald at gigawatt dot nl --- Comment #8 from Harald van Dijk --- (In reply to Andrew Pinski from comment #7) > Isn't doing the extern "C" around standard C++ headers declared by the C++ > standard as undefined behavior? It is (as is doing extern "C++" around standard C++ headers, for that matter), but only became a standard C++ header in C++11. This bug is from 2003 and the comment before yours was from 2009, so I think was not a standard C++ header yet.
[Bug middle-end/63184] [9/10/11/12 Regression] Fails to simplify comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63184 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|9.5 |12.0 --- Comment #30 from Andrew Pinski --- Fixed on the trunk and I don't think this should be backported as it has been a missed optimization for 7 years or more.
[Bug middle-end/63184] [9/10/11/12 Regression] Fails to simplify comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63184 --- Comment #29 from CVS Commits --- The master branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:564efbf40077c25623cdd6ce2f911c56b5b08f6c commit r12-3364-g564efbf40077c25623cdd6ce2f911c56b5b08f6c Author: Andrew Pinski Date: Mon Sep 6 00:52:18 2021 + Fix PR tree-optimization/63184: add simplification of (& + A) != (& + B) These two testcases have been failing since GCC 5 but things have improved such that adding a simplification to match.pd for this case is easier than before. In the end we have the following IR: _5 = [1] + _4; _7 = + _13; if (_5 != _7) So we can fold the _5 != _7 into: ([1] - ) + _4 != _13 The subtraction is folded into constant by ptr_difference_const. In this case, the full expression gets folded into a constant and we are able to remove the if statement. OK? Bootstrapped and tested on aarch64-linux-gnu with no regressions. gcc/ChangeLog: PR tree-optimization/63184 * match.pd: Add simplification of pointer_diff of two pointer_plus with addr_expr in the first operand of each pointer_plus. Add simplificatoin of ne/eq of two pointer_plus with addr_expr in the first operand of each pointer_plus. gcc/testsuite/ChangeLog: PR tree-optimization/63184 * c-c++-common/pr19807-2.c: Enable for all targets and remove the xfail. * c-c++-common/pr19807-3.c: Likewise.
[Bug target/102186] [12 Regression] Broken bootstrap: soft-fp/half.h:62:1: error: unable to emulate ‘HF’ since r12-3308-ge42d2d2a20f2bb59928bc895ec9f46503a1b5c73
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102186 --- Comment #4 from Hongtao.liu --- (In reply to Hongtao.liu from comment #3) > A patch is posted at > https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578746.html Fixed by r12-3363 in GCC12
[Bug middle-end/14840] fold tree_code_type[CST] and tree_code_length[CST] in GCC itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14840 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #12 from Andrew Pinski --- since we require C++11 now, shouldn't they be constexpr now? I will try doing that in the next couple of weeks.
[Bug driver/13071] no easy way to exclude backward C++ headers from include path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13071 --- Comment #7 from Andrew Pinski --- Isn't doing the extern "C" around standard C++ headers declared by the C++ standard as undefined behavior?
[Bug tree-optimization/102176] BB SLP scalar costing is off with extern promoted nodes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102176 Richard Biener changed: What|Removed |Added Known to work||12.0 --- Comment #4 from Richard Biener --- Fixed on trunk, since we enabled whole-function BB vectorization for GCC 11 I'm considering to backport this.
[Bug tree-optimization/102176] BB SLP scalar costing is off with extern promoted nodes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102176 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:a3fb781d4b341c0d50ef1b92cd3e8734e673ef18 commit r12-3362-ga3fb781d4b341c0d50ef1b92cd3e8734e673ef18 Author: Richard Biener Date: Thu Sep 2 14:48:10 2021 +0200 tree-optimization/102176 - locally compute participating SLP stmts This performs local re-computation of participating scalar stmts in BB vectorization subgraphs to allow precise computation of liveness of scalar stmts after vectorization and thus precise costing. This treats all extern defs as live but continues to optimistically handle scalar defs that we think we can handle by lane-extraction even though that can still fail late during code-generation. 2021-09-02 Richard Biener PR tree-optimization/102176 * tree-vect-slp.c (vect_slp_gather_vectorized_scalar_stmts): New function. (vect_bb_slp_scalar_cost): Use the computed set of vectorized scalar stmts instead of relying on the out-of-date and not accurate PURE_SLP_STMT. (vect_bb_vectorization_profitable_p): Compute the set of vectorized scalar stmts.
[Bug middle-end/102206] amd zen hosts running zen-optimized gcc: gimplification ICE after r10-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102206 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |WAITING Last reconfirmed||2021-09-06 --- Comment #2 from Martin Liška --- Can you please show how do you configure and build GCC (gcc -v). And can you please attach a pre-processed boost source (and command-line used) that can reproduce the issue?
[Bug tree-optimization/10980] vararg functions are not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10980 --- Comment #14 from Andrew Pinski --- We have __builtin_va_arg_pack and __builtin_va_arg_pack_len which I think solves this problem really. https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/Constructing-Calls.html#index-_005f_005fbuiltin_005fva_005farg_005fpack
[Bug debug/7853] gcc reports multiple symbol definitions on the wrong line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7853 Andrew Pinski changed: What|Removed |Added Known to work||7.5.0 --- Comment #20 from Andrew Pinski --- Still broken with stabs (which I think is about to removed ...): apinski@xeond:~/src/pr7853$ ~/upstream-gcc/bin/gcc -shared -g -o foo.so foo.c bar.c -gstabs /tmp/ccs5BDpP.o: In function `foo': bar.c:3: multiple definition of `x' /tmp/ccwMzLfi.o:(.bss+0x0): first defined here collect2: error: ld returned 1 exit status
[Bug tree-optimization/102178] [12 Regression] SPECFP 2006 470.lbm regressions on AMD Zen CPUs after r12-897-gde56f95afaaa22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102178 Richard Biener changed: What|Removed |Added Version|11.0|12.0 Summary|SPECFP 2006 470.lbm |[12 Regression] SPECFP 2006 |regressions on AMD Zen CPUs |470.lbm regressions on AMD |after |Zen CPUs after |r12-897-gde56f95afaaa22 |r12-897-gde56f95afaaa22 Target Milestone|--- |12.0
[Bug tree-optimization/102178] SPECFP 2006 470.lbm regressions on AMD Zen CPUs after r12-897-gde56f95afaaa22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102178 --- Comment #1 from Richard Biener --- Maybe related to PR102008, see the comment I made there. Martin, maybe you can try moving late sink to before the last phiopt pass.
[Bug c++/102212] New: The explicit conversion function should be permitted in direct-initialization of a reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102212
Bug ID: 102212
Summary: The explicit conversion function should be permitted
in direct-initialization of a reference
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: xmh970252187 at gmail dot com
Target Milestone: ---
struct D{};
D global;
struct A{
explicit operator D(){
return global;
}
};
int main(){
A a;
D&& rf(a);
}
GCC rejects this example. According to [dcl.init.ref#5.3.2]
> has a class type (i.e., T2 is a class type), where T1 is not
> reference-related to T2, and can be converted to an rvalue or function lvalue
> of type “cv3 T3”, where “cv1 T1” is reference-compatible with “cv3 T3” (see
> [over.match.ref]),
And [over.match.ref#1]
> “cv2 T2” and “rvalue reference to cv2 T2” (when initializing an rvalue
> reference or an lvalue reference to function)
> For direct-initialization, the permissible types for explicit conversion
> functions are the members of R where T2 can be converted to type T with a
> (possibly trivial) qualification conversion ([conv.qual]); otherwise there
> are none.
In this direct-initialization `D&& rf(a);`, `A::operator D()` should be a
candidate.
[Bug bootstrap/4284] gcc-lib directory not configurable thru configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4284 --- Comment #3 from Andrew Pinski --- # Directory in which the compiler finds libraries etc. libsubdir = $(libdir)/gcc/$(real_target_noncanonical)/$(version)$(accel_dir_suffix) # Directory in which the compiler finds executables libexecsubdir = $(libexecdir)/gcc/$(real_target_noncanonical)/$(version)$(accel_dir_suffix)
[Bug driver/2252] If 'as' crashes gcc points you to the gcc bug site
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2252 Andrew Pinski changed: What|Removed |Added Known to fail|| Last reconfirmed|2005-12-31 20:30:04 |2021-9-5 --- Comment #2 from Andrew Pinski --- r8-2534 improved this slightly. At least for the killed (e.g. OOM) case. Otherwise still happens today.
[Bug c++/99] Bug in template type in error message.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2010-06-05 23:38:41 |2021-9-5 --- Comment #23 from Andrew Pinski --- Still here: :20:21: error: call of overloaded 'ch(dummy<0>, dummy<0>)' is ambiguous 20 | return 0.5 * ch(dummy(), dummy<0>()); | ~~^~~~ :10:11: note: candidate: 'double ch(dummy, dummy) [with unsigned int n = 0; unsigned int m = 0]' 10 |double ch(dummy, dummy) | ^~ :18:11: note: candidate: 'double ch(dummy, dummy<0>) [with unsigned int n = 0]' 18 |double ch(dummy, dummy<0>) | ^~ :24:11: note: candidate: 'double ch(dummy<0>, dummy) [with unsigned int m = 0]' 24 |double ch(dummy<0>, dummy) | ^~
[Bug other/1634] Request for gcc-cvs-patches list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1634 --- Comment #13 from Andrew Pinski --- When we moved to git, gcc-cvs has become what this bug has requested. In that it sends the exact patch which was committed to the list now. An example is https://gcc.gnu.org/pipermail/gcc-cvs/2021-September/352936.html
[Bug target/82139] unnecessary movapd with _mm_castsi128_pd to use BLENDPD on __m128i results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82139 --- Comment #2 from Hongtao.liu --- (In reply to Andrew Pinski from comment #1) > It is worse on the trunk: > .L2: > movdqu (%rdi), %xmm1 > movdqu (%rdi), %xmm0 > addq$16, %rdi > paddd %xmm3, %xmm1 > paddd %xmm2, %xmm0 > blendpd $2, %xmm0, %xmm1 > movups %xmm1, -16(%rdi) > cmpq%rdi, %rax > jne .L2 > > Why two loads from %rdi here? > This is done during RA as far as I can tell. It looks like generic cost model should be updated. w/ -O2 -msse4 -mno-avx -mtune=skylake looks optimal movdqu (%rdi), %xmm0 movdqa %xmm3, %xmm1 paddd %xmm0, %xmm1 paddd %xmm2, %xmm0 blendpd $2, %xmm0, %xmm1 movups %xmm1, (%rdi) addq $16, %rdi cmpq %rdi, %rax jne .L2
