[Bug c++/96387] gnu gmp c source edit g++ internal compiler error appear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96387 Andrew Pinski changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |INVALID --- Comment #6 from Andrew Pinski --- GCC uses GMP, MPFR (which uses GMP internally) and MPC (which uses MPFR). so yes it depends on GMP ABI being stable. Again if you are messing with the GMP ABI, you really should be doing a cross compiler to do a bootstrap of the compiler. THERE is nothing that can be done as you are changing the GMP ABI/API.
[Bug c++/96387] gnu gmp c source edit g++ internal compiler error appear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96387 cents2823 at yahoo dot co.jp changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #5 from cents2823 at yahoo dot co.jp --- Sorry, g++'s error disappeared in the new procedure I commented the other day, but it will be an error in gnu gmp if the root 2 calculation program specifies more than 41 billion digits. >Did you recompile GCC, MPFR and mpc after this change? If not then there is >still no bug. When compiling gcc-10.1.0 from the source, an error (gcc internale compile error) occurs during the make, and I cannot recompile. Is there any way around it? Thanking you in advance. From:Tsukamoto
[Bug c++/96623] New: [10/11 Regression] ICE in inject_parm_decls, at cp/parser.c:23893
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96623
Bug ID: 96623
Summary: [10/11 Regression] ICE in inject_parm_decls, at
cp/parser.c:23893
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Input:
//small.cc
struct A{
void a(){
struct B {
void b () noexcept();
};
}
};
Command:
g++ small.cc
Output:
small.cc: In member function ‘void A::a()’:
small.cc:5:25: internal compiler error: in inject_parm_decls, at
cp/parser.c:23893
5 | };
| ^
0x67450f inject_parm_decls
../../gcc/cp/parser.c:23893
0x67450f cp_parser_class_specifier_1
../../gcc/cp/parser.c:24239
0x9d3143 cp_parser_class_specifier
../../gcc/cp/parser.c:24308
0x9d3143 cp_parser_type_specifier
../../gcc/cp/parser.c:17811
0x9d40be cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:14436
0x9d4e71 cp_parser_simple_declaration
../../gcc/cp/parser.c:13690
0x9d6fdd cp_parser_declaration_statement
../../gcc/cp/parser.c:13249
0x9d7c67 cp_parser_statement
../../gcc/cp/parser.c:11555
0x9d8ccd cp_parser_statement_seq_opt
../../gcc/cp/parser.c:11921
0x9d8da8 cp_parser_compound_statement
../../gcc/cp/parser.c:11871
0x9f0ee5 cp_parser_function_body
../../gcc/cp/parser.c:23170
0x9f0ee5 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:23221
0x9f4510 cp_parser_function_definition_after_declarator
../../gcc/cp/parser.c:29117
0x9f590c cp_parser_late_parsing_for_member
../../gcc/cp/parser.c:30019
0x9d225b cp_parser_class_specifier_1
../../gcc/cp/parser.c:24284
0x9d3143 cp_parser_class_specifier
../../gcc/cp/parser.c:24308
0x9d3143 cp_parser_type_specifier
../../gcc/cp/parser.c:17811
0x9d40be cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:14436
0x9d4e71 cp_parser_simple_declaration
../../gcc/cp/parser.c:13690
0xa002fe cp_parser_declaration
../../gcc/cp/parser.c:13510
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug gcov-profile/96622] gcov misses to count break statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96622 --- Comment #1 from Roland Illig --- In my own code coverage measurer for Go programs, I took the approach of creating a coverage counter for every true and false branch of a boolean condition. https://github.com/rillig/gobco/blob/6be01424/instrumenter.go#L126 I had expected gcov to work in the same way, but it seems to me that gcov takes a different approach. Or is it that the break statement is converted to a direct jump too early to be seen by the --coverage option, discarding the basic block for it? That reminds me of what I consider a bug in the OpenJDK Java compiler (as well as the Eclipse Java compiler): https://mail.openjdk.java.net/pipermail/compiler-dev/2020-February/014290.html
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 --- Comment #23 from Damian Rouson --- A related issue arises if the procedure in question is a pure function as demonstrated below. The code compiles cleanly if either 1. The result-spec is absent and the procedure is renamed new_foo in both the interface body and in the procedure definition, or 2. The interface body is repeated in the procedure definition instead the "module procedure" syntax. ± cat pure-shape-mismatch.f90 module foobar implicit none type foo integer bar end type interface pure module function create() result(new_foo) implicit none type(foo) new_foo end function end interface contains module procedure create new_foo%bar = 1 end procedure end module ± gfortran -c pure-shape-mismatch.f90 pure-shape-mismatch.f90:17:4: 17 | new_foo%bar = 1 |1 Error: Variable ‘new_foo’ cannot appear in a variable definition context (assignment) at (1) in PURE procedure ± gfortran --version GNU Fortran (GCC) 11.0.0 20200804 (experimental)
[Bug gcov-profile/96622] New: gcov misses to count break statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96622 Bug ID: 96622 Summary: gcov misses to count break statement Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de CC: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 49064 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49064=edit demonstration project Run gcov on the attached project. Examine the coverage count of the break statement. It should be 1, but is '-'.
[Bug tree-optimization/96621] fold strlen relational expressions after nul stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96621 Martin Sebor changed: What|Removed |Added Severity|normal |enhancement Blocks||83819 Keywords||missed-optimization Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819 [Bug 83819] [meta-bug] missing strlen optimizations
[Bug tree-optimization/96621] New: fold strlen relational expressions after nul stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96621
Bug ID: 96621
Summary: fold strlen relational expressions after nul stores
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
strlen(s) <= N can be folded to true after nul has been stored into s[N].
$ cat t.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout t.c
void f0 (char *s)
{
s[0] = 0;
if (__builtin_strlen (s) > 0) // folded to false
__builtin_abort ();
}
void f1 (char *s)
{
s[1] = 0;
if (__builtin_strlen (s) > 1) // not folded but can be
__builtin_abort ();
}
;; Function f0 (f0, funcdef_no=0, decl_uid=1931, cgraph_uid=1, symbol_order=0)
f0 (char * s)
{
[local count: 1073741824]:
*s_2(D) = 0;
return;
}
;; Function f1 (f1, funcdef_no=1, decl_uid=1934, cgraph_uid=2, symbol_order=1)
f1 (char * s)
{
long unsigned int _1;
[local count: 1073741824]:
MEM[(char *)s_2(D) + 1B] = 0;
_1 = __builtin_strlen (s_2(D));
if (_1 > 1)
goto ; [0.00%]
else
goto ; [100.00%]
[count: 0]:
__builtin_abort ();
[local count: 1073741824]:
return;
}
[Bug tree-optimization/78257] missing memcmp optimization with constant arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78257 Martin Sebor changed: What|Removed |Added Known to work||11.0 Target Milestone|--- |11.0 Resolution|--- |FIXED Keywords||patch Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Status|NEW |RESOLVED Known to fail||10.2.0, 7.3.0, 8.2.0, 9.2.0 --- Comment #10 from Martin Sebor --- Done for GCC 11.
[Bug analyzer/96608] Build failure due to cast to type long on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608 --- Comment #2 from Markus Böck --- Don't worry there's no rush! It's the master branch after all. Just wanted to make sure people are aware of it as soon as possible.
[Bug tree-optimization/78257] missing memcmp optimization with constant arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78257 --- Comment #9 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:866626efd749ed3e2b7014e88e4340b5a4c73560 commit r11-2709-g866626efd749ed3e2b7014e88e4340b5a4c73560 Author: Martin Sebor Date: Fri Aug 14 17:11:53 2020 -0600 PR tree-optimization/78257 - missing memcmp optimization with constant arrays gcc/ChangeLog: PR middle-end/78257 * builtins.c (expand_builtin_memory_copy_args): Rename called function. (expand_builtin_stpcpy_1): Remove argument from call. (expand_builtin_memcmp): Rename called function. (inline_expand_builtin_bytecmp): Same. * expr.c (convert_to_bytes): New function. (constant_byte_string): New function (formerly string_constant). (string_constant): Call constant_byte_string. (byte_representation): New function. * expr.h (byte_representation): Declare. * fold-const-call.c (fold_const_call): Rename called function. * fold-const.c (c_getstr): Remove an argument. (getbyterep): Define a new function. * fold-const.h (c_getstr): Remove an argument. (getbyterep): Declare a new function. * gimple-fold.c (gimple_fold_builtin_memory_op): Rename callee. (gimple_fold_builtin_string_compare): Same. (gimple_fold_builtin_memchr): Same. gcc/testsuite/ChangeLog: PR middle-end/78257 * gcc.dg/memchr.c: New test. * gcc.dg/memcmp-2.c: New test. * gcc.dg/memcmp-3.c: New test. * gcc.dg/memcmp-4.c: New test.
[Bug analyzer/96608] Build failure due to cast to type long on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608 --- Comment #1 from David Malcolm --- Thanks for filing this; sorry for not fixing this today, I hope to get to this early next week. If you need a temporary workaround to unbreak your build, the analyzer code can be disabled altogether at configure time when building GCC via --disable-analyzer.
[Bug analyzer/96616] Many new analyzer failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96616 --- Comment #4 from David Malcolm --- The init.c issue should be fixed by commit r11-2708-g2867118ddda9b56d991c16022f7d3d634ed08313 I'm still investigating the pr93032-mztools.c -Wanalyzer-too-complex warnings (affects at least arm and aarch64 also).
[Bug analyzer/96616] Many new analyzer failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96616 David Malcolm changed: What|Removed |Added CC||seurer at gcc dot gnu.org --- Comment #3 from David Malcolm --- *** Bug 96609 has been marked as a duplicate of this bug. ***
[Bug testsuite/96609] new test case gcc.dg/analyzer/init.c has many failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96609 David Malcolm changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from David Malcolm --- Thanks for filing this. r11-2708-g2867118ddda9b56d991c16022f7d3d634ed08313 should fix the init.c issue mentioned in this bug's title, but not the issue in comment #1. Both issues here are also being tracked by PR analyzer/96616 which has a more generic title, so I'm going to close out this bug as a duplicate of that one. *** This bug has been marked as a duplicate of bug 96616 ***
[Bug analyzer/96616] Many new analyzer failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96616
--- Comment #2 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:2867118ddda9b56d991c16022f7d3d634ed08313
commit r11-2708-g2867118ddda9b56d991c16022f7d3d634ed08313
Author: David Malcolm
Date: Fri Aug 14 15:49:52 2020 -0400
analyzer: fix initialization from constant pool [PR96609,PR96616]
PR testsuite/96609 and PR analyzer/96616 report various testsuite
failures seen on powerpc64, aarch64, and arm in new tests added by
r11-2694-g808f4dfeb3a95f50f15e71148e5c1067f90a126d.
Some of these failures (in gcc.dg/analyzer/init.c, and on arm
in gcc.dg/analyzer/casts-1.c) relate to initializations from var_decls
in the constant pool. I wrote the tests assuming that the gimplified
stmts would initialize the locals via a gassign of code CONSTRUCTOR,
whereas on these targets some of the initializations are gassign from
a VAR_DECL e.g.:
c = *.LC0;
where "*.LC0" is a var_decl with DECL_IN_CONSTANT_POOL set.
For example, in test_7:
struct coord c[2] = {{3, 4}, {5, 6}};
__analyzer_eval (c[0].x == 3); /* { dg-warning "TRUE" } */
after the initialization, the store was simply recording:
cluster for: c: INIT_VAL(*.LC0)
when I was expecting the cluster for c to have:
cluster for: c
key: {kind: direct, start: 0, size: 32, next: 32}
value: 'int' {(int)3}
key: {kind: direct, start: 32, size: 32, next: 64}
value: 'int' {(int)4}
key: {kind: direct, start: 64, size: 32, next: 96}
value: 'int' {(int)5}
key: {kind: direct, start: 96, size: 32, next: 128}
value: 'int' {(int)6}
The test for c[0].x == 3 would then generate:
cluster for: _2: (SUB(SUB(INIT_VAL(*.LC0), c[(int)0]),
c[(int)0].x)==(int)3)
which is UNKNOWN, leading to the test failing.
This patch fixes the init.c and casts-1.c failures by special-casing
reads from a var_decl with DECL_IN_CONSTANT_POOL set, so that they build
a compound_svalue containing the bindings implied by the CONSTRUCTOR
node for DECL_INITIAL.
gcc/analyzer/ChangeLog:
PR testsuite/96609
PR analyzer/96616
* region-model.cc (region_model::get_store_value): Call
maybe_get_constant_value on decl_regions first.
* region-model.h (decl_region::maybe_get_constant_value): New decl.
* region.cc (decl_region::get_stack_depth): Likewise.
(decl_region::maybe_get_constant_value): New.
* store.cc (get_subregion_within_ctor): New.
(binding_map::apply_ctor_to_region): New.
* store.h (binding_map::apply_ctor_to_region): New decl.
[Bug testsuite/96609] new test case gcc.dg/analyzer/init.c has many failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96609
--- Comment #2 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:2867118ddda9b56d991c16022f7d3d634ed08313
commit r11-2708-g2867118ddda9b56d991c16022f7d3d634ed08313
Author: David Malcolm
Date: Fri Aug 14 15:49:52 2020 -0400
analyzer: fix initialization from constant pool [PR96609,PR96616]
PR testsuite/96609 and PR analyzer/96616 report various testsuite
failures seen on powerpc64, aarch64, and arm in new tests added by
r11-2694-g808f4dfeb3a95f50f15e71148e5c1067f90a126d.
Some of these failures (in gcc.dg/analyzer/init.c, and on arm
in gcc.dg/analyzer/casts-1.c) relate to initializations from var_decls
in the constant pool. I wrote the tests assuming that the gimplified
stmts would initialize the locals via a gassign of code CONSTRUCTOR,
whereas on these targets some of the initializations are gassign from
a VAR_DECL e.g.:
c = *.LC0;
where "*.LC0" is a var_decl with DECL_IN_CONSTANT_POOL set.
For example, in test_7:
struct coord c[2] = {{3, 4}, {5, 6}};
__analyzer_eval (c[0].x == 3); /* { dg-warning "TRUE" } */
after the initialization, the store was simply recording:
cluster for: c: INIT_VAL(*.LC0)
when I was expecting the cluster for c to have:
cluster for: c
key: {kind: direct, start: 0, size: 32, next: 32}
value: 'int' {(int)3}
key: {kind: direct, start: 32, size: 32, next: 64}
value: 'int' {(int)4}
key: {kind: direct, start: 64, size: 32, next: 96}
value: 'int' {(int)5}
key: {kind: direct, start: 96, size: 32, next: 128}
value: 'int' {(int)6}
The test for c[0].x == 3 would then generate:
cluster for: _2: (SUB(SUB(INIT_VAL(*.LC0), c[(int)0]),
c[(int)0].x)==(int)3)
which is UNKNOWN, leading to the test failing.
This patch fixes the init.c and casts-1.c failures by special-casing
reads from a var_decl with DECL_IN_CONSTANT_POOL set, so that they build
a compound_svalue containing the bindings implied by the CONSTRUCTOR
node for DECL_INITIAL.
gcc/analyzer/ChangeLog:
PR testsuite/96609
PR analyzer/96616
* region-model.cc (region_model::get_store_value): Call
maybe_get_constant_value on decl_regions first.
* region-model.h (decl_region::maybe_get_constant_value): New decl.
* region.cc (decl_region::get_stack_depth): Likewise.
(decl_region::maybe_get_constant_value): New.
* store.cc (get_subregion_within_ctor): New.
(binding_map::apply_ctor_to_region): New.
* store.h (binding_map::apply_ctor_to_region): New decl.
[Bug libfortran/93727] Fortran 2018: EX edit descriptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727 --- Comment #3 from jvdelisle at charter dot net --- Interesting language if not sort of weird: "exp is a binary exponent expressed as a decimal integer" I am in early stages of choosing how to do this.
[Bug analyzer/96611] ICE in get_or_create_cluster
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96611 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from David Malcolm --- Should be fixed by the above commit.
[Bug analyzer/96611] ICE in get_or_create_cluster
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96611 --- Comment #1 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:ee88b536069db8f870c444c441182a9c76ec5bba commit r11-2707-gee88b536069db8f870c444c441182a9c76ec5bba Author: David Malcolm Date: Fri Aug 14 10:48:30 2020 -0400 analyzer: fix ICE on escaped unknown pointers [PR96611] PR analyzer/96611 reports an ICE within the handling for unknown functions, when passing a pointer to something accessed via a global pointer, after an unknown function has already been called. The first unknown function leads to the store being flagged, so the access to the global pointer leads to (*unknown_svalue) for the base region of the argument to the 2nd function, and thus *unknown_svalue being reachable by the 2nd unknown function, triggering an assertion failure. Handle this case by rejecting attempts to get a cluster for the unknown pointer, fixing the ICE. gcc/analyzer/ChangeLog: PR analyzer/96611 * store.cc (store::mark_as_escaped): Reject attempts to get a cluster for an unknown pointer. gcc/testsuite/ChangeLog: PR analyzer/96611 * gcc.dg/analyzer/pr96611.c: New test.
[Bug c++/96620] New: bogus -Wdeprecated-declarations on attribute deprecated immediately preceding parameter name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96620 Bug ID: 96620 Summary: bogus -Wdeprecated-declarations on attribute deprecated immediately preceding parameter name Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- The C++ front end (but not the C front end) issues a warning for the declaration of the function argument in f1(). The C front end also doesn't warn for this use case, and neither do Clang or ICC, suggesting the G++ rules should be adjusted to match. $ cat t.c && gcc -O2 -S -Wall -Wextra -xc++ t.c #define DEPRECATED __attribute__ ((deprecated)) void f0 ( int*p DEPRECATED); void f1 ( int* DEPRECATED p ); void f2 ( int DEPRECATED *p ); void f3 (DEPRECATED int*p ); t.c:4:61: warning: type is deprecated [-Wdeprecated-declarations] 4 | void f1 ( int* DEPRECATED p ); | ^
[Bug c/96619] New: attribute deprecated immediately before a parameter has no effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96619
Bug ID: 96619
Summary: attribute deprecated immediately before a parameter
has no effect
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The following test case shows that while attribute unused suppresses a warning
about unused pointer parameter regardless of its placement, attribute
deprecated is not respected when it immediately precedes the parameter name.
The C++ front end behaves as expected, as do Clang and ICC.
$ cat t.c && gcc -S -Wall t.c
void f1 (__attribute__ ((unused)) int *p) { }
void g1 (int __attribute__ ((unused)) *p) { }
void h1 (int *__attribute__ ((unused)) p) { }
void i1 (int *p __attribute__ ((unused))) { }
void* f2 (__attribute__ ((deprecated)) int *p) { return p; }
void* g2 (int __attribute__ ((deprecated)) *p) { return p; }
void* h2 (int *__attribute__ ((deprecated)) p) { return p; } // missing
warning
void* i2 (int *p __attribute__ ((deprecated))) { return p; }
t.c: In function ‘f2’:
t.c:6:1: warning: ‘p’ is deprecated [-Wdeprecated-declarations]
6 | void* f2 (__attribute__ ((deprecated)) int *p) { return p; }
| ^~~~
t.c:6:45: note: declared here
6 | void* f2 (__attribute__ ((deprecated)) int *p) { return p; }
|~^
t.c: In function ‘g2’:
t.c:7:1: warning: ‘p’ is deprecated [-Wdeprecated-declarations]
7 | void* g2 (int __attribute__ ((deprecated)) *p) { return p; }
| ^~~~
t.c:7:45: note: declared here
7 | void* g2 (int __attribute__ ((deprecated)) *p) { return p; }
| ~~^
t.c: In function ‘i2’:
t.c:9:1: warning: ‘p’ is deprecated [-Wdeprecated-declarations]
9 | void* i2 (int *p __attribute__ ((deprecated))) { return p; }
| ^~~~
t.c:9:16: note: declared here
9 | void* i2 (int *p __attribute__ ((deprecated))) { return p; }
| ~^~
[Bug analyzer/93388] ensure -fanalyzer works with our C code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93388 --- Comment #19 from David Binderman --- I tried out the C++ code with -g -O2 -fanalyzer and got the following: $ cat 20200814.ana.O2.cpp.out | fgrep "internal c" | fgrep analyzer ./g++.dg/expr/ptrmem7.C:20:3: internal compiler error: in get_or_create_mem_ref, at analyzer/region-model.cc:6938 ./g++.dg/expr/ptrmem8.C:13:3: internal compiler error: in get_or_create_mem_ref, at analyzer/region-model.cc:6938 ./g++.old-deja/g++.bugs/900212_03.C:28:3: internal compiler error: in get_or_create_mem_ref, at analyzer/region-model.cc:6938 ./g++.old-deja/g++.law/code-gen4.C:24:9: internal compiler error: in get_or_create_mem_ref, at analyzer/region-model.cc:6938 ./g++.old-deja/g++.mike/pmf1.C:36:3: internal compiler error: in get_or_create_mem_ref, at analyzer/region-model.cc:6938 $ So only one crash, different to the C code, there.
[Bug testsuite/96618] [10 regression] excess errors for g++.dg/torture/pr95548.C after r10-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96618 seurer at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from seurer at gcc dot gnu.org --- Looks like this was just fixed actually.
[Bug testsuite/96618] New: [10 regression] excess errors for g++.dg/torture/pr95548.C after r10-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96618 Bug ID: 96618 Summary: [10 regression] excess errors for g++.dg/torture/pr95548.C after r10- Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:aa81d093bf26a263131ecc1add04e27274457bb9, r10-8625 make -k check-gcc RUNTESTFLAGS=dg-torture.exp=g++.dg/torture/pr95548.C FAIL: g++.dg/torture/pr95548.C -O0 (test for excess errors) FAIL: g++.dg/torture/pr95548.C -O1 (test for excess errors) FAIL: g++.dg/torture/pr95548.C -O2 (test for excess errors) FAIL: g++.dg/torture/pr95548.C -O3 -g (test for excess errors) FAIL: g++.dg/torture/pr95548.C -Os (test for excess errors) FAIL: g++.dg/torture/pr95548.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors) FAIL: g++.dg/torture/pr95548.C -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors) # of unexpected failures7 spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-10-test/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/git/build/gcc-10-test/gcc/testsuite/g++/../../ exceptions_enabled34416.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -nostdinc++ -I/home/seurer/gcc/git/build/gcc-10-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/home/seurer/gcc/git/build/gcc-10-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/git/gcc-10-test/libstdc++-v3/libsupc++ -I/home/seurer/gcc/git/gcc-10-test/libstdc++-v3/include/backward -I/home/seurer/gcc/git/gcc-10-test/libstdc++-v3/testsuite/util -fmessage-length=0 -S -o exceptions_enabled34416.s FAIL: g++.dg/torture/pr95548.C -O0 (test for excess errors) Excess errors: /home/seurer/gcc/git/gcc-10-test/gcc/testsuite/g++.dg/torture/pr95548.C:6:1: warning: ISO C++ forbids declaration of 'main' with no type [-Wreturn-type] ...more like this...
[Bug lto/96617] [10 regression] ICE in gcc.dg/pr34457-2.c after r10-8624
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96617 seurer at gcc dot gnu.org changed: What|Removed |Added Summary|[11 regression] ICE in |[10 regression] ICE in |gcc.dg/pr34457-2.c after|gcc.dg/pr34457-2.c after |r10-8624|r10-8624 --- Comment #3 from seurer at gcc dot gnu.org --- OK, thanks. I verified it now works.
[Bug c++/93711] [9/10 Regression] ICE: [[no_unique_address] when constructing via template helper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93711 Jason Merrill changed: What|Removed |Added Summary|[9/10/11 Regression] ICE: |[9/10 Regression] ICE: |[[no_unique_address] when |[[no_unique_address] when |constructing via template |constructing via template |helper |helper --- Comment #11 from Jason Merrill --- Fixed for GCC 11 so far.
[Bug c++/90254] [8/9/10 Regression] ice on aggregate initialization of unmovable base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90254 Jason Merrill changed: What|Removed |Added Summary|[8/9/10/11 Regression] ice |[8/9/10 Regression] ice on |on aggregate initialization |aggregate initialization of |of unmovable base |unmovable base --- Comment #7 from Jason Merrill --- The patch fixes the testcase from comment #4 for GCC 11. I agree with the clang response that the original testcase is ill-formed, and will continue to be rejected. The testcase in comment #3 is still broken due to PR 66139.
[Bug c++/93711] [9/10/11 Regression] ICE: [[no_unique_address] when constructing via template helper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93711 --- Comment #10 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:320054784250e572cb75d6f69ab44b2330d61d8b commit r11-2704-g320054784250e572cb75d6f69ab44b2330d61d8b Author: Jason Merrill Date: Wed Aug 12 05:45:02 2020 -0400 c++: Copy elision and [[no_unique_address]]. [PR93711] We don't elide a copy from a function returning a class by value into a base because that can overwrite data laid out in the tail padding of the base class; we need to handle [[no_unique_address]] fields the same way, or we ICE when the middle-end wants to create a temporary object of a TYPE_NEEDS_CONSTRUCTING type. This means that we can't always express initialization of a field with INIT_EXPR from a TARGET_EXPR the way we usually do, so I needed to change several places that were assuming that was sufficient. This also fixes 90254, the same problem with C++17 aggregate initialization of a base. gcc/cp/ChangeLog: PR c++/90254 PR c++/93711 * cp-tree.h (unsafe_return_slot_p): Declare. * call.c (is_base_field_ref): Rename to unsafe_return_slot_p. (build_over_call): Check unsafe_return_slot_p. (build_special_member_call): Likewise. * init.c (expand_default_init): Likewise. * typeck2.c (split_nonconstant_init_1): Likewise. gcc/testsuite/ChangeLog: PR c++/90254 PR c++/93711 * g++.dg/cpp1z/aggr-base10.C: New test. * g++.dg/cpp2a/no_unique_address7.C: New test. * g++.dg/cpp2a/no_unique_address7a.C: New test.
[Bug c++/90254] [8/9/10/11 Regression] ice on aggregate initialization of unmovable base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90254 --- Comment #6 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:320054784250e572cb75d6f69ab44b2330d61d8b commit r11-2704-g320054784250e572cb75d6f69ab44b2330d61d8b Author: Jason Merrill Date: Wed Aug 12 05:45:02 2020 -0400 c++: Copy elision and [[no_unique_address]]. [PR93711] We don't elide a copy from a function returning a class by value into a base because that can overwrite data laid out in the tail padding of the base class; we need to handle [[no_unique_address]] fields the same way, or we ICE when the middle-end wants to create a temporary object of a TYPE_NEEDS_CONSTRUCTING type. This means that we can't always express initialization of a field with INIT_EXPR from a TARGET_EXPR the way we usually do, so I needed to change several places that were assuming that was sufficient. This also fixes 90254, the same problem with C++17 aggregate initialization of a base. gcc/cp/ChangeLog: PR c++/90254 PR c++/93711 * cp-tree.h (unsafe_return_slot_p): Declare. * call.c (is_base_field_ref): Rename to unsafe_return_slot_p. (build_over_call): Check unsafe_return_slot_p. (build_special_member_call): Likewise. * init.c (expand_default_init): Likewise. * typeck2.c (split_nonconstant_init_1): Likewise. gcc/testsuite/ChangeLog: PR c++/90254 PR c++/93711 * g++.dg/cpp1z/aggr-base10.C: New test. * g++.dg/cpp2a/no_unique_address7.C: New test. * g++.dg/cpp2a/no_unique_address7a.C: New test.
[Bug c++/95407] [DR 1873] G++ allows access to base class members from a friend of a derived class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95407
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
--- Comment #1 from Arthur O'Dwyer ---
According to Richard's comment on https://bugs.llvm.org/show_bug.cgi?id=46036 ,
http://cwg-issue-browser.herokuapp.com/cwg1873 indicates that Clang may be
correct according to the Standard as written. HOWEVER...
The "misbehavior" here isn't really about `friend`; it's about the interaction
between `static` and `protected`. If you change your test case to make `value`
non-static, then all vendors agree that the non-static `value` is inaccessible.
With a static protected member (Clang rejects, GCC and MSVC accept):
https://godbolt.org/z/essofs
With a non-static protected member (all three correctly reject):
https://godbolt.org/z/T1GWTP
And here's a test case that doesn't use `friend` at all, but rather uses a
private inheritance path, so that `C` is derived from `A`, but `C` itself is
not aware of the fact. This case came up on Slack on 2020-08-14:
https://cpplang.slack.com/archives/C5GN4SP41/p1597391677014800
With a static protected member (GCC and Clang accept, MSVC rejects):
https://godbolt.org/z/6d786M
With a non-static protected member (all three correctly reject):
https://godbolt.org/z/MeTxeW
// https://godbolt.org/z/6d786M
struct A {
protected:
static int sf();
};
struct B : private A {};
struct C : public B {
static void test();
};
void C::test() { &::A::sf; }
[Bug lto/95548] ice in tree_to_shwi, at tree.c:7321
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95548 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:eae728e6597727393b96886c77dbf0727a9fa720 commit r10-8630-geae728e6597727393b96886c77dbf0727a9fa720 Author: Jakub Jelinek Date: Mon Jun 8 10:30:48 2020 +0200 testsuite: Fix up pr95548.C testcase. 2020-06-08 Jakub Jelinek PR lto/95548 * g++.dg/torture/pr95548.C: Change from dg-do compile to dg-do link, add return type for main, for __SIZEOF_INT128__ test with __uint128_t enumerator constants and add a test with unsigned long long enumerators for all targets. (cherry picked from commit 296d644b9f526e44fbe574426f24799c1d545fd3)
[Bug analyzer/96616] Many new analyzer failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96616 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2020-08-14 --- Comment #1 from David Malcolm --- Thanks; sorry about this. Seems to be the same set of failures as PR 96609; am investigating.
[Bug lto/96617] [11 regression] ICE in gcc.dg/pr34457-2.c after r10-8624
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96617 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Martin Liška --- Should be fixed with r10-8629-g630474c8904cf797d0ee022d2ab177e25932c1d7.
[Bug lto/96617] [11 regression] ICE in gcc.dg/pr34457-2.c after r10-8624
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96617 seurer at gcc dot gnu.org changed: What|Removed |Added CC||bergner at gcc dot gnu.org, ||hubicka at gcc dot gnu.org --- Comment #1 from seurer at gcc dot gnu.org --- g:c836addc227954db4e7b371618df2615bc977b70, r10-8624 I only noticed this on the one power 8 LE server.
[Bug lto/96617] New: [11 regression] ICE in gcc.dg/pr34457-2.c after r10-8624
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96617 Bug ID: 96617 Summary: [11 regression] ICE in gcc.dg/pr34457-2.c after r10-8624 Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- Executing on host: /home/seurer/gcc/git/build/gcc-10-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-10-test/gcc/ /home/seurer/gcc/git/gcc-10-test/gcc/testsuite/gcc.dg/pr34457-1.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -flto -O2 /home/seurer/gcc/git/gcc-10-test/gcc/testsuite/gcc.dg/pr34457-2.c -lm -o pr34457-1.exe(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-10-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-10-test/gcc/ /home/seurer/gcc/git/gcc-10-test/gcc/testsuite/gcc.dg/pr34457-1.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -flto -O2 /home/seurer/gcc/git/gcc-10-test/gcc/testsuite/gcc.dg/pr34457-2.c -lm -o pr34457-1.exe during IPA pass: cp lto1: internal compiler error: Segmentation fault 0x10791c93 crash_signal /home/seurer/gcc/git/gcc-10-test/gcc/toplev.c:328 0x10526c68 ipa_prop_read_section /home/seurer/gcc/git/gcc-10-test/gcc/ipa-prop.c:5061 0x10526c68 ipa_prop_read_jump_functions() /home/seurer/gcc/git/gcc-10-test/gcc/ipa-prop.c:5089 0x11172ce7 ipcp_read_summary /home/seurer/gcc/git/gcc-10-test/gcc/ipa-cp.c:5962 0x106896eb ipa_read_summaries_1 /home/seurer/gcc/git/gcc-10-test/gcc/passes.c:2837 0x101da857 read_cgraph_and_symbols(unsigned int, char const**) /home/seurer/gcc/git/gcc-10-test/gcc/lto/lto-common.c:2919 0x101bf547 lto_main() /home/seurer/gcc/git/gcc-10-test/gcc/lto/lto.c:625
[Bug fortran/96613] SIGFPE on min1() with -ffpe-trap=invalid switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96613 kargl at gcc dot gnu.org changed: What|Removed |Added Component|libfortran |fortran --- Comment #2 from kargl at gcc dot gnu.org --- Change component to 'fortran' as MIN1() is in-lined.
[Bug analyzer/96616] New: Many new analyzer failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96616 Bug ID: 96616 Summary: Many new analyzer failures Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: segher at gcc dot gnu.org Target Milestone: --- On powerpc64-linux. For -m32: +FAIL: gcc.dg/analyzer/init.c (test for warnings, line 100) +FAIL: gcc.dg/analyzer/init.c (test for warnings, line 101) +FAIL: gcc.dg/analyzer/init.c (test for warnings, line 102) +FAIL: gcc.dg/analyzer/init.c (test for warnings, line 124) +FAIL: gcc.dg/analyzer/init.c (test for warnings, line 125) +FAIL: gcc.dg/analyzer/init.c (test for warnings, line 126) +FAIL: gcc.dg/analyzer/init.c (test for warnings, line 127) +FAIL: gcc.dg/analyzer/init.c (test for warnings, line 128) +FAIL: gcc.dg/analyzer/init.c (test for warnings, line 129) +FAIL: gcc.dg/analyzer/init.c (test for warnings, line 30) +FAIL: gcc.dg/analyzer/init.c (test for warnings, line 31) +FAIL: gcc.dg/analyzer/init.c (test for warnings, line 51) +FAIL: gcc.dg/analyzer/init.c (test for warnings, line 52) +FAIL: gcc.dg/analyzer/init.c (test for warnings, line 72) +FAIL: gcc.dg/analyzer/init.c (test for warnings, line 73) +FAIL: gcc.dg/analyzer/init.c (test for warnings, line 74) +FAIL: gcc.dg/analyzer/init.c (test for warnings, line 75) +FAIL: gcc.dg/analyzer/init.c (test for warnings, line 99) +FAIL: gcc.dg/analyzer/init.c (test for excess errors) +FAIL: gcc.dg/analyzer/pr93032-mztools.c (test for excess errors) For -m64: +FAIL: gcc.dg/analyzer/init.c (test for warnings, line 100) +FAIL: gcc.dg/analyzer/init.c (test for warnings, line 101) +FAIL: gcc.dg/analyzer/init.c (test for warnings, line 102) +FAIL: gcc.dg/analyzer/init.c (test for warnings, line 124) +FAIL: gcc.dg/analyzer/init.c (test for warnings, line 125) +FAIL: gcc.dg/analyzer/init.c (test for warnings, line 126) +FAIL: gcc.dg/analyzer/init.c (test for warnings, line 127) +FAIL: gcc.dg/analyzer/init.c (test for warnings, line 128) +FAIL: gcc.dg/analyzer/init.c (test for warnings, line 129) +FAIL: gcc.dg/analyzer/init.c (test for warnings, line 72) +FAIL: gcc.dg/analyzer/init.c (test for warnings, line 73) +FAIL: gcc.dg/analyzer/init.c (test for warnings, line 74) +FAIL: gcc.dg/analyzer/init.c (test for warnings, line 75) +FAIL: gcc.dg/analyzer/init.c (test for warnings, line 99) +FAIL: gcc.dg/analyzer/init.c (test for excess errors) +FAIL: gcc.dg/analyzer/pr93032-mztools.c (test for excess errors) (That latter one is over a screenful of /home/segher/src/gcc/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:261:11: war ning: terminating analysis for this program point: EN: 810-818 [-Wanalyzer-too-c omplex] and all the rest are variations on /home/segher/src/gcc/gcc/testsuite/gcc.dg/analyzer/init.c:72:3: warning: UNKNOWN ).
[Bug libfortran/96613] SIGFPE on min1() with -ffpe-trap=invalid switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96613
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-08-14
Ever confirmed|0 |1
CC||kargl at gcc dot gnu.org
Priority|P3 |P4
--- Comment #1 from kargl at gcc dot gnu.org ---
Compiling with -fdump-tree-original gives
integer(kind=4) ix;
real(kind=4) x;
x = 7.7643945e+9;
{
integer(kind=4) M.0;
M.0 = 5000;
M.0 = MIN_EXPR <(integer(kind=4)) x, M.0>;
ix = M.0;
}
The MIN_EXPR is clealy a bad idea as x > huge(1).
The Fortran standard states, that for example,
MIN1(a,b) = INT(MIN(a,b)). I would have expected
to see something along the lines of
integer(kind=4) ix;
real(kind=4) x;
x = 7.7643945e+9;
{
real(kind=4) M.0;
M.0 = 5000.0;
M.0 = MIN_EXPR ;
ix = (integer(kind=4)) M.0;
}
If this is effecting your code, I suggest changing it to
min1() = int(min()) to work around the issue. This might
get fixed someday when a gfortran contributor has time to
look at it.
[Bug target/96607] GCC feeds SPARC/Solaris linker with unrecognized TLS sequences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96607 --- Comment #2 from Rainer Orth --- Created attachment 49063 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49063=edit Non-reduced test case.
[Bug target/96607] GCC feeds SPARC/Solaris linker with unrecognized TLS sequences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96607 Rainer Orth changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org, ||ro at gcc dot gnu.org --- Comment #1 from Rainer Orth --- To add some background: I've been experiencing ca. 250 test failures in the LLVM testsuite when building for sparcv9-sun-solaris2.11. As a workaround, I've posted [cmake] Don't build with -O3 -fPIC on Solaris/sparcv9 https://reviews.llvm.org/D85630 based on the observation that the SEGVs vanish if LLVM is compiled with -O -fPIC only instead of the default -O3 -fPIC. I've been using the following slightly reduced example (attached): * tqt.cpp is reduced from LLVM's llvm/unittests/Support/TaskQueueTest.cpp. * ThreadPool.cpp is LLVM 10.0.0 llvm/lib/Support/ThreadPool.cpp. They can be compiled and linked with the included tqt.sh; however that relies on LLVM 10 bundled with Solaris 11.4 for LLVM headers, libLLVMSupport and libLLVMDemangle. I haven't tried to produce a further reduced example yet.
[Bug lto/95362] [11 regression] pr34457-1.c and pr92088-1.c fail on arm and aarch64 since g:a746f952abb78af9db28a7f3bce442e113877c9c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95362 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:630474c8904cf797d0ee022d2ab177e25932c1d7 commit r10-8629-g630474c8904cf797d0ee022d2ab177e25932c1d7 Author: Jan Hubicka Date: Fri May 29 12:25:48 2020 +0200 Fix streamer desynchornization caused by streamer debugging patch it turns out I lost one hunk in the patch disabling extra streaming which causes streamer to go out of sync in the case non-trivial scc containing the node being streamed appears in local stream (which seems quite rare since it does not happen during bootstrap). 2020-05-29 Jan Hubicka PR lto/95362 * lto-streamer-out.c (lto_output_tree): Disable redundant streaming. (cherry picked from commit 11041c3151e30d197d1c2774721db24332eeccef)
[Bug tree-optimization/96615] New: Failure to optimize out loop that eventually ends but has no side effects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96615
Bug ID: 96615
Summary: Failure to optimize out loop that eventually ends but
has no side effects
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: ---
void f(int bytes)
{
bytes = (int)((unsigned int)bytes - 64);
if (bytes > 0)
f(bytes);
return;
}
This can be optimized to doing nothing. LLVM does this transformation, but GCC
does not.
[Bug c++/96614] New: constexpr deletion failure through pointer to base with virtual base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96614
Bug ID: 96614
Summary: constexpr deletion failure through pointer to base
with virtual base class
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pkeir at outlook dot com
Target Milestone: ---
Created attachment 49062
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49062=edit
A C++ file containing the code described.
The C++20 code below (also attached) fails to compile with GCC trunk.
struct FooBase {
constexpr virtual ~FooBase() {}
};
struct Foo : public FooBase {};
constexpr bool test()
{
FooBase* pb = new Foo;
delete pb;
return true;
}
int main(int argc, char *argv[])
{
static_assert(test());
test(); // no problem
return 0;
}
The error is invoked by the `static_assert` expression, and relates to the call
to `delete pb`. It states:
virtual constexpr Foo::~Foo()’ used before its definition
[Bug c++/95514] constexpr dynamic memory allocation compile error with inheritance and the this pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95514
Paul Keir changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from Paul Keir ---
Here is a reduced test case which removes prior use of static_cast and a
pointer reference parameter.
struct FooBase {
constexpr FooBase* get_this() { return this; }
int x;
};
struct Foo : FooBase {};
constexpr bool test()
{
Foo* pf = new Foo;
delete pf->get_this();
return true;
}
constexpr bool b = test();
--- Comment #3 from Paul Keir ---
The code invokes undefined behaviour; as it tries to delete the object through
pointer to base.
[Bug libfortran/96613] New: SIGFPE on min1() with -ffpe-trap=invalid switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96613 Bug ID: 96613 Summary: SIGFPE on min1() with -ffpe-trap=invalid switch Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: thomas.huxhorn at web dot de Target Milestone: --- The program fails if -ffpe-trap=invalid is present and no optimization flag is set. It print 5000 with any optimization level set. The expected behavior is that it print 5000 with no optimization. Perhaps it is possible to first calculate the minimum of both real values and then convert it to integer? Testet with gcc 10.1 and 4.9 Compile with gfortran -ffpe-trap=invalid -g -ggdb -fbacktrace test.f90 program test implicit none real :: X integer :: IX X = 7.7643945e+09 IX = MIN1(5000.0, X) write(*,*) IX end program gdb ./a.out (gdb) run Starting program: /home/thomas/a.out Program received signal SIGFPE, Arithmetic exception. 0x00400794 in test () at test.f90:8 8 IX = MIN1(5000.0, X)
[Bug analyzer/93388] ensure -fanalyzer works with our C code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93388 --- Comment #18 from David Binderman --- (In reply to Arseny Solokha from comment #17) > After the recent analyzer overhaul it's probably time to update this list > once again. Done. $ cat 20200814.ana.O2.c.out | fgrep "internal c" | fgrep analyzer ./c-c++-common/vector-subscript-3.c:5:16: internal compiler error: in validate, at analyzer/region-model.cc:243 ./gcc.c-torture/compile/20010107-1.c:7:3: internal compiler error: in get_or_create_mem_ref, at analyzer/region-model.cc:6932 ./gcc.dg/pr70022.c:9:3: internal compiler error: in validate, at analyzer/region-model.cc:243 ./gcc.dg/pr78526.c:10:1: internal compiler error: in validate, at analyzer/region-model.cc:243 ./gcc.target/i386/addr-space-5.c:13:3: internal compiler error: in get_or_create_mem_ref, at analyzer/region-model.cc:6932 ./gcc.target/i386/pr79498.c:9:1: internal compiler error: in validate, at analyzer/region-model.cc:243 $ So downto two crashes. I used flags -g -O2 -fanalyzer > Maybe trying each optimization level in turn besides -O2 might > also make sense. Maybe. One thing at a time. Let's get popular flags like -g -O2 working first. Then maybe -g -O3 then -g -O3 -march=native. Then when that's all working we can try out -fanalyzer on the source code of gcc. Just some ideas.
[Bug bootstrap/96612] [11 Regression][submitted patch] Fails to bootstrap with older --build= than --host= compiler due to missing -std=c++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96612 Tobias Burnus changed: What|Removed |Added Version|10.0|11.0 Target Milestone|--- |11.0
[Bug c/96610] ICE: in gimplify_va_arg_expr, at gimplify.c:15150 since r7-2847-gba9bbd6f584afe29
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96610 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-08-14 Status|UNCONFIRMED |NEW Summary|ICE: in |ICE: in |gimplify_va_arg_expr, at|gimplify_va_arg_expr, at |gimplify.c:15150|gimplify.c:15150 since ||r7-2847-gba9bbd6f584afe29 CC||marxin at gcc dot gnu.org, ||vries at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Started to ICE with r7-2847-gba9bbd6f584afe29.
[Bug analyzer/96611] ICE in get_or_create_cluster
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96611 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2020-08-14
[Bug bootstrap/96612] New: [11 Regression][submitted patch] Fails to bootstrap with older --build= than --host= compiler due to missing -std=c++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96612
Bug ID: 96612
Summary: [11 Regression][submitted patch] Fails to bootstrap
with older --build= than --host= compiler due to
missing -std=c++11
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: build, patch
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551900.html
The issue occurs when doing a cross build with
--build= being a GCC 5.2 compiler
--host= being a GCC 8.2 compiler
While the latter supports C++11 out of the box, GCC 5 still needs --std=c++11
in order to compile C++11. The configure check only checks the ${host} compiler
but not the ${build} / CXX_FOR_BUILD compiler – hence, no flag is added.
I think the proper solution is to do the C++11 check also for the CXX_FOR_BUILD
compiler, as done in the patch linked above,
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551900.html
... but technically it is a regression as reverting the following commits also
fixes the build:
commit https://gcc.gnu.org/g:d59a576b8b5e12c3a56f0262912090e2921f5daa
Redefine NULL to nullptr
2020-06-30
plus the three patches
commit https://gcc.gnu.org/g:20a2e6afa82c165bcd1a8749478e9402a25088a4
recog: Restore builds with Clang
Workaround forhttps://bugs.llvm.org/show_bug.cgi?id=46377
2020-06-22
which was the follow up to
commit https://gcc.gnu.org/g:4e49b994de060d4a6c9318d0ed52ef038153426e
recog: Tweak insn_gen_fn::operator() definition
2020-06-17
which was the follow-up patch to
commit https://gcc.gnu.org/g:3a179232a743b2b1987b21034cd5bb3bc660ee85
recog: Use parameter packs for operator()
2020-06-12
[Bug c++/96605] ICE in tsubst, at cp/pt.c:14929 on C++20 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96605 Martin Liška changed: What|Removed |Added Summary|ICE on C++20 code |ICE in tsubst, at ||cp/pt.c:14929 on C++20 code Ever confirmed|0 |1 Last reconfirmed||2020-08-14 Status|UNCONFIRMED |NEW CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Confirmed, started with the revision that added -fconcepts-ts r10-3735-gcb57504a55015891.
[Bug target/96536] -fcf-protection code in i386.md:restore_stack_nonlocal uses invalid compare-and-jump rtl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96536 --- Comment #5 from Hongtao.liu --- (In reply to Uroš Bizjak from comment #4) > Created attachment 49060 [details] > Proposed patch > > Attached patch completely rewrites restore_stack_nonlocal expander. > > Can someone please test the patch on a CET enabled target? I can help with this, we have CET enabled tigerlake.
[Bug analyzer/96611] New: ICE in get_or_create_cluster
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96611
Bug ID: 96611
Summary: ICE in get_or_create_cluster
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: pmatos at gcc dot gnu.org
Target Milestone: ---
On GCC tip of master from 20200814.
While static analyzing the racket source (github.com/racket/racket), it fails
on (reduced):
struct {
long a;
} * b;
void c();
int d() {
c();
c(>a);
return 1;
}
with message:
~/racket/racket/src/bc/rktio# /gcc/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/cc1
-fpreprocessed rktio_sleep.i -quiet -dumpbase rktio_sleep.c -dumpbase-ext .c
-mtune=generic -march=x86-64 -g -O2 -Wall -version -Werror -Wfatal-errors
-fanalyzer -o rktio_sleep.s
GNU C17 (GCC) version 11.0.0 20200814 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 8.3.0, GMP version 6.1.2, MPFR version 4.0.2,
MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C17 (GCC) version 11.0.0 20200814 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 8.3.0, GMP version 6.1.2, MPFR version 4.0.2,
MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: bca87f5421b78e00047ba8f5a58d16b4
during IPA pass: analyzer
rktio_sleep.i: In function 'd':
rktio_sleep.i:7:3: internal compiler error: in get_or_create_cluster, at
analyzer/store.cc:1613
7 | c(>a);
| ^~~~
0x735ea1 ana::store::get_or_create_cluster(ana::region const*)
../../gcc/gcc/analyzer/store.cc:1613
0x115ca10 ana::store::mark_as_escaped(ana::region const*)
../../gcc/gcc/analyzer/store.cc:1694
0x115237b ana::reachable_regions::mark_escaped_clusters()
../../gcc/gcc/analyzer/region-model-reachability.cc:218
0x113e3fc ana::region_model::handle_unrecognized_call(gcall const*,
ana::region_model_context*)
../../gcc/gcc/analyzer/region-model.cc:773
0x113e5bd ana::region_model::on_call_post(gcall const*, bool,
ana::region_model_context*)
../../gcc/gcc/analyzer/region-model.cc:707
0x111af7c ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode
const*, gimple const*, ana::program_state*) const
../../gcc/gcc/analyzer/engine.cc:1105
0x111bd22 ana::exploded_graph::process_node(ana::exploded_node*)
../../gcc/gcc/analyzer/engine.cc:2526
0x111c69a ana::exploded_graph::process_worklist()
../../gcc/gcc/analyzer/engine.cc:2341
0x111e6bc ana::impl_run_checkers(ana::logger*)
../../gcc/gcc/analyzer/engine.cc:4107
0x111f8bd ana::run_checkers()
../../gcc/gcc/analyzer/engine.cc:4175
0x11142b8 execute
../../gcc/gcc/analyzer/analyzer-pass.cc:84
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.
