[Bug fortran/99061] [10/11 Regression] ICE in gfc_conv_intrinsic_atan2d, at fortran/trans-intrinsic.c:4728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99061 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.3
[Bug fortran/99060] [9/10/11 Regression] ICE in gfc_match_varspec, at fortran/primary.c:2411
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99060 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.4
[Bug c++/99057] Memory leak in cp_parser_selection_statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99057 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- Fixed r11-7182-g27a804bc62805aedb1b097a00eb2c0059244680a.
[Bug c++/99063] [9/10/11 Regression] ICE in prep_operand, at cp/call.c:5842
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99063 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Marek Polacek --- I have a fix.
[Bug libfortran/98825] Unexpected behavior of FORTRAN FORMAT expressions when suppressing new line with '$'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98825 --- Comment #10 from CVS Commits --- The master branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:19c023241020e3b6f5c38f47447bc0fcbe9fef5f commit r11-7183-g19c023241020e3b6f5c38f47447bc0fcbe9fef5f Author: Jerry DeLisle Date: Wed Feb 10 19:37:52 2021 -0800 libgfortran: Fix unwanted end-of-record by checking if seen_dollar. libgfortran/ChangeLog: PR libfortran/98825 * io/transfer.c (next_record_w): Insert check for seen_dollar and if so, skip issueing next record. gcc/testsuite/ChangeLog: PR libfortran/98825 * gfortran.dg/dollar_edit_descriptor_4.f: New test.
[Bug analyzer/98969] [11 Regression] ICE: Segmentation fault (in print_mem_ref)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98969 --- Comment #9 from David Malcolm --- *** Bug 99064 has been marked as a duplicate of this bug. ***
[Bug analyzer/99064] [11 regression] ICE analyzer::print_mem_ref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99064 David Malcolm changed: What|Removed |Added Resolution|--- |DUPLICATE Status|ASSIGNED|RESOLVED --- Comment #2 from David Malcolm --- It is indeed a dup of bug 98969; am working on a fix for both. *** This bug has been marked as a duplicate of bug 98969 ***
[Bug tree-optimization/99068] Missed PowerPC lhau optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99068 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Component|target |tree-optimization
[Bug rtl-optimization/99067] Missed optimization for induction variable elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99067
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #1 from Jim Wilson ---
This looks similar to an ivopts problem I looked at regarding coremark. Given
this testcase
void matrix_add_const_unsigned(unsigned int N, short *A, short val) {
unsigned int i,j;
for (i=0; i
[Bug tree-optimization/21236] force_gimple_operand destroys trees passed to it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21236 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org Status|NEW |WAITING --- Comment #2 from Martin Sebor --- This bug hasn't been updated in over 15 years. Is it worth keeping it open?
[Bug c/92773] [8/9/10/11 Regression] GCC compilation with big array / header is infinite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92773
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #13 from Martin Sebor ---
The output of the much simpler test case below shows the warning repeatedly
prints the same hint over and over, adding to it for each new element of the
outer array. The last two hints are also duplicates of one another. It's easy
to limit the number of warnings for the same initializer to some maximum. A
nicer fix would avoid the duplication altogether.
$ cat t.c && gcc -S -Wall t.c
struct {
int a[8];
}
a [] =
{
{ 0 },
{ 0, 0 },
{ 0, 0, 0 },
{ 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0, 0 }
};
t.c:5:1: warning: missing braces around initializer [-Wmissing-braces]
5 | {
| ^
6 | { 0 },
| { }
7 | { 0, 0 },
| {}
t.c:5:1: warning: missing braces around initializer [-Wmissing-braces]
5 | {
| ^
6 | { 0 },
| { }
7 | { 0, 0 },
| {}
8 | { 0, 0, 0 },
| { }
t.c:5:1: warning: missing braces around initializer [-Wmissing-braces]
5 | {
| ^
6 | { 0 },
| { }
7 | { 0, 0 },
| {}
8 | { 0, 0, 0 },
| { }
9 | { 0, 0, 0, 0 },
| { }
t.c:5:1: warning: missing braces around initializer [-Wmissing-braces]
5 | {
| ^
6 | { 0 },
| { }
7 | { 0, 0 },
| {}
8 | { 0, 0, 0 },
| { }
9 | { 0, 0, 0, 0 },
| { }
10 | { 0, 0, 0, 0, 0 },
| { }
t.c:5:1: warning: missing braces around initializer [-Wmissing-braces]
5 | {
| ^
6 | { 0 },
| { }
7 | { 0, 0 },
| {}
8 | { 0, 0, 0 },
| { }
9 | { 0, 0, 0, 0 },
| { }
10 | { 0, 0, 0, 0, 0 },
| { }
11 | { 0, 0, 0, 0, 0, 0 },
| {}
t.c:5:1: warning: missing braces around initializer [-Wmissing-braces]
5 | {
| ^
6 | { 0 },
| { }
7 | { 0, 0 },
| {}
8 | { 0, 0, 0 },
| { }
9 | { 0, 0, 0, 0 },
| { }
10 | { 0, 0, 0, 0, 0 },
| { }
11 | { 0, 0, 0, 0, 0, 0 },
| {}
12 | { 0, 0, 0, 0, 0, 0, 0 }
| { }
t.c:5:1: warning: missing braces around initializer [-Wmissing-braces]
5 | {
| ^
6 | { 0 },
| { }
7 | { 0, 0 },
| {}
8 | { 0, 0, 0 },
| { }
9 | { 0, 0, 0, 0 },
| { }
10 | { 0, 0, 0, 0, 0 },
| { }
11 | { 0, 0, 0, 0, 0, 0 },
| {}
12 | { 0, 0, 0, 0, 0, 0, 0 }
| { }
[Bug target/99068] New: Missed PowerPC lhau optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99068
Bug ID: 99068
Summary: Missed PowerPC lhau optimization
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: brian.grayson at sifive dot com
Target Milestone: ---
(This relates to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99067 but is a
distinct target optimization bug).
This code:
int16_t a[1000];
int64_t N = 100;
int found_zero_ptr(int *a, int N) {
for (int16_t* p = [0]; p <= [N]; p++) {
if (*p == 0) return 1;
}
return 0;
}
generates this PowerPC assembly under -O3:
...
.L15:
bgt 7,.L12
.L11:
lha 10,0(9)
addi 9,9,2
cmpld 7,9,8
cmpwi 0,10,0
bne 0,.L15
...
In a minor variation of this code, the lha and addi are merged into an lhau.
Why does gcc not do that same merge in the code shown here?
[Bug rtl-optimization/99067] New: Missed optimization for induction variable elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99067
Bug ID: 99067
Summary: Missed optimization for induction variable elimination
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: brian.grayson at sifive dot com
Target Milestone: ---
For RISC-V, this code snippet could eliminate the induction variable for the
loop ending condition.
#include
int16_t a[1000];
int64_t N = 100;
int64_t found_zero() {
for (int i = 0; i <= N; i++) {
if (a[i] == 0) return 1;
}
return 0;
}
gcc -O3 for RISC-V generates:
.L8:
addi a5,a5,2
blt a2,a4,.L4
.L3:
lh a3,0(a5)
addi a4,a4,1 <-- induction variable update that can be eliminated
bne a3,zero,.L8
li a0,1
ret
.L4:
li a0,0
ret
Is there a reason it doesn't do this transform (written at the C level) to do
pointer comparisons:
for (int16_t* p = [0]; p <= [N]; p++) { ... }
That C code is able to remove the extra add instruction:
.L15:
bgtu a5,a3,.L12
.L11:
lh a4,0(a5)
addi a5,a5,2
bne a4,zero,.L15
li a0,1
ret
.L12:
li a0,0
ret
I verified the same issue occurs in PowerPC and ARM code-gen, so this isn't
target-specific.
[Bug c/19449] __builtin_constant_p cannot resolve to const when optimizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19449 Martin Sebor changed: What|Removed |Added Last reconfirmed|2005-12-18 01:38:34 |2021-2-10 Known to fail||11.0, 3.4.2 CC||msebor at gcc dot gnu.org --- Comment #8 from Martin Sebor --- No change in GCC 11: $ gcc -O -S -Wall pr19449.c pr19449.c: In function ‘foo’: pr19449.c:9:15: error: storage size of ‘e’ isn’t constant 9 | static char e[__builtin_constant_p (x) ? -1 : 1]; | ^ pr19449.c:10:15: error: object with variably modified type must have no linkage 10 | extern char f[__builtin_constant_p (x) ? -1 : 1]; | ^ pr19449.c:10:15: error: storage size of ‘f’ isn’t constant pr19449.c:12:8: warning: unused variable ‘h’ [-Wunused-variable] 12 | char h[__builtin_constant_p (x) ? -1 : 1]; |^ pr19449.c:11:13: warning: unused variable ‘g’ [-Wunused-variable] 11 | auto char g[__builtin_constant_p (x) ? -1 : 1]; | ^ pr19449.c:10:15: warning: unused variable ‘f’ [-Wunused-variable] 10 | extern char f[__builtin_constant_p (x) ? -1 : 1]; | ^ pr19449.c:9:15: warning: unused variable ‘e’ [-Wunused-variable] 9 | static char e[__builtin_constant_p (x) ? -1 : 1]; | ^ At top level: pr19449.c:2:13: warning: ‘a’ defined but not used [-Wunused-variable] 2 | static char a[__builtin_constant_p (y) ? -1 : 1]; | ^
[Bug middle-end/21433] The COMPONENT_REF case of expand_expr_real_1 is probably wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21433 Martin Sebor changed: What|Removed |Added Last reconfirmed|2012-01-19 00:00:00 |2021-2-10 CC||msebor at gcc dot gnu.org --- Comment #2 from Martin Sebor --- Instrumenting GCC 11 to print the tree code of the first operand shows the following: array_ref component_ref mem_ref parm_decl result_decl var_decl confirming the code is most likely dead.
[Bug preprocessor/96391] [10 Regression] ICE in linemap_compare_locations on "CONST VOID" in large C++ files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391 --- Comment #23 from qinzhao at gcc dot gnu.org --- with the latest gcc11, our application can be compiled without any issue now. thanks a lot for fixing this bug. will this patch be added to gcc10?
[Bug c/90036] [8/9/10/11 Regression] false positive: directive argument is null [-Werror=format-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90036 Martin Sebor changed: What|Removed |Added Target Milestone|11.0|12.0 Known to fail|9.0 |10.2.0, 11.0, 9.3.0 Last reconfirmed|2019-04-10 00:00:00 |2021-2-10 --- Comment #11 from Martin Sebor --- No progress in GCC 11 but hopefully in GCC 12.
[Bug c++/99059] Static inline variable can't refer to itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99059 --- Comment #1 from Jonathan Wakely --- Looks like a bug.
[Bug c++/99059] Static inline variable can't refer to itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99059 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-02-10 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug libstdc++/99058] Consider adding a note about std::optional ABI break to the C++17 status table
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99058 --- Comment #7 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #6) > +GCC 5.1 was the first release with non-experimental C++11 support, > +so the API and ABI of C++11 components is only stable from that release on. Maybe this should say "of new C++11 components" (and similarly in the other sections) to make it clear that it only applies to features added by C++11, and not everything in the C++11 status table.
[Bug c/22241] completion by initializer incompatible with type in inner scope should be diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22241 Martin Sebor changed: What|Removed |Added Known to fail||10.2.0, 11.0 Last reconfirmed|2012-01-19 00:00:00 |2021-2-10 CC||msebor at gcc dot gnu.org --- Comment #2 from Martin Sebor --- No change in GCC 11.
[Bug libstdc++/99058] Consider adding a note about std::optional ABI break to the C++17 status table
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99058 --- Comment #6 from Jonathan Wakely --- I think the following doc patch would probably help. --- a/libstdc++-v3/doc/xml/manual/status_cxx2011.xml +++ b/libstdc++-v3/doc/xml/manual/status_cxx2011.xml @@ -24,6 +24,8 @@ features. See dialect options. The pre-defined symbol __cplusplus is used to check for the presence of the required flag. +GCC 5.1 was the first release with non-experimental C++11 support, +so the API and ABI of C++11 components is only stable from that release on. diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2014.xml b/libstdc++-v3/doc/xml/manual/status_cxx2014.xml index 61bea5adad5..af4bb6dc736 100644 --- a/libstdc++-v3/doc/xml/manual/status_cxx2014.xml +++ b/libstdc++-v3/doc/xml/manual/status_cxx2014.xml @@ -17,6 +17,8 @@ features. See dialect options. The pre-defined symbol __cplusplus is used to check for the presence of the required flag. +GCC 6.1 was the first release with non-experimental C++14 support, +so the API and ABI of C++14 components is only stable from that release on. diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2017.xml b/libstdc++-v3/doc/xml/manual/status_cxx2017.xml index aa34b8c3cf5..a3c23ba54e8 100644 --- a/libstdc++-v3/doc/xml/manual/status_cxx2017.xml +++ b/libstdc++-v3/doc/xml/manual/status_cxx2017.xml @@ -17,6 +17,8 @@ features. See dialect options. The pre-defined symbol __cplusplus is used to check for the presence of the required flag. +GCC 9.1 was the first release with non-experimental C++17 support, +so the API and ABI of C++17 components is only stable from that release on.
[Bug libstdc++/99058] Consider adding a note about std::optional ABI break to the C++17 status table
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99058 --- Comment #5 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #1) > C++17 support isn't stable until GCC 9 so there is no guarantee of > compatibility between 7 and 8 or 8 and 9. That applies to the entire library > (and language features) not just std::optional. I should clarify that what "applies to the entire library" is the experimental nature of C++17 features. But C++98/11/14 features like std::vector and std::shared_ptr are compatible between GCC 7 and later releases.
[Bug libstdc++/99058] Consider adding a note about std::optional ABI break to the C++17 status table
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99058 --- Comment #4 from Jonathan Wakely --- (In reply to Brad Spencer from comment #3) > Ok. What's the right way for me to learn what version of GCC has stable > support for a C++ version? The release notes: https://gcc.gnu.org/gcc-9/changes.html#libstdcxx > I am under the (possibly mistaken) impression that the libstdc++ ABI (in a > given configuration) has been stable for a very long time, and that > generally integrators (such as Debian or Ubuntu, for example) provide > versions of libstdc++ that are ABI-compatible with code compiled against > previous versions. The shared library ABI is stable. There are no std::optional symbols in the shared library, so changes to std::optional do not affect the ABI of the shared library (only of user code compiled using the libstdc++ headers). > As per https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html this is > reflected in the long-standing .so major version of 6. I know there are > many caveats here, especially around the early introduction of > pre-standardized features, etc. Right, like std::optional. What matters is not whether the features has been standardized but whether it's considered stable in GCC. The features don't suddenly become complete and stable on the day that ISO publishes the next standard. > Is it correct to think that the _intention_ is that it is possible to > configure the library to remain ABI compatible into the future until a > conscious decision is made to introduce an ABI break? Only for parts of the library that are not considered experimental. Support for C++17 in GCC 7 and 8 is experimental, as noted in the release notes: https://gcc.gnu.org/gcc-7/changes.html#libstdcxx https://gcc.gnu.org/gcc-8/changes.html#libstdcxx It is declared no longer experimental in GCC 9: https://gcc.gnu.org/gcc-9/changes.html#libstdcxx If you use experimental pieces (like C++17 support in GCC 8, or C++20 support in GCC 10) then you are giving up the expectation of ABI stability between releases. https://stackoverflow.com/questions/46746878/is-it-safe-to-link-c17-c14-and-c11-objects/49119902#49119902
[Bug tree-optimization/92879] [10/11 Regression] incorrect warning of __builtin_memset offset is out of the bounds on zero-size allocation and initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92879 --- Comment #10 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:21c6ad7a12fecc4c85ac26289d9096379b550585 commit r11-7180-g21c6ad7a12fecc4c85ac26289d9096379b550585 Author: Martin Sebor Date: Wed Feb 10 14:42:22 2021 -0700 Add test for PR tree-optimization/92879. gcc/testsuite/ChangeLog: PR tree-optimization/92879 * g++.dg/warn/Warray-bounds-16.C: New test.
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 92879, which changed state. Bug 92879 Summary: [10/11 Regression] incorrect warning of __builtin_memset offset is out of the bounds on zero-size allocation and initialization https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92879 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/92879] [10/11 Regression] incorrect warning of __builtin_memset offset is out of the bounds on zero-size allocation and initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92879
Martin Sebor changed:
What|Removed |Added
Resolution|--- |FIXED
Known to work||11.0
Status|NEW |RESOLVED
--- Comment #9 from Martin Sebor ---
The warning has disappeared with r11-4745. GCC now emits the following code:
;; Function _GLOBAL__sub_I_a (_GLOBAL__sub_I_a, funcdef_no=5, decl_uid=2418,
cgraph_uid=6, symbol_order=6) (executed once)
void _GLOBAL__sub_I_a ()
{
int i;
void * _5;
[local count: 1073741824]:
MEM[(struct __as_base &)] ={v} {CLOBBER};
a.m = 0;
_5 = operator new [] (0);
a.p = _5;
return;
}
[Bug target/99041] combine creates invalid address which ICEs in decompose_normal_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99041 --- Comment #7 from Segher Boessenkool --- (In reply to Peter Bergner from comment #6) > The mma_assemble_pair/mma_assemble_acc patterns both generate lxv or lxvp > at, which both use a DQ offset and we already have function to > test for that. The following change fixes the ICE, so I'll give it a spin > on regtesting. That looks fine; if that is the only change you need it is pre-approved for trunk. Thanks!
[Bug tree-optimization/86010] [8 Regression] redundant memset with smaller size not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86010 --- Comment #13 from Martin Sebor --- Should this be resolved as fixed per comment #10?
[Bug c/78568] [8/9/10/11 Regression] Wtype-limits warning regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78568 Martin Sebor changed: What|Removed |Added Last reconfirmed|2016-11-29 00:00:00 |2021-2-10 Known to fail|7.0 |10.2.0, 11.0, 7.5.0, 8.3.0, ||9.3.0 --- Comment #12 from Martin Sebor --- No change in GCC 11.
[Bug c++/99040] [modules] partitions & using declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99040 Nathan Sidwell changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-02-10
[Bug c++/99062] [10/11 Regression] ICE in tree_to_uhwi, at tree.h:4579
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99062 --- Comment #5 from Marek Polacek --- (In reply to Martin Sebor from comment #4) > There already is a test in the attribute handler to validate the alignment: > it calls integer_pow2p (val). Val here is: > > constant -2147483648> > but integer_pow2p (val) returns true. I'd expect the function to return > false since INT_MIN is not a power of two. Anyway, the test integer_pow2p > (val) should probably be changed to tree_int_cst_sgn (val) < 0 || > integer_pow2p (val). About to post a patch that hoists the tree_int_cst_sgn check so that we don't have to repeat it.
[Bug target/99041] combine creates invalid address which ICEs in decompose_normal_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99041 Peter Bergner changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #6 from Peter Bergner --- (In reply to Peter Bergner from comment #3) > Ahh, ok. I can make that more robust. Thanks for the pointer! The mma_assemble_pair/mma_assemble_acc patterns both generate lxv or lxvp instructions, which both use a DQ offset and we already have function to test for that. The following change fixes the ICE, so I'll give it a spin on regtesting. diff --git a/gcc/config/rs6000/predicates.md b/gcc/config/rs6000/predicates.md index 76328ecff3d..bd26c62b3a4 100644 --- a/gcc/config/rs6000/predicates.md +++ b/gcc/config/rs6000/predicates.md @@ -1156,7 +1156,9 @@ ;; Return 1 if this operand is valid for a MMA assemble accumulator insn. (define_special_predicate "mma_assemble_input_operand" (match_test "(mode == V16QImode - && (vsx_register_operand (op, mode) || MEM_P (op)))")) + && (vsx_register_operand (op, mode) + || (MEM_P (op) + && quad_address_p (XEXP (op, 0), mode, false")) ;; Return 1 if this operand is valid for an MMA disassemble insn. (define_predicate "mma_disassemble_output_operand"
[Bug c++/99062] [10/11 Regression] ICE in tree_to_uhwi, at tree.h:4579
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99062 --- Comment #4 from Martin Sebor --- There already is a test in the attribute handler to validate the alignment: it calls integer_pow2p (val). Val here is: constant -2147483648> but integer_pow2p (val) returns true. I'd expect the function to return false since INT_MIN is not a power of two. Anyway, the test integer_pow2p (val) should probably be changed to tree_int_cst_sgn (val) < 0 || integer_pow2p (val). Separately, the warning should be enhanced to understand that [x, y) is a half-open range and not complain; then the code can go back to the original [0, %E) without any additional checking.
[Bug preprocessor/93109] #undefine suggests #define but not #undef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93109 David Malcolm changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #4 from David Malcolm --- Eric's analysis in comment #1 is correct. I agree that "#undef" would be a better suggestion for the case in comment #0, but I don't think I agree with comment #2. I'm not sure how to fix this, or if it's worth special-casing it.
[Bug preprocessor/98021] #warning issues redundant diagnostic lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98021 --- Comment #17 from David Malcolm --- One aspect of the original case in comment #0 that hasn't been mentioned in this discussion is that the two #warning messages are related to each other. It looks to me like the author of those lines intended for them to emit a block of related text, but the source-printing gets in the way of this and makes the connection between the two messages less clear. I'm not sure what the best approach here is though.
[Bug middle-end/95140] [10/11 Regression] bogus -Wstringop-overflow for a loop unrolled past the end of an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95140 Martin Sebor changed: What|Removed |Added Summary|[10/11 Regression] bogus|[10/11 Regression] bogus |-Wstringop-overflow for a |-Wstringop-overflow for a |loop unrolled past the end |loop unrolled past the end |of a trailing array |of an array --- Comment #6 from Martin Sebor --- The problem isn't specific to trailing arrays; it can be reproduced with an interior member as well: $ gcc -O3 -S -Wall pr95140.cpr95140.c: In function ‘f’: pr95140.c:9:13: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] 9 | p->v[i] = s[i]; | ^~ pr95140.c:3:8: note: at offset 8 into destination object ‘v’ of size 8 3 | char v[8], u; |^ ... pr95140.c:9:13: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] 9 | p->v[i] = s[i]; | ^~ pr95140.c:3:8: note: at offset 14 into destination object ‘v’ of size 8 3 | char v[8], u; |^
[Bug preprocessor/96391] [10 Regression] ICE in linemap_compare_locations on "CONST VOID" in large C++ files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391 --- Comment #22 from David Malcolm --- *** Bug 96940 has been marked as a duplicate of this bug. ***
[Bug preprocessor/96940] ICE in linemap_compare_locations, at libcpp/line-map.c:1359
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96940 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||dmalcolm at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #3 from David Malcolm --- This does indeed look like a duplicate of bug 96391; note the missing column number, and the two declspecs in different macros here: /x/bcm_sdk/sdk/include/shared/bitop.h:73: internal compiler error: in linemap_compare_locations, at libcpp/line-map.c:1359 73 | CONST SHR_BITDCL *c, | *** This bug has been marked as a duplicate of bug 96391 ***
[Bug libstdc++/99058] Consider adding a note about std::optional ABI break to the C++17 status table
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99058 --- Comment #3 from Brad Spencer --- (In reply to Jonathan Wakely from comment #1) > C++17 support isn't stable until GCC 9 so there is no guarantee of > compatibility between 7 and 8 or 8 and 9. That applies to the entire library > (and language features) not just std::optional. Ok. What's the right way for me to learn what version of GCC has stable support for a C++ version? For example, where would I look to know that C++17 support isn't stable until GCC 9? I can't seem to find that information on the status page, but maybe I am looking in the wrong place. (In reply to Jonathan Wakely from comment #2) > (In reply to Brad Spencer from comment #0) > > Perhaps I was misusing this table, but I interpreted "supported since 7.1" > > to mean that if I compile against 7.1 headers, my code will remain ABI > > compatible against future versions of the library _and_ other code compiled > > against future versions of the headers. > > Absolutely not. Sorry. I was imprecise in my wording. I am not looking for or expecting any guarantees. I am under the (possibly mistaken) impression that the libstdc++ ABI (in a given configuration) has been stable for a very long time, and that generally integrators (such as Debian or Ubuntu, for example) provide versions of libstdc++ that are ABI-compatible with code compiled against previous versions. As per https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html this is reflected in the long-standing .so major version of 6. I know there are many caveats here, especially around the early introduction of pre-standardized features, etc. Is it correct to think that the _intention_ is that it is possible to configure the library to remain ABI compatible into the future until a conscious decision is made to introduce an ABI break? Or, if I ever run code compiled with GCC N against the library from GCC N+1, am I always at risk, with not even best efforts to lean on? I'm not asking you to do more. I just want to get a good understanding of the circumstances of ABI stability.
[Bug preprocessor/96391] [10 Regression] ICE in linemap_compare_locations on "CONST VOID" in large C++ files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391 David Malcolm changed: What|Removed |Added Summary|[10/11 Regression] ICE in |[10 Regression] ICE in |linemap_compare_locations |linemap_compare_locations |on "CONST VOID" in large|on "CONST VOID" in large |C++ files |C++ files --- Comment #21 from David Malcolm --- Should be fixed on trunk by the above commit. Presumably still affects gcc 10 branch. Updating "Summary" accordingly.
[Bug preprocessor/96391] [10/11 Regression] ICE in linemap_compare_locations on "CONST VOID" in large C++ files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391 --- Comment #20 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:1f5c80883efce5242d892eb771ebb60830d20e0f commit r11-7179-g1f5c80883efce5242d892eb771ebb60830d20e0f Author: David Malcolm Date: Wed Feb 10 14:33:10 2021 -0500 libcpp: fix ICE comparing macro locations without column info [PR96391] PR preprocessor/96391 describes an ICE in the C++ frontend on: #define CONST const #define VOID void typedef CONST VOID *PCVOID; where the typedef line occurs after enough code has been compiled that location_t values are beyond LINE_MAP_MAX_LOCATION_WITH_COLS, and hence no column numbers are available. The issue occurs in linemap_compare_locations when comparing the locations of the "const" and "void" tokens. Upon resolving the LRK_MACRO_EXPANSION_POINT, both have the same location_t, the line of the "typedef" (with no column), and so the l0 == l1 clause is triggered, but they are not from the same macro expansion, leading first_map_in_common to return NULL and triggering the "abort" condition. This patch fixes the issue by checking when the two macro expansion point location_t values are equal that the value <= LINE_MAP_MAX_LOCATION_WITH_COLS and thus has column information, fixing the issue. gcc/testsuite/ChangeLog: PR preprocessor/96391 * g++.dg/plugin/location-overflow-test-pr96391.c: New test. * g++.dg/plugin/plugin.exp (plugin_test_list): Add it, using the location_overflow_plugin.c from gcc.dg/plugin. libcpp/ChangeLog: PR preprocessor/96391 * line-map.c (linemap_compare_locations): Require that the location be <= LINE_MAP_MAX_LOCATION_WITH_COLS when treating locations as coming from the same macro expansion.
[Bug fortran/99061] [10/11 Regression] ICE in gfc_conv_intrinsic_atan2d, at fortran/trans-intrinsic.c:4728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99061 Martin Liška changed: What|Removed |Added CC||foreese at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- Just for the record, started with r10-7603-g57391ddaf39f7cb8.
[Bug fortran/99060] [9/10/11 Regression] ICE in gfc_match_varspec, at fortran/primary.c:2411
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99060 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||pault at gcc dot gnu.org --- Comment #2 from Martin Liška --- Just for the record, started with r11-2487-ge41da82345fb01c4.
[Bug c++/99062] [10/11 Regression] ICE in tree_to_uhwi, at tree.h:4579
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99062 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED Priority|P3 |P2 --- Comment #3 from Marek Polacek --- So we need to check that ALIGN is sane.
[Bug target/99025] [11 Regression] ICE Segmentation fault since r11-6351-g12ae2bc70846a2be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99025 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug c++/99035] [9/10 Regression] ICE in declare_weak, at varasm.c:5930
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99035 Jakub Jelinek changed: What|Removed |Added Summary|[9/10/11 Regression] ICE in |[9/10 Regression] ICE in |declare_weak, at|declare_weak, at |varasm.c:5930 |varasm.c:5930 --- Comment #4 from Jakub Jelinek --- Fixed on the trunk (so far).
[Bug c++/99066] [8/9/10/11 Regression] non-weak definition emitted for explicit instantiation declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99066 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2021-02-10 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Jakub Jelinek --- Perhaps caused by PR23691 changes?
[Bug c++/99035] [9/10/11 Regression] ICE in declare_weak, at varasm.c:5930
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99035 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:0f39fb7b001df7cdba56cd5c572d0737667acd2c commit r11-7178-g0f39fb7b001df7cdba56cd5c572d0737667acd2c Author: Jakub Jelinek Date: Wed Feb 10 19:52:37 2021 +0100 varasm: Fix ICE with -fsyntax-only [PR99035] My FE change from 2 years ago uses TREE_ASM_WRITTEN in -fsyntax-only mode more aggressively to avoid "expanding" functions multiple times. With -fsyntax-only nothing is really expanded, so I think it is acceptable to adjust the assert and allow declare_weak at any time, with -fsyntax-only we know it is during parsing only anyway. 2021-02-10 Jakub Jelinek PR c++/99035 * varasm.c (declare_weak): For -fsyntax-only, allow even TREE_ASM_WRITTEN function decls. * g++.dg/ext/weak6.C: New test.
[Bug target/99025] [11 Regression] ICE Segmentation fault since r11-6351-g12ae2bc70846a2be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99025 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:20482cfcc1d3b71e0aec57b5b48685bf0b5402ca commit r11-7177-g20482cfcc1d3b71e0aec57b5b48685bf0b5402ca Author: Jakub Jelinek Date: Wed Feb 10 19:50:11 2021 +0100 i386: Fix ICEs due to simplify_gen_subreg returning NULL [PR99025] In these patterns, we call simplify_gen_subreg on the input operand to create paradoxical subregs that have 2x, 4x or 8x elements as the input operand. That works fine if the input operand is a REG, but when it is a SUBREG, RTL doesn't allow SUBREG of SUBREG and so relies on simplify_subreg actually simplifying it. And e.g. if the input operand is a SUBREG that changes the element mode (floating vs. non-floating) and then combined with a paradoxical subreg (i.e. different size) this can easily fail, then simplify_gen_subreg returns NULL but we still use it in instructions. Fixed by forcing the operands into REG. 2021-02-10 Jakub Jelinek PR target/99025 * config/i386/sse.md (fix_truncv2sfv2di2, v8qiv8hi2, v8qiv8si2, v4qiv4si2, v4hiv4si2, v8qiv8di2, v4qiv4di2, v2qiv2di2, v4hiv4di2, v2hiv2di2, v2siv2di2): Force operands[1] into REG before calling simplify_gen_subreg on it. * gcc.target/i386/pr99025.c: New test.
[Bug libstdc++/99058] Consider adding a note about std::optional ABI break to the C++17 status table
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99058 --- Comment #2 from Jonathan Wakely --- (In reply to Brad Spencer from comment #0) > Perhaps I was misusing this table, but I interpreted "supported since 7.1" > to mean that if I compile against 7.1 headers, my code will remain ABI > compatible against future versions of the library _and_ other code compiled > against future versions of the headers. Absolutely not.
[Bug libstdc++/99058] Consider adding a note about std::optional ABI break to the C++17 status table
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99058 --- Comment #1 from Jonathan Wakely --- C++17 support isn't stable until GCC 9 so there is no guarantee of compatibility between 7 and 8 or 8 and 9. That applies to the entire library (and language features) not just std::optional.
[Bug c++/99031] Comparing pointers to heap-allocated memory is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99031 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Jakub Jelinek --- Fixed.
[Bug c++/98988] delete is not a constant expression with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98988 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug c++/99062] [10/11 Regression] ICE in tree_to_uhwi, at tree.h:4579
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99062 --- Comment #2 from Marek Polacek --- Must be this part: @@ -2935,8 +2936,8 @@ handle_assume_aligned_attribute (tree *node, tree name, tree args, int, /* The misalignment specified by the second argument must be non-negative and less than the alignment. */ warning (OPT_Wattributes, - "%qE attribute argument %E is not in the range [0, %E)", - name, val, align); + "%qE attribute argument %E is not in the range [0, %wu]", + name, val, tree_to_uhwi (align) - 1); *no_add_attrs = true; return NULL_TREE; }
[Bug c++/99066] [8/9/10/11 Regression] non-weak definition emitted for explicit instantiation declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99066 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 Summary|non-weak definition emitted |[8/9/10/11 Regression] |for explicit instantiation |non-weak definition emitted |declaration |for explicit instantiation ||declaration Target Milestone|--- |8.5
[Bug c++/99062] [10/11 Regression] ICE in tree_to_uhwi, at tree.h:4579
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99062 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org, ||msebor at gcc dot gnu.org Last reconfirmed||2021-02-10 Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Target Milestone|--- |10.3 --- Comment #1 from Marek Polacek --- Started with r271338.
[Bug c++/99066] non-weak definition emitted for explicit instantiation declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99066 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org, ||ppalka at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Note, r104000 still doesn't emit it but r104500 already does, so perhaps a 4.1 GCC era regression?
[Bug fortran/99061] [10/11 Regression] ICE in gfc_conv_intrinsic_atan2d, at fortran/trans-intrinsic.c:4728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99061
--- Comment #2 from Steve Kargl ---
On Wed, Feb 10, 2021 at 06:03:56PM +, kargl at gcc dot gnu.org wrote:
> diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
> index 5c9258c65c3..0cf0aa56811 100644
> --- a/gcc/fortran/trans-intrinsic.c
> +++ b/gcc/fortran/trans-intrinsic.c
> @@ -4717,6 +4717,7 @@ gfc_conv_intrinsic_cotand (gfc_se *se, gfc_expr *expr)
> static void
> gfc_conv_intrinsic_atan2d (gfc_se *se, gfc_expr *expr)
> {
> + gfc_intrinsic_map_t *m;
>tree args[2];
>tree atan2d;
>tree type;
> @@ -4724,7 +4725,13 @@ gfc_conv_intrinsic_atan2d (gfc_se *se, gfc_expr *expr)
>gfc_conv_intrinsic_function_args (se, expr, args, 2);
>type = TREE_TYPE (args[0]);
>
> - atan2d = gfc_builtin_decl_for_float_kind (BUILT_IN_ATAN2, expr->ts.kind);
> + /* Find tan builtin function. */
I suppose whomever commits the patch will fix the comment.
> + m = gfc_intrinsic_map;
> + for (; m->id != GFC_ISYM_NONE || m->double_built_in != END_BUILTINS; m++)
> +if (GFC_ISYM_ATAN2 == m->id)
> + break;
> +
> + atan2d = gfc_get_intrinsic_lib_fndecl (m, expr);
>atan2d = build_call_expr_loc (input_location, atan2d, 2, args[0], args[1]);
>
>se->expr = fold_build2_loc (input_location, MULT_EXPR, type, atan2d,
[Bug c++/99031] Comparing pointers to heap-allocated memory is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99031 --- Comment #1 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a8db7887dfbf502b7e60d64bfeebd0de592d2d45 commit r11-7176-ga8db7887dfbf502b7e60d64bfeebd0de592d2d45 Author: Jakub Jelinek Date: Wed Feb 10 19:31:15 2021 +0100 c++: Consider addresses of heap artificial vars always non-NULL [PR98988, PR99031] With -fno-delete-null-pointer-checks which is e.g. implied by -fsanitize=undefined or default on some embedded targets, the middle-end folder doesn't consider addresses of global VAR_DECLs to be non-NULL, as one of them could have address 0. Still, I think malloc/operator new (at least the nonthrowing) relies on NULL returns meaning allocation failure rather than success. Furthermore, the artificial VAR_DECLs we create for constexpr new never actually live in the address space of the program, so we can pretend they will never be NULL too. > I'm surprised that nonzero_address has such a limited set of things it will > actually believe have non-zero addresses with > -fno-delete-null-pointer-checks. But it seems that we should be able to > arrange to satisfy > > > if (definition && !DECL_EXTERNAL (decl) > > since these "variables" are indeed defined within the current translation > unit. Doing that seems to work and as added benefit it fixes another PR that has been filed recently. I need to create the varpool node explicitly and call a method that sets the definition member in there, but I can also unregister those varpool nodes at the end of constexpr processing, as the processing ensured they don't leak outside of the processing. 2021-02-10 Jakub Jelinek PR c++/98988 PR c++/99031 * constexpr.c: Include cgraph.h. (cxx_eval_call_expression): Call varpool_node::finalize_decl on heap artificial vars. (cxx_eval_outermost_constant_expr): Remove varpool nodes for heap artificial vars. * g++.dg/cpp2a/constexpr-new16.C: New test. * g++.dg/cpp2a/constexpr-new17.C: New test.
[Bug c++/98988] delete is not a constant expression with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98988 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a8db7887dfbf502b7e60d64bfeebd0de592d2d45 commit r11-7176-ga8db7887dfbf502b7e60d64bfeebd0de592d2d45 Author: Jakub Jelinek Date: Wed Feb 10 19:31:15 2021 +0100 c++: Consider addresses of heap artificial vars always non-NULL [PR98988, PR99031] With -fno-delete-null-pointer-checks which is e.g. implied by -fsanitize=undefined or default on some embedded targets, the middle-end folder doesn't consider addresses of global VAR_DECLs to be non-NULL, as one of them could have address 0. Still, I think malloc/operator new (at least the nonthrowing) relies on NULL returns meaning allocation failure rather than success. Furthermore, the artificial VAR_DECLs we create for constexpr new never actually live in the address space of the program, so we can pretend they will never be NULL too. > I'm surprised that nonzero_address has such a limited set of things it will > actually believe have non-zero addresses with > -fno-delete-null-pointer-checks. But it seems that we should be able to > arrange to satisfy > > > if (definition && !DECL_EXTERNAL (decl) > > since these "variables" are indeed defined within the current translation > unit. Doing that seems to work and as added benefit it fixes another PR that has been filed recently. I need to create the varpool node explicitly and call a method that sets the definition member in there, but I can also unregister those varpool nodes at the end of constexpr processing, as the processing ensured they don't leak outside of the processing. 2021-02-10 Jakub Jelinek PR c++/98988 PR c++/99031 * constexpr.c: Include cgraph.h. (cxx_eval_call_expression): Call varpool_node::finalize_decl on heap artificial vars. (cxx_eval_outermost_constant_expr): Remove varpool nodes for heap artificial vars. * g++.dg/cpp2a/constexpr-new16.C: New test. * g++.dg/cpp2a/constexpr-new17.C: New test.
[Bug c++/99066] New: non-weak definition emitted for explicit instantiation declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99066
Bug ID: 99066
Summary: non-weak definition emitted for explicit instantiation
declaration
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: link-failure
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
If two TUs both include a header that contains:
template struct basic_string {
static const int npos = 1;
};
template const int basic_string::npos;
struct e { template int f() const; };
template int e::f() const {
return basic_string::npos;
}
extern template class basic_string;
then we get a linker error, because both TUs define the npos constant:
/usr/bin/ld: /tmp/ccjy3Spq.o:(.rodata+0x0): multiple definition of
`basic_string::npos'; /tmp/ccMQ33nr.o:(.rodata+0x0): first defined here
Shouldn't the static data member only have weak definitions, unless an explicit
instantiation definition is seen?
/* TU 1 */
#include "str.h"
int main()
{
return e().f();
}
/* TU 2 */
#include "str.h"
The assembly for both files contains:
.globl _ZN12basic_stringIcE4nposE
.section.rodata
.align 4
.type _ZN12basic_stringIcE4nposE, @object
.size _ZN12basic_stringIcE4nposE, 4
_ZN12basic_stringIcE4nposE:
.long 1
[Bug analyzer/99064] [11 regression] ICE analyzer::print_mem_ref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99064 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-02-10 --- Comment #1 from David Malcolm --- Thanks for filing this. Confirmed. Seems similar to PR analyzer/98969; not sure if a dup yet.
[Bug fortran/99060] [9/10/11 Regression] ICE in gfc_match_varspec, at fortran/primary.c:2411
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99060
kargl at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2021-02-10
Ever confirmed|0 |1
Priority|P3 |P4
Status|UNCONFIRMED |NEW
CC||kargl at gcc dot gnu.org
--- Comment #1 from kargl at gcc dot gnu.org ---
Avoid NULL pointer dereference. Not regression tested.
diff --git a/gcc/fortran/primary.c b/gcc/fortran/primary.c
index d0610d02ebd..7633e77909f 100644
--- a/gcc/fortran/primary.c
+++ b/gcc/fortran/primary.c
@@ -2407,11 +2407,15 @@ gfc_match_varspec (gfc_expr *primary, int equiv_flag,
bool sub_flag,
component = NULL;
if (intrinsic && !inquiry)
- {
- gfc_error ("%qs at %C is not an inquiry reference to an intrinsic "
-"type component %qs", name, previous->name);
+ {
+ if (previous)
+ gfc_error ("%qs at %C is not an inquiry reference to an intrinsic "
+ "type component %qs", name, previous->name);
+ else
+ gfc_error ("%qs at %C is not an inquiry reference to an intrinsic "
+ "type component", name);
return MATCH_ERROR;
- }
+ }
else if (component == NULL && !inquiry)
return MATCH_ERROR;
[Bug fortran/99065] New: ASSOCIATE function selector expression "no IMPLICIT type" failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99065 Bug ID: 99065 Summary: ASSOCIATE function selector expression "no IMPLICIT type" failure Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: pault at gcc dot gnu.org Target Milestone: --- Created attachment 50164 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50164=edit Testcase illustrating the failure This bug was detected in testing variations of the testcase in PR98897. The attached fails with: ../pr98897/foo1.f90:9:20: 9 | print *, var%i |1 Error: Symbol ‘var’ at (1) has no IMPLICIT type If the contained procedures 'foo' and 'bar' are interchanged it compiles and produces the intended result. All component references suffer from this problem. Intrinsic types are fixed up by parse.c(gfc_fixup_sibling_symbols) but there is no simple way to do this for derived type or class selectors. Certain operator expressions also suffer from this problem. It is caused by parsing and matching in gfortran being single pass. This means that unless the specification of 'bar', in this case, has been obtained, the type of 'var' cannot be determined and primary.c(gfc_match_varspec) is bound to return MATCH_NO. I am looking at either two passes for contained procedures (specification blocks first, followed by code blocks) or a fixup in gfc_match_varspec that looks through the derived types for successful matches. Paul
[Bug fortran/99061] [10/11 Regression] ICE in gfc_conv_intrinsic_atan2d, at fortran/trans-intrinsic.c:4728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99061
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
Last reconfirmed||2021-02-10
Priority|P3 |P4
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from kargl at gcc dot gnu.org ---
Patch tested with
program p
real(4) :: z4, a4 = 1.0_4
real(8) :: z8, a8 = 1.0_8
real(10) :: z0, a0 = 1.0_10
real(16) :: z6, a6 = 1.0_16
z4 = atan2d(a4, a4)
z8 = atan2d(a8, a8)
z0 = atan2d(a0, a0)
z6 = atan2d(a6, a6)
print *, z4
print *, z8
print *, z0
print *, z6
end
Patch has not been regression tested.
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 5c9258c65c3..0cf0aa56811 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -4717,6 +4717,7 @@ gfc_conv_intrinsic_cotand (gfc_se *se, gfc_expr *expr)
static void
gfc_conv_intrinsic_atan2d (gfc_se *se, gfc_expr *expr)
{
+ gfc_intrinsic_map_t *m;
tree args[2];
tree atan2d;
tree type;
@@ -4724,7 +4725,13 @@ gfc_conv_intrinsic_atan2d (gfc_se *se, gfc_expr *expr)
gfc_conv_intrinsic_function_args (se, expr, args, 2);
type = TREE_TYPE (args[0]);
- atan2d = gfc_builtin_decl_for_float_kind (BUILT_IN_ATAN2, expr->ts.kind);
+ /* Find tan builtin function. */
+ m = gfc_intrinsic_map;
+ for (; m->id != GFC_ISYM_NONE || m->double_built_in != END_BUILTINS; m++)
+if (GFC_ISYM_ATAN2 == m->id)
+ break;
+
+ atan2d = gfc_get_intrinsic_lib_fndecl (m, expr);
atan2d = build_call_expr_loc (input_location, atan2d, 2, args[0], args[1]);
se->expr = fold_build2_loc (input_location, MULT_EXPR, type, atan2d,
[Bug c++/99063] [9/10/11 Regression] ICE in prep_operand, at cp/call.c:5842
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99063 Marek Polacek changed: What|Removed |Added Priority|P3 |P2
[Bug c++/99063] [9/10/11 Regression] ICE in prep_operand, at cp/call.c:5842
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99063 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||jason at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Last reconfirmed||2021-02-10 Target Milestone|--- |9.4 --- Comment #1 from Marek Polacek --- Started with r247842: commit 0ea37ae178ba156ec9f88134acc4bb13665c56ef Author: Jason Merrill Date: Wed May 10 11:56:09 2017 -0400 PR c++/79549 - C++17 ICE with non-type auto template parameter pack * pt.c (convert_template_argument): Just return an argument pack. (coerce_template_parameter_pack, template_parm_to_arg) (extract_fnparm_pack, make_argument_pack, tsubst_template_args) (tsubst_decl, tsubst, type_unification_real, unify_pack_expansion): Don't set the type of a NONTYPE_ARGUMENT_PACK. * parser.c (make_char_string_pack, make_string_pack): Likewise.
[Bug analyzer/99064] New: [11 regression] ICE analyzer::print_mem_ref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99064
Bug ID: 99064
Summary: [11 regression] ICE analyzer::print_mem_ref
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dimhen at gmail dot com
Target Milestone: ---
gcc version 11.0.0 20210104 (experimental) [master revision
7f2b7317566:9da1da01aec:39bd65faee3bafe2dc067e5fedb5079896551a8a] (GCC)
r11-6442 PASS
gcc version 11.0.0 20210108 (experimental) [master revision
bdcde150450:e18dcf9fcae:b407f233d7c18534fbfe8f74af7f0232498fb0c4] (GCC)
r11-6550 FAIL
gcc version 11.0.0 20210210 (experimental) [master revision
bd0e37f68a3:deed5164277:72932511053596091ad291539022b51d9f2ba418] (GCC)
r11-7168 FAIL
$ cat x.ii
template struct iterator_traits;
template struct iterator_traits<_Tp *> {
typedef _Tp
};
template struct __normal_iterator {
_Iterator _M_current;
__normal_iterator(_Iterator &__i) : _M_current(__i) {}
typename iterator_traits<_Iterator>::reference operator*() {
return *_M_current;
}
};
template struct allocator;
template struct allocator_traits;
template struct allocator_traits> {
using pointer = _Tp *;
};
struct TPkcs11Token;
struct __alloc_traits : allocator_traits> {};
struct _Vector_base {
typedef __alloc_traits::pointer pointer;
struct {
pointer _M_start;
} _M_impl;
};
struct : _Vector_base {
__normal_iterator begin() { return _M_impl._M_start; }
} list_tokens_token_list;
struct TPkcs11Token {
int *add_info;
};
void list_tokens() {
for (__normal_iterator base = list_tokens_token_list.begin();;) {
int *add_info = new int;
(*base).add_info = add_info;
}
}
// cvise'd from private codebase
$ gcc_current/bin/g++ -fpreprocessed -O2 -fanalyzer -c x.ii
during IPA pass: analyzer
x.ii:34:22: internal compiler error: Segmentation fault
34 | (*base).add_info = add_info;
| ~^~
0x12baa3f crash_signal
/home/dimhen/src/gcc_current/gcc/toplev.c:327
0xd7f150 print_mem_ref
/home/dimhen/src/gcc_current/gcc/c-family/c-pretty-print.c:2006
0xb7b035 dump_expr
/home/dimhen/src/gcc_current/gcc/cp/error.c:2367
0xb80640 expr_to_string(tree_node*)
/home/dimhen/src/gcc_current/gcc/cp/error.c:3188
0xb80d7c cp_printer
/home/dimhen/src/gcc_current/gcc/cp/error.c:4356
0x1f28c86 pp_format(pretty_printer*, text_info*)
/home/dimhen/src/gcc_current/gcc/pretty-print.c:1475
0x16533cc ana::evdesc::event_desc::formatted_print(char const*, ...) const
/home/dimhen/src/gcc_current/gcc/analyzer/pending-diagnostic.cc:64
0x1eb67a6 ana::warning_event::get_desc(bool) const
/home/dimhen/src/gcc_current/gcc/analyzer/checker-path.cc:885
0x1eb60f2 ana::checker_event::prepare_for_emission(ana::checker_path*,
ana::pending_diagnostic*, diagnostic_event_id_t)
/home/dimhen/src/gcc_current/gcc/analyzer/checker-path.cc:149
0x1ec64f3 ana::checker_path::prepare_for_emission(ana::pending_diagnostic*)
/home/dimhen/src/gcc_current/gcc/analyzer/checker-path.h:559
0x1ec64f3 ana::diagnostic_manager::emit_saved_diagnostic(ana::exploded_graph
const&, ana::saved_diagnostic const&, ana::exploded_path const&, gimple const*,
int)
/home/dimhen/src/gcc_current/gcc/analyzer/diagnostic-manager.cc:668
0x1ec8a80 ana::dedupe_winners::emit_best(ana::diagnostic_manager*,
ana::exploded_graph const&)
/home/dimhen/src/gcc_current/gcc/analyzer/diagnostic-manager.cc:569
0x1ec68c8 ana::diagnostic_manager::emit_saved_diagnostics(ana::exploded_graph
const&)
/home/dimhen/src/gcc_current/gcc/analyzer/diagnostic-manager.cc:622
0x1649d32 ana::impl_run_checkers(ana::logger*)
/home/dimhen/src/gcc_current/gcc/analyzer/engine.cc:4744
0x164aafe ana::run_checkers()
/home/dimhen/src/gcc_current/gcc/analyzer/engine.cc:4801
0x163d568 execute
/home/dimhen/src/gcc_current/gcc/analyzer/analyzer-pass.cc:87
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ gcc_current/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/home/dimhen/arch-gcc/gcc_current/bin/g++
COLLECT_LTO_WRAPPER=/home/dimhen/arch-gcc/gcc_current/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
Target: x86_64-pc-linux-gnu
Configured with: /home/dimhen/src/gcc_current/configure
--prefix=/home/dimhen/arch-gcc/gcc_current
--enable-checking=yes,df,fold,rtl,extra --enable-languages=c,c++,lto
--disable-multilib --enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl
--enable-offload-targets=nvptx-
[Bug driver/87758] --print-file-name= ignores -L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87758 npl at chello dot at changed: What|Removed |Added CC||npl at chello dot at --- Comment #4 from npl at chello dot at --- Is it really an excuse that it behaved like that forever? Given that -march and -sysroot (and spec files AFAIR) already affect the search paths, its not reasonable to expect -L wont work. I know that the linker is separate, but just adding the searchpath should be easy? If there is a new flag, please show in the returncode whether the library was found or not. If you want to inquire the linker, then maybe some "link-only" mode would be better, just invoking the linker with the usual flags and passing though additional commands.
[Bug c/99055] memory leak in warn_parm_array_mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99055 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #1 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565139.html
[Bug c++/99063] New: [9/10/11 Regression] ICE in prep_operand, at cp/call.c:5842
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99063
Bug ID: 99063
Summary: [9/10/11 Regression] ICE in prep_operand, at
cp/call.c:5842
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 with r8 (before 20180525) :
$ cat z1.cc
template
void f (a... n)
{
do; while (--n); {}
}
void g ()
{
f(3);
}
$ cat z2.cc
template
void f (a... n)
{
do; while (n--); {}
}
void g ()
{
f(1,2);
}
$ g++-11-20210207 -c z1.cc
z1.cc: In instantiation of 'void f(a ...) [with a = {int}]':
z1.cc:8:6: required from here
z1.cc:4:14: internal compiler error: Segmentation fault
4 | do; while (--n); {}
| ^~~
0xcd922f crash_signal
../../gcc/toplev.c:327
0x66567d prep_operand
../../gcc/cp/call.c:5842
0x677955 build_new_op_1
../../gcc/cp/call.c:6224
0x6786c0 build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node**, int)
../../gcc/cp/call.c:6676
0x80d982 build_x_unary_op(unsigned int, tree_code, cp_expr, int)
../../gcc/cp/typeck.c:6136
0x7b5e11 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:19737
0x7c6a67 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:19084
0x7c65f8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18411
0x7c5c17 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18475
0x7ba4f3 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:25835
0x7ba4f3 instantiate_body
../../gcc/cp/pt.c:25835
0x7bb580 instantiate_decl(tree_node*, bool, bool)
../../gcc/cp/pt.c:26124
0x7d5bab instantiate_pending_templates(int)
../../gcc/cp/pt.c:26203
0x6ecab2 c_parse_final_cleanups()
../../gcc/cp/decl2.c:4965
[Bug c++/99062] New: [10/11 Regression] ICE in tree_to_uhwi, at tree.h:4579
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99062
Bug ID: 99062
Summary: [10/11 Regression] ICE in tree_to_uhwi, at tree.h:4579
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 20190512 and 20190519 :
$ cat z1.cc
enum { a = 1 << 31 };
void *f () __attribute__ ((assume_aligned (a, 4)));
$ g++-11-20210207 -c z1.cc
z1.cc:2:50: internal compiler error: in tree_to_uhwi, at tree.h:4579
2 | void *f () __attribute__ ((assume_aligned (a, 4)));
| ^
0x8835a6 tree_to_uhwi(tree_node const*)
../../gcc/tree.h:4579
0x8835a6 handle_assume_aligned_attribute
../../gcc/c-family/c-attribs.c:3565
0x823311 decl_attributes(tree_node**, tree_node*, int, tree_node*)
../../gcc/attribs.c:724
0x6e6fc7 cplus_decl_attributes(tree_node**, tree_node*, int)
../../gcc/cp/decl2.c:1596
0x6272a2 grokfndecl
../../gcc/cp/decl.c:9983
0x6d5261 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
../../gcc/cp/decl.c:13818
0x6da5f8 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc/cp/decl.c:5333
0x79bffb cp_parser_init_declarator
../../gcc/cp/parser.c:21660
0x77cf3a cp_parser_simple_declaration
../../gcc/cp/parser.c:14381
0x7a0ea5 cp_parser_declaration
../../gcc/cp/parser.c:14078
0x7a03db cp_parser_translation_unit
../../gcc/cp/parser.c:4936
0x7a03db c_parse_file()
../../gcc/cp/parser.c:45179
0x86d982 c_common_parse_file()
../../gcc/c-family/c-opts.c:1218
[Bug fortran/99061] New: [10/11 Regression] ICE in gfc_conv_intrinsic_atan2d, at fortran/trans-intrinsic.c:4728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99061 Bug ID: 99061 Summary: [10/11 Regression] ICE in gfc_conv_intrinsic_atan2d, at fortran/trans-intrinsic.c:4728 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: --- Changed between 20200308 and 20200412 : $ cat z1.f90 program p real(16) :: a = 1.0_16 z = atan2d(a, a) end $ gfortran-10-20200308 -c z1.f90 $ $ gfortran-11-20210207 -c z1.f90 z1.f90:3:19: 3 |z = atan2d(a, a) | 1 internal compiler error: Segmentation fault 0xc093ef crash_signal ../../gcc/toplev.c:327 0xe8528e build_call_expr_loc_array(unsigned int, tree_node*, int, tree_node**) ../../gcc/tree.c:11558 0xe8536f build_call_expr_loc(unsigned int, tree_node*, int, ...) ../../gcc/tree.c:11591 0x792bc9 gfc_conv_intrinsic_atan2d ../../gcc/fortran/trans-intrinsic.c:4728 0x792bc9 gfc_conv_intrinsic_function(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-intrinsic.c:10296 0x767aaa gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:8878 0x76a973 gfc_conv_expr_val(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:8931 0x77bbbc gfc_conv_intrinsic_function_args ../../gcc/fortran/trans-intrinsic.c:235 0x77c026 gfc_conv_intrinsic_conversion ../../gcc/fortran/trans-intrinsic.c:293 0x7930a5 gfc_conv_intrinsic_function(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-intrinsic.c:10338 0x767aaa gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:8878 0x777601 gfc_trans_assignment_1 ../../gcc/fortran/trans-expr.c:11167 0x739b67 trans_code ../../gcc/fortran/trans.c:1922 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 rtl-optimization/98986] Try matching both orders of commutative RTX operations when there is no canonical order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98986 --- Comment #6 from Segher Boessenkool --- (In reply to rguent...@suse.de from comment #4) > So this is where the "autogenerated" part comes in. We should have > an idea what might be useful and what isn't even worth trying by > looking at the machine description (which might require exposing > costs in such form for this case of constants). > > For commutative operands maybe recog itself can be relaxed and > accept the insn with the "wrong" commutation (or fix it up > itself) for example. Or maybe genrecog can magically emit > commutated variants (like genmatch does for :c annotated > expression branches). We could probably derive what things in an RTL expression are commutative (even if there are many quantities in play), but only allowing the canonical forms in that is a daunting task. Something like :c could help; we already have % in RTL, but we need more general than that (examples: a+b+c and a*b+c*d should both be handled some way, since such cases (structure, not necessarily those exact ops) happen a lot in practice.
[Bug fortran/99060] New: [9/10/11 Regression] ICE in gfc_match_varspec, at fortran/primary.c:2411
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99060 Bug ID: 99060 Summary: [9/10/11 Regression] ICE in gfc_match_varspec, at fortran/primary.c:2411 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: --- Changed between 20200726 and 20200809 : $ cat z1.f90 program p real :: a print *, a%kind%n end $ gfortran-11-20200726 -c z1.f90 z1.f90:3:20: 3 |print *, a%kind%n |1 Error: Expected expression in PRINT statement at (1) $ gfortran-11-20210207 -c z1.f90 f951: internal compiler error: Segmentation fault 0xc093ef crash_signal ../../gcc/toplev.c:327 0x6eaa63 gfc_match_varspec(gfc_expr*, int, bool, bool) ../../gcc/fortran/primary.c:2411 0x6ec2e1 gfc_match_rvalue(gfc_expr**) ../../gcc/fortran/primary.c:3849 0x6c0c4e match_primary ../../gcc/fortran/matchexp.c:157 0x6c0c4e match_level_1 ../../gcc/fortran/matchexp.c:211 0x6c0c4e match_mult_operand ../../gcc/fortran/matchexp.c:267 0x6c0e98 match_add_operand ../../gcc/fortran/matchexp.c:356 0x6c10ec match_level_2 ../../gcc/fortran/matchexp.c:480 0x6c1242 match_level_3 ../../gcc/fortran/matchexp.c:551 0x6c1334 match_level_4 ../../gcc/fortran/matchexp.c:599 0x6c1334 match_and_operand ../../gcc/fortran/matchexp.c:693 0x6c1522 match_or_operand ../../gcc/fortran/matchexp.c:722 0x6c15f2 match_equiv_operand ../../gcc/fortran/matchexp.c:765 0x6c16c4 match_level_5 ../../gcc/fortran/matchexp.c:811 0x6c0aa1 gfc_match_expr(gfc_expr**) ../../gcc/fortran/matchexp.c:870 0x6a8a69 match_io_element ../../gcc/fortran/io.c:3661 0x6ab345 match_io_list ../../gcc/fortran/io.c:3709 0x6ab744 match_io ../../gcc/fortran/io.c:4387 0x6af1ca gfc_match_print() ../../gcc/fortran/io.c:4443 0x6db9c1 match_word ../../gcc/fortran/parse.c:65
[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 #19 from David Malcolm --- (In reply to David Malcolm from comment #18) > Converting one of both of those "const" and "void" to non-macros ought to "one or both", I meant to say
[Bug libstdc++/88881] std::filesystem::status gives bad results on mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1 --- Comment #15 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:3df5b249b3c81e95cdcb293a388155ae5b168f9e commit r11-7174-g3df5b249b3c81e95cdcb293a388155ae5b168f9e Author: Jonathan Wakely Date: Wed Feb 10 16:51:34 2021 + libstdc++: Re-enable workaround for _wstat64 bug [PR 1] This wasn't fixed upstream for mingw-w64 so we still need the workaround. libstdc++-v3/ChangeLog: PR libstdc++/1 * src/c++17/fs_ops.cc (fs::status): Re-enable workaround.
[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
Last reconfirmed||2021-02-10
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
--- Comment #18 from David Malcolm ---
(In reply to qinzhao from comment #17)
> (In reply to David Malcolm from comment #15)
> > /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1-x86/widget/windows/
> > Unified_cpp_widget_windows0.cpp:2:
> > /usr/i686-w64-mingw32/sys-root/mingw/include/cfgmgr32.h: At global scope:
> > /usr/i686-w64-mingw32/sys-root/mingw/include/cfgmgr32.h:19: note: loc_a
> >19 | typedef CONST VOID *PCVOID;
>
> Is the above line the failing point for the testing file?
>
> there is a "CONST" qualifier. I am not sure whether it's helpful or not: we
> found that deleting "CONST" from the source code helped the compilation to
> succeed.
Yes.
Note how there are no column numbers for the macro invocation locations.
The issue occurs when location_t > LINE_MAP_MAX_LOCATION_WITH_COLS (enough
source has been compiled that we've stopped tracking column numbers).
We have two locations that are both from macro expansions, and return the same
output from:
linemap_resolve_location (set, [...], LRK_MACRO_EXPANSION_POINT, NULL);
i.e. line 19 of cfgmgr32.h
cc1plus attempts to compare the locations of the two declarators ("const" and
"void"), decides that they are the same location, and assumes they must be from
the same macro expansion - but they're only at the same location because we're
no longer attempting to track column numbers.
Converting one of both of those "const" and "void" to non-macros ought to work
around it.
I've created a minimal reproducer and will attempt a fix.
[Bug rtl-optimization/98986] Try matching both orders of commutative RTX operations when there is no canonical order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98986 --- Comment #5 from Segher Boessenkool --- (In reply to rsand...@gcc.gnu.org from comment #3) > FWIW, another similar thing I've wanted in the past is to try > recognising multiple possible constants in an (and X (const_int N)) > when X is known to have some bits clear. Often we try to make N contain > as few bits as possible, but that can give worse results than a fuller mask. This could be done in the target machine description, where it makes a lot more sense to do anyway, *if* nonzero_bits was generally usable there. I have Plans for that for GCC 12, but don't depend on it please :-)
[Bug middle-end/38474] compile time explosion in dataflow_set_preserve_mem_locs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #93 from Jakub Jelinek --- I think I'd go for more chains by default, at least 64 or even 256, with a param and tracking on how many we have in a counter. The class has a ctor/dtor, so the increment/decrement of the counter can be done there. And I think it is doubly-linked, so tail should be prev on the head.
[Bug rtl-optimization/98692] Unitialized Values reported only with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692 --- Comment #24 from Segher Boessenkool --- I do see the problems for savegpr/restgpr with that suggestion, but maybe something in that vein can be done.
[Bug rtl-optimization/98692] Unitialized Values reported only with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692 --- Comment #23 from Segher Boessenkool --- savegpr/restgpr are special ABI-defined functions that do not have all the same ABI calling conventions as normal functions. They indeed write into the parent's frame (red zone, in this case). Maybe you should allow this always when a function has not established a new frame? That always has to be done with a stdu 1,...(1) insn (in 64-bit; stwu in 32-bit, but the 32-bit Linux ABI has no red zone anyway) so it probably isn't too hard to detect. Only leaf functions will not establish a new frame normally (but that can happen later in the function, esp. with shrink-wrapping). Unstacking a frame is most other things that write to r1, often addi 1,1,... and sometimes ld 1,0(1) (there probably are other cases too that I am forgetting here). Maybe you should invalidate the red zone whenever r1 is changed, instead?
[Bug middle-end/38474] compile time explosion in dataflow_set_preserve_mem_locs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #92 from Richard Biener ---
Simple and stupid like the below works and does
store merging : 0.42 ( 1%) 0.00 ( 0%) 0.43 ( 1%)
3858k ( 1%)
TOTAL : 56.86 0.56 57.45
557M
we have a limit of 64 stores in a single chain, so the product of both limits
limit the number of alias queries done in terminate_all_aliasing_chains. I'll
polish it up tomorrow (and will refrain from trying to avoid the linear
walk here and keeping a counter or even a pointer to the last element).
diff --git a/gcc/gimple-ssa-store-merging.c b/gcc/gimple-ssa-store-merging.c
index f0f4a068de5..c6ec6b2cbce 100644
--- a/gcc/gimple-ssa-store-merging.c
+++ b/gcc/gimple-ssa-store-merging.c
@@ -5175,6 +5175,19 @@ pass_store_merging::process_store (gimple *stmt)
/* Store aliases any existing chain? */
ret |= terminate_all_aliasing_chains (NULL, stmt);
+ unsigned cnt = 0;
+ imm_store_chain_info **e = _stores_head;
+ while (*e)
+if (++cnt > 16)
+ {
+ if (dump_file && (dump_flags & TDF_DETAILS))
+ fprintf (dump_file, "Too many chains, terminating oldest before "
+ "starting a new chain.\n");
+ terminate_and_process_chain (*e);
+ }
+else
+ e = &(*e)->next;
+
/* Start a new chain. */
class imm_store_chain_info *new_chain
= new imm_store_chain_info (m_stores_head, base_addr);
[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 #17 from qinzhao at gcc dot gnu.org --- (In reply to David Malcolm from comment #15) > where: > > (gdb) call inform (loc_a, "loc_a") > In file included from > /usr/i686-w64-mingw32/sys-root/mingw/include/minwindef.h:163, > from > /usr/i686-w64-mingw32/sys-root/mingw/include/windef.h:8, > from > /usr/i686-w64-mingw32/sys-root/mingw/include/windows.h:69, > from > /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1/widget/windows/ > AudioSession.cpp:7, > from > /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1-x86/widget/windows/ > Unified_cpp_widget_windows0.cpp:2: > /usr/i686-w64-mingw32/sys-root/mingw/include/cfgmgr32.h: At global scope: > /usr/i686-w64-mingw32/sys-root/mingw/include/cfgmgr32.h:19: note: loc_a >19 | typedef CONST VOID *PCVOID; Is the above line the failing point for the testing file? there is a "CONST" qualifier. I am not sure whether it's helpful or not: we found that deleting "CONST" from the source code helped the compilation to succeed.
[Bug middle-end/38474] compile time explosion in dataflow_set_preserve_mem_locs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #91 from Richard Biener --- So the other simple idea I have is to limit the number of active store groups and force-terminate in either a LRU or FIFO manner. For the testcase at hand the decls we start the chain for are all only used in full but knowing that would require some pre-analysis of the IL similar to what SRA does for example (collecting all accesses). It's then also still easy to "break" such heuristic so limiting is in the end the only (and I guess best) option.
[Bug middle-end/38474] compile time explosion in dataflow_set_preserve_mem_locs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #90 from Jakub Jelinek --- Because it says that the whole range is uninitialized, so the store merging code doesn't need to care about pre-existing content in any gaps between the stored values. So say when the whole var is clobbered and then the code stores to every second bitfield, we don't need to read the old content, mask it, or with the stored bits and store that, but can just put some suitable value into the gaps (0 or all ones or whatever is best). For quadratic behavior, I wonder if we just shouldn't see how many chains are we tracking currently and if we have too many (some param), terminate all of them.
[Bug middle-end/38474] compile time explosion in dataflow_set_preserve_mem_locs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #89 from Richard Biener ---
Fallout includes
FAIL: g++.dg/opt/store-merging-1.C scan-tree-dump store-merging "New sequence
of [12] stores to replace old one of 2 stores"
which shows
Starting new chain with statement:
s ={v} {CLOBBER};
The base object is:
Recording immediate store from stmt:
s.a = 0;
Recording immediate store from stmt:
s.b = 0;
stmt causes chain termination:
foo (s);
and the CLOBBER allows us to use zeros for padding:
Store 0:
bitsize:64 bitpos:0 val:{CLOBBER}
Store 1:
bitsize:32 bitpos:0 val:0
Store 2:
bitsize:8 bitpos:32 val:0
After writing {CLOBBER} of size 64 at position 0
the merged value contains 00 00 00 00 00 00 00 00
the merged mask contains 00 00 00 00 00 00 00 00
After writing 0 of size 32 at position 0
the merged value contains 00 00 00 00 00 00 00 00
the merged mask contains 00 00 00 00 00 00 00 00
After writing 0 of size 8 at position 32
the merged value contains 00 00 00 00 00 00 00 00
the merged mask contains 00 00 00 00 00 00 00 00
Coalescing successful!
Merged into 1 stores
New sequence of 1 stores to replace old one of 2 stores
# .MEM_6 = VDEF <.MEM_5>
MEM [(void *)] = 0;
Merging successful!
[Bug c/99055] memory leak in warn_parm_array_mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99055 Martin Sebor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-02-10 CC||msebor at gcc dot gnu.org
[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 #16 from rguenther at suse dot de --- On Wed, 10 Feb 2021, dmalcolm at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391 > > --- Comment #15 from David Malcolm --- > #0 fancy_abort (file=0x95b0ab6 "../../libcpp/line-map.c", line=1359, > function=0x95b0ace "linemap_compare_locations") > at ../../gcc/diagnostic.c:1778 > #1 0x08fcbecf in linemap_compare_locations (set=0xf7ffb000, pre=2146782942, > post=) at ../../libcpp/line-map.c:1359 > #2 0x080f4378 in linemap_location_before_p (loc_b=2146782943, > loc_a=2146782942, set=) > at ../../gcc/../libcpp/include/line-map.h:1247 > #3 min_location (locb=2146782942, loca=2146782943) at > ../../gcc/cp/decl.c:10641 > #4 smallest_type_location (type_quals=type_quals@entry=1, > locations=locations@entry=0xc778) at ../../gcc/cp/decl.c:10673 > #5 0x081024bb in grokdeclarator (declarator=0xa03c950, declspecs=0xc778, > decl_context=NORMAL, initialized=0, attrlist=0xc62c) > at ../../gcc/cp/decl.c:11008 > #6 0x0810a109 in start_decl (declarator=0xa03c950, declspecs=0xc778, > initialized=0, attributes=, prefix_attributes=0x0, > pushed_scope_p=0xc68c) at ../../gcc/cp/decl.c:5226 > #7 0x0818face in cp_parser_init_declarator (parser=0xec83dae0, > flags=, decl_specifiers=0xc778, checks=0x0, > function_definition_allowed_p=true, member_p=false, > declares_class_or_enum=0, function_definition_p=0xc71c, > maybe_range_for_decl=0x0, > init_loc=0xc710, auto_result=0xc7fc) at > ../../gcc/cp/parser.c:20776 > #8 0x08172e04 in cp_parser_simple_declaration (parser=0xec83dae0, > function_definition_allowed_p=, maybe_range_for_decl=0x0) > at ../../gcc/cp/parser.c:13739 > #9 0x08198e6a in cp_parser_declaration (parser=0xec83dae0) at > ../../gcc/cp/parser.c:13438 > #10 0x081998cb in cp_parser_declaration_seq_opt (parser=) at > ../../gcc/cp/parser.c:13314 > #11 cp_parser_linkage_specification (parser=0xec83dae0) at > ../../gcc/cp/parser.c:14632 > #12 0x08198ed2 in cp_parser_declaration (parser=0xec83dae0) at > ../../gcc/cp/parser.c:13375 > #13 0x081995b6 in cp_parser_translation_unit (parser=0xec83dae0) at > ../../gcc/cp/parser.c:4734 > #14 c_parse_file () at ../../gcc/cp/parser.c:44001 > #15 0x0825a13c in c_common_parse_file () at ../../gcc/c-family/c-opts.c:1190 > #16 0x086be8ce in compile_file () at ../../gcc/toplev.c:458 > #17 0x0809227d in do_compile () at ../../gcc/toplev.c:2298 > #18 toplev::main (this=0xca4e, argc=120, argv=0xcb24) at > ../../gcc/toplev.c:2437 > #19 0x08096231 in main (argc=120, argv=0xcb24) at ../../gcc/main.c:39 > > > It's hitting the abort at line 1359 within linemap_compare_locations: > > 1350 /* So pre and post represent two tokens that are present in a > 1351 same macro expansion. Let's see if the token for pre was > 1352 before the token for post in that expansion. */ > 1353 unsigned i0, i1; > 1354 const struct line_map *map = > 1355first_map_in_common (set, pre, post, , ); > 1356 > 1357 if (map == NULL) > 1358/* This should not be possible. */ > 1359abort (); > > where: > > (gdb) p /x loc_a > $1 = 0x7ff54ede > (gdb) p /x loc_b > $2 = 0x7ff54edf > (gdb) call inform (loc_a, "loc_a") > In file included from > /usr/i686-w64-mingw32/sys-root/mingw/include/minwindef.h:163, > from /usr/i686-w64-mingw32/sys-root/mingw/include/windef.h:8, > from > /usr/i686-w64-mingw32/sys-root/mingw/include/windows.h:69, > from > /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1/widget/windows/AudioSession.cpp:7, > from > /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1-x86/widget/windows/Unified_cpp_widget_windows0.cpp:2: > /usr/i686-w64-mingw32/sys-root/mingw/include/cfgmgr32.h: At global scope: > /usr/i686-w64-mingw32/sys-root/mingw/include/cfgmgr32.h:19: note: loc_a >19 | typedef CONST VOID *PCVOID; > | > (gdb) call inform (loc_b, "loc_b") > In file included from /usr/i686-w64-mingw32/sys-root/mingw/include/windef.h:8, > from > /usr/i686-w64-mingw32/sys-root/mingw/include/windows.h:69, > from > /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1/widget/windows/AudioSession.cpp:7, > from > /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1-x86/widget/windows/Unified_cpp_widget_windows0.cpp:2: > /usr/i686-w64-mingw32/sys-root/mingw/include/cfgmgr32.h:19: note: loc_b >19 | typedef CONST VOID *PCVOID; > | > Guess you now have to trace first_map_in_common_1 where it "breaks" since visually there should be a common map.
[Bug middle-end/38474] compile time explosion in dataflow_set_preserve_mem_locs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #88 from rguenther at suse dot de --- On Wed, 10 Feb 2021, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 > > --- Comment #87 from Jakub Jelinek --- > At least for PR92038 it is important to see CLOBBERs in the chain, including > the first position in there. Hmm, OK. I'll look closer tomorrow but can you try to explain why it's ever important at the first position?
[Bug middle-end/38474] compile time explosion in dataflow_set_preserve_mem_locs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #87 from Jakub Jelinek --- At least for PR92038 it is important to see CLOBBERs in the chain, including the first position in there.
[Bug middle-end/38474] compile time explosion in dataflow_set_preserve_mem_locs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #86 from Richard Biener --- OK, so clobber handling was added as a fix for PR92038
[Bug middle-end/38474] compile time explosion in dataflow_set_preserve_mem_locs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #85 from Richard Biener ---
Starting new chain with statement:
D.31414 ={v} {CLOBBER};
The base object is:
Starting new chain with statement:
D.31415 ={v} {CLOBBER};
The base object is:
...
but those are all the last use of the base object so they just add up and
are never invalidated, but lengthening the m_stores_head list and thus
making terminate_all_aliasing_chains more expensive.
Jakub, were the clobbers ever supposed to _start_ a chain?
With
diff --git a/gcc/gimple-ssa-store-merging.c b/gcc/gimple-ssa-store-merging.c
index f0f4a068de5..fa9a092d544 100644
--- a/gcc/gimple-ssa-store-merging.c
+++ b/gcc/gimple-ssa-store-merging.c
@@ -5175,6 +5175,9 @@ pass_store_merging::process_store (gimple *stmt)
/* Store aliases any existing chain? */
ret |= terminate_all_aliasing_chains (NULL, stmt);
+ /* Do not start a new chain from a CLOBBER. */
+ if (gimple_clobber_p (stmt))
+return ret;
/* Start a new chain. */
class imm_store_chain_info *new_chain
= new imm_store_chain_info (m_stores_head, base_addr);
compile-time gets down to
store merging : 1.18 ( 2%) 0.00 ( 0%) 1.18 ( 2%)
3858k ( 1%)
TOTAL : 59.84 0.57 60.43
557M
I'm checking if it has any testsuite fallout.
[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 #15 from David Malcolm --- #0 fancy_abort (file=0x95b0ab6 "../../libcpp/line-map.c", line=1359, function=0x95b0ace "linemap_compare_locations") at ../../gcc/diagnostic.c:1778 #1 0x08fcbecf in linemap_compare_locations (set=0xf7ffb000, pre=2146782942, post=) at ../../libcpp/line-map.c:1359 #2 0x080f4378 in linemap_location_before_p (loc_b=2146782943, loc_a=2146782942, set=) at ../../gcc/../libcpp/include/line-map.h:1247 #3 min_location (locb=2146782942, loca=2146782943) at ../../gcc/cp/decl.c:10641 #4 smallest_type_location (type_quals=type_quals@entry=1, locations=locations@entry=0xc778) at ../../gcc/cp/decl.c:10673 #5 0x081024bb in grokdeclarator (declarator=0xa03c950, declspecs=0xc778, decl_context=NORMAL, initialized=0, attrlist=0xc62c) at ../../gcc/cp/decl.c:11008 #6 0x0810a109 in start_decl (declarator=0xa03c950, declspecs=0xc778, initialized=0, attributes=, prefix_attributes=0x0, pushed_scope_p=0xc68c) at ../../gcc/cp/decl.c:5226 #7 0x0818face in cp_parser_init_declarator (parser=0xec83dae0, flags=, decl_specifiers=0xc778, checks=0x0, function_definition_allowed_p=true, member_p=false, declares_class_or_enum=0, function_definition_p=0xc71c, maybe_range_for_decl=0x0, init_loc=0xc710, auto_result=0xc7fc) at ../../gcc/cp/parser.c:20776 #8 0x08172e04 in cp_parser_simple_declaration (parser=0xec83dae0, function_definition_allowed_p=, maybe_range_for_decl=0x0) at ../../gcc/cp/parser.c:13739 #9 0x08198e6a in cp_parser_declaration (parser=0xec83dae0) at ../../gcc/cp/parser.c:13438 #10 0x081998cb in cp_parser_declaration_seq_opt (parser=) at ../../gcc/cp/parser.c:13314 #11 cp_parser_linkage_specification (parser=0xec83dae0) at ../../gcc/cp/parser.c:14632 #12 0x08198ed2 in cp_parser_declaration (parser=0xec83dae0) at ../../gcc/cp/parser.c:13375 #13 0x081995b6 in cp_parser_translation_unit (parser=0xec83dae0) at ../../gcc/cp/parser.c:4734 #14 c_parse_file () at ../../gcc/cp/parser.c:44001 #15 0x0825a13c in c_common_parse_file () at ../../gcc/c-family/c-opts.c:1190 #16 0x086be8ce in compile_file () at ../../gcc/toplev.c:458 #17 0x0809227d in do_compile () at ../../gcc/toplev.c:2298 #18 toplev::main (this=0xca4e, argc=120, argv=0xcb24) at ../../gcc/toplev.c:2437 #19 0x08096231 in main (argc=120, argv=0xcb24) at ../../gcc/main.c:39 It's hitting the abort at line 1359 within linemap_compare_locations: 1350 /* So pre and post represent two tokens that are present in a 1351 same macro expansion. Let's see if the token for pre was 1352 before the token for post in that expansion. */ 1353 unsigned i0, i1; 1354 const struct line_map *map = 1355first_map_in_common (set, pre, post, , ); 1356 1357 if (map == NULL) 1358/* This should not be possible. */ 1359abort (); where: (gdb) p /x loc_a $1 = 0x7ff54ede (gdb) p /x loc_b $2 = 0x7ff54edf (gdb) call inform (loc_a, "loc_a") In file included from /usr/i686-w64-mingw32/sys-root/mingw/include/minwindef.h:163, from /usr/i686-w64-mingw32/sys-root/mingw/include/windef.h:8, from /usr/i686-w64-mingw32/sys-root/mingw/include/windows.h:69, from /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1/widget/windows/AudioSession.cpp:7, from /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1-x86/widget/windows/Unified_cpp_widget_windows0.cpp:2: /usr/i686-w64-mingw32/sys-root/mingw/include/cfgmgr32.h: At global scope: /usr/i686-w64-mingw32/sys-root/mingw/include/cfgmgr32.h:19: note: loc_a 19 | typedef CONST VOID *PCVOID; | (gdb) call inform (loc_b, "loc_b") In file included from /usr/i686-w64-mingw32/sys-root/mingw/include/windef.h:8, from /usr/i686-w64-mingw32/sys-root/mingw/include/windows.h:69, from /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1/widget/windows/AudioSession.cpp:7, from /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1-x86/widget/windows/Unified_cpp_widget_windows0.cpp:2: /usr/i686-w64-mingw32/sys-root/mingw/include/cfgmgr32.h:19: note: loc_b 19 | typedef CONST VOID *PCVOID; |
[Bug middle-end/38474] compile time explosion in dataflow_set_preserve_mem_locs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #84 from Richard Biener --- So it's the usual (quadratic) culprit: Samples: 1M of event 'cycles:u', Event count (approx.): 1675893461671 Overhead Samples Command Shared Object Symbol 20.61%316521 f951 f951 [.] get_ref_base_and_extent 14.42%221221 f951 f951 [.] (anonymous namespace)::pass_store_merging::terminate_all_aliasing_chains 5.77% 88586 f951 f951 [.] special_function_p I'll see whether I can do some surgery.
[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 Patrick Palka changed: What|Removed |Added Resolution|--- |DUPLICATE CC||ppalka at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #2 from Patrick Palka --- Hmm, looks like a dup of PR95675 *** This bug has been marked as a duplicate of bug 95675 ***
[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||david at doublewise dot net --- Comment #7 from Patrick Palka --- *** Bug 99016 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/98692] Unitialized Values reported only with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692 --- Comment #22 from jseward at acm dot org --- Looking back at the above, it's now clearer what the problem is: # Park potentially live data in the red zone _savegpr0_14: std r14,-144(r1) _savegpr0_15: std r15,-136(r1) _savegpr0_16: std r16,-128(r1) _savegpr0_17: std r17,-120(r1) _savegpr0_18: std r18,-112(r1) _savegpr0_19: std r19,-104(r1) _savegpr0_20: std r20,-96(r1) _savegpr0_21: std r21,-88(r1) _savegpr0_22: std r22,-80(r1) _savegpr0_23: std r23,-72(r1) _savegpr0_24: std r24,-64(r1) _savegpr0_25: std r25,-56(r1) _savegpr0_26: std r26,-48(r1) _savegpr0_27: std r27,-40(r1) _savegpr0_28: std r28,-32(r1) _savegpr0_29: std r29,-24(r1) _savegpr0_30: std r30,-16(r1) _savegpr0_31: std r31,-8(r1) std r0, 16(r1) # And ka-zap! Memcheck paints -288(r1) .. -1(r1) as undefined. blr # So now they're all "unusable".
[Bug middle-end/38474] compile time explosion in dataflow_set_preserve_mem_locs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 Richard Biener changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #83 from Richard Biener --- Meh. On trunk (GCC 11) we now have for the reduced testcase > ./f951 -quiet testcase_reduced.f90 -ffree-line-length-512 -ftime-report -O3 Time variable usr sys wall GGC ... callgraph ipa passes : 28.09 ( 8%) 0.23 ( 38%) 28.33 ( 8%) 68M ( 12%) ipa inlining heuristics: 5.13 ( 1%) 0.01 ( 2%) 5.13 ( 1%) 14M ( 3%) alias stmt walking : 7.03 ( 2%) 0.09 ( 15%) 7.15 ( 2%) 277k ( 0%) tree PTA : 26.20 ( 7%) 0.17 ( 28%) 26.39 ( 7%) 25M ( 5%) store merging : 308.60 ( 84%) 0.01 ( 2%) 308.70 ( 84%) 3858k ( 1%) TOTAL : 365.68 0.61366.42 557M so store-merging goes bollocks. I will try to dig into it a bit but I'm not very familiar with the code. GCC 10 behaves similar here but not as bad: store merging : 232.10 ( 82%) 0.02 ( 4%) 232.19 ( 82%) 3837 kB ( 1%) TOTAL : 283.51 0.45284.05 582957 kB while GCC 9 is sane: store merging : 0.04 ( 0%) 0.00 ( 0%) 0.04 ( 0%) 2700 kB ( 1%) TOTAL : 88.59 0.70 89.34 521364 kB
