[Bug preprocessor/89808] An option to disable warning "#pragma once in main file"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89808 Justin Bassett changed: What|Removed |Added CC||jbassett271 at gmail dot com --- Comment #11 from Justin Bassett --- An additional use case: to test that header files can compile in isolation, one could compile the header file with -fsyntax-only ( g++ -xc++ -fsyntax-only myheader.hpp ). However, this emits the "#pragma once in main file" warning, which is undesirable, especially because it makes -Werror impossible. This means that a tool for checking header file isolation would have to emit a new file to check header isolation.
[Bug c++/99223] [modules] stdl header-unit ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99223 --- Comment #4 from Alexander Lelyakin --- Currently these two sequences produce same error: internal compiler error: in install_entity, at cp/module.cc:7464 Which is duplicate of 99241. Should be closed.
[Bug c++/99222] [modules] system header-unit ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99222 Alexander Lelyakin changed: What|Removed |Added CC||alexander.lelyakin@googlema ||il.com --- Comment #1 from Alexander Lelyakin --- This is not more reproducible for more than month. Should be closed.
[Bug c++/99246] [modules] ICE in write_location, at cp/module.cc:15687
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99246 --- Comment #4 from Alexander Lelyakin --- This report is marked as resolved, but it is stable reproducible all the time. /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header bit /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header istream /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header cmath /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header locale /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header bitset /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header shared_mutex /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header new /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header ciso646 /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header memory /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header fstream /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header thread /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header regex In module imported at /usr/local/include/c++/11.0.1/sstream:38:1, included from /usr/local/include/c++/11.0.1/regex:46: /usr/local/include/c++/11.0.1/istream: note: unable to represent further imported source locations /usr/local/include/c++/11.0.1/regex: internal compiler error: in write_location, at cp/module.cc:15593 0x6e02cf module_state::write_location(bytes_out&, unsigned int) ../../gcc/gcc/cp/module.cc:15593 0xa60ff3 trees_out::core_vals(tree_node*) ../../gcc/gcc/cp/module.cc:5900 0xa64464 trees_out::tree_node_vals(tree_node*) ../../gcc/gcc/cp/module.cc:7050 0xa64464 trees_out::tree_value(tree_node*) ../../gcc/gcc/cp/module.cc:8887 0xa604f4 trees_out::tree_node(tree_node*) ../../gcc/gcc/cp/module.cc:9085 0xa6484a trees_out::write_var_def(tree_node*) ../../gcc/gcc/cp/module.cc:11472 0xa65ae5 module_state::write_cluster(elf_out*, depset**, unsigned int, depset::hash&, unsigned int*, unsigned int*) ../../gcc/gcc/cp/module.cc:14648 0xa6743e module_state::write(elf_out*, cpp_reader*) ../../gcc/gcc/cp/module.cc:17720 0xa6801f finish_module_processing(cpp_reader*) ../../gcc/gcc/cp/module.cc:19831 0x9fb4cb c_parse_final_cleanups() ../../gcc/gcc/cp/decl2.c:5175 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. g++ (GCC) 11.0.1 20210330 (experimental) Copyright (C) 2021 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.
[Bug c++/99284] [modules] ICE in key_mergeable, at cp/module.cc:10441
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99284 --- Comment #2 from Alexander Lelyakin --- Not reproduced anymore.
[Bug c++/99815] [11 Regression] ICE: in placeholder_type_constraint_dependent_p, at cp/pt.c:28193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99815 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Patrick Palka --- Fixed.
[Bug c++/88115] Incorrect result from alignof in templates, if also using __alignof__.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88115 --- Comment #12 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:a3bf6ce7f2e17f2c977c13df23eb718e7b433dcd commit r11-7921-ga3bf6ce7f2e17f2c977c13df23eb718e7b433dcd Author: Patrick Palka Date: Tue Mar 30 22:57:11 2021 -0400 c++: Adjust mangling of __alignof__ [PR88115] r11-4926 made __alignof__ get mangled differently from alignof, encoding __alignof__ as a vendor extended operator. But this mangling is problematic for the reasons mentioned in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88115#c6. This patch changes our mangling of __alignof__ to instead use the new "vendor extended expression" syntax that's proposed in https://github.com/itanium-cxx-abi/cxx-abi/issues/112. Clang does the same thing already, so after this patch Clang and GCC agree about the mangling of __alignof__(type) and __alignof__(expr). gcc/cp/ChangeLog: PR c++/88115 * mangle.c (write_expression): Adjust the mangling of __alignof__. include/ChangeLog: PR c++/88115 * demangle.h (enum demangle_component_type): Add DEMANGLE_COMPONENT_VENDOR_EXPR. libiberty/ChangeLog: PR c++/88115 * cp-demangle.c (d_dump, d_make_comp, d_expression_1) (d_count_templates_scopes): Handle DEMANGLE_COMPONENT_VENDOR_EXPR. (d_print_comp_inner): Likewise. : Revert r11-4926 change. : Likewise. * testsuite/demangle-expected: Adjust __alignof__ tests. gcc/testsuite/ChangeLog: PR c++/88115 * g++.dg/cpp0x/alignof7.C: Adjust expected mangling.
[Bug c++/99844] New: ICE: unexpected expression 'B' of kind template_parm_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99844
Bug ID: 99844
Summary: ICE: unexpected expression 'B' of kind
template_parm_index
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
Related to fixed PR 99745 and PR 99757.
https://godbolt.org/z/5qW5a1Mnq
template
struct S {
constexpr explicit(B) S() {}
};
constexpr S s;
:3:25: internal compiler error: unexpected expression 'B' of kind
template_parm_index
3 | constexpr explicit(B) S() {}
| ^
0x1cfb6a9 internal_error(char const*, ...)
???:0
0x9164c7 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x959fc9 instantiate_class_template(tree_node*)
???:0
0x77fbc7 start_decl_1(tree_node*, bool)
???:0
0x7a728f start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
???:0
0x8e12ad c_parse_file()
???:0
0xa600a2 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug c++/99815] [11 Regression] ICE: in placeholder_type_constraint_dependent_p, at cp/pt.c:28193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99815 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:0bbf0edbfc782f8e4e416d5fbd1b52a515adb585 commit r11-7920-g0bbf0edbfc782f8e4e416d5fbd1b52a515adb585 Author: Patrick Palka Date: Tue Mar 30 22:54:37 2021 -0400 c++: placeholder type constraint and argument pack [PR99815] When checking dependence of a placeholder type constraint, if the first template argument of the constraint is an argument pack, we need to expand it in order to properly separate the implicit 'auto' argument from the rest. gcc/cp/ChangeLog: PR c++/99815 * pt.c (placeholder_type_constraint_dependent_p): Expand argument packs to separate the first non-pack argument from the rest. gcc/testsuite/ChangeLog: PR c++/99815 * g++.dg/cpp2a/concepts-placeholder5.C: New test.
[Bug tree-optimization/99823] -funroll-all-loops bugs when using contexpr variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99823 --- Comment #2 from apple --- (In reply to Richard Biener from comment #1) > -funroll-all-loops applies to the RTL loop unroller, the GIMPLE level > concludes: > > Estimating sizes for loop 1 > BB: 3, after_exit: 0 > size: 1 _1 = MEM[(int (*) (int) &)__for_begin_21]; > size: 5 _13 = _1 (s_20); > size: 1 __for_begin_14 = __for_begin_21 + 8; > size: 1 ivtmp_4 = ivtmp_11 - 1; >Induction variable computation will be folded away. > size: 2 if (ivtmp_4 != 0) >Exit condition will be eliminated in peeled copies. >Exit condition will be eliminated in last copy. >Constant conditional. > BB: 5, after_exit: 1 > size: 10-3, last_iteration: 10-3 > Loop size: 10 > Estimated size after unrolling: 14 > Not unrolling loop 1: contains call and code would grow. > > so it concludes unrolling isn't profitable (but it would turn indirect into > direct calls). Anyway, I should mention here that clang can unroll it without this flag and turn out constexpr.cpp equal to unroll.cpp. And you can try to insert "#pragma GCC unroll 2“ the loop finally unrolled, even in this pragma, constexpr.cpp is not equal to unroll.cpp. But this is technically another issue
[Bug c++/99843] New: Making a function a friend of a class will hide function constructor priority if has constructor(n) attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99843
Bug ID: 99843
Summary: Making a function a friend of a class will hide
function constructor priority if has constructor(n)
attribute
Product: gcc
Version: 9.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: itirg1 at optusnet dot com.au
Target Milestone: ---
When declaring a function a friend of a class and that function uses the
__attribute__((constructor(priority))) attribute, the priority is lost. I have
only tested this on the arm-none-eabi-g++ on windows.
In the code below I made a quick demo of the problem, all of the initialisation
functions correctly have a section called .init_array.(5 digit priority number)
containing a pointer to the function except for the function that was made a
friend which is placed in .init_array which as a result the linker script will
place after the numbered ones.
F:\Test>arm-none-eabi-g++ --version
arm-none-eabi-g++ (GNU Arm Embedded Toolchain 9-2020-q3-update) 9.3.1 20200408
(release)
Copyright (C) 2019 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.
F:\Test>cat testinit.cpp
// Initialization order test
void Init101(void) __attribute__((constructor(101)));
void Init101(void)
{
while(1);
}
static void Init102(void) __attribute__((constructor(102)));
static void Init102(void)
{
while(1);
}
namespace Something
{
void Init103(void) __attribute__((constructor(103)));
void Init103(void)
{
while(1);
}
static void Init104(void) __attribute__((constructor(104)));
static void Init104(void)
{
while(1);
}
class SomeClass
{
friend void Init105(void);
private:
int foo;
public:
int bar;
};
SomeClass * AClassPtr = nullptr;
void Init105(void) __attribute__((constructor(105)));
void Init105(void)
{
if (AClassPtr == nullptr)
{
AClassPtr = new SomeClass;
}
AClassPtr->foo = 219;
}
void Init106(void) __attribute__((constructor(106)));
void Init106(void)
{
while(1);
}
}
F:\Test>arm-none-eabi-g++ -mcpu=cortex-m0 -c -fno-exceptions testinit.cpp
F:\Test>arm-none-eabi-objdump -h -r -t testinit.o
testinit.o: file format elf32-littlearm
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 004c 0034 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
1 .data 0080 2**0
CONTENTS, ALLOC, LOAD, DATA
2 .bss 0004 0080 2**2
ALLOC
3 .init_array.00101 0004 0080 2**2
CONTENTS, ALLOC, LOAD, RELOC, DATA
4 .init_array.00102 0004 0084 2**2
CONTENTS, ALLOC, LOAD, RELOC, DATA
5 .init_array.00103 0004 0088 2**2
CONTENTS, ALLOC, LOAD, RELOC, DATA
6 .init_array.00104 0004 008c 2**2
CONTENTS, ALLOC, LOAD, RELOC, DATA
7 .init_array 0004 0090 2**2
CONTENTS, ALLOC, LOAD, RELOC, DATA
8 .init_array.00106 0004 0094 2**2
CONTENTS, ALLOC, LOAD, RELOC, DATA
9 .comment 004d 0098 2**0
CONTENTS, READONLY
10 .ARM.attributes 002c 00e5 2**0
CONTENTS, READONLY
SYMBOL TABLE:
ldf *ABS* testinit.cpp
ld .text .text
ld .data .data
ld .bss .bss
ld .init_array.00101 .init_array.00101
0006 l F .text 0006 _ZL7Init102v
ld .init_array.00102 .init_array.00102
ld .init_array.00103 .init_array.00103
0012 l F .text 0006 _ZN9SomethingL7Init104Ev
ld .init_array.00104 .init_array.00104
ld .init_array .init_array
ld .init_array.00106 .init_array.00106
ld .comment .comment
ld .ARM.attributes .ARM.attributes
g F .text 0006 _Z7Init101v
000c g F .text 0006 _ZN9Something7Init103Ev
g O .bss 0004 _ZN9Something9AClassPtrE
0018 g F .text
[Bug tree-optimization/63660] -Wmaybe-uninitialized false positive (uninit pass limits)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63660 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org Known to fail|4.8.3, 4.9.2, 5.0 |10.2.0, 11.0, 4.8.4, 4.9.4, ||5.5.0, 6.4.0, 7.2.0, 8.3.0, ||9.1.0 Last reconfirmed|2014-10-28 00:00:00 |2021-3-30 --- Comment #4 from Martin Sebor --- Reconfirmed with GCC 11. The limits don't come into play here. There is an uninitialized use in a PHI in the IL: [local count: 1073741824]: # xj_35 = PHI # .MEM_55 = PHI <.MEM_54(53), .MEM_77(21)> if (m_3 > 63) goto ; [51.12%] else goto ; [48.88%] ... [local count: 262422500]: # .MEM_88 = VDEF <.MEM_64> x_25->j = xj_35;
[Bug c++/99831] ICE: in reshape_init, at cp/decl.c:6720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99831
--- Comment #8 from Marek Polacek ---
The problem is that post-r277865 in defaulted_late_check we call
synthesize_method here:
if (kind == sfk_comparison)
{
/* If the function was declared constexpr, check that the definition
qualifies. Otherwise we can define the function lazily. */
if (DECL_DECLARED_CONSTEXPR_P (fn) && !DECL_INITIAL (fn))
synthesize_method (fn);
return;
}
and that results in garbage collection, which then frees {} that we created
when parsing the braced-list in string<"a">{}. Then of course accessing the
freed data fails.
[Bug target/99718] [11 regression] ICE in new test case gcc.target/powerpc/pr98914.c for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718 luoxhu at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #21 from luoxhu at gcc dot gnu.org --- Fixed on mater.
[Bug c++/99445] [11 Regression] ICE in hashtab_chk_error, at hash-table.c:137 since r11-7011-g6e0a231a4aa2407b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99445 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug target/99842] MMA test case ICEs using -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99842 Peter Bergner changed: What|Removed |Added Target||powerpc64le-linux Ever confirmed|0 |1 Known to fail||11.0 Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot gnu.org Last reconfirmed||2021-03-30 Status|UNCONFIRMED |ASSIGNED Target Milestone|--- |11.0 --- Comment #1 from Peter Bergner --- Mine. The problem is that the mma_assemble_input_operand predicate is rejecting valid reg+reg indexed addresses in the MEMs in the above rtl. The predicate is calling quad_address_p() which accepts reg+offset addresses (with constrained offset values), but doesn't allow reg+reg addresses, which are valid. Replacing the MEM_P() && quad_address_p() test with a call to memory_operand() fixes the ICE, since it calls down to rs6000_legitimate_address_p(), which calls quad_address_p() to validate reg+offset addresses, but also allows reg+reg addresses. I'll submit a patch with that fix.
[Bug target/99842] New: MMA test case ICEs using -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99842
Bug ID: 99842
Summary: MMA test case ICEs using -O3
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
A reduced test case from Eigen using MMA builtins ICEs using -O3:
bergner@pike:~/gcc/BUGS/$ g++ -w -S -O3 -mcpu=power10 bug.ii
bug.ii: In function ‘n< , , m, ,
, >::n(ab) [with ab = af, const n >, n >; cg = double; int
= -1; int m = 1; int = 3; int = 0; int
= 1]’:
bug.ii:90:59: error: could not split insn
90 | template n(ab p) { n::template ch(p); }
| ^
(insn:TI 28 335 29 (set (reg:OO 32 0 [orig:125 _28 ] [125])
(unspec:OO [
(mem:V16QI (plus:DI (reg/f:DI 26 26 [orig:223 MEM
[(struct ca *)_253] ] [223])
(reg:DI 27 27 [222])) [0 MEM [(void *)_25]+0 S16
A8])
(mem:V16QI (plus:DI (reg/f:DI 26 26 [orig:223 MEM
[(struct ca *)_253] ] [223])
(reg:DI 27 27 [222])) [0 MEM [(void *)_25]+0 S16
A8])
] UNSPEC_MMA_ASSEMBLE)) 2080 {*vsx_assemble_pair}
(expr_list:REG_EQUIV (mem/c:OO (plus:DI (reg/f:DI 31 31 [217])
(const_int 160 [0xa0])) [6 MEM[(__vector_pair *)_173]+0 S32
A256])
(nil)))
during RTL pass: final
bug.ii:90:59: internal compiler error: in final_scan_insn_1, at final.c:3092
0x101fa5fb _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/rtl-error.c:108
0x10a2b5cb final_scan_insn_1
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/final.c:3092
0x10a2c613 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/final.c:3171
0x10a2c9b3 final_1
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/final.c:2022
0x10a2dc57 rest_of_handle_final
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/final.c:4676
0x10a2dc57 execute
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/final.c:4754
[Bug c++/99790] [8/9/10 Regression] internal compiler error: in expand_expr_real_2 since r7-3811
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99790 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7cdd30b43a63832d6f908b2dd64bd19a0817cd7b commit r10-9626-g7cdd30b43a63832d6f908b2dd64bd19a0817cd7b Author: Jakub Jelinek Date: Tue Mar 30 18:15:32 2021 +0200 c++: Fix ICE on PTRMEM_CST in lambda in inline var initializer [PR99790] The following testcase ICEs (since the addition of inline var support), because the lambda contains PTRMEM_CST but finish_function is called for the lambda quite early during parsing it (from finish_lambda_function) when the containing class is still incomplete. That means that during genericization cplus_expand_constant keeps the PTRMEM_CST unmodified, but later nothing lowers it when the class is finalized. Using sizeof etc. on the class in such contexts is rejected by both g++ and clang++, and when the PTRMEM_CST appears e.g. in static var initializers rather than in functions, we handle it correctly because c_parse_final_cleanups -> lower_var_init will handle those cplus_expand_constant when all classes are already finalized. The following patch fixes it by calling cplus_expand_constant again during gimplification, as we are now unconditionally unit at a time, I'd think everything that could be completed will be before we start gimplification. 2021-03-30 Jakub Jelinek PR c++/99790 * cp-gimplify.c (cp_gimplify_expr): Handle PTRMEM_CST. * g++.dg/cpp1z/pr99790.C: New test.
[Bug tree-optimization/99777] [11 Regression] ICE in build2, at tree.c:4869 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99777
--- Comment #6 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:afe9a630eae114665e77402ea083201c9d406e99
commit r10-9625-gafe9a630eae114665e77402ea083201c9d406e99
Author: Jakub Jelinek
Date: Mon Mar 29 12:35:32 2021 +0200
fold-const: Fix ICE in extract_muldiv_1 [PR99777]
extract_muldiv{,_1} is apparently only prepared to handle scalar integer
operations, the callers ensure it by only calling it if the divisor or
one of the multiplicands is INTEGER_CST and because neither multiplication
nor division nor modulo are really supported e.g. for pointer types,
nullptr
type etc. But the CASE_CONVERT handling doesn't really check if it isn't
a cast from some other type kind, so on the testcase we end up trying to
build MULT_EXPR in POINTER_TYPE which ICEs. A few years ago Marek has
added ANY_INTEGRAL_TYPE_P checks to two spots, but the code uses
TYPE_PRECISION which means something completely different for vector types,
etc.
So IMNSHO we should just punt on conversions from non-integrals or
non-scalar integrals.
2021-03-29 Jakub Jelinek
PR tree-optimization/99777
* fold-const.c (extract_muldiv_1): For conversions, punt on casts
from
types other than scalar integral types.
* g++.dg/torture/pr99777.C: New test.
[Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99334 --- Comment #11 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f5df18504c1790413f293bfb50d40faa7f1ea860 commit r10-9624-gf5df18504c1790413f293bfb50d40faa7f1ea860 Author: Jakub Jelinek Date: Sat Mar 27 00:20:42 2021 +0100 dwarf2cfi: Defer queued register saves some more [PR99334] On the testcase in the PR with -fno-tree-sink -O3 -fPIC -fomit-frame-pointer -fno-strict-aliasing -mstackrealign we have prologue: <_func_with_dwarf_issue_>: 0: 4c 8d 54 24 08 lea0x8(%rsp),%r10 5: 48 83 e4 f0 and$0xfff0,%rsp 9: 41 ff 72 f8 pushq -0x8(%r10) d: 55 push %rbp e: 48 89 e5mov%rsp,%rbp 11: 41 57 push %r15 13: 41 56 push %r14 15: 41 55 push %r13 17: 41 54 push %r12 19: 41 52 push %r10 1b: 53 push %rbx 1c: 48 83 ec 20 sub$0x20,%rsp and emit 0014 CIE Version: 1 Augmentation: "zR" Code alignment factor: 1 Data alignment factor: -8 Return address column: 16 Augmentation data: 1b DW_CFA_def_cfa: r7 (rsp) ofs 8 DW_CFA_offset: r16 (rip) at cfa-8 DW_CFA_nop DW_CFA_nop 0018 0044 001c FDE cie= pc=..01d5 DW_CFA_advance_loc: 5 to 0005 DW_CFA_def_cfa: r10 (r10) ofs 0 DW_CFA_advance_loc: 9 to 000e DW_CFA_expression: r6 (rbp) (DW_OP_breg6 (rbp): 0) DW_CFA_advance_loc: 13 to 001b DW_CFA_def_cfa_expression (DW_OP_breg6 (rbp): -40; DW_OP_deref) DW_CFA_expression: r15 (r15) (DW_OP_breg6 (rbp): -8) DW_CFA_expression: r14 (r14) (DW_OP_breg6 (rbp): -16) DW_CFA_expression: r13 (r13) (DW_OP_breg6 (rbp): -24) DW_CFA_expression: r12 (r12) (DW_OP_breg6 (rbp): -32) ... unwind info for that. The problem is when async signal (or stepping through in the debugger) stops after the pushq %rbp instruction and before movq %rsp, %rbp, the unwind info says that caller's %rbp is saved there at *%rbp, but that is not true, caller's %rbp is either still available in the %rbp register, or in *%rsp, only after executing the next instruction - movq %rsp, %rbp - the location for %rbp is correct. So, either we'd need to temporarily say: DW_CFA_advance_loc: 9 to 000e DW_CFA_expression: r6 (rbp) (DW_OP_breg7 (rsp): 0) DW_CFA_advance_loc: 3 to 0011 DW_CFA_expression: r6 (rbp) (DW_OP_breg6 (rbp): 0) DW_CFA_advance_loc: 10 to 001b or to me it seems more compact to just say: DW_CFA_advance_loc: 12 to 0011 DW_CFA_expression: r6 (rbp) (DW_OP_breg6 (rbp): 0) DW_CFA_advance_loc: 10 to 001b I've tried instead to deal with it through REG_FRAME_RELATED_EXPR from the backend, but that failed miserably as explained in the PR, dwarf2cfi.c has some rules (Rule 16 to Rule 19) that are specific to the dynamic stack realignment using drap register that only the i386 backend does right now, and by using REG_FRAME_RELATED_EXPR or REG_CFA* notes we can't emulate those rules. The following patch instead does the deferring of the hard frame pointer save rule in dwarf2cfi.c Rule 18 handling and emits it on the (set hfp sp) assignment that must appear shortly after it and adds assertion that it is the case. The difference before/after the patch on the assembly is: --- pr99334.s~ 2021-03-26 15:42:40.881749380 +0100 +++ pr99334.s 2021-03-26 17:38:05.729161910 +0100 @@ -11,8 +11,8 @@ _func_with_dwarf_issue_: andq$-16, %rsp pushq -8(%r10) pushq %rbp - .cfi_escape 0x10,0x6,0x2,0x76,0 movq%rsp, %rbp + .cfi_escape 0x10,0x6,0x2,0x76,0 pushq %r15 pushq %r14 pushq %r13 i.e. does just what we IMHO need, after pushq %rbp %rbp still contains parent's frame value and so the save rule doesn't need to be overridden there, ditto at the start of the next insn before the side-effect took effect, and we override it only after it when %rbp already has the right value. If some other target adds dynamic stack realignment in the future and the offset 0 case wouldn't be true there, the code can be adjusted so that it works on all the drap architectures, I'm pretty sure the code would need other adjustments too. For the rule 18 and for the (set hfp sp) after it we already have asserts for
[Bug c++/99705] [10 Regression] ICE in expand_expr_real_1 since r10-3661
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99705
--- Comment #6 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:1c82b47137ab4212b7618da3458d2949b2dff1a3
commit r10-9623-g1c82b47137ab4212b7618da3458d2949b2dff1a3
Author: Jakub Jelinek
Date: Fri Mar 26 09:35:26 2021 +0100
c++: Fix ICE with nsdmi [PR99705]
When adding P0784R7 constexpr new support, we still didn't have
P1331R2 implemented and so I had to change also build_vec_delete_1
- instead of having uninitialized tbase temporary later initialized
by MODIFY_EXPR I've set the DECL_INITIAL for it - because otherwise
it would be rejected during constexpr evaluation which didn't like
uninitialized vars. Unfortunately, that change broke the following
testcase.
The problem is that these temporaries (not just tbase but tbase was
the only one with an initializer) are created during NSDMI parsing
and current_function_decl is NULL at that point. Later when we
clone body of constructors, auto_var_in_fn_p is false for those
(as they have NULL DECL_CONTEXT) and so they aren't duplicated,
and what is worse, the DECL_INITIAL isn't duplicated either nor processed,
and during expansion we ICE because the code from DECL_INITIAL of that
var refers to the abstract constructor's PARM_DECL (this) rather than
the actual constructor's one.
So, either we can just revert those build_vec_delete_1 changes (as done
in the second patch - in attachment), or, as the first patch does, we can
copy the temporaries during bot_manip like we copy the temporaries of
TARGET_EXPRs. To me that looks like a better fix because e.g. if
break_out_of_target_exprs is called for the same NSDMI multiple times,
sharing the temporaries looks just wrong to me. If the temporaries
are declared as BIND_EXPR_VARS of some BIND_EXPR (which is the case
of the tbase variable built by build_vec_delete_1 and is the only way
how the DECL_INITIAL can be walked by *walk_tree*), then we need to
copy it also in the BIND_EXPR BIND_EXPR_VARS chain, other temporaries
(those that don't need DECL_INITIAL) often have just DECL_EXPR and no
corresponding BIND_EXPR.
Note, ({ }) are rejected in nsdmis, so all we run into are temporaries
the FE creates artificially.
2021-03-26 Jakub Jelinek
PR c++/99705
* tree.c (bot_manip): Remap artificial automatic temporaries
mentioned
in DECL_EXPR or in BIND_EXPR_VARS.
* g++.dg/cpp0x/new5.C: New test.
[Bug c++/99745] ICE when parameter pack not expanded in bit field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99745 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f8780caf07340f5d5e55cf5fb1b2be07cabab1ea commit r10-9622-gf8780caf07340f5d5e55cf5fb1b2be07cabab1ea Author: Jakub Jelinek Date: Thu Mar 25 21:06:09 2021 +0100 c++: Diagnose bare parameter packs in bitfield widths [PR99745] The following invalid tests ICE because we don't diagnose (and drop) bare parameter packs in bitfield widths. 2021-03-25 Jakub Jelinek PR c++/99745 * decl2.c (grokbitfield): Diagnose bitfields containing bare parameter packs and don't set DECL_BIT_FIELD_REPRESENTATIVE in that case. * g++.dg/cpp0x/variadic181.C: New test.
[Bug c++/99650] ICE when trying to form reference to void in structured binding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99650 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d5e379e3fe19362442b5d0ac608fb8ddf67fecd3 commit r10-9621-gd5e379e3fe19362442b5d0ac608fb8ddf67fecd3 Author: Jakub Jelinek Date: Tue Mar 23 10:23:42 2021 +0100 c++: Diagnose references to void in structured bindings [PR99650] We ICE on the following testcase, because std::tuple_element<...,...>::type is void and for structured bindings we therefore need to create void & or void && which is invalid. We created such REFERENCE_TYPE and later ICEd in the middle-end. The following patch fixes it by diagnosing that. 2021-03-23 Jakub Jelinek PR c++/99650 * decl.c (cp_finish_decomp): Diagnose void initializers when using tuple_element and get. * g++.dg/cpp1z/decomp55.C: New test.
[Bug debug/99388] Invalid debug info for __fp16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99388
--- Comment #4 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:d3dd3703f1d42b14c88b91e51a2a775fe00a2974
commit r10-9620-gd3dd3703f1d42b14c88b91e51a2a775fe00a2974
Author: Jakub Jelinek
Date: Sun Mar 21 17:27:39 2021 +0100
dwarf2out: Fix debug info for 2 byte floats [PR99388]
Aarch64, ARM and a couple of other architectures have 16-bit floats,
HFmode.
As can be seen e.g. on
void
foo (void)
{
__fp16 a = 1.0;
asm ("nop");
a = 2.0;
asm ("nop");
a = 3.0;
asm ("nop");
}
testcase, GCC mishandles this on the dwarf2out.c side by assuming all
floating point types have sizes in multiples of 4 bytes, so what GCC emits
is it says that e.g. the DW_OP_implicit_value will be 2 bytes but then
doesn't emit anything and so anything emitted after it is treated by
consumers as the value and then they get out of sync.
real_to_target which insert_float uses indeed fills it that way, but
putting
into an array of long 32 bits each time, but for the half floats it puts
everything into the least significant 16 bits of the first long no matter
what endianity host or target has.
The following patch fixes it. With the patch the -g -O2 -dA output changes
(in a cross without .uleb128 support):
.byte 0x9e// DW_OP_implicit_value
.byte 0x2 // uleb128 0x2
+ .2byte 0x3c00 // fp or vector constant word 0
.byte 0x7 // DW_LLE_start_end (*.LLST0)
.8byte .LVL1 // Location list begin address (*.LLST0)
.8byte .LVL2 // Location list end address (*.LLST0)
.byte 0x4 // uleb128 0x4; Location expression size
.byte 0x9e// DW_OP_implicit_value
.byte 0x2 // uleb128 0x2
+ .2byte 0x4000 // fp or vector constant word 0
.byte 0x7 // DW_LLE_start_end (*.LLST0)
.8byte .LVL2 // Location list begin address (*.LLST0)
.8byte .LFE0 // Location list end address (*.LLST0)
.byte 0x4 // uleb128 0x4; Location expression size
.byte 0x9e// DW_OP_implicit_value
.byte 0x2 // uleb128 0x2
+ .2byte 0x4200 // fp or vector constant word 0
.byte 0 // DW_LLE_end_of_list (*.LLST0)
Bootstrapped/regtested on x86_64-linux, aarch64-linux and
armv7hl-linux-gnueabi, ok for trunk?
I fear the CONST_VECTOR case is still broken, while HFmode elements of
vectors
should be fine (it uses eltsize of the element sizes) and likewise SFmode
could
be fine, DFmode vectors are emitted as two 32-bit ints regardless of
endianity
and I'm afraid it can't be right on big-endian. But I haven't been able to
create a testcase that emits a CONST_VECTOR, for e.g. unused vector vars
with constant operands we emit CONCATN during expansion and thus ...
DW_OP_*piece for each element of the vector and for
DW_TAG_call_site_parameter we give up (because we handle CONST_VECTOR only
in loc_descriptor, not mem_loc_descriptor).
2021-03-21 Jakub Jelinek
PR debug/99388
* dwarf2out.c (insert_float): Change return type from void to
unsigned, handle GET_MODE_SIZE (mode) == 2 and return element size.
(mem_loc_descriptor, loc_descriptor, add_const_value_attribute):
Adjust callers.
[Bug c/99588] variable set but not used warning on static _Atomic assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99588 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:b1fc1f1c4b2e9005c40ed476b067577da2d2ce84 commit r10-9619-gb1fc1f1c4b2e9005c40ed476b067577da2d2ce84 Author: Jakub Jelinek Date: Fri Mar 19 22:54:31 2021 +0100 c: Fix up -Wunused-but-set-* warnings for _Atomics [PR99588] As the following testcases show, compared to -D_Atomic= case we have many -Wunused-but-set-* warning false positives. When an _Atomic variable/parameter is read, we call mark_exp_read on it in convert_lvalue_to_rvalue, but build_atomic_assign does not. For consistency with the non-_Atomic case where we mark_exp_read the lhs for lhs op= ... but not for lhs = ..., this patch does that too. But furthermore we need to pattern match the trees emitted by _Atomic store, so that _Atomic store itself is not marked as being a variable read, but when the result of the store is used, we mark it. 2021-03-19 Jakub Jelinek PR c/99588 * c-typeck.c (mark_exp_read): Recognize what build_atomic_assign with modifycode NOP_EXPR produces and mark the _Atomic var as read if found. (build_atomic_assign): For modifycode of NOP_EXPR, use COMPOUND_EXPRs rather than STATEMENT_LIST. Otherwise call mark_exp_read on lhs. Set TREE_SIDE_EFFECTS on the TARGET_EXPR. * gcc.dg/Wunused-var-5.c: New test. * gcc.dg/Wunused-var-6.c: New test.
[Bug analyzer/99771] Analyzer diagnostics should not say ""
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99771 --- Comment #1 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:0f9aa35c79a0fe195d5076375b5794246cf44819 commit r11-7917-g0f9aa35c79a0fe195d5076375b5794246cf44819 Author: David Malcolm Date: Fri Mar 26 13:26:15 2021 -0400 analyzer: only call get_diagnostic_tree when it's needed impl_sm_context::get_diagnostic_tree could be expensive, and I find myself needing to put a breakpoint on it to debug PR analyzer/99771, so only call it if we're about to use the result. gcc/analyzer/ChangeLog: * sm-file.cc (fileptr_state_machine::on_stmt): Only call get_diagnostic_tree if the result will be used. * sm-malloc.cc (malloc_state_machine::on_stmt): Likewise. (malloc_state_machine::on_deallocator_call): Likewise. (malloc_state_machine::on_realloc_call): Likewise. (malloc_state_machine::on_realloc_call): Likewise. * sm-sensitive.cc (sensitive_state_machine::warn_for_any_exposure): Likewise. * sm-taint.cc (taint_state_machine::on_stmt): Likewise.
[Bug rtl-optimization/96264] [10 Regression] wrong code with -Os -fno-forward-propagate -fschedule-insns -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96264 --- Comment #17 from Vladimir Makarov --- (In reply to Peter Bergner from comment #16) > (In reply to seurer from comment #15) > > It still fails on gcc 10, though > > Vlad, can we get this backported to GCC 10? Maybe in time for GCC 10.3? Nobody complained about this patch since its commit. So I believe we can backport it and the patch should be safe for GCC 10 branch.
[Bug c++/99833] [8/9/10/11 Regression] structured binding + if init + generic lambda = internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99833 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/99833] [8/9/10/11 Regression] structured binding + if init + generic lambda = internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99833
--- Comment #3 from Marek Polacek ---
Reduced:
namespace std {
template struct integral_constant {
static constexpr int value = __v;
};
template struct tuple_size;
template struct tuple_element;
template
using __tuple_element_t = typename tuple_element<__i, _Tp>::type;
template class tuple;
template tuple(_UTypes...) -> tuple<_UTypes...>;
template class tuple<_T1, _T2> {
public:
template tuple(_U1, _U2);
};
template
struct tuple_size>
: integral_constant {};
template
struct tuple_element<__i, tuple<_Head, _Tail...>>
: tuple_element<__i - 1, tuple<_Tail...>> {};
template
struct tuple_element<0, tuple<_Head, _Tail...>> {
typedef _Head type;
};
template
__tuple_element_t<__i, tuple<_Elements...>> get(tuple<_Elements...>);
} // namespace std
void f(auto x) {
[&](auto...) {
auto y = std::tuple{"", x};
if constexpr (auto [_, z] = y; requires { z; })
;
}();
}
auto main() -> int { f(2); }
[Bug c++/99833] [8/9/10/11 Regression] structured binding + if init + generic lambda = internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99833 Marek Polacek changed: What|Removed |Added Build|-std=c++20 | CC||ppalka at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Started with r11-372. So may be a P1 :(.
[Bug c++/99427] [modules] in system headers: non-constant condition for static assertion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99427 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek --- Fixed then. Thanks for checking!
[Bug c++/99227] [meta] [modules] Bugs relating to header-units of STL header files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99227 Bug 99227 depends on bug 99427, which changed state. Bug 99427 Summary: [modules] in system headers: non-constant condition for static assertion https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99427 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/99427] [modules] in system headers: non-constant condition for static assertion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99427 --- Comment #4 from Alexander Lelyakin --- Not reproduced anymore
[Bug c++/99833] [8/9/10/11 Regression] structured binding + if init + generic lambda = internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99833
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2021-03-30
Keywords||ice-on-valid-code
Target Milestone|--- |8.5
Status|UNCONFIRMED |NEW
Summary|structured binding + if |[8/9/10/11 Regression]
|init + generic lambda = |structured binding + if
|internal compiler error |init + generic lambda =
||internal compiler error
CC||mpolacek at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Marek Polacek ---
Confirmed.
$ xg++-7 -c 99833.C -std=c++17 -fconcepts
# ok
$ xg++-8 -c 99833.C -std=c++17 -fconcepts
99833.C: In instantiation of ‘f(auto:1&&) [with auto:1 = int]:: [with auto:2 = {}]’:
99833.C:8:10: required from ‘auto f(auto:1&&) [with auto:1 = int]’
99833.C:12:13: required from here
99833.C:6:32: internal compiler error: in tsubst_decomp_names, at cp/pt.c:16673
if constexpr (auto [_, z] = y; requires { z; })
^~
0xa44cc6 tsubst_decomp_names
/home/mpolacek/src/gcc8/gcc/cp/pt.c:16673
0xa46041 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc8/gcc/cp/pt.c:16837
0xa4b103 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc8/gcc/cp/pt.c:17512
0xa46e75 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc8/gcc/cp/pt.c:16961
0xa45012 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc8/gcc/cp/pt.c:16714
0xa475be tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc8/gcc/cp/pt.c:17014
0xa475be tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc8/gcc/cp/pt.c:17014
0xa45012 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc8/gcc/cp/pt.c:16714
0xa475be tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc8/gcc/cp/pt.c:17014
0xa68a40 instantiate_decl(tree_node*, bool, bool)
/home/mpolacek/src/gcc8/gcc/cp/pt.c:24161
0x90b1e3 maybe_instantiate_decl
/home/mpolacek/src/gcc8/gcc/cp/decl2.c:5211
0x90bb8a mark_used(tree_node*, int)
/home/mpolacek/src/gcc8/gcc/cp/decl2.c:5312
0x814c71 build_over_call
/home/mpolacek/src/gcc8/gcc/cp/call.c:8286
0x804e91 build_op_call_1
/home/mpolacek/src/gcc8/gcc/cp/call.c:4589
0x805053 build_op_call(tree_node*, vec**, int)
/home/mpolacek/src/gcc8/gcc/cp/call.c:4618
0xa9a847 finish_call_expr(tree_node*, vec**, bool,
bool, int)
/home/mpolacek/src/gcc8/gcc/cp/semantics.c:2567
0xa503bf tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mpolacek/src/gcc8/gcc/cp/pt.c:18594
0xa4b422 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc8/gcc/cp/pt.c:17530
0xa4512d tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc8/gcc/cp/pt.c:16728
0xa45012 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc8/gcc/cp/pt.c:16714
[Bug fortran/99839] [8/9/10/11 Regression] ICE in inline_matmul_assign, at fortran/frontend-passes.c:4234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99839 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |8.5 Summary|ICE in |[8/9/10/11 Regression] ICE |inline_matmul_assign, at|in inline_matmul_assign, at |fortran/frontend-passes.c:4 |fortran/frontend-passes.c:4 |234 |234
[Bug c++/99841] (temporary) refs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99841
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #3 from Andrew Pinski ---
(In reply to g.peterhoff from comment #2)
> That is not the problem. I only made using type = ... and type(x) in the
> ctor calls so that I can test different types. You like to throw that out -
> has no influence.
I think you misunderstood.
Take a look at:
mm_pair_t m{type(1), type(2)};
there are two temps here created by type(1) and type(2). The lifetime of those
temps normally end at the end of the statement, unless they are extended due to
the C++ rules of binding the temp to a reference. In this case they are not
bound to a reference as the reference is not m but rather the constructor
arguments (this is why mm_t works while the others don't).
Adding -W -Wall -Werror to the command line we get the following
warnings/errors:
: In function 'int main()':
:33:24: error: '' is used uninitialized
[-Werror=uninitialized]
33 | std::cout << m.first << std::endl;
|^
:34:24: error: '' is used uninitialized
[-Werror=uninitialized]
34 | std::cout << m.second << std::endl;
|^~
:39:35: error: '' is used uninitialized
[-Werror=uninitialized]
39 | std::cout << std::get<0>(m) << std::endl;
| ^
:40:35: error: '' is used uninitialized
[-Werror=uninitialized]
40 | std::cout << std::get<1>(m) << std::endl;
| ^
:45:24: error: '' is used uninitialized
[-Werror=uninitialized]
45 | std::cout << m.min << std::endl;
|^~~
:46:24: error: '' is used uninitialized
[-Werror=uninitialized]
46 | std::cout << m.max << std::endl;
|^~~
- CUT
Which is exactly what you expect when the temp rvalue does not gets its
timeline extended past the end of that statement.
[Bug fortran/99839] ICE in inline_matmul_assign, at fortran/frontend-passes.c:4234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99839
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC||anlauf at gcc dot gnu.org,
||tkoenig at gcc dot gnu.org
Last reconfirmed||2021-03-30
Ever confirmed|0 |1
Priority|P3 |P4
--- Comment #1 from anlauf at gcc dot gnu.org ---
This one is funny. Simply punting on non-numeric and non-logical results
works around the ICE.
diff --git a/gcc/fortran/frontend-passes.c b/gcc/fortran/frontend-passes.c
index 7d3eae67632..213530e46e1 100644
--- a/gcc/fortran/frontend-passes.c
+++ b/gcc/fortran/frontend-passes.c
@@ -4193,6 +4193,19 @@ inline_matmul_assign (gfc_code **c, int *walk_subtrees,
if (m_case == none)
return 0;
+ /* We only handle assignment to numeric or logical variables. */
+ switch(expr1->ts.type)
+{
+case BT_INTEGER:
+case BT_LOGICAL:
+case BT_REAL:
+case BT_COMPLEX:
+ break;
+
+default:
+ return 0;
+}
+
ns = insert_block ();
/* Assign the type of the zero expression for initializing the resulting
Adding Thomas, who knows the code better.
[Bug target/99648] [11 regression] gcc.dg/torture/pr71522.c fails starting with r11-165 for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99648 --- Comment #4 from seurer at gcc dot gnu.org --- Which RTL do you want to see?
[Bug fortran/99840] [9/10/11 Regression] ICE in gfc_simplify_matmul, at fortran/simplify.c:4777
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99840 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- Patch. Check if a or b is zero-sized. diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c index 388aca7c38c..6c5259c648d 100644 --- a/gcc/fortran/simplify.c +++ b/gcc/fortran/simplify.c @@ -4728,7 +4728,9 @@ gfc_simplify_matmul (gfc_expr *matrix_a, gfc_expr *matrix_b) int stride_a, offset_a, stride_b, offset_b; if (!is_constant_array_expr (matrix_a) - || !is_constant_array_expr (matrix_b)) + || gfc_is_size_zero_array (matrix_a) + || !is_constant_array_expr (matrix_b) + || gfc_is_size_zero_array (matrix_b)) return NULL; /* MATMUL should do mixed-mode arithmetic. Set the result type. */
[Bug target/99648] [11 regression] gcc.dg/torture/pr71522.c fails starting with r11-165 for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99648 --- Comment #3 from seurer at gcc dot gnu.org --- The assembler isn't that long so here it is (from -Os): .file "pr71522.c" .machine power8 .section".text" .section.rodata.str1.1,"aMS",@progbits,1 .LC1: .string "AAA" .section.text.startup,"ax",@progbits .align 2 .globl main .type main, @function main: .LFB0: .cfi_startproc lis 9,.LC0@ha stwu 1,-48(1) .cfi_def_cfa_offset 48 mflr 0 la 9,.LC0@l(9) lis 4,.LC1@ha la 4,.LC1@l(4) lfd 0,0(9) lfd 1,8(9) lis 9,0x4151 ori 9,9,0x4141 addi 3,1,8 stw 0,52(1) .cfi_offset 65, 4 stw 9,8(1) lis 9,0x4141 ori 9,9,0x4120 stfd 0,32(1) stfd 1,40(1) stw 9,12(1) lis 9,0x3e00 stw 9,16(1) li 9,0 stw 9,20(1) bl strcmp cmpwi 0,3,0 beq 0,.L2 bl abort .L2: lwz 0,52(1) addi 1,1,48 .cfi_def_cfa_offset 0 mtlr 0 .cfi_restore 65 blr .cfi_endproc .LFE0: .size main,.-main .section.rodata.cst16,"aM",@progbits,16 .align 4 .LC0: .long 1095844161 .long 1094795552 .long 1040187392 .long 0 .ident "GCC: (GNU) 11.0.1 20210329 (experimental) [remotes/origin/HEAD revision c277abd:ad0a649:953624089be3f51c2ebacba65be8521bf6ae8430]" .gnu_attribute 4, 5 .section.note.GNU-stack,"",@progbits
[Bug c++/99283] [modules] ICE in assert_definition, at cp/module.cc:4608
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99283
--- Comment #16 from Alexander Lelyakin ---
Still reproduces:
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header system_error
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header type_traits
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header ccomplex
In file included from /usr/local/include/c++/11.0.1/ios:42,
from /usr/local/include/c++/11.0.1/istream:38,
from /usr/local/include/c++/11.0.1/sstream:38,
from /usr/local/include/c++/11.0.1/complex:45,
from /usr/local/include/c++/11.0.1/ccomplex:39:
/usr/local/include/c++/11.0.1/bits/ios_base.h:205:69: internal compiler error:
in assert_definition, at cp/module.cc:4491
205 | template <> struct is_error_code_enum : public true_type {
};
| ^
0x6e20eb trees_in::assert_definition(tree_node*, bool)
../../gcc/gcc/cp/module.cc:4491
0xa5db60 trees_in::odr_duplicate(tree_node*, bool)
../../gcc/gcc/cp/module.cc:11323
0xa6d21f trees_in::read_function_def(tree_node*, tree_node*)
../../gcc/gcc/cp/module.cc:11403
0xa6f711 module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14806
0xa6fd8d module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18068
0xa6fe4f module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18726
0xa6a0d0 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9661
0xa6aee6 trees_in::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:6662
0xa68937 trees_in::tree_node_vals(tree_node*)
../../gcc/gcc/cp/module.cc:7057
0xa68937 trees_in::tree_value()
../../gcc/gcc/cp/module.cc:8927
0xa68d6f trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9145
0xa6ab71 trees_in::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:6413
0xa68937 trees_in::tree_node_vals(tree_node*)
../../gcc/gcc/cp/module.cc:7057
0xa68937 trees_in::tree_value()
../../gcc/gcc/cp/module.cc:8927
0xa68d6f trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9145
0xa6ab71 trees_in::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:6413
0xa68937 trees_in::tree_node_vals(tree_node*)
../../gcc/gcc/cp/module.cc:7057
0xa68937 trees_in::tree_value()
../../gcc/gcc/cp/module.cc:8927
0xa68d6f trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9145
0xa6ab71 trees_in::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:6413
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
g++ (GCC) 11.0.1 20210330 (experimental)
Copyright (C) 2021 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.
commit 5f3c6027257118469a722816e228394b5978ddb0 (HEAD -> master, origin/trunk,
origin/master, origin/HEAD)
Author: Nathan Sidwell
Date: Tue Mar 30 09:45:59 2021 -0700
c++: duplicate const static members [PR 99283]
[Bug c++/99841] (temporary) refs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99841 --- Comment #2 from g.peterh...@t-online.de --- That is not the problem. I only made using type = ... and type(x) in the ctor calls so that I can test different types. You like to throw that out - has no influence.
[Bug fortran/99840] [9/10/11 Regression] ICE in gfc_simplify_matmul, at fortran/simplify.c:4777
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99840 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-03-30 Known to fail||10.2.1, 11.0, 8.4.1, 9.3.1 Priority|P3 |P4 CC||anlauf at gcc dot gnu.org --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. This one is funny. The TRANSPOSE seems to screw up the simplification. Works without TRANSPOSE.
[Bug c++/99831] ICE: in reshape_init, at cp/decl.c:6720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99831 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug lto/99828] inlining failed in call to ‘always_inline’ ‘memcpy’: --param max-inline-insns-auto limit reached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99828 --- Comment #5 from Jan Hubicka --- > Btw, one solution would be to drop __always_inline__ after always-inline > inlining > and thus make it reliably not present for IPA inlining. Removing it would make you to lose those errors, but we can ignore it for late inlining if we decide we do not really care about always inlining indirect calls (that are not reliably inlined by early inliner). But I tried that at some point and broke kernel. Note that we could also use syntactic aliase and consider two decls unmergeable if they differ by always_inline attribute. That should make it to behave consistently... Honza
[Bug c++/99841] (temporary) refs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99841
--- Comment #1 from Andrew Pinski ---
The question is:
mm_pair_t m{type(1), type(2)};
I think GCC is correct here, type(1) is a temp and it does not bind to a field
directly, it goes through a constructure and therefor the temp goes away right
after the statement is done.
[Bug c++/99831] ICE: in reshape_init, at cp/decl.c:6720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99831 --- Comment #7 from Marek Polacek --- There was en error + ICE, but since r11-5752 we only have the ICE. Looks like the ICE started with r277865.
[Bug other/99496] [11 regression] g++.dg/modules/xtreme-header-3_c.C ICEs after r11-7557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99496 seurer at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #16 from seurer at gcc dot gnu.org --- I just double checked and these are all fixed now. Thanks!
[Bug fortran/99819] [9/10/11 Regression] ICE in gfc_defer_symbol_init, at fortran/trans-decl.c:841
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99819 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-03-30 Status|UNCONFIRMED |NEW --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. I believe there are tons of duplicates of this one.
[Bug c++/99841] New: (temporary) refs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99841 Bug ID: 99841 Summary: (temporary) refs Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: g.peterh...@t-online.de Target Milestone: --- please see https://godbolt.org/z/Ez1K7eofr gcc gives different (false?) results than clang/icc. If you set O0 or remove O-option gives same results.
[Bug c++/99831] ICE: in reshape_init, at cp/decl.c:6720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99831
--- Comment #6 from Marek Polacek ---
Even shorter:
// PR c++/99831
template struct S {
constexpr S(const char ()[N]) : value{} { }
char value[N];
};
template struct string {
constexpr bool operator==(const string &) const = default;
};
template void operator+(string) {
char value[1];
S{value};
}
static_assert(string<"a">{} == string<"a">{});
[Bug fortran/99817] [10/11 Regression] ICE in create_function_arglist, at fortran/trans-decl.c:2838 (etc.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99817 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org, ||burnus at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- The ICE happens in Program received signal SIGSEGV, Segmentation fault. create_function_arglist (sym=) at ../../gcc-trunk/gcc/fortran/trans-decl.c:2838 2838 hidden_typelist = TREE_CHAIN (hidden_typelist); (gdb) git blame points to: commit 212f4988f37ccf788c8c72b1dc952980bc9be3b7 Author: Tobias Burnus Date: Tue Mar 23 15:45:36 2021 +0100 Fortran: Fix func decl mismatch [PR93660] Adding Tobias.
[Bug target/99781] [11 Regression] ICE in partial_subreg_p, at rtl.h:3144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99781 --- Comment #5 from Vladimir Makarov --- I've reproduced it too and started to work on it. I hope the fix will be ready this week.
[Bug lto/99828] inlining failed in call to ‘always_inline’ ‘memcpy’: --param max-inline-insns-auto limit reached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99828 --- Comment #4 from rguenther at suse dot de --- On March 30, 2021 7:44:56 PM GMT+02:00, andi-gcc at firstfloor dot org wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99828 > >--- Comment #3 from Andi Kleen --- >So what do you want to fix in the kernel? > >Use a wrapper for taking the address of the memcpy? >(I hope nothing in gcc would remove such a wrapper) Remove the always_inline or also place it on the definition.
[Bug c++/99831] ICE: in reshape_init, at cp/decl.c:6720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99831
Marek Polacek changed:
What|Removed |Added
Keywords|needs-reduction |
--- Comment #5 from Marek Polacek ---
And here's a reduced version of there original test. Will try to reduce
further.
template struct remove_cv { using type = int; };
template using __remove_cvref_t = typename remove_cv<_Tp>::type;
template using remove_cvref_t = __remove_cvref_t<_Tp>;
template
concept derived_from = __is_base_of(_Base, _Derived);
template struct iterator_traits;
struct input_iterator_tag;
namespace __detail {
template struct __iter_traits_impl {
using type = iterator_traits;
};
template
using __iter_traits = typename __iter_traits_impl<_Iter>::type;
template
using __iter_diff_t = typename __iter_traits<_Tp>::difference_type;
} // namespace __detail
template
using iter_difference_t = __detail::__iter_diff_t>;
namespace __detail {
template struct __iter_concept_impl;
template requires requires { typename _Iter; }
struct __iter_concept_impl<_Iter> {
using type = typename __iter_traits<_Iter>::iterator_concept;
};
template
using __iter_concept = typename __iter_concept_impl<_Iter>::type;
} // namespace __detail
template concept weakly_incrementable = requires(_Iter __i) {
__i;
};
template
concept input_iterator =
derived_from<__detail::__iter_concept<_Iter>, input_iterator_tag>;
template struct iterator_traits {
using iterator_concept = input_iterator_tag;
using difference_type = int;
};
template struct in_out_result {};
template using copy_n_result = in_out_result<_Out>;
struct {
template
constexpr copy_n_result<_Iter, _Out>
operator()(_Iter __first, iter_difference_t<_Iter> __n, _Out __result) {
for (; __n; --__n, ++__result)
*__result = *__first;
return {};
}
} copy_n;
template struct StringLiteral {
constexpr StringLiteral(const char ()[N]) { copy_n(str, N, value); }
char value[N];
};
template struct string {
constexpr bool operator==(const string &) const = default;
};
template void operator+(string) {
char value[1];
StringLiteral{value};
}
static_assert(string<"hello, world">{} == string<"hello"
", world">{});
static_assert(string<"a rose is a rose is a rose">{} == string<"a rose"
" is "
"a rose"
" is "
"a rose">{});
[Bug fortran/99840] New: [9/10/11 Regression] ICE in gfc_simplify_matmul, at fortran/simplify.c:4777
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99840 Bug ID: 99840 Summary: [9/10/11 Regression] ICE in gfc_simplify_matmul, at fortran/simplify.c:4777 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started with r8, compiles with r7 : $ cat z1.f90 program p integer, parameter :: x(0,0) = 0 integer :: y(0,0) y = matmul(x, transpose(x)) end $ gfortran-7 -c z1.f90 $ $ gfortran-11-20210328 -c z1.f90 f951: internal compiler error: Segmentation fault 0xc09d4f crash_signal ../../gcc/toplev.c:327 0x716f87 gfc_simplify_matmul(gfc_expr*, gfc_expr*) ../../gcc/fortran/simplify.c:4777 0x69b9d3 do_simplify ../../gcc/fortran/intrinsic.c:4664 0x6a63fa gfc_intrinsic_func_interface(gfc_expr*, int) ../../gcc/fortran/intrinsic.c:5050 0x6f5699 resolve_unknown_f ../../gcc/fortran/resolve.c:2926 0x6f5699 resolve_function ../../gcc/fortran/resolve.c:3270 0x6f5699 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:7105 0x6fbb24 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:11728 0x6fbb24 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11824 0x6fd0b7 resolve_codes ../../gcc/fortran/resolve.c:17395 0x6fd17e gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:17430 0x6e56e4 resolve_all_program_units ../../gcc/fortran/parse.c:6290 0x6e56e4 gfc_parse_file() ../../gcc/fortran/parse.c:6542 0x7320ef gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug fortran/99839] New: ICE in inline_matmul_assign, at fortran/frontend-passes.c:4234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99839 Bug ID: 99839 Summary: ICE in inline_matmul_assign, at fortran/frontend-passes.c:4234 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to r7, at -O1+ : $ cat z1.f90 program p real :: x(3, 3) = 1.0 class(*), allocatable :: z(:, :) z = matmul(x, x) end $ gfortran-11-20210328 -c z1.f90 -O0 $ $ gfortran-11-20210328 -c z1.f90 -O2 f951: internal compiler error: in inline_matmul_assign, at fortran/frontend-passes.c:4234 0x7bf248 inline_matmul_assign ../../gcc/fortran/frontend-passes.c:4234 0x7bfd69 gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int (*)(gfc_expr**, int*, void*), void*) ../../gcc/fortran/frontend-passes.c:5320 0x7c1172 optimize_namespace ../../gcc/fortran/frontend-passes.c:1500 0x7c154f gfc_run_passes(gfc_namespace*) ../../gcc/fortran/frontend-passes.c:169 0x6fd1a7 gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:17436 0x6e56e4 resolve_all_program_units ../../gcc/fortran/parse.c:6290 0x6e56e4 gfc_parse_file() ../../gcc/fortran/parse.c:6542 0x7320ef gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug fortran/99838] New: ICE in gfc_format_decoder, at fortran/error.c:970
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99838 Bug ID: 99838 Summary: ICE in gfc_format_decoder, at fortran/error.c:970 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- With option -Warray-temporaries, affects versions down to at least r5 : $ cat z1.f90 program p type t integer :: a end type type(t) :: x(3)[*] data x%a /1, 2, 3/ end $ gfortran-11-20210328 -c z1.f90 -fcoarray=lib $ gfortran-11-20210328 -c z1.f90 -Warray-temporaries -fcoarray=single $ $ gfortran-11-20210328 -c z1.f90 -Warray-temporaries -fcoarray=lib z1.f90:1:9: 1 | program p | 1 in gfc_format_decoder, at fortran/error.c:970 0x686202 gfc_format_decoder ../../gcc/fortran/error.c:970 0x162f05e pp_format(pretty_printer*, text_info*) ../../gcc/pretty-print.c:1475 0x1622fe1 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) ../../gcc/diagnostic.c:1244 0x685fc5 gfc_report_diagnostic ../../gcc/fortran/error.c:782 0x685fc5 gfc_warning ../../gcc/fortran/error.c:815 0x686d86 gfc_warning(int, char const*, ...) ../../gcc/fortran/error.c:846 0x73c613 gfc_trans_create_temp_array(stmtblock_t*, stmtblock_t*, gfc_ss*, tree_node*, tree_node*, bool, bool, bool, locus*) ../../gcc/fortran/trans-array.c:1355 0x746663 trans_array_constructor ../../gcc/fortran/trans-array.c:2724 0x746663 gfc_add_loop_ss_code ../../gcc/fortran/trans-array.c:3012 0x746d95 gfc_conv_loop_setup(gfc_loopinfo*, locus*) ../../gcc/fortran/trans-array.c:5317 0x776b0d gfc_trans_assignment_1 ../../gcc/fortran/trans-expr.c:11179 0x753cd8 generate_coarray_sym_init ../../gcc/fortran/trans-decl.c:5736 0x71d2b2 do_traverse_symtree ../../gcc/fortran/symbol.c:4170 0x753135 generate_coarray_init ../../gcc/fortran/trans-decl.c:5786 0x75f9c4 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6822 0x6e5de6 translate_all_program_units ../../gcc/fortran/parse.c:6351 0x6e5de6 gfc_parse_file() ../../gcc/fortran/parse.c:6620 0x7320ef gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug fortran/99837] ICE in parse_associate, at fortran/parse.c:4780
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99837 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #1 from G. Steinmetz --- Similar cases with "select type" instead : $ cat z3.f90 program p type t integer, allocatable :: a(:) end type class(t) :: x[:] select type (y => x) end select end $ cat z4.f90 program p type t integer, allocatable :: a(:) end type class(t) :: x[*] select type (y => x) end select end
[Bug fortran/99837] New: ICE in parse_associate, at fortran/parse.c:4780
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99837 Bug ID: 99837 Summary: ICE in parse_associate, at fortran/parse.c:4780 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Follow-up of pr88357, affects versions down to at least r5. With a missing attribute allocatable or pointer : $ cat z1.f90 program p type t integer, allocatable :: a(:) end type class(t) :: x[:] associate (y => x) end associate end $ cat z2.f90 program p type t integer, allocatable :: a(:) end type class(t) :: x[*] associate (y => x) end associate end $ gfortran-11-20210328 -c z1.f90 -fcoarray=single f951: internal compiler error: in parse_associate, at fortran/parse.c:4780 0x6e3f39 parse_associate ../../gcc/fortran/parse.c:4780 0x6e3f39 parse_executable ../../gcc/fortran/parse.c:5524 0x6e401f parse_progunit ../../gcc/fortran/parse.c:5922 0x6e5671 gfc_parse_file() ../../gcc/fortran/parse.c:6437 0x7320ef gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212 With that attribute : $ cat z0z1.f90 program p type t integer, allocatable :: a(:) end type class(t), allocatable :: x[:] associate (y => x) end associate end $ gfortran-11-20210328 -c z0z1.f90 -fcoarray=single z0z1.f90:1:9: 1 | program p | 1 Error: Pointer assignment target in initialization expression does not have the TARGET attribute at (1)
[Bug rtl-optimization/96264] [10 Regression] wrong code with -Os -fno-forward-propagate -fschedule-insns -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96264 --- Comment #16 from Peter Bergner --- (In reply to seurer from comment #15) > It still fails on gcc 10, though Vlad, can we get this backported to GCC 10? Maybe in time for GCC 10.3?
[Bug target/99836] New: aarch64: -fpatchable-function-entry=N[,0] should place .cfi_startproc before NOPs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99836
Bug ID: 99836
Summary: aarch64: -fpatchable-function-entry=N[,0] should place
.cfi_startproc before NOPs
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
Extracted from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92424#c8
% echo 'int main() {}' > a.c
% clang --target=aarch64 -fpatchable-function-entry=2
-mbranch-protection=standard -S a.c -o -
...
main: // @main
.Lfunc_begin0:
.cfi_startproc
// %bb.0: // %entry
hint#34
.Lpatch0:
nop
nop
%
/tmp/glibc-many/install/compilers/aarch64-linux-gnu/bin/aarch64-glibc-linux-gnu-g++
-fpatchable-function-entry=2 -mbranch-protection=standard -S a.c -o -
.arch armv8-a
.file "a.c"
.text
.align 2
.global main
.type main, %function
main:
hint34 // bti c
.section__patchable_function_entries,"aw",@progbits
.align 3
.8byte .LPFE1
.text
.LPFE1:
nop
nop
.LFB0:
.cfi_startproc
For -fpatchable-function-entry=N[,0], placing .cfi_startproc before NOPs makes
more sense and can make unwinding work in that region.
For N[,M] where M>0, that is a very narrow use case by the Linux kernel. I
prefer not to place .cfi_startproc above the function label.
[Bug lto/99828] inlining failed in call to ‘always_inline’ ‘memcpy’: --param max-inline-insns-auto limit reached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99828 --- Comment #3 from Andi Kleen --- So what do you want to fix in the kernel? Use a wrapper for taking the address of the memcpy? (I hope nothing in gcc would remove such a wrapper)
[Bug c++/99831] ICE: in reshape_init, at cp/decl.c:6720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99831
--- Comment #4 from 康桓瑋 ---
When the array subscript is outside the bounds of array, gcc seems to fall into
infinite recursion due to the default operator==.
Here is the reduced with no header:
struct A {
constexpr A(const char*) {}
char value[1] = {};
};
template
struct B {
constexpr bool operator==(const B&) const = default;
};
constexpr auto foo(auto) {
constexpr auto a = [] {
char value[1];
value[2] = 0; // this line
return A{value};
}();
return B{};
}
constexpr auto b = foo(B<"">{});
: In instantiation of 'struct B< >':
:8:18: recursively required from 'struct B< >'
:8:18: required from 'struct B< >'
:17:15: required from 'constexpr auto foo(auto:1) [with auto:1 =
B]'
:20:23: required from here
:8:18: fatal error: template instantiation depth exceeds maximum of 900
(use '-ftemplate-depth=' to increase the maximum)
8 | constexpr bool operator==(const B&) const = default;
| ^~~~
compilation terminated.
[Bug tree-optimization/99835] New: missed optimization for dead code elimination at -O3 (vs. -O1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99835
Bug ID: 99835
Summary: missed optimization for dead code elimination at -O3
(vs. -O1)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
[558] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.1 20210330 (experimental) [master revision
8aac913adfc:ff4ebc2f17c:65374af219f9c5c594951a07e766fe70c1136a1f] (GCC)
[559] %
[559] % gcctk -O1 -S -o O1.s small.c
[560] % gcctk -O3 -S -o O3.s small.c
[561] %
[561] % wc O1.s O3.s
23 45 420 O1.s
35 66 615 O3.s
58 111 1035 total
[562] %
[562] % grep foo O1.s
[563] % grep foo O3.s
jmp foo
[564] %
[564] % cat small.c
extern void foo(void);
static int a, d;
void b();
static int c() {
foo();
b();
}
void b() {
while (d) {
if (!a)
break;
c();
}
}
int main() {
b();
return 0;
}
[Bug ipa/99834] New: missed optimization for dead code elimination at -O3 (vs. -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99834
Bug ID: 99834
Summary: missed optimization for dead code elimination at -O3
(vs. -O2)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
CC: marxin at gcc dot gnu.org
Target Milestone: ---
[590] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.1 20210330 (experimental) [master revision
8aac913adfc:ff4ebc2f17c:65374af219f9c5c594951a07e766fe70c1136a1f] (GCC)
[591] %
[591] % gcctk -O2 -S -o O2.s small.c
[592] % gcctk -O3 -S -o O3.s small.c
[593] %
[593] % wc O2.s O3.s
43 90 704 O2.s
61 126 950 O3.s
104 216 1654 total
[594] %
[594] % grep foo O2.s
[595] % grep foo O3.s
callfoo
callfoo
[596] %
[596] % cat small.c
extern void foo(void);
static int a, b, c;
static int d() {
for (a = 0; a < 1; a++)
b = 1;
for (; b; b--)
for (; c; c--)
;
return 0;
}
static void e() {
if (d())
foo();
}
int main() {
e();
e();
return 0;
}
[Bug c++/99833] New: structured binding + if init + generic lambda = internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99833
Bug ID: 99833
Summary: structured binding + if init + generic lambda =
internal compiler error
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickgray0 at brown dot edu
Target Milestone: ---
Build: -std=c++20
as the title suggests, the following code triggers an internal compiler error:
#include
auto f(auto&& x) {
[&](auto...) {
auto y = std::tuple{ "what's happening here?", x };
if constexpr (auto [_, z] = y; requires { z; })
return;
}();
}
auto main()->int {
f(42);
}
error message: :6:36: internal compiler error: in tsubst_decomp_names,
at cp/pt.c:18034
6 | if constexpr (auto [_, z] = y; requires { z; })
|^~
0x1cfb6a9 internal_error(char const*, ...)
???:0
0x6ba871 fancy_abort(char const*, int, char const*)
???:0
0x91c84f instantiate_decl(tree_node*, bool, bool)
???:0
0x7c6c0e maybe_instantiate_decl(tree_node*)
???:0
0x7c8370 mark_used(tree_node*, int)
???:0
0x6e2835 build_op_call(tree_node*, vec**, int)
???:0
0x980ae5 finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0x91c84f instantiate_decl(tree_node*, bool, bool)
???:0
0x7c6c0e maybe_instantiate_decl(tree_node*)
???:0
0x7c8370 mark_used(tree_node*, int)
???:0
0x6de097 build_new_function_call(tree_node*, vec**, int)
???:0
0x980c6c finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0x8e12ad c_parse_file()
???:0
0xa600a2 c_common_parse_file()
???:0
either moving the structured binding outside of if statement or making the
lambda non-generic seems to solve the problem.
[Bug tree-optimization/98268] [10/11 Regression] ICE: verify_gimple failed with LTO and SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98268 rsandifo at gcc dot gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #7 from rsandifo at gcc dot gnu.org --- Mine. Seems that maybe_canonicalize_mem_ref_addr should call recompute_tree_invariant_for_addr_expr when replacing _MEM_REF (which is never treated as invariant) with _REF (which can be invariant).
[Bug c++/99283] [modules] ICE in assert_definition, at cp/module.cc:4608
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99283 --- Comment #15 from Nathan Sidwell --- another one encountered on the way ... * 5f3c6027257 2021-03-30 | c++: duplicate const static members [PR 99283]
[Bug c++/99283] [modules] ICE in assert_definition, at cp/module.cc:4608
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99283 --- Comment #14 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:5f3c6027257118469a722816e228394b5978ddb0 commit r11-7915-g5f3c6027257118469a722816e228394b5978ddb0 Author: Nathan Sidwell Date: Tue Mar 30 09:45:59 2021 -0700 c++: duplicate const static members [PR 99283] This is the bug that keeps on giving. Reducing it has been successful at hitting other defects. In this case, some more specialization hash table fun, plus an issue with reading in a definition of a duplicated declaration. At least I discovered a null context check is no longer needed. PR c++/99283 gcc/cp/ * module.cc (dumper::operator): Make less brittle. (trees_out::core_bools): VAR_DECLs always have a context. (trees_out::key_mergeable): Use same_type_p for asserting. (trees_in::read_var_def): Propagate DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P. gcc/testsuite/ * g++.dg/modules/pr99283-5.h: New. * g++.dg/modules/pr99283-5_a.H: New. * g++.dg/modules/pr99283-5_b.H: New. * g++.dg/modules/pr99283-5_c.C: New.
[Bug middle-end/61112] Simple example triggers false-positive -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61112
--- Comment #9 from Manuel López-Ibáñez ---
(In reply to Martin Sebor from comment #8)
> I've added both the passing test case from comment #0 and the still failing
> test case from comment #5 to the test suite and xfailed the latter (thus
> reconfirming for GCC 11). Without any further analysis, the comment #5 test
> case also looks similar to pr99756.
I think the '||' is a red-herring or insufficient to explain the PR. The
following also warns:
int p;
void foo (int x, int y, int z, int a)
{
int w;
if (x)
w = z;
if (y)
w = 10;
if (a)
w = 67;
if (x)
p = w;
}
[Bug c++/99790] [8/9/10 Regression] internal compiler error: in expand_expr_real_2 since r7-3811
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99790 Jakub Jelinek changed: What|Removed |Added Summary|[8/9/10/11 Regression] |[8/9/10 Regression] |internal compiler error: in |internal compiler error: in |expand_expr_real_2 since|expand_expr_real_2 since |r7-3811 |r7-3811 --- Comment #6 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug middle-end/60488] missing uninitialized warning (address taken, VOP)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60488 --- Comment #9 from Manuel López-Ibáñez --- (In reply to Martin Sebor from comment #8) > You're right, the test cases aren't equivalent, or meant to be. What I want > to highlight is that in the test case in comment #6, in g() and other > similar ones like it the warning is most likely going to be a false > positive, while in h(), not warning most likely a false negative. Both of > these "problems" are due to the same underlying assumption: that a variable > whose address escapes may be modified by a subsequent call to an unknown > function. Sure, but that assumption is not the problem in this PR, since assuming one thing or the other only matters for distinguishing between "is" and "may be", but a warning should have been given and it is not given.
[Bug c++/99790] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_2 since r7-3811
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99790 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:953624089be3f51c2ebacba65be8521bf6ae8430 commit r11-7914-g953624089be3f51c2ebacba65be8521bf6ae8430 Author: Jakub Jelinek Date: Tue Mar 30 18:15:32 2021 +0200 c++: Fix ICE on PTRMEM_CST in lambda in inline var initializer [PR99790] The following testcase ICEs (since the addition of inline var support), because the lambda contains PTRMEM_CST but finish_function is called for the lambda quite early during parsing it (from finish_lambda_function) when the containing class is still incomplete. That means that during genericization cplus_expand_constant keeps the PTRMEM_CST unmodified, but later nothing lowers it when the class is finalized. Using sizeof etc. on the class in such contexts is rejected by both g++ and clang++, and when the PTRMEM_CST appears e.g. in static var initializers rather than in functions, we handle it correctly because c_parse_final_cleanups -> lower_var_init will handle those cplus_expand_constant when all classes are already finalized. The following patch fixes it by calling cplus_expand_constant again during gimplification, as we are now unconditionally unit at a time, I'd think everything that could be completed will be before we start gimplification. 2021-03-30 Jakub Jelinek PR c++/99790 * cp-gimplify.c (cp_gimplify_expr): Handle PTRMEM_CST. * g++.dg/cpp1z/pr99790.C: New test.
[Bug rtl-optimization/99830] [11 Regression] ICE: in lra_eliminate_regs_1, at lra-eliminations.c:659 with -O2 -fno-expensive-optimizations -fno-split-wide-types -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99830 Alex Coplan changed: What|Removed |Added Last reconfirmed||2021-03-30 CC||acoplan at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Alex Coplan --- Confirmed. Started with r11-5185-gd0d8b5d83614d8f0d0e40c0520d4f40ffa01f8d9 so must be latent. I'll see if I can recover a testcase that ICEs prior to that rev.
[Bug target/99813] [11 Regression] SVE: Invalid assembly at -O3 (multiplier out of range in incb instruction)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99813 Jakub Jelinek changed: What|Removed |Added Attachment #50487|0 |1 is obsolete|| --- Comment #6 from Jakub Jelinek --- Created attachment 50489 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50489=edit gcc11-pr99813.patch Retesting this overnight too.
[Bug target/99102] [11 Regression] SVE: Wrong code with -O2 -ftree-vectorize -march=armv8.2-a+sve -msve-vector-bits=256
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99102 --- Comment #7 from rsandifo at gcc dot gnu.org --- *** Bug 98917 has been marked as a duplicate of this bug. ***
[Bug target/98917] SVE: wrong code with -O -ftree-vectorize -msve-vector-bits=128 --param=aarch64-autovec-preference=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98917 rsandifo at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED CC||rsandifo at gcc dot gnu.org --- Comment #3 from rsandifo at gcc dot gnu.org --- Same underlying problem as PR99102. *** This bug has been marked as a duplicate of bug 99102 ***
[Bug libstdc++/99832] New: std::chrono::system_clock::to_time_t needs ABI tag for 32-bit time_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99832 Bug ID: 99832 Summary: std::chrono::system_clock::to_time_t needs ABI tag for 32-bit time_t Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: ABI Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- chrono::system_clock defines: static std::time_t to_time_t(const time_point& __t) noexcept This is a non-template function and its mangled name does not depend on the return type. The mangled name is: _ZNSt6chrono3_V212system_clock9to_time_tERKNS_10time_pointIS1_NS_8durationIlSt5ratioILl1ELl10EE For a target that allows time_t to be either 32-bit or 64-bit, we need this mangled name to reflect the type of time_t.
[Bug target/99813] [11 Regression] SVE: Invalid assembly at -O3 (multiplier out of range in incb instruction)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99813 --- Comment #5 from Jakub Jelinek --- Oops, totally missed that.
[Bug c++/97536] [concepts] parser segfault for concept defined in function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97536
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
--- Comment #2 from Marek Polacek ---
Still present, just hit this with
template void forward() {
concept C = true;
}
Let me take a look then...
[Bug target/99820] aarch64: ICE (segfault) in aarch64_analyze_loop_vinfo with -moverride=tune=use_new_vector_costs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99820 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from ktkachov at gcc dot gnu.org --- Fixed.
[Bug target/99820] aarch64: ICE (segfault) in aarch64_analyze_loop_vinfo with -moverride=tune=use_new_vector_costs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99820 --- Comment #1 from CVS Commits --- The master branch has been updated by Kyrylo Tkachov : https://gcc.gnu.org/g:c277abd9cd3d10db59f9965d7d6356868da42a9f commit r11-7913-gc277abd9cd3d10db59f9965d7d6356868da42a9f Author: Kyrylo Tkachov Date: Tue Mar 30 16:42:17 2021 +0100 aarch64: PR target/99820: Guard on available SVE issue info before using This fixes a simple segfault ICE when using the use_new_vector_costs tunable with a CPU tuning that it wasn't intended for. I'm not adding a testcase here as we intend to remove the tunable for GCC 12 anyway (the new costing logic will remain and will benefit from this extra check, but the -moverride option will no longer exist). gcc/ChangeLog: PR target/99820 * config/aarch64/aarch64.c (aarch64_analyze_loop_vinfo): Check for available issue_info before using it.
[Bug target/99216] ICE in aarch64_sve::function_expander::expand() with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99216 --- Comment #9 from rsandifo at gcc dot gnu.org --- *** Bug 99252 has been marked as a duplicate of this bug. ***
[Bug target/99252] SVE: ICE in maybe_legitimize_operand with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99252 rsandifo at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED CC||rsandifo at gcc dot gnu.org --- Comment #2 from rsandifo at gcc dot gnu.org --- Confirmed to be the same problem as PR99216. *** This bug has been marked as a duplicate of bug 99216 ***
[Bug target/99540] [10 Regression] ICE: Segmentation fault in aarch64_add_offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99540 --- Comment #10 from rsandifo at gcc dot gnu.org --- *** Bug 99560 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/99560] aarch64: ICE (segfault) in LRA with SVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99560 rsandifo at gcc dot gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from rsandifo at gcc dot gnu.org --- Same -ftrapv problem as PR99540. *** This bug has been marked as a duplicate of bug 99540 ***
[Bug target/99813] [11 Regression] SVE: Invalid assembly at -O3 (multiplier out of range in incb instruction)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99813 --- Comment #4 from rsandifo at gcc dot gnu.org --- Thanks for looking at this. I agree swapping the constraints for operand 2 looks like the right fix, and brings it into line with *add3_aarch64". I think we need to swap operand 1 too though, since Uai needs tied registers but Uav doesn't. I'll test with that change overnight.
[Bug c++/99377] [modules] undefined std::string_view::empty() if referenced in inline exported function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99377 Boris Kolpackov changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #4 from Boris Kolpackov --- I still get the same error if I move the inline function into an interface partition (main.cxx is unchanged): cat
[Bug target/98119] [10/11 Regression] SVE: Wrong code with -O1 -ftree-vectorize -msve-vector-bits=512 -mtune=thunderx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98119 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #3 from rsandifo at gcc dot gnu.org --- Mine.
[Bug c++/99831] ICE: in reshape_init, at cp/decl.c:6720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99831 Marek Polacek changed: What|Removed |Added Keywords||needs-reduction --- Comment #3 from Marek Polacek --- Trying to reduce (--param ggc-min-heapsize=100 --param ggc-min-expand=10 seems to help), but it'll take time.
[Bug target/99822] [11 Regression] Assembler messages: Error: integer register expected in the extended/shifted operand register at operand 3 -- `adds x1,xzr,#2'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99822 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from ktkachov at gcc dot gnu.org --- Fixed.
[Bug target/99822] [11 Regression] Assembler messages: Error: integer register expected in the extended/shifted operand register at operand 3 -- `adds x1,xzr,#2'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99822 --- Comment #3 from CVS Commits --- The master branch has been updated by Kyrylo Tkachov : https://gcc.gnu.org/g:19199a6f2b0f4ce4b100856c78706d56a16b1956 commit r11-7912-g19199a6f2b0f4ce4b100856c78706d56a16b1956 Author: Kyrylo Tkachov Date: Tue Mar 30 15:43:36 2021 +0100 aarch64: PR target/99822 Don't allow zero register in first operand of SUBS/ADDS-immediate In this PR we end up generating an invalid instruction: adds x1,xzr,#2 because the pattern accepts zero as an operand in the comparison, but the instruction doesn't. Fix it by adjusting the predicate and constraints. gcc/ChangeLog: PR target/99822 * config/aarch64/aarch64.md (sub3_compare1_imm): Do not allow zero in operand 1. gcc/testsuite/ChangeLog: PR target/99822 * gcc.c-torture/compile/pr99822.c: New test.
[Bug c++/99831] ICE: in reshape_init, at cp/decl.c:6720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99831 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Keywords||ice-on-valid-code Last reconfirmed||2021-03-30 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Marek Polacek --- Confirmed. Breakpoint 1, fancy_abort (file=0x283d618 "/home/mpolacek/src/gcc/gcc/cp/decl.c", line=6720, function=0x28403ca "reshape_init") at /home/mpolacek/src/gcc/gcc/diagnostic.c:1884 1884 if (global_dc->printer == NULL) (gdb) up #1 0x00b284fd in reshape_init (type=, init=, complain=3) at /home/mpolacek/src/gcc/gcc/cp/decl.c:6720 6720 gcc_assert (BRACE_ENCLOSED_INITIALIZER_P (init)); (gdb) p init $1 =
[Bug c++/99831] ICE: in reshape_init, at cp/decl.c:6720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99831 --- Comment #1 from 康桓瑋 --- Note that if we comment one of the asserts, there will be no problem, or we just comment the redundant std::ranges::sort.
[Bug target/99781] [11 Regression] ICE in partial_subreg_p, at rtl.h:3144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99781 rsandifo at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-03-30 Status|UNCONFIRMED |NEW --- Comment #4 from rsandifo at gcc dot gnu.org --- Confirmed. The REG_NOTE itself is easy to fix (I have a patch), but then we run into similar problems because of the (correct-looking) code added for PR77761. Not sure what the best way out of this is.
[Bug c++/99831] New: ICE: in reshape_init, at cp/decl.c:6720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99831
Bug ID: 99831
Summary: ICE: in reshape_init, at cp/decl.c:6720
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
This is a complicated one since I don't know how to reduce it.
https://godbolt.org/z/rqTGxMWef
#include
template
struct StringLiteral {
constexpr StringLiteral(const char ()[N]) {
std::ranges::copy_n(str, N, value);
}
char value[N];
};
template
struct string{
constexpr bool operator==(const string&) const noexcept = default;
};
template
constexpr auto operator+(string, string) {
constexpr auto L3 = []{
constexpr auto size1 = sizeof(L1.value);
constexpr auto size2 = sizeof(L2.value);
char value[size1 + size2 - 1] = {};
std::ranges::sort(value);
std::ranges::copy_n(L1.value, size1, value);
std::ranges::copy_n(L2.value, size2, value + size1 - 1);
return StringLiteral{value};
}();
return string{};
}
static_assert(
string<"hello, world">{} ==
string<"hello">{} + string<", world">{}
);
static_assert(
string<"a rose is a rose is a rose">{} ==
string<"a rose">{} + string<" is ">{} +
string<"a rose">{} + string<" is ">{} +
string<"a rose">{}
);
:36:40: internal compiler error: in reshape_init, at cp/decl.c:6720
36 | string<"a rose is a rose is a rose">{} ==
|^
0x1cfb6a9 internal_error(char const*, ...)
???:0
0x6ba871 fancy_abort(char const*, int, char const*)
???:0
0x7810b6 reshape_init(tree_node*, tree_node*, int)
???:0
0x97e050 finish_compound_literal(tree_node*, tree_node*, int, fcl_t)
???:0
0x8e12ad c_parse_file()
???:0
0xa600a2 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug testsuite/91799] [10/11 regression] r273245 breaks test case gcc.target/powerpc/pr88233.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91799 seurer at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #12 from seurer at gcc dot gnu.org --- fixed
[Bug rtl-optimization/99830] New: [11 Regression] ICE: in lra_eliminate_regs_1, at lra-eliminations.c:659 with -O2 -fno-expensive-optimizations -fno-split-wide-types -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99830 Bug ID: 99830 Summary: [11 Regression] ICE: in lra_eliminate_regs_1, at lra-eliminations.c:659 with -O2 -fno-expensive-optimizations -fno-split-wide-types -g Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: aarch64-unknown-linux-gnu Created attachment 50488 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50488=edit reduced testcase Compiler output: $ aarch64-unknown-linux-gnu-gcc -O2 -fno-expensive-optimizations -fno-split-wide-types -g testcase.c during RTL pass: reload testcase.c: In function 'foo': testcase.c:6:1: internal compiler error: in lra_eliminate_regs_1, at lra-eliminations.c:659 6 | } | ^ 0x73e41c lra_eliminate_regs_1(rtx_insn*, rtx_def*, machine_mode, bool, bool, poly_int<2u, long>, bool) /repo/gcc-trunk/gcc/lra-eliminations.c:659 0xf16d42 lra_eliminate_regs_1(rtx_insn*, rtx_def*, machine_mode, bool, bool, poly_int<2u, long>, bool) /repo/gcc-trunk/gcc/lra-eliminations.c:602 0xf16b3c lra_eliminate_regs_1(rtx_insn*, rtx_def*, machine_mode, bool, bool, poly_int<2u, long>, bool) /repo/gcc-trunk/gcc/lra-eliminations.c:503 0xf16ba9 lra_eliminate_regs_1(rtx_insn*, rtx_def*, machine_mode, bool, bool, poly_int<2u, long>, bool) /repo/gcc-trunk/gcc/lra-eliminations.c:507 0xf171ad lra_eliminate_regs_1(rtx_insn*, rtx_def*, machine_mode, bool, bool, poly_int<2u, long>, bool) /repo/gcc-trunk/gcc/lra-eliminations.c:610 0xf16d42 lra_eliminate_regs_1(rtx_insn*, rtx_def*, machine_mode, bool, bool, poly_int<2u, long>, bool) /repo/gcc-trunk/gcc/lra-eliminations.c:602 0xf16ba9 lra_eliminate_regs_1(rtx_insn*, rtx_def*, machine_mode, bool, bool, poly_int<2u, long>, bool) /repo/gcc-trunk/gcc/lra-eliminations.c:507 0xf171ad lra_eliminate_regs_1(rtx_insn*, rtx_def*, machine_mode, bool, bool, poly_int<2u, long>, bool) /repo/gcc-trunk/gcc/lra-eliminations.c:610 0xf183ff eliminate_regs_in_insn(rtx_insn*, bool, bool, poly_int<2u, long>) /repo/gcc-trunk/gcc/lra-eliminations.c:1023 0xf18f9d process_insn_for_elimination /repo/gcc-trunk/gcc/lra-eliminations.c:1333 0xf18f9d lra_eliminate(bool, bool) /repo/gcc-trunk/gcc/lra-eliminations.c:1401 0xefa038 lra(_IO_FILE*) /repo/gcc-trunk/gcc/lra.c:2470 0xeab919 do_reload /repo/gcc-trunk/gcc/ira.c:5835 0xeab919 execute /repo/gcc-trunk/gcc/ira.c:6021 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ aarch64-unknown-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r11-7911-20210330134321-gf64b91568f3-checking-yes-rtl-df-extra-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/11.0.1/lto-wrapper Target: aarch64-unknown-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --with-sysroot=/usr/aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu --with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld --with-as=/usr/bin/aarch64-unknown-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r11-7911-20210330134321-gf64b91568f3-checking-yes-rtl-df-extra-aarch64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.0.1 20210330 (experimental) (GCC)
[Bug testsuite/98125] [11 Regression] New test case g++.dg/pr93195a.C in r11-5656 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125
--- Comment #18 from Jakub Jelinek ---
Another more targeted partial reversion:
2021-03-30 Jakub Jelinek
* targhooks.h (default_print_patchable_function_entry_1): Declare.
* targhooks.c (default_print_patchable_function_entry_1): New function,
copied from default_print_patchable_function_entry with an added flags
argument.
(default_print_patchable_function_entry): Rewritten into a small
wrapper around default_print_patchable_function_entry_1.
* config/rs6000/rs6000.c (TARGET_ASM_PRINT_PATCHABLE_FUNCTION_ENTRY):
Redefine.
(rs6000_print_patchable_function_entry): New function.
--- gcc/targhooks.h.jj 2021-01-04 10:25:39.665224403 +0100
+++ gcc/targhooks.h 2021-03-30 15:48:42.826706369 +0200
@@ -230,6 +230,9 @@ extern bool default_use_by_pieces_infras
bool);
extern int default_compare_by_pieces_branch_ratio (machine_mode);
+extern void default_print_patchable_function_entry_1 (FILE *,
+ unsigned HOST_WIDE_INT,
+ bool, unsigned int);
extern void default_print_patchable_function_entry (FILE *,
unsigned HOST_WIDE_INT,
bool);
--- gcc/targhooks.c.jj 2021-01-04 10:25:38.974232228 +0100
+++ gcc/targhooks.c 2021-03-30 15:51:22.924932795 +0200
@@ -1832,17 +1832,15 @@ default_compare_by_pieces_branch_ratio (
return 1;
}
-/* Write PATCH_AREA_SIZE NOPs into the asm outfile FILE around a function
- entry. If RECORD_P is true and the target supports named sections,
- the location of the NOPs will be recorded in a special object section
- called "__patchable_function_entries". This routine may be called
- twice per function to put NOPs before and after the function
- entry. */
+/* Helper for default_print_patchable_function_entry and other
+ print_patchable_function_entry hook implementations. */
void
-default_print_patchable_function_entry (FILE *file,
- unsigned HOST_WIDE_INT patch_area_size,
- bool record_p)
+default_print_patchable_function_entry_1 (FILE *file,
+ unsigned HOST_WIDE_INT
+ patch_area_size,
+ bool record_p,
+ unsigned int flags)
{
const char *nop_templ = 0;
int code_num;
@@ -1864,9 +1862,6 @@ default_print_patchable_function_entry (
patch_area_number++;
ASM_GENERATE_INTERNAL_LABEL (buf, "LPFE", patch_area_number);
- unsigned int flags = SECTION_WRITE | SECTION_RELRO;
- if (HAVE_GAS_SECTION_LINK_ORDER)
- flags |= SECTION_LINK_ORDER;
switch_to_section (get_section ("__patchable_function_entries",
flags, current_function_decl));
assemble_align (POINTER_SIZE);
@@ -1883,6 +1878,25 @@ default_print_patchable_function_entry (
output_asm_insn (nop_templ, NULL);
}
+/* Write PATCH_AREA_SIZE NOPs into the asm outfile FILE around a function
+ entry. If RECORD_P is true and the target supports named sections,
+ the location of the NOPs will be recorded in a special object section
+ called "__patchable_function_entries". This routine may be called
+ twice per function to put NOPs before and after the function
+ entry. */
+
+void
+default_print_patchable_function_entry (FILE *file,
+ unsigned HOST_WIDE_INT patch_area_size,
+ bool record_p)
+{
+ unsigned int flags = SECTION_WRITE | SECTION_RELRO;
+ if (HAVE_GAS_SECTION_LINK_ORDER)
+flags |= SECTION_LINK_ORDER;
+ default_print_patchable_function_entry_1 (file, patch_area_size, record_p,
+ flags);
+}
+
bool
default_profile_before_prologue (void)
{
--- gcc/config/rs6000/rs6000.c.jj 2021-03-29 11:15:49.942202792 +0200
+++ gcc/config/rs6000/rs6000.c 2021-03-30 15:59:10.299755166 +0200
@@ -1341,6 +1341,9 @@ static const struct attribute_spec rs600
#define TARGET_ASM_ASSEMBLE_VISIBILITY rs6000_assemble_visibility
#endif
+#undef TARGET_ASM_PRINT_PATCHABLE_FUNCTION_ENTRY
+#define TARGET_ASM_PRINT_PATCHABLE_FUNCTION_ENTRY
rs6000_print_patchable_function_entry
+
#undef TARGET_SET_UP_BY_PROLOGUE
#define TARGET_SET_UP_BY_PROLOGUE rs6000_set_up_by_prologue
@@ -14642,6 +14645,30 @@ rs6000_assemble_visibility (tree decl, i
}
#endif
+/* Write PATCH_AREA_SIZE NOPs into the asm outfile FILE around a function
+ entry. If RECORD_P is true and the target supports named sections,
+ the location of the NOPs will be recorded in a special object section
+ called
