[Bug target/98285] xtensa doesn't use addx/subx instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98285 jcmvbkbc at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from jcmvbkbc at gcc dot gnu.org --- Fix committed to master.
[Bug target/98285] xtensa doesn't use addx/subx instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98285 --- Comment #1 from CVS Commits --- The master branch has been updated by Max Filippov : https://gcc.gnu.org/g:06ff8708f0b834cf1b35afa46113c6c973905cad commit r11-6035-g06ff8708f0b834cf1b35afa46113c6c973905cad Author: Max Filippov Date: Sat Dec 12 12:14:40 2020 -0800 gcc: xtensa: fix PR target/98285 2020-12-14 Max Filippov gcc/ * config/xtensa/predicates.md (addsubx_operand): Change accepted values from 2/4/8 to 1..3. * config/xtensa/xtensa.md (*addx, *subx): Change RTL pattern to use 'ashift' instead of 'mult'. Update operands[3] value. gcc/testsuite/ * gcc.target/xtensa/pr98285.c: New test.
[Bug fortran/98284] ICE in get_array_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98284
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Last reconfirmed||2020-12-15
CC||kargl at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1 from kargl at gcc dot gnu.org ---
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 280157)
+++ gcc/fortran/resolve.c (working copy)
@@ -16006,6 +16006,13 @@ check_data_variable (gfc_data_variable *var, locus *wh
if (ref->type == REF_COMPONENT && ref->u.c.component->attr.pointer)
has_pointer = 1;
+ if (ref->type == REF_COMPONENT && ref->u.c.component->attr.allocatable)
+ {
+ gfc_error ("DATA element %qs at %L cannot have an allocatable "
+"attribute", ref->u.c.component->name, where);
+ return false;
+ }
+
if (has_pointer)
{
if (ref->type == REF_ARRAY && ref->u.ar.type != AR_FULL)
[Bug target/98285] New: xtensa doesn't use addx/subx instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98285
Bug ID: 98285
Summary: xtensa doesn't use addx/subx instructions
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jcmvbkbc at gcc dot gnu.org
Target Milestone: ---
Prior to version 6.1.0 gcc for xtensa used addx and subx instructions to
implement multiplication by small integer constants. After the commit
963ba1b26665 ("combine.c (make_compound_operation): Remove checks for
PLUS/MINUS rtx type.") it no longer does that.
[Bug fortran/98284] New: ICE in get_array_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98284 Bug ID: 98284 Summary: ICE in get_array_index Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- gfortran-11.0.0-alpha20201213 snapshot (g:2c3d487a9a8af00c0c462cd4e1a112804b9cc156) ICEs when compiling the following testcase, reduced from f18/testsuite/Semantics/data04.f90 from the flang 11.0.0 test suite: module at contains subroutine r8(zd) type uk integer, allocatable :: h5(:) end type uk type(uk) :: n0 integer :: zd DATA(n0 % h5(zd), zd = 1, 10) / 10 * 1/ end subroutine r8 end module at % powerpc-e300c3-linux-gnu-gfortran-11.0.0 -c uj2rgix5.f90 f951: internal compiler error: Segmentation fault 0xe7df86 crash_signal /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201213/work/gcc-11-20201213/gcc/toplev.c:327 0x7e5977 get_array_index /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201213/work/gcc-11-20201213/gcc/fortran/data.c:69 0x7e5977 gfc_assign_data_value(gfc_expr*, gfc_expr*, __mpz_struct*, __mpz_struct (*) [1]) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201213/work/gcc-11-20201213/gcc/fortran/data.c:285 0x885f44 check_data_variable /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201213/work/gcc-11-20201213/gcc/fortran/resolve.c:16276 0x88641c traverse_data_var /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201213/work/gcc-11-20201213/gcc/fortran/resolve.c:16413 0x88641c traverse_data_list /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201213/work/gcc-11-20201213/gcc/fortran/resolve.c:16369 0x88ce76 traverse_data_var /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201213/work/gcc-11-20201213/gcc/fortran/resolve.c:16411 0x88ce76 resolve_data /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201213/work/gcc-11-20201213/gcc/fortran/resolve.c:16468 0x88ce76 resolve_types /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201213/work/gcc-11-20201213/gcc/fortran/resolve.c:17295 0x88cd6b resolve_types /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201213/work/gcc-11-20201213/gcc/fortran/resolve.c:17281 0x87d57e gfc_resolve(gfc_namespace*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201213/work/gcc-11-20201213/gcc/fortran/resolve.c:17385 0x87d57e gfc_resolve(gfc_namespace*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201213/work/gcc-11-20201213/gcc/fortran/resolve.c:17366 0x86ebd1 gfc_parse_file() /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201213/work/gcc-11-20201213/gcc/fortran/parse.c:6492 0x8c474e gfc_be_parse_file /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201213/work/gcc-11-20201213/gcc/fortran/f95-lang.c:212 (While my target here is powerpc, the ICE is not target-specific.)
[Bug fortran/97692] GNU Fortran is not working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97692 ninos changed: What|Removed |Added Resolution|--- |WORKSFORME Status|WAITING |RESOLVED --- Comment #10 from ninos --- It is caused by xilinx bsp setting. Close for now.
[Bug c++/98283] New: decltype(auto) may be deduce static data member to wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98283
Bug ID: 98283
Summary: decltype(auto) may be deduce static data member to
wrong type
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wuyongwei at gmail dot com
Target Milestone: ---
The following code shows that `decltype(auto)` is deduced to the wrong type
when used in template code for an expression like `(var.static_data_member>)`.
```cpp
#include
#include
#include
template
struct type_displayer;
#define TYPE_DISPLAY(x) type_displayer test_obj;
struct SkipField {};
struct TestSkip {
template struct FIELD;
int value;
static SkipField unused;
template
struct FIELD {
T &&obj;
FIELD(T &&ref) : obj(std::forward(ref))
{
}
decltype(auto) value()
{
return (obj.value);
}
static constexpr const char *name()
{
return "value";
}
};
template
struct FIELD {
T &&obj;
FIELD(T &&ref) : obj(std::forward(ref))
{
}
decltype(auto) value()
{
return (obj.unused);
}
decltype((obj.unused)) valueAlt()
{
return (obj.unused);
}
static constexpr const char *name()
{
return "unused";
}
};
};
int main()
{
TestSkip s;
// decltype((TestSkip::FIELD(s).value()))is int&
// decltype((TestSkip::FIELD(s).value()))is SkipField,
but it should be SkipField&
// decltype((TestSkip::FIELD(s).valueAlt())) is SkipField&
}
```
This is a simplified usage scenario, where I want to use a macro to generate
code to emulate static reflection. Here is the problematic part:
```cpp
decltype(auto) value()
{
return (obj.unused);
}
```
This function returns `SkipField`, instead of the expected `SkipField&`. I have
verified that clang does what I want.
Currently I have to avoid `decltype(auto)` as a workaround:
```cpp
decltype((obj.unused)) valueAlt()
{
return (obj.unused);
}
```
(I used the macro TYPE_DISPLAY to check the type of an expression.)
[Bug target/98112] Add -fdirect-access-external-data & drop HAVE_LD_PIE_COPYRELOC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112 --- Comment #3 from Fangrui Song --- Are you happy with the option name -f[no-]direct-access-external-data ? https://reviews.llvm.org/D92633 is what I want to add to Clang. I want GCC and Clang to use the same option names...
[Bug c++/98282] [8/9/10/11 Regression] Segmentation fault when compiling with optimization >= 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98282 Jakub Jelinek changed: What|Removed |Added Summary|Segmentation fault when |[8/9/10/11 Regression] |compiling with optimization |Segmentation fault when |>= 2|compiling with optimization ||>= 2 Priority|P3 |P2 Keywords||ice-on-valid-code Target Milestone|--- |8.5 --- Comment #4 from Jakub Jelinek --- Started with r7-1867-g3c5b29f56103d60f4f4dca7136ae4dcc7987a728
[Bug c++/98282] Segmentation fault when compiling with optimization >= 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98282
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2020-12-14
--- Comment #3 from Jakub Jelinek ---
Reduced testcase that ICEs with -O2 even with current trunk in PRE:
template struct g;
template struct g { typedef b c; };
template typename g::c &&d(b &&e) {
return static_cast::c &&>(e);
}
void *operator new(__SIZE_TYPE__, void *f) { return f; }
struct h;
struct k {
using i = h *;
};
struct D {
k::i j;
};
struct p : D {
p(p &&) : D() {}
};
struct r {
using l = int;
r(r &&) : ad() {}
l *ad;
};
struct s {
static s m();
};
struct t {
template void operator=(ah);
};
struct I {
template void q(o ai) {
*ai = aj();
s::m();
}
h aj();
};
template class as;
struct J {
int a;
char av;
};
template struct aw : J {
void ax(...) {}
};
template
struct aw, an, n...> : aw, n...> {
using az = as;
using ba = aw;
char bb;
an &bc() { return *reinterpret_cast(this); }
void ax(az *bd) {
if (bb)
new (bd) an(d(bc()));
ba::ax(bd);
}
};
template struct as : aw, n...> {
as();
as(as &&be) { be.ax(this); }
void operator=(as be) { be.ax(this); }
};
struct h {
as bg;
};
using bh = t;
struct u {
bh bj;
};
I bk();
template void bl() {
h a;
bk().q(&a);
}
template void bn(int) {
u b;
b.bj = bl;
}
void bp() { bn(0); }
/usr/src/gcc/obj/gcc/cc1plus -quiet -O2 pr98282.ii
during GIMPLE pass: pre
pr98282.ii: In function ‘void bl() [with = int]’:
pr98282.ii:68:26: internal compiler error: Segmentation fault
68 | template void bl() {
| ^~
0x17098ba crash_signal
../../gcc/toplev.c:327
0x9dc372 contains_struct_check(tree_node const*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/tree.h:3707
0xa7089b wi::to_wide(tree_node const*)
../../gcc/tree.h:5983
0x19caa55 compute_avail
../../gcc/tree-ssa-pre.c:4214
0x19cb145 execute
../../gcc/tree-ssa-pre.c:4408
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/98282] Segmentation fault when compiling with optimization >= 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98282 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- GCC 7.x isn't supported anymore. That said, this is an ICE that went away on trunk and in 10.x with the r10-3583-g562d1e9556777988ae46c5d1357af2636bc272ea change, which means it likely went latent because those changes were inliner heuristic changes and the ICE in PRE. I can reproduce on 9 branch. cvise reducing now.
[Bug testsuite/98208] make check's check-fixincludes fails in sys/types.h around AIX_PHYSADR_T_CHECK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98208 Ilya Leoshkevich changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Ilya Leoshkevich --- I've committed the fix: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=057dc81f820b I think I messed up the commit message and Bugzilla did not link the commit to this bug. Anyway, marking this as RESOLVED/FIXED now.
[Bug testsuite/90806] Warray-bounds-2.c fail on cross-aarch64 on RH6 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90806
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
CC||ebotcazou at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
Last reconfirmed||2020-12-14
--- Comment #8 from Eric Botcazou ---
We have been seeing it for a few days now, along with Warray-bounds-30.c. What
has changed in our setup is only the base compiler. The reduction of
Warray-bounds-30.c shows that for:
#define DIFF_MAX __PTRDIFF_MAX__
#define DIFF_MIN (-DIFF_MAX - 1)
#define MIN DIFF_MIN
void sink (int, ...);
#define T(...) sink (0, __VA_ARGS__)
void test_local_char_array (void)
{
char ar3[3] = { 1, 2, 3 };
char *p = ar3;
T (p[MIN]); /* { dg-warning "subscript -\[0-9\]+ is outside array
bounds of .char\\\[3]." } */
T (p[-1]);/* { dg-warning "subscript -1 is outside array bounds of
.char\\\[3]." } */
T (&p[MIN]); /* { dg-warning "subscript -\[0-9\]+ is \(below|outside\)
array bounds of .char\\\[3]." } */
T (&p[-1]); /* { dg-warning "subscript -1 is \(below|outside\) array
bounds of .char\\\[3]." } */
}
compiled at -O2, the FRE1 pass behaves differently:
@@ -15,11 +15,11 @@
Value numbering store ar3 to "\x01\x02\x03"
Setting value number of .MEM_10 to .MEM_10 (changed)
Value numbering stmt = _2 = MEM[(char *)&ar3 + -9223372036854775808B];
-Setting value number of _2 to _2 (changed)
-Making available beyond BB2 _2 for value _2
+Setting value number of _2 to 1 (changed)
Value numbering stmt = _3 = (int) _2;
-Setting value number of _3 to _3 (changed)
-Making available beyond BB2 _3 for value _3
+Match-and-simplified (int) _2 to 1
+RHS (int) _2 simplified to 1
+Setting value number of _3 to 1 (changed)
Value numbering stmt = sink (0, _3);
Setting value number of .MEM_12 to .MEM_12 (changed)
Value numbering stmt = _5 = MEM[(char *)&ar3 + -1B];
@@ -39,21 +39,21 @@
Value numbering stmt = return;
marking outgoing edge 2 -> 1 executable
RPO iteration over 1 blocks visited 1 blocks in total discovering 1 executable
blocks iterating 1.0 times, a block was visited max. 1 times
-RPO tracked 4 values available at 4 locations and 10 lattice elements
+RPO tracked 2 values available at 2 locations and 10 lattice elements
+Replaced MEM[(char *)&ar3 + -9223372036854775808B] with 1 in all uses of _2 =
MEM[(char *)&ar3 + -9223372036854775808B];
+Replaced (int) _2 with 1 in all uses of _3 = (int) _2;
+Removing dead stmt _3 = (int) _2;
+Removing dead stmt _2 = MEM[(char *)&ar3 + -9223372036854775808B];
test_local_char_array ()
{
char * p;
char ar3[3];
- char _2;
- int _3;
char _5;
int _6;
:
ar3 = "\x01\x02\x03";
- _2 = MEM[(char *)&ar3 + -9223372036854775808B];
- _3 = (int) _2;
- sink (0, _3);
+ sink (0, 1);
_5 = MEM[(char *)&ar3 + -1B];
_6 = (int) _5;
sink (0, _6);
Richard, can you imagine what could be the cause of this? Didn't you fix
something similar relatively recently, e.g. an expression with side effects
that would depend on the order the C++ compiler chooses for them or something
along this line?
[Bug c++/98216] [C++20] std::array template parameter error with negative values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98216
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #5 from Patrick Palka ---
Related testcase which may or may not be caused by the same underlying bug:
$ cat testcase.C
template void foo() {}
template void foo<-1.0>();
template void foo<-2.0>();
$ g++ -std=c++20 testcase.C
testcase.C:3:26: error: Two symbols with same comdat_group are not linked by
the same_comdat_group list.
3 | template void foo<-2.0>();
| ^
_Z3fooILdEEvv/1 (void foo() [with double s = -2.0e+0])
@0x7fdb12c4aee0
Type: function definition analyzed
Visibility: force_output forced_by_abi no_reorder public weak
comdat_group:_Z3fooILdEEvv one_only
previous sharing asm name: 0
References:
Referring:
Function flags: body
Called by:
Calls:
_Z3fooILdEEvv/0 (void foo() [with double s = -1.0e+0])
@0x7fdb12c4add0
Type: function definition analyzed
Visibility: force_output forced_by_abi no_reorder public weak
comdat_group:_Z3fooILdEEvv one_only
next sharing asm name: 1
References:
Referring:
Function flags: body
Called by:
Calls:
testcase.C:3:26: internal compiler error: symtab_node::verify failed
0xbebe81 symtab_node::verify_symtab_nodes()
/home/patrick/code/gcc/gcc/symtab.c:1406
0xc00586 symtab_node::checking_verify_symtab_nodes()
/home/patrick/code/gcc/gcc/cgraph.h:675
0xc00586 symbol_table::compile()
/home/patrick/code/gcc/gcc/cgraphunit.c:2277
0xc02f67 symbol_table::compile()
/home/patrick/code/gcc/gcc/cgraphunit.c:2274
0xc02f67 symbol_table::finalize_compilation_unit()
/home/patrick/code/gcc/gcc/cgraphunit.c:2542
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 98160, which changed state. Bug 98160 Summary: [11 Regression] ICE in default_tree_printer at gcc/tree-diagnostic.c:270 since r11-5732-gdce6c58db87ebf7f https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98160 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/98160] [11 Regression] ICE in default_tree_printer at gcc/tree-diagnostic.c:270 since r11-5732-gdce6c58db87ebf7f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98160 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Martin Sebor --- Fixed in r11-6028.
[Bug c++/57111] Generalize -Wfree-nonheap-object to delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57111 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=54202 Status|ASSIGNED|RESOLVED Target Milestone|--- |11.0 Resolution|--- |FIXED --- Comment #16 from Martin Sebor --- Done for GCC 11, including issuing warnings for system headers. As I mentioned, the warning is not free of false positives (e.g., pr54202).
[Bug c++/57111] Generalize -Wfree-nonheap-object to delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57111 --- Comment #15 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:fe7f75cf16783589eedbab597e6d0b8d35d7e470 commit r11-6028-gfe7f75cf16783589eedbab597e6d0b8d35d7e470 Author: Martin Sebor Date: Mon Dec 14 13:30:00 2020 -0700 Correct/improve maybe_emit_free_warning (PR middle-end/98166, PR c++/57111, PR middle-end/98160). Resolves: PR middle-end/98166 - bogus -Wmismatched-dealloc on user-defined allocator and inlining PR c++/57111 - 57111 - Generalize -Wfree-nonheap-object to delete PR middle-end/98160 - ICE in default_tree_printer at gcc/tree-diagnostic.c:270 gcc/ChangeLog: PR middle-end/98166 PR c++/57111 PR middle-end/98160 * builtins.c (check_access): Call tree_inlined_location fndecl_alloc_p): Handle BUILT_IN_ALIGNED_ALLOC and BUILT_IN_GOMP_ALLOC. call_dealloc_p): Remove unused function. (new_delete_mismatch_p): Call valid_new_delete_pair_p and rework. (matching_alloc_calls_p): Handle built-in deallocation functions. (warn_dealloc_offset): Corrct the handling of user-defined operators delete. (maybe_emit_free_warning): Avoid assuming expression is a decl. Simplify. * doc/extend.texi (attribute malloc): Update. * tree-ssa-dce.c (valid_new_delete_pair_p): Factor code out into valid_new_delete_pair_p in tree.c. * tree.c (tree_inlined_location): Define new function. (valid_new_delete_pair_p): Define. * tree.h (tree_inlined_location): Declare. (valid_new_delete_pair_p): Declare. gcc/c-family/ChangeLog: PR middle-end/98166 PR c++/57111 PR middle-end/98160 * c-attribs.c (maybe_add_noinline): New function. (handle_malloc_attribute): Call it. Use ATTR_FLAG_INTERNAL. Implicitly add attribute noinline to functions not declared inline and warn on those. libstdc++-v3/ChangeLog: * testsuite/ext/vstring/requirements/exception/basic.cc: Suppress a false positive warning. * testsuite/ext/vstring/requirements/exception/propagation_consistent.cc: Same. gcc/testsuite/ChangeLog: PR middle-end/98166 PR c++/57111 PR middle-end/98160 * g++.dg/warn/Wmismatched-dealloc-2.C: Adjust test of expected warning. * g++.dg/warn/Wmismatched-new-delete.C: Same. * gcc.dg/Wmismatched-dealloc.c: Same. * c-c++-common/Wfree-nonheap-object-2.c: New test. * c-c++-common/Wfree-nonheap-object-3.c: New test. * c-c++-common/Wfree-nonheap-object.c: New test. * c-c++-common/Wmismatched-dealloc.c: New test. * g++.dg/warn/Wfree-nonheap-object-3.C: New test. * g++.dg/warn/Wfree-nonheap-object-4.C: New test. * g++.dg/warn/Wmismatched-dealloc-2.C: New test. * g++.dg/warn/Wmismatched-new-delete-2.C: New test. * g++.dg/warn/Wmismatched-new-delete.C: New test. * gcc.dg/Wmismatched-dealloc-2.c: New test. * gcc.dg/Wmismatched-dealloc-3.c: New test. * gcc.dg/Wmismatched-dealloc.c: New test.
[Bug middle-end/98166] bogus -Wmismatched-dealloc on user-defined allocator and inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98166 --- Comment #2 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:fe7f75cf16783589eedbab597e6d0b8d35d7e470 commit r11-6028-gfe7f75cf16783589eedbab597e6d0b8d35d7e470 Author: Martin Sebor Date: Mon Dec 14 13:30:00 2020 -0700 Correct/improve maybe_emit_free_warning (PR middle-end/98166, PR c++/57111, PR middle-end/98160). Resolves: PR middle-end/98166 - bogus -Wmismatched-dealloc on user-defined allocator and inlining PR c++/57111 - 57111 - Generalize -Wfree-nonheap-object to delete PR middle-end/98160 - ICE in default_tree_printer at gcc/tree-diagnostic.c:270 gcc/ChangeLog: PR middle-end/98166 PR c++/57111 PR middle-end/98160 * builtins.c (check_access): Call tree_inlined_location fndecl_alloc_p): Handle BUILT_IN_ALIGNED_ALLOC and BUILT_IN_GOMP_ALLOC. call_dealloc_p): Remove unused function. (new_delete_mismatch_p): Call valid_new_delete_pair_p and rework. (matching_alloc_calls_p): Handle built-in deallocation functions. (warn_dealloc_offset): Corrct the handling of user-defined operators delete. (maybe_emit_free_warning): Avoid assuming expression is a decl. Simplify. * doc/extend.texi (attribute malloc): Update. * tree-ssa-dce.c (valid_new_delete_pair_p): Factor code out into valid_new_delete_pair_p in tree.c. * tree.c (tree_inlined_location): Define new function. (valid_new_delete_pair_p): Define. * tree.h (tree_inlined_location): Declare. (valid_new_delete_pair_p): Declare. gcc/c-family/ChangeLog: PR middle-end/98166 PR c++/57111 PR middle-end/98160 * c-attribs.c (maybe_add_noinline): New function. (handle_malloc_attribute): Call it. Use ATTR_FLAG_INTERNAL. Implicitly add attribute noinline to functions not declared inline and warn on those. libstdc++-v3/ChangeLog: * testsuite/ext/vstring/requirements/exception/basic.cc: Suppress a false positive warning. * testsuite/ext/vstring/requirements/exception/propagation_consistent.cc: Same. gcc/testsuite/ChangeLog: PR middle-end/98166 PR c++/57111 PR middle-end/98160 * g++.dg/warn/Wmismatched-dealloc-2.C: Adjust test of expected warning. * g++.dg/warn/Wmismatched-new-delete.C: Same. * gcc.dg/Wmismatched-dealloc.c: Same. * c-c++-common/Wfree-nonheap-object-2.c: New test. * c-c++-common/Wfree-nonheap-object-3.c: New test. * c-c++-common/Wfree-nonheap-object.c: New test. * c-c++-common/Wmismatched-dealloc.c: New test. * g++.dg/warn/Wfree-nonheap-object-3.C: New test. * g++.dg/warn/Wfree-nonheap-object-4.C: New test. * g++.dg/warn/Wmismatched-dealloc-2.C: New test. * g++.dg/warn/Wmismatched-new-delete-2.C: New test. * g++.dg/warn/Wmismatched-new-delete.C: New test. * gcc.dg/Wmismatched-dealloc-2.c: New test. * gcc.dg/Wmismatched-dealloc-3.c: New test. * gcc.dg/Wmismatched-dealloc.c: New test.
[Bug tree-optimization/98160] [11 Regression] ICE in default_tree_printer at gcc/tree-diagnostic.c:270 since r11-5732-gdce6c58db87ebf7f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98160 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:fe7f75cf16783589eedbab597e6d0b8d35d7e470 commit r11-6028-gfe7f75cf16783589eedbab597e6d0b8d35d7e470 Author: Martin Sebor Date: Mon Dec 14 13:30:00 2020 -0700 Correct/improve maybe_emit_free_warning (PR middle-end/98166, PR c++/57111, PR middle-end/98160). Resolves: PR middle-end/98166 - bogus -Wmismatched-dealloc on user-defined allocator and inlining PR c++/57111 - 57111 - Generalize -Wfree-nonheap-object to delete PR middle-end/98160 - ICE in default_tree_printer at gcc/tree-diagnostic.c:270 gcc/ChangeLog: PR middle-end/98166 PR c++/57111 PR middle-end/98160 * builtins.c (check_access): Call tree_inlined_location fndecl_alloc_p): Handle BUILT_IN_ALIGNED_ALLOC and BUILT_IN_GOMP_ALLOC. call_dealloc_p): Remove unused function. (new_delete_mismatch_p): Call valid_new_delete_pair_p and rework. (matching_alloc_calls_p): Handle built-in deallocation functions. (warn_dealloc_offset): Corrct the handling of user-defined operators delete. (maybe_emit_free_warning): Avoid assuming expression is a decl. Simplify. * doc/extend.texi (attribute malloc): Update. * tree-ssa-dce.c (valid_new_delete_pair_p): Factor code out into valid_new_delete_pair_p in tree.c. * tree.c (tree_inlined_location): Define new function. (valid_new_delete_pair_p): Define. * tree.h (tree_inlined_location): Declare. (valid_new_delete_pair_p): Declare. gcc/c-family/ChangeLog: PR middle-end/98166 PR c++/57111 PR middle-end/98160 * c-attribs.c (maybe_add_noinline): New function. (handle_malloc_attribute): Call it. Use ATTR_FLAG_INTERNAL. Implicitly add attribute noinline to functions not declared inline and warn on those. libstdc++-v3/ChangeLog: * testsuite/ext/vstring/requirements/exception/basic.cc: Suppress a false positive warning. * testsuite/ext/vstring/requirements/exception/propagation_consistent.cc: Same. gcc/testsuite/ChangeLog: PR middle-end/98166 PR c++/57111 PR middle-end/98160 * g++.dg/warn/Wmismatched-dealloc-2.C: Adjust test of expected warning. * g++.dg/warn/Wmismatched-new-delete.C: Same. * gcc.dg/Wmismatched-dealloc.c: Same. * c-c++-common/Wfree-nonheap-object-2.c: New test. * c-c++-common/Wfree-nonheap-object-3.c: New test. * c-c++-common/Wfree-nonheap-object.c: New test. * c-c++-common/Wmismatched-dealloc.c: New test. * g++.dg/warn/Wfree-nonheap-object-3.C: New test. * g++.dg/warn/Wfree-nonheap-object-4.C: New test. * g++.dg/warn/Wmismatched-dealloc-2.C: New test. * g++.dg/warn/Wmismatched-new-delete-2.C: New test. * g++.dg/warn/Wmismatched-new-delete.C: New test. * gcc.dg/Wmismatched-dealloc-2.c: New test. * gcc.dg/Wmismatched-dealloc-3.c: New test. * gcc.dg/Wmismatched-dealloc.c: New test.
[Bug tree-optimization/96239] Failure to recognize __builtin_bswap16 pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96239 --- Comment #3 from Jakub Jelinek --- Created attachment 49766 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49766&action=edit gcc11-pr96239.patch So, I wrote this untested patch which fixes my testcases, but doesn't fix due to pass ordering issue the original one, as the bswap pass is done before vectorization only (both loop and slp). I guess some of the options are schedule another bswap pass instance later, or include just the vector CONSTRUCTOR handling in e.g. the store-merging pass (yes, it would be related just because the bswap code lives in the store-merging source file and performs also bswap optimizations upon stores).
[Bug c++/98282] Segmentation fault when compiling with optimization >= 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98282 --- Comment #1 from Benjamin Kietzman --- Created attachment 49765 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49765&action=edit preprocessed file which reproduces the crash
[Bug c++/98282] New: Segmentation fault when compiling with optimization >= 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98282
Bug ID: 98282
Summary: Segmentation fault when compiling with optimization >=
2
Product: gcc
Version: 7.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bengilgit at gmail dot com
Target Milestone: ---
Compilation of the attached preprocessed source produces an internal compiler
error:
$ /usr/bin/g++ -O2 -c ../scalar_cast_nested.cc.preprocessed.cc
../src/arrow/compute/kernels/scalar_cast_nested.cc: In function ‘void
arrow::compute::internal::CastListExec(arrow::compute::KernelContext*, const
arrow::compute::ExecBatch&, arrow::Datum*) [with Type = arrow::ListType]’:
../src/arrow/compute/kernels/scalar_cast_nested.cc:33:6: internal compiler
error: Segmentation fault
void CastListExec(KernelContext* ctx, const ExecBatch& batch, Datum* out) {
^~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
$ /usr/bin/g++ --version
g++ (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Bisection indicates this is ultimately caused by replacing `nonstd::variant`
with an in-house implementation, change at:
https://github.com/apache/arrow/pull/8472
[Bug tree-optimization/98281] - -Wformat-truncation false positive due to excessive integer range (gcc 10.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98281 --- Comment #2 from ishikawa,chiaki --- Created attachment 49764 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49764&action=edit The patch that I had for 94021 Funny I thought this was gone for a while with gcc-9 and an earlier 10 (?) I say this because I had a patch as attached locally (which I produced since I reported bug 94021). But I could compile the source without the patch this Fall., it seems. Yeah, I took it out from my local patch queeu. Maybe something changed. Also, please notice that the first part of the patch is for the case quite similar to bug 94021 comment 4 test example, and I think that was somehow taken care of (?) Anyway, the bug(s) still persist for the static snprintf format check.
[Bug tree-optimization/98281] - -Wformat-truncation false positive due to excessive integer range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98281 --- Comment #1 from ishikawa,chiaki --- The command to compile the source file uploaded. (Place it in /tmp) cd tmp export TERM=dumb /usr/bin/gcc-10 -std=gnu99 -o /tmp/Unified_c_libical_src_libical1.o -c -I/NEW-SSD/moz-obj-dir/objdir-tb3/dist/system_wrappers -include /NEW-SSD/NREF-COMM-CENTRAL/mozilla/config/gcc_hidden.h -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -DDEBUG=1 -DHAVE_CONFIG_H -DHAVE_SNPRINTF -DMOZ_HAS_MOZGLUE -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -DSTATIC_EXPORTABLE_JS_API -I/NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/calendar/libical/src/libical -I/NEW-SSD/moz-obj-dir/objdir-tb3/comm/calendar/libical/src/libical -I/NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/calendar/libical -I/NEW-SSD/moz-obj-dir/objdir-tb3/dist/include -I/NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/nspr -I/NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/nss -fPIC -include /NEW-SSD/moz-obj-dir/objdir-tb3/mozilla-config.h -DMOZILLA_CLIENT -fno-builtin-strlen -Wl,--gdb-index -Dfdatasync=fdatasync -DDEBUG_4GB_CHECK -DUSEHELGRIND=1 -DUSEVALGRIND=1 -DDEBUG -g -gsplit-dwarf -Werror=sign-compare -Werror=unused-result -Werror=unused-variable -Werror=format -fuse-ld=gold -fno-strict-aliasing -ffunction-sections -fdata-sections -fno-math-errno -pthread -pipe -g -g -Og -fvar-tracking -gdwarf-4 -fvar-tracking-assignments -freorder-blocks -fno-omit-frame-pointer -funwind-tables -Wall -Wempty-body -Wignored-qualifiers -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wduplicated-cond -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=coverage-mismatch -Wno-error=free-nonheap-object -Wno-multistatement-macros -Wno-error=class-memaccess -Wno-error=deprecated-copy -Wformat -Wformat-overflow=2 -Werror=implicit-function-declaration -Wno-psabi -MD -MP -MF .deps/Unified_c_libical_src_libical1.o.ppUnified_c_libical_src_libical1.c We get the following error at the end, but please ignore it. Unified_c_libical_src_libical1.c: At top level: Unified_c_libical_src_libical1.c:48: fatal error: opening dependency file .deps/Unified_c_libical_src_libical1.o.pp: No such file or directory 48 | #pragma GCC visibility pop
[Bug tree-optimization/98281] New: - -Wformat-truncation false positive due to excessive integer range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98281
Bug ID: 98281
Summary: - -Wformat-truncation false positive due to excessive
integer range
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ishikawa at yk dot rim.or.jp
Target Milestone: ---
Created attachment 49763
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49763&action=edit
Code that triggered the error.
Actually there was bug 94021 but that was for 9.2.1, and this is with 10.2.0,
and the error is subtly different. So I am submitting this bug entry.
Compared with the example in bug 94021 comment 4, the bug is slightly
different.
gcc --version
gcc (Debian 10.2.0-19) 10.2.0
The source code is from mozilla's thunderbird.
The error I observed is:
In file included from Unified_c_libical_src_libical1.c:20:
/NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/calendar/libical/src/libical/icalvalue.c:
In function ‘icalvalue_utcoffset_as_ical_string_r’:
/NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/calendar/libical/src/libical/icalvalue.c:897:20:
error: ‘%02d’ directive output may be truncated writing between 2 and 6 bytes
into a region of size between 2 and 4 [-Werror=format-truncation=]
897 | snprintf(str,9,"%c%02d%02d%02d",sign,abs(h),abs(m),abs(s));
|^~~~
/NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/calendar/libical/src/libical/icalvalue.c:897:20:
note: directive argument in the range [1, 338339]
In file included from /usr/include/stdio.h:867,
from
/NEW-SSD/moz-obj-dir/objdir-tb3/dist/system_wrappers/stdio.h:3,
from
/NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/calendar/libical/src/libical/icaltimezone.c:34,
from Unified_c_libical_src_libical1.c:2:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:67:10: note:
‘__builtin___snprintf_chk’ output between 8 and 14 bytes into a destination of
size 9
67 | return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
| ^~~~
68 |__bos (__s), __fmt, __va_arg_pack ());
|~~
This does not make sense, since the value(s) ought to be constrained
to fit into the final string.
Also, I am not sure what this [1, 338339] is valid for WHICH variable.
The code snippet from the affected function: Sorry, I could no reproduce the
problem with a simplified source code. There must be an optimization issue
involved.
--- begin quote
static char* icalvalue_utcoffset_as_ical_string_r(const icalvalue* value)
{
int data,h,m,s;
char sign;
char* str;
if(!((value!=0))) { icalerror_set_errno(ICAL_BADARG_ERROR); return 0;};
str = (char*)icalmemory_new_buffer(9);
data = icalvalue_get_utcoffset(value);
if (abs(data) == data){
sign = '+';
} else {
sign = '-';
}
if (data >= 3600 * 24 || data <= - 3600 * 24) {
snprintf(str,9,"+");
return str;
}
if(data < 0)
data = - data;
h = data/3600;
m = (data - (h*3600))/ 60;
s = (data - (h*3600) - (m*60));
if (s > 0)
snprintf(str,9,"%c%02d%02d%02d",sign,abs(h),abs(m),abs(s));
else
snprintf(str,9,"%c%02d%02d",sign,abs(h),abs(m));
return str;
}
--- end quote
The intention is that the following conditions hold before snprintf is invoked.
h is in [0, 24)
m is in [0, 60)
s is in [0, 60)
I wonder where "[1, 338339]" comes from.
Yes, I know the original code does something funny like abs(data) == data,
The preprocessed source file is in the attachment.
The command script to compile the source file is in another comment.
[Bug target/97827] bootstrap error building the amdgcn-amdhsa offload compiler with LLVM 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97827 --- Comment #10 from Fangrui Song --- Note: the section key is not just (name, group name "G"). It is a quadruple: (name, group name "G", linked-to "o", unique ID) Keeping just name works for the simplest case. If GCC decides to support PR95095 -fno-unique-section-names, unique ID can be common. https://sourceware.org/bugzilla/show_bug.cgi?id=25490#c3 added the support for `.section ,unique` to GNU as.
[Bug target/97827] bootstrap error building the amdgcn-amdhsa offload compiler with LLVM 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97827 Fangrui Song changed: What|Removed |Added CC||i at maskray dot me --- Comment #9 from Fangrui Song --- I want to know whether this is really a wontfix on GCC's side. Richard Sandiford on https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559572.html "I'm not saying we should bend over backwards to support difficult quirks. But here we're talking about a choice between (a) doing something that works “everywhere” unconditionally (and keeping things simple) vs. (b) having both code that takes a shortcut and code that doesn't take a shortcut and trying to predict which one we should do." This makes a lot of sense to me. For the LLVM "fix", we had not known this PR before https://reviews.llvm.org/D92052#2452577 To me personally, I might have a different opinion if I knew this is not an entire dead end on gcc -S output.
[Bug gcov-profile/98257] Replace Donald B. Johnson's cycle enumeration with iterative loop finding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98257 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-12-14 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Thank you for the feedback. I have 2 basic questions: 1) Are you willing to provide patches that will improve the algorithm? 2) Do you see a real-world program that suffers from the currently used algorithm?
[Bug tree-optimization/80738] dead first stmt in a=0;a=b;b=0 whatever the aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80738
David Stone changed:
What|Removed |Added
CC||david at doublewise dot net
--- Comment #6 from David Stone ---
All of the standard library types in C++ have a hand-written version of
std::swap to work around the problem. Fundamental types do not need anything
set to 0 in the middle so they don't show the problem. The simplest case to
show this would probably be a struct containing a unique_ptr (although it
applies to any resource-owning type that doesn't have a swap written
specifically for it):
```
#include
#include
struct wrapper {
std::unique_ptr ptr;
};
void slow(wrapper & lhs, wrapper & rhs) {
std::swap(lhs, rhs);
}
void fast(wrapper & lhs, wrapper & rhs) {
std::swap(lhs.ptr, rhs.ptr);
}
```
At `-O3`, this generates the assembly
```
slow(wrapper&, wrapper&):
mov rax, QWORD PTR [rdi]
mov QWORD PTR [rdi], 0
mov rdx, QWORD PTR [rsi]
mov QWORD PTR [rsi], 0
mov QWORD PTR [rdi], rdx
mov rdi, QWORD PTR [rsi]
mov QWORD PTR [rsi], rax
testrdi, rdi
je .L1
mov esi, 4
jmp operator delete(void*, unsigned long)
.L1:
ret
fast(wrapper&, wrapper&):
mov rax, QWORD PTR [rdi]
mov rdx, QWORD PTR [rsi]
mov QWORD PTR [rdi], rdx
mov QWORD PTR [rsi], rax
ret
```
Where `fast` is better only because the C++ standard library maintainers
hand-wrote a faster version.
[Bug libstdc++/65118] Android target build is broken with "guard.cc:36:22: fatal error: syscall.h: No such file or directory"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65118 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-12-14 Status|UNCONFIRMED |WAITING --- Comment #2 from Jonathan Wakely --- Is this still a problem?
[Bug tree-optimization/98272] [11 Regression] ICE: during GIMPLE pass: switchlower: in decompose, at wide-int.h:984 with -O -fno-tree-forwprop by r11-5836
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98272 --- Comment #2 from Eric Botcazou --- Created attachment 49762 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49762&action=edit Tentative fix
[Bug libstdc++/93151] system_error header fails to compile with -D_XOPEN_SOURCE=600
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93151 --- Comment #5 from Jonathan Wakely --- http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2227r0.html fixed C++ to depend on a later POSIX standard which defines EOWNERDEAD and ENOTRECOVERABLE but that won't help existing system headers which don't check __cplusplus anyway.
[Bug tree-optimization/98279] ICE in apply_scale with --param=hot-bb-frequency-fraction >= 2^31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98279 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Last reconfirmed||2020-12-14 --- Comment #2 from Martin Liška --- Let me fix that.
[Bug rtl-optimization/98276] ICE in want_to_gcse_p, at gcse.c:808 with --param=gcse-cost-distance-ratio > 2^31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98276 Martin Liška changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org CC||marxin at gcc dot gnu.org Last reconfirmed||2020-12-14 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Martin Liška --- Let me fix that.
[Bug tree-optimization/98272] [11 Regression] ICE: during GIMPLE pass: switchlower: in decompose, at wide-int.h:984 with -O -fno-tree-forwprop by r11-5836
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98272 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED CC||marxin at gcc dot gnu.org Last reconfirmed||2020-12-14 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Target Milestone|--- |11.0 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- I can fix it.
[Bug rtl-optimization/98271] ICE in apply_scale, at profile-count.h:1082 with large --param=align-loop-iterations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98271 --- Comment #3 from Martin Liška --- All params we have are of int type: #ifdef GENERATOR_FILE extern int param_align_loop_iterations; #else int x_param_align_loop_iterations; #define param_align_loop_iterations global_options.x_param_align_loop_iterations
[Bug rtl-optimization/98271] ICE in apply_scale, at profile-count.h:1082 with large --param=align-loop-iterations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98271 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Last reconfirmed||2020-12-14 Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- We end up with: (gdb) p global_options.x_param_align_loop_iterations $3 = -2147483648 I'm gonna fix this, we need param overflow check.
[Bug testsuite/98280] New: [11 regression] gcc.target/powerpc/fold-vec-logical-ors-char.c fails after t11-5958 with assembler output differences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98280 Bug ID: 98280 Summary: [11 regression] gcc.target/powerpc/fold-vec-logical-ors-char.c fails after t11-5958 with assembler output differences Product: gcc Version: 11.0 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:0bd675183d94e6bca100c3aaaf87ee9676fb3c26, r11-5958 FAIL: gcc.target/powerpc/fold-vec-logical-ors-char.c scan-assembler-times mxxlnorM 2 FAIL: gcc.target/powerpc/fold-vec-logical-ors-char.c scan-assembler-times mxxlorM 6 FAIL: gcc.target/powerpc/fold-vec-logical-ors-int.c scan-assembler-times mxxlnorM 2 FAIL: gcc.target/powerpc/fold-vec-logical-ors-int.c scan-assembler-times mxxlorM 6 FAIL: gcc.target/powerpc/fold-vec-logical-ors-longlong.c scan-assembler-times mxxlnorM 6 FAIL: gcc.target/powerpc/fold-vec-logical-ors-longlong.c scan-assembler-times mxxlorM 6 FAIL: gcc.target/powerpc/fold-vec-logical-ors-short.c scan-assembler-times mxxlnorM 2 FAIL: gcc.target/powerpc/fold-vec-logical-ors-short.c scan-assembler-times mxxlorM 6 FAIL: gcc.target/powerpc/fold-vec-logical-other-char.c scan-assembler-times mxxlnandM 6 FAIL: gcc.target/powerpc/fold-vec-logical-other-int.c scan-assembler-times mxxlnandM 6 FAIL: gcc.target/powerpc/fold-vec-logical-other-longlong.c scan-assembler-times mxxlnandM 6 FAIL: gcc.target/powerpc/fold-vec-logical-other-short.c scan-assembler-times mxxlnandM 6 The differences are all similar *** fold-vec-logical-ors-char.r11-5957.sMon Dec 14 10:08:59 2020 --- fold-vec-logical-ors-char.r11-5958.sMon Dec 14 10:08:35 2020 *** *** 298,306 .L.test6_nor: .LFB13: .cfi_startproc ! xxlnor 34,34,35 li 9,0 lxvw4x 32,0,9 vaddubm 2,2,0 stxvw4x 34,0,9 blr --- 298,308 .L.test6_nor: .LFB13: .cfi_startproc ! xxlor 34,34,35 li 9,0 lxvw4x 32,0,9 + vsububm 2,0,2 + vspltisw 0,-1 vaddubm 2,2,0 stxvw4x 34,0,9 *** fold-vec-logical-ors-int.r11-5957.s Mon Dec 14 10:15:44 2020 --- fold-vec-logical-ors-int.r11-5958.s Mon Dec 14 10:15:25 2020 *** *** 298,306 .L.test6_nor: .LFB13: .cfi_startproc ! xxlnor 34,34,35 li 9,0 lxvw4x 32,0,9 vadduwm 2,2,0 stxvw4x 34,0,9 blr --- 298,308 .L.test6_nor: .LFB13: .cfi_startproc ! xxlor 34,34,35 li 9,0 lxvw4x 32,0,9 + vsubuwm 2,0,2 + vspltisw 0,-1 vadduwm 2,2,0 stxvw4x 34,0,9 blr
[Bug lto/98275] -flto=auto fails if nthreads_var is zero, must not pass -j0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98275
Martin Liška changed:
What|Removed |Added
Target Milestone|--- |11.0
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2020-12-14
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
--- Comment #1 from Martin Liška ---
Thank you for the bug report.
Can you please test the following patch:
diff --git a/gcc/lto-wrapper.c b/gcc/lto-wrapper.c
index 68ccb156521..da1305c1696 100644
--- a/gcc/lto-wrapper.c
+++ b/gcc/lto-wrapper.c
@@ -1780,6 +1780,8 @@ cont1:
{
char buf[256];
init_num_threads ();
+ if (nthreads_var == 0)
+ nthreads_var = 1;
if (verbose)
fprintf (stderr, "LTO parallelism level set to %ld\n",
nthreads_var);
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 98264, which changed state. Bug 98264 Summary: [11 Regression] ice during linear_loads_p since r11-5969-g3ed472af6bc9f83b https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98264 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug middle-end/98264] [11 Regression] ice during linear_loads_p since r11-5969-g3ed472af6bc9f83b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98264 Tamar Christina changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Tamar Christina --- This should be fixed now.
[Bug middle-end/98264] [11 Regression] ice during linear_loads_p since r11-5969-g3ed472af6bc9f83b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98264 --- Comment #10 from CVS Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:159b0bd9ce263dfb791eff5133b0ca0207201c84 commit r11-5993-g159b0bd9ce263dfb791eff5133b0ca0207201c84 Author: Tamar Christina Date: Mon Dec 14 15:20:05 2020 + middle-end: Exclude TOP permute from blend considerations Similarly to UNKNOWN permutes, TOP needs to be excluded from being considered for blends because it produces no permute to check. gcc/ChangeLog: PR middle-end/98264 * tree-vect-slp-patterns.c (linear_loads_p): Exclude TOP permute. gcc/testsuite/ChangeLog: PR middle-end/98264 * gcc.target/i386/pr98264.c: New test.
[Bug tree-optimization/98279] ICE in apply_scale with --param=hot-bb-frequency-fraction >= 2^31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98279
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
--- Comment #1 from ktkachov at gcc dot gnu.org ---
(In reply to Alex Coplan from comment #0)
> The following fails:
>
> $ cat test.c
> int a() {}
> $ aarch64-elf-gcc test.c -c -O --param=hot-bb-frequency-fraction=2147483648
> during GIMPLE pass: cdce
> test.c: In function 'a':
> test.c:1:5: internal compiler error: in apply_scale, at profile-count.h:1082
> 1 | int a() {}
> | ^
> 0xcf2c8d profile_count::apply_scale(long, long) const
> /home/alecop01/toolchain/src/gcc/gcc/profile-count.h:1082
> 0xce6ed7 maybe_hot_count_p(function*, profile_count)
> /home/alecop01/toolchain/src/gcc/gcc/predict.c:175
> 0xce7459 maybe_hot_bb_p(function*, basic_block_def const*)
> /home/alecop01/toolchain/src/gcc/gcc/predict.c:193
> 0xce76c1 optimize_bb_for_size_p(basic_block_def const*)
> /home/alecop01/toolchain/src/gcc/gcc/predict.c:301
> 0xe11269 execute
> /home/alecop01/toolchain/src/gcc/gcc/tree-call-cdce.c:1195
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See
[Bug tree-optimization/98279] New: ICE in apply_scale with --param=hot-bb-frequency-fraction >= 2^31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98279
Bug ID: 98279
Summary: ICE in apply_scale with
--param=hot-bb-frequency-fraction >= 2^31
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
The following fails:
$ cat test.c
int a() {}
$ aarch64-elf-gcc test.c -c -O --param=hot-bb-frequency-fraction=2147483648
during GIMPLE pass: cdce
test.c: In function 'a':
test.c:1:5: internal compiler error: in apply_scale, at profile-count.h:1082
1 | int a() {}
| ^
0xcf2c8d profile_count::apply_scale(long, long) const
/home/alecop01/toolchain/src/gcc/gcc/profile-count.h:1082
0xce6ed7 maybe_hot_count_p(function*, profile_count)
/home/alecop01/toolchain/src/gcc/gcc/predict.c:175
0xce7459 maybe_hot_bb_p(function*, basic_block_def const*)
/home/alecop01/toolchain/src/gcc/gcc/predict.c:193
0xce76c1 optimize_bb_for_size_p(basic_block_def const*)
/home/alecop01/toolchain/src/gcc/gcc/predict.c:301
0xe11269 execute
/home/alecop01/toolchain/src/gcc/gcc/tree-call-cdce.c:1195
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/98278] New: switch optimisation and -fstrict-enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98278
Bug ID: 98278
Summary: switch optimisation and -fstrict-enums
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
Created attachment 49761
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49761&action=edit
input file
The attached file, compiled with -O2 -fstrict-enums, only for `foobar` all
branches are transformed to a jump table.
If I did not made any mistake all the function should be able to be transformed
should produce the same assembly.
Changing the definition of the enum to
enum e { A = 1, B, C, D}; will produce worse code. Only one jumtable is
used/created.
enum e { A = 2, B = 4, C = 6, D = 8 }; (or any other sequence) no jump table is
created.
[Bug tree-optimization/96239] Failure to recognize __builtin_bswap16 pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96239
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Doing it in the vectorizer wouldn't optimize it when users write it by hand,
like:
typedef char V __attribute__((vector_size (2)));
typedef char W __attribute__((vector_size (8)));
V
foo (unsigned short x)
{
return (V) { x >> 8, x };
}
W
bar (unsigned long long x)
{
return (W) { x >> 56, x >> 48, x >> 40, x >> 32, x >> 24, x >> 16, x >> 8, x
};
}
and forwprop doesn't have the infrastructure needed for this.
Wouldn't the bswap pass be the right spot to handle this?
[Bug d/98277] New: d: ICE in gimplify_expr, at gimplify.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98277
Bug ID: 98277
Summary: d: ICE in gimplify_expr, at gimplify.c
Product: gcc
Version: 9.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
This happens when using an enum member in a ternary condition for a function
that returns by reference.
---
enum Side
{
left
}
int left;
int right;
ref int get(Side side)
{
return side == Side.left ? left : right;
}
---
[Bug tree-optimization/96245] Failure to optimize arithmetic pattern in switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96245 --- Comment #10 from Jakub Jelinek --- That is just one specific special case, it can be anything else, like case 7: p[14] = 1; break; case 8: p[13] = 1; break; case 9: p[12] = 1; break; case 10: p[11] = 1; break; etc. I think there are advantages of doing this in switchconv, namely that it would be done only if the switchconv pass finds out it would be beneficial, but there can be advantages doing that in tail-merging too, mainly for -Os or proven cold code it is often but not always to optimize this (not only if either the code is very small or if between pre and switchconv we can simplify it if it is constant).
[Bug c/47781] warnings from custom printf format specifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781 --- Comment #24 from Tom Tromey --- (In reply to David Crocker from comment #23) > I need this feature too. Instead of waiting several more years for an > all-singing all-dancing solution, PLEASE can we have a simple solution that > allows me to use a custom format specifier and skips a single argument for > that specifier. I believe this would cover the vast majority of uses custom > format specifiers. My particular use case is that my application generates a > lot of JSON strings, so in my printf replacement I want to implement a > specifier similar to %s that performs JSON escaping on characters in the > string. As a workaround, see the kernel doc linked earlier in this bug. gdb uses this hack as well -- e.g., it uses "%ps" in its formatter to mean a styled string, passed as a pointer to get past gcc's checking.
[Bug rtl-optimization/98276] New: ICE in want_to_gcse_p, at gcse.c:808 with --param=gcse-cost-distance-ratio > 2^31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98276
Bug ID: 98276
Summary: ICE in want_to_gcse_p, at gcse.c:808 with
--param=gcse-cost-distance-ratio > 2^31
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
$ cat test.c
int a;
int c(void);
int b() { a && c(); }
$ aarch64-elf-gcc -c -Os --param=gcse-cost-distance-ratio=2147483648 test.c
during RTL pass: hoist
test.c: In function 'b':
test.c:3:21: internal compiler error: in want_to_gcse_p, at gcse.c:808
3 | int b() { a && c(); }
| ^
0xa4f8bb want_to_gcse_p
/home/alecop01/toolchain/src/gcc/gcc/gcse.c:808
0xa4f9f7 hash_scan_set
/home/alecop01/toolchain/src/gcc/gcc/gcse.c:1272
0xa4fe88 hash_scan_insn
/home/alecop01/toolchain/src/gcc/gcc/gcse.c:1368
0xa4fe88 compute_hash_table_work
/home/alecop01/toolchain/src/gcc/gcc/gcse.c:1551
0xa4fe88 compute_hash_table
/home/alecop01/toolchain/src/gcc/gcc/gcse.c:1597
0xa50481 one_code_hoisting_pass
/home/alecop01/toolchain/src/gcc/gcc/gcse.c:3549
0xa50481 execute_rtl_hoist
/home/alecop01/toolchain/src/gcc/gcc/gcse.c:4043
0xa50481 execute
/home/alecop01/toolchain/src/gcc/gcc/gcse.c:4124
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug lto/98275] New: -flto=auto fails if nthreads_var is zero, must not pass -j0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98275
Bug ID: 98275
Summary: -flto=auto fails if nthreads_var is zero, must not
pass -j0
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: p...@gcc-bugzilla.mail.kapsi.fi
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Host: mingw64
Hi.
When using `-flto=auto' if the number of threads is not detected, i.e.
`nthreads_var' equals to zero, lto-wrapper must not pass -j0 to GNU make as -j
expects a positive, non-zero integer (if any given).
>From GNU make manual: ``If the ‘-j’ option is followed by an integer, this is
the number of recipes to execute at once; this is called the number of job
slots. If there is nothing looking like an integer after the ‘-j’ option, there
is no limit on the number of job slots.''.
gcc/lto-wrapper.c:
2001 snprintf (jobs, 31, "-j%ld",
2002 auto_parallel ? nthreads_var : parallel);
$ make -j0
make: the '-j' option requires a positive integer argument
Tried GNU make 4.2.1 (2016 vintage) and 4.2.93 (2020). For the latest trunk
argument parsing happens at src/main.c around line 2961 [1]; It basically does
``int i = atoi(arg); if (i < 1 || not-all-chars-are-digits) { handle-bad-arg
}''.
[1] https://git.savannah.gnu.org/cgit/make.git/tree/src/main.c#n2961
[Bug rtl-optimization/98271] ICE in apply_scale, at profile-count.h:1082 with large --param=align-loop-iterations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98271 --- Comment #1 from Alex Coplan --- On further investigation, it seems we ICE when align-loop-iterations is 2^31 and above (i.e. if it's negative, treated as a 32-bit signed integer).
[Bug tree-optimization/96245] Failure to optimize arithmetic pattern in switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96245
--- Comment #9 from rguenther at suse dot de ---
On December 14, 2020 12:19:32 PM GMT+01:00, "jakub at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96245
>
>--- Comment #7 from Jakub Jelinek ---
>Looking at godbolt and LLVM release notes, this optimization appeared
>in LLVM 9
>and looks to be a switch optimization:
>
>LLVM can now sink similar instructions to a common successor block also
>when
>the instructions have no uses, such as calls to void functions. This
>allows
>code such as
>
>void g(int);
>enum e { A, B, C, D };
>void f(e x, int y, int z) {
> switch(x) {
>case A: g(6); break;
>case B: g(3); break;
>case C: g(9); break;
>case D: g(2); break;
> }
>}
>
>to be optimized to a single call to g, with the argument loaded from a
>lookup
>table.
>I bet it is https://reviews.llvm.org/D59936
>
>We don't optimize even:
>void
>foo (int *p, int x)
>{
> switch (x)
>{
>case 7: *p = 14; break;
>case 8: *p = 15; break;
>case 9: *p = 16; break;
>case 10: *p = 17; break;
>case 11: *p = 18; break;
>case 12: *p = 19; break;
>default: return;
>}
>}
Store commoning in the sink pass should do this. But it would need to create a
forwarder because of the default case.
That's a missed piece there.
>but do optimize if one performs the switch parametrized tail merging
>manually:
>void
>bar (int *p, int x)
>{
> int y;
> switch (x)
>{
>case 7: y = 14; break;
>case 8: y = 15; break;
>case 9: y = 16; break;
>case 10: y = 17; break;
>case 11: y = 18; break;
>case 12: y = 19; break;
>default: return;
>}
> *p = y;
>}
>
>So, do you prefer to do this in tree-ssa-tail-merge.c (for blocks
>starting with
>switches) or in tree-switch-conversion.c, and should we handle both the
>case
>where the constant(s) are linear vs. the switch expression, or also any
>other
>(let the switchconv pass then create the arrays)?
[Bug target/98274] -march=x86-64-v[234] incompatible with target attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98274 --- Comment #1 from Jakub Jelinek --- Created attachment 49760 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49760&action=edit gcc11-pr98274.patch Untested fix.
[Bug target/98274] -march=x86-64-v[234] incompatible with target attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98274 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-12-14 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
[Bug target/98274] New: -march=x86-64-v[234] incompatible with target attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98274
Bug ID: 98274
Summary: -march=x86-64-v[234] incompatible with target
attribute
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
void __attribute__((target ("avx")))
foo (void)
{
}
fails to compile with -march=x86-64-v2 :
~/src/gcc/obj04/gcc/xgcc -B ~/src/gcc/obj04/gcc/ -S -O2 qauquu.c
-march=x86-64-v2
qauquu.c:3:1: error: bad value (‘x86-64-v2’) for ‘target("tune=")’ attribute
3 | {
| ^
qauquu.c:3:1: note: valid arguments to ‘target("tune=")’ attribute are: nocona
core2 nehalem corei7 westmere sandybridge corei7-avx ivybridge core-avx-i
haswell core-avx2 broadwell skylake skylake-avx512 cannonlake icelake-client
icelake-server cascadelake tigerlake cooperlake sapphirerapids alderlake
bonnell atom silvermont slm goldmont goldmont-plus tremont knl knm intel x86-64
eden-x2 nano nano-1000 nano-2000 nano-3000 nano-x2 eden-x4 nano-x4 k8 k8-sse3
opteron opteron-sse3 athlon64 athlon64-sse3 athlon-fx amdfam10 barcelona bdver1
bdver2 bdver3 bdver4 znver1 znver2 znver3 btver1 btver2 generic native; did you
mean ‘x86-64’?
[Bug c/98217] Prefer a warning for when VLAs declared on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98217 --- Comment #10 from Martin Uecker --- (for C++ compatibility, there is: -Wc++XX-compat ) So since Xmas is coming: - I would also like an option to allocate VLAs of unbounded size larger than X on the heap. - Better code generation for VLAs. Maybe VLAs of small bounded size could be automatically transformed into regular arrays for the purpose of code generation. IIRC, Linux kernel replaced some VLAs on the stack with fixed-sized buffers on the stack. But this increases stack size and reduces type safety.
[Bug c/98217] Prefer a warning for when VLAs declared on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98217 --- Comment #9 from David Svoboda --- The more I think about it, the more I want to see two -W warnings...one to flag VLA declarations on the stack, and another to see *any* use of VLAs, even if in something as harmless as a conformant array. The latter flag is simply for platforms (like C++) that does not support VLAs. I am less concerned about codebases that have a "no VLAs" rule. They have the same problem we do of understanding what chat constitutes a VLA, and they would benefit the most from well-defined, precise -W warnings.
[Bug fortran/96986] [8/9/10/11 Regression] Explicit interface required: volatile argument for ENTRY subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96986 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2020-12-14 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed, but is the error message an error?
[Bug gcov-profile/98273] GCOV intermediate format is wrong when lambda functions (or nested functions) are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98273 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-12-14 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- I've got a patch for it.
[Bug tree-optimization/96094] Failure to optimize bool division
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96094 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 49759 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49759&action=edit gcc11-pr96094.patch Untested fix.
[Bug gcov-profile/98273] New: GCOV intermediate format is wrong when lambda functions (or nested functions) are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98273
Bug ID: 98273
Summary: GCOV intermediate format is wrong when lambda
functions (or nested functions) are used
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Consider the following example:
$ bat gcov-lambda.C
───┬──
│ File: gcov-lambda.C
───┼──
1 │ int main()
2 │ {
3 │ int i = 42;
4 │ {
5 │ auto f = [](){};
6 │ f();
7 │ }
8 │ ++i;
9 │ ++i;
10 │ ++i;
11 │ return 45 - i;
12 │ }
───┴──
we wrongly generate:
"lines": [
{
...
{
"branches": [],
"count": 1,
"function_name": "_ZZ4mainENKUlvE_clEv",
"line_number": 6,
"unexecuted_block": false
},
{
"branches": [],
"count": 1,
"function_name": "_ZZ4mainENKUlvE_clEv",
"line_number": 8,
"unexecuted_block": false
},
As seen line #8 is wrongly assigned to the lambda function, instead of the main
function.
[Bug tree-optimization/98272] New: [11 Regression] ICE: during GIMPLE pass: switchlower: in decompose, at wide-int.h:984 with -O -fno-tree-forwprop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98272 Bug ID: 98272 Summary: [11 Regression] ICE: during GIMPLE pass: switchlower: in decompose, at wide-int.h:984 with -O -fno-tree-forwprop Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Created attachment 49758 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49758&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O -fno-tree-forwprop testcase.c during GIMPLE pass: switchlower testcase.c: In function 'foo': testcase.c:4:1: internal compiler error: in decompose, at wide-int.h:984 4 | foo (unsigned char uc) | ^~~ 0x61a4c0 wi::int_traits > >::decompose(long*, unsigned int, generic_wide_int > const&) /repo/gcc-trunk/gcc/wide-int.h:984 0xac2400 wi::int_traits >::decompose(long*, unsigned int, generic_wide_int const&) /repo/gcc-trunk/gcc/wide-int.h:1933 0xac2400 wide_int_ref_storage::wide_int_ref_storage >(generic_wide_int const&, unsigned int) /repo/gcc-trunk/gcc/wide-int.h:1034 0xac2400 generic_wide_int >::generic_wide_int >(generic_wide_int const&, unsigned int) /repo/gcc-trunk/gcc/wide-int.h:790 0xac2400 bool wi::ltu_p, generic_wide_int >(generic_wide_int const&, generic_wide_int const&) /repo/gcc-trunk/gcc/wide-int.h:1937 0x10aa543 bool wi::lt_p, generic_wide_int >(generic_wide_int const&, generic_wide_int const&, signop) /repo/gcc-trunk/gcc/wide-int.h:1963 0x10aa543 tree_switch_conversion::bit_test_cluster::emit(tree_node*, tree_node*, tree_node*, basic_block_def*) /repo/gcc-trunk/gcc/tree-switch-conversion.c:1562 0x10aac3b tree_switch_conversion::switch_decision_tree::try_switch_expansion(vec&) /repo/gcc-trunk/gcc/tree-switch-conversion.c:1893 0x10ab413 tree_switch_conversion::switch_decision_tree::analyze_switch_statement() /repo/gcc-trunk/gcc/tree-switch-conversion.c:1823 0x10ac217 execute /repo/gcc-trunk/gcc/tree-switch-conversion.c:2570 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. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r11-5984-20201214092247-gcf7efe2d36f-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r11-5984-20201214092247-gcf7efe2d36f-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.0.0 20201214 (experimental) (GCC)
[Bug rtl-optimization/98271] New: ICE in apply_scale, at profile-count.h:1082 with large --param=align-loop-iterations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98271
Bug ID: 98271
Summary: ICE in apply_scale, at profile-count.h:1082 with large
--param=align-loop-iterations
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
The following fails:
$ cat test.c
void a() {
for (;;)
;
}
$ aarch64-elf-gcc -c -O --param=align-loop-iterations=1197120096074465280
test.c
during RTL pass: alignments
test.c: In function 'a':
test.c:4:1: internal compiler error: in apply_scale, at profile-count.h:1082
4 | }
| ^
0x9e0637 profile_count::apply_scale(long, long) const
/home/alecop01/toolchain/src/gcc/gcc/profile-count.h:1082
0x9e0637 compute_alignments()
/home/alecop01/toolchain/src/gcc/gcc/final.c:746
0x9e086e execute
/home/alecop01/toolchain/src/gcc/gcc/final.c:825
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/96245] Failure to optimize arithmetic pattern in switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96245
Jakub Jelinek changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #8 from Jakub Jelinek ---
Effectively it would be the inverse of jump threading optimization, though I
think we don't do it for switches, turning say:
void
foo (int *p, int x)
{
switch (x)
{
case 7:
case 8:
case 9:
case 10:
case 11:
case 12: *p = 12 + x; break;
default: return;
}
}
into the above foo.
[Bug tree-optimization/96245] Failure to optimize arithmetic pattern in switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96245
--- Comment #7 from Jakub Jelinek ---
Looking at godbolt and LLVM release notes, this optimization appeared in LLVM 9
and looks to be a switch optimization:
LLVM can now sink similar instructions to a common successor block also when
the instructions have no uses, such as calls to void functions. This allows
code such as
void g(int);
enum e { A, B, C, D };
void f(e x, int y, int z) {
switch(x) {
case A: g(6); break;
case B: g(3); break;
case C: g(9); break;
case D: g(2); break;
}
}
to be optimized to a single call to g, with the argument loaded from a lookup
table.
I bet it is https://reviews.llvm.org/D59936
We don't optimize even:
void
foo (int *p, int x)
{
switch (x)
{
case 7: *p = 14; break;
case 8: *p = 15; break;
case 9: *p = 16; break;
case 10: *p = 17; break;
case 11: *p = 18; break;
case 12: *p = 19; break;
default: return;
}
}
but do optimize if one performs the switch parametrized tail merging manually:
void
bar (int *p, int x)
{
int y;
switch (x)
{
case 7: y = 14; break;
case 8: y = 15; break;
case 9: y = 16; break;
case 10: y = 17; break;
case 11: y = 18; break;
case 12: y = 19; break;
default: return;
}
*p = y;
}
So, do you prefer to do this in tree-ssa-tail-merge.c (for blocks starting with
switches) or in tree-switch-conversion.c, and should we handle both the case
where the constant(s) are linear vs. the switch expression, or also any other
(let the switchconv pass then create the arrays)?
[Bug tree-optimization/96245] Failure to optimize arithmetic pattern in switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96245 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||vries at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- I think it isn't really a too special case, of course one shouldn't take it literally and look for a particular call etc. But, generally try to see if all the switch cases are the same except some constant or two (same e.g. in the ICF sense) and if that constant or two is linear vs. the corresponding case. It can be done either in switchconv, or could be perhaps some kind of GIMPLE_SWITCH aware parametrized tail merging/cross jumping. As it would (or could) turn constant expressions into non-constant, I guess we'd need to take some conservative approach with __builtin_constant_p, punt if there is a __builtin_constant_p in the block, either altogether, or if it is among (recursively) the immediate uses of the stmt where the constant(s) appear.
[Bug target/98259] [11 Regression] error: 'void verify_insn_chain()' causes a section type conflict with 'void init_rtl_bb_info(basic_block)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98259 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #2 from ktkachov at gcc dot gnu.org --- May be a dup of PR98146?
[Bug target/98259] [11 Regression] error: 'void verify_insn_chain()' causes a section type conflict with 'void init_rtl_bb_info(basic_block)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98259 --- Comment #1 from Matthias Klose --- a normal bootstrap works
[Bug target/97417] RISC-V Unnecessary andi instruction when loading volatile bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417 --- Comment #48 from Levy --- Created attachment 49757 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49757&action=edit Initial V1 patch on combine.c Three patches together: = Summary of gcc testsuite = | # of unexpected case / # of unique unexpected case | gcc | g++ | gfortran | rv64imafdc/ lp64d/ medlow |0 / 0 |0 / 0 | - | I'll merge all 3 patches together and fix all the debug/coding style/efficiency /whatever problem with explanations later this week. Looks likes it's fixed from my side.
[Bug middle-end/19987] [meta-bug] fold missing optimizations in general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987 Bug 19987 depends on bug 96272, which changed state. Bug 96272 Summary: Failure to optimize overflow check https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96272 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/96272] Failure to optimize overflow check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96272 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Jakub Jelinek --- Fixed now.
[Bug target/98147] [11 Regression] ICE in emit_library_call_value_1, at calls.c:5296 since r11-5725-g442b6fb7c09a39577261de90413cc4db366f1c5f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98147 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug middle-end/98183] [8/9/10 Regression] ICE in expand_gimple_stmt_1, at cfgexpand.c:3972
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98183 Jakub Jelinek changed: What|Removed |Added Summary|[8/9/10/11 Regression] ICE |[8/9/10 Regression] ICE in |in expand_gimple_stmt_1, at |expand_gimple_stmt_1, at |cfgexpand.c:3972|cfgexpand.c:3972 --- Comment #8 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug sanitizer/98204] ICE in pointer_diff, at c/c-typeck.c:3954 since r8-5108-g05abad4cca62d372
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98204 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Martin Liška --- Fixed on the master, not planning to backport.
[Bug sanitizer/98204] ICE in pointer_diff, at c/c-typeck.c:3954 since r8-5108-g05abad4cca62d372
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98204 --- Comment #2 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:ab28eac607637a641fbec27c5f6bbe9b6197c80f commit r11-5985-gab28eac607637a641fbec27c5f6bbe9b6197c80f Author: Martin Liska Date: Wed Dec 9 16:21:18 2020 +0100 sanitizer: do not ICE for pointer cmp/sub gcc/c/ChangeLog: PR sanitizer/98204 * c-typeck.c (pointer_diff): Do not emit a top-level sanitization. (build_binary_op): Likewise. gcc/testsuite/ChangeLog: PR sanitizer/98204 * c-c++-common/asan/pr98204.c: New test.
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 --- Comment #5 from Martin Liška --- I can confirm that as well with --enable-checking=yes.
[Bug tree-optimization/98270] [11 Regression] UBSAN: /gcc/tree-vect-slp.c:2396:16: runtime error: load of value 112, which is not a valid value for type 'bool' since r11-5928-gfc7b4248172561a9ee310e2d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98270 Martin Liška changed: What|Removed |Added Target Milestone|--- |11.0 Ever confirmed|0 |1 Blocks||63426 Known to work||10.2.0 Last reconfirmed||2020-12-14 Known to fail||11.0 Status|UNCONFIRMED |NEW Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 [Bug 63426] [meta-bug] Issues found with -fsanitize=undefined
[Bug tree-optimization/98270] New: [11 Regression] UBSAN: /gcc/tree-vect-slp.c:2396:16: runtime error: load of value 112, which is not a valid value for type 'bool' since r11-5928-gfc7b4248172561a9ee3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98270 Bug ID: 98270 Summary: [11 Regression] UBSAN: /gcc/tree-vect-slp.c:2396:16: runtime error: load of value 112, which is not a valid value for type 'bool' since r11-5928-gfc7b4248172561a9ee310e2d43d8a485a5c9e108 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Since the revision I see for UBSAN enabled compiler: $ ./gcc/xgcc -B gcc /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/testsuite/gcc.dg/torture/pr98235.c -O3 -c -fallow-store-data-races /home/marxin/Programming/gcc/gcc/tree-vect-slp.c:2396:16: runtime error: load of value 112, which is not a valid value for type 'bool' #0 0x2e53ba8 in vect_build_slp_instance /home/marxin/Programming/gcc/gcc/tree-vect-slp.c:2396 #1 0x2e55120 in vect_analyze_slp_instance /home/marxin/Programming/gcc/gcc/tree-vect-slp.c:2565 #2 0x2e553ce in vect_analyze_slp(vec_info*, unsigned int) /home/marxin/Programming/gcc/gcc/tree-vect-slp.c:2596 #3 0x2e649ce in vect_slp_analyze_bb_1 /home/marxin/Programming/gcc/gcc/tree-vect-slp.c:4409 #4 0x2e6572a in vect_slp_region /home/marxin/Programming/gcc/gcc/tree-vect-slp.c:4521 #5 0x2e67593 in vect_slp_bbs /home/marxin/Programming/gcc/gcc/tree-vect-slp.c:4669 #6 0x2e67f29 in vect_slp_function(function*) /home/marxin/Programming/gcc/gcc/tree-vect-slp.c:4755 #7 0x2ea0219 in execute /home/marxin/Programming/gcc/gcc/tree-vectorizer.c:1436 #8 0x1fe199b in execute_one_pass(opt_pass*) /home/marxin/Programming/gcc/gcc/passes.c:2567 #9 0x1fe2323 in execute_pass_list_1 /home/marxin/Programming/gcc/gcc/passes.c:2656 #10 0x1fe23d8 in execute_pass_list_1 /home/marxin/Programming/gcc/gcc/passes.c:2657 #11 0x1fe23d8 in execute_pass_list_1 /home/marxin/Programming/gcc/gcc/passes.c:2657 #12 0x1fe2476 in execute_pass_list(function*, opt_pass*) /home/marxin/Programming/gcc/gcc/passes.c:2667 #13 0x10bc8c5 in cgraph_node::expand() /home/marxin/Programming/gcc/gcc/cgraphunit.c:1829 #14 0x10be21d in expand_all_functions /home/marxin/Programming/gcc/gcc/cgraphunit.c:1997 #15 0x10c0342 in symbol_table::compile() /home/marxin/Programming/gcc/gcc/cgraphunit.c:2361 #16 0x10c0cce in symbol_table::finalize_compilation_unit() /home/marxin/Programming/gcc/gcc/cgraphunit.c:2542 #17 0x24682ca in compile_file /home/marxin/Programming/gcc/gcc/toplev.c:482 #18 0x2470b0d in do_compile /home/marxin/Programming/gcc/gcc/toplev.c:2193 #19 0x2471110 in toplev::main(int, char**) /home/marxin/Programming/gcc/gcc/toplev.c:2332 #20 0x508734c in main /home/marxin/Programming/gcc/gcc/main.c:39 #21 0x76d2a151 in __libc_start_main (/lib64/libc.so.6+0x28151) #22 0x9e49fd in _start (/home/marxin/Programming/gcc/objdir/gcc/cc1+0x9e49fd)
[Bug tree-optimization/98254] Failure to optimize simple pattern for __builtin_convertvector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98254
--- Comment #6 from Jakub Jelinek ---
So, we have simplify_vector_constructor, but that handles only extractions from
some other vector, not reads from memory.
E.g. on -mavx2 -O2 -mtune=intel:
typedef int __attribute__((vector_size(32))) V;
typedef short __attribute__((vector_size(16))) W;
V
foo (short *a)
{
return (V){a[0], a[1], a[2], a[3], a[4], a[5], a[6], a[7]};
}
V
bar (int *a)
{
return (V){a[0], a[1], a[2], a[3], a[4], a[5], a[6], a[7]};
}
V
baz (short *b)
{
W a = *(W *)b;
return (V){a[0], a[1], a[2], a[3], a[4], a[5], a[6], a[7]};
}
V
qux (short *b)
{
W a = *(W *)b;
return __builtin_convertvector (a, V);
}
it triggers on baz, but emits worse code than qux, bar is after forwprop1 and
dce:
W a;
vector(8) short int _1;
vector(16) short int _20;
V _21;
:
_1 = MEM[(W *)b_19(D)];
_20 = BIT_INSERT_EXPR <{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
_1, 0>;
_21 = [vec_unpack_lo_expr] _20;
return _21;
and we don't really emit the code we want for the BIT_INSERT_EXPR.
I guess it might be better to canonicalize on .VEC_CONVERT for this.
And then for the memory reads, see if the target supports unaligned vector
loads and in that case also support MEM_REFs.
[Bug middle-end/98264] [11 Regression] ice during linear_loads_p since r11-5969-g3ed472af6bc9f83b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98264 Martin Liška changed: What|Removed |Added Blocks||26163 --- Comment #9 from Martin Liška --- Apparently, it's blocking couple of SPEC benchmarks: -Ofast -march=znver2 -g -flto=128: warning: 416.gamess(peak; CE) benchmark build failed! warning: 465.tonto(peak; CE) benchmark build failed! warning: 483.xalancbmk(peak; CE) benchmark build failed! Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug c/98267] internal compiler error: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98267 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-12-14 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1
[Bug middle-end/98264] [11 Regression] ice during linear_loads_p since r11-5969-g3ed472af6bc9f83b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98264 Martin Liška changed: What|Removed |Added Priority|P3 |P1 Summary|[11 Regression] ice during |[11 Regression] ice during |linear_loads_p |linear_loads_p since ||r11-5969-g3ed472af6bc9f83b Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #8 from Martin Liška --- Started with r11-5969-g3ed472af6bc9f83b, it fails due to a Invalid read: $ valgrind --trace-children=yes gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/avx-vaddsubpd-1.c -c -c -march=bdver2 -O3 -c ... ==15595== Invalid read of size 4 ==15595==at 0x109B3DB: operator[] (vec.h:890) ==15595==by 0x109B3DB: operator[] (vec.h:1461) ==15595==by 0x109B3DB: linear_loads_p(hash_map<_slp_tree*, std::pair<_complex_perm_kinds, vec >, simple_hashmap_traits, std::pair<_complex_perm_kinds, vec > > >*, _slp_tree*) (tree-vect-slp-patterns.c:255) ==15595==by 0x109B63A: complex_add_pattern::matches(_complex_operation, hash_map<_slp_tree*, std::pair<_complex_perm_kinds, vec >, simple_hashmap_traits, std::pair<_complex_perm_kinds, vec > > >*, vec<_slp_tree*, va_heap, vl_ptr>*) (tree-vect-slp-patterns.c:678) ==15595==by 0x109B6C9: complex_add_pattern::recognize(hash_map<_slp_tree*, std::pair<_complex_perm_kinds, vec >, simple_hashmap_traits, std::pair<_complex_perm_kinds, vec > > >*, _slp_tree**) (tree-vect-slp-patterns.c:697) ==15595==by 0x108FEEC: vect_match_slp_patterns_2(_slp_tree**, vec_info*, hash_map<_slp_tree*, std::pair<_complex_perm_kinds, vec >, simple_hashmap_traits, std::pair<_complex_perm_kinds, vec > > >*, hash_set<_slp_tree*, false, default_hash_traits<_slp_tree*> >*) (tree-vect-slp.c:2257) ==15595==by 0x108FEB1: vect_match_slp_patterns_2(_slp_tree**, vec_info*, hash_map<_slp_tree*, std::pair<_complex_perm_kinds, vec >, simple_hashmap_traits, std::pair<_complex_perm_kinds, vec > > >*, hash_set<_slp_tree*, false, default_hash_traits<_slp_tree*> >*) (tree-vect-slp.c:2252) ==15595==by 0x108FEB1: vect_match_slp_patterns_2(_slp_tree**, vec_info*, hash_map<_slp_tree*, std::pair<_complex_perm_kinds, vec >, simple_hashmap_traits, std::pair<_complex_perm_kinds, vec > > >*, hash_set<_slp_tree*, false, default_hash_traits<_slp_tree*> >*) (tree-vect-slp.c:2252) ==15595==by 0x1090277: vect_match_slp_patterns (tree-vect-slp.c:2290) ==15595==by 0x1090277: vect_analyze_slp(vec_info*, unsigned int) (tree-vect-slp.c:2743) ==15595==by 0x10974B2: vect_slp_analyze_bb_1 (tree-vect-slp.c:4507) ==15595==by 0x10974B2: vect_slp_region (tree-vect-slp.c:4619) ==15595==by 0x10974B2: vect_slp_bbs(vec) (tree-vect-slp.c:4767) ==15595==by 0x1098F54: vect_slp_function(function*) (tree-vect-slp.c:4853) ==15595==by 0x109C362: (anonymous namespace)::pass_slp_vectorize::execute(function*) (tree-vectorizer.c:1449) ==15595==by 0xD1F357: execute_one_pass(opt_pass*) (passes.c:2567) ==15595==by 0xD1FCFF: execute_pass_list_1(opt_pass*) (passes.c:2656) ==15595== Address 0x4 is not stack'd, malloc'd or (recently) free'd ==15595== during GIMPLE pass: slp In file included from /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/sse3-addsubpd.c:13, from /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/avx-vaddsubpd-1.c:8: /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/avx-check.h: In function ‘do_test’: /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/avx-check.h:10:1: internal compiler error: Segmentation fault 10 | do_test (void) | ^~~ 0x4fff151 __libc_start_main ???:0
[Bug target/97251] [10 Regression] arm: ICEs compiling pure-code/no-literal-pool.c with integer MVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97251 Przemyslaw Wirkus changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED CC||wirkus at gcc dot gnu.org --- Comment #4 from Przemyslaw Wirkus --- Closing as this issue is resolved and backport was done.
[Bug c/98269] gcc 6.5.0 __builtin_add_overflow() with small uint32_t values incorrectly detects overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98269 --- Comment #3 from Jakub Jelinek --- For documentation, the bisection would be best, if you can preprocess the testcase and git bisect it between some 6.0-ish and 8.0-ish trunk revisions, we could know if the bug has been fixed or is just mere latent.
[Bug middle-end/98264] [11 Regression] ice during linear_loads_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98264 Tamar Christina changed: What|Removed |Added Version|unknown |11.0 Summary|ice during linear_loads_p |[11 Regression] ice during ||linear_loads_p Target Milestone|--- |11.0
[Bug middle-end/98264] ice during linear_loads_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98264 Tamar Christina changed: What|Removed |Added CC|tamar.christina at arm dot com |tnfchris at gcc dot gnu.org Last reconfirmed||2020-12-14 Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot gnu.org --- Comment #7 from Tamar Christina --- confirmed, testing patch. Curiously this tests runs with `-O2 -mavx -mfpmath=sse` for me locally which passes but I can reproduce it using the reported flags. > Any news of anything faster would be appreciated. You don't have to rebuild the whole thing at every step just the C compiler since this is a C test. So once you build it once you can go into the build dir (since you're doing a non-bootstrap build) and do `make cc1 -C gcc -j ` . Which should take just seconds. If you're doing a bootstrapped build you should just build the last stage. You can then run the testcase using the `xgcc` command you see in the log (you don't need the install).
[Bug c/98269] gcc 6.5.0 __builtin_add_overflow() with small uint32_t values incorrectly detects overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98269 stli at linux dot ibm.com changed: What|Removed |Added Target||s390x Known to work||10.1.0, 5.4.0, 5.5.0, ||7.1.0, 8.1.0, 9.1.0 CC||stli at linux dot ibm.com Known to fail||6.3.0, 6.4.0, 6.5.0 --- Comment #2 from stli at linux dot ibm.com --- That's okay for me. But I wanted to document it. Currently glibc is requiring gcc 6.2 as minimum. For s390x, I will post a patch which requires gcc 7.1 as minimum.
[Bug c/98269] gcc 6.5.0 __builtin_add_overflow() with small uint32_t values incorrectly detects overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98269 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- gcc 6.5 is unsupported since October 2018 and 7.x since November 2019, so if currently supported branches work, there is nothing to do for us. If you want, you can bisect which gcc change fixed it.
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-12-14 CC||ebotcazou at gcc dot gnu.org --- Comment #4 from Eric Botcazou --- This looks like a miscompilation of the compiler so probably not reproducible with a cross compiler.
[Bug c/98267] internal compiler error: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98267 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Possible dup of PR98256, please retry with r11-5974-g49ec63666e086853401021e686f0aa4d285ce9dc or later.
[Bug c/98269] New: gcc 6.5.0 __builtin_add_overflow() with small uint32_t values incorrectly detects overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98269
Bug ID: 98269
Summary: gcc 6.5.0 __builtin_add_overflow() with small uint32_t
values incorrectly detects overflow
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: stli at linux dot ibm.com
Target Milestone: ---
Created attachment 49756
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49756&action=edit
Build this tst-gcc-addoverflow.c with gcc 6.5.0 to see the ERROR
If build on s390x (I had no chance to test it on other architectures) with gcc
6.5.0 the attached testcase with small uint32_t input values for
__builtin_add_overflow() detects an overflow and fails:
else if (__builtin_add_overflow (previous->offset,
previous->length + 1,
¤t->offset))
{
printf ("ERROR: __builtin_add_overflow() OVERFLOWED: "
"previous->offset=%" PRIu32 " + "
"(previous->length=%" PRIu32 " + 1)"
" => current->offset=%" PRIu32 "\n",
previous->offset, previous->length, current->offset);
return EXIT_FAILURE;
}
=>
ERROR: __builtin_add_overflow() OVERFLOWED: previous->offset=7 +
(previous->length=3 + 1) => current->offset=11
I have not recognized this issue with gcc 7.1 and later.
The original issue was found if glibc is build with gcc 6.5.0:
__builtin_add_overflow is used in
/elf/stringtable.c:stringtable_finalize()
(https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/stringtable.c;h=099347d73ee70b8ffa4b4a91c493e0bba147ffa2;hb=HEAD#l185)
which leads to ldconfig failing with "String table is too large". This is
also recognizable in following glibc-tests:
FAIL: elf/tst-glibc-hwcaps-cache
FAIL: elf/tst-glibc-hwcaps-prepend-cache
FAIL: elf/tst-ldconfig-X
FAIL: elf/tst-ldconfig-bad-aux-cache
FAIL: elf/tst-ldconfig-ld_so_conf-update
FAIL: elf/tst-stringtable
Please also have a look at attached tst-gcc-addoverflow.c for some more details
from my gdb session showing the add and jump instruction.
[Bug tree-optimization/98268] New: ICE: verify_gimple failed with LTO and SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98268
Bug ID: 98268
Summary: ICE: verify_gimple failed with LTO and SVE
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
The following fails on the head of the GCC 10 branch (reproduced at
g:907525c3063e6ec5cf02790a5d5a37053c731401 with both an aarch64-elf cross and
natively on aarch64-linux-gnu):
$ cat a.c
short d, e;
void f(char, long*);
int main() {
long x;
f(-114, &x);
return d == e;
}
$ cat b.c
extern short d[], e[];
void f(char a, long *b) {
for (int c = 0; c < a - 12; c++) {
d[c] = b[c];
e[c] = 0;
}
}
$ aarch64-elf-gcc a.c b.c -flto -O1 -march=armv8.2-a+sve -ftree-vectorize
-msve-vector-bits=128
a.c: In function 'main':
a.c:3:5: error: constant not recomputed when 'ADDR_EXPR' changed
3 | int main() {
| ^
_59 = &MEM [(short int *)&d + 256B];
a.c:3:5: error: constant not recomputed when 'ADDR_EXPR' changed
_64 = &MEM [(short int *)&e + 256B];
during GIMPLE pass: dom
a.c:3:5: internal compiler error: verify_gimple failed
0xcbba04 verify_gimple_in_cfg(function*, bool)
/home/alecop01/toolchain/src/gcc/gcc/tree-cfg.c:5492
0xb6dca8 execute_function_todo
/home/alecop01/toolchain/src/gcc/gcc/passes.c:1985
0xb6dea2 do_per_function
/home/alecop01/toolchain/src/gcc/gcc/passes.c:1640
0xb6e03d execute_todo
/home/alecop01/toolchain/src/gcc/gcc/passes.c:2039
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
