[Bug tree-optimization/99017] ICE: Segmentation fault (in vect_bb_vectorization_profitable_p)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99017 --- Comment #2 from Richard Biener --- So while this crashes in the new BB costing part the issue this uncovers is that graph partitioning does not merge two partitions that share a vect_external_def SLP node. But the SLP costing performed during SLP analysis walked the whole graph honoring this sharing. In the end we end up with no vector cost entry. It's not so easy to change graph partitioning so for the moment I'll fixup the BB costing to be more forgiving. The way for a real fix is to attach SLP node costings to the individual nodes when doing analysis and only gather them during partition costing. But that's for next stage1.
[Bug tree-optimization/99017] ICE: Segmentation fault (in vect_bb_vectorization_profitable_p)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99017 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-02-09 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Richard Biener --- Mine.
[Bug c++/99016] [9/10/11 Regression] Internal compiler error from decltype of binary operator when one operand is a prvalue function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99016 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c/86134] earlier diagnostic causes followup diagnostic about unknown -Wno-* options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86134 Richard Biener changed: What|Removed |Added CC||vincent-gcc at vinc17 dot net --- Comment #15 from Richard Biener --- *** Bug 99014 has been marked as a duplicate of this bug. ***
[Bug c/99014] -Werror -Wno-foo with foo unrecognized results in an error if another warning is emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99014 Richard Biener changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED Keywords||diagnostic --- Comment #1 from Richard Biener --- As you may have guessed, duplicate. *** This bug has been marked as a duplicate of bug 86134 ***
[Bug middle-end/90075] [7/8 Regression] [AArch64] ICE during RTL pass when member of union passed to copysignf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90075 Richard Biener changed: What|Removed |Added CC||nikita.shulga at gmail dot com --- Comment #10 from Richard Biener --- *** Bug 99012 has been marked as a duplicate of this bug. ***
[Bug c++/99012] gcc-8.4.0 on aarch64 hits internal error during RTL pass: expand if `std::copysign` is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99012 Richard Biener changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Richard Biener --- *** This bug has been marked as a duplicate of bug 90075 ***
[Bug middle-end/99011] Potentially missed optimization. Arrays are created without need
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99011 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-02-09 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Confirmed. The issue is the array accesses remain variable and there's no transform that turns a two-valued variable access into two (constant folded) accesses plus a select. Depending on how expensive it is to load the constants such transform may not always be profitable. Given we're looking for a two-valued variable access it might be tempting to do the transform in VRP where there's also a related PR around deriving a range for the loaded value from the entries of the indexed array (PR80603).
[Bug fortran/99010] [11 Regression] ICE in gfc_dep_resolver, at fortran/dependency.c:2322
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99010 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0 Priority|P3 |P4
[Bug c++/99008] [10/11 Regression] ICE in set_constraints, at cp/constraint.cc:1256
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99008 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |10.3
[Bug libgomp/99005] libgomp runtime does not support AMD GPU offloading for OpenACC directives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99005 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Richard Biener --- .
[Bug c++/96333] [10/11 Regression] Regression on concepts constraint checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96333 David Stone changed: What|Removed |Added CC||david at doublewise dot net --- Comment #5 from David Stone --- *** Bug 98987 has been marked as a duplicate of this bug. ***
[Bug c++/98987] Concept subsumption doesn't work with by-value vs. by-reference parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98987 David Stone changed: What|Removed |Added CC||david at doublewise dot net Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from David Stone --- I agree, this is a duplicate of that other issue. *** This bug has been marked as a duplicate of bug 96333 ***
[Bug preprocessor/96391] [10/11 Regression] internal compiler error: in linemap_compare_locations, at libcpp/line-map.c:1359
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391 --- Comment #10 from Jan Smets --- I have a couple of changes in my own tree. I had a couple of different issues and I don't recall exactly what change was for what specifically. I locally have a revert of 0d48e8779c6a9ac88f5efd1b4a2d40f43ef75faf "Support string locations for C++ in -Wformat (PR c++/56856)" , plus the ugly hack patch from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96940
[Bug c++/99018] New: Comparing address of array element not considered a constant expression in certain contexts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99018
Bug ID: 99018
Summary: Comparing address of array element not considered a
constant expression in certain contexts
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david at doublewise dot net
Target Milestone: ---
The following valid translation unit
```
struct s {
constexpr s() = default;
constexpr s(s const & other) {
if (this == &other) {
}
}
};
constexpr auto f() {
s init[2];
for (auto & element : init) {
s foo = element;
}
return true;
}
static_assert(f());
```
is rejected by gcc with
```
:18:16: error: non-constant condition for static assertion
18 | static_assert(f());
| ~^~
:18:16: in 'constexpr' expansion of 'f()'
:13:11: in 'constexpr' expansion of 's((*(const s*)(& element)))'
:5:26: error: '(((const s*)(& foo)) == (((const s*)(& init)) + 1))' is
not a constant expression
5 | if (this == &other) {
| ~^
Compiler returned: 1
```
See it live: https://godbolt.org/z/xG5dv5
[Bug c++/98944] [modules] Failed to read compiled module with a non-exported partition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98944 Steven Sun changed: What|Removed |Added CC||StevenSun2021 at hotmail dot com --- Comment #1 from Steven Sun --- I met the same problem. - Three days ago, I pull from the repository and then compile the gnu c++ compiler in the devel/c++-modules branch. system: ubuntu-20.04 x86_64 configured with: --disable-multilib I took the same exaple as you, which is in the final working draft n4861 [modules.unit]. I think the compile order should be tu3 tu2 tu1 tu4, because the compiler tells me I cannot import before build. So I compile it as g++ -fmodules-ts -std=c++20 -c 3.cc -o 3.o g++ -fmodules-ts -std=c++20 -c 2.cc -o 2.o g++ -fmodules-ts -std=c++20 -c 1.cc -o 1.o g++ -fmodules-ts -std=c++20 -c 4.cc -o 4.o The compiling for 4.cc got an error -- In module imported at 4.cc:1:1: A: error: failed to read compiled module: Bad file data A: note: compiled module file is ‘gcm.cache/A.gcm’ A: fatal error: returning to the gate for a mechanical issue compilation terminated. -- Then I took a peek into the gcm.cache/A.gcm, using readelf. Found that there's already a section header named bar. So I removed the line `import :Internals;` in 4.cc and it compiles. Anyway, I don't know if that is a bug. Maybe the standard is different from the final working draft. I am not sure.
[Bug c++/98983] SEGV during C++17 variadic template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98983 --- Comment #4 from Alison Chaiken --- The folly source referred to below comes from https://github.com/facebook/folly.git I do not work for F**k and am simply trying to make use of their tracing functionality in their StaticTracepoint.h header.
[Bug fortran/95647] operator(.eq.) and operator(==) treated differently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647 --- Comment #10 from Jerry DeLisle --- Oops, that what I get for doing 16 things at once. sorry.
[Bug tree-optimization/99017] New: ICE: Segmentation fault (in vect_bb_vectorization_profitable_p)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99017
Bug ID: 99017
Summary: ICE: Segmentation fault (in
vect_bb_vectorization_profitable_p)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: powerpc-*-linux-gnu-gcc
gcc-11.0.0-alpha20210207 snapshot (g:3d912941f29c27b2ac7c79b9e7cb2f1150e75758)
ICEs when compiling the following testcase, reduced from
gcc/testsuite/gcc.dg/torture/pr57569.c, w/ -mcpu=power8 -O3 -fno-tree-fre
-ftree-parallelize-loops=2:
int e, f, *d;
void
fn1 (void)
{
int **g[9][6];
int ***h = &g[6][3];
while (e < ~0)
{
for (f = 0; f < 6; f++)
g[e][f] = &d;
e++;
}
**h = 0;
}
% powerpc-e300c3-linux-gnu-gcc-11.0.0 -mcpu=power8 -O3 -fno-tree-fre
-ftree-parallelize-loops=2 -c pfxmw8d8.c
during GIMPLE pass: slp
pfxmw8d8.c: In function 'fn1._loopfn.0':
pfxmw8d8.c:9:12: internal compiler error: Segmentation fault
9 | while (e < ~0)
|^
0xe12d26 crash_signal
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20210207/work/gcc-11-20210207/gcc/toplev.c:327
0x10da66f vec, va_heap,
vl_embed>::operator[](unsigned int)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20210207/work/gcc-11-20210207/gcc/vec.h:890
0x10da66f vec, va_heap,
vl_ptr>::operator[](unsigned int)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20210207/work/gcc-11-20210207/gcc/vec.h:1461
0x10da66f vect_bb_vectorization_profitable_p
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20210207/work/gcc-11-20210207/gcc/tree-vect-slp.c:4433
0x10da66f vect_slp_region
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20210207/work/gcc-11-20210207/gcc/tree-vect-slp.c:4915
0x10da66f vect_slp_bbs
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20210207/work/gcc-11-20210207/gcc/tree-vect-slp.c:5043
0x10dc06c vect_slp_function(function*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20210207/work/gcc-11-20210207/gcc/tree-vect-slp.c:5129
0x10e282a execute
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20210207/work/gcc-11-20210207/gcc/tree-vectorizer.c:1449
[Bug c++/99016] [9/10/11 Regression] Internal compiler error from decltype of binary operator when one operand is a prvalue function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99016 Marek Polacek changed: What|Removed |Added Summary|Internal compiler error |[9/10/11 Regression] |from decltype of binary |Internal compiler error |operator when one operand |from decltype of binary |is a prvalue function call |operator when one operand ||is a prvalue function call Keywords||ice-on-valid-code CC||jason at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Last reconfirmed||2021-02-09 Target Milestone|--- |9.4 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- ICEs since r240845: commit b7558a2c1f87e374c48fa2be8e3ab93e1b3c68b0 Author: Jason Merrill Date: Thu Oct 6 17:24:40 2016 -0400 C++17 copy elision improvements. * call.c (build_temp, convert_like_real): Don't re-copy TARGET_EXPR. Handle packed fields. (build_x_va_arg): Wrap it in a TARGET_EXPR. (build_over_call): Add sanity check. * cvt.c (early_elide_copy): New. (ocp_convert): Use it. * except.c (build_throw): Use it. * init.c (get_nsdmi): Put back the TARGET_EXPR. (expand_default_init): Call early_elide_copy. * typeck.c (cp_build_modify_expr): Call early_elide_copy.
[Bug c++/99016] New: Internal compiler error from decltype of binary operator when one operand is a prvalue function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99016
Bug ID: 99016
Summary: Internal compiler error from decltype of binary
operator when one operand is a prvalue function call
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david at doublewise dot net
Target Milestone: ---
The following valid translation unit
```
struct integer {};
integer f();
int operator+(integer, integer);
using max_type = decltype(f() + f());
```
Causes gcc to crash with
```
:7:35: internal compiler error: in build_over_call, at cp/call.c:9244
7 | using max_type = decltype(f() + f());
| ^
0x1ce6f09 internal_error(char const*, ...)
???:0
0x6b6f43 fancy_abort(char const*, int, char const*)
???:0
0x6df89c build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
???:0
0x6e1000 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
???:0
0x6e2760 build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node**, int)
???:0
0x9c121d build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node**, int)
???:0
0x8de23d c_parse_file()
???:0
0xa5b7c2 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/96905] [10/11 Regression] ICE with consteval function: internal compiler error: in cp_gimplify_expr, at cp/cp-gimplify.c:827
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96905 --- Comment #6 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:57d705da0b98f5d398c4b8f9bd76fe8ad98e13bc commit r11-7143-g57d705da0b98f5d398c4b8f9bd76fe8ad98e13bc Author: Jason Merrill Date: Mon Feb 8 17:16:14 2021 -0500 c++: consteval and explicit instantiation [PR96905] Normally, an explicit instantiation means we want to write out the instantiation. But not for a consteval function. gcc/cp/ChangeLog: PR c++/96905 * pt.c (mark_decl_instantiated): Exit early if consteval. gcc/testsuite/ChangeLog: PR c++/96905 * g++.dg/cpp2a/consteval-expinst1.C: New test.
[Bug c++/98326] [10/11 Regression] ICE: in create_tmp_var, at gimple-expr.c:482, converting stateless generic-lambda to function pointer since r10-599-gc652ff8312433483
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98326 --- Comment #3 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:bdbca69e0720fa9062fe71782235141f629ae006 commit r11-7142-gbdbca69e0720fa9062fe71782235141f629ae006 Author: Jason Merrill Date: Mon Feb 8 17:04:03 2021 -0500 c++: generic lambda, fn* conv, empty class [PR98326] Here, in the thunk returned from the captureless lambda conversion to pointer-to-function, we try to pass through invisible reference parameters by reference, without doing a copy. The empty class copy optimization was messing that up. gcc/cp/ChangeLog: PR c++/98326 PR c++/20408 * cp-gimplify.c (simple_empty_class_p): Don't touch an invisiref parm. gcc/testsuite/ChangeLog: PR c++/98326 * g++.dg/cpp1y/lambda-generic-empty1.C: New test.
[Bug middle-end/20408] Unnecessary code generated for empty structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20408 --- Comment #24 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:bdbca69e0720fa9062fe71782235141f629ae006 commit r11-7142-gbdbca69e0720fa9062fe71782235141f629ae006 Author: Jason Merrill Date: Mon Feb 8 17:04:03 2021 -0500 c++: generic lambda, fn* conv, empty class [PR98326] Here, in the thunk returned from the captureless lambda conversion to pointer-to-function, we try to pass through invisible reference parameters by reference, without doing a copy. The empty class copy optimization was messing that up. gcc/cp/ChangeLog: PR c++/98326 PR c++/20408 * cp-gimplify.c (simple_empty_class_p): Don't touch an invisiref parm. gcc/testsuite/ChangeLog: PR c++/98326 * g++.dg/cpp1y/lambda-generic-empty1.C: New test.
[Bug c++/97566] [[no_unique_address]] causes miscompiles when mixed with EBO in constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97566 --- Comment #4 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:a8dd2b3e96590ceccead63d28fc91c956a5f1a73 commit r11-7141-ga8dd2b3e96590ceccead63d28fc91c956a5f1a73 Author: Jason Merrill Date: Mon Feb 8 15:56:11 2021 -0500 c++: constexpr, union, and no_unique_address [PR98994] My second patch for 97566 omits nested CONSTRUCTORs for empty fields, but we do want them for empty union members. gcc/cp/ChangeLog: PR c++/98994 PR c++/97566 * constexpr.c (cxx_eval_store_expression): Only skip empty fields in RECORD_TYPE. gcc/testsuite/ChangeLog: PR c++/98994 * g++.dg/cpp2a/no_unique_address12.C: New test.
[Bug c++/98994] [11 Regression] Empty type with [[no_unique_address]] in union with constructor is not a constant expression since r11-6918
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98994 --- Comment #2 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:a8dd2b3e96590ceccead63d28fc91c956a5f1a73 commit r11-7141-ga8dd2b3e96590ceccead63d28fc91c956a5f1a73 Author: Jason Merrill Date: Mon Feb 8 15:56:11 2021 -0500 c++: constexpr, union, and no_unique_address [PR98994] My second patch for 97566 omits nested CONSTRUCTORs for empty fields, but we do want them for empty union members. gcc/cp/ChangeLog: PR c++/98994 PR c++/97566 * constexpr.c (cxx_eval_store_expression): Only skip empty fields in RECORD_TYPE. gcc/testsuite/ChangeLog: PR c++/98994 * g++.dg/cpp2a/no_unique_address12.C: New test.
[Bug inline-asm/99015] New: ICE: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99015
Bug ID: 99015
Summary: ICE: Max. number of generated reload insns per insn is
achieved (90)
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: zhan3299 at purdue dot edu
Target Milestone: ---
Another inline-asm issue causes an ICE.
--- poc.c starts ---
int main() {
asm("" : : "fq"(.100));
}
--- poc.c ends ---
The version of GCC is 10.2.0 x86-64, and running 'gcc -O1 poc.c ' can trigger
the ICE.
--- error trace starts ---
$ gcc -O1 poc.c
during RTL pass: reload
test.c: In function ‘main’:
test.c:3:1: internal compiler error: maximum number of generated reload insns
per insn achieved (90)
3 | }
| ^
0x9fb0c0 lra_constraints(bool)
../../gcc/gcc/lra-constraints.c:4952
0x9e9314 lra(_IO_FILE*)
../../gcc/gcc/lra.c:2440
0x9a7201 do_reload
../../gcc/gcc/ira.c:5523
0x9a7201 execute
../../gcc/gcc/ira.c:5709
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c/99014] New: -Werror -Wno-foo with foo unrecognized results in an error if another warning is emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99014
Bug ID: 99014
Summary: -Werror -Wno-foo with foo unrecognized results in an
error if another warning is emitted
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Consider the following tst.c file:
int f (void)
{
#ifdef F
int i;
#endif
return 0;
}
With gcc-9 (Debian 9.3.0-22) 9.3.0:
zira:~> gcc-9 -Wextra -Werror -Wno-error=unused-variable -Wno-foo -c tst.c
zira:~> gcc-9 -Wextra -Werror -Wno-error=unused-variable -Wno-foo -c tst.c -DF
tst.c: In function ‘f’:
tst.c:4:7: warning: unused variable ‘i’ [-Wunused-variable]
4 | int i;
| ^
tst.c: At top level:
cc1: error: unrecognized command line option ‘-Wno-foo’ [-Werror]
cc1: all warnings being treated as errors
while -Wno-foo should be ignored as usual.
Ditto with gcc-8 (Debian 8.4.0-7) 8.4.0.
With gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, this is OK, -Wno-foo just emits
a non-fatal note:
zira:~> gcc-10 -Wextra -Werror -Wno-error=unused-variable -Wno-foo -c tst.c
zira:~> gcc-10 -Wextra -Werror -Wno-error=unused-variable -Wno-foo -c tst.c -DF
tst.c: In function ‘f’:
tst.c:4:7: warning: unused variable ‘i’ [-Wunused-variable]
4 | int i;
| ^
tst.c: At top level:
cc1: note: unrecognized command-line option ‘-Wno-foo’ may have been intended
to silence earlier diagnostics
[Bug tree-optimization/98984] Failure to optimize out float conversion from long long->float->char conversion on -fno-trapping-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98984 Gabriel Ravier changed: What|Removed |Added Summary|Failure to optimize out |Failure to optimize out |float conversion from long |float conversion from long |long->float->char |long->float->char |conversion |conversion on ||-fno-trapping-math --- Comment #3 from Gabriel Ravier --- Hm, so that looks to be one more divergeance between Clang and GCC: -ftrapping-math is the default on GCC, while Clang has -fno-trapping-math as the default (note: using -ftrapping-math makes LLVM not do the optimization). The transformation is still not done on GCC with -fno-trapping-math though, so I'll keep the bug open.
[Bug preprocessor/96391] [10/11 Regression] internal compiler error: in linemap_compare_locations, at libcpp/line-map.c:1359
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391 David Malcolm changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #9 from David Malcolm --- I tried reproducing this using the .ii file (albeit with trunk), but it's not triggering for me. (In reply to Michael Cronenworth from comment #0) [...] > When I compile it with '-save-temps' to get the preprocessed file no error > occurs. No error occurs if I compile the preprocessed file either. ...which suggests to me that maybe this is in a diagnostic that relies on re-reading the sources, such as -Wmisleading-indentation. Alternatively, the crash is in linemap_compare_locations. This is used by linemap_location_before_p, which is used by -Wuninitialized and -Wmaybe-uninitialized. So those could be a few warnings to try disabling to see if we can narrow this down; try adding: -Wno-misleading-indentation -Wno-uninitialized -Wno-maybe-uninitialized and see if one of those fixes it. Michael: are you able to invoke the crashing command under gdb? Adding -wrapper gdb,--args to the g++ invocation will make it invoke cc1plus under the debugger, from which you can get a backtrace. (gdb) run [...hopefully the process crashes...] (gdb) bt and hopefully will shed light on where it's crashing. Hope this is helpful
[Bug tree-optimization/98984] Failure to optimize out float conversion from long long->float->char conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98984 --- Comment #2 from joseph at codesourcery dot com --- Under Annex F, conversion of an out-of-range floating-point value to an integer type other than _Bool produces an unspecified value with the "invalid" exception raised. Losing that exception (and "inexact" for unsigned long long values not representable exactly in float) makes such a transformation questionable unless -fno-trapping-math is used.
[Bug target/88197] ICE in decompose_normal_address, at rtlanal.c:6381
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88197 Peter Bergner changed: What|Removed |Added Ever confirmed|0 |1 CC||bergner at gcc dot gnu.org Last reconfirmed||2021-02-08 Status|UNCONFIRMED |NEW --- Comment #2 from Peter Bergner --- Hmmm, I was unaware of this bug, but it's probably mine. Confirmed. I'll have a look.
[Bug c++/99013] New: std::source_location::function_name should return same result in constexpr mode and non-constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99013
Bug ID: 99013
Summary: std::source_location::function_name should return same
result in constexpr mode and non-constexpr
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hanicka at hanicka dot net
Target Milestone: ---
Hi found out std::source_location is returning different result in constexpr:
```
#include
template
constexpr std::string_view get_object_name1()
{
/*constexpr*/ const char * ptr =
std::source_location::current().function_name();
return ptr;
}
template
constexpr std::string_view get_object_name2()
{
constexpr const char * ptr =
std::source_location::current().function_name();
return ptr;
}
void foo() { }
```
when called `get_object_name1` it returns `constexpr std::string_view
get_object_name1() [with auto Object = foo; std::string_view =
std::basic_string_view]`
but when called `get_object_name2` it returns `constexpr std::string_view
get_object_name2()`
the difference is the BUG (missing `[with auto Object = foo; std::string_view =
std::basic_string_view]`)
error with latest trunk on compiler-explorer.com
https://compiler-explorer.com/z/4e8Gd1
[Bug c++/98983] SEGV during C++17 variadic template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98983 --- Comment #3 from Alison Chaiken --- The folly source referred to below comes from https://github.com/facebook/folly.git I do not work for F**k and am simply trying to make use of their tracing functionality in their StaticTracepoint.h header.
[Bug c++/98983] SEGV during C++17 variadic template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98983 --- Comment #2 from Alison Chaiken --- Created attachment 50147 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50147&action=edit compressed preprocessor output
[Bug c++/99012] gcc-8.4.0 on aarch64 hits internal error during RTL pass: expand if `std::copysign` is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99012 --- Comment #3 from Sebastian Pop --- I do not see the bug with today's cc1plus from origin/releases/gcc-8
[Bug rtl-optimization/98692] Unitialized Values reported only with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692 --- Comment #11 from Will Schmidt --- (In reply to Mark Wielaard from comment #10) > (In reply to Will Schmidt from comment #9) > > (In reply to Segher Boessenkool from comment #5) > > > Have you tried a new valgrind? > > > > > > Either this is (or was) a known problem in valgrind, or it is related to > > > one. Cc:ing Aaron, he might know more (he wrote the GCC optimisations > > > that expose the problem). > > > > > > I've recreated against new (built out of upstream git) valgrind: > > with --track-origins=yes > > > > > > ==37507== > > argv[0]=./a.out > > ==37507== Use of uninitialised value of size 8 > > ==37507==at 0x1618: main (pr9862.C:16) > > ==37507== Uninitialised value was created by a stack allocation > > ==37507==at 0x17D4: isVariable(char*) (pr9862.C:5) > > Trying to get hold of a ppc64 setup. But could you try with --vgdb-error=0 > and then (in another window) gdb ./a.out and target remote | vgdb and > continue till you get the TRAP. Then disassamble so we can see the exact > instruction that generates the use of uninitialised value? Yes. so this traps on a ld instruction upon the return from the isVariable call. As seen below here: Window #1: ==79608== argv[0]=./a.out ==79608== Use of uninitialised value of size 8 ==79608==at 0x1618: main (pr9862.C:16) ==79608== Uninitialised value was created by a stack allocation ==79608==at 0x17D4: isVariable(char*) (pr9862.C:5) ==79608== ==79608== (action on error) vgdb me ... Window #2: (gdb) target remote | vgdb Remote debugging using | vgdb relaying data between gdb and process 79608 warning: remote target does not support file transfer, attempting to access files from local filesystem. Reading symbols from /lib64/ld64.so.2... (No debugging symbols found in /lib64/ld64.so.2) 0x04001720 in ?? () from /lib64/ld64.so.2 (gdb) (gdb) set disassemble-next-line on (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. main (argc=, argv=0x1fff00e8a8) at pr9862.C:16 16len = __builtin_strlen (argv[1]); => 0x1618 : 08 00 7f e8 ld r3,8(r31) 0x161c : a5 ff ff 4b bl 0x15c0 <0037.plt_call.strlen@@GLIBC_2.17> 0x1620 : 18 00 41 e8 ld r2,24(r1) 0x1624 : 00 00 00 60 nop 0x1628 : 70 00 21 38 addi r1,r1,112 0x162c : 50 81 62 90 stw r3,-32432(r2) (gdb) disas Dump of assembler code for function main(int, char**): 0x15e0 <+0>: lis r2,4098 0x15e4 <+4>: addir2,r2,32512 0x15e8 <+8>: mflrr0 0x15ec <+12>:std r31,-8(r1) 0x15f0 <+16>:addis r3,r2,-2 0x15f4 <+20>:mr r31,r4 0x15f8 <+24>:addir3,r3,-29882 0x15fc <+28>:std r0,16(r1) 0x1600 <+32>:stdur1,-112(r1) 0x1604 <+36>:ld r4,0(r4) 0x1608 <+40>:bl 0x1580 <0037.plt_call.printf@@GLIBC_2.17> 0x160c <+44>:ld r2,24(r1) 0x1610 <+48>:ld r3,0(r31) 0x1614 <+52>:bl 0x17c4 => 0x1618 <+56>:ld r3,8(r31) 0x161c <+60>:bl 0x15c0 <0037.plt_call.strlen@@GLIBC_2.17> 0x1620 <+64>:ld r2,24(r1) 0x1624 <+68>:nop 0x1628 <+72>:addir1,r1,112 0x162c <+76>:stw r3,-32432(r2) 0x1630 <+80>:li r3,0 0x1634 <+84>:b 0x198c <_restgpr0_31> 0x1638 <+88>:.long 0x0 0x163c <+92>:.long 0x1000900 0x1640 <+96>:.long 0x180 End of assembler dump. (gdb) WIndow#1:
[Bug c++/99012] gcc-8.4.0 on aarch64 hits internal error during RTL pass: expand if `std::copysign` is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99012 Sebastian Pop changed: What|Removed |Added CC||spop at gcc dot gnu.org --- Comment #2 from Sebastian Pop --- I see the bug with $ gcc-8 --version gcc-8 (Ubuntu/Linaro 8.4.0-1ubuntu1~18.04) 8.4.0
[Bug libgomp/99005] libgomp runtime does not support AMD GPU offloading for OpenACC directives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99005 --- Comment #2 from Kiril Dichev --- Yes, I can confirm that there seems to be an underlying issue with permissions, similar to the link you posted (rocminfo gives me the same error). Indeed, I was referring to compilation with PGI on an Nvidia system. Looks like this is not a bug. Sorry.
[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #30 from Mikael Pettersson --- Patch has been posted: https://gcc.gnu.org/pipermail/gcc-patches/2021-February/564990.html
[Bug rtl-optimization/98692] Unitialized Values reported only with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692 --- Comment #10 from Mark Wielaard --- (In reply to Will Schmidt from comment #9) > (In reply to Segher Boessenkool from comment #5) > > Have you tried a new valgrind? > > > > Either this is (or was) a known problem in valgrind, or it is related to > > one. Cc:ing Aaron, he might know more (he wrote the GCC optimisations > > that expose the problem). > > > I've recreated against new (built out of upstream git) valgrind: > with --track-origins=yes > > > ==37507== > argv[0]=./a.out > ==37507== Use of uninitialised value of size 8 > ==37507==at 0x1618: main (pr9862.C:16) > ==37507== Uninitialised value was created by a stack allocation > ==37507==at 0x17D4: isVariable(char*) (pr9862.C:5) Trying to get hold of a ppc64 setup. But could you try with --vgdb-error=0 and then (in another window) gdb ./a.out and target remote | vgdb and continue till you get the TRAP. Then disassamble so we can see the exact instruction that generates the use of uninitialised value?
[Bug c++/99012] gcc-8.4.0 on aarch64 hits internal error during RTL pass: expand if `std::copysign` is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99012 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2021-02-08 --- Comment #1 from ktkachov at gcc dot gnu.org --- What GCC version are you using? (gcc -v) I can't reproduce the ICE and it looks at first glance like it could be a duplicate of the already-fixed PR90075
[Bug rtl-optimization/98692] Unitialized Values reported only with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692 Will Schmidt changed: What|Removed |Added CC||willschm at gcc dot gnu.org --- Comment #9 from Will Schmidt --- (In reply to Segher Boessenkool from comment #5) > Have you tried a new valgrind? > > Either this is (or was) a known problem in valgrind, or it is related to > one. Cc:ing Aaron, he might know more (he wrote the GCC optimisations > that expose the problem). I've recreated against new (built out of upstream git) valgrind: with --track-origins=yes ==37507== argv[0]=./a.out ==37507== Use of uninitialised value of size 8 ==37507==at 0x1618: main (pr9862.C:16) ==37507== Uninitialised value was created by a stack allocation ==37507==at 0x17D4: isVariable(char*) (pr9862.C:5)
[Bug c++/98990] [10/11 Regression] ICE when two overloaded functions return `auto &&` and one accepts an `auto` parameter since r10-6571-ga6ee556c7659877b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98990 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org --- Comment #4 from Patrick Palka --- (In reply to Jason Merrill from comment #3) > (In reply to Martin Liška from comment #2) > > With -fchecking, it started with a6ee556c7659877b. > > i.e. r10-6571 > > The problem is that splice_late_return_type is changing the TREE_TYPE of a > REFERENCE_TYPE without also updating its TYPE_CANONICAL, which breaks; we > need to rebuild the type instead. I expect that tsubst would do the trick, > as in do_auto_deduction. Want to take this, Patrick? Ah, that makes sense. Yes, I'll take it :)
[Bug c++/98326] [10/11 Regression] ICE: in create_tmp_var, at gimple-expr.c:482, converting stateless generic-lambda to function pointer since r10-599-gc652ff8312433483
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98326 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/98990] [10/11 Regression] ICE when two overloaded functions return `auto &&` and one accepts an `auto` parameter since r10-6571-ga6ee556c7659877b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98990 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|jason at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #3 from Jason Merrill --- (In reply to Martin Liška from comment #2) > With -fchecking, it started with a6ee556c7659877b. i.e. r10-6571 The problem is that splice_late_return_type is changing the TREE_TYPE of a REFERENCE_TYPE without also updating its TYPE_CANONICAL, which breaks; we need to rebuild the type instead. I expect that tsubst would do the trick, as in do_auto_deduction. Want to take this, Patrick?
[Bug middle-end/99011] Potentially missed optimization. Arrays are created without need
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99011 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Component|c |middle-end Keywords||missed-optimization
[Bug c++/98990] [10/11 Regression] ICE when two overloaded functions return `auto &&` and one accepts an `auto` parameter since r10-6571-ga6ee556c7659877b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98990 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug fortran/98979] [11 regression] ICE in several tests cases after r11-7112
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98979 --- Comment #5 from seurer at gcc dot gnu.org --- For completeness, the new test case added for this in g:b2d84e9f9cccbe4ee662f7002b83105629d09939, r11-7113 also fails: make -k check-gcc RUNTESTFLAGS="goacc.exp=gfortran.dg/goacc/derived-chartypes-1.f90" FAIL: gfortran.dg/goacc/derived-chartypes-1.f90 -O (internal compiler error) FAIL: gfortran.dg/goacc/derived-chartypes-1.f90 -O (test for excess errors) # of unexpected failures2
[Bug c++/98994] [11 Regression] Empty type with [[no_unique_address]] in union with constructor is not a constant expression since r11-6918
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98994 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/98995] [11 Regression] Copy elision not applied to members declared with [[no_unique_address]]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98995 Jason Merrill changed: What|Removed |Added Last reconfirmed||2021-02-08 Status|UNCONFIRMED |SUSPENDED Ever confirmed|0 |1 --- Comment #2 from Jason Merrill --- This was a deliberate change. This language/ABI issue is tracked at https://wg21.link/cwg2403 and https://github.com/itanium-cxx-abi/cxx-abi/issues/107 The problem is that we can't safely initialize a base or potentially-overlapping member from the result of a function call, at least without a major ABI break, because it might clobber other data allocated into the tail padding.
[Bug c++/99012] New: gcc-8.4.0 on aarch64 hits internal error during RTL pass: expand if `std::copysign` is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99012
Bug ID: 99012
Summary: gcc-8.4.0 on aarch64 hits internal error during RTL
pass: expand if `std::copysign` is used
Product: gcc
Version: 8.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nikita.shulga at gmail dot com
Target Milestone: ---
Created attachment 50146
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50146&action=edit
gzipped preprocessed file that hits the issue
To repro, run `g++-8 -O3 -c BinaryOpsKernel.cpp.DEFAULT.E.cpp` and it will fail
with:
```
/usr/include/c++/8/cmath: In function
‘at::native::{anonymous}::cpu_kernel(at::TensorIteratorBase&, func_t&&) [with
func_t =
at::native::{anonymous}::div_floor_kernel(at::TensorIterator&)::]’:
/usr/include/c++/8/cmath:1287:31: internal compiler error: Segmentation fault
{ return __builtin_copysignf(__x, __y); }
~~~^~
```
[Bug c++/99000] [modules] declaration std::__copy_move_a2 conflicts with import
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99000
Nathan Sidwell changed:
What|Removed |Added
Status|UNCONFIRMED |SUSPENDED
Last reconfirmed||2021-02-08
Ever confirmed|0 |1
--- Comment #1 from Nathan Sidwell ---
You're hitting this:
@emph{G++'s modules support is not complete.} Other than bugs, the
known missing pieces are:
@item Textual merging of reachable GM entities
Entities may be multiply defined across different header-units.
These must be de-duplicated, and this is implemented across imports,
or when an import redefines a textually-defined entity. However the
reverse is not implemented---textually redefining an entity that has
been defined in an imported header-unit. A redefinition error is
emitted.
[Bug libgomp/99005] libgomp runtime does not support AMD GPU offloading for OpenACC directives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99005 --- Comment #1 from Tobias Burnus --- (In reply to Kiril Dichev from comment #0) > Code runs fine without GPU offloading, or with offloading with PGI compiler. With PGI + offloading: that's for that AMD Vega machine or for some Nvidia system? > Sample code with single OpenACC directive in for loop The example code just contains only a module without a main program. Hence, I added at the end: use mymodule implicit none (external, type) call init call do_work call terminate end Using that on a gfx906 Vega 20 with GCC 11.0.0 20210203 and -march=gfx906 – and works fine. I have now also tried it with: gcc version 10.2.1 20210206 – same result. * * * Especially assuming that AMD system is not the same system as the system used with the PGI compiler: If I look for HSA_STATUS_ERROR_OUT_OF_RESOURCES, I run into https://github.com/RadeonOpenCompute/ROCm/issues/1080 That person did have such an error due to permission problems. I assume that it works on your side, but just to check: Does /opt/rocm/bin/rocminfo work? If it does, does the program as above work (your module + the lines by me to run it)? Are there more messages? Which compiler version did you use? Is this a Linux vendor compiler (which one?), some pre-compiled compiler or self compiled?
[Bug c/99011] Potentially missed optimization. Arrays are created without need
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99011 Piotr changed: What|Removed |Added Version|10.2.1 |10.2.0 --- Comment #1 from Piotr --- https://godbolt.org/z/E18djs
[Bug c/99011] New: Potentially missed optimization. Arrays are created without need
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99011
Bug ID: 99011
Summary: Potentially missed optimization. Arrays are created
without need
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pj at hugeone dot co.uk
Target Milestone: ---
Consider the code:
```
int bar(int N)
{
return N > 10 ? 14 : 8;
}
int foo(int N)
{
return (const int[]){8, 14}[N > 10];
}
int zoo(int N)
{
int a[] = {8,14};
return a[N > 10];
}
int boo(int N)
{
const static int a[] = {8,14};
return a[N > 10];
}
```
IMO in all cases the generated code should be the same as generated for
function bar. IMO arrays can be optimized out.
Compiled with -O3
foo:
mov rax, QWORD PTR .LC0[rip]
mov QWORD PTR [rsp-8], rax
xor eax, eax
cmp edi, 10
setgal
mov eax, DWORD PTR [rsp-8+rax*4]
ret
bar:
cmp edi, 10
mov edx, 8
mov eax, 14
cmovle eax, edx
ret
zoo:
mov rax, QWORD PTR .LC0[rip]
mov QWORD PTR [rsp-8], rax
xor eax, eax
cmp edi, 10
setgal
mov eax, DWORD PTR [rsp-8+rax*4]
ret
boo:
xor eax, eax
cmp edi, 10
setgal
mov eax, DWORD PTR a.0[0+rax*4]
ret
a.0:
.long 8
.long 14
.LC0:
.long 8
.long 14
gcc -O3 --verbose:
Using built-in specs.
COLLECT_GCC=/opt/compiler-explorer/gcc-10.2.0/bin/gcc
Target: x86_64-linux-gnu
Configured with: ../gcc-10.2.0/configure
--prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap
--enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --enable-clocale=gnu
--enable-languages=c,c++,fortran,ada,go,d --enable-ld=yes --enable-gold=yes
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-linker-build-id
--enable-lto --enable-plugins --enable-threads=posix
--with-pkgversion=Compiler-Explorer-Build
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (Compiler-Explorer-Build)
COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-g' '-o' './output.s'
'-masm=intel' '-S' '-v' '-O3' '-mtune=generic' '-march=x86-64'
/opt/compiler-explorer/gcc-10.2.0/bin/../libexec/gcc/x86_64-linux-gnu/10.2.0/cc1
-quiet -v -imultiarch x86_64-linux-gnu -iprefix
/opt/compiler-explorer/gcc-10.2.0/bin/../lib/gcc/x86_64-linux-gnu/10.2.0/
-quiet -dumpbase example.c -masm=intel -mtune=generic -march=x86-64
-auxbase-strip ./output.s -g -O3 -version -fdiagnostics-color=always -o
./output.s
GNU C17 (Compiler-Explorer-Build) version 10.2.0 (x86_64-linux-gnu)
compiled by GNU C version 7.5.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version isl-0.18-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/opt/compiler-explorer/gcc-10.2.0/bin/../lib/gcc/x86_64-linux-gnu/10.2.0/../../../../x86_64-linux-gnu/include"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-10.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/10.2.0/include"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-10.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/10.2.0/include-fixed"
ignoring nonexistent directory
"/opt/compiler-explorer/gcc-10.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/10.2.0/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/opt/compiler-explorer/gcc-10.2.0/bin/../lib/gcc/x86_64-linux-gnu/10.2.0/include
/opt/compiler-explorer/gcc-10.2.0/bin/../lib/gcc/x86_64-linux-gnu/10.2.0/include-fixed
/usr/local/include
/opt/compiler-explorer/gcc-10.2.0/bin/../lib/gcc/../../include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
GNU C17 (Compiler-Explorer-Build) version 10.2.0 (x86_64-linux-gnu)
compiled by GNU C version 7.5.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version isl-0.18-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 870fa0f1a93c5f0ff6fd5ef23d839e5a
COMPILER_PATH=/opt/compiler-explorer/gcc-10.2.0/bin/../libexec/gcc/x86_64-linux-gnu/10.2.0/:/opt/compiler-explorer/gcc-10.2.0/bin/../libexec/gcc/x86_64-linux-gnu/:/opt/compiler-explorer/gcc-10.2.0/bin/../libexec/gcc/:/opt/compiler-explorer/gcc-10.2.0/bin/../lib/gcc/x86_64-linux-gnu/10.2.0/../../../../x86_64-linux-gnu/bin/
LIBRARY_PATH=/opt/compiler-explorer/gcc-10.2.0/bin/../lib/gcc/x86_64-linux-gnu/10.2.0/:/opt/compiler-explorer/gcc-10.2.0/bin/../lib/gcc/x86_64-linux-gnu/:/opt/compiler-ex
[Bug libstdc++/37475] [DR 382] codecvt::do_in/do_out functions return "ok" when the output sequence has zero length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37475 Kristian Spangsege changed: What|Removed |Added CC||kristian.spangsege at gmail dot co ||m --- Comment #5 from Kristian Spangsege --- This bug still exists in GCC 10.2, while libc++ (clang) appears to do the right thing. Specifically, when passing a nonzero amount of data (from_end > from) to std::codecvt::out(), but an empty output buffer (to_end == to), the return value is "ok". According to the C++ standard (C++17), the correct return value is "partial". This appears to happen regardless of locale. In particular, it happens in the C locale. As far as I can tell, http://cplusplus.github.io/LWG/lwg-closed.html#382 is not relevant here, because the current standard text is clear (C++17), and http://cplusplus.github.io/LWG/lwg-closed.html#382 has status NAD, which I assume means "not a defect". Jonathan, let me know if I am missing something.
[Bug middle-end/98465] [11 Regression] Bogus -Wstringop-overread with -std=gnu++20 -O2 and std::string::insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465 --- Comment #29 from Jakub Jelinek --- Created attachment 50145 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50145&action=edit gcc11-pr98465.patch Yet another libstdc++ change that makes the warning go away, but doesn't actually change the generated code - in GIMPLE we end up with more stmts than before but RTL optimizations once we lose distinction on what is a pointer and what is just an offset added to it optimize those differences away.
[Bug c++/99009] [9/10/11 Regression] ICE in type_dependent_expression_p, at cp/pt.c:27265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99009 --- Comment #2 from Marek Polacek --- Not a duplicate of bug 97034 but they might be related.
[Bug target/98997] Linking mismatched -fcf-protection objects generates incorrect code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98997 --- Comment #6 from H.J. Lu --- (In reply to Andy Lutomirski from comment #4) > I should add: on brief inspection, that patch looks like an ABI break for > -fcf-protection=none True if __builtin_longjmp and __builtin_setjmp are compiled by different compilers.
[Bug c++/99009] [9/10/11 Regression] ICE in type_dependent_expression_p, at cp/pt.c:27265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99009 Marek Polacek changed: What|Removed |Added Target Milestone|--- |9.4 Priority|P3 |P2 Ever confirmed|0 |1 Keywords||ice-on-valid-code Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-02-08 CC||mpolacek at gcc dot gnu.org Summary|[11 Regression] ICE in |[9/10/11 Regression] ICE in |type_dependent_expression_p |type_dependent_expression_p |, at cp/pt.c:27265 |, at cp/pt.c:27265 --- Comment #1 from Marek Polacek --- Started with r267533 so mine.
[Bug target/98997] Linking mismatched -fcf-protection objects generates incorrect code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98997 --- Comment #5 from H.J. Lu --- (In reply to Andy Lutomirski from comment #3) > What is -fcf-protection=stack actually supposed to do as compared to It is -fcf-protection=return. > -fcf-protection=none? Is it valid to run code compiled with > -fcf-protection=none with SHSTK enabled? If so, then I wonder why No. The binary will crash. > -fcf-protection=stack exists at all. If not, then I'm wondering why your > patch seems to be effectively hardcoding "stack" mode for SJLJ? > Correct.
[Bug fortran/99010] New: [11 Regression] ICE in gfc_dep_resolver, at fortran/dependency.c:2322
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99010 Bug ID: 99010 Summary: [11 Regression] ICE in gfc_dep_resolver, at fortran/dependency.c:2322 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: --- This changed recently, between 20210131 and 20210207 : $ cat z1.f90 program p integer :: x[*] x = this_image() if ( this_image() == 2 ) then x = x[1] end if end $ gfortran-11-20210131 -c z1.f90 -fcoarray=lib $ $ gfortran-11-20210207 -c z1.f90 -fcoarray=lib z1.f90:5:14: 5 | x = x[1] | 1 internal compiler error: in gfc_dep_resolver, at fortran/dependency.c:2322 0x72b427 gfc_dep_resolver(gfc_ref*, gfc_ref*, gfc_reverse*, bool) ../../gcc/fortran/dependency.c:2322 0x783aa8 conv_caf_send ../../gcc/fortran/trans-intrinsic.c:1952 0x78b3d5 gfc_conv_intrinsic_subroutine(gfc_code*) ../../gcc/fortran/trans-intrinsic.c:12442 0x739be2 trans_code ../../gcc/fortran/trans.c:1981 0x7a58d5 gfc_trans_if_1 ../../gcc/fortran/trans-stmt.c:1475 0x7ad46a gfc_trans_if(gfc_code*) ../../gcc/fortran/trans-stmt.c:1507 0x739c87 trans_code ../../gcc/fortran/trans.c:2010 0x7602d4 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6880 0x6e6c26 translate_all_program_units ../../gcc/fortran/parse.c:6351 0x6e6c26 gfc_parse_file() ../../gcc/fortran/parse.c:6620 0x732e7f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug c++/99009] New: [11 Regression] ICE in type_dependent_expression_p, at cp/pt.c:27265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99009
Bug ID: 99009
Summary: [11 Regression] ICE in type_dependent_expression_p, at
cp/pt.c:27265
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed between 20200621 and 20200628 :
(presumably related to pr97034)
$ cat z1.cc
template struct B
{
B (int = A()) {}
template struct A;
};
$ cat z2.cc
template struct A
{
template struct B;
A () { B c; };
};
$ g++-11-20210207 -c z1.cc
z1.cc:3:14: internal compiler error: in type_dependent_expression_p, at
cp/pt.c:27265
3 | B (int = A()) {}
| ^
0x7aacd8 type_dependent_expression_p(tree_node*)
../../gcc/cp/pt.c:27264
0x7b7ca4 maybe_instantiate_noexcept(tree_node*, int)
../../gcc/cp/pt.c:25549
0x6eae12 mark_used(tree_node*, int)
../../gcc/cp/decl2.c:5610
0x80d6d2 cp_build_addr_expr_1
../../gcc/cp/typeck.c:6518
0x6664e3 build_addr_func(tree_node*, int)
../../gcc/cp/call.c:285
0x673eab build_over_call
../../gcc/cp/call.c:8763
0x675da7 build_new_function_call(tree_node*, vec**, int)
../../gcc/cp/call.c:4689
0x7b2a9a do_class_deduction
../../gcc/cp/pt.c:29323
0x7b2a9a do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
../../gcc/cp/pt.c:29420
0x81c535 build_functional_cast_1
../../gcc/cp/typeck2.c:2208
0x81c535 build_functional_cast(unsigned int, tree_node*, tree_node*, int)
../../gcc/cp/typeck2.c:2308
0x772977 cp_parser_functional_cast
../../gcc/cp/parser.c:30553
0x783bd2 cp_parser_postfix_expression
../../gcc/cp/parser.c:7427
0x793d35 cp_parser_unary_expression
../../gcc/cp/parser.c:8818
0x76d96f cp_parser_cast_expression
../../gcc/cp/parser.c:9722
0x76e1a2 cp_parser_binary_expression
../../gcc/cp/parser.c:9824
0x76e900 cp_parser_assignment_expression
../../gcc/cp/parser.c:10128
0x76fddd cp_parser_constant_expression
../../gcc/cp/parser.c:10424
0x76fe41 cp_parser_initializer_clause
../../gcc/cp/parser.c:24145
0x772b5b cp_parser_initializer
../../gcc/cp/parser.c:24085
[Bug c++/99008] [10/11 Regression] ICE in set_constraints, at cp/constraint.cc:1256
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99008 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org Last reconfirmed||2021-02-08 Summary|[11 Regression] ICE in |[10/11 Regression] ICE in |set_constraints, at |set_constraints, at |cp/constraint.cc:1256 |cp/constraint.cc:1256 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- With -std=c++17, it started with r10-5020-g1a291106384cabc7.
[Bug c++/99008] New: [11 Regression] ICE in set_constraints, at cp/constraint.cc:1256
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99008
Bug ID: 99008
Summary: [11 Regression] ICE in set_constraints, at
cp/constraint.cc:1256
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed between 20200621 and 20200628 :
(maybe related to pr93297)
$ cat z1.cc
template struct A;
template using C = A;
void *f { C(); }
$ g++-11-20210207 -c z1.cc
z1.cc:3:13: internal compiler error: in set_constraints, at
cp/constraint.cc:1256
3 | void *f { C(); }
| ^
0x6a757e set_constraints(tree_node*, tree_node*)
../../gcc/cp/constraint.cc:1256
0x7b1bd2 alias_ctad_tweaks
../../gcc/cp/pt.c:29025
0x7b1bd2 deduction_guides_for
../../gcc/cp/pt.c:29140
0x7b2042 do_class_deduction
../../gcc/cp/pt.c:29250
0x7b2042 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
../../gcc/cp/pt.c:29420
0x81c535 build_functional_cast_1
../../gcc/cp/typeck2.c:2208
0x81c535 build_functional_cast(unsigned int, tree_node*, tree_node*, int)
../../gcc/cp/typeck2.c:2308
0x772977 cp_parser_functional_cast
../../gcc/cp/parser.c:30553
0x783bd2 cp_parser_postfix_expression
../../gcc/cp/parser.c:7427
0x793d35 cp_parser_unary_expression
../../gcc/cp/parser.c:8818
0x76d96f cp_parser_cast_expression
../../gcc/cp/parser.c:9722
0x76e1a2 cp_parser_binary_expression
../../gcc/cp/parser.c:9824
0x76e900 cp_parser_assignment_expression
../../gcc/cp/parser.c:10128
0x76fddd cp_parser_constant_expression
../../gcc/cp/parser.c:10424
0x76fe41 cp_parser_initializer_clause
../../gcc/cp/parser.c:24145
0x76ffe4 cp_parser_initializer_list
../../gcc/cp/parser.c:24424
0x76ffe4 cp_parser_braced_list
../../gcc/cp/parser.c:24186
0x772b82 cp_parser_initializer
../../gcc/cp/parser.c:24103
0x79c6b7 cp_parser_init_declarator
../../gcc/cp/parser.c:21745
0x77cf3a cp_parser_simple_declaration
../../gcc/cp/parser.c:14381
[Bug c++/99007] [11 Regression] ICE in dominated_by_p, at dominance.c:1124
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99007 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |11.0 Last reconfirmed||2021-02-08 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Started with my r11-4710-g9649031577028310e853025672c71dfb500494f0 change when allocate clause has been implemented for this.
[Bug c++/99007] New: [11 Regression] ICE in dominated_by_p, at dominance.c:1124
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99007
Bug ID: 99007
Summary: [11 Regression] ICE in dominated_by_p, at
dominance.c:1124
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 20201018 and 20201108 :
$ cat z1.cc
template void bar (T *)
{
T s[0/0];
#pragma omp teams distribute parallel for reduction(+:s) allocate(s)
for (int i = 0; i < 8; i++);
}
void foo ()
{
long *a;
bar (a);
}
$ g++-11-20210207 -c z1.cc -fopenmp
z1.cc: In function 'void bar(T*)':
z1.cc:3:8: warning: division by zero [-Wdiv-by-zero]
3 | T s[0/0];
| ~^~
z1.cc: In instantiation of 'void bar(T*) [with T = long int]':
z1.cc:10:9: required from here
z1.cc:3:8: warning: division by zero [-Wdiv-by-zero]
during GIMPLE pass: ssa
z1.cc: In function '_Z3barIlEvPT_._omp_fn.0':
z1.cc:11:1: internal compiler error: Segmentation fault
11 | }
| ^
0xfe6cdf crash_signal
../../gcc/toplev.c:327
0xb6e764 dominated_by_p(cdi_direction, basic_block_def const*, basic_block_def
const*)
../../gcc/dominance.c:1124
0x1259775 verify_use
../../gcc/tree-ssa.c:892
0x125e462 verify_ssa(bool, bool)
../../gcc/tree-ssa.c:1167
0xef8a87 execute_function_todo
../../gcc/passes.c:2049
0xef97f2 execute_todo
../../gcc/passes.c:2096
[Bug target/98997] Linking mismatched -fcf-protection objects generates incorrect code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98997 --- Comment #4 from Andy Lutomirski --- I should add: on brief inspection, that patch looks like an ABI break for -fcf-protection=none
[Bug target/98997] Linking mismatched -fcf-protection objects generates incorrect code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98997 --- Comment #3 from Andy Lutomirski --- What is -fcf-protection=stack actually supposed to do as compared to -fcf-protection=none? Is it valid to run code compiled with -fcf-protection=none with SHSTK enabled? If so, then I wonder why -fcf-protection=stack exists at all. If not, then I'm wondering why your patch seems to be effectively hardcoding "stack" mode for SJLJ? You could probably fix this bug differently by changing __builtin_setjmp() to store 0 for SSP in "none" mode. Then at least -fcf-protection=none wouldn't emit CET code.
[Bug c++/98531] [11 Regression] g++.dg/modules/xtreme-header-2_a.H etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98531 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #12 from Nathan Sidwell --- With two patches committed: * efcd941e86b 2021-02-03 | c++: cleanup function name [PR 98531] (HEAD -> master, origin/master, origin/HEAD, me/regressions) [Nathan Sidwell] * 57b17858a1b 2021-01-22 | c++: cross-module __cxa_atexit use [PR 98531] [Nathan Sidwell] an i386-solaris2.11 cc1plus can compile the testcase. If there's still a problem with (this bit of) the testsuite more information is needed, or maybe a different report?
[Bug c++/98531] [11 Regression] g++.dg/modules/xtreme-header-2_a.H etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98531 --- Comment #11 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:57b17858a1b3719507ccad926fb57b05f26935f8 commit r11-7138-g57b17858a1b3719507ccad926fb57b05f26935f8 Author: Nathan Sidwell Date: Fri Jan 22 08:48:27 2021 -0800 c++: cross-module __cxa_atexit use [PR 98531] The compiler's use of lazily-declared library functions must insert said functions into a symbol table, so that they can be correctly merged across TUs at the module-level. We have too many different ways of declaring such library functions. This fixes __cxa_atexit (or its system-specific variations), pushing (or merging) the decl into the appropriate namespace. Because we're pushing a lazy builtin, check_redeclaration_exception_specification needed a tweak to allow a such a builtin's eh spec to differ from what the user may have already declared. (I suspect no all headers declare atexit as noexcept.) We can't test the -fno-use-cxa-atexit path with modules, as that requires a followup patch to a closely related piece (which also affects cxa_atexit targets in other circumstances). PR c++/98531 gcc/cp/ * cp-tree.h (push_abi_namespace, pop_abi_namespace): Declare. * decl.c (push_abi_namespace, pop_abi_namespace): Moved from rtti.c, add default namespace arg. (check_redeclaration_exception_specification): Allow a lazy builtin's eh spec to differ from an lready-declared user declaration. (declare_global_var): Use push/pop_abi_namespace. (get_atexit_node): Push the fndecl into a namespace. * rtti.c (push_abi_namespace, pop_abi_namespace): Moved to decl.c. gcc/testsuite/ * g++.dg/modules/pr98531-1.h: New. * g++.dg/modules/pr98531-1_a.H: New. * g++.dg/modules/pr98531-1_b.C: New. * g++.dg/abi/pr98531-1.C: New. * g++.dg/abi/pr98531-2.C: New. * g++.dg/abi/pr98531-3.C: New. * g++.dg/abi/pr98531-4.C: New.
[Bug ipa/93115] gcc fails to emit inline function on llvm-roc project: -O1 -fPIC -fdevirtualize -fdevirtualize-speculatively -fipa-cp -fipa-cp-clone -fvisibility-inlines-hidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93115
--- Comment #8 from Sergei Trofimovich ---
Slightly better example without warnings (used `__builtin_trap();` to work
around use of uninitialized value):
```c++
struct a {
char ac1;
char ac2;
int d() { return av() + ac1 + ac2; }
virtual void f() {}
virtual int av() { __builtin_trap(); }
a(){}
};
struct g : a {
virtual void f2();
g():a(){}
};
#ifdef LIB_FILE
void g::f2() {}
#endif
#ifdef MAIN_FILE
static g b;
static char bb;
char cc() { return bb; }
void h() {
if (cc()) {
b.d();
return;
}
}
int main() {}
#endif
```
[Bug libstdc++/99006] New: make_shared silently works
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99006
Bug ID: 99006
Summary: make_shared silently works
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: Darrell.Wright at gmail dot com
Target Milestone: ---
std::make_shared in libstdc++ prior to c++20 doesn't fail.
The minimal example is
#include
int func( ) {
auto sp = std::make_shared( 55 );
return *sp.get( );
}
will return 55;
libc++ removes it from the overload set and MS STL fails.
https://gcc.godbolt.org/z/PaW6WY
With T = int[], I think
https://timsong-https://timsong-cpp.github.io/cppwp/n4659/util.smartptr.shared.create#1
should make this not work.
[Bug middle-end/99004] memory leak in maybe_warn_rdwr_sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99004 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2021-02-08 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Jakub Jelinek --- Created attachment 50144 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50144&action=edit gcc11-pr99004.patch Untested fix.
[Bug ipa/99003] memory leak in IPA ICF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99003 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2021-02-08 --- Comment #1 from Martin Liška --- Mine.
[Bug tree-optimization/99002] [11 Regression] memory leak in if-to-switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99002 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-02-08 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Mine.
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 98974, which changed state. Bug 98974 Summary: [11 Regression] ICE in vectorizable_condition after STMT_VINFO_VEC_STMTS https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98974 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug middle-end/98974] [11 Regression] ICE in vectorizable_condition after STMT_VINFO_VEC_STMTS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98974 avieira at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from avieira at gcc dot gnu.org --- That should fix it.
[Bug middle-end/98974] [11 Regression] ICE in vectorizable_condition after STMT_VINFO_VEC_STMTS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98974 --- Comment #4 from CVS Commits --- The master branch has been updated by Andre Simoes Dias Vieira : https://gcc.gnu.org/g:40c92180df970143249f3cd5056f8fb48a4d9333 commit r11-7135-g40c92180df970143249f3cd5056f8fb48a4d9333 Author: Andre Vieira Date: Mon Feb 8 16:04:18 2021 + middle-end/98974 - fixup after STMT_VINFO_VEC_STMTS rework This fixes up the nvectors parameter passed to vect_get_loop_mask in vectorizable_condition after the STMT_VINFO_VEC_STMTS rework. gcc/ChangeLog: 2021-02-08 Andre Vieira PR middle-end/98974 * tree-vect-stmts.c (vectorizable_condition): Remove shadow vec_num parameter in vectorizable_condition. gcc/testsuite/ChangeLog: 2021-02-08 Andre Vieira PR middle-end/98974 * gfortran.dg/pr98974.F90: New test.
[Bug fortran/99005] New: libgomp runtime does not support AMD GPU offloading for OpenACC directives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99005 Bug ID: 99005 Summary: libgomp runtime does not support AMD GPU offloading for OpenACC directives Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: kd486 at cam dot ac.uk Target Milestone: --- Created attachment 50143 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50143&action=edit Sample code with single OpenACC directive in for loop Simple Gfortran compiled OpenACC code crashes. Code used attached and compiled with: gfortran -fopenacc -Wall -Wextra -foffload=amdgcn-amdhsa="-march=gfx900" -c mymodule.f90 The server has an AMD EPYC 7742 CPU with 4 Vega 20 AMD GPUs. Runtime error: ./main libgomp: GCN fatal error: Run-time could not be initialized Runtime message: HSA_STATUS_ERROR_OUT_OF_RESOURCES: The runtime failed to allocate the necessary resources. This error may also occur when the core runtime library needs to spawn threads or create internal OS-specific events. Code runs fine without GPU offloading, or with offloading with PGI compiler.
[Bug inline-asm/98991] ICE: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98991 --- Comment #4 from zhan3299 at purdue dot edu --- Seems '-fpermissive' is useless. I can reproduce the ICE simply via 'gcc poc.cc'
[Bug inline-asm/98991] ICE: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98991
--- Comment #3 from zhan3299 at purdue dot edu ---
(In reply to Martin Liška from comment #1)
> Is it a valid or invalid code, please?
Hi, sorry for the confusion. I used a simple delta debugging to reduce the
test-case, and it seems very confused.
Currently, I use C-Reduce to get a simple test-case:
--- poc.cc starts ---
void a() {
float b;
asm("" : "=rmf"(b) : "0"(0));
&b;
}
--- poc.cc ends ---
run 'gcc poc.cc -fpermissive' and we can get the same ICE.
--- error trace starts ---
during RTL pass: reload
poc.cc: In function 'void a()':
poc.cc:5:1: internal compiler error: maximum number of generated reload insns
per insn achieved (90)
5 | }
| ^
0x20cb324 lra_constraints(bool)
../../gcc/gcc/lra-constraints.c:4951
0x20ab2c8 lra(_IO_FILE*)
../../gcc/gcc/lra.c:2440
0x1ff80de do_reload()
../../gcc/gcc/ira.c:5523
0x1ff80de (anonymous namespace)::pass_reload::execute(function*)
../../gcc/gcc/ira.c:5709
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/98988] delete is not a constant expression with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98988 --- Comment #1 from Jakub Jelinek --- Some sanitizers imply -fno-delete-null-pointer-checks and this testcase fails with fno-delete-null-pointer-checks too - the &heap_magic_var_decl != NULL comparison in that case which is done on delete is not folded into true. Wonder if at least for the magic heap vars we shouldn't fold comparisons against NULL, because those will never live in any memory and thus we can pretend their address will never be 0.
[Bug tree-optimization/98856] [11 Regression] botan AES-128/XTS is slower by ~17% since r11-6649-g285fa338b06b804e72997c4d876ecf08a9c083af
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98856 --- Comment #16 from Jakub Jelinek --- Created attachment 50142 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50142&action=edit gcc11-pr98856.patch Full patch.
[Bug ipa/97346] IPA reference reference_vars_to_consider leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97346 Jan Hubicka changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-02-08 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #3 from Jan Hubicka --- I will check If I recall correctly, during analysis the vector is only collected for dumps, so that is why vec_free is conditional. Since vec_free is noop on NULL, we could just free it anyway. I think it is the delete call that causes the leak.
[Bug middle-end/99004] New: memory leak in maybe_warn_rdwr_sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99004 Bug ID: 99004 Summary: memory leak in maybe_warn_rdwr_sizes Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- ==3511== Memcheck, a memory error detector ==3511== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==3511== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==3511== Command: ./cc1 -quiet -fdiagnostics-plain-output -O3 -o ssa-dom-thread-1.s /home/rguenther/src/gcc3/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c ==3511== ==3511== ==3511== HEAP SUMMARY: ==3511== in use at exit: 2,402,368 bytes in 5,697 blocks ==3511== total heap usage: 424,419 allocs, 418,722 frees, 208,122,638 bytes allocated ==3511== ==3511== 2 bytes in 1 blocks are definitely lost in loss record 1 of 921 ==3511==at 0x4C2E2DF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==3511==by 0x28ECDF6: xmalloc (xmalloc.c:147) ==3511==by 0x28ECF6F: xstrdup (xstrdup.c:34) ==3511==by 0x15EF51F: print_generic_expr_to_str(tree_node*) (tree-pretty-print.c:179) ==3511==by 0xC532AD: maybe_warn_rdwr_sizes(hash_map, attr_access> >*, tree_node*, tree_node*, tree_node*) (calls.c:2035) ==3511==by 0xC5535F: initialize_argument_information(int, arg_data*, args_size*, int, tree_node*, tree_node*, tree_node*, tree_node*, cumulative_args_t, int, rtx_def**, poly_int_pod<1u, long>*, int*, int*, bool*, bool) (calls.c:2625) ==3511==by 0xC5957C: expand_call(tree_node*, rtx_def*, int) (calls.c:4009) ==3511==by 0xE84D06: expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) (expr.c:11279) ==3511==by 0xE77230: expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) (expr.c:8513) ==3511==by 0xC7C8EA: expand_expr(tree_node*, rtx_def*, machine_mode, expand_modifier) (expr.h:282) ==3511==by 0xC858B6: expand_call_stmt(gcall*) (cfgexpand.c:2840) ==3511==by 0xC8933E: expand_gimple_stmt_1(gimple*) (cfgexpand.c:3844)
[Bug ipa/99003] New: memory leak in IPA ICF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99003 Bug ID: 99003 Summary: memory leak in IPA ICF Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- ==1945== Memcheck, a memory error detector ==1945== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==1945== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==1945== Command: ./cc1 -quiet -fdiagnostics-plain-output -O3 -o ssa-dom-thread-1.s /home/rguenther/src/gcc3/gcc/testsuite/gcc.dg/tree-ssa/20030714-1.c ==1945== ==1945== ==1945== HEAP SUMMARY: ==1945== in use at exit: 1,973,344 bytes in 2,924 blocks ==1945== total heap usage: 52,587 allocs, 49,663 frees, 19,998,193 bytes allocated ==1945== ==1945== 16 bytes in 1 blocks are definitely lost in loss record 9 of 785 ==1945==at 0x4C2E94F: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==1945==by 0x263B75A: ipa_icf::sem_item::add_reference(hash_map, simple_hashmap_traits, auto_vec > >*, ipa_icf::sem_item*) (ipa-icf.c:169) ==1945==by 0x264556E: ipa_icf::sem_item_optimizer::build_graph() (ipa-icf.c:2642) ==1945==by 0x26448AF: ipa_icf::sem_item_optimizer::execute() (ipa-icf.c:2423) ==1945==by 0x2648932: ipa_icf::ipa_icf_driver() (ipa-icf.c:3584) ==1945==by 0x264B206: ipa_icf::pass_ipa_icf::execute(function*) (ipa-icf.c:3631) ==1945==by 0x12E8130: execute_one_pass(opt_pass*) (passes.c:2572) ==1945==by 0x12E90C8: execute_ipa_pass_list(opt_pass*) (passes.c:3001) ==1945==by 0xCFCB79: ipa_passes() (cgraphunit.c:2215) ==1945==by 0xCFCE0C: symbol_table::compile() (cgraphunit.c:2292) ==1945==by 0xCFD379: symbol_table::finalize_compilation_unit() (cgraphunit.c:2540) ==1945==by 0x148FF21: compile_file() (toplev.c:482)
[Bug ipa/93115] gcc fails to emit inline function on llvm-roc project: -O1 -fPIC -fdevirtualize -fdevirtualize-speculatively -fipa-cp -fipa-cp-clone -fvisibility-inlines-hidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93115
--- Comment #7 from Sergei Trofimovich ---
Looks like original test does not trigger the bug as is (probably due to tets
fragility). Here is something shorter (but with warnings):
```c++
struct a {
char at;
char au;
int d() { return av() + au - at; }
virtual void f() {}
virtual int av() { }
};
struct g : a {
void f();
char b;
char c() { return b; }
} b;
#ifdef MAIN_FILE
g e;
void h() {
if (b.c()) {
e.d();
return;
}
}
int main() {}
#endif
#ifdef LIB_FILE
void g::f() {}
#endif
```
$ g++-11.0.0 -Wall -fPIC -O1 -fdevirtualize -fdevirtualize-speculatively
-fipa-cp -fipa-cp-clone -fvisibility-inlines-hidden -fPIC -shared -o libbug.so
bug.cpp -DLIB_FILE
bug.cpp: In member function 'virtual int a::av()':
bug.cpp:6:22: warning: no return statement in function returning non-void
[-Wreturn-type]
6 | virtual int av() { }
| ^
$ g++-11.0.0 -Wall -fPIC -O1 -fdevirtualize -fdevirtualize-speculatively
-fipa-cp -fipa-cp-clone -fvisibility-inlines-hidden -o main bug.cpp -DMAIN_FILE
-L. -lbug
bug.cpp: In member function 'virtual int a::av()':
bug.cpp:6:22: warning: no return statement in function returning non-void
[-Wreturn-type]
6 | virtual int av() { }
| ^
/usr/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../x86_64-pc-linux-gnu/bin/ld:
/tmp/ccbaHYef.o: in function `h()':
bug.cpp:(.text+0x1a): undefined reference to `a::av()'
collect2: error: ld returned 1 exit status
[Bug target/97638] aarch64: bti c is missing at function entry with branch-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97638 Wilco changed: What|Removed |Added Resolution|--- |FIXED CC||wilco at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #3 from Wilco --- Fixed and backported, so close.
[Bug c++/98987] Concept subsumption doesn't work with by-value vs. by-reference parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98987 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- As with PR96333, since the function templates' function parameters aren't equivalent, neither is considered more constrained than the other, and so we're correct to reject this testcase from what I understand.
[Bug ipa/97346] IPA reference reference_vars_to_consider leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97346 --- Comment #2 from Richard Biener --- Ping. This is annoying and pops up with each and every valgrind --leak-check=full ...
[Bug tree-optimization/99002] [11 Regression] memory leak in if-to-switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99002 Richard Biener changed: What|Removed |Added CC||marxin at gcc dot gnu.org Target Milestone|--- |11.0
[Bug tree-optimization/99002] New: [11 Regression] memory leak in if-to-switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99002 Bug ID: 99002 Summary: [11 Regression] memory leak in if-to-switch Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- ==1542== Memcheck, a memory error detector ==1542== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==1542== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==1542== Command: ./cc1 -quiet -fdiagnostics-plain-output -O2 -fno-tree-vrp -fdump-tree-dom2-details -o ssa-dom-thread-1.s /home/rguenther/src/gcc3/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-11.c ==1542== ==1542== ==1542== HEAP SUMMARY: ==1542== in use at exit: 1,875,265 bytes in 2,696 blocks ==1542== total heap usage: 16,329 allocs, 13,633 frees, 6,189,742 bytes allocated ==1542== ==1542== 64 bytes in 1 blocks are definitely lost in loss record 151 of 682 ==1542==at 0x4C2E94F: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==1542==by 0x24FFE0F: find_conditions(basic_block_def*, hash_map, condition_info*> >*) (gimple-if-to-switch.cc:398) ==1542==by 0x250044B: (anonymous namespace)::pass_if_to_switch::execute(function*) (gimple-if-to-switch.cc:499) ==1542==by 0x12E8130: execute_one_pass(opt_pass*) (passes.c:2572) ==1542==by 0x12E8467: execute_pass_list_1(opt_pass*) (passes.c:2661) ==1542==by 0x12E8498: execute_pass_list_1(opt_pass*) (passes.c:2662) ==1542==by 0x12E84F0: execute_pass_list(function*, opt_pass*) (passes.c:2672) ==1542==by 0x12E6425: do_per_function_toporder(void (*)(function*, void*), void*) (passes.c:1774) ==1542==by 0x12E9120: execute_ipa_pass_list(opt_pass*) (passes.c:3006) ==1542==by 0xCFC9D6: ipa_passes() (cgraphunit.c:2157) ==1542==by 0xCFCE0C: symbol_table::compile() (cgraphunit.c:2292) ==1542==by 0xCFD379: symbol_table::finalize_compilation_unit() (cgraphunit.c:2540) ==1542==
[Bug target/98997] Linking mismatched -fcf-protection objects generates incorrect code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98997 H.J. Lu changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-02-08 Status|UNCONFIRMED |NEW --- Comment #2 from H.J. Lu --- A patch is posted at https://gcc.gnu.org/pipermail/gcc-patches/2021-February/564972.html
[Bug rtl-optimization/98863] [11 Regression] WRF with LTO consumes a lot of memory in REE, FWPROP and x86 specific passes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98863 --- Comment #43 from Richard Biener --- So module_configure.fppized.f90 is one of the interesting ones (IIRC lot of small init loops), module_first_rk_step_part1.fppized.f90 is the one with most obvious DF and fwprop participation, that one also has complete unrolling. /home/rguenther/install/gcc-11.0/usr/local/bin/gfortran -c -o start_em.fppized.o -I. -I./netcdf/include -I./inc -Ofast -march=znver2 -ftime-report -std=legacy -fconvert=big-endian -fno-openmp -g0 start_em.fppized.f90 df reaching defs : 0.96 ( 3%) 0.02 ( 3%) 0.94 ( 3%) 0 ( 0%) df live regs : 1.15 ( 4%) 0.00 ( 0%) 1.13 ( 4%) 0 ( 0%) df live&initialized regs : 1.08 ( 4%) 0.01 ( 2%) 1.18 ( 4%) 0 ( 0%) tree forward propagate : 0.09 ( 0%) 0.01 ( 2%) 0.08 ( 0%) 2217k ( 0%) complete unrolling : 1.00 ( 3%) 0.02 ( 3%) 1.01 ( 3%) 56M ( 12%) forward prop : 0.93 ( 3%) 0.18 ( 29%) 1.10 ( 4%) 388k ( 0%) TOTAL : 30.60 0.62 31.23 492M /home/rguenther/install/gcc-11.0/usr/local/bin/gfortran -c -o module_advect_em.fppized.o -I. -I./netcdf/include -I./inc -Ofast -march=znver2 -ftime-report -std=legacy -fconvert=big-endian -fno-openmp -g0 module_advect_em.fppized.f90 df reaching defs : 0.28 ( 1%) 0.00 ( 0%) 0.30 ( 1%) 0 ( 0%) df live regs : 1.45 ( 5%) 0.00 ( 0%) 1.35 ( 4%) 0 ( 0%) df live&initialized regs : 0.54 ( 2%) 0.00 ( 0%) 0.64 ( 2%) 0 ( 0%) tree forward propagate : 0.08 ( 0%) 0.00 ( 0%) 0.13 ( 0%) 2824k ( 0%) complete unrolling : 0.99 ( 3%) 0.03 ( 9%) 1.05 ( 3%) 78M ( 8%) forward prop : 0.24 ( 1%) 0.00 ( 0%) 0.20 ( 1%) 1270k ( 0%) TOTAL : 31.59 0.34 31.96 974M /home/rguenther/install/gcc-11.0/usr/local/bin/gfortran -c -o module_first_rk_step_part1.fppized.o -I. -I./netcdf/include -I./inc -Ofast -march=znver2 -ftime-report -std=legacy -fconvert=big-endian -fno-openmp -g0 module_first_rk_step_part1.fppized.f90 df reaching defs : 2.69 ( 4%) 0.04 ( 3%) 2.81 ( 5%) 0 ( 0%) df live regs : 1.76 ( 3%) 0.01 ( 1%) 1.71 ( 3%) 0 ( 0%) df live&initialized regs : 1.57 ( 3%) 0.01 ( 1%) 1.58 ( 3%) 0 ( 0%) tree forward propagate : 0.20 ( 0%) 0.02 ( 2%) 0.19 ( 0%) 4095k ( 0%) complete unrolling : 3.25 ( 5%) 0.04 ( 3%) 3.27 ( 5%) 94M ( 11%) forward prop : 2.79 ( 5%) 0.38 ( 30%) 3.16 ( 5%) 765k ( 0%) TOTAL : 60.41 1.27 61.72 873M /home/rguenther/install/gcc-11.0/usr/local/bin/gfortran -c -o solve_em.fppized.o -I. -I./netcdf/include -I./inc -Ofast -march=znver2 -ftime-report -std=legacy -fconvert=big-endian -fno-openmp -g0 solve_em.fppized.f90 df reaching defs : 1.57 ( 5%) 0.01 ( 2%) 1.50 ( 5%) 0 ( 0%) df live regs : 2.22 ( 7%) 0.01 ( 2%) 2.24 ( 7%) 0 ( 0%) df live&initialized regs : 2.83 ( 9%) 0.01 ( 2%) 2.81 ( 9%) 0 ( 0%) tree forward propagate : 0.15 ( 0%) 0.00 ( 0%) 0.15 ( 0%) 2644k ( 0%) complete unrolling : 1.11 ( 4%) 0.02 ( 4%) 1.12 ( 4%) 86M ( 14%) forward prop : 0.75 ( 2%) 0.08 ( 14%) 0.84 ( 3%) 495k ( 0%) TOTAL : 31.21 0.57 31.80 629M In the end LTO makes the case unique still ... And then there's of course one other frequently reported bug: /home/rguenther/install/gcc-11.0/usr/local/bin/gfortran -c -o module_alloc_space_2.fppized.o -I. -I./netcdf/include -I./inc -Ofast -march=znver2 -ftime-report -std=legacy -fconvert=big-endian -fno-openmp -g0 module_alloc_space_2.fppized.f90 load CSE after reload : 10.18 ( 37%) 0.00 ( 0%) 10.19 ( 37%) 14k ( 0%) TOTAL : 27.28 0.33 27.63 333M
[Bug c++/99001] indirect modification of function parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99001 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- (In reply to Wolfgang Roehrl from comment #0) > Hi, > I would like to post a bug report for the GNU C/C++ compiler 7.5.0. GCC 7 is no longer supported or maintained and will not get any bug fixes. > I think that the behaviour of f2() is wrong and f2() should behave as > function f1() does. No, what GCC does is correct. In f2 the return value is initialized before x.~X() runs.
[Bug c++/98995] [11 Regression] Copy elision not applied to members declared with [[no_unique_address]]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98995 Jonathan Wakely changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #1 from Jonathan Wakely --- Started with r11-2704: c++: Copy elision and [[no_unique_address]]. [PR93711] We don't elide a copy from a function returning a class by value into a base because that can overwrite data laid out in the tail padding of the base class; we need to handle [[no_unique_address]] fields the same way, or we ICE when the middle-end wants to create a temporary object of a TYPE_NEEDS_CONSTRUCTING type. This means that we can't always express initialization of a field with INIT_EXPR from a TARGET_EXPR the way we usually do, so I needed to change several places that were assuming that was sufficient. This also fixes 90254, the same problem with C++17 aggregate initialization of a base.
[Bug c++/99001] New: indirect modification of function parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99001
Bug ID: 99001
Summary: indirect modification of function parameters
Product: gcc
Version: 7.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wolfgang.roe...@gi-de.com
Target Milestone: ---
Hi,
I would like to post a bug report for the GNU C/C++ compiler 7.5.0.
We use the compiler to generate code for a PowerPC processor.
Invokation line for the GNU C++ compiler:
ccppc -c -x c++ --std=gnu++17 -Wall -Werror -g -mcpu=e6500 -m32
-maltivec -mvrsave -ftls-model=local-exec -msdata=sysv
-fno-common -fno-openmp -mbig -mmultiple -mno-string -misel
-mstrict-align -fverbose-asm -G 8 -O3
-I
-D
X.CPP -oX.O
// file X.CPP
struct X
{
X (int& r) : rr(r) {}
~X () { rr = 0; }
int& rr;
};
int f1 (int i)
{
{ X x(i); }
return i;
}
int f2 (int i)
{
X x(i);
return i;
}
Wenn we compile this program the functions do the following:
- function f1() returns 0 - independently of the value of parameter i;
- function f2() returns the unmodified value of parameter i.
I think that the behaviour of f2() is wrong and f2() should behave as
function f1() does.
With kind regards
W. Roehrl
[Bug lto/96591] [8/9/10 Regression] ICE with -flto=auto and -O1: tree code ‘typename_type’ is not supported in LTO streams
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96591 Richard Biener changed: What|Removed |Added Known to work||11.0 Summary|[8/9/10/11 Regression] ICE |[8/9/10 Regression] ICE |with -flto=auto and -O1:|with -flto=auto and -O1: |tree code ‘typename_type’ |tree code ‘typename_type’ |is not supported in LTO |is not supported in LTO |streams |streams --- Comment #9 from Richard Biener --- Fixed on trunk sofar.
