[Bug driver/103465] [12 regression] -freorder-blocks-and-partition broken on 64-bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465 Eric Botcazou changed: What|Removed |Added Resolution|FIXED |--- Severity|normal |major Status|RESOLVED|REOPENED CC||ebotcazou at gcc dot gnu.org Summary|Invalid note with |[12 regression] |-fno-reorder-blocks-and-par |-freorder-blocks-and-partit |tition |ion broken on 64-bit ||Windows --- Comment #18 from Eric Botcazou --- The fix does more harm than good though since it disables -freorder-blocks-and-partition entirely for 64-bit Windows.
[Bug target/95737] PPC: Unnecessary extsw after negative less than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95737
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
--- Comment #6 from HaoChen Gui ---
//source code
unsigned long long negativeLessThan(unsigned long long a, unsigned long long b)
{
return -(a < b);
}
//P8 with -O2
subfc 4,4,3
subfe 3,3,3
extsw 3,3
//P9 with -O2
li 10,0
li 9,1
cmpld 0,3,4
isel 3,9,10,0
neg 3,3
Seems cmp+isel on P9 is sub-optimal.
[Bug tree-optimization/80857] slow compare_exchange_weak with unintegral type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80857 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement Status|UNCONFIRMED |NEW Last reconfirmed||2022-01-06 Ever confirmed|0 |1 Component|middle-end |tree-optimization --- Comment #2 from Andrew Pinski --- In the scalar case we change it to be: _12 = (long unsigned int) current_9; _13 = .ATOMIC_COMPARE_EXCHANGE ([(const struct __atomic_base *)]._M_i, _12, __i2.17_11, 264, 5, 5); _14 = IMAGPART_EXPR <_13>; _15 = REALPART_EXPR <_13>; While in the case of the struct we keep it as: _20 = __atomic_compare_exchange_8 (_M_i, , _12, 1, 5, 5); if (_20 != 0) I wonder if we should instead just use a VCE here to get the perfomance back.
[Bug middle-end/92455] Unnecessary memory read in a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92455 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug middle-end/78874] Manual describes "-Wno-aggressive-loop-optimizations" as if without "no-"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78874 --- Comment #2 from Andrew Pinski --- @item -Wno-aggressive-loop-optimizations @opindex Wno-aggressive-loop-optimizations @opindex Waggressive-loop-optimizations Warn if in a loop with constant number of iterations the compiler detects undefined behavior in some statement during one or more of the iterations.
[Bug middle-end/78874] Manual describes "-Wno-aggressive-loop-optimizations" as if without "no-"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78874 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-01-06 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug target/103926] "wQ" broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103926 --- Comment #4 from Andrew Pinski --- (In reply to Alexey Kardashevskiy from comment #3) > Documented here: > https://dmalcolm.fedorapeople.org/gcc/2015-08-31/rst-experiment/how-to-use- > inline-assembly-language-in-c-code.html Not documented in user's manual though: https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/Machine-Constraints.html#Machine-Constraints It is documented in the internals manual which is be expected (it is not supposed to be used by the user): https://gcc.gnu.org/onlinedocs/gccint/Machine-Constraints.html#Machine-Constraints
[Bug c++/82125] Suboptimal error message for range-based for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82125 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug c++/54299] Array parameter does not allow for iterator syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54299 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug c++/54299] Array parameter does not allow for iterator syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54299 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-01-06 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- Clang gives even better diagnostic now: :7:17: error: cannot build range expression with array function parameter 'arr' since parameter with array type 'int[10]' is treated as pointer type 'int *' for (auto i : arr) ^~~ :4:11: note: declared here int f(int arr[10]) ^ GCC trunk gives: : In function 'int f(int*)': :7:17: error: 'begin' was not declared in this scope 7 | for (auto i : arr) | ^~~ :7:17: error: 'end' was not declared in this scope
[Bug target/103926] "wQ" broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103926
--- Comment #3 from Alexey Kardashevskiy ---
Documented here:
https://dmalcolm.fedorapeople.org/gcc/2015-08-31/rst-experiment/how-to-use-inline-assembly-language-in-c-code.html
Your example does not compile either (but does not crash :) )
This one does compile:
asm volatile("lq %0, %1" : "=" (v) : "wQ" (*(__int128 *)ptr));
Anyway, I posted this bug because of the crash than anything else.
[Bug middle-end/51867] GCC generates inconsistent code for same sources calling builtin calls, like sqrtf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51867 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Keywords||missed-optimization Resolution|--- |FIXED Target Milestone|--- |4.7.0 --- Comment #6 from Andrew Pinski --- Fixed.
[Bug middle-end/46106] Error in Manpage? -fstack-protection => -fstack-protector(-all)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46106 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Keywords||documentation Target Milestone|--- |12.0 --- Comment #2 from Andrew Pinski --- Just fixed last month for GCC 12 by r12-6040.
[Bug gcov-profile/45272] comment about sqrt() implementation wrong: it is not from Carmack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45272 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-01-06 CC||marxin at gcc dot gnu.org Component|middle-end |gcov-profile --- Comment #2 from Andrew Pinski --- The code really should be removed and moved away from really. It depends on the host floating point which is wrong thing to do. As shown in PR 45273. Also this code is only enabled for -fauto-profile (which is broken) or if you use -fprofile-correction directly.
[Bug middle-end/39552] Unnecessary stack usage with flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39552 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||missed-optimization Blocks||101926 Last reconfirmed||2022-01-06 Severity|normal |enhancement Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101926 [Bug 101926] [meta-bug] struct/complex argument passing and return should be improved
[Bug target/103925] Missing int3 in ix86_output_indirect_function_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103925 --- Comment #3 from Andrew Pinski --- The bug is in ix86_output_indirect_function_return.
[Bug target/103925] Missing int3 in ix86_output_indirect_function_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103925 H.J. Lu changed: What|Removed |Added Status|WAITING |NEW --- Comment #2 from H.J. Lu --- (In reply to Andrew Pinski from comment #1) > > jmp *%rcx Missing int3 > > > Can you expand on why you think int3 is missing here? -mharden-sls=all should generate INT3 after indirect jmp.
[Bug target/103925] Missing int3 in ix86_output_indirect_function_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103925 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2022-01-06 --- Comment #1 from Andrew Pinski --- > jmp *%rcx Missing int3 Can you expand on why you think int3 is missing here?
[Bug fortran/103898] [12 Regression] ICE: gimplification failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103898 sandra at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |sandra at gcc dot gnu.org --- Comment #7 from sandra at gcc dot gnu.org --- Yeah, the implementation of the SIZE intrinsic is pretty borked. I'm working on it.
[Bug target/103926] "wQ" broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103926
Andrew Pinski changed:
What|Removed |Added
Keywords|ice-on-valid-code |ice-on-invalid-code
--- Comment #2 from Andrew Pinski ---
The constraint is not documented even because it looks like an internal only
one:
;; Lq/stq validates the address for load/store quad
(define_memory_constraint "wQ"
"@internal Memory operand suitable for the load/store quad instructions."
(match_operand 0 "quad_memory_operand"))
Note your inline-asm is broken but GCC should not be crashing.
I think the following will work:
__int128 f(void *ptr)
{
__int128 v;
asm volatile("lq %0, 0(%1)" : "=" (v) : "wQ" (*(__int128 *)ptr));
return v;
}
But there still some other stuff that you need to do.
The constraint is failing because you don't have a memory passed to the
inline-asm only the register and it is the wrong size, it is a 64bit rather
than 128bit.
[Bug target/103926] "wQ" broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103926 Andrew Pinski changed: What|Removed |Added Host|power8 | Build|3b0ba97fafe8 (2 week old| |releases/gcc-11)| Keywords||inline-asm Component|other |target --- Comment #1 from Andrew Pinski --- 3b0ba97fafe8 (2 week old releases/gcc-11)
[Bug other/103926] New: "wQ" broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103926
Bug ID: 103926
Summary: "wQ" broken
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: aik at ozlabs dot ru
CC: segher at gcc dot gnu.org
Target Milestone: ---
Host: power8
Target: powerpc64le-linux
Build: 3b0ba97fafe8 (2 week old releases/gcc-11)
Using `wQ` constraint ("memory acceptable by `lq`") makes gcc crash. Note that
without "-O2" gcc gently fails (not sure why).
The issue recreates on gcc-11 from git and Ubuntu 2104's gcc (10.3.0-1ubuntu1).
[fstn1-p1 ~]$
/home/aik/pbuild/crossgcc/gcc-powerpc64le-linux-11.2.1-2.37.50-nolibc/bin/powerpc64le-linux-gcc
gccbug.c -o gccbug.o -O2
gccbug.c: In function ‘f’:
gccbug.c:6:1: error: unrecognizable insn:
6 | }
| ^
(insn 6 11 9 2 (parallel [
(set (reg:TI 10 10 [orig:118 v ] [118])
(asm_operands/v:TI ("lq %0, 0(%1)") ("=") 0 [
(mem/f/c:DI (reg:DI 9 9 [120]) [1 ptr+0 S8 A128])
]
[
(asm_input:DI ("wQ") gccbug.c:5)
]
[] gccbug.c:5))
(clobber (reg:SI 98 ca))
]) "gccbug.c":5:2 -1
(nil))
during RTL pass: postreload
gccbug.c:6:1: internal compiler error: in extract_constrain_insn, at
recog.c:2671
0x10190343 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/aik/p/gcc/gcc/gcc/rtl-error.c:108
0x10190397 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/aik/p/gcc/gcc/gcc/rtl-error.c:116
0x1082fe6b extract_constrain_insn(rtx_insn*)
/home/aik/p/gcc/gcc/gcc/recog.c:2671
0x107ea1bf reload_cse_simplify_operands
/home/aik/p/gcc/gcc/gcc/postreload.c:407
0x107ebd5f reload_cse_simplify
/home/aik/p/gcc/gcc/gcc/postreload.c:190
0x107ebd5f reload_cse_regs_1
/home/aik/p/gcc/gcc/gcc/postreload.c:238
0x107edf7b reload_cse_regs
/home/aik/p/gcc/gcc/gcc/postreload.c:66
0x107edf7b execute
/home/aik/p/gcc/gcc/gcc/postreload.c:2359
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/102191] [C++20] Can't return prvalue with potentially-throwing destructor during constant evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102191 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Last reconfirmed||2022-01-06 Summary|Can't return prvalue with |[C++20] Can't return |potentially-throwing|prvalue with |destructor during constant |potentially-throwing |evaluation |destructor during constant ||evaluation Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED
[Bug target/103925] New: Missing int3 in ix86_output_indirect_function_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103925
Bug ID: 103925
Summary: Missing int3 in ix86_output_indirect_function_return
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: andrew.cooper3 at citrix dot com, ubizjak at gmail dot com
Target Milestone: ---
[hjl@gnu-tgl-2 tmp]$ cat foo.c
struct _Unwind_Context _Unwind_Resume_or_Rethrow_this_context;
void offset (int);
struct _Unwind_Context {
void *reg[7];
} _Unwind_Resume_or_Rethrow() {
struct _Unwind_Context cur_contextcur_context =
_Unwind_Resume_or_Rethrow_this_context;
offset(0);
__builtin_eh_return ((long) offset, 0);
}
[hjl@gnu-tgl-2 tmp]$ /usr/gcc-12.0.0-x32/bin/gcc -S -O2 -fcf-protection
-mharden-sls=all foo.c
[hjl@gnu-tgl-2 tmp]$ cat foo.s
.file "foo.c"
.text
.p2align 4
.globl _Unwind_Resume_or_Rethrow
.type _Unwind_Resume_or_Rethrow, @function
_Unwind_Resume_or_Rethrow:
.LFB0:
.cfi_startproc
endbr64
pushq %rdx
.cfi_def_cfa_offset 16
.cfi_offset 1, -16
xorl%edi, %edi
pushq %rax
.cfi_def_cfa_offset 24
.cfi_offset 0, -24
subq$8, %rsp
.cfi_def_cfa_offset 32
calloffset
movl$offset, %ecx
movq$0, 24(%rsp,%rcx)
movq8(%rsp), %rax
movq16(%rsp), %rdx
leaq24(%rsp,%rcx), %rsp
.cfi_def_cfa_offset 8
popq%rcx
.cfi_register 16, 2
.cfi_def_cfa_offset 0
jmp *%rcx Missing int3
.cfi_endproc
.LFE0:
.size _Unwind_Resume_or_Rethrow, .-_Unwind_Resume_or_Rethrow
.globl _Unwind_Resume_or_Rethrow_this_context
.bss
.align 32
.type _Unwind_Resume_or_Rethrow_this_context, @object
.size _Unwind_Resume_or_Rethrow_this_context, 56
_Unwind_Resume_or_Rethrow_this_context:
.zero 56
.ident "GCC: (GNU) 12.0.0 20211225 (experimental)"
.section.note.GNU-stack,"",@progbits
.section.note.gnu.property,"a"
.align 8
.long 1f - 0f
.long 4f - 1f
.long 5
0:
.string "GNU"
1:
.align 8
.long 0xc002
.long 3f - 2f
2:
.long 0x3
3:
.align 8
4:
[hjl@gnu-tgl-2 tmp]$
[Bug c++/103879] error: accessing value of variant::_Copy_ctor_base through a 'const variant' glvalue in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103879 --- Comment #10 from 康桓瑋 --- (In reply to Patrick Palka from comment #9) > That one unfortunately seems to be an unrelated constexpr bug. Mind opening > a separate PR? > > I'm reducing the testcase.. Reported PR103924.
[Bug libstdc++/103924] New: views::join combined with std::string cannot be used in constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103924
Bug ID: 103924
Summary: views::join combined with std::string cannot be used
in constant expressions
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
The following code cannot be used as a constant expression, but it should work
since constexpr non-propagating-cache and std::string have been implemented.
#include
#include
int main() {
using namespace std::string_literals;
static_assert(std::ranges::distance(
std::views::single("42"s) | std::views::join));
}
https://godbolt.org/z/zPv4xnxnP
#include
#include
int main() {
using namespace std::string_literals;
static_assert(std::ranges::distance(
std::views::iota(0, 1)
| std::views::transform([](auto) { return "42"s; })
| std::views::join));
}
https://godbolt.org/z/d5TM4x53z
[Bug target/103622] [12 Regression] ICE: Segmentation fault (in altivec_resolve_new_overloaded_builtin)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103622 Bill Schmidt changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #12 from Bill Schmidt --- Fixed now.
[Bug fortran/102708] Improve ''array temporary was created for argument" diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102708 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #2 from sandra at gcc dot gnu.org --- I fixed a lot of bugs with creating excessive temporaries for calls to bind(c) functions in my fix for PR 103390 (commit 6447f6f983ffeaecb8753ef685d702bf2594968b). I'm not sure if there is more to do there or not, but it seems unrelated to the original problem. If there's a bug, it ought to be in its own issue. IIUC what needs to be done for the original problem is fixing (all?) the calls to gfc_conv_subref_array_arg to pass the fsym and proc_name arguments.
[Bug fortran/103366] [9/10/11/12 Regression] ICE in gfc_conv_gfc_desc_to_cfi_desc, at fortran/trans-expr.c:5647
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103366 --- Comment #7 from sandra at gcc dot gnu.org --- The proposed patch looks reasonable to me.
[Bug c++/103758] bogus warning: misspelled term 'decl' in format; use 'declaration' instead [-Wformat-diag]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103758 --- Comment #11 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:1935db296892bbd9fc597889237528bd7e080ab1 commit r12-6277-g1935db296892bbd9fc597889237528bd7e080ab1 Author: Marek Polacek Date: Wed Jan 5 17:53:30 2022 -0500 Avoid more -Wformat-diag warnings [PR103758] Let's use "%, %, or %" rather than "[x|y|z]" as in the rest of our codebase. PR c++/103758 gcc/c-family/ChangeLog: * c-pragma.c (handle_pragma_scalar_storage_order): Use %< %> in diagnostic messages. (handle_pragma_diagnostic): Likewise. gcc/testsuite/ChangeLog: * gcc.dg/sso-6.c: Update dg-warning.
[Bug bootstrap/59447] --with-dwarf2 should be documented as meaning "DWARF 2 or later" instead of just "DWARF 2"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59447
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #7 from Andrew Pinski ---
Actually this will solve it fully:
diff --git a/gcc/configure.ac b/gcc/configure.ac
index 247371e6537..78c9bb15531 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -1002,7 +1002,7 @@ fi,
objc_boehm_gc='')
AC_ARG_WITH(dwarf2,
-[AS_HELP_STRING([--with-dwarf2], [force the default debug format to be DWARF
2])],
+[AS_HELP_STRING([--with-dwarf2], [force the default debug format to be DWARF 2
(or later)])],
dwarf2="$with_dwarf2",
dwarf2=no)
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 54ad7c7b47c..56136ff0e7f 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -1872,7 +1872,7 @@ should not be built.
@item --with-dwarf2
Specify that the compiler should
-use DWARF 2 debugging information as the default.
+use DWARF 2 (or later) debugging information as the default.
@item --with-advance-toolchain=@var{at}
On 64-bit PowerPC Linux systems, configure the compiler to use the
Let me take it and submit the patch.
[Bug bootstrap/59447] --with-dwarf2 should be documented as meaning "DWARF 2 or later" instead of just "DWARF 2"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59447 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2017-09-07 00:00:00 |2022-1-5 --- Comment #6 from Andrew Pinski --- diff --git a/gcc/configure.ac b/gcc/configure.ac index 247371e6537..78c9bb15531 100644 --- a/gcc/configure.ac +++ b/gcc/configure.ac @@ -1002,7 +1002,7 @@ fi, objc_boehm_gc='') AC_ARG_WITH(dwarf2, -[AS_HELP_STRING([--with-dwarf2], [force the default debug format to be DWARF 2])], +[AS_HELP_STRING([--with-dwarf2], [force the default debug format to be DWARF 2 (or later)])], dwarf2="$with_dwarf2", dwarf2=no) I think will fix the issue.
[Bug preprocessor/45227] libcpp Makefile does not enable instrumentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45227 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #6 from Andrew Pinski --- Profiledbootstrap does profile libcpp for me so closing as works for me since it has been doing this for a long time now.
[Bug ipa/67051] symtab_node::equal_address_to too conservative?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67051
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Ever confirmed|0 |1
Last reconfirmed||2022-01-06
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
Confirmed testcase:
int i;
int j;
int f(void)
{
return !=
}
Compile with -O2 -fcommon and you will see the problem. Note this might be less
important now that -fno-common is the default.
[Bug tree-optimization/10520] induction variable analysis not used to eliminate comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10520 --- Comment #6 from Andrew Pinski --- Hmm, shouldn't we convert: _24 = MAX_EXPR ; if (_24 < _tmp0_27(D)) goto ; [94.50%] else goto ; [5.50%] [local count: 906139990]: _25 = MAX_EXPR ; if (_25 < _tmp0_27(D)) goto ; [94.50%] else goto ; [5.50%] Which is: if (MAX_EXPR < _tmp0_27 && MAX_EXPR < _tmp0_27) goto 3 else goto 5 Into: if (MAX_EXPR, MAX_EXPR > < _tmp0_27) goto 3 else goto 5 Also? To simplify things a little more?
[Bug tree-optimization/10520] induction variable analysis not used to eliminate comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10520 --- Comment #5 from Andrew Pinski --- Here is the current IR at optimized: [local count: 958878296]: # n_in_42 = PHI # n_out_43 = PHI # n_in1_44 = PHI # n_out1_45 = PHI n_in.0_1 = (int) n_in_42; _3 = n_in.0_1 w* 4; _4 = buf_fast_28(D) + _3; n_out.1_5 = (int) n_out_43; _7 = n_out.1_5 w* 4; _8 = buf_fast_28(D) + _7; _9 = *_4; *_8 = _9; n_in1.2_10 = (int) n_in1_44; _12 = n_in1.2_10 w* 4; _13 = buf_fast_28(D) + _12; n_out1.3_14 = (int) n_out1_45; _16 = n_out1.3_14 w* 4; _17 = buf_fast_28(D) + _16; _18 = *_13; *_17 = _18; n_in_31 = n_in_42 + 4; n_out_32 = n_out_43 + 2; n_in1_33 = n_in1_44 + 4; n_out1_34 = n_out1_45 + 2; _24 = MAX_EXPR ; if (_24 < _tmp0_27(D)) goto ; [94.50%] else goto ; [5.50%] [local count: 906139990]: _25 = MAX_EXPR ; if (_25 < _tmp0_27(D)) goto ; [94.50%] else goto ; [5.50%] We should figure out that: _24 = MAX_EXPR ; Is just as n_in_31 is being incremented by 4 each time through the loop while n_out_32 only by 2 _24 = n_in_31 And: _25 = MAX_EXPR ; Is just (same logic as above) _25 = n_in1_33 And then we have: if (n_in_31 < _tmp0_27(D)) goto ; [94.50%] else goto ; [5.50%] [local count: 906139990]: if (n_in1_33 < _tmp0_27(D)) goto ; [94.50%] else goto ; [5.50%] Where n_in1_33 = n_in_31+1 There for we should reduce it to just: [local count: 906139990]: if (n_in1_33 < _tmp0_27(D)) goto ; [94.50%] else goto ; [5.50%] (hopefully I did this correctly). Of course this depends on if they are not going to be overflowed Which we know they won't because they are being used for pointer accesses.
[Bug target/43311] missed 'movw' optimization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43311
Andrew Pinski changed:
What|Removed |Added
Host|x86_64-gnu-linux|
Build|x86_64-gnu-linux|
--- Comment #7 from Andrew Pinski ---
(In reply to Zdenek Sojka from comment #5)
> (In reply to comment #4)
> >
> > No, s.b2 should be 1.
>
> Thank you for the answer. In that case, the optimisation in comment #0 can't
> be done in a general case (unless I have overlooked something).
Right this makes the code wrong if we do this, an aliasing issue.
But this is well defined to do:
typedef struct { unsigned char b1, b2; } __attribute__((aligned(8))) S;
void f( S const* __restrict__ s, unsigned char* __restrict__ b1, unsigned char*
__restrict__ b2 )
{
*b1 = s->b1;
*b2 = s->b2;
}
[Bug libstdc++/103923] is_invocable inexplicably fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103923 Andrew Pinski changed: What|Removed |Added Component|c++ |libstdc++ --- Comment #1 from Andrew Pinski --- This looks like a libstdc++ issue as if I use clang with libstdc++ I get: 0 1 But if I use LLVM's libc++ I get: 1 1
[Bug c++/103923] New: is_invocable inexplicably fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103923
Bug ID: 103923
Summary: is_invocable inexplicably fails
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jengelh at inai dot de
Target Milestone: ---
Input:
#include
#include
#include
#include
struct T {
struct K {
bool operator==(const K &) const { return 0; }
bool operator<(const K &) const { return 0; }
};
struct H {
auto operator()(const K &) const { return 0; }
};
std::unordered_map m;
};
int main()
{
printf("%d\n", std::is_invocable_v);
printf("%d\n", std::is_invocable_v);
//T().m[T::K()]; // for extra fun
}
Output:
GNU C++17 (SUSE Linux) version 11.2.1 20211124 [revision
7510c23c1ec53aa4a62705f0384079661342ff7b] (x86_64-suse-linux)
compiled by GNU C version 11.2.1 20211124 [revision
7510c23c1ec53aa4a62705f0384079661342ff7b], GMP version 6.2.1, MPFR version
4.1.0-p7, MPC version 1.2.1, isl version isl-0.24-GMP
0
1
Expected output:
1
1
Expectation based on it being possible to invoke on a const H &:
{ T::H h; const T::H = h; hh(T::K()); }
[Bug c++/103711] Virtual base destroyed twice when an exception is thrown in a derived class' constructor called from a delegated constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103711 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org CC||jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug target/103622] [12 Regression] ICE: Segmentation fault (in altivec_resolve_new_overloaded_builtin)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103622 --- Comment #11 from CVS Commits --- The master branch has been updated by William Schmidt : https://gcc.gnu.org/g:4ec62dbafe0cb3b79cc635dfb964ef6a7ccc2d40 commit r12-6275-g4ec62dbafe0cb3b79cc635dfb964ef6a7ccc2d40 Author: Bill Schmidt Date: Wed Jan 5 16:53:29 2022 -0600 rs6000: Skip overload instances with uninitialized fntype (PR103622) 2022-01-05 Bill Schmidt gcc/ PR target/103622 * config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin): Skip over instances with undefined function types.
[Bug c++/103922] fconcepts syntax cause g++ to stop checking access modifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103922 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Target Milestone|--- |10.0 Keywords||accepts-invalid Resolution|--- |FIXED --- Comment #2 from Andrew Pinski --- >Was fixed in g++-10. GCC 10 had a rewrite of concepts so I am not shocked it was fixed in GCC 10. There is no much to do about GCC 9 here really because of that fact.
[Bug c++/103922] fconcepts syntax cause g++ to stop checking access modifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103922
--- Comment #1 from Ido Kessler ---
(In reply to Ido Kessler from comment #0)
> As far as I could verify this has not been mention anywhere.
>
> Versions: g++-9 (all versions I tried). Was fixed in g++-10.
> Compiler flags: -fconcepts -std=c++17
> Symptoms: The following line cause any code after it to ignore access
> modifiers:
>
> class A {
> int x;
> };
>
> template
> concept ConceptWithTwoImputs = true;
>
> template
> concept ConceptThatUsesIt = requires(T t) {
> {t} -> ConceptWithTwoImputs; // problematic line.
> };
>
> int main() {
> A a;
> a.x = 1;
> }
>
> If you comment this line, it would result in "error: 'int A::x' is private
> within this context".
Inputs* (typo)
Also changing the line to:
{t} -> bool; // problematic line.
works.
[Bug c++/103922] New: fconcepts syntax cause g++ to stop checking access modifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103922
Bug ID: 103922
Summary: fconcepts syntax cause g++ to stop checking access
modifiers
Product: gcc
Version: 9.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kessido at gmail dot com
Target Milestone: ---
As far as I could verify this has not been mention anywhere.
Versions: g++-9 (all versions I tried). Was fixed in g++-10.
Compiler flags: -fconcepts -std=c++17
Symptoms: The following line cause any code after it to ignore access
modifiers:
class A {
int x;
};
template
concept ConceptWithTwoImputs = true;
template
concept ConceptThatUsesIt = requires(T t) {
{t} -> ConceptWithTwoImputs; // problematic line.
};
int main() {
A a;
a.x = 1;
}
If you comment this line, it would result in "error: 'int A::x' is private
within this context".
[Bug target/103910] openjdk17 causes ICE on -O3 -march=opteron -fcheck-new: during GIMPLE pass: aprefetch: in gimple_build_call, at gimple.c:267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103910 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |12.0 Status|ASSIGNED|RESOLVED --- Comment #7 from Andrew Pinski --- Fixed. The bug has been latent since r0-81404 (4.3.0 release). I doubt many people are testing on opteron any mores but if someone wants to backport the fix I am ok with that too.
[Bug target/103910] openjdk17 causes ICE on -O3 -march=opteron -fcheck-new: during GIMPLE pass: aprefetch: in gimple_build_call, at gimple.c:267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103910 --- Comment #6 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:d243f4009d8071b734df16cd70f4c5d09a373769 commit r12-6274-gd243f4009d8071b734df16cd70f4c5d09a373769 Author: Andrew Pinski Date: Wed Jan 5 22:00:07 2022 + Fix target/103910: missing GTY on x86_mfence causing PCH usage to ICE With -O3 -march=opteron, a mfence builtin is added after the loop to say the nontemporal stores are no longer needed. This all good without precompiled headers as the function decl that is referneced by x86_mfence is referenced in another variable but with precompiled headers, x86_mfence is all messed up and the decl was GC'ed away. This fixes the problem by marking x86_mfence as GTY to save/restore during precompiled headers just like most other variables in the header file. Committed as obvious after a bootstrap/test on x86_64-linux-gnu. gcc/ChangeLog: PR target/103910 * config/i386/i386.h (x86_mfence): Mark with GTY.
[Bug fortran/95879] [10/11/12 Regression] ICE in gfc_resolve_formal_arglist, at fortran/resolve.c:313
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95879 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #6 from anlauf at gcc dot gnu.org --- (In reply to sandra from comment #5) > The ICE from the z1.90 example is gone on mainline now. I don't know if the > error on y1.f90 is correct or not without further research. y1.f90 is invalid code. However, gfortran's checking looks suspicious to me. Rewriting the testcase slightly: module m implicit none contains integer function f(x) bind(c) use iso_c_binding, only: c_funloc real, intent(in) :: x c_funloc(f) = x f = 0 end end This would give: pr95879-y1.f90:7:13: 7 | c_funloc(f) = x | 1 Error: Function result 'f' at (1) is invalid as X argument to C_FUNLOC I think this is wrong. F2018: 18.2.3.5 C_FUNLOC (X) Argument. X shall be a procedure; if it is a procedure pointer it shall be associated. It shall not be a coindexed object. Deactivating the related check in gfc_check_c_funloc, I get: pr95879-y1.f90:7:4: 7 | c_funloc(f) = x |1 Error: The function result on the lhs of the assignment at (1) must have the pointer attribute. That looks like a more reasonable error.
[Bug target/103861] [i386] vectorize v2qi vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103861 --- Comment #9 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:c166632bd22d7da66354121502019fc9c92ef07f commit r12-6273-gc166632bd22d7da66354121502019fc9c92ef07f Author: Uros Bizjak Date: Wed Jan 5 23:16:34 2022 +0100 i386: Introduce V2QImode minmax, abs and uavgv2hi3_ceil [PR103861] Add V2QImode minmax, abs and uavxv2qi3_ceil operations with SSE registers. 2022-01-05 Uroš Bizjak gcc/ChangeLog: PR target/103861 * config/i386/mmx.md (VI_16_32): New mode iterator. (VI1_16_32): Ditto. (mmxvecsize): Handle V2QI mode. (3): Rename from v4qi3. Use VI1_16_32 mode iterator. (3): Rename from v4qi3. Use VI1_16_32 mode iterator. (abs2): Use VI_16_32 mode iterator. (uavgv2qi3_ceil): New insn pattern. gcc/testsuite/ChangeLog: PR target/103861 * gcc.target/i386/pr103861-3.c: New test. * g++.dg/vect/slp-pr98855.cc (dg-final): Check that no vectorization using SLP was performed.
[Bug libstdc++/103453] ASAN detection with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103453 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|12.0|10.4 --- Comment #13 from Jonathan Wakely --- Fixed for 11.3 and 10.4
[Bug libstdc++/103877] libstdc++ docs give a bad recommendation for printing C++ defines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103877 Jonathan Wakely changed: What|Removed |Added Target Milestone|12.0|10.4
[Bug libstdc++/102445] [meta-bug] std::regex issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102445 Bug 102445 depends on bug 103549, which changed state. Bug 103549 Summary: Uninitialized member warning from regex header https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103549 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug libstdc++/103549] Uninitialized member warning from regex header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103549 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|12.0|10.4 Status|NEW |RESOLVED --- Comment #6 from Jonathan Wakely --- Fixed for 11.3 and 10.4
[Bug c++/89074] valid pointer equality constexpr comparison rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89074 --- Comment #13 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:226210894e53259940a8e1453125e37c65299ba4 commit r11-9441-g226210894e53259940a8e1453125e37c65299ba4 Author: Jonathan Wakely Date: Thu Nov 18 12:39:20 2021 + libstdc++: Fix std::char_traits::move for constexpr The constexpr branch in __gnu_cxx::char_traits::move compares the string arguments to see if they overlap, but relational comparisons between unrelated pointers are not core constant expressions. I want to replace the comparisons with a loop using pointer equality to determine whether the end of the source string is in the destination string. However, that doesn't work with GCC, due to PR c++/89074 so allocate a temporary buffer instead and copy out into that first, so that overlapping source and destination don't matter. The allocation isn't supported by the current Intel icc so use the loop as a fallback. libstdc++-v3/ChangeLog: * include/bits/char_traits.h (__gnu_cxx::char_traits::move): Do not compare unrelated pointers during constant evaluation. * testsuite/21_strings/char_traits/requirements/constexpr_functions_c++20.cc: Improve tests for char_traits::move. (cherry picked from commit ca243ada71656651a8753e88164a1f0f019be1c3)
[Bug libstdc++/103919] The basic_string(const T&, size_type, size_type) constructor is overconstrained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103919 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Jonathan Wakely --- Fixed for 11.3 too.
[Bug c++/89074] valid pointer equality constexpr comparison rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89074 --- Comment #12 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:0d566335a31722f8044852d9a24f492830ae5789 commit r10-10381-g0d566335a31722f8044852d9a24f492830ae5789 Author: Jonathan Wakely Date: Thu Nov 18 12:39:20 2021 + libstdc++: Fix std::char_traits::move for constexpr The constexpr branch in __gnu_cxx::char_traits::move compares the string arguments to see if they overlap, but relational comparisons between unrelated pointers are not core constant expressions. I want to replace the comparisons with a loop using pointer equality to determine whether the end of the source string is in the destination string. However, that doesn't work with GCC, due to PR c++/89074 so allocate a temporary buffer instead and copy out into that first, so that overlapping source and destination don't matter. The allocation isn't supported by the current Intel icc so use the loop as a fallback. libstdc++-v3/ChangeLog: * include/bits/char_traits.h (__gnu_cxx::char_traits::move): Do not compare unrelated pointers during constant evaluation. * testsuite/21_strings/char_traits/requirements/constexpr_functions_c++20.cc: Improve tests for char_traits::move. (cherry picked from commit ca243ada71656651a8753e88164a1f0f019be1c3)
[Bug libstdc++/103877] libstdc++ docs give a bad recommendation for printing C++ defines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103877 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:39e5b756e1412a399613d7df25d8730e7de1d989 commit r11-9439-g39e5b756e1412a399613d7df25d8730e7de1d989 Author: Jonathan Wakely Date: Tue Jan 4 15:54:16 2022 + libstdc++: Fix example preprocessor command in FAQ [PR103877] libstdc++-v3/ChangeLog: PR libstdc++/103877 * doc/xml/faq.xml: Add '-x c++' to preprocessor command. * doc/html/faq.html: Regenerate. (cherry picked from commit cebe875f6f44b905a0d56a2007b5a638a33a893c)
[Bug libstdc++/103877] libstdc++ docs give a bad recommendation for printing C++ defines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103877 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:88518e5ae0c7b4ed87ffa4ba39c1ff93c7d146dd commit r10-10380-g88518e5ae0c7b4ed87ffa4ba39c1ff93c7d146dd Author: Jonathan Wakely Date: Tue Jan 4 15:54:16 2022 + libstdc++: Fix example preprocessor command in FAQ [PR103877] libstdc++-v3/ChangeLog: PR libstdc++/103877 * doc/xml/faq.xml: Add '-x c++' to preprocessor command. * doc/html/faq.html: Regenerate. (cherry picked from commit cebe875f6f44b905a0d56a2007b5a638a33a893c)
[Bug libstdc++/103501] associative containers left invalid after allocator-extended move construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103501 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:bae757f80970824fbc6a1a2598b233ff489efa4a commit r11-9438-gbae757f80970824fbc6a1a2598b233ff489efa4a Author: Jonathan Wakely Date: Tue Nov 30 23:32:50 2021 + libstdc++: Clear RB tree after moving elements [PR103501] If the allocator-extended move constructor move-constructs each element into the new container, the contents of the old container are left in moved-from states. We cannot know if those states preserve the container's ordering and uniqueness guarantees, so just erase all moved-from elements. libstdc++-v3/ChangeLog: PR libstdc++/103501 * include/bits/stl_tree.h (_Rb_tree(_Rb_tree&&, false_type)): Clear container if elements have been moved-from. * testsuite/23_containers/map/allocator/move_cons.cc: Expect moved-from container to be empty. * testsuite/23_containers/multimap/allocator/move_cons.cc: Likewise. * testsuite/23_containers/multiset/allocator/103501.cc: New test. * testsuite/23_containers/set/allocator/103501.cc: New test. (cherry picked from commit 056551414a328b427c4bf4955b9a3832f344685c)
[Bug libstdc++/103549] Uninitialized member warning from regex header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103549 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:17af7c1a054c9663e5b353a4fc576522e0cd9a4f commit r10-10379-g17af7c1a054c9663e5b353a4fc576522e0cd9a4f Author: Jonathan Wakely Date: Sat Dec 4 11:38:25 2021 + libstdc++: Initialize member in std::match_results [PR103549] This fixes a -Wuninitialized warning for std::cmatch m1, m2; m1=m2; Also name the template parameters in the forward declaration, to get rid of the noise in diagnostics. libstdc++-v3/ChangeLog: PR libstdc++/103549 * include/bits/regex.h (match_results): Give names to template parameters in first declaration. (match_results::_M_begin): Add default member-initializer. (cherry picked from commit 87710ec7b213245ecb194b778e97ae3a6790394f)
[Bug libstdc++/103549] Uninitialized member warning from regex header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103549 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:5e0ef5621b518caa593b77b7c8f202ee018a0900 commit r11-9437-g5e0ef5621b518caa593b77b7c8f202ee018a0900 Author: Jonathan Wakely Date: Sat Dec 4 11:38:25 2021 + libstdc++: Initialize member in std::match_results [PR103549] This fixes a -Wuninitialized warning for std::cmatch m1, m2; m1=m2; Also name the template parameters in the forward declaration, to get rid of the noise in diagnostics. libstdc++-v3/ChangeLog: PR libstdc++/103549 * include/bits/regex.h (match_results): Give names to template parameters in first declaration. (match_results::_M_begin): Add default member-initializer. (cherry picked from commit 87710ec7b213245ecb194b778e97ae3a6790394f)
[Bug libstdc++/103453] ASAN detection with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103453 --- Comment #12 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:37fec1c1b0c942d861dd51b31d099084826a485b commit r10-10378-g37fec1c1b0c942d861dd51b31d099084826a485b Author: Jonathan Wakely Date: Tue Nov 30 13:14:38 2021 + libstdc++: Make Asan detection work for Clang [PR103453] Clang doesn't define __SANITIZE_ADDRESS__ so use its __has_feature check to detect Asan instead. libstdc++-v3/ChangeLog: PR libstdc++/103453 * config/allocator/malloc_allocator_base.h (_GLIBCXX_SANITIZE_STD_ALLOCATOR): Define for Clang. * config/allocator/new_allocator_base.h (_GLIBCXX_SANITIZE_STD_ALLOCATOR): Likewise. (cherry picked from commit cca6090b13ab503bef1cfa327e2d107789d6bd30)
[Bug libstdc++/103453] ASAN detection with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103453 --- Comment #11 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:ad54d3fb8f09babc43ea46a93cc73cd623fe822f commit r11-9436-gad54d3fb8f09babc43ea46a93cc73cd623fe822f Author: Jonathan Wakely Date: Tue Nov 30 13:14:38 2021 + libstdc++: Make Asan detection work for Clang [PR103453] Clang doesn't define __SANITIZE_ADDRESS__ so use its __has_feature check to detect Asan instead. libstdc++-v3/ChangeLog: PR libstdc++/103453 * config/allocator/malloc_allocator_base.h (_GLIBCXX_SANITIZE_STD_ALLOCATOR): Define for Clang. * config/allocator/new_allocator_base.h (_GLIBCXX_SANITIZE_STD_ALLOCATOR): Likewise. (cherry picked from commit cca6090b13ab503bef1cfa327e2d107789d6bd30)
[Bug libstdc++/103919] The basic_string(const T&, size_type, size_type) constructor is overconstrained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103919 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:4c64143f32642d22590959704e2ec6c686d745ff commit r11-9435-g4c64143f32642d22590959704e2ec6c686d745ff Author: Jonathan Wakely Date: Wed Jan 5 15:16:33 2022 + libstdc++: Fix overconstrained std::string constructor [PR103919] The C++17 basic_string(const T&, size_t, size_t) constructor is overconstrained, so it can't be used for a NTBS and a temporary string gets constructed (potentially allocating memory). There is no corresponding constructor taking an NTBS, so no need to disambiguate from it. Accepting an NTBS avoids the temporary (and potential allocation) and is what the standard requires. libstdc++-v3/ChangeLog: PR libstdc++/103919 * include/bits/basic_string.h (basic_string(const T&, size_t, size_t)): Relax constraints on string_view parameter. [!_GLIBCXX_USE_CXX11_ABI] (basic_string(const T&, size_t, size_t)): Likewise. * testsuite/21_strings/basic_string/cons/char/103919.cc: New test. (cherry picked from commit 6aa0859afaf28f4fb13121352225bc5877e02a44)
[Bug analyzer/103546] Analyzer reports null dereference in flex scanners
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103546 David Malcolm changed: What|Removed |Added Last reconfirmed||2022-01-05 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from David Malcolm --- Thanks for filing this bug report; I too see the false positive (tested with trunk). It seems to be an issue with alias handling in the analyzer: if I'm debugging things correctly, it seems the analyzer "thinks" that various writes through unrelated pointers could clobber the value of yy_buffer_stack. Hence we end up with code paths in which yy_buffer_stack is non-NULL, then a write through a pointer happens that the analyzer treats as possibly clobbered yy_buffer_stack, and so it could theoretically be NULL at a subsequent test for NULL, and hence we have false positives in which yy_buffer_stack is erroneously treated as being NULL after yyensure_buffer_stack has returned. It might be possible to fix this by "teaching" the analyzer about TBAA (type-based alias analysis) so that it can reject some kinds of clobbering; I'm not yet sure.
[Bug c++/93050] throw within constructor initialisation list causes invalid free in destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93050 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |WAITING CC||jason at gcc dot gnu.org Last reconfirmed||2022-01-05 Ever confirmed|0 |1 --- Comment #2 from Jason Merrill --- We should never call ~Test if the constructor throws, and indeed we don't on my RHEL system. Can you reproduce this with a more recent MSYS2 gcc? Looks like they have 11.2 packages now.
[Bug fortran/103782] [9/10/11/12 Regression] internal error occurs when overloading intrinsic since r9-1566-g87c789f1c0b2df41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103782
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #3 from anlauf at gcc dot gnu.org ---
The following patch seems to solve this and to regtest ok:
diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 96a2cd70900..6ecd79beef0 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -2219,7 +2219,7 @@ gfc_simplify_expr (gfc_expr *p, int type)
&& gfc_intrinsic_func_interface (p, 1) == MATCH_ERROR)
return false;
- if (p->expr_type == EXPR_FUNCTION)
+ if (p->symtree && (p->value.function.isym || (p->ts.type ==
BT_UNKNOWN)))
{
if (p->symtree)
isym = gfc_find_function (p->symtree->n.sym->name);
@Paul: can you comment on this as original author of that code block?
It appears that the original "if" was not intended as we are already in a
switch (p->expr_type)
...
case EXPR_FUNCTION:
Now my interpretation is: we want to do scalarize_intrinsic_call if we either
know already that the function did resolve to an intrinsic, or we have a name
but want to look it up.
(Omitting the latter part regression on gfortran.dg/fmt_nonchar_3.f90)
[Bug tree-optimization/103899] [12 Regression] make profiledbootstrap fails due to uninitialized warning in expr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103899 --- Comment #8 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #6) > While we should fix uninit warning to deal with this if possible, I think we > should also try to work around this in expr.c. > > If following works, then I think it would be even a cleanup (as it moves the > context variable declaration to the sole spot where it is used): Yes I do think we should improve the code in expr.c to better express this and have this cleanup.
[Bug target/103910] openjdk17 causes ICE on -O3 -march=opteron -fcheck-new: during GIMPLE pass: aprefetch: in gimple_build_call, at gimple.c:267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103910 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #5 from Andrew Pinski --- Mine then.
[Bug c++/96057] [9/10/11/12 Regression] -Wreturn-type warning message disappears with -O1+ in anonymous namespace definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96057 Andrew Pinski changed: What|Removed |Added Summary|-Wreturn-type warning |[9/10/11/12 Regression] |message disappears with -O1 |-Wreturn-type warning |to -Os in unnamed namespace |message disappears with |definition |-O1+ in anonymous namespace ||definition Known to fail||12.0, 4.4.7 Ever confirmed|0 |1 Target Milestone|--- |9.5 Status|UNCONFIRMED |NEW Last reconfirmed||2022-01-05 Known to work||4.1.2 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug target/103722] [12 Regression] ICE in extract_constrain_insn building glibc for SH4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103722 Jeffrey A. Law changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-01-05 CC||law at gcc dot gnu.org --- Comment #2 from Jeffrey A. Law --- I'll confirm. My tester is seeing the same failure building the linux kernel on sh4/sh4eb and was bisected to the same commit. Isn't a move cost 2 special to the old reload pass, causing it to avoid various checks on simple move insns? If so, wouldn't returning any other value be helpful, and something closer to 2 than 7 would perturb the generated code less? Regardless, I'd approve the patch as-is if you submit it.
[Bug c++/90769] Template instantiation recursion when trying to do a conversion template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90769
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #4 from Patrick Palka ---
I think this issue can be distilled into the following testcase:
enum E { };
template
int f(E e) {
return e + e;
}
int operator+(E, E) = delete; // #1
template int f(E);
For e + e, should ADL be performed at instantiation time and therefore find the
later-declared #1? GCC, Clang and MSVC all appear to perform ADL here, and
they all reject this testcase. I'm not sure but I think ADL shouldn't be
performed here since since the operator expression is non-dependent.
[Bug c/103920] No warning for large structs passed by value ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103920 --- Comment #1 from Andrew Pinski --- Actually I think the warning is incorrect as there are aliasing implications if passed by reference instead of by value.
[Bug c++/89074] valid pointer equality constexpr comparison rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89074 --- Comment #11 from Jakub Jelinek --- There are some further questions though. E.g. address_compare has a smart code to assume that static vars will never be adjacent to automatic vars or vice versa (the implementation guarantees that): /* Assume that automatic variables can't be adjacent to global variables. */ else if (is_global_var (base0) != is_global_var (base1)) ; or similarly there is code that assumes that string literals won't be adjacent to user variables or vice versa: if ((DECL_P (base0) && TREE_CODE (base1) == STRING_CST) || (TREE_CODE (base0) == STRING_CST && DECL_P (base1)) || (TREE_CODE (base0) == STRING_CST && TREE_CODE (base1) == STRING_CST && ioff0 >= 0 && ioff1 >= 0 && ioff0 < TREE_STRING_LENGTH (base0) && ioff1 < TREE_STRING_LENGTH (base1) /* This is a too conservative test that the STRING_CSTs will not end up being string-merged. */ && strncmp (TREE_STRING_POINTER (base0) + ioff0, TREE_STRING_POINTER (base1) + ioff1, MIN (TREE_STRING_LENGTH (base0) - ioff0, TREE_STRING_LENGTH (base1) - ioff1)) != 0)) ; The question is what do we want for folding_initializer cases. Do we want to add !folding_initializer && to the is_global_var != checks and the first two above (the STRING_CST vs. STRING_CST in some form is needed I think)? Though, there is else if (!DECL_P (base0) || !DECL_P (base1)) return 2; and so such !folding_initalizer && in there would reject valid cases where a pointer doesn't point to start of a string or end of it. And in another PR, we have mentioned that &"foo"[0] != &"foo"[0] is pedantically not a constant expression, but if it was e.g. const char *s = "foo"; [0] != [0], then it would be well defined, and we certainly don't track whether it must be the same string literal or could be another one (neither does clang++ AFAIK).
[Bug c++/89074] valid pointer equality constexpr comparison rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89074
--- Comment #10 from Jakub Jelinek ---
So, for #c5,
if ([1] == [0])
instead of if (a+1 == b+0) works right, that is handled by the match.pd
(cmp (convert1?@2 addr@0) (convert2? addr@1))
address_compare simplification. And it also works for GIMPLE, where we have
in gimple-fold.c the:
/* Translate + CST into an invariant form suitable for
further propagation. */
if (subcode == POINTER_PLUS_EXPR)
{
tree op0 = (*valueize) (gimple_assign_rhs1 (stmt));
tree op1 = (*valueize) (gimple_assign_rhs2 (stmt));
if (TREE_CODE (op0) == ADDR_EXPR
&& TREE_CODE (op1) == INTEGER_CST)
{
tree off = fold_convert (ptr_type_node, op1);
return build1_loc
(loc, ADDR_EXPR, TREE_TYPE (op0),
fold_build2 (MEM_REF,
TREE_TYPE (TREE_TYPE (op0)),
unshare_expr (op0), off));
}
}
I think we don't do this for GENERIC because that can seriously break the
constant evaluation, the details on which exact field is accessed can be lost
in there.
But, if we take e.g.
struct S { int s; };
struct T : public S {};
struct U : public T {};
constexpr bool
test()
{
U a[] = { 1, 2, 3, 4 };
U b[] = { 5, 6, 7, 8 };
T *c = (T *) a + 1;
S *d = (S *) c + 2;
S *e = (S *) b + 1;
if (a+0 == b+0) // OK
return false;
if (d == e) // ERROR
return false;
return true;
}
static_assert( test() );
then we can see the comparison is tried on
‘S*)((& a[0].U::) + 4)) + 8) == ((&
b[0].U::.T::) + 4))’ is not a constant expression
so the multiple pointer_plus aren't merged in there either.
Hasving a GENERIC guarded variant of the address_compare with one pointer_plus
in one or the other or both operands might be still doable, but the above shows
that it wouldn't be sufficient.
So, perhaps instead if simple comparison fails during constexpr evaluation,
we could call some helper function that looks through cast and optimizes the
POINTER_PLUS into MEM_REF that it folds and then we'd try to compare it again
(or call that helper function regardless on both comparison operands)?
Another thing is that the following testcase isn't rejected:
2022-01-05 Jakub Jelinek
PR c++/89074
* fold-const.c (address_compare): Punt on comparison of address of
one object with address of end of another object if
folding_initializer.
* g++.dg/cpp1y/constexpr-89074-1.C: New test.
--- gcc/fold-const.c.jj 2022-01-05 20:30:08.731806756 +0100
+++ gcc/fold-const.c2022-01-05 20:34:52.277822349 +0100
@@ -16627,7 +16627,7 @@ address_compare (tree_code code, tree ty
/* If this is a pointer comparison, ignore for now even
valid equalities where one pointer is the offset zero
of one object and the other to one past end of another one. */
- else if (!INTEGRAL_TYPE_P (type))
+ else if (!folding_initializer && !INTEGRAL_TYPE_P (type))
;
/* Assume that automatic variables can't be adjacent to global
variables. */
--- gcc/testsuite/g++.dg/cpp1y/constexpr-89074-1.C.jj 2022-01-05
20:43:03.696917484 +0100
+++ gcc/testsuite/g++.dg/cpp1y/constexpr-89074-1.C 2022-01-05
20:42:12.676634044 +0100
@@ -0,0 +1,28 @@
+// PR c++/89074
+// { dg-do compile { target c++14 } }
+
+constexpr bool
+foo ()
+{
+ int a[] = { 1, 2 };
+ int b[] = { 3, 4 };
+
+ if ([0] == [0])
+return false;
+
+ if ([1] == [0])
+return false;
+
+ if ([1] == [1])
+return false;
+
+ if ([2] == [1])
+return false;
+
+ if ([2] == [0]) // { dg-error "is not a constant expression" }
+return false;
+
+ return true;
+}
+
+constexpr bool a = foo ();
[Bug rtl-optimization/94440] [9 Regression] ICE in check_bool_attrs, at recog.c:2168 since r7-5324-gb8cab8a5492e9639
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94440 --- Comment #21 from Uroš Bizjak --- Fixed?
[Bug target/103915] [12 Regression] ICE: SIGSEGV in memory_operand with -flive-range-shrinkage since r12-6215-g708b87dcb6e48cb4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103915 Uroš Bizjak changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Uroš Bizjak --- Fixed.
[Bug tree-optimization/92860] [9/10/11/12 regression] Global flags affected by -O settings are clobbered by optimize attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92860 Bug 92860 depends on bug 103905, which changed state. Bug 103905 Summary: [12 Regression] Miscompiled i386-expand.c with -march=bdver1 and -O3 since r12-1789-g836328b2c99f5b8d https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103905 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/103905] [12 Regression] Miscompiled i386-expand.c with -march=bdver1 and -O3 since r12-1789-g836328b2c99f5b8d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103905 Uroš Bizjak changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #14 from Uroš Bizjak --- Fixed.
[Bug target/103915] [12 Regression] ICE: SIGSEGV in memory_operand with -flive-range-shrinkage since r12-6215-g708b87dcb6e48cb4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103915 --- Comment #3 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:6aa44066b342b9636a736f28d7ac3a0d44dae5c8 commit r12-6270-g6aa44066b342b9636a736f28d7ac3a0d44dae5c8 Author: Uros Bizjak Date: Wed Jan 5 20:08:15 2022 +0100 i386: Fix type of one_cmplv2qi2 alternatives 1,2 [PR103915] 2022-01-05 Uroš Bizjak gcc/ChangeLog: PR target/103915 * config/i386/mmx.md (one_cmplv2qi2): Change alternatives 1,2 type from sselog to sselog1. gcc/testsuite/ChangeLog: PR target/103915 * gcc.target/i386/pr103915.c: New test.
[Bug target/103905] [12 Regression] Miscompiled i386-expand.c with -march=bdver1 and -O3 since r12-1789-g836328b2c99f5b8d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103905 --- Comment #13 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:877c9e332f9b2b6eacd6ed4edf5790ee0f41a68f commit r12-6269-g877c9e332f9b2b6eacd6ed4edf5790ee0f41a68f Author: Uros Bizjak Date: Wed Jan 5 20:06:03 2022 +0100 i386: Fix expand_vec_perm_pshufb for narrow modes [PR103905] 2022-01-05 Uroš Bizjak gcc/ChangeLog: PR target/103905 * config/i386/i386-expand.c (expand_vec_perm_pshufb): Fix number of narrow mode remapped elements for !one_operand_p case. gcc/testsuite/ChangeLog: PR target/103905 * gcc.target/i386/pr103905.c: New test.
[Bug c++/103879] error: accessing value of variant::_Copy_ctor_base through a 'const variant' glvalue in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103879 --- Comment #9 from Patrick Palka --- That one unfortunately seems to be an unrelated constexpr bug. Mind opening a separate PR? I'm reducing the testcase..
[Bug c++/103921] [modules] ICE dependent expression in explicit-specifier of instantiation of imported template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103921
--- Comment #4 from Johel Ernesto Guerrero Peña ---
For the above, when it's fixed:
```diff
- explicit(B) operator int() const;
+ explicit(B) operator int() { return 0; }
```
[Bug other/89863] [meta-bug] Issues in gcc that other static analyzers (cppcheck, clang-static-analyzer, PVS-studio) find that gcc misses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863 Bug 89863 depends on bug 94669, which changed state. Bug 94669 Summary: libcc1: 4 * minor performance problem https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94669 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c/94669] libcc1: 4 * minor performance problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94669 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Target Milestone|--- |12.0 --- Comment #9 from Jonathan Wakely --- I don't think this needs to be backported, so it can just be closed as fixed for GCC 12.
[Bug c++/103921] [modules] ICE dependent expression in explicit-specifier of instantiation of imported template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103921
--- Comment #3 from Johel Ernesto Guerrero Peña ---
Simplified: https://godbolt.org/z/rnfKrzYaP.
mod.cpp:
```C++
export module mod;
export template struct Int {
explicit(B) operator int() const;
};
```
test.cpp:
```C++
import mod;
int main() {
return Int{};
}
```
Output:
```
In module mod, imported at /app/test.cpp:1:
mod.cpp: In instantiation of 'struct Int@mod':
test.cpp:3:20: required from here
mod.cpp:4:15: internal compiler error: Segmentation fault
4 | explicit(B) operator int() const;
| ^~~~
0x2139bd9 internal_error(char const*, ...)
???:0
0x9ada27 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x9f2c99 instantiate_class_template(tree_node*)
???:0
0xa184bc finish_compound_literal(tree_node*, tree_node*, int, fcl_t)
???:0
0x97a00d c_parse_file()
???:0
0xb08022 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c/94669] libcc1: 4 * minor performance problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94669 --- Comment #8 from Tom Tromey --- (In reply to David Binderman from comment #7) > Could this bug be marked as fixed, then ? Yes, but I don't really know the GCC rules about closing reports any more, so someone else probably ought to handle it.
[Bug target/103197] ppc inline expansion of memcpy/memmove should not use lxsibzx/stxsibx for a single byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103197 Segher Boessenkool changed: What|Removed |Added CC||npiggin at gmail dot com --- Comment #10 from Segher Boessenkool --- *** Bug 102169 has been marked as a duplicate of this bug. ***
[Bug target/102169] powerpc64 int memory operations using FP instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102169 Segher Boessenkool changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #6 from Segher Boessenkool --- Proposed patch in PR103197, doing similar to what Hao Chen says in comment 4. *** This bug has been marked as a duplicate of bug 103197 ***
[Bug fortran/103914] -fcheck=do seems not to work with omp parallel do construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103914 anlauf at gcc dot gnu.org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Priority|P3 |P5 Ever confirmed|0 |1 Last reconfirmed||2022-01-05 --- Comment #1 from anlauf at gcc dot gnu.org --- (In reply to xiao@compiler-dev.com from comment #0) > I have some questions: > why the option "-fcheck=do" do not take effect for "parallel do"? Just an observation: The code for ordinary do loops is generated in gfc_trans_do(), which also adds code for runtime checking. The code for OpenMP annotated loops is generated in gfc_trans_omp_do(). There appears to be no runtime checking implemented for this type of loops.
[Bug c++/103921] [modules] ICE dependent expression in explicit-specifier of instantiation of imported template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103921
Johel Ernesto Guerrero Peña changed:
What|Removed |Added
Summary|[modules] ICE requires in |[modules] ICE dependent
|explicit-specifier of |expression in
|instantiation of imported |explicit-specifier of
|template|instantiation of imported
||template
--- Comment #2 from Johel Ernesto Guerrero Peña ---
It actually ICEs whenever the expression is dependent:
https://godbolt.org/z/oqbnanoex.
mod.cpp:
```C++
export module mod;
template constexpr bool b{true};
export template struct quantity {
template
explicit(b) operator quantity() const;
};
```
[Bug target/103197] ppc inline expansion of memcpy/memmove should not use lxsibzx/stxsibx for a single byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103197 --- Comment #9 from Segher Boessenkool --- Created attachment 52131 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52131=edit Proposed patch
[Bug libstdc++/103086] [11 Regression] std::unique_ptr printer gets confused by [[no_unique_address]] in tuple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103086 --- Comment #11 from Jonathan Wakely --- Also fixed for 10.4 now.
[Bug inline-asm/98096] Inconsistent operand numbering for asm goto with in-out operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98096 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- That isn't easibly possible, the labels are really significantly different from the implementation POV, so having them intermixed with inputs is hard. If you don't want to count on those extra inputs, name the labels...
[Bug libstdc++/103086] [11 Regression] std::unique_ptr printer gets confused by [[no_unique_address]] in tuple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103086 --- Comment #10 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:865ad53c49953f2950901aaf45b34a38841df019 commit r10-10375-g865ad53c49953f2950901aaf45b34a38841df019 Author: Jonathan Wakely Date: Tue Nov 23 21:35:40 2021 + libstdc++: Add another testcase for std::unique_ptr printer [PR103086] libstdc++-v3/ChangeLog: PR libstdc++/103086 * testsuite/libstdc++-prettyprinters/cxx11.cc: Check unique_ptr with non-empty pointer and non-empty deleter. (cherry picked from commit c59ec55c3459fba619e05ee7f59480b71e85ffd7)
[Bug libstdc++/103086] [11 Regression] std::unique_ptr printer gets confused by [[no_unique_address]] in tuple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103086 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:5400112aa94163b1e94404e74b3000779d24303b commit r10-10374-g5400112aa94163b1e94404e74b3000779d24303b Author: Jonathan Wakely Date: Thu Nov 4 22:50:02 2021 + libstdc++: Fix pretty printing of std::unique_ptr [PR103086] Since std::tuple started using [[no_unique_address]] the tuple member of std::unique_ptr has two _M_head_impl subobjects, in different base classes. That means this printer code is ambiguous: tuple_head_type = tuple_impl_type.fields()[1].type # _Head_base head_field = tuple_head_type.fields()[0] if head_field.name == '_M_head_impl': self.pointer = tuple_member['_M_head_impl'] In older versions of GDB it happened to work by chance, because GDB returned the last _M_head_impl member and std::tuple's base classes are stored in reverse order, so the last one was the T* element of the tuple. Since GDB 11 it returns the first _M_head_impl, which is the deleter element. The fix is for the printer to stop using an ambiguous field name and cast the tuple to the correct base class before accessing the _M_head_impl member. Instead of fixing this in both UniquePointerPrinter and StdPathPrinter a new unique_ptr_get function is defined to do it correctly. That is defined in terms of new tuple_get and _tuple_impl_get functions. It would be possible to reuse _tuple_impl_get to access each element in StdTuplePrinter._iterator.__next__, but that already does the correct casting, and wouldn't be much simpler anyway. libstdc++-v3/ChangeLog: PR libstdc++/103086 * python/libstdcxx/v6/printers.py (_tuple_impl_get): New helper for accessing the tuple element stored in a _Tuple_impl node. (tuple_get): New function for accessing a tuple element. (unique_ptr_get): New function for accessing a unique_ptr. (UniquePointerPrinter, StdPathPrinter): Use unique_ptr_get. * python/libstdcxx/v6/xmethods.py (UniquePtrGetWorker): Cast tuple to its base class before accessing _M_head_impl. (cherry picked from commit a634928f5c8a281442ac8f5fb1636aed048ed72c)
[Bug inline-asm/98096] Inconsistent operand numbering for asm goto with in-out operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98096 James Y Knight changed: What|Removed |Added CC||foom at fuhm dot net --- Comment #7 from James Y Knight --- Previously, you never needed to care about the numbering of the extra hidden input constraints generated for an in-out constraints, because they were _last_. Their existence previously only mattered in that you needed to count them as part of the "max 30" constraint limit. That's why it is sensible to _keep_ these internal constraints last -- after ALL user-specified constraints, including asm-goto labels. Putting in the middle, and forcing users to count them just adds extra unnecessary complexity to the user-facing API. It appears to me that the GCC decision here was accidental, and that when pointed out, the bug was simply documented rather than fixed. That's unfortunate.
[Bug fortran/95879] [10/11/12 Regression] ICE in gfc_resolve_formal_arglist, at fortran/resolve.c:313
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95879 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #5 from sandra at gcc dot gnu.org --- The ICE from the z1.90 example is gone on mainline now. I don't know if the error on y1.f90 is correct or not without further research.
[Bug c/103920] No warning for large structs passed by value ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103920 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Blocks||87403 Severity|normal |enhancement Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 [Bug 87403] [Meta-bug] Issues that suggest a new warning
[Bug c++/89074] valid pointer equality constexpr comparison rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89074 --- Comment #9 from Patrick Palka --- (In reply to Jakub Jelinek from comment #8) > At least when not constant evaluating that, a + 2 can be equal to b + 0 or > can be different, shouldn't we reject at least that? I think so, according to https://eel.is/c++draft/expr.eq#3.1 and http://eel.is/c++draft/expr.const#5.25
[Bug fortran/103258] [12 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1114 since r12-4979-gee11be7f2d788e60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103258 sandra at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from sandra at gcc dot gnu.org --- Should be fixed now.
