[Bug debug/98946] GCC generating incorrect relocation R_386_GOTOFF in .debug-info for x86 (32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98946 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #5 from Jakub Jelinek --- No, that is a lld bug, there is no such rule that would say these relocations can't be applied against non-allocated or debug sections. GCC var-tracking figures out that the last argument passed to __assert_fail is equivalent to %ebx + __PRETTY_FUNCTION__.0@gotoff, but can't prove that %ebx will be equal to __GLOBAL_OFFSET_TABLE__, so can't emit there just __PRETTY_FUNCTION__.0 - while %ebx must be some __GLOBAL_OFFSET_TABLE__ pointer, it could have been adjusted, so e.g. it could be __GLOBAL_OFFSET_TABLE__ + index and the needed value would then be __PRETTY_FUNCTION__.0 + index. And we want to emit as compact debug info as possible, so emitting it as %ebx + __PRETTY_FUNCTION__.0@gotoff rather than say (%ebx - __GLOBAL_OFFSET_TABLE__) + __PRETTY_FUNCTION__.0, especially because referencing __GLOBAL_OFFSET_TABLE__ symbol in assembly poses interesting problem (implies special relocations).
[Bug c++/98949] gcc-9.3 aarch64 -ftree-vectorize generates wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98949 Richard Biener changed: What|Removed |Added Keywords||needs-bisection --- Comment #1 from Richard Biener --- There are several open vectorizer regressions on older branches, some harder to fix and thus fixes not backported.
[Bug debug/98946] GCC generating incorrect relocation R_386_GOTOFF in .debug-info for x86 (32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98946 --- Comment #4 from Richard Biener --- (In reply to Richard Biener from comment #3) > Confirmed with -O2 -g -fPIE plus -march=atom -m32
[Bug debug/98946] GCC generating incorrect relocation R_386_GOTOFF in .debug-info for x86 (32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98946 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to fail||10.2.1, 11.0, 9.3.1 Keywords||wrong-debug Last reconfirmed||2021-02-03 Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- Confirmed with -O2 -g -fPIE. GCC 7 produces .uleb128 0x42 # (DIE (0x5789) DW_TAG_GNU_call_site_parameter) .uleb128 0x2# DW_AT_location .byte 0x74# DW_OP_breg4 .sleb128 0 .uleb128 0xf# DW_AT_GNU_call_site_value .byte 0x91# DW_OP_fbreg .sleb128 -60 .byte 0x6 # DW_OP_deref .byte 0x3 # DW_OP_addr .long _GLOBAL_OFFSET_TABLE_ .byte 0x1c# DW_OP_minus .byte 0x3 # DW_OP_addr .long .LC3 .byte 0x22# DW_OP_plus .byte 0 # end of children of DIE 0x5780 .byte 0 # end of children of DIE 0x4f2c not sure if that's any better ... GCC 10 variant: .uleb128 0x35 # (DIE (0x2aeb) DW_TAG_GNU_call_site_parameter) .uleb128 0x2# DW_AT_location .byte 0x74# DW_OP_breg4 .sleb128 0 .uleb128 0x9# DW_AT_GNU_call_site_value .byte 0x91# DW_OP_fbreg .sleb128 -60 .byte 0x6 # DW_OP_deref .byte 0x3 # DW_OP_addr .long .LC3@gotoff .byte 0x22# DW_OP_plus .byte 0 # end of children of DIE 0x2ade
[Bug c/98945] gcc does not warn when assigning value of type int (*)() to variable of type int (*)(double)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98945 --- Comment #2 from Richard Biener --- Guess it's from unprototyped function times where float would be promoted to double.
[Bug driver/98943] [11 Regression] gcc driver does not fail on unknown files: tricks configure scripts to recognize /W4 and -diag-disable 1,2,3,4 options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98943 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0 Keywords||needs-bisection Priority|P3 |P1 Summary|gcc driver does not fail on |[11 Regression] gcc driver |unknown files: tricks |does not fail on unknown |configure scripts to|files: tricks configure |recognize /W4 and |scripts to recognize /W4 |-diag-disable 1,2,3,4 |and -diag-disable 1,2,3,4 |options |options --- Comment #1 from Richard Biener --- Definitely undesired.
[Bug tree-optimization/98950] New: jump threading memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98950 Bug ID: 98950 Summary: jump threading memory leak Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- Tried to find my way around the code but I'm not too familiar with it. This shows up (at least) when building 521.wrf_r with -Ofast -flto ==19644== 832 bytes in 52 blocks are definitely lost in loss record 7,748 of 9,681 ==19644==at 0x4C2E94F: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==19644==by 0xC750AE: thread_jumps::convert_and_register_current_path(edge_def*) (tree-ssa-threadbackward.c:472) ==19644==by 0xC75452: thread_jumps::register_jump_thread_path_if_profitable(tree_node*, tree_node*, basic_block_def*) [clone .part.37] (tree-ssa-threadbackward.c:561) ==19644==by 0xC76487: register_jump_thread_path_if_profitable (tree-ssa-threadbackward.c:553) ==19644==by 0xC76487: thread_jumps::handle_phi(gphi*, tree_node*, basic_block_def*) (tree-ssa-threadbackward.c:600) ==19644==by 0xC763B4: thread_jumps::fsm_find_control_statement_thread_paths(tree_node*) (tree-ssa-threadbackward.c:730) ==19644==by 0xC764D4: thread_jumps::handle_phi(gphi*, tree_node*, basic_block_def*) (tree-ssa-threadbackward.c:594) ==19644==by 0xC763B4: thread_jumps::fsm_find_control_statement_thread_paths(tree_node*) (tree-ssa-threadbackward.c:730) ==19644==by 0xC76B8E: (anonymous namespace)::pass_thread_jumps::execute(function*) (tree-ssa-threadbackward.c:828) ==19644==by 0x9E58A3: execute_one_pass(opt_pass*) (passes.c:2567) ==19644==by 0x9E6100: execute_pass_list_1(opt_pass*) (passes.c:2656) ==19644==by 0x9E6112: execute_pass_list_1(opt_pass*) (passes.c:2657) ==19644==by 0x9E6154: execute_pass_list(function*, opt_pass*) (passes.c:2667)
[Bug fortran/98948] unexpected error in procedure pointer initialization or assignment with intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98948 kargl at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2021-02-03 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug fortran/98948] unexpected error in procedure pointer initialization or assignment with intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98948 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- Confirmed, although the original code uses an extension, REAL*4. This is a better testcase. program test implicit none integer, parameter :: k = kind(1.e0)! This works. ! integer, parameter :: k = kind(1.d0) ! This gives error. See F2018:C1519 ! intrinsic abs, acos! This is needed, but should not be. procedure(real(k)), pointer :: pf => ABS ! intrinsic abs, acos! Or, this is needed, but should not be. print *, pf(-6.5_k) if(pf(-6.5_k) /= ABS(-6.5_k)) STOP 1 pf => ACOS print '(Z8.8)', pf(0.54030231_k) ! Never a good idea to check equality of floating-pointing entities. if (abs(pf(0.54030231_k) - ACOS(0.54030231_k)) > 1e-7) STOP 2 print *, 'PASS' end program
[Bug c++/95434] ICE for CTAD in generic lambda within variadic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95434 Johel Ernesto Guerrero Peña changed: What|Removed |Added Known to work||11.0 Status|ASSIGNED|RESOLVED URL||https://godbolt.org/z/-fZVX ||4 Known to fail||10.1.0 Resolution|--- |FIXED --- Comment #6 from Johel Ernesto Guerrero Peña --- Thank you.
[Bug c++/95486] ICE for alias CTAD with non-dependent argument and constrained constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95486 --- Comment #5 from Johel Ernesto Guerrero Peña --- Thank you. I was under the mistaken impression that the above was only a partial solution. Adding the following deduction guide restores the ICE. See https://godbolt.org/z/fej7WT. ```C++ template X(U) -> X; ```
[Bug c++/98949] New: gcc-9.3 aarch64 -ftree-vectorize generates wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98949
Bug ID: 98949
Summary: gcc-9.3 aarch64 -ftree-vectorize generates wrong code
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: cyb70289 at gmail dot com
Target Milestone: ---
Assertion fired in below test code when compiled with g++-9.3 aarch64 -O3.
Disable tree-vectorize fixes the issue.
g++-7, g++-10 don't have this problem.
$ uname -m
aarch64
$ g++-9 --version
g++-9 (Ubuntu 9.3.0-11ubuntu0~18.04.1) 9.3.0
$ g++-9 -O3 -march=armv8-a test.cc && ./a.out
a.out: test.cc:27: int main(): Assertion `bitmap[7] != 0' failed.
Aborted (core dumped)
$ g++-9 -O3 -fno-tree-vectorize -march=armv8-a test.cc && ./a.out
[assertion not fired]
test.cc
===
#include
#include
int main(void) {
uint64_t a[64], b[64];
for (int i = 0; i < 64; ++i) {
a[i] = 1;
b[i] = 2;
}
a[63] = b[63]; // only last element is the same
uint8_t bitmap[8]; // holds 64 bits, bit_i = 1 if (a[i] == b[i]) else 0, i =
0 ~ 63
int index = 0; // index to a[], b[]
for (int byte = 0; byte < 8; ++byte) {
uint8_t out_results[8]; // holds 8 comparison results temporarily
for (int bit = 0; bit < 8; ++bit) {
out_results[bit] = a[index] == b[index];
++index;
}
bitmap[byte] = (out_results[0] | out_results[1] << 1 | out_results[2] << 2
|
out_results[3] << 3 | out_results[4] << 4 | out_results[5]
<< 5 |
out_results[6] << 6 | out_results[7] << 7);
}
// last bitmap should be non-zero, fired on gcc-9.3 aarch64 -O3
assert(bitmap[7] != 0);
return 0;
}
[Bug target/98914] [11 Regression] ICE in rs6000_expand_vector_set, at config/rs6000/rs6000.c:7198
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98914
--- Comment #1 from luoxhu at gcc dot gnu.org ---
The type of k in the case should be "long" to reproduce the issue,
ICE happens at
rs6000_expand_vector_set: gcc_assert (GET_MODE (idx) == E_SImode);
Reason is the vector index variable need be "signed int" for all vec_insert
prototype.
ELFv2 ABI:
vector signed char vec_insert (signed char, vector signed char, signed int);
vector unsigned char vec_insert (unsigned char, vector unsigned char, signed
int);
vector signed int vec_insert (signed int, vector signed int, signed int);
vector unsigned int vec_insert (unsigned int, vector unsigned int, signed int);
vector signed long long vec_insert (signed long long, vector signed long long,
signed int);
Not sure all targets like X86/AArch64 also has some requirements, and whether
below fix reasonable to not generate IFN VEC_SET for stmt like
VIEW_CONVERT_EXPR(v)[k_7] = 170; ?
diff --git a/gcc/gimple-isel.cc b/gcc/gimple-isel.cc
index 2c78a08d3f1..dbbae270a36 100644
--- a/gcc/gimple-isel.cc
+++ b/gcc/gimple-isel.cc
@@ -77,6 +77,7 @@ gimple_expand_vec_set_expr (gimple_stmt_iterator *gsi)
tree view_op0 = TREE_OPERAND (op0, 0);
machine_mode outermode = TYPE_MODE (TREE_TYPE (view_op0));
if (auto_var_in_fn_p (view_op0, cfun->decl)
+ && TYPE_MODE (TREE_TYPE (pos)) == E_SImode
&& !TREE_ADDRESSABLE (view_op0) && can_vec_set_var_idx_p (outermode))
{
location_t loc = gimple_location (stmt);
[Bug fortran/98948] New: unexpected error in procedure pointer initialization or assignment with intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98948 Bug ID: 98948 Summary: unexpected error in procedure pointer initialization or assignment with intrinsic Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: xiao@compiler-dev.com Target Milestone: --- the test case is: program test implicit none procedure(real*4), pointer :: pf => ABS print *, pf(-6.5_4) if(pf(-6.5_4) /= ABS(-6.5_4)) STOP 1 pf => ACOS print *, pf(0.54030231_4) if(pf(0.54030231_4) /= ACOS(0.54030231_4)) STOP 2 print *, 'PASS' end program the error under gfortran 10.0 is: bbb.f90:3:41: 3 | procedure(real*4), pointer :: pf => ABS | 1 Error: Symbol ‘abs’ at (1) has no IMPLICIT type bbb.f90:8:12: 8 | pf => ACOS |1 Error: Symbol ‘acos’ at (1) has no IMPLICIT type If annotate those two if-stmt, the test case will function well. And the result is: 6.5000 0.99940 PASS
[Bug debug/98946] GCC generating incorrect relocation R_386_GOTOFF in .debug-info for x86 (32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98946 --- Comment #2 from Manoj Gupta --- Created attachment 50117 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50117&action=edit dl-close.s file generated by GCC
[Bug debug/98946] GCC generating incorrect relocation R_386_GOTOFF in .debug-info for x86 (32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98946 --- Comment #1 from Manoj Gupta --- For ease of search, the problem I think lies at Line 6957 of dl-close.s. dl-close.s file line 6957: .long .LC3@gotoff It is part of .debug_info section and it has GOTOFF relocation This matches the LLD complain: ld.lld: error: dl-close.c:(.debug_info+0x1E6A): has non-ABS relocation R_386_GOTOFF against symbol '.LC3
[Bug c/98945] gcc does not warn when assigning value of type int (*)() to variable of type int (*)(double)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98945 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=97882 Ever confirmed|0 |1 Keywords||diagnostic CC||msebor at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2021-02-03 --- Comment #1 from Martin Sebor --- Confirmed. It's somewhat related to pr97882 in that the warning depends on the result of comp_target_types() which considers int (*)(double) compatible with int(*)() but int (*)(float) incompatible. The warning is issued in convert_for_assignment(). Interestingly, on Godbolt, both Clang and ICC behave just like GCC. Only MSVC warns for both assignments.
[Bug c++/98926] [11 regression] several ICEs after r11-7011
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98926 --- Comment #8 from seurer at gcc dot gnu.org --- Here was what I saw on a power 8 comparing r11-7010 with r11-7011: previous run: g:bec5dbae5649da4bd7ea2731a8446ac481cb78ab, r11-7010: 50 failures this run: g:6e0a231a4aa2407bb7167daf98a37795a67364d8, r11-7011: 61 failures FAIL: g++.dg/cpp0x/alias-decl-52.C -std=c++2a (internal compiler error) FAIL: g++.dg/cpp0x/alias-decl-52.C -std=c++2a (test for excess errors) FAIL: g++.dg/lto/pr65549 cp_lto_pr65549_0.o assemble, -std=gnu++14 -flto -g -O2 -fno-inline -flto-partition=max -Wno-return-type (internal compiler error) FAIL: g++.dg/lto/pr65549 cp_lto_pr65549_0.o assemble, -std=gnu++14 -flto -g -Wno-return-type (internal compiler error) FAIL: g++.dg/pr77550.C (test for excess errors) FAIL: g++.dg/warn/Warray-bounds15.C -std=gnu++14 (test for warnings, line 38) FAIL: g++.dg/warn/Warray-bounds15.C -std=gnu++14 (internal compiler error) FAIL: g++.dg/warn/Warray-bounds15.C -std=gnu++14 (test for excess errors) FAIL: g++.dg/warn/Warray-bounds15.C -std=gnu++17 (test for warnings, line 38) FAIL: g++.dg/warn/Warray-bounds15.C -std=gnu++17 (internal compiler error) FAIL: g++.dg/warn/Warray-bounds15.C -std=gnu++17 (test for excess errors)
[Bug c++/98947] New: Incorrect warning when using a ternary operator to select one of two volatile variables to write to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98947
Bug ID: 98947
Summary: Incorrect warning when using a ternary operator to
select one of two volatile variables to write to
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: headch at gmail dot com
Target Milestone: ---
Using a ternary operator to select one of two variables of the same
volatile-qualified type and then writing into the selected variable yields a
warning in C++2a mode, which I believe either it should not or it is
incorrectly worded.
$ cat test.cpp
volatile int x, y;
void f(bool b) {
(b ? x : y) = 27;
}
$ g++-10.2.0 -Wall -Wextra -std=c++2a -c test.cpp
test.cpp: In function ‘void f(bool)’:
test.cpp:4:14: warning: using value of simple assignment with
‘volatile’-qualified left operand is deprecated [-Wvolatile]
4 | (b ? x : y) = 27;
| ^~~~
test.cpp:4:14: warning: using value of simple assignment with
‘volatile’-qualified left operand is deprecated [-Wvolatile]
$ g++-10.2.0 --version
g++-10.2.0 (Gentoo 10.2.0-r5 p6) 10.2.0
Copyright (C) 2020 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.
I’m not sure whether this code is even deprecated or not. Either way, though,
the warning is wrong. I am not, as the warning claims, using the return value
of the assignment operator.
The roughly equivalent form “*(b ? &x : &y) = 27;” does not generate a warning.
The even more similar, and silly, “*&(b ? x : y) = 27;” also does not generate
a warning.
[Bug debug/98946] New: GCC generating incorrect relocation R_386_GOTOFF in .debug-info for x86 (32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98946 Bug ID: 98946 Summary: GCC generating incorrect relocation R_386_GOTOFF in .debug-info for x86 (32) Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: manojgupta at google dot com Target Milestone: --- Created attachment 50116 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50116&action=edit pre-processed files and gcc command limes This might be related to an older bug 82630 that fixed a similar issue for R_386_GOTPC relocations. Chromium OS bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1171829 We are hitting a similar problem when upgrading to GCC 10.2.1 in Chrome OS. the affected files are in glibc 2.27 where the presence of R_386_GOTOFF is causing LLD linker to complain. This is breaking static linking on 32-bit for us. The errors look like: ld.lld: error: dl-close.c:(.debug_info+0x1E6A): has non-ABS relocation R_386_GOTOFF against symbol '.LC3' ld.lld: error: dl-profile.c:(.debug_info+0x1A7C): has non-ABS relocation R_386_GOTOFF against symbol '.LC4' ld.lld: error: dl-lookup.c:(.debug_info+0x23FA): has non-ABS relocation R_386_GOTOFF against symbol '.LC8' ld.lld: error: dl-reloc.c:(.debug_info+0x3555): has non-ABS relocation R_386_GOTOFF against symbol '.LC7' ld.lld: error: dl-load.c:(.debug_info+0x1B1C): has non-ABS relocation R_386_GOTOFF against symbol '.LC65' ld.lld: error: malloc.c:(.debug_info+0x28D5): has non-ABS relocation R_386_GOTOFF against symbol '.LC2' ld.lld: error: plural.c:(.debug_loc+0xFA4): has non-ABS relocation R_386_GOTOFF against symbol 'yyr2' It was suggested on the bug by Fangrui who is our LLD expert that this might be a GCC bug. "Relocations from .debug_info referencing .text.* can only be absolute relocation types or DTPREL (TLS)-like." There was a previous fix for a similar bug: https://gcc.gnu.org/git/?p=gcc.git&a=commit;h=6b10f1741a1d79c9e32e8790fb98ba93c864b219 . Maybe the fix needs to be extended to handle the R_386_GOTOFF relocations. I am attaching one of the files LLD is complaining (dl-close.c) with intermediate steps and output of "-v" command line. The assembler being used is GNU assembler 2.35.1. Please let me know if more information is needed.
[Bug c++/98926] [11 regression] several ICEs after r11-7011
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98926 --- Comment #7 from seurer at gcc dot gnu.org --- gcc112 is an LE machine and the ICEs were mostly on BE. Try it on gcc110 or 203 which appear to be BE. Looking through my logs I see I got different errors and ICEs on different LE machines. Maybe the hardware level (power 8 vs. 9 for instance) has something to do with it.
[Bug middle-end/90904] vec assignment and copying undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90904 --- Comment #5 from Martin Sebor --- Looks like move ctor/assignment have been added to auto_vec in g:4b9d61f79c0c0185a33048ae6cc72269cf7efa31 but not copy ctor/assignment.
[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519 Michael Meissner changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|meissner at gcc dot gnu.org|unassigned at gcc dot gnu.org
[Bug c/98945] New: gcc does not warn when assigning value of type int (*)() to variable of type int (*)(double)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98945 Bug ID: 98945 Summary: gcc does not warn when assigning value of type int (*)() to variable of type int (*)(double) Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: rogi at skylittlesystem dot org Target Milestone: --- gcc complains about assigning a value of type `int (*)()` to a variable of type `int (*)(float)`, but not for a variable of type `int (*)(double)`, which I thought to be a minor bug. First observed on version 9.3.0, and also after updating 10.2.1, both give the same result. Here's a small test case: ``` $ gcc -O0 -Wall -o a.out -xc - <: In function 'main': :8:35: warning: initialization of 'int (*)(float)' from incompatible pointer type 'int (*)()' [-Wincompatible-pointer-types] :9:15: warning: unused variable 'p_double' [-Wunused-variable] :8:15: warning: unused variable 'p_float' [-Wunused-variable] ``` thanks <3
[Bug ipa/98594] [11 Regression] IPA modref codegen bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98594 --- Comment #6 from Jeffrey A. Law --- Duh. I should have seen the reinterpret_cast as a red flag on this one. And not surprising -fno-strict-aliasing makes the glm testsuite happy. Sorry for the noise.
[Bug c++/98926] [11 regression] several ICEs after r11-7011
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98926 --- Comment #6 from Jakub Jelinek --- I can reproduce it on x86_64 with extra options: ./cc1plus -quiet -fnon-call-exceptions -fno-inline-functions-called-once -fno-tree-sra --param early-inlining-insns=1 pr94582.C -fchecking=2 --param=hash-table-verification-limit=100
[Bug c++/98926] [11 regression] several ICEs after r11-7011
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98926 --- Comment #5 from Jason Merrill --- Hmm, I just did a bootstrap/check on gcc112, and don't get any of the ICEs, but I do see the alias-decl-52.C failure, so I'll poke more at that.
[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519 --- Comment #22 from Segher Boessenkool --- Don't replace the constraints. For one thing, this is very hard to do correctly. Just make the "m" constraint not allow prefixed memory in asms, like I said above. (So all "general_operand" even!)
[Bug c++/98531] [11 Regression] g++.dg/modules/xtreme-header-2_a.H etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98531 --- Comment #10 from Nathan Sidwell --- while I didn't expect https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564224.html to fix the reported failure, I did hope for progress. (the original failure is tickling a chain of events). I realize I didn';t check fno-cxa-atexit in the module path -- just the ABI path, thanks for mentioning solaris 11.4 and 11.3 are different in this regard.
[Bug c++/98944] New: [modules] Failed to read compiled module with a non-exported partition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98944
Bug ID: 98944
Summary: [modules] Failed to read compiled module with a
non-exported partition.
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
Example 1 from the std:
tu1:
export module A;
export import :Foo;
export int baz();
tu2:
export module A:Foo;
import :Internals;
export int foo() { return 2 * (bar() + 1); }
tu3:
module A:Internals;
int bar();
tu4:
module A;
import :Internals;
int bar() { return baz() - 10; }
int baz() { return 30; }
g++ -std=c++20 -fmodules-ts /source/test/module/mu-tu-3.cxx -S
g++ -std=c++20 -fmodules-ts /source/test/module/mu-tu-2.cxx -S
g++ -std=c++20 -fmodules-ts /source/test/module/mu-tu-1.cxx -S
ls gcm.cache/
A-Foo.gcm A-Internals.gcm A.gcm
g++ -std=c++20 -fmodules-ts /source/test/module/mu-tu-4.cxx -S
A: error: failed to read compiled module: Bad file data
A: note: compiled module file is ‘gcm.cache/A.gcm’
...
[Bug target/98927] Code using _mm_extract_epi16 compiles with -O3 but not on other optimization modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98927 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- As we use inline functions, it is required to diagnose this only after inlining, and historically we've been doing that during expansion, so that even if a constant materializes through optimizations it is accepted. I think not diagnosing this when the loop is unrolled and only constants make it in is just fine.
[Bug driver/98943] New: gcc driver does not fail on unknown files: tricks configure scripts to recognize /W4 and -diag-disable 1,2,3,4 options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98943 Bug ID: 98943 Summary: gcc driver does not fail on unknown files: tricks configure scripts to recognize /W4 and -diag-disable 1,2,3,4 options Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: slyfox at gcc dot gnu.org Target Milestone: --- Example failures are extracted from Gentoo downstream: - https://bugs.gentoo.org/768399: gdal build failure (-diag-disable) - https://bugs.gentoo.org/768222: lz4 build failure (/W4 option) $ gcc-11.0.0 /W4 -c -x c /dev/null gcc-11.0.0: warning: /W4: linker input file unused because linking not done $ gcc-10.2.0 /W4 -c -x c /dev/null gcc-10.2.0: error: /W4: No such file or directory $ gcc-11.0.0 -diag-disable 188,1684,2259,2304,3280,11074,11076 -c -x c /dev/null cc1: warning: unrecognized gcc debugging option: i cc1: warning: unrecognized gcc debugging option: g cc1: warning: unrecognized gcc debugging option: - cc1: warning: unrecognized gcc debugging option: d cc1: warning: unrecognized gcc debugging option: i cc1: warning: unrecognized gcc debugging option: s cc1: warning: unrecognized gcc debugging option: b cc1: warning: unrecognized gcc debugging option: l cc1: warning: unrecognized gcc debugging option: e gcc-11.0.0: warning: 188,1684,2259,2304,3280,11074,11076: linker input file unused because linking not done $ gcc-10.2.0 -diag-disable 188,1684,2259,2304,3280,11074,11076 -c -x c /dev/null gcc-10.2.0: error: 188,1684,2259,2304,3280,11074,11076: No such file or directory Was gcc change intentional and upstream packages should try harder to test flags against linker as well? Or it's an unintentional gcc change? Thanks! $ gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-11.0.0_pre/work/gcc-11.0.0_pre/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/11.0.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.0.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.0.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.0.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include/g++-v11 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/11.0.0/python --enable-languages=c,c++,go,jit,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 11.0.0_pre p6, commit 33a1e511b57465d898429740377466894a0b247d' --disable-esp --enable-libstdcxx-time --enable-host-shared --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all --enable-libgomp --disable-libssp --disable-libada --disable-systemtap --enable-valgrind-annotations --enable-vtable-verify --with-zstd --enable-lto --with-isl --disable-isl-version-check --enable-default-pie --enable-default-ssp Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.0.0 20210201 (experimental) (Gentoo 11.0.0_pre p6, commit 33a1e511b57465d898429740377466894a0b247d)
[Bug c++/98941] [C++23] Implement P0330R2 - Literal Suffixes for ptrdiff_t and size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98941 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |emsr at gcc dot gnu.org CC||jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/98295] [8/9/10 Regression] ICE in verify_ctor_sanity, at cp/constexpr.c:4312
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98295 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Patrick Palka --- Fixed.
[Bug c++/98942] [C++23] Implement P1102R2 - Down with ()!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98942 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-02-02 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/98942] New: [C++23] Implement P1102R2 - Down with ()!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98942 Bug ID: 98942 Summary: [C++23] Implement P1102R2 - Down with ()! Product: gcc Version: 11.0 URL: https://wg21.link/p1102r2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mpolacek at gcc dot gnu.org Blocks: 98940 Target Milestone: --- A proposal for removing unnecessary ()’s from C++ lambdas. (Assuming this will be voted in.) Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98940 [Bug 98940] Implement C++23 language features
[Bug tree-optimization/98937] [11 Regression] pointer_query cache leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98937 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #1 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-February/564743.html
[Bug c++/98941] [C++23] Implement P0330R2 - Literal Suffixes for ptrdiff_t and size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98941 --- Comment #1 from Marek Polacek --- WIP: https://gcc.gnu.org/pipermail/gcc-patches/2021-February/564675.html
[Bug c++/98941] [C++23] Implement P0330R2 - Literal Suffixes for ptrdiff_t and size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98941 Marek Polacek changed: What|Removed |Added Last reconfirmed||2021-02-02 Blocks||98940 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 URL||https://wg21.link/p0330r8 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98940 [Bug 98940] Implement C++23 language features
[Bug c++/98941] New: [C++23] Implement P0330R2 - Literal Suffixes for ptrdiff_t and size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98941 Bug ID: 98941 Summary: [C++23] Implement P0330R2 - Literal Suffixes for ptrdiff_t and size_t Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mpolacek at gcc dot gnu.org Target Milestone: --- This paper proposes core language suffixes for size_t and its associated signed type.
[Bug c++/98940] Implement C++23 language features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98940 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-02-02 Status|UNCONFIRMED |NEW
[Bug c++/98940] New: Implement C++23 language features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98940 Bug ID: 98940 Summary: Implement C++23 language features Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: meta-bug Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mpolacek at gcc dot gnu.org Depends on: 98939 Target Milestone: --- A meta bug to track the overall progress of C++23 features in the C++ FE. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98939 [Bug 98939] [C++23] Implement P1787R6 "Declarations and where to find them"
[Bug libstdc++/88101] Implement P0528R3, C++20 cmpxchg and padding bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88101 --- Comment #12 from Jakub Jelinek --- The compiler side is done, but the libstdc++-v3 side is not on the trunk yet.
[Bug libstdc++/88101] Implement P0528R3, C++20 cmpxchg and padding bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88101 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #11 from Marek Polacek --- Any remaining work here?
[Bug c++/98939] [C++23] Implement P1787R6 "Declarations and where to find them"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98939 Jason Merrill changed: What|Removed |Added Version|10.0|11.0 Last reconfirmed||2021-02-02 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug c++/98939] New: [C++23] Implement P1787R6 "Declarations and where to find them"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98939
Bug ID: 98939
Summary: [C++23] Implement P1787R6 "Declarations and where to
find them"
Product: gcc
Version: 10.0
URL: http://wg21.link/p1787r6
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jason at gcc dot gnu.org
Target Milestone: ---
The changes from this paper should not affect a significant amount of code;
many are clarifications that bring the wording in line with existing practice,
some are clarifications of corner cases that most code doesn't depend on, like
ambiguous lookup within a conversion-type-id.
A few changes that allow code that has been ill-formed:
conversion-type-id is added to the list of type-only contexts from P0634:
template struct A { operator T::type(); }; // OK
::template is also not required in type-only contexts:
template auto f(T t) { return static_cast>(t); } // OK
Default template arguments are now complete-class contexts, like default
function arguments:
template struct A {
template void g() { } // OK
T t;
};
One change that might break a small amount of existing code:
Since lookup for a name after . or -> now happens first in the scope of the
object, .template is required in dependent.template X<...> even if a definition
of X would be found by unqualified lookup.
template struct X { void f(); };
template void g(T t) { t.X<2>::f(); } // error, needs .template
[Bug target/97510] [9/10/11 Regression] ICE in check_bool_attrs, at recog.c:2168 since r9-2793-gf6b95f78f8048e2f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97510 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Martin Liška --- Fixed on master.
[Bug target/97510] [9/10/11 Regression] ICE in check_bool_attrs, at recog.c:2168 since r9-2793-gf6b95f78f8048e2f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97510 --- Comment #5 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:db53dd4f784d5d36c2119dd66a22ad40b5020b1c commit r11-7045-gdb53dd4f784d5d36c2119dd66a22ad40b5020b1c Author: Martin Liska Date: Tue Feb 2 20:02:47 2021 +0100 Add test-case. gcc/testsuite/ChangeLog: PR target/97510 * gcc.target/i386/pr97510.c: New test.
[Bug c++/98938] New: throw calls move constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98938
Bug ID: 98938
Summary: throw calls move constructor
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: njormrod at fb dot com
Target Milestone: ---
Throwing invokes the move constructor instead of the copy constructor.
Demonstration of move-constructor in godbolt: https://gcc.godbolt.org/z/zhjv5z
Demonstration of copy-constructor using clang: https://gcc.godbolt.org/z/E3MEef
>From 14.2 Throwing an exception [except.throw]: "Throwing an exception
copy-initializes (9.4, 11.4.5.3) a temporary object, called the exception
object."
Code (as used in godbolt):
```
#include
struct A : std::exception {
A(int* q) : p(q) {}
A(const A& a) : p(a.p) { *p = 12345; }
A(A&& a) : p(a.p) { *p = 56789; }
int* p;
};
int foo() {
int i = 10;
A a(&i);
try {
throw a;
} catch (A&) {}
return i;
}
```
[Bug tree-optimization/98932] Wrong output with -O3 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98932 Martin Liška changed: What|Removed |Added Known to work||11.0 CC||rguenth at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org Status|ASSIGNED|NEW Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #3 from Martin Liška --- Ok, so the issue was fixed in g:74166aabeb7f22990476b1169bba031b8323ee92, which is about a preferred vector types. So with the following patch: diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c index 9e88438b3c3..1e5a05a00b0 100644 --- a/gcc/config/aarch64/aarch64.c +++ b/gcc/config/aarch64/aarch64.c @@ -17351,14 +17351,14 @@ aarch64_autovectorize_vector_modes (vector_modes *modes, bool) TODO: We could support a limited form of V4QImode too, so that we use 32-bit vectors for 8-bit elements. */ -V4HImode, +//V4HImode, /* Try using 64-bit vectors for 32-bit elements and 128-bit vectors for 64-bit elements. TODO: We could similarly support limited forms of V2QImode and V2HImode for this case. */ -V2SImode +//V2SImode }; /* Try using N-byte SVE modes only after trying N-byte Advanced SIMD mode. @@ -23901,8 +23901,8 @@ aarch64_libgcc_floating_mode_supported_p #define TARGET_VECTORIZE_VEC_PERM_CONST \ aarch64_vectorize_vec_perm_const -#undef TARGET_VECTORIZE_RELATED_MODE -#define TARGET_VECTORIZE_RELATED_MODE aarch64_vectorize_related_mode +//#undef TARGET_VECTORIZE_RELATED_MODE +//#define TARGET_VECTORIZE_RELATED_MODE aarch64_vectorize_related_mode #undef TARGET_VECTORIZE_GET_MASK_MODE #define TARGET_VECTORIZE_GET_MASK_MODE aarch64_get_mask_mode #undef TARGET_VECTORIZE_EMPTY_MASK_IS_EXPENSIVE I tracked that it was fixed with g:04b99da898a9817e72fedb4063589648b7961ac5, which is a vectorizer related revision. Thus it's likely dup of PR97236. Can we backport the fixed into 8 and 9 branch?
[Bug c++/41091] Using section attribute in c and c++ function causes section type conflict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41091 David L. changed: What|Removed |Added CC||equinox-gccbugs at diac24 dot net --- Comment #8 from David L. --- Issue persists in gcc 10.2, test program from comment #6 still errors out. We're hitting this bug in production/real-world code [ https://github.com/FRRouting/frr/pull/6766 ]. What we're doing is very similar to SystemTap's trace points, I believe those might be affected as well. clang++ works fine meanwhile.
[Bug c/97882] [8/9/10/11 Regression] Segmentation Fault on improper redeclaration of function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97882 --- Comment #4 from Martin Sebor --- A couple of data points: Clang doesn't support nested functions in any form, and ICC silently all three storage specifiers (auto, extern, as well as static) on their definitions and rejects only register.
[Bug c++/98926] [11 regression] several ICEs after r11-7011
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98926 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/98929] [11 Regression] Internal compiler error on gcc trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98929 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Jason Merrill --- Fixed.
[Bug c++/98929] [11 Regression] Internal compiler error on gcc trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98929 --- Comment #5 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:709718d4d89e5976257f53e67dcb8ba704574c56 commit r11-7044-g709718d4d89e5976257f53e67dcb8ba704574c56 Author: Jason Merrill Date: Tue Feb 2 10:08:48 2021 -0500 c++: Member fns and deduction guide rewriting [PR98929] My patch for 96199 had us re-substitute the parameter types of a constructor in order to rewrite mentions of members into dependent references. We need to do that for member functions, too. gcc/cp/ChangeLog: PR c++/98929 PR c++/96199 * error.c (dump_expr): Ignore dummy object. * pt.c (tsubst_baselink): Handle dependent scope. gcc/testsuite/ChangeLog: PR c++/98929 * g++.dg/cpp1z/class-deduction-decltype1.C: New test.
[Bug c++/96199] [10/11 Regression] internal compiler error: in tsubst_copy with CTAD for alias templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96199 --- Comment #10 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:709718d4d89e5976257f53e67dcb8ba704574c56 commit r11-7044-g709718d4d89e5976257f53e67dcb8ba704574c56 Author: Jason Merrill Date: Tue Feb 2 10:08:48 2021 -0500 c++: Member fns and deduction guide rewriting [PR98929] My patch for 96199 had us re-substitute the parameter types of a constructor in order to rewrite mentions of members into dependent references. We need to do that for member functions, too. gcc/cp/ChangeLog: PR c++/98929 PR c++/96199 * error.c (dump_expr): Ignore dummy object. * pt.c (tsubst_baselink): Handle dependent scope. gcc/testsuite/ChangeLog: PR c++/98929 * g++.dg/cpp1z/class-deduction-decltype1.C: New test.
[Bug tree-optimization/98937] [11 Regression] pointer_query cache leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98937 Martin Sebor changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-02-02 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org
[Bug c/97882] [8/9/10/11 Regression] Segmentation Fault on improper redeclaration of function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97882
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC||msebor at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
--- Comment #3 from Martin Sebor ---
While testing a fix for this I came up with the following variation on the
original test case:
void f (void)
{
auto enum E g (); // valid?
unsigned g () { }
}
This also ICEs but I'm not sure if it should be fixed the same way as the
original
or rather by rejecting the auto storage specifier on nested function
declarations. Since nested functions are implicitly static the auto is in
conflict with that, the same way extern is below. Shouldn't the auto be
rejected? (There are tests that expect this to be valid, e.g.,
gcc.dg/nested-func-3.c.)
$ cat t.c && /build/gcc-trunk/gcc/cc1 t.c
void f (void)
{
extern enum E g ();
unsigned g () { }
}
f g
t.c:4:12: error: static declaration of ‘g’ follows non-static declaration
4 | unsigned g () { }
|^
t.c:3:17: note: previous declaration of ‘g’ was here
3 | extern enum E g ();
| ^
t.c: In function ‘g’:
t.c:4:3: internal compiler error: Segmentation fault
4 | unsigned g () { }
| ^~~~
0x13f321a crash_signal
/src/gcc/trunk/gcc/toplev.c:327
0xbdc3b4 must_pass_in_stack_var_size_or_pad(function_arg_info const&)
/src/gcc/trunk/gcc/calls.c:6282
[Bug target/92168] Poor code generation for addcarry / subborrow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92168 --- Comment #6 from Jakub Jelinek --- I mean r11-3882-g06bec55e80d98419121f3998d98d969990a75b0b
[Bug target/92168] Poor code generation for addcarry / subborrow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92168 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Yes, at least the #c3 testcase with r11-3880-ga121715bcab6e8980768d142b9781c45821130ac
[Bug target/92168] Poor code generation for addcarry / subborrow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92168 Gabriel Ravier changed: What|Removed |Added CC||gabravier at gmail dot com --- Comment #4 from Gabriel Ravier --- Seems to be fixed on trunk.
[Bug target/98931] [11 Regression] arm: Assembly fails with "branch out of range or not a multiple of 2" since r11-2012
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98931 --- Comment #5 from Jakub Jelinek --- At the end of shorten_branches the label the doloop_end insn wants to jump to has (gdb) p insn_addresses_[2361] $1 = (int &) @0x2e264ac: 22 and the doloop_end is (gdb) p insn_addresses_[2397] $2 = (int &) @0x2e2653c: 7150 If that is in bytes, then it is conservatively correct (perhaps too large), if it is in 2 byte units, then it is not accurate.
[Bug target/98931] [11 Regression] arm: Assembly fails with "branch out of range or not a multiple of 2" since r11-2012
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98931 --- Comment #4 from Andrea Corallo --- "jakub at gcc dot gnu.org via Gcc-bugs" writes: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98931 > > --- Comment #3 from Jakub Jelinek --- > And the problem is not something not being multiple of 2, but just out of > range > jump. The code has: > 10: f04e e001 dls lr, lr > 14: 9900ldr r1, [sp, #0] > ... > 130e: f00f c7ff le lr, 316 > if I manually move .L2 label so that it doesn't complain anymore, which means > it can jump only to -4096 bytes from the end of the le instruction, but it was > supposed to jump to foo+0x14, i.e. to 4862 bytes before the end of the le insn > at 0x1312. > So, either the computation of the instruction sizes is incorrect, or for this > kind of branch nothing checks whether the distance is in range. I think this (the second) is the case.
Re: [Bug target/98931] [11 Regression] arm: Assembly fails with "branch out of range or not a multiple of 2" since r11-2012
"jakub at gcc dot gnu.org via Gcc-bugs" writes: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98931 > > --- Comment #3 from Jakub Jelinek --- > And the problem is not something not being multiple of 2, but just out of > range > jump. The code has: > 10: f04e e001 dls lr, lr > 14: 9900ldr r1, [sp, #0] > ... > 130e: f00f c7ff le lr, 316 > if I manually move .L2 label so that it doesn't complain anymore, which means > it can jump only to -4096 bytes from the end of the le instruction, but it was > supposed to jump to foo+0x14, i.e. to 4862 bytes before the end of the le insn > at 0x1312. > So, either the computation of the instruction sizes is incorrect, or for this > kind of branch nothing checks whether the distance is in range. I think this (the second) is the case.
[Bug fortran/98897] Erroneous procedure attribute for associate name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98897 --- Comment #3 from Damian Rouson --- Thanks for the quick fix, Paul! Any chance of this being back-ported to the 10 branch?
[Bug target/98931] [11 Regression] arm: Assembly fails with "branch out of range or not a multiple of 2" since r11-2012
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98931 --- Comment #3 from Jakub Jelinek --- And the problem is not something not being multiple of 2, but just out of range jump. The code has: 10: f04e e001 dls lr, lr 14: 9900ldr r1, [sp, #0] ... 130e: f00f c7ff le lr, 316 if I manually move .L2 label so that it doesn't complain anymore, which means it can jump only to -4096 bytes from the end of the le instruction, but it was supposed to jump to foo+0x14, i.e. to 4862 bytes before the end of the le insn at 0x1312. So, either the computation of the instruction sizes is incorrect, or for this kind of branch nothing checks whether the distance is in range.
[Bug tree-optimization/98937] [11 Regression] pointer_query cache leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98937 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0 Keywords||memory-hog CC||msebor at gcc dot gnu.org
[Bug tree-optimization/98937] New: [11 Regression] pointer_query cache leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98937 Bug ID: 98937 Summary: [11 Regression] pointer_query cache leaks Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- ==25237== 2,634,236 bytes in 1 blocks are possibly lost in loss record 9,732 of 9,737 ==25237==at 0x4C308BF: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==25237==by 0x1547AFC: xrealloc (xmalloc.c:179) ==25237==by 0x67CB71: reserve (vec.h:290) ==25237==by 0x67CB71: reserve (vec.h:1778) ==25237==by 0x67CB71: safe_grow (vec.h:1926) ==25237==by 0x67CB71: safe_grow_cleared (vec.h:1945) ==25237==by 0x67CB71: pointer_query::put_ref(tree_node*, access_ref const&, int) (builtins.c:705) ==25237==by 0x6864DF: compute_objsize_r(tree_node*, int, access_ref*, ssa_name_limit_t&, pointer_query*) (builtins.c:5739) ==25237==by 0x68CEAD: compute_objsize(tree_node*, int, access_ref*, pointer_query*) (builtins.c:5775) ==25237==by 0xC4BFD1: maybe_warn_overflow(gimple*, tree_node*, pointer_query&, strinfo*, bool, bool) (tree-ssa-strlen.c:1952) ==25237==by 0xC5642F: handle_builtin_memset (tree-ssa-strlen.c:3687) ==25237==by 0xC5642F: strlen_check_and_optimize_call (tree-ssa-strlen.c:5178) ==25237==by 0xC5642F: check_and_optimize_stmt (tree-ssa-strlen.c:5359) ==25237==by 0xC5642F: strlen_dom_walker::before_dom_children(basic_block_def*) (tree-ssa-strlen.c:5602) ==25237==by 0x13366A4: dom_walker::walk(basic_block_def*) (domwalk.c:309) ==25237==by 0xC49ABE: (anonymous namespace)::printf_strlen_execute(function*, bool) (tree-ssa-strlen.c:5668) ==25237==by 0x9E58A3: execute_one_pass(opt_pass*) (passes.c:2567) ==25237==by 0x9E6100: execute_pass_list_1(opt_pass*) (passes.c:2656) ==25237==by 0x9E6112: execute_pass_list_1(opt_pass*) (passes.c:2657) looks like there's no DTOR for pointer_query::cache_type so strlen_dom_walker will not release the two vectors.
[Bug c++/98936] New: Incorrect computation of trivially copyable for class with user-declared move assignment operator, defined as deleted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98936
Bug ID: 98936
Summary: Incorrect computation of trivially copyable for class
with user-declared move assignment operator, defined
as deleted
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: adr26__gcc at nunsway dot co.uk
Target Milestone: ---
Consider the following code:
#include
class Bar {
public:
int A;
// User-declared move assignment operator, defined as deleted
Bar& operator=(Bar&&) = delete;
};
static_assert(!std::is_trivially_copyable::value, "Bar is trivially
copyable");
>From C++11 to C++17, as per CWG 1734
[http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_defects.html#1734], the
definition of a trivially copyable class was as follows (all references taken
from C++17) - in §12 "Classes" [class], §12/6 defines a trivially copyable
class:
“A trivially copyable class is a class:
(6.1) — where each copy constructor, move constructor, copy assignment
operator, and move assignment operator (15.8, 16.5.3) is either deleted or
trivial,
(6.2) — that has at least one non-deleted copy constructor, move
constructor, copy assignment operator, or move assignment operator, and
(6.3) — that has a trivial, non-deleted destructor (15.4).”
1. For §12/6.1 - we can look at copy constructors, move constructors, copy
assignment operators, and move assignment operators in turn.
a. For copy constructors: Bar has no user-declared copy constructor. In
§15.8.1 "Copy/move constructors" [class.copy.ctor], §15.8.1/6 states that a
non-explicit copy constructor will be implicitly declared in the absence of a
user-declared copy constructor:
“If the class definition does not explicitly declare a copy
constructor, a non-explicit one is declared implicitly. If the class definition
declares a move constructor or move assignment operator, the implicitly
declared copy constructor is defined as deleted; otherwise, it is defined as
defaulted (11.4). The latter case is deprecated if the class has a
user-declared copy assignment operator or a user-declared destructor.”
Since Bar has a user-declared move assignment operator, this
implicitly-declared copy constructor is defined as deleted and §12/6.1 is
therefore satisfied with respect to copy constructors.
b. For move constructors: the class Bar has no user-declared move
constructors, and so therefore may only have an implicitly declared move
constructor. §15.8.1/8 specifies the exact and sole conditions under which a
move constructor may be implicitly declared:
“If the definition of a class X does not explicitly declare a move
constructor, a non-explicit one will be implicitly declared as defaulted if and
only if
(8.1) — X does not have a user-declared copy constructor,
(8.2) — X does not have a user-declared copy assignment operator,
(8.3) — X does not have a user-declared move assignment operator, and
(8.4) — X does not have a user-declared destructor.”
We may note that in particular that while Bar does not have an explicitly
declared move constructor, Bar does have a user-declared move assignment
operator so condition §15.8.1/8.3 is not met in any case. As such, Bar will not
have neither a user- nor an implicitly-declared move constructor and therefore
§12/6.1 is trivially satisfied with respect to move constructors (since there
are none).
c. For copy assignment operators: the class Bar has no user-declared copy
assignment operators, and so therefore may only have an implicitly declared
copy assignment operators. §15.8.2 "Copy/move assignment operator"
[class.copy.assign] describes these and §15.8.2/2 specifies how a copy
assignment operator will always be implicitly declared if the class has no
user-declared copy assignment operators:
“If the class definition does not explicitly declare a copy assignment
operator, one is declared implicitly. If the class definition declares a move
constructor or move assignment operator, the implicitly declared copy
assignment operator is defined as deleted; otherwise, it is defined as
defaulted (11.4). The latter case is deprecated if the class has a
user-declared copy constructor or a user-declared destructor.”
Since Bar has a user-declared move assignment operator, this
implicitly-declared copy assignment operator is defined as deleted and §12/6.1
is therefore satisfied with respect to copy assignment operators.
d. For move assignment operators: Bar has one user-declared move assignment
operator, defined as deleted - which therefore satisfies §12/6.1.
Therefore, for each of the copy constructors, move constructors, copy
assignment operators, and move assignment operators of Bar, §12/6.1 is
satisf
[Bug target/98931] [11 Regression] arm: Assembly fails with "branch out of range or not a multiple of 2" since r11-2012
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98931 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Summary|[11 Regression] arm:|[11 Regression] arm: |Assembly fails with "branch |Assembly fails with "branch |out of range or not a |out of range or not a |multiple of 2" |multiple of 2" since ||r11-2012 --- Comment #2 from Jakub Jelinek --- Started with r11-2012-gd2ed233cb940aa3eecc163d98b47979dd81dbc0a
[Bug target/98934] Very poor code generation for SSE 8-bit vector right shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98934 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-02-02 --- Comment #1 from Richard Biener --- Uh, it's a very inefficient lowering as well, relying on constant amount vector word right-shift. But yeah, fancy at least ;)
[Bug target/97510] [9/10/11 Regression] ICE in check_bool_attrs, at recog.c:2168 since r9-2793-gf6b95f78f8048e2f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97510 --- Comment #4 from Martin Liška --- Yes, I'm going to do that.
[Bug target/97510] [9/10/11 Regression] ICE in check_bool_attrs, at recog.c:2168 since r9-2793-gf6b95f78f8048e2f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97510 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Don't we want to add a testcase covering that?
[Bug target/97510] [9/10/11 Regression] ICE in check_bool_attrs, at recog.c:2168 since r9-2793-gf6b95f78f8048e2f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97510 --- Comment #2 from Martin Liška --- It was fixed with r11-5855-ge401db7bfd8cf86d. May I close it as fixed?
[Bug c++/98926] [11 regression] several ICEs after r11-7011
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98926
--- Comment #4 from seurer at gcc dot gnu.org ---
This one is from powerpc64 LE. Same traceback I think.
g:6e0a231a4aa2407bb7167daf98a37795a67364d8, r11-7011
make -k check-gcc RUNTESTFLAGS="lto.exp=g++.dg/lto/pr65549_0.C"
# of unexpected failures2
# of unresolved testcases 4
spawn -ignore SIGHUP
/home/seurer/gcc/git/build/gcc-test2/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/git/build/gcc-test2/gcc/testsuite/g++/../../
-fdiagnostics-plain-output -nostdinc++
-I/home/seurer/gcc/git/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-test2/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-test2/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0
-std=gnu++14 -flto -g -O2 -fno-inline -flto-partition=max -Wno-return-type -c
-o cp_lto_pr65549_0.o
/home/seurer/gcc/git/gcc-test2/gcc/testsuite/g++.dg/lto/pr65549_0.C
hash table checking failed: equal operator returns true for a pair of values
with a different hash value
/home/seurer/gcc/git/gcc-test2/gcc/testsuite/g++.dg/lto/pr65549_0.C: In
substitution of 'template template using _Requires = int [with = std::__and_;
= void; _Res = void; _ArgTypes = {}]':
/home/seurer/gcc/git/gcc-test2/gcc/testsuite/g++.dg/lto/pr65549_0.C:71:32:
required by substitution of 'template
std::function::function(_Functor) [with _Functor = main()::;
= ]'
/home/seurer/gcc/git/gcc-test2/gcc/testsuite/g++.dg/lto/pr65549_0.C:144:4:
required from here
/home/seurer/gcc/git/gcc-test2/gcc/testsuite/g++.dg/lto/pr65549_0.C:71:32:
internal compiler error: in hashtab_chk_error, at hash-table.c:137
0x102b63b3 hashtab_chk_error()
/home/seurer/gcc/git/gcc-test2/gcc/hash-table.c:137
0x10645307 hash_table::verify(spec_entry*
const&, unsigned int)
/home/seurer/gcc/git/gcc-test2/gcc/hash-table.h:1033
0x10645503 hash_table::find_with_hash(spec_entry* const&, unsigned int)
/home/seurer/gcc/git/gcc-test2/gcc/hash-table.h:918
0x105c9ba7 retrieve_specialization
/home/seurer/gcc/git/gcc-test2/gcc/cp/pt.c:1302
0x1062a013 instantiate_template_1
/home/seurer/gcc/git/gcc-test2/gcc/cp/pt.c:20973
0x1062a013 instantiate_template(tree_node*, tree_node*, int)
/home/seurer/gcc/git/gcc-test2/gcc/cp/pt.c:21099
0x105e1073 instantiate_alias_template
/home/seurer/gcc/git/gcc-test2/gcc/cp/pt.c:21137
0x105e1073 tsubst(tree_node*, tree_node*, int, tree_node*)
/home/seurer/gcc/git/gcc-test2/gcc/cp/pt.c:15395
0x106147ef type_unification_real
/home/seurer/gcc/git/gcc-test2/gcc/cp/pt.c:22318
0x10634503 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
/home/seurer/gcc/git/gcc-test2/gcc/cp/pt.c:21493
0x102d0ec3 add_template_candidate_real
/home/seurer/gcc/git/gcc-test2/gcc/cp/call.c:3441
0x102d1e1b add_template_candidate
/home/seurer/gcc/git/gcc-test2/gcc/cp/call.c:3529
0x102d1e1b add_candidates
/home/seurer/gcc/git/gcc-test2/gcc/cp/call.c:5955
0x102daa47 add_candidates
/home/seurer/gcc/git/gcc-test2/gcc/cp/call.c:4087
0x102daa47 build_user_type_conversion_1
/home/seurer/gcc/git/gcc-test2/gcc/cp/call.c:4087
0x102cd873 implicit_conversion_1
/home/seurer/gcc/git/gcc-test2/gcc/cp/call.c:2078
0x102cd873 implicit_conversion
/home/seurer/gcc/git/gcc-test2/gcc/cp/call.c:2118
0x102d01d3 add_function_candidate
/home/seurer/gcc/git/gcc-test2/gcc/cp/call.c:2428
0x102d1cf3 add_candidates
/home/seurer/gcc/git/gcc-test2/gcc/cp/call.c:5968
0x102e4eab add_candidates
/home/seurer/gcc/git/gcc-test2/gcc/cp/call.c:10459
[Bug target/97510] [9/10/11 Regression] ICE in check_bool_attrs, at recog.c:2168 since r9-2793-gf6b95f78f8048e2f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97510 --- Comment #1 from Vladimir Makarov --- I cannot reproduce this on today trunk. The bug might be fixed by some recent patches (probably for PR98777).
[Bug c++/98935] New: [coroutines] co_await on statement expressions causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98935
Bug ID: 98935
Summary: [coroutines] co_await on statement expressions causes
ICE
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mail+gnu at tzik dot jp
Target Milestone: ---
In a repro case below, `co_await ({auto x = future{}; x;});` causes an internal
compiler error.
https://wandbox.org/permlink/3jX83p34mVDfBgc1
The compile command was:
$ g++ -std=c++20 failcase.cc
where g++ was the current trunk (11.0.0).
failcase.cc
#if __has_include()
#include
#elif __has_include()
#include
namespace std {
using namespace std::experimental;
}
#endif
struct future {
struct promise_type {
void return_void() {}
std::suspend_always initial_suspend() noexcept { return {}; }
std::suspend_always final_suspend() noexcept { return {}; }
void unhandled_exception() {}
future get_return_object() { return {}; }
};
bool await_ready() { return false; }
void await_suspend(std::coroutine_handle<>) {}
void await_resume() {}
};
future failcase() {
co_await ({auto x = future{}; x;});
}
And its backtrace was:
prog.cc: In function 'future failcase()':
prog.cc:25:1: internal compiler error: Segmentation fault
25 | }
| ^
0xca67ef crash_signal
../../source/gcc/toplev.c:327
0xf1866b walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../source/gcc/tree.c:12105
0xf18c82 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../source/gcc/tree.c:12340
0xf18ad1 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../source/gcc/tree.c:12204
0x680293 transform_local_var_uses
../../source/gcc/cp/coroutines.cc:1903
0xf1865b walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../source/gcc/tree.c:12099
0x680293 transform_local_var_uses
../../source/gcc/cp/coroutines.cc:1903
0xf1865b walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../source/gcc/tree.c:12099
0xf18ad1 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../source/gcc/tree.c:12204
0xf187aa walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../source/gcc/tree.c:12436
0xf18ad1 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../source/gcc/tree.c:12204
0x680293 transform_local_var_uses
../../source/gcc/cp/coroutines.cc:1903
0xf1865b walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../source/gcc/tree.c:12099
0x680a27 build_actor_fn
../../source/gcc/cp/coroutines.cc:2085
0x6832a5 morph_fn_to_coro(tree_node*, tree_node**, tree_node**)
../../source/gcc/cp/coroutines.cc:4750
0x6b4f87 finish_function(bool)
../../source/gcc/cp/decl.c:17155
0x76da42 cp_parser_function_definition_after_declarator
../../source/gcc/cp/parser.c:29941
0x76eb9c cp_parser_function_definition_from_specifiers_and_declarator
../../source/gcc/cp/parser.c:29854
0x76eb9c cp_parser_init_declarator
../../source/gcc/cp/parser.c:21564
0x74d5b4 cp_parser_simple_declaration
../../source/gcc/cp/parser.c:14381
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/98934] New: Very poor code generation for SSE 8-bit vector right shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98934
Bug ID: 98934
Summary: Very poor code generation for SSE 8-bit vector right
shift
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
typedef char __attribute__((vector_size(16))) v16i8;
v16i8 f(v16i8 x, v16i8 y)
{
return x >> y;
}
With -O3, LLVM outputs this:
f(char __vector(16), char __vector(16)):
punpckhbw xmm2, xmm0 # xmm2 =
xmm2[8],xmm0[8],xmm2[9],xmm0[9],xmm2[10],xmm0[10],xmm2[11],xmm0[11],xmm2[12],xmm0[12],xmm2[13],xmm0[13],xmm2[14],xmm0[14],xmm2[15],xmm0[15]
psllw xmm1, 5
punpckhbw xmm4, xmm1 # xmm4 =
xmm4[8],xmm1[8],xmm4[9],xmm1[9],xmm4[10],xmm1[10],xmm4[11],xmm1[11],xmm4[12],xmm1[12],xmm4[13],xmm1[13],xmm4[14],xmm1[14],xmm4[15],xmm1[15]
pxor xmm3, xmm3
pxor xmm5, xmm5
pcmpgtw xmm5, xmm4
movdqa xmm6, xmm5
pandn xmm6, xmm2
psraw xmm2, 4
pand xmm2, xmm5
por xmm2, xmm6
paddw xmm4, xmm4
pxor xmm5, xmm5
pcmpgtw xmm5, xmm4
movdqa xmm6, xmm5
pandn xmm6, xmm2
psraw xmm2, 2
pand xmm2, xmm5
por xmm2, xmm6
paddw xmm4, xmm4
pxor xmm5, xmm5
pcmpgtw xmm5, xmm4
movdqa xmm4, xmm5
pandn xmm4, xmm2
psraw xmm2, 1
pand xmm2, xmm5
por xmm2, xmm4
psrlw xmm2, 8
punpcklbw xmm0, xmm0 # xmm0 = xmm0[0,0,1,1,2,2,3,3,4,4,5,5,6,6,7,7]
punpcklbw xmm1, xmm1 # xmm1 = xmm1[0,0,1,1,2,2,3,3,4,4,5,5,6,6,7,7]
pxor xmm4, xmm4
pcmpgtw xmm4, xmm1
movdqa xmm5, xmm4
pandn xmm5, xmm0
psraw xmm0, 4
pand xmm0, xmm4
por xmm0, xmm5
paddw xmm1, xmm1
pxor xmm4, xmm4
pcmpgtw xmm4, xmm1
movdqa xmm5, xmm4
pandn xmm5, xmm0
psraw xmm0, 2
pand xmm0, xmm4
por xmm0, xmm5
paddw xmm1, xmm1
pcmpgtw xmm3, xmm1
movdqa xmm1, xmm3
pandn xmm1, xmm0
psraw xmm0, 1
pand xmm0, xmm3
por xmm0, xmm1
psrlw xmm0, 8
packuswb xmm0, xmm2
ret
GCC outputs this:
f(char __vector(16), char __vector(16)):
push r15
movd edx, xmm0
movd ecx, xmm1
push r14
sar dl, cl
push r13
movzx edx, dl
push r12
push rbp
push rbx
sub rsp, 400
movaps XMMWORD PTR [rsp+376], xmm0
movzx ebx, BYTE PTR [rsp+377]
movaps XMMWORD PTR [rsp+360], xmm1
movzx ecx, BYTE PTR [rsp+361]
movaps XMMWORD PTR [rsp+344], xmm0
movzx ebp, BYTE PTR [rsp+346]
sar bl, cl
movaps XMMWORD PTR [rsp+328], xmm1
movzx ecx, BYTE PTR [rsp+330]
movaps XMMWORD PTR [rsp+312], xmm0
movzx ebx, bl
movzx r12d, BYTE PTR [rsp+315]
sar bpl, cl
movaps XMMWORD PTR [rsp+296], xmm1
movzx ecx, BYTE PTR [rsp+299]
movaps XMMWORD PTR [rsp+280], xmm0
movzx ebp, bpl
movzx r13d, BYTE PTR [rsp+284]
sar r12b, cl
movaps XMMWORD PTR [rsp+264], xmm1
movzx ecx, BYTE PTR [rsp+268]
movaps XMMWORD PTR [rsp+248], xmm0
movzx r12d, r12b
movzx r14d, BYTE PTR [rsp+253]
sar r13b, cl
movaps XMMWORD PTR [rsp+232], xmm1
movzx ecx, BYTE PTR [rsp+237]
movaps XMMWORD PTR [rsp+216], xmm0
movzx r13d, r13b
movzx r15d, BYTE PTR [rsp+222]
sar r14b, cl
movaps XMMWORD PTR [rsp+200], xmm1
movzx ecx, BYTE PTR [rsp+206]
movaps XMMWORD PTR [rsp+184], xmm0
movzx r14d, r14b
movaps XMMWORD PTR [rsp+168], xmm1
sar r15b, cl
movzx eax, BYTE PTR [rsp+191]
movzx ecx, BYTE PTR [rsp+175]
movaps XMMWORD PTR [rsp+152], xmm0
movzx esi, BYTE PTR [rsp+160]
movzx r15d, r15b
sar al, cl
movaps XMMWORD PTR [rsp+136], xmm1
movzx ecx, BYTE PTR [rsp+144]
movaps XMMWORD PTR [rsp+120], xmm0
movzx edi, BYTE PTR [rsp+129]
sar sil, cl
movaps XMMWORD PTR [rsp+104], xmm1
movzx ecx, BYTE PTR [rsp+113]
movaps XMMWORD PTR [rsp+88], xmm0
sar dil, cl
mov BYTE PTR [rsp-89], sil
movaps XMMWORD PTR [rsp+72], xmm1
movzx esi, dil
movzx ecx, BYTE PTR [rsp+82]
movzx edi, BYTE PTR [rsp+98]
movaps XMMWORD PTR [rsp+56], xmm0
movzx r8d, BYTE PTR [rsp+67]
sar dil, cl
movaps XMMWORD PTR [rsp+40], xmm1
movzx ecx, BYTE PTR [rsp+51]
movaps XMMWORD PTR [rsp+24], xmm0
movzx r9d, BYTE PTR [rsp+36]
movzx edi, dil
sar r8b, cl
movaps XMMWORD PTR [rsp+8], xmm1
movzx ecx, BYTE PTR [rsp+20]
movaps XMMWORD PTR [rsp-8], xmm0
movzx r10d, BYTE PTR [rsp+5]
movzx r8d, r8b
sar r9b, cl
movaps XMMWORD PTR [rsp-24], xmm1
movzx ecx, BYTE PTR [rsp-11]
movaps XMMWORD PTR [rsp-40], xmm0
movzx r11d, BYTE PTR [rsp-26]
movzx r9d, r9b
sar r10b, cl
movaps XMMWORD PTR [rsp-56], xmm1
movzx ecx, BYTE PTR [rsp-42]
mov BYTE PTR [rsp-120], al
movzx r10d, r10b
movaps XMMWORD PTR [rsp-72], xmm0
sar r11b, cl
movzx eax, BYTE PTR [rsp-57]
movaps XMMWORD PTR [rsp-88], xmm1
movzx ecx, BYTE PTR [rsp-73]
movzx r11d, r11b
sar al, cl
movzx ecx, al
movzx eax, BYTE PTR [rsp-120]
sal rcx, 8
sal rax, 8
or rcx, r11
or rax, r15
sal rax, 8
or rax, r14
sal rax, 8
or rax, r13
sal rax, 8
or rax, r12
sal rax, 8
or rax, rbp
sal r
[Bug c++/98929] [11 Regression] Internal compiler error on gcc trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98929
--- Comment #4 from Jakub Jelinek ---
Another testcase for -std=c++20, this one is accepted by GCC 10 and up to
r11-2747 and rejected with r11-2748 and later:
namespace a {
template constexpr bool d = __is_same_as(b, c);
namespace al {
template concept am = d;
}
template concept an = al::am;
}
namespace ap {
template struct e { using f = bf; };
template using bk = e::f;
}
namespace bd {
template concept cv = a::an, bf>;
template concept dg = requires { int(); };
}
namespace bd::ap {
template struct h {
static auto i() {}
using j = g;
using k = decltype(i);
h(k);
h(j, auto);
};
struct l {
using k = int;
l(k);
};
}
namespace bd {
struct C : ap::l {};
}
template void n(g bz, m ignore) { bd::ap::h(bz, ignore); }
void o() {
using bd::C;
C p{0};
int ignore;
n(p, ignore);
}
[Bug tree-optimization/98928] [11 regression] ICE when build 638.imagick_s since r11-5969-g3ed472af6bc9f83b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98928 Tamar Christina changed: What|Removed |Added Assignee|rguenth at gcc dot gnu.org |tnfchris at gcc dot gnu.org --- Comment #6 from Tamar Christina --- testing patch.
[Bug c++/98933] P0784R7 example support: constexpr new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98933
--- Comment #4 from Mark ---
So this is the only way?
```
#include
template struct S {
std::size_t sz;
T *ps;
template
constexpr S(T (&p)[N]) :
sz { N }, ps {p} {}
};
static constexpr char buf[] {"Hello"};
constexpr S str(buf);
// str ends up pointing to a static array
// containing the string "Hello!".
```
[Bug c++/98929] [11 Regression] Internal compiler error on gcc trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98929 --- Comment #3 from Jakub Jelinek --- It might actually be also ICE on valid, doing another reduction now...
[Bug analyzer/93355] Missing diagnostic for missing fclose in intl/localealias.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93355 --- Comment #7 from David Malcolm --- (In reply to CVS Commits from comment #6) > The master branch has been updated by David Malcolm : > > https://gcc.gnu.org/g:8a2750086d57d1a2251d9239fa4e6c2dc9ec3a86 > > commit r11-7029-g8a2750086d57d1a2251d9239fa4e6c2dc9ec3a86 This patch probably also fixes (c) within comment #4 above.
[Bug c++/98933] P0784R7 example support: constexpr new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98933
--- Comment #3 from Jakub Jelinek ---
You just need to allocate and deallocate during the same constexpr evaluation.
So doing
constexpr int
foo ()
{
... std::construct_at(...);
...
... std::destroy_at(...);
...
return ...;
}
is fine, but not what you were trying to do, which is turn the transient
allocations into something permanent.
[Bug c++/98929] [11 Regression] Internal compiler error on gcc trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98929 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/98933] P0784R7 example support: constexpr new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98933 --- Comment #2 from Mark --- (In reply to Jakub Jelinek from comment #1) > Have you noticed the > In Kona 2019, this approach was considered too brittle, and as a result > non-transient allocation was removed from the feature set. > line just below that example? > This is not valid C++20. So just to understand this right. It is ok as long as it does not survive compilation? But how are you going to implement constexpr std::vector and std::string then? (I'm actually somehow trying to bridge the time until that happens ;-)
[Bug c++/98933] P0784R7 example support: constexpr new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98933 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Have you noticed the In Kona 2019, this approach was considered too brittle, and as a result non-transient allocation was removed from the feature set. line just below that example? This is not valid C++20.
[Bug c++/98933] New: P0784R7 example support: constexpr new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98933
Bug ID: 98933
Summary: P0784R7 example support: constexpr new
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: markus.kuehni at triviso dot ch
Target Milestone: ---
Trying to recreate the
[P0784R7](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0784r7.html)
code example.
:13:10: error: 'mark_immutable_if_constexpr' is not a member of 'std'
13 | std::mark_immutable_if_constexpr(this->ps);
Removed std::mark_immutable_if_constexpr(this->ps);
:22:31: error: no matching function for call to 'S::S(const char
[7])'
22 | constexpr S str("Hello!");
| ^
Added std::add_const::type for constructor argument p.
:22:31: in 'constexpr' expansion of 'S("Hello!")'
:11:7: error: call to non-'constexpr' function 'void* operator
new(std::size_t, void*)'
11 | new(this->ps+k) T{p[k]};
Replaced with std::construct_at() and std::destroy_at() for symmetry, see
[91369](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91369).
In file included from
/opt/compiler-explorer/gcc-trunk-20210202/include/c++/11.0.0/memory:64,
from :1:
/opt/compiler-explorer/gcc-trunk-20210202/include/c++/11.0.0/bits/allocator.h:171:50:
error: 'S("Hello!")' is not a constant expression because it refers to a
result of 'operator new'
171 | return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp)));
Now I'm stuck.
A cleaned-up version is here:
https://godbolt.org/z/KWMqna
```
#include
#include
template struct S : std::allocator {
std::size_t sz;
T *ps;
template
constexpr S(typename std::add_const::type (&p)[N]) :
sz { N }, ps {this->allocate(N)} {
for (std::size_t k = 0; ksz; ++k) {
std::destroy_at(ps+k);
}
this->deallocate(this->ps, this->sz);
}
};
constexpr S str("Hello!");
// str ends up pointing to a static array
// containing the string "Hello!".
```
[Bug c++/98929] [11 Regression] Internal compiler error on gcc trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98929
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||jason at gcc dot gnu.org
Status|WAITING |NEW
--- Comment #2 from Jakub Jelinek ---
Reduced testcase for -std=c++20:
template
struct A {
void foo ();
using c = decltype (foo ());
A (c);
};
A d;
Started with r11-2748-gb871301f09be7061904dc87880919d30e6afef8f
[Bug fortran/91862] [9/10/11 Regression] ICE in fold_convert_loc, at fold-const.c:2394
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91862 Paul Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #9 from Paul Thomas --- Closed. Thanks for the report Gerhard! Paul
[Bug c++/98926] [11 regression] several ICEs after r11-7011
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98926 --- Comment #3 from seurer at gcc dot gnu.org --- This appears to be happening on powerpc64 BE. More ICEs and a traceback: g:6e0a231a4aa2407bb7167daf98a37795a67364d8, r11-7011 make -k check-gcc RUNTESTFLAGS="dg-torture.exp=g++.dg/torture/pr94582.C" FAIL: g++.dg/torture/pr94582.C -O0 (internal compiler error) FAIL: g++.dg/torture/pr94582.C -O0 (test for excess errors) FAIL: g++.dg/torture/pr94582.C -O1 (internal compiler error) FAIL: g++.dg/torture/pr94582.C -O1 (test for excess errors) FAIL: g++.dg/torture/pr94582.C -O2 (internal compiler error) FAIL: g++.dg/torture/pr94582.C -O2 (test for excess errors) FAIL: g++.dg/torture/pr94582.C -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler error) FAIL: g++.dg/torture/pr94582.C -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: g++.dg/torture/pr94582.C -O3 -g (internal compiler error) FAIL: g++.dg/torture/pr94582.C -O3 -g (test for excess errors) FAIL: g++.dg/torture/pr94582.C -Os (internal compiler error) FAIL: g++.dg/torture/pr94582.C -Os (test for excess errors) FAIL: g++.dg/torture/pr94582.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error) FAIL: g++.dg/torture/pr94582.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors) FAIL: g++.dg/torture/pr94582.C -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (internal compiler error) FAIL: g++.dg/torture/pr94582.C -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors) /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/torture/pr94582.C:12:9: internal compiler error: in hashtab_chk_error, at hash-table.c:137 0x102b63b3 hashtab_chk_error() /home/seurer/gcc/git/gcc-test/gcc/hash-table.c:137 0x10645307 hash_table::verify(spec_entry* const&, unsigned int) /home/seurer/gcc/git/gcc-test/gcc/hash-table.h:1033 0x10645503 hash_table::find_with_hash(spec_entry* const&, unsigned int) /home/seurer/gcc/git/gcc-test/gcc/hash-table.h:918 0x105f9433 lookup_template_class_1 /home/seurer/gcc/git/gcc-test/gcc/cp/pt.c:9869 0x105f9433 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*, int, int) /home/seurer/gcc/git/gcc-test/gcc/cp/pt.c:10231 0x105fcdf3 tsubst_aggr_type /home/seurer/gcc/git/gcc-test/gcc/cp/pt.c:13548 0x105e0a4b tsubst(tree_node*, tree_node*, int, tree_node*) /home/seurer/gcc/git/gcc-test/gcc/cp/pt.c:15988 0x105fee13 tsubst_decl /home/seurer/gcc/git/gcc-test/gcc/cp/pt.c:14768 0x105e099b tsubst(tree_node*, tree_node*, int, tree_node*) /home/seurer/gcc/git/gcc-test/gcc/cp/pt.c:15368 0x1062a3f7 instantiate_template_1 /home/seurer/gcc/git/gcc-test/gcc/cp/pt.c:21040 0x1062a3f7 instantiate_template(tree_node*, tree_node*, int) /home/seurer/gcc/git/gcc-test/gcc/cp/pt.c:21099 0x105e1073 instantiate_alias_template /home/seurer/gcc/git/gcc-test/gcc/cp/pt.c:21137 0x105e1073 tsubst(tree_node*, tree_node*, int, tree_node*) /home/seurer/gcc/git/gcc-test/gcc/cp/pt.c:15395 0x105fee13 tsubst_decl /home/seurer/gcc/git/gcc-test/gcc/cp/pt.c:14768 0x105e099b tsubst(tree_node*, tree_node*, int, tree_node*) /home/seurer/gcc/git/gcc-test/gcc/cp/pt.c:15368 0x1062a3f7 instantiate_template_1 /home/seurer/gcc/git/gcc-test/gcc/cp/pt.c:21040 0x1062a3f7 instantiate_template(tree_node*, tree_node*, int) /home/seurer/gcc/git/gcc-test/gcc/cp/pt.c:21099 0x105e1073 instantiate_alias_template /home/seurer/gcc/git/gcc-test/gcc/cp/pt.c:21137 0x105e1073 tsubst(tree_node*, tree_node*, int, tree_node*) /home/seurer/gcc/git/gcc-test/gcc/cp/pt.c:15395 0x105fee13 tsubst_decl /home/seurer/gcc/git/gcc-test/gcc/cp/pt.c:14768
[Bug fortran/91862] [9/10/11 Regression] ICE in fold_convert_loc, at fold-const.c:2394
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91862 --- Comment #8 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:831ff94a882149616b17132d23478c9d1fcbdcd6 commit r11-7041-g831ff94a882149616b17132d23478c9d1fcbdcd6 Author: Paul Thomas Date: Tue Feb 2 13:55:50 2021 + Fortran: Check remains fixed by patch for PRs 96100/101 [PR91862]. 2021-02-02 Paul Thomas gcc/testsuite PR fortran/91862 * gfortran.dg/pr91862.f90: New test.
[Bug c++/98932] Wrong output with -O3 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98932 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-02-02 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- I'm going to bisect that..
[Bug c++/98932] Wrong output with -O3 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98932 --- Comment #1 from Kristian --- Created attachment 50115 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50115&action=edit Test-case
[Bug c++/98932] New: Wrong output with -O3 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98932 Bug ID: 98932 Summary: Wrong output with -O3 on aarch64 Product: gcc Version: 8.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: kristian.klausen at scoutdi dot com Target Milestone: --- Hi, I have been struggling with a vectorization issue, and have managed to re-create to a minimal example as attached. When compiled with `-O2` the correct output is produced, however when compiled with `-O3` the output is bogus when compiled with gcc-8 and gcc-9. Gcc-7 gives the correct output. Tested with the following versions under qemu for aarch64: ``` g++-7 --version g++-7 (Ubuntu/Linaro 7.5.0-6ubuntu2) 7.5.0 g++-8 --version g++-8 (Ubuntu/Linaro 8.4.0-3ubuntu2) 8.4.0 g++-9 --version g++-9 (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0 ``` Output: ``` :~# g++-9 -O3 a.cpp && ./a.out Length is: 26348240 :~# g++-8 -O3 a.cpp && ./a.out Length is: 26348240 :~# g++-7 -O3 a.cpp && ./a.out Length is: 294 ``` Also gave it a go with the suggested flags before filing the report: ``` g++-8 -O3 -Wall -Wextra -fno-strict-aliasing -fwrapv a.cpp && ./a.out Length is: 26348240 ``` The code gives the correct output with gcc-10: ``` g++-10 -O3 a.cpp && ./a.out Length is: 294 g++-10 --version g++-10 (Ubuntu 10.2.0-5ubuntu1~20.04) 10.2.0 ``` Let me know if I can provide more information. Best, Kristian
[Bug lto/98922] -fstack-usage not working with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98922 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-02-02 Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Yes, the current master behaves well. I tend to close this as resolved, Richi?
[Bug target/98931] [11 Regression] arm: Assembly fails with "branch out of range or not a multiple of 2"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98931 ktkachov at gcc dot gnu.org changed: What|Removed |Added Summary|arm: Assembly fails with|[11 Regression] arm: |"branch out of range or not |Assembly fails with "branch |a multiple of 2"|out of range or not a ||multiple of 2" Target Milestone|--- |11.0 Known to work||10.2.1 Status|UNCONFIRMED |NEW CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 Priority|P3 |P1 Last reconfirmed||2021-02-02 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed. Assembles fine on GCC 10.
[Bug sanitizer/98920] [10/11 Regression] uses regexec without support for REG_STARTEND with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98920 Martin Liška changed: What|Removed |Added URL||https://reviews.llvm.org/D9 ||5864 --- Comment #2 from Martin Liška --- I've just made an upstream patch submission.
[Bug tree-optimization/98928] [11 regression] ICE when build 638.imagick_s since r11-5969-g3ed472af6bc9f83b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98928 --- Comment #5 from Tamar Christina --- Hmm looks like the SLP unwinding code is accidentally cancelling a pattern it shouldn't have. Checking why...
[Bug target/98931] New: arm: Assembly fails with "branch out of range or not a multiple of 2"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98931
Bug ID: 98931
Summary: arm: Assembly fails with "branch out of range or not a
multiple of 2"
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
GCC's output fails to assemble for the following:
$ cat test.c
extern long long a[][20][26][26][22];
void foo()
{
for (short d = 0; d+1; d++)
for (unsigned e = 0; e < 25; e += 4)
for (unsigned f = 0; f < 25; f += 4)
for (int g = 0; g < 21; g += 4)
a[4][d][e][f][g] = 0;
}
$ arm-eabi-gcc -c test.c -march=armv8.1-m.main -O3
--param=max-completely-peeled-insns=1300
/tmp/ccDd7AwT.s: Assembler messages:
/tmp/ccDd7AwT.s:1642: Error: branch out of range or not a multiple of 2
