[Bug c++/91217] [8/9/10/11 Regression] Returning std::array from lambda results in an extra copy step on return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91217 --- Comment #5 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:04771106cda8dca2c8b975fd4648933679455b8f commit r11-7967-g04771106cda8dca2c8b975fd4648933679455b8f Author: Jason Merrill Date: Sat Apr 3 01:07:36 2021 -0400 c++: NRV in lambda in template [PR91217] tsubst_lambda_expr was producing a function with two blocks that claimed to be the outermost block in the function body, one from the call to start_lambda_function in tsubst_lambda_expr, and one from tsubsting the block added by start_lambda_function when we first parsed the lambda. This messed with the named return value optimization, which only works for variables in the outermost block. gcc/cp/ChangeLog: PR c++/91217 * pt.c (tsubst_lambda_expr): Skip the body block from DECL_SAVED_TREE. gcc/testsuite/ChangeLog: PR c++/91217 * g++.dg/opt/nrv20.C: New test.
[Bug c++/90664] [9/10/11 regression] noexcept confuses template argument deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90664 --- Comment #3 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:7c3ba2145ceddb0fd7f85fbf27f8db81896527d1 commit r11-7966-g7c3ba2145ceddb0fd7f85fbf27f8db81896527d1 Author: Jason Merrill Date: Fri Apr 2 17:07:12 2021 -0400 c++: PMF template parm and noexcept [PR90664] The constexpr code only wants to preserve PTRMEM_CST in conversions if the conversions are only qualification conversions; dropping noexcept counts as a qualification adjustment in overload resolution, so let's include it here. gcc/cp/ChangeLog: PR c++/90664 * cvt.c (can_convert_qual): Check fnptr_conv_p. gcc/testsuite/ChangeLog: PR c++/90664 * g++.dg/cpp1z/noexcept-type24.C: New test.
[Bug c++/97900] [9/10/11 Regression] g++ crashes when instantiating a templated function with a template-type vector parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97900 --- Comment #3 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:23be03a0f243a084a0fe03d0b96a3d045e1a2b65 commit r11-7965-g23be03a0f243a084a0fe03d0b96a3d045e1a2b65 Author: Jason Merrill Date: Fri Apr 2 14:49:15 2021 -0400 c++: dependent attribute on parameter [PR97900] We were copying attributes from the template to the instantiation without considering that they might be dependent. To make sure that the new parms have the appropriate properties for the code pattern, let's just regenerate them. gcc/cp/ChangeLog: PR c++/97900 * pt.c (regenerate_decl_from_template): tsubst_decl the parms. gcc/testsuite/ChangeLog: PR c++/97900 * g++.dg/ext/vector40.C: New test.
[Bug tree-optimization/99887] New: Failure to optimize log2 pattern to clz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99887
Bug ID: 99887
Summary: Failure to optimize log2 pattern to clz
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
static inline unsigned int_log2_rec(unsigned x)
{
return x == 0 ? 0 : int_log2_rec(x >> 1) + 1;
}
unsigned int_log2(unsigned x)
{
return x == 0 ? 0 : int_log2_rec(x) - 1;
}
This can be optimized to `return x == 0 ? x : 31 - __builtin_clz(x);`. This
transformation is done by LLVM, but not by GCC.
[Bug c++/99869] [11 Regression] ICE: in do_auto_deduction, at cp/pt.c:29620
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99869 --- Comment #4 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:260caabe10cde0158b87968a3bac85575301dafa commit r11-7963-g260caabe10cde0158b87968a3bac85575301dafa Author: Patrick Palka Date: Fri Apr 2 19:46:24 2021 -0400 c++: placeholder type constraint inside range-for [PR99869] In the testcase below, during ahead-of-time deduction of a constrained auto inside a range-based for loop, we trip over an assert within do_auto_deduction which expects the deduction context to be adc_return_type or adc_variable_type, but do_range_for_auto_deduction calls do_auto_deduction with the context defaulted to adc_unspecified. We could safely relax the assert to also accept adc_unspecified, but it seems the deduction context should really be adc_variable_type here. gcc/cp/ChangeLog: PR c++/99869 * parser.c (do_range_for_auto_deduction): Pass adc_variable_type to do_auto_deduction. gcc/testsuite/ChangeLog: PR c++/99869 * g++.dg/cpp2a/concepts-placeholder6.C: New test.
[Bug c++/99586] Use of class template identifier checked for CTAD before instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99586
--- Comment #2 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:cf25e27faef75e265e659f39ef6b7d0f1695dfeb
commit r11-7962-gcf25e27faef75e265e659f39ef6b7d0f1695dfeb
Author: Patrick Palka
Date: Fri Apr 2 19:47:09 2021 -0400
c++: Refine check for CTAD placeholder [PR99586]
In the below testcase, during finish_compound_literal for A{},
type_uses_auto finds and returns the CTAD placeholder for B{V}, which
tricks us into attempting CTAD on A{} and leads to bogus errors.
AFAICT 'type' will always be a bare 'auto' in the CTAD case so we don't
need to look deeply to find it; checking template_placeholder_p instead
should suffice here.
gcc/cp/ChangeLog:
PR c++/99586
* semantics.c (finish_compound_literal): Check
template_placeholder_p instead of type_uses_auto.
gcc/testsuite/ChangeLog:
PR c++/99586
* g++.dg/cpp2a/nontype-class42.C: New test.
[Bug analyzer/99886] Delay loop in -fanalyzer seen on gcc.dg/analyzer/malloc-1.c with -fanalyzer-verbosity=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99886 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-04-02 Summary|Infinite loop in -fanalyzer |Delay loop in -fanalyzer |seen on |seen on |gcc.dg/analyzer/malloc-1.c |gcc.dg/analyzer/malloc-1.c |with -fanalyzer-verbosity=0 |with -fanalyzer-verbosity=0 --- Comment #1 from David Malcolm --- Not an infinite loop; it "merely" counts very slowly from 0 to 0x due to ((unsigned)0) - 1 as a loop boundary. Testing a fix.
[Bug analyzer/99886] New: Infinite loop in -fanalyzer seen on gcc.dg/analyzer/malloc-1.c with -fanalyzer-verbosity=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99886
Bug ID: 99886
Summary: Infinite loop in -fanalyzer seen on
gcc.dg/analyzer/malloc-1.c with -fanalyzer-verbosity=0
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Reproducer:
#include
struct coord {
float x;
float y;
};
void test_34 (void)
{
float *q;
struct coord *p = malloc (sizeof (struct coord));
if (!p)
return;
p->x = 0.0f;
q = >x;
free (p);
*q = 1.0f; /* { dg-warning "use after 'free' of 'q'" } */
};
when compiled with:
-fanalyzer -fanalyzer-verbosity=0
Doesn't happen at other verbosity levels.
Seems to be getting stuck here in diagnostic_manager::consolidate_conditions:
(gdb) bt
#0 0x024a8777 in vec::length
(this=0x7fffca98) at ../../src/gcc/vec.h:1439
#1 0x024c0d30 in ana::checker_path::num_events (this=0x7fffca90)
at ../../src/gcc/analyzer/checker-path.h:503
#2 0x024c0138 in ana::diagnostic_manager::consolidate_conditions
(this=0x7fffcf00, path=0x7fffca90)
at ../../src/gcc/analyzer/diagnostic-manager.cc:2203
#3 0x024bf433 in ana::diagnostic_manager::prune_path
(this=0x7fffcf00, path=0x7fffca90, sm=0x0, sval=0x0, state=0x0)
at ../../src/gcc/analyzer/diagnostic-manager.cc:1783
#4 0x024be1b6 in ana::diagnostic_manager::emit_saved_diagnostic
(this=0x7fffcf00, eg=..., sd=...)
at ../../src/gcc/analyzer/diagnostic-manager.cc:1131
#5 0x024c1af1 in ana::dedupe_winners::emit_best (this=0x7fffcc20,
dm=0x7fffcf00, eg=...)
at ../../src/gcc/analyzer/diagnostic-manager.cc:1051
#6 0x024bdfa6 in ana::diagnostic_manager::emit_saved_diagnostics
(this=0x7fffcf00, eg=...)
at ../../src/gcc/analyzer/diagnostic-manager.cc:1100
#7 0x01830e13 in ana::impl_run_checkers (logger=0x35ccbf0) at
../../src/gcc/analyzer/engine.cc:4892
[Bug middle-end/82601] missing uninitialized warning for INTENT(OUT) argument with -O0 / -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82601
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
Last reconfirmed|2017-12-30 00:00:00 |2021-4-2
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=31279
Known to fail||10.2.0, 11.0, 8.3.0, 9.3.0
Target Milestone|--- |12.0
Status|NEW |ASSIGNED
--- Comment #5 from Martin Sebor ---
Pr31279 asks for a warning for a warning for call-by-reference arguments with
known intent(in). This is the converse, but as I mentioned in pr31279 comment
#7 the middle end infrastructure to issue these warnings is in place. The
Fortran front end needs to make use of it.
That being said, detecting read accesses to write-only arguments within the
annotated function itself isn't implemented yet (only passing uninitialized
arguments to read-only arguments is). So I suggest tracking the Fortran
changes in pr31279 and the missing middle-end support here.
$ cat z.c && gcc -S -Wall z.c
__attribute__ ((access (read_only, 1)))
void f1 (int *);
void f2 (void)
{
int i;
f1 (); // -Wuninitialized (good)
}
__attribute__ ((access (write_only, 1)))
int g1 (int *p)
{
return *p; // missing warning
}
z.c: In function ‘f2’:
z.c:7:3: warning: ‘i’ is used uninitialized [-Wuninitialized]
7 | f1 (); // -Wuninitialized (good)
| ^~~
z.c:2:6: note: in a call to ‘f1’ declared with attribute ‘access (read_only,
1)’ here
2 | void f1 (int *);
| ^~
z.c:6:7: note: ‘i’ declared here
6 | int i;
| ^
[Bug c++/99885] New: CTAD fails for auto const& NTTP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99885
Bug ID: 99885
Summary: CTAD fails for auto const& NTTP
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
Following (much-reduced) code causes a CTAD failure in gcc but not clang
(https://godbolt.org/z/zWhWGj7PE) with both C++17 and C++20.
template
struct Foo {};
template
struct Bar {
constexpr auto foo() const -> Foo {
return {};
}
};
constexpr int a = 1;
constexpr Bar bar;
Foo foo = bar.foo(); // <-- CTAD failure
[Bug c++/91217] [8/9/10/11 Regression] Returning std::array from lambda results in an extra copy step on return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91217 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 c++/90664] [9/10/11 regression] noexcept confuses template argument deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90664 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org CC||jason at gcc dot gnu.org
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 83468, which changed state. Bug 83468 Summary: -Wuninitialized false negative (reference, VOPs at O0, Wsystem-headers) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83468 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/83468] -Wuninitialized false negative (reference, VOPs at O0, Wsystem-headers)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83468 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org Resolution|--- |FIXED Status|NEW |RESOLVED Known to work||11.0 --- Comment #5 from Martin Sebor --- For the very first test case GCC 11 warns at -O0 and -O1 but not at -O2. For the second test case in comment #0 and for the one in comment #4 it warns at all three levels. The warning otherwise missing at -O2 in first test case reappears once the call to test3() is commented out, as one would expect. Given all the outstanding problems with the warning I consider this resolved.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 82101, which changed state. Bug 82101 Summary: missed warning for uninitialized value on the loop entry edge https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82101 What|Removed |Added Status|RESOLVED|NEW Resolution|FIXED |---
[Bug middle-end/82101] missed warning for uninitialized value on the loop entry edge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82101
Martin Sebor changed:
What|Removed |Added
Resolution|FIXED |---
Known to fail||10.2.0, 11.0, 7.3.0, 8.3.0,
||9.2.0
Last reconfirmed|2017-09-05 00:00:00 |2021-4-2
Status|RESOLVED|NEW
--- Comment #4 from Martin Sebor ---
Let me take that back. The complaint is about the missing warning for the
variable in the loop, not the one outside it, and presumably with -O1 or above.
That's not quite clear from the description.
Here's a test case for the problem. It's never been diagnosed:
$ cat pr82101.C && gcc -O1 -S -Wall pr82101.C
void f (int);
void g (void)
{
for (int i = 0; i < 10; i++)
{
int t = t; // -Wuninitialized
f (t);
}
}
void h (void)
{
for (int i = 0; i < 10; i++)
{
int t = t; // missing warning
}
}
pr82101.C: In function ‘void g()’:
pr82101.C:8:9: warning: ‘t’ is used uninitialized [-Wuninitialized]
8 | f (t);
| ~~^~~
pr82101.C:7:11: note: ‘t’ was declared here
7 | int t = t; // -Wuninitialized
| ^
[Bug middle-end/82101] missed warning for uninitialized value on the loop entry edge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82101
Martin Sebor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
CC||msebor at gcc dot gnu.org
Component|c++ |middle-end
--- Comment #3 from Martin Sebor ---
GCC 11 in C++ mode warns at all optimization levels:
$ cat pr82101.c && gcc -Wall -xc++ pr82101.c
int main(){
int k=k;
for(int i = 0 ; i < 10 ; i ++){
int t=t;
}
return 0;
}
pr82101.c: In function ‘int main()’:
pr82101.c:2:9: warning: ‘k’ is used uninitialized [-Wuninitialized]
2 | int k=k;
| ^
pr82101.c:2:9: note: ‘k’ was declared here
2 | int k=k;
| ^
According to my bisection, in C++ mode it started warning with r138835 (4.4.0
20080712), so I'm puzzled by Version being set to 7.1.1.
In C it never warned. I think C still doesn't complain about
self-initialization to accommodate the hack as a suppression mechanism for
-Wuninitialized/-Wmaybe-uinitialized.
So with that, I'm going to resolve this as fixed.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 82101, which changed state. Bug 82101 Summary: missed warning for uninitialized value on the loop entry edge https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82101 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/81958] [9/10/11 Regression] spurious -Wmaybe-uninitialized warning in gcc-8, or with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81958
Martin Sebor changed:
What|Removed |Added
Summary|spurious|[9/10/11 Regression]
|-Wmaybe-uninitialized |spurious
|warning in gcc-8, or with |-Wmaybe-uninitialized
|-O1 |warning in gcc-8, or with
||-O1
Known to fail||10.2.0, 11.0, 8.3.0, 9.3.0
CC||msebor at gcc dot gnu.org
Known to work||7.3.0
Last reconfirmed|2017-09-30 00:00:00 |2021-4-2
--- Comment #4 from Martin Sebor ---
Reconfirming with GCC 11 as a GCC 8 regression introduced in r249013. It fails
the same with -O1 and -O2. I think the warning seems to be doing what it's
designed to do. The IL below annotated with my comments in bb 7 shows that
there is a patch along which the use is uninitialized.
void lpfc_debug_dump_all_queues (unsigned int maxidx)
{
unsigned long ivtmp.7;
unsigned int eqidx;
struct lpfc_queue * eq;
struct lpfc_queue * cq_phba.0_1;
struct lpfc_queue * _2;
int _5;
unsigned int _23;
long unsigned int _24;
[count: 0]:
# .MEM_12 = VDEF <.MEM_11(D)>
printk ();
# VUSE <.MEM_12>
cq_phba.0_1 = cq_phba;
goto ; [0.00%]
[count: 0]:
# VUSE <.MEM_12>
_2 = cq_phba.0_1->hba_eq;
_24 = ivtmp.7_25 * 16;
eq_16 = _2 + _24;
# VUSE <.MEM_12>
_5 = eq_16->queue_id;
ivtmp.7_26 = ivtmp.7_25 + 1;
if (_5 != 0)
goto ; [0.00%]
else
goto ; [0.00%]
[count: 0]:
goto ; [100.00%]
[count: 0]:
[count: 0]:
# eq_7 = PHI
# ivtmp.7_25 = PHI <0(2), ivtmp.7_26(8)>
_23 = (unsigned int) ivtmp.7_25;
if (maxidx_15(D) > _23)
goto ; [0.00%]
else
goto ; [0.00%]
[count: 0]:
if (maxidx_15(D) == _23)
goto ; [0.00%]
else
goto ; [0.00%]
[count: 0]:
goto ; [100.00%]
[count: 0]:
# VUSE <.MEM_12>
eq_18 = cq_phba.0_1->hba_eq;
[count: 0]:
## eq_7(10) = PHI
## eq_7(10) = eq_14(D)(2) (unconditional: 2 -> 4)
## eq_9 = eq_7 = eq_14(D)(2)
## if (maxidx_15(D) <= _23 && maxidx_15(D) != _23: 4 -> 5, 5 -> 10, 10 ->
7)
# eq_9 = PHI
# .MEM_19 = VDEF <.MEM_12>
printk (eq_9); [tail call]
# VUSE <.MEM_19>
return;
}
Before r249013 there is no uninitialized read from eq in the IL:
; Function lpfc_debug_dump_all_queues (lpfc_debug_dump_all_queues,
funcdef_no=0, decl_uid=1800, cgraph_uid=0, symbol_order=1)
lpfc_debug_dump_all_queues (unsigned int maxidx)
{
unsigned int eqidx;
struct lpfc_queue * eq;
struct lpfc_queue * prephitmp_1;
unsigned long _2;
int _5;
struct lpfc_queue * _20;
int _22;
struct lpfc_queue * pretmp_23;
struct lpfc_queue * pretmp_24;
struct lpfc_queue * cq_phba.0_25;
struct lpfc_queue * _26;
unsigned long _28;
[14.44%]:
printk ();
if (maxidx_15(D) != 0)
goto ; [92.50%]
else
goto ; [7.50%]
[1.08%]:
pretmp_23 = cq_phba;
pretmp_24 = pretmp_23->hba_eq;
goto ; [100.00%]
[13.32%]:
cq_phba.0_25 = cq_phba;
_26 = cq_phba.0_25->hba_eq;
_22 = _26->queue_id;
if (_22 != 0)
goto ; [7.50%]
else
goto ; [92.50%]
[12.32%]:
goto ; [100.00%]
[1.00%]:
goto ; [100.00%]
[79.18%]:
_2 = (unsigned long) eq_29;
_28 = _2 + 16;
_20 = (struct lpfc_queue *) _28;
_5 = MEM[base: _20, offset: 0B];
if (_5 != 0)
goto ; [7.50%]
else
goto ; [92.50%]
[5.94%]:
goto ; [100.00%]
[73.24%]:
[85.60%]:
# eqidx_27 = PHI
# eq_29 = PHI <_20(12), _26(10)>
eqidx_17 = eqidx_27 + 1;
if (maxidx_15(D) != eqidx_17)
goto ; [92.50%]
else
goto ; [7.50%]
[6.42%]:
[5.44%]:
# prephitmp_1 = PHI <_26(13), pretmp_24(3)>
[14.44%]:
# eq_9 = PHI <_26(9), prephitmp_1(7), _20(11)>
printk (eq_9); [tail call]
return;
}
[Bug target/99881] Regression compare -O2 -ftree-vectorize with -O2 on SKX/CLX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99881
--- Comment #2 from H.J. Lu ---
Created attachment 50501
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50501=edit
A patch to add vec_contruct cost
ix86_builtin_vectorization_cost has
case vec_construct:
{
/* N element inserts into SSE vectors. */
int cost = TYPE_VECTOR_SUBPARTS (vectype) * ix86_cost->sse_op;
/* One vinserti128 for combining two SSE vectors for AVX256. */
if (GET_MODE_BITSIZE (mode) == 256)
cost += ix86_vec_cost (mode, ix86_cost->addss);
/* One vinserti64x4 and two vinserti128 for combining SSE
and AVX256 vectors to AVX512. */
else if (GET_MODE_BITSIZE (mode) == 512)
cost += 3 * ix86_vec_cost (mode, ix86_cost->addss);
return cost;
}
Add vec_contruct cost for vec_construct operation.
[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 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #13 from anlauf at gcc dot gnu.org --- Fixed on mainline and all open branches. Closing. Thanks for the report!
[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 --- Comment #12 from CVS Commits --- The releases/gcc-8 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:28ba017a7ef5d0d0ebe4a37e52db22f667c1c0e2 commit r8-10828-g28ba017a7ef5d0d0ebe4a37e52db22f667c1c0e2 Author: Harald Anlauf Date: Thu Apr 1 07:49:32 2021 +0200 PR fortran/99840 - ICE in gfc_simplify_matmul, at fortran/simplify.c:4777 The simplification of the transposition of a constant array shall properly initialize and set the shape of the result. gcc/fortran/ChangeLog: PR fortran/99840 * simplify.c (gfc_simplify_transpose): Properly initialize resulting shape. gcc/testsuite/ChangeLog: PR fortran/99840 * gfortran.dg/transpose_5.f90: New test. (cherry picked from commit d7cef070bf43bfb3f3d77bac42eadea06c4b0281)
[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 --- Comment #11 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:0c7d11dbd216df4c1ae2f47138321b399e7349f0 commit r9-9319-g0c7d11dbd216df4c1ae2f47138321b399e7349f0 Author: Harald Anlauf Date: Thu Apr 1 07:49:32 2021 +0200 PR fortran/99840 - ICE in gfc_simplify_matmul, at fortran/simplify.c:4777 The simplification of the transposition of a constant array shall properly initialize and set the shape of the result. gcc/fortran/ChangeLog: PR fortran/99840 * simplify.c (gfc_simplify_transpose): Properly initialize resulting shape. gcc/testsuite/ChangeLog: PR fortran/99840 * gfortran.dg/transpose_5.f90: New test. (cherry picked from commit d7cef070bf43bfb3f3d77bac42eadea06c4b0281)
[Bug c++/97900] [9/10/11 Regression] g++ crashes when instantiating a templated function with a template-type vector parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97900 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/96645] [9/10/11 Regression] std::variant default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645
--- Comment #9 from Jason Merrill ---
(In reply to Jason Merrill from comment #8)
> This is related to CWG1890, and the general issue that we don't currently
> parse on demand like we do instantiate on demand for templates.
("We" in this sentence is the C++ standard.)
[Bug c++/96645] [9/10/11 Regression] std::variant default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645
--- Comment #8 from Jason Merrill ---
(In reply to Patrick Palka from comment #7)
>
> Maybe the note in [class.mem.general]/7 is relevant:
>
> A complete-class context of a nested class is also a complete-class
> context of any enclosing class, if the nested class is defined within the
> member-specification of the enclosing class.
>
> We can't determine if A is constructible until we parse the initializer for
> DataWithStruct::A::number. And according to the above, we can't parse this
> initializer until DataWithStruct is complete.
Right.
> Looks like PR81359 is closely related.
Yes. Perhaps PR81359 or PR88368, or both, were wrongly resolved.
We cannot correctly resolve is_nothrow_constructible until we've parsed the
DMI. Given that, we have three options:
1) Conservatively say no.
2) Optimistically guess yes.
3) Non-SFINAE error.
PR81359 changed our behavior from 3 to 1.
#2 seems the clear worst choice, as it can lead to things unexpectedly
throwing.
#3 means people have to jump through hoops to make their code compile.
#1 means silently pessimized code for anything that relies on
std::is_nothrow_constructible in the rest of the translation, since the
value is permanently cached.
If we choose #1, we have another choice for is_constructible: should it be
true (giving A() a throwing exception-spec) or false?
PR88368 changed our choice from true to false.
Any opinions on what our behavior should be? Should there be an LWG issue?
This is related to CWG1890, and the general issue that we don't currently parse
on demand like we do instantiate on demand for templates.
So one workaround is to wrap DataWith* in a dummy template:
#include
using namespace std;
template
struct DataWithStruct {
struct A {
int number = 5;
};
/*typename*/ is_nothrow_constructible::type t = true_type{};
};
DataWithStruct<> d; // OK
or move the nested class out so we can finish parsing it before the use:
#include
void testVarStruct()
{
struct A {
int number = 5;
};
struct B {
bool flag = false;
};
struct DataWithStruct {
using Member = std::variant;
Member data;
};
auto d = DataWithStruct{};
}
[Bug fortran/99884] New: Double spaces in warning message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99884 Bug ID: 99884 Summary: Double spaces in warning message Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: goeran at uddeborg dot se Target Milestone: --- At https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/fortran/io.c;h=40cd76eb5858614c81de98b59a4f6e5b814988ea;hb=HEAD#l2494 the variable "spec" is either set to a string followed by a space, or an empty string. This seems like a good way to be able to create a correct error message when there is a valid string to print but avoid an extra space when not. But when actually used in a message a few lines below, this feature is not taken advantage of, and the specifier is followed by a space regardless. That will make two spaces if there is a valid string, and one useless space when "spec" is empty. Unless I miss something the message string should begin "%sspecifier at %L not …"
[Bug c++/81714] incorrect location for uninitialised variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81714
Martin Sebor changed:
What|Removed |Added
Known to fail|6.4.0, 7.3.0, 8.0 |10.2.0, 11.0, 6.3.0, 7.0.1,
||8.3.0, 9.3.0
Last reconfirmed|2018-02-02 00:00:00 |2021-4-2
--- Comment #2 from Martin Sebor ---
Reconfirmed with GCC 11. This doesn't look like a problem with -Wuninitialized
but rather much earlier. The Gimple dump already has the wrong column number:
$ cat pr81714.c && gcc -S -Wall -fdump-tree-gimple-lineno=/dev/stdout -xc++
pr81714.c
int f0 ()
{
int i;
return i + 1;
}
int f1 ()
{
int i;
return 2 + i;
}
int f0 ()
[pr81714.c:4:15] {
int D.2352;
int i;
[pr81714.c:4:14] D.2352 = i + 1;
[pr81714.c:4:14] return D.2352;
}
int f1 ()
[pr81714.c:10:15] {
int D.2354;
int i;
[pr81714.c:10:14] D.2354 = i + 2;
[pr81714.c:10:14] return D.2354;
}
pr81714.c: In function ‘int f0()’:
pr81714.c:4:14: warning: ‘i’ is used uninitialized [-Wuninitialized]
4 | return i + 1;
| ^
pr81714.c:3:7: note: ‘i’ was declared here
3 | int i;
| ^
pr81714.c: In function ‘int f1()’:
pr81714.c:10:14: warning: ‘i’ is used uninitialized [-Wuninitialized]
10 | return 2 + i;
| ^
pr81714.c:9:7: note: ‘i’ was declared here
9 | int i;
| ^
Other middle-end warnings are also affected (e.g., -Warray-bounds).
[Bug other/99883] New: A couple of minor misspellings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99883 Bug ID: 99883 Summary: A couple of minor misspellings Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: goeran at uddeborg dot se Target Milestone: --- There are two misspellings Anders Jonsson found while reviewing my Swedish translation of gcc: "exclussive" rather than "exclusive at https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/lto/lto-lang.c;h=8e73a11a7f6fdad1f3b69a44635d9cdf7d5466e5;hb=HEAD#l899 "corrsponding" rather than "corresponding" at https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/c-family/c.opt;h=64e46e7573ef58fac424bc40c7d5981fdca001c1;hb=HEAD#l803
[Bug tree-optimization/99474] missing warning on an out of bounds VLA access by a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99474 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-04-02 Known to fail||10.2.0, 11.0, 7.3.0, 8.3.0, ||9.2.0 --- Comment #1 from Martin Sebor --- Confirmed. This never worked.
[Bug c++/99283] [modules] ICE in assert_definition, at cp/module.cc:4608
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99283 --- Comment #24 from Alexander Lelyakin --- Congratulations! After first testing results this bug is not seen more!
[Bug c++/97938] [9/10 Regression] g++ crash when inferring type of auto parameter pack in lambda capture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97938 Jason Merrill changed: What|Removed |Added Summary|[9/10/11 Regression] g++ |[9/10 Regression] g++ |crash when inferring type |crash when inferring type |of auto parameter pack in |of auto parameter pack in |lambda capture |lambda capture --- Comment #5 from Jason Merrill --- Fixed for GCC 11 so far. Note that the original testcase has a syntax error in print_args; the fold-expression line should be (std::cout << ... << args);
[Bug ipa/99862] [meta-issue] various missed optimizations for dead code elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99862 --- Comment #4 from Zhendong Su --- (In reply to Eric Gallager from comment #3) > generally meta-bugs are created to collect other issues under their "Depends > On" field; do you have any other bug numbers to add here? Hi Eric, no, I don't, but all these instances are related in the sense that they all show missed optimizations for dead code. Instead of filing them separately, I thought it might work better if I file them together as a meta issue. If you folks prefer these being filed separately, I'm also happy to do so. Please just let me know whichever works better; thanks. (See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99834#c2)
[Bug c++/81674] gcc cannot detect missing initialisers for fields in constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81674 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=78391 CC||mpolacek at gcc dot gnu.org Last reconfirmed|2018-02-02 00:00:00 |2021-4-2 --- Comment #6 from Martin Sebor --- Reconfirmed with GCC 11. See also pr78391. The patch in pr19808 comment 29 was either never committed or even submitted, and the other patch for the same bug submitted last November (https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559162.html) wasn't approved. Let me CC Marek to see if plans to resubmit it for GCC 12.
[Bug middle-end/78391] g++ (any version) at O0 (for O1, O2, O3 is ok) doesn't warn when class members are used uninitialized.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78391 --- Comment #7 from Martin Sebor --- Patch for pr19808: https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559162.html
[Bug middle-end/78391] g++ (any version) at O0 (for O1, O2, O3 is ok) doesn't warn when class members are used uninitialized.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78391
Martin Sebor changed:
What|Removed |Added
Target Milestone|--- |12.0
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=19808
Status|NEW |ASSIGNED
Component|c++ |middle-end
--- Comment #6 from Martin Sebor ---
In bug 19808 comment #38 Jason explains why the CLOBBER isn't present in the
constructor, so that's not a bug. In light of that, I'm not sure the request
can be implemented without introducing what are strictly speaking false
positives like those Clang suffers from. In the test case below, the global a
is implicitly zeroed out first and then its members are explicitly assigned, so
there is no uninitialized read.
At the same time, I suspect the result of this initialization is probably not
going to be what the author intended, and so warning on it regardless might
actually be useful (admittedly, issuing -Wuninitialized in this case would be a
bit misleading). So with that, -Wuninitialized or -Wmaybe-uninitialized in the
middle end could be probably enhanced to detect this pattern of intialization
dependencies. Marek submitted a C++ patch for a subset of pr19808 last
November but I'm not sure it handled this case. The patch was also not
approved as Jason's preference was to detect these things in the middle end.
So let me reassign this back to the middle end and try to remember to get to it
for GCC 12.
$ cat t.C && clang -S t.C
struct A { int x = w; int w = 10; };
A a;
t.C:1:20: warning: field 'w' is uninitialized when used here [-Wuninitialized]
struct A { int x = w; int w = 10; };
^
t.C:3:3: note: in implicit default constructor for 'A' first required here
A a;
^
t.C:1:8: note: during field initialization in the implicit default constructor
struct A { int x = w; int w = 10; };
^
1 warning generated.
[Bug c++/97938] [9/10/11 Regression] g++ crash when inferring type of auto parameter pack in lambda capture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97938 --- Comment #4 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:2a26351b598242c2fbce95d2a0baacce0084aec6 commit r11-7961-g2a26351b598242c2fbce95d2a0baacce0084aec6 Author: Jason Merrill Date: Fri Apr 2 11:05:46 2021 -0400 c++: lambda pack init-capture within generic lambda We represent the type of a pack init-capture as auto... with packs from the initializer stuck into PACK_EXPANSION_PARAMETER_PACKS so that expanding it produces the right number of elements. But when partially instantiating the auto..., we were changing PACK_EXPANSION_PARAMETER_PACKS to refer to only the auto itself. Fixed thus. gcc/cp/ChangeLog: PR c++/97938 * cp-tree.h (PACK_EXPANSION_AUTO_P): New. * lambda.c (add_capture): Set it. * pt.c (tsubst_pack_expansion): Handle it. gcc/testsuite/ChangeLog: PR c++/97938 * g++.dg/cpp2a/lambda-pack-init6.C: New test.
[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 99283, which changed state. Bug 99283 Summary: [modules] ICE in assert_definition, at cp/module.cc:4608 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99283 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug c++/99283] [modules] ICE in assert_definition, at cp/module.cc:4608
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99283 Nathan Sidwell changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #23 from Nathan Sidwell --- * f4e05eebd6a 2021-04-02 | c++: header unit purview [PR 99283] I think if there are other cases with other test patterns, they should be separate bugs, otherwise this has just turned into a meta bug of its own.
[Bug tree-optimization/99882] [11 Regression] ICE in bswap_view_convert, at gimple-ssa-store-merging.c:988 since r11-7946-g5b9a65ecbeb22ef6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99882
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
Untested fix:
--- gcc/gimple-ssa-store-merging.c.jj 2021-04-01 10:50:56.238629197 +0200
+++ gcc/gimple-ssa-store-merging.c 2021-04-02 16:52:38.763803716 +0200
@@ -985,10 +985,19 @@ public:
static tree
bswap_view_convert (gimple_stmt_iterator *gsi, tree type, tree val)
{
- gcc_assert (INTEGRAL_TYPE_P (TREE_TYPE (val)));
+ gcc_assert (INTEGRAL_TYPE_P (TREE_TYPE (val))
+ || POINTER_TYPE_P (TREE_TYPE (val)));
if (TYPE_SIZE (type) != TYPE_SIZE (TREE_TYPE (val)))
{
HOST_WIDE_INT prec = TREE_INT_CST_LOW (TYPE_SIZE (type));
+ if (POINTER_TYPE_P (TREE_TYPE (val)))
+ {
+ gimple *g
+ = gimple_build_assign (make_ssa_name (pointer_sized_int_node),
+ NOP_EXPR, val);
+ gsi_insert_before (gsi, g, GSI_SAME_STMT);
+ val = gimple_assign_lhs (g);
+ }
tree itype = build_nonstandard_integer_type (prec, 1);
gimple *g = gimple_build_assign (make_ssa_name (itype), NOP_EXPR, val);
gsi_insert_before (gsi, g, GSI_SAME_STMT);
Slightly cleaned up testcase:
void
foo (char *p, void *q)
{
__INTPTR_TYPE__ i = (__INTPTR_TYPE__) q;
p[2] = i;
i >>= 8;
p[3] = i;
i >>= 8;
p[4] = i;
i >>= 8;
p[5] = i;
i >>= 8;
p[6] = i;
i >>= 8;
p[7] = i;
i >>= 8;
p[8] = i;
i >>= 8;
p[9] = i;
}
void
bar (char *p, void *q)
{
__INTPTR_TYPE__ i = (__INTPTR_TYPE__) q;
p[2] = i;
i >>= 8;
p[3] = i;
i >>= 8;
p[4] = i;
i >>= 8;
p[5] = i;
}
[Bug c++/83529] ICE in canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83529 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #9 from Patrick Palka --- FWIW, we accept both testcases (comment #0 and comment #5) after r9-6794 aka the fix for PR86946.
[Bug target/99881] Regression compare -O2 -ftree-vectorize with -O2 on SKX/CLX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99881
H.J. Lu changed:
What|Removed |Added
Last reconfirmed||2021-04-02
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from H.J. Lu ---
(In reply to Hongtao.liu from comment #0)
> testcase is extracted from 557.xz_r
>
> void
> foo (int* __restrict a, int n, int c)
> {
> a[0] = n;
> a[1] = c;
> }
>
> gcc -O2 -ftree-vectorize -fvect-cost-model=very-cheap
>
> foo(int*, int, int):
> movdxmm0, esi
> movdxmm1, edx
> punpckldq xmm0, xmm1
> movqQWORD PTR [rdi], xmm0
> ret
>
> without vectorization
>
> foo(int*, int, int):
> mov DWORD PTR [rdi], esi
> mov DWORD PTR [rdi+4], edx
> ret
>
> cost model:
> scalar: 2 times scalar_store costs 24,
> vector: 1 times unaligned_store costs 12, vec_contruct 8
How is vec_contruct cost computed today?
[Bug c++/94628] [8/9 Regression] ICE in invalid_nonstatic_memfn_p at cp/typeck.c:1979 since r9-640-g1268ecc26fc1289b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94628 Patrick Palka changed: What|Removed |Added CC||gufideg at gmail dot com --- Comment #15 from Patrick Palka --- *** Bug 86859 has been marked as a duplicate of this bug. ***
[Bug c++/86859] error: expansion pattern contains no parameter pack when a pack from introduced in a capture is used in decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86859 Patrick Palka changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE CC||ppalka at gcc dot gnu.org --- Comment #2 from Patrick Palka --- Thanks for the bug reports. This looks similar to PR94628, and indeed GCC 10 accepts both testcases here after r10-7835, so I'm going to mark this PR as a dup of that one. *** This bug has been marked as a duplicate of bug 94628 ***
[Bug c++/95675] [8/9/10/11 Regression] internal compiler error: in build_over_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95675 Patrick Palka changed: What|Removed |Added CC||doko at debian dot org --- Comment #12 from Patrick Palka --- *** Bug 97962 has been marked as a duplicate of this bug. ***
[Bug c++/97962] ICE in build_over_call, at cp/call.c:8976
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97962 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #4 from Patrick Palka --- (In reply to Marek Polacek from comment #3) > A dup of 95675 most likely, which has a much better test. After r11-7481 we no longer ICE here, so a dup indeed. *** This bug has been marked as a duplicate of bug 95675 ***
[Bug c++/99599] [11 Regression] Concepts requirement falsely reporting cyclic dependency, breaks tag_invoke pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99599 --- Comment #3 from gcc-bugs at marehr dot dialup.fu-berlin.de --- Hi Jason, as you linked to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97704, I'm interested if your suggestion would allow that, too? > But that's a matter for the committee Will such issues be forwarded, or do we need to submit a paper / regression / idea? I wouldn't know how to proceed here and / or what needs to be done. Thank you!
[Bug tree-optimization/99882] [11 Regression] ICE in bswap_view_convert, at gimple-ssa-store-merging.c:988 since r11-7946-g5b9a65ecbeb22ef6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99882 Martin Liška changed: What|Removed |Added Target Milestone|--- |11.0 Priority|P3 |P1 Ever confirmed|0 |1 Known to fail||11.0 Known to work||10.2.0 Status|UNCONFIRMED |NEW Last reconfirmed||2021-04-02
[Bug tree-optimization/99882] New: [11 Regression] ICE in bswap_view_convert, at gimple-ssa-store-merging.c:988 since r11-7946-g5b9a65ecbeb22ef6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99882
Bug ID: 99882
Summary: [11 Regression] ICE in bswap_view_convert, at
gimple-ssa-store-merging.c:988 since
r11-7946-g5b9a65ecbeb22ef6
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: marxin at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
The following is reduced from valgrind package:
$ cat libvex.i
void patchProfInc_AMD64(long *location_of_counter) {
char *p;
long imm64 = (long)location_of_counter;
p[2] = (long)location_of_counter;
imm64 >>= 8;
p[3] = imm64;
imm64 >>= 8;
p[4] = imm64;
imm64 >>= 8;
p[5] = imm64;
imm64 >>= 8;
p[6] = imm64;
imm64 >>= 8;
p[7] = imm64;
imm64 >>= 8;
p[8] = imm64;
imm64 >>= 8;
p[9] = imm64;
}
$ gcc libvex.i -c -O3
during GIMPLE pass: store-merging
libvex.i: In function ‘patchProfInc_AMD64’:
libvex.i:1:6: internal compiler error: in bswap_view_convert, at
gimple-ssa-store-merging.c:988
1 | void patchProfInc_AMD64(long *location_of_counter) {
| ^~
0x81c13b bswap_view_convert
/home/marxin/Programming/gcc/gcc/gimple-ssa-store-merging.c:988
0x18a7cdb bswap_replace
/home/marxin/Programming/gcc/gcc/gimple-ssa-store-merging.c:1166
0x18b259f maybe_optimize_vector_constructor
/home/marxin/Programming/gcc/gcc/gimple-ssa-store-merging.c:1344
0x18b259f execute
/home/marxin/Programming/gcc/gcc/gimple-ssa-store-merging.c:5368
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c/99878] -fuse-ld=gold says "could not find ld" instead of "could not find gold"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99878 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug c/99878] -fuse-ld=gold says "could not find ld" instead of "could not find gold"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99878 Martin Liška changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2021-04-02 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- I can take a look. Thanks for the report.
[Bug tree-optimization/99880] [10/11 Regression] ICE in maybe_set_vectorized_backedge_value, at tree-vect-loop.c:9161 since r10-3711-g69f8c1aef5cdcc54
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99880 Martin Liška changed: What|Removed |Added Known to work||9.3.0 Last reconfirmed||2021-04-02 Summary|ICE in |[10/11 Regression] ICE in |maybe_set_vectorized_backed |maybe_set_vectorized_backed |ge_value, at|ge_value, at |tree-vect-loop.c:9161 |tree-vect-loop.c:9161 since ||r10-3711-g69f8c1aef5cdcc54 Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Status|UNCONFIRMED |NEW Known to fail||10.2.0, 11.0 --- Comment #1 from Martin Liška --- Thank you for the bug report, started with r10-3711-g69f8c1aef5cdcc54.
[Bug sanitizer/99877] [8/9/10/11 Regression] Crash in GIMPLE pass:sanopt in huge function using OpenMP since r8-7544-gd838c2d5a8b1844c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99877
Martin Liška changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
Summary|Crash in GIMPLE pass:sanopt |[8/9/10/11 Regression]
|in huge function using |Crash in GIMPLE pass:sanopt
|OpenMP |in huge function using
||OpenMP since
||r8-7544-gd838c2d5a8b1844c
--- Comment #3 from Martin Liška ---
Reduced test-case:
$ cat pr99877.ii
struct vector {
int size();
};
int main() {
vector outqueue;
#pragma omp parallel
{
goto continueloop;
continueloop:;
}
for (; outqueue.size();)
;
}
Started with r8-7544-gd838c2d5a8b1844c, I'll take a look.
[Bug sanitizer/99877] Crash in GIMPLE pass:sanopt in huge function using OpenMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99877 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-04-02 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Martin Liška --- Thank you for the report. I can reproduce it and I'm reducing the provided test-case.
[Bug tree-optimization/99726] [10 Regression] ICE in create_intersect_range_checks_index, at tree-data-ref.c:1855 since r10-4762-gf9d6338bd15ce1fae36bf25d3a0545e9678ddc58
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99726 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:e53c0696113cced90561e79ade27445f6c0926d0 commit r11-7957-ge53c0696113cced90561e79ade27445f6c0926d0 Author: Jakub Jelinek Date: Fri Apr 2 10:07:50 2021 +0200 testsuite: Fix up gcc.target/i386/pr99726.c test [PR99726] -m32 shouldn't be used in gcc.target/i386/ testcases, people do test with -m32/-m64 to get 32-bit compilation tested. And, -floop-nest-optimize is a graphite optimization, so might not be enabled in all gcc builds. 2021-04-02 Jakub Jelinek PR tree-optimization/99726 * gcc.target/i386/pr99726.c: Remove -m32 from dg-options. Move -floop-nest-optimize to dg-additional-options guarded on fgraphite effective target.
[Bug tree-optimization/78394] False positives of maybe-uninitialized with -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78394 --- Comment #17 from Allan Jensen --- Yes, if you can figure out exactly what optimization passes it needs, then we could disable the warning when those passes are disabled.
