[Bug pch/105858] MinGW-w64 64-bit build with --libstdcxx-pch: fatal error: cannot write PCH file: required memory segment unavailable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105858 --- Comment #6 from Egor Pugin --- Same issue.
[Bug libstdc++/108212] [13 Regression] pretty printers don't work with Python 2 due to imports for chrono
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108212 Jonathan Wakely changed: What|Removed |Added Summary| pretty printers|[13 Regression] pretty |don't work with Python 2|printers don't work with ||Python 2 due to imports for ||chrono Priority|P3 |P1
[Bug libstdc++/108211] std::chrono::current_zone() fails if zone only has one component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108211 --- Comment #1 from Jonathan Wakely --- The obvious solution is to try locate_zone(dir/filename) and if that fails try locate_zone(filename).
[Bug libstdc++/108214] [13 Regression] writinng bitset to stringstream fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108214 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug fortran/108131] [10/11/12/13 Regression] Incorrect bound calculation when bound intrinsic used in size expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108131 --- Comment #4 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:6a95f0e0a06d78d94138d4c3dd64d41591197281 commit r13-4880-g6a95f0e0a06d78d94138d4c3dd64d41591197281 Author: Harald Anlauf Date: Sat Dec 17 22:04:32 2022 +0100 Fortran: incorrect array bounds when bound intrinsic used in decl [PR108131] gcc/fortran/ChangeLog: PR fortran/108131 * array.cc (match_array_element_spec): Avoid too early simplification of matched array element specs that can lead to a misinterpretation when used as array bounds in array declarations. gcc/testsuite/ChangeLog: PR fortran/108131 * gfortran.dg/pr103505.f90: Adjust expected patterns. * gfortran.dg/pr108131.f90: New test.
[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998 --- Comment #11 from James McKelvey --- (In reply to Christophe Lyon from comment #10) > Can you try to revert my patches: > f0d3b6e384a68f8b58bc750f240a15cad92600cd > ccb9c7b129206209cfc315ab1a0432b5f517bdd9 > and remove your patch at comment #5 ? > You should still see the problem you reported in bug #108011 > > > However, I don't understand why you had to do what you describe in comment > #8. When multilibs are disabled, the build shouldn't try to use > MULTILIB_OPTIONS etc... Sorry, I don't use git. I just build from the weekly snapshots. I double-checked by removing the fix, make distclean, and ./configure --enable-languages=c,c++ --enable-threads=posix --disable-multilib and got the same error.
[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102 --- Comment #5 from Andrew Pinski --- (In reply to Stefan Schulze Frielinghaus from comment #4) > and the current working directory was most likely /devel/gcc/build/gcc. > Creating a symlink from $build/stage1-gcc to $build/prev-gcc and then > running the command from above doesn't do the trick. There is probably an > easier way which I miss. Any hints? See stage2-start/stage3-start I think. See https://gcc.gnu.org/onlinedocs/gccint/Makefile.html#Makefile
[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102 --- Comment #4 from Stefan Schulze Frielinghaus --- I was playing around with this and was wondering how can I actually execute the stageN compiler? From the output of make I see two compilations for object rust-hir-trait-resolve.o. Thus the first one must be for stage2 and the second one for stage3. For the former the command line is /devel/gcc/build/./prev-gcc/xg++ -B/devel/gcc/build/./prev-gcc/ -B/devel/gcc/dst/s390x-ibm-linux-gnu/bin/ -nostdinc++ -B/devel/gcc/build/prev-s390x-ibm-linux-gnu/libstdc++-v3/src/.libs -B/devel/gcc/build/prev-s390x-ibm-linux-gnu/libstdc++-v3/libsupc++/.libs -I/devel/gcc/build/prev-s390x-ibm-linux-gnu/libstdc++-v3/include/s390x-ibm-linux-gnu -I/devel/gcc/build/prev-s390x-ibm-linux-gnu/libstdc++-v3/include -I/devel/gcc/src/libstdc++-v3/libsupc++ -L/devel/gcc/build/prev-s390x-ibm-linux-gnu/libstdc++-v3/src/.libs -L/devel/gcc/build/prev-s390x-ibm-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -DIN_GCC_FRONTEND -g -O2 -fno-checking -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wno-unused-parameter -fno-common -DHAVE_CONFIG_H -I. -Irust -I/devel/gcc/src/gcc -I/devel/gcc/src/gcc/rust -I/devel/gcc/src/gcc/../include -I/devel/gcc/src/gcc/../libcpp/include -I/devel/gcc/src/gcc/../libcody -I/devel/gcc/src/gcc/../libdecnumber -I/devel/gcc/src/gcc/../libdecnumber/dpd -I../libdecnumber -I/devel/gcc/src/gcc/../libbacktrace -o rust/rust-hir-trait-resolve.o -MT rust/rust-hir-trait-resolve.o -MMD -MP -MF rust/.deps/rust-hir-trait-resolve.TPo -g -O2 -fno-checking -gtoggle -I /devel/gcc/src/gcc/rust -I /devel/gcc/src/gcc/rust/lex -I /devel/gcc/src/gcc/rust/parse -I /devel/gcc/src/gcc/rust/ast -I /devel/gcc/src/gcc/rust/analysis -I /devel/gcc/src/gcc/rust/backend -I /devel/gcc/src/gcc/rust/expand -I /devel/gcc/src/gcc/rust/hir/tree -I /devel/gcc/src/gcc/rust/hir -I /devel/gcc/src/gcc/rust/resolve -I /devel/gcc/src/gcc/rust/util -I /devel/gcc/src/gcc/rust/typecheck -I /devel/gcc/src/gcc/rust/checks/lints -I /devel/gcc/src/gcc/rust/checks/errors -I /devel/gcc/src/gcc/rust/checks/errors/privacy -I /devel/gcc/src/gcc/rust/util -I /devel/gcc/src/gcc/rust/metadata /devel/gcc/src/gcc/rust/typecheck/rust-hir-trait-resolve.cc and the current working directory was most likely /devel/gcc/build/gcc. Creating a symlink from $build/stage1-gcc to $build/prev-gcc and then running the command from above doesn't do the trick. There is probably an easier way which I miss. Any hints?
[Bug fortran/106731] ICE on automatic array of derived type with DTIO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106731 --- Comment #11 from federico --- Thank you. I can confirm the patch works. I thought that, while fixing the issue, removing the assert was not the best solution as automatic arrays are not supposed to be static. My bad. Happy holidays, Federico
[Bug c++/108216] Wrong offset for (already-constructed) virtual base during construction of full object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108216 --- Comment #3 from Thiago Macieira --- In bug 70644, the pointer to Base was passed to Base's constructor, so the conversion from the derived type to the virtual base Base happened clearly before said base was constructed. In this example here, the conversion happens inside C's constructor body, where C's direct (but virtual) base A must be fully initialised, notwithstanding the fact that it was initialised by D's in-charge constructor. I'm not making a conclusion that this is or isn't UB. I'm saying that it can't be UB for the explanation offered in that bug.
[Bug c++/108216] Wrong offset for (already-constructed) virtual base during construction of full object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108216 --- Comment #2 from Andrew Pinski --- Right reading bug 70644, then this code might be undefined.
[Bug c++/108216] Wrong offset for (already-constructed) virtual base during construction of full object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108216 --- Comment #1 from Arthur O'Dwyer --- Possibly tangentially related: #70644, #81051
[Bug c++/108216] New: Wrong offset for (already-constructed) virtual base during construction of full object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108216
Bug ID: 108216
Summary: Wrong offset for (already-constructed) virtual base
during construction of full object
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
// https://godbolt.org/z/6qMTY6bGn
#include
struct A *ga = nullptr;
struct B *gb = nullptr;
struct C *gc = nullptr;
struct D *gd = nullptr;
struct A {
explicit A() {
printf("Constructing A at %p\n", (void*)this);
ga = this;
printf(" A is %p\n", (void*)ga);
}
virtual void f() {}
void *a() { return this; }
};
struct B : virtual A {
explicit B() {
printf("Constructing B at %p\n", (void*)this);
gb = this;
printf(" B.A is %p\n", (void*)(A*)gb);
}
void *b() { return this; }
};
struct C : virtual A {
explicit C() {
printf("Constructing C at %p\n", (void*)this);
gc = this;
printf(" B.A is %p -- look here!\n", (void*)(A*)gb);
printf(" C.A is %p\n", (void*)(A*)gc);
}
// void f() override {} // give Clang trouble, too
void *c() { return this; }
};
struct D : B, C {
explicit D(): B(), C() {
printf("Constructing D at %p\n", (void*)this);
gd = this;
printf(" D.B.A is %p\n", (void*)(A*)(B*)gd);
printf(" D.C.A is %p\n", (void*)(A*)(C*)gd);
}
};
int main() {
D d;
printf(" is %p\n", (void*));
printf(" is %p\n", d.c());
printf(" is %p\n", d.b());
printf(" is %p\n", d.a());
}
==
Constructing A at 0x7ffd2ef4db10
A is 0x7ffd2ef4db10
Constructing B at 0x7ffd2ef4db10
B.A is 0x7ffd2ef4db10
Constructing C at 0x7ffd2ef4db18
B.A is 0x7ffd2f34ed1c -- look here!
C.A is 0x7ffd2ef4db10
Constructing D at 0x7ffd2ef4db10
D.B.A is 0x7ffd2ef4db10
D.C.A is 0x7ffd2ef4db10
is 0x7ffd2ef4db10
is 0x7ffd2ef4db18
is 0x7ffd2ef4db10
is 0x7ffd2ef4db10
==
Before the line marked "look here":
- The `A` object was constructed at 0x7ffd2ef4db10.
- The `B` object pointed to by `gb` has been completely constructed.
- So `gb->a()` ought to return the address of that `A` object, 0x7ffd2ef4db10.
But instead it returns 0x7ffd2f34ed1c, which is 0x40120c bytes away from the
correct value!
I wonder if this is caused by the B-in-D and C-in-D vptrs having the same
offset, so that when we think we're access the B vtable of `*gb`, we're
actually accessing the C vtable of that empty C object...? But then, still, the
offset from the beginning of the B object or the beginning of the C object, to
the A virtual base, ought to be exactly the same number. I can't figure out a
reason for the answer to be off by 0x40120c.
==
Notice that Clang passes this test case as shown; BUT, if you uncomment the
line marked "give Clang trouble, too", then Clang will join GCC in producing
wrong results for the line marked "look here". MSVC passes both test cases,
but that's not surprising because MSVC has a radically different ABI for struct
layout.
Originally reported by @caster on Slack, here:
https://cpplang.slack.com/archives/CBTFTLR9R/p1671750342552189
[Bug tree-optimization/108215] New: Does not optimize trivial case with bit operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108215
Bug ID: 108215
Summary: Does not optimize trivial case with bit operations
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: socketpair at gmail dot com
Target Milestone: ---
https://godbolt.org/z/5e3eKqPqs
```C
#include
int firewall3(const uint8_t *restrict data) {
const uint32_t src = *((const uint32_t *)data);
if ((src & 0x) == 0x1122) return 1;
if ((src & 0xFF00) == 0x11223300) return 1;
return 0;
}
int firewall4(const uint8_t *restrict data) {
const uint32_t src = *((const uint32_t *)data);
if ((src & 0xFF00) == 0x11223300) return 1;
if ((src & 0x) == 0x1122) return 1;
return 0;
}
```
```
firewall3:
movl(%rdi), %eax
xorw%ax, %ax
cmpl$287440896, %eax
sete%al
movzbl %al, %eax
ret
firewall4:
movl(%rdi), %eax
movl$1, %edx
movl%eax, %ecx
xorb%cl, %cl
cmpl$287453952, %ecx
je .L3
xorw%ax, %ax
xorl%edx, %edx
cmpl$287440896, %eax
sete%dl
.L3:
movl%edx, %eax
ret
```
firewall3(): Excellent!
firewall4(): FAIL!
It's obvious that order of comparisons in this example does not matter. So I
think misoptimisation of firewall4() is a bug.
[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102 Andrew Pinski changed: What|Removed |Added Ever confirmed|1 |0 Status|WAITING |UNCONFIRMED --- Comment #3 from Andrew Pinski --- Moved to middle-end since the code that is causing issues is c++ code. Can you attach the preprocessed source? I wonder if this is a -g0 vs -g issue ...
[Bug rust/108102] rust bootstrap comparison failure on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102 Stefan Schulze Frielinghaus changed: What|Removed |Added CC||stefansf at linux dot ibm.com --- Comment #2 from Stefan Schulze Frielinghaus --- Can confirm. Happens with --with-arch=arch13 and started since adding rust to languages via commit r13-4676-ga75f038c069cc3. $ diff <(objdump -d stage2-gcc/rust/rust-hir-trait-resolve.o) \ <(objdump -d stage3-gcc/rust/rust-hir-trait-resolve.o) 2c2 < stage2-gcc/rust/rust-hir-trait-resolve.o: file format elf64-s390 --- > stage3-gcc/rust/rust-hir-trait-resolve.o: file format elf64-s390 1939,1940c1939,1940 < 24ec: e3 20 f2 50 00 24 stg %r2,592(%r15) < 24f2: e3 30 f1 28 00 04 lg %r3,296(%r15) --- > 24ec: e3 30 f1 28 00 04 lg %r3,296(%r15) > 24f2: e3 20 f2 50 00 24 stg %r2,592(%r15)
[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998 --- Comment #10 from Christophe Lyon --- Can you try to revert my patches: f0d3b6e384a68f8b58bc750f240a15cad92600cd ccb9c7b129206209cfc315ab1a0432b5f517bdd9 and remove your patch at comment #5 ? You should still see the problem you reported in bug #108011 However, I don't understand why you had to do what you describe in comment #8. When multilibs are disabled, the build shouldn't try to use MULTILIB_OPTIONS etc...
[Bug middle-end/108209] goof in genmatch.cc:commutative_op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108209 --- Comment #1 from Alexander Monakov --- Keeping notes as I go... Duplicated checks for 'op0' in lower_for are duplicated.
[Bug libstdc++/108214] [13 Regression] writinng bitset to stringstream fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108214 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-12-23 Ever confirmed|0 |1 Target Milestone|--- |13.0 Summary|writinng bitset to |[13 Regression] writinng |stringstream fails |bitset to stringstream ||fails Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- I suspect r13-2998-g1c12a3cfdfabf6 is causing this. Confirmed.
[Bug target/106877] [12 Regression] ICE in move_for_stack_reg, at reg-stack.cc:1076 since r12-248-gb58dc0b803057c0e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106877 Roger Sayle changed: What|Removed |Added Target Milestone|12.3|13.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Roger Sayle --- Please let me know if you'd like this backported to the gcc-12 release branch, but I'm assuming that a low priority ICE-on-invalid means we can now consider this closed.
[Bug c++/108214] New: writinng bitset to stringstream fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108214
Bug ID: 108214
Summary: writinng bitset to stringstream fails
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rhalbersma at gmail dot com
Target Milestone: ---
#include
#include
int main() {
using T = std::bitset<1>;
T a(1);
T b;
std::stringstream sstr;
sstr << a;
sstr >> b;
}
The above program works correctly for g++ until version 12, but for version 13
(trunk) it errors out with: "terminate called after throwing an instance of
'std::invalid_argument' what(): bitset::_M_copy_from_ptr"
Godbolt link: https://godbolt.org/z/nnKT6cddb
[Bug c++/108116] [12 Regression] ICE in check_noexcept_r, at cp/except.cc:1074 since r12-6897-gdec8d0e5fa00ceb2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108116 Patrick Palka changed: What|Removed |Added Known to work||13.0 Summary|[12/13 Regression] ICE in |[12 Regression] ICE in |check_noexcept_r, at|check_noexcept_r, at |cp/except.cc:1074 since |cp/except.cc:1074 since |r12-6897-gdec8d0e5fa00ceb2 |r12-6897-gdec8d0e5fa00ceb2 --- Comment #5 from Patrick Palka --- Fixed on trunk so far
[Bug c++/108116] [12/13 Regression] ICE in check_noexcept_r, at cp/except.cc:1074 since r12-6897-gdec8d0e5fa00ceb2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108116
--- Comment #4 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:cf59c8983ef6590f0d69014f8dc8778b5b7691c6
commit r13-4879-gcf59c8983ef6590f0d69014f8dc8778b5b7691c6
Author: Patrick Palka
Date: Fri Dec 23 11:17:45 2022 -0500
c++: get_nsdmi in template context [PR108116]
Here during ahead of time checking of C{}, we indirectly call get_nsdmi
for C::m from finish_compound_literal, which in turn calls
break_out_target_exprs for C::m's (non-templated) initializer, during
which we build a call to A::~A and check expr_noexcept_p for it (from
build_vec_delete_1). But this is all done with processing_template_decl
set, so the built A::~A call is templated (whose form was recently
changed by r12-6897-gdec8d0e5fa00ceb2) which expr_noexcept_p doesn't
expect, and we crash.
This patch fixes this by clearing processing_template_decl before
the call to break_out_target_exprs from get_nsdmi. And since it more
generally seems we shouldn't be seeing (or producing) non-templated
trees in break_out_target_exprs, this patch also adds an assert to
that effect.
PR c++/108116
gcc/cp/ChangeLog:
* constexpr.cc (maybe_constant_value): Clear
processing_template_decl before calling break_out_target_exprs.
* init.cc (get_nsdmi): Likewise.
* tree.cc (break_out_target_exprs): Assert processing_template_decl
is cleared.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/nsdmi-template24.C: New test.
[Bug c/107947] __has_c_attribute incorrectly identifies attribute as supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107947 Andrew Pinski changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #6 from Andrew Pinski --- *** Bug 108213 has been marked as a duplicate of this bug. ***
[Bug c/108213] [[noreturn]] cannot be used after static keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108213 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- It is a bug in the timezone sources. *** This bug has been marked as a duplicate of bug 107947 ***
[Bug c/107993] ICE: tree check: expected string_cst, have integer_cst in get_target_clone_attr_len, at tree.cc:14872
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107993 Martin Liška changed: What|Removed |Added Keywords||patch --- Comment #3 from Martin Liška --- Patch candidate: https://gcc.gnu.org/pipermail/gcc-patches/2022-December/609060.html
[Bug c/108213] New: [[noreturn]] cannot be used after static keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108213
Bug ID: 108213
Summary: [[noreturn]] cannot be used after static keyword
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: jsm28 at gcc dot gnu.org
Target Milestone: ---
I noticed that in timezone package:
$ cat zic.i && gcc-12 zic.i -c
static _Noreturn void
time_overflow(void)
{
__builtin_abort ();
}
$ cat zic.i && gcc-12 zic.i -c
static [[noreturn]] void
time_overflow(void)
{
__builtin_abort ();
}
zic.i:1:1: warning: ‘noreturn’ attribute ignored [-Wattributes]
1 | static [[noreturn]] void
| ^~
zic.i:1:21: error: expected identifier or ‘(’ before ‘void’
1 | static [[noreturn]] void
| ^~~~
Is it really an invalid construction?
[Bug sanitizer/108085] gcc trunk's ASAN at -O3 missed a stack-use-after-scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108085 Martin Liška changed: What|Removed |Added Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug sanitizer/108085] gcc trunk's ASAN at -O3 missed a stack-use-after-scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108085 --- Comment #3 from Martin Liška --- Created attachment 54153 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54153=edit pr108085.c.216t.uncprop1.dot.svg So no, it's a real issue where we optimize out .ASAN_CHECK (6, , 4, 8); in the exit block. As seen in the dump file, we have the very ASAN_CHECK in bb_3: .ASAN_CHECK (7, , 4, 8), however, there are 2 ASAN_MARK (POISON, , 4) calls that are on the path from bb_3 to the exit block. @Jakub: Can you please take a look at the optimization algorithm why the check is not preserved?
[Bug tree-optimization/108068] [10/11/12 Regression] decimal floating point signed zero is not honored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108068 Jakub Jelinek changed: What|Removed |Added Summary|[10/11/12/13 Regression]|[10/11/12 Regression] |decimal floating point |decimal floating point |signed zero is not honored |signed zero is not honored --- Comment #12 from Jakub Jelinek --- Fixed on the trunk for now.
[Bug tree-optimization/108068] [10/11/12/13 Regression] decimal floating point signed zero is not honored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108068 --- Comment #11 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:fd1b0aefda5b65f3f841ca6e61ccea6a72daa060 commit r13-4877-gfd1b0aefda5b65f3f841ca6e61ccea6a72daa060 Author: Jakub Jelinek Date: Fri Dec 23 16:12:21 2022 +0100 tree-ssa-dom: can_infer_simple_equiv fixes [PR108068] As reported in the PR, tree-ssa-dom.cc uses real_zerop call to find if a floating point constant is zero and it shouldn't try to infer equivalences from comparison against it if signed zeros are honored. This doesn't work at all for decimal types, because real_zerop always returns false for them (one can have different representations of decimal zero beyond -0/+0), and it doesn't work for vector compares either, as real_zerop checks if all elements are zero, while we need to avoid infering equivalences from comparison against vector constants which have at least one zero element in it (if signed zeros are honored). Furthermore, as mentioned by Joseph, for decimal types many other values aren't singleton. So, this patch stops infering anything if element mode is decimal, and otherwise uses instead of real_zerop a new function, real_maybe_zerop, which will work even for decimal types and for complex or vector will return true if any element is or might be zero (so it returns true for anything but constants for now). 2022-12-23 Jakub Jelinek PR tree-optimization/108068 * tree.h (real_maybe_zerop): Declare. * tree.cc (real_maybe_zerop): Define. * tree-ssa-dom.cc (record_edge_info): Use it instead of real_zerop or TREE_CODE (op1) == SSA_NAME || real_zerop. Always set can_infer_simple_equiv to false for decimal floating point types. * gcc.dg/dfp/pr108068.c: New test.
[Bug c++/87697] Casting a base class to derived gives no warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87697 Arthur O'Dwyer changed: What|Removed |Added CC||arthur.j.odwyer at gmail dot com --- Comment #4 from Arthur O'Dwyer --- jynelson: Static-casting from Base& to Derived& is the foundation of the "Curiously Recurring Template Pattern" in C++, and therefore can't be allowed to trigger any diagnostic with -Wall -Wextra. (Many industry codebases build with -Wall -Wextra, and also use the CRTP.) *Aside* from that practical consideration, I don't think there's anything wrong with casting from one type to another. The point of type-cast syntax is to say "Don't worry, compiler, I know what I'm doing." If one doesn't know what one's doing, then one shouldn't use casts at all, and just stick to the implicit conversions. It's already an error to *implicitly convert* from Base& to Derived&, so if you stick to implicit conversions you'll get exactly the behavior you want. Suggest closing this issue as NOTABUG. But see also #96765 (for this kind of cast specifically *inside a constructor*).
[Bug libstdc++/108212] pretty printers don't work with Python 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108212 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 Target Milestone|--- |13.0 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-12-23
[Bug libstdc++/108212] New: pretty printers don't work with Python 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108212 Bug ID: 108212 Summary: pretty printers don't work with Python 2 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- ImportError: cannot import name timezone
[Bug libstdc++/108211] std::chrono::current_zone() fails if zone only has one component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108211 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |13.0 Last reconfirmed||2022-12-23 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1
[Bug libstdc++/108211] New: std::chrono::current_zone() fails if zone only has one component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108211 Bug ID: 108211 Summary: std::chrono::current_zone() fails if zone only has one component Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- $ ls -l /etc/localtime lrwxrwxrwx. 1 root root 25 Mar 15 2017 /etc/localtime -> ../usr/share/zoneinfo/UTC Libstdc++ incorrectly assumes the local timezone will be "foo/bar" and so it breaks for "UTC" or any other name without a slash in it. terminate called after throwing an instance of 'std::runtime_error' what(): tzdb: cannot determine current zone This causes: FAIL: std/time/tzdb/1.cc execution test FAIL: std/time/zoned_time/custom.cc execution test
[Bug c++/107853] [10/11/12 Regression] variadic template with a variadic template friend with a requires of fold expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107853 Patrick Palka changed: What|Removed |Added Summary|[10/11/12/13 Regression]|[10/11/12 Regression] |variadic template with a|variadic template with a |variadic template friend|variadic template friend |with a requires of fold |with a requires of fold |expression |expression Known to work||13.0 --- Comment #6 from Patrick Palka --- Fixed on trunk so far
[Bug c++/107853] [10/11/12/13 Regression] variadic template with a variadic template friend with a requires of fold expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107853
--- Comment #5 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:bd1fc4a219d8c0fad0ec41002e895b49e384c1c2
commit r13-4876-gbd1fc4a219d8c0fad0ec41002e895b49e384c1c2
Author: Patrick Palka
Date: Fri Dec 23 09:18:37 2022 -0500
c++: template friend with variadic constraints [PR107853]
When instantiating a constrained hidden template friend, we substitute
into its template-head requirements in tsubst_friend_function. For this
substitution we use the template's full argument vector whose outer
levels correspond to the instantiated class's arguments and innermost
level corresponds to the template's own level-lowered generic arguments.
But for A::f here, for which the relevant argument vector is
{{int}, {Us...}}, the substitution into (C && ...) triggers the
assert in use_pack_expansion_extra_args_p since one argument is a pack
expansion and the other isn't.
And for A::f, for which the relevant argument vector is
{{int, int}, {Us...}}, the use_pack_expansion_extra_args_p assert would
also trigger but we first get a bogus "mismatched argument pack lengths"
error from tsubst_pack_expansion.
Sidestepping the question of whether tsubst_pack_expansion should be
able to handle such substitutions, it seems we can work around this by
using only the instantiated class's arguments and not also the template
friend's own generic arguments, which is consistent with how we normally
substitute into the signature of a member template.
PR c++/107853
gcc/cp/ChangeLog:
* constraint.cc (maybe_substitute_reqs_for): Substitute into
the template-head requirements of a template friend using only
its outer arguments via outer_template_args.
* cp-tree.h (outer_template_args): Declare.
* pt.cc (outer_template_args): Define, factored out and
generalized from ...
(ctor_deduction_guides_for): ... here.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-friend12.C: New test.
* g++.dg/cpp2a/concepts-friend13.C: New test.
[Bug tree-optimization/107767] [13 Regression] switch to table conversion happening even though using btq is better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107767 --- Comment #15 from Martin Liška --- @Richi: Please send the patch for switch conversion in the next stage 1.
[Bug c++/108203] Format string checking with __USE_MINGW_ANSI_STDIO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108203 --- Comment #2 from LIU Hao --- (In reply to nightstrike from comment #0) > Bug report that came from it: > https://sourceforge.net/p/mingw-w64/bugs/292/ > I think this should be no longer the case. Two years ago I submitted a patch that made the `ms_printf` attribute accept `%lld`, so there is now a universal modifier for `long long`. The issue here looks like that `printf` , which is a 'well known' function to GCC, has a pre-defined attribute. If a new `*_printf` attribute is declared, it gets both, as pointed out by Andrew Pinski.
[Bug libstdc++/108210] error: 'mutex' does not name a type; did you mean 'minutes'? for x86_64-w64-mingw32 target with win32 thread model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108210 cqwrteur changed: What|Removed |Added CC||unlvsur at live dot com --- Comment #1 from cqwrteur --- Created attachment 54152 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54152=edit config
[Bug libstdc++/108210] New: error: 'mutex' does not name a type; did you mean 'minutes'? for x86_64-w64-mingw32 target with win32 thread model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108210 Bug ID: 108210 Summary: error: 'mutex' does not name a type; did you mean 'minutes'? for x86_64-w64-mingw32 target with win32 thread model Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- /home/cqwrteur/toolchains_build/gcc/libstdc++-v3/src/c++20/tzdb.cc:565:5: error: 'mutex' does not name a type; did you mean 'minutes'? 565 | mutex infos_mutex; | ^ | minutes Win32 thread model does not provide mutex, lock_guard, and other threading mechanism. However. this can be implemented easily with win32 CriticalSection API. https://github.com/cppfastio/fast_io/blob/master/include/fast_io_hosted/threads/mutex/win32_critical_section.h
[Bug middle-end/108209] New: goof in genmatch.cc:commutative_op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108209
Bug ID: 108209
Summary: goof in genmatch.cc:commutative_op
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
It pretends that define_operator_list is commutative when its first member is
NOT commutative:
if (user_id *uid = dyn_cast (id))
{
int res = commutative_op (uid->substitutes[0]);
if (res < 0)
return 0;
for (unsigned i = 1; i < uid->substitutes.length (); ++i)
if (res != commutative_op (uid->substitutes[i]))
return -1;
return res;
}
The first 'return 0' should be 'return -1' instead.
[Bug target/108208] Bad assembly? on large LLVM source files on powerpc-unknown-linux-gnu (Error: operand out of range)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108208 --- Comment #1 from Sam James --- Ah, based on https://bugzilla.redhat.com/show_bug.cgi?id=427700#c3 & https://bugzilla.redhat.com/show_bug.cgi?id=427700#c5, maybe the source really does just need splitting.
[Bug c++/108207] ICE in testcase g++.dg/other/ptrmem8.C on mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108207 --- Comment #1 from nightstrike --- Ah, Andrew, before you beat me to it... this doesn't ICE if you pass -fno-ms-extensions, and it does ICE on Linux if you pass -fms-extensions
[Bug target/108208] New: Build failure on large LLVM source files on PPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108208 Bug ID: 108208 Summary: Build failure on large LLVM source files on PPC Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sam at gentoo dot org Target Milestone: --- We've seen this a few times in Gentoo when building LLVM, but this is the latest case. ``` $ gcc --version gcc (Gentoo 13.0.0_pre20221218 p5) 13.0.0 20221218 (experimental) Copyright (C) 2022 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ``` ``` /usr/bin/c++ -save-temps -O2 -g -pipe -fsanitize=undefined -std=c++17 -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -ffunction-sections -fdata-sections -fno-exceptions -fno-rtti RegisterInfoEmitter.cpp.ii [...] a-RegisterInfoEmitter.cpp.s:577996: Error: operand out of range (0x9d8c is not between 0x8000 and 0x7fff) a-RegisterInfoEmitter.cpp.s:578007: Error: operand out of range (0x9d10 is not between 0x8000 and 0x7fff) a-RegisterInfoEmitter.cpp.s:578016: Error: operand out of range (0x9d18 is not between 0x8000 and 0x7fff) a-RegisterInfoEmitter.cpp.s:578024: Error: operand out of range (0x9d14 is not between 0x8000 and 0x7fff) a-RegisterInfoEmitter.cpp.s:578042: Error: operand out of range (0x9d84 is not between 0x8000 and 0x7fff) a-RegisterInfoEmitter.cpp.s:578061: Error: operand out of range (0x9d5c is not between 0x8000 and 0x7fff) a-RegisterInfoEmitter.cpp.s:578071: Error: operand out of range (0x9d68 is not between 0x8000 and 0x7fff) [...] ``` I've uploaded gcc-RegisterInfoEmitter-ppc.tar.xz at https://dev.gentoo.org/~sam/bugs/gcc/gcc-RegisterInfoEmitter-ppc/gcc-RegisterInfoEmitter-ppc.tar.xz (because of the size of the files) which contains: ``` -rw-r--r-- 1 root root 2.8M Dec 23 10:35 gcc-RegisterInfoEmitter-ppc/RegisterInfoEmitter.cpp.ii -rw-r--r-- 1 root root 42M Dec 23 10:45 gcc-RegisterInfoEmitter-ppc/a-RegisterInfoEmitter.cpp.s ``` Minimising is hard because it only happens with large source files and it's also time consuming to compile and get the error. (Sorry for external link, it's too big even when compressed to attach here, as it's 4MB.)
[Bug c++/108207] New: ICE in testcase g++.dg/other/ptrmem8.C on mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108207
Bug ID: 108207
Summary: ICE in testcase g++.dg/other/ptrmem8.C on mingw
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
All variants of this test fail (98, 14, 17, 20)
// Target: x86_64-w64-mingw32
// Configured with: ../configure --disable-nls --with-sysroot=/tmp/rtmingw
--target=x86_64-w64-mingw32 --disable-multilib
--enable-languages=c,c++,fortran,lto,objc,obj-c++,m2,rust
// Thread model: win32
// Supported LTO compression algorithms: zlib zstd
// gcc version 13.0.0 20221222 (experimental) (GCC)
bbe04bade0cc3b17e62c2af3d89b899367e7d2d1
g++.dg/other/ptrmem8.C: In function 'void foo(void (A::*)())':
g++.dg/other/ptrmem8.C:9:9: internal compiler error: in build_ptrmemfunc, at
cp/typeck.cc:10015
0x7f38c0 build_ptrmemfunc(tree_node*, tree_node*, int, bool, int)
../../gcc/cp/typeck.cc:10015
0xc643bb cp_build_addr_expr_1
../../gcc/cp/typeck.cc:7241
0xc64704 cp_build_addr_expr_strict
../../gcc/cp/typeck.cc:7269
0xc64704 build_x_unary_op(unsigned int, tree_code, cp_expr, tree_node*, int)
../../gcc/cp/typeck.cc:6890
0xb9b7c3 cp_parser_unary_expression
../../gcc/cp/parser.cc:9039
0xb688bc cp_parser_binary_expression
../../gcc/cp/parser.cc:10101
0xb69612 cp_parser_assignment_expression
../../gcc/cp/parser.cc:10444
0xb6ba73 cp_parser_expression
../../gcc/cp/parser.cc:10614
0xb6fa07 cp_parser_expression_statement
../../gcc/cp/parser.cc:12758
0xb7aced cp_parser_statement
../../gcc/cp/parser.cc:12538
0xb7bfdd cp_parser_statement_seq_opt
../../gcc/cp/parser.cc:12909
0xb7c0b7 cp_parser_compound_statement
../../gcc/cp/parser.cc:12861
0xb9ea55 cp_parser_function_body
../../gcc/cp/parser.cc:25280
0xb9ea55 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.cc:25331
0xba09fe cp_parser_function_definition_after_declarator
../../gcc/cp/parser.cc:31942
0xba1eb0 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.cc:31859
0xba1eb0 cp_parser_init_declarator
../../gcc/cp/parser.cc:22734
0xba928e cp_parser_single_declaration
../../gcc/cp/parser.cc:32459
0xba94b4 cp_parser_template_declaration_after_parameters
../../gcc/cp/parser.cc:32012
0xba9d40 cp_parser_explicit_template_declaration
../../gcc/cp/parser.cc:32285
Preprocessed source is as you might expect, given the lack of includes:
struct A {};
template void foo(void (A::* f)())
{
A a;
&(a.*f);
}
template void bar(void (A::* f)())
{
A *p;
&(p->*f);
}
[Bug target/107548] STV doesn't consider vec_select
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107548
--- Comment #1 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:0b2c1369d035e92847cca81fd9f7b4e9ab9da710
commit r13-4873-g0b2c1369d035e92847cca81fd9f7b4e9ab9da710
Author: Roger Sayle
Date: Fri Dec 23 09:56:30 2022 +
PR target/107548: Handle vec_select in STV on x86.
This patch enhances x86's STV pass to handle VEC_SELECT during general
scalar chain conversion, performing SImode scalar extraction from V4SI
and DImode scalar extraction from V2DI in vector registers.
The motivating test case from bugzilla is:
typedef unsigned int v4si __attribute__((vector_size(16)));
unsigned int f (v4si a, v4si b)
{
a[0] += b[0];
return a[0] + a[1];
}
currently with -O2 -march=znver2 this generates:
vpextrd $1, %xmm0, %edx
vmovd %xmm0, %eax
addl%edx, %eax
vmovd %xmm1, %edx
addl%edx, %eax
ret
which performs three transfers from the vector unit to the scalar unit,
and performs the two additions there. With this patch, we now generate:
vmovdqa %xmm0, %xmm2
vpshufd $85, %xmm0, %xmm0
vpaddd %xmm0, %xmm2, %xmm0
vpaddd %xmm1, %xmm0, %xmm0
vmovd %xmm0, %eax
ret
which performs the two additions in the vector unit, and then transfers
the result to the scalar unit. Technically the (cheap) movdqa isn't
needed with better register allocation (or this could be cleaned up
during peephole2), but even so this transform is still a win.
2022-12-23 Roger Sayle
gcc/ChangeLog
PR target/107548
* config/i386/i386-features.cc (scalar_chain::add_insn): The
operands of a VEC_SELECT don't need to added to the scalar chain.
(general_scalar_chain::compute_convert_gain) :
Provide gains for performing STV on a VEC_SELECT.
(general_scalar_chain::convert_insn): Convert VEC_SELECT to pshufd,
psrldq or no-op.
(general_scalar_to_vector_candidate_p): Handle VEC_SELECT of a
single element from a vector register to a scalar register.
gcc/testsuite/ChangeLog
PR target/107548
* gcc.target/i386/pr107548-1.c: New test V4SI case.
* gcc.target/i386/pr107548-2.c: New test V2DI case.
[Bug target/106933] [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) since r13-2049-g6f94923dea21bd92
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106933 --- Comment #8 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:24a7980d0f48671ea13da18c9162a43420b5af58 commit r13-4872-g24a7980d0f48671ea13da18c9162a43420b5af58 Author: Roger Sayle Date: Fri Dec 23 09:50:18 2022 + PR target/106933: Limit TImode STV to SSA-like def-use chains on x86. With many thanks to H.J. for doing all the hard work, this patch resolves two P1 regressions; PR target/106933 and PR target/106959. Although superficially similar, the i386 backend's two scalar-to-vector (STV) passes perform their transformations in importantly different ways. The original pass converting SImode and DImode operations to V4SImode or V2DImode operations is "soft", allowing values to be maintained in both integer and vector hard registers. The newer pass converting TImode operations to V1TImode is "hard" (all or nothing) that converts all uses of a pseudo to vector form. To implement this it invokes powerful ju-ju calling SET_MODE on a reg_rtx, which due to RTL sharing, often updates this pseudo's mode everywhere in the RTL chain. Hence, TImode STV can only be performed when all uses of a pseudo are convertible to V1TImode form. To ensure this the STV passes currently use data-flow analysis to inspect all DEFs and USEs in a chain. This works fine for chains that are in the usual single assignment form, but the occurrence of uninitialized variables, or multiple assignments that split a pseudo's usage into several independent chains (lifetimes) can lead to situations where some but not all of a pseudo's occurrences need to be updated. This is safe for the SImode/DImode pass, but leads to the above bugs during the TImode pass. My one minor tweak to HJ's patch from comment #4 of bugzilla PR106959 is to only perform the new single_def_chain_p check for TImode STV; it turns out that STV of SImode/DImode min/max operates safely on multiple-def chains, and prohibiting this leads to testsuite regressions. We don't (yet) support V1TImode min/max, so this idiom isn't an issue during the TImode STV pass. For the record, the two alternate possible fixes are (i) make the TImode STV pass "soft", by eliminating use of SET_MODE, instead using replace_rtx with a new pseudo, or (ii) merging "chains" so that multiple DFA chains/lifetimes are considered a single STV chain. 2022-12-23 H.J. Lu Roger Sayle gcc/ChangeLog PR target/106933 PR target/106959 * config/i386/i386-features.cc (single_def_chain_p): New predicate function to check that a pseudo's use-def chain is in SSA form. (timode_scalar_to_vector_candidate_p): Check that TImode regs that are SET_DEST or SET_SRC of an insn match/are single_def_chain_p. gcc/testsuite/ChangeLog PR target/106933 PR target/106959 * gcc.target/i386/pr106933-1.c: New test case. * gcc.target/i386/pr106933-2.c: Likewise. * gcc.target/i386/pr106959-1.c: Likewise. * gcc.target/i386/pr106959-2.c: Likewise. * gcc.target/i386/pr106959-3.c: Likewise.
[Bug target/106959] [13 Regression] ICE in curr_insn_transform, at lra-constraints.cc:4168 (error: unable to generate reloads), or ICE in simplify_subreg, at simplify-rtx.cc:7405 since r13-2100-g5cccc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106959 --- Comment #5 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:24a7980d0f48671ea13da18c9162a43420b5af58 commit r13-4872-g24a7980d0f48671ea13da18c9162a43420b5af58 Author: Roger Sayle Date: Fri Dec 23 09:50:18 2022 + PR target/106933: Limit TImode STV to SSA-like def-use chains on x86. With many thanks to H.J. for doing all the hard work, this patch resolves two P1 regressions; PR target/106933 and PR target/106959. Although superficially similar, the i386 backend's two scalar-to-vector (STV) passes perform their transformations in importantly different ways. The original pass converting SImode and DImode operations to V4SImode or V2DImode operations is "soft", allowing values to be maintained in both integer and vector hard registers. The newer pass converting TImode operations to V1TImode is "hard" (all or nothing) that converts all uses of a pseudo to vector form. To implement this it invokes powerful ju-ju calling SET_MODE on a reg_rtx, which due to RTL sharing, often updates this pseudo's mode everywhere in the RTL chain. Hence, TImode STV can only be performed when all uses of a pseudo are convertible to V1TImode form. To ensure this the STV passes currently use data-flow analysis to inspect all DEFs and USEs in a chain. This works fine for chains that are in the usual single assignment form, but the occurrence of uninitialized variables, or multiple assignments that split a pseudo's usage into several independent chains (lifetimes) can lead to situations where some but not all of a pseudo's occurrences need to be updated. This is safe for the SImode/DImode pass, but leads to the above bugs during the TImode pass. My one minor tweak to HJ's patch from comment #4 of bugzilla PR106959 is to only perform the new single_def_chain_p check for TImode STV; it turns out that STV of SImode/DImode min/max operates safely on multiple-def chains, and prohibiting this leads to testsuite regressions. We don't (yet) support V1TImode min/max, so this idiom isn't an issue during the TImode STV pass. For the record, the two alternate possible fixes are (i) make the TImode STV pass "soft", by eliminating use of SET_MODE, instead using replace_rtx with a new pseudo, or (ii) merging "chains" so that multiple DFA chains/lifetimes are considered a single STV chain. 2022-12-23 H.J. Lu Roger Sayle gcc/ChangeLog PR target/106933 PR target/106959 * config/i386/i386-features.cc (single_def_chain_p): New predicate function to check that a pseudo's use-def chain is in SSA form. (timode_scalar_to_vector_candidate_p): Check that TImode regs that are SET_DEST or SET_SRC of an insn match/are single_def_chain_p. gcc/testsuite/ChangeLog PR target/106933 PR target/106959 * gcc.target/i386/pr106933-1.c: New test case. * gcc.target/i386/pr106933-2.c: Likewise. * gcc.target/i386/pr106959-1.c: Likewise. * gcc.target/i386/pr106959-2.c: Likewise. * gcc.target/i386/pr106959-3.c: Likewise.
[Bug c++/108206] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in merge_default_template_args, at cp/decl.cc:1563 since r12-7562-gfe548eb8436f3906
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108206 Martin Liška changed: What|Removed |Added Summary|ICE: tree check: expected |ICE: tree check: expected |tree that contains 'decl|tree that contains 'decl |minimal' structure, have|minimal' structure, have |'error_mark' in |'error_mark' in |merge_default_template_args |merge_default_template_args |, at cp/decl.cc:1563|, at cp/decl.cc:1563 since ||r12-7562-gfe548eb8436f3906 Status|UNCONFIRMED |NEW Last reconfirmed||2022-12-23 Target Milestone|--- |12.3 CC||marxin at gcc dot gnu.org, ||ppalka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Started with r12-7562-gfe548eb8436f3906.
[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107532 --- Comment #2 from Martin Liška --- @Marek: PING
