[Bug other/92329] New: Undocumented option -f{,no-}allocation-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92329
Bug ID: 92329
Summary: Undocumented option -f{,no-}allocation-dce
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: documentation
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
The -f{,no-}allocation-dce option introduced in r273791 still seems to be
undocumented in the user's manual.
[Bug tree-optimization/92328] New: [10 Regression] ICE in eliminate_stmt, at tree-ssa-sccvn.c:5497
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92328
Bug ID: 92328
Summary: [10 Regression] ICE in eliminate_stmt, at
tree-ssa-sccvn.c:5497
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-10.0.0-alpha20191027 snapshot (r277495) ICEs when compiling the following
testcase w/ -O2:
int nt;
void
ja (int os)
{
int *ku = , *id =
unsigned int qr = 0;
for (;;)
{
if (os == *ku)
{
*id = 0;
qr += os != *ku;
id =
}
*id &= qr;
if (os != 0)
{
nt /= 0;
ku =
}
}
}
% gcc-10.0.0-alpha20191027 -O2 -w -c ewpykney.c
during GIMPLE pass: pre
ewpykney.c: In function 'ja':
ewpykney.c:4:1: internal compiler error: in eliminate_stmt, at
tree-ssa-sccvn.c:5497
4 | ja (int os)
| ^~
0x6a5140 eliminate_dom_walker::eliminate_stmt(basic_block_def*,
gimple_stmt_iterator*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191027/work/gcc-10-20191027/gcc/tree-ssa-sccvn.c:5497
0xdee2bd eliminate_dom_walker::before_dom_children(basic_block_def*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191027/work/gcc-10-20191027/gcc/tree-ssa-sccvn.c:5913
0xdee2bd eliminate_dom_walker::before_dom_children(basic_block_def*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191027/work/gcc-10-20191027/gcc/tree-ssa-sccvn.c:5846
0x1406b6a dom_walker::walk(basic_block_def*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191027/work/gcc-10-20191027/gcc/domwalk.c:309
0xde657d eliminate_with_rpo_vn(bitmap_head*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191027/work/gcc-10-20191027/gcc/tree-ssa-sccvn.c:6091
0xdcadb0 execute
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191027/work/gcc-10-20191027/gcc/tree-ssa-pre.c:4234
[Bug c++/92327] New: insufficient diagnosis on the incompatibility type of auto template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92327
Bug ID: 92327
Summary: insufficient diagnosis on the incompatibility type of
auto template parameter
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jonathan.poelen at gmail dot com
Target Milestone: ---
template class val{};
long const x = 1;
val<1> v = val(); // val<1> != val<1>
test.cpp:3:12: error: conversion from ‘val<1>’ to non-scalar type ‘val<1>’
requested
3 | val<1> v = val();
|^~~~
https://godbolt.org/z/l_nb-W
Clang shows the real type of the parameter:
test.cpp:3:8: error: no viable conversion from 'val' to
'val<(int) 1>'
[Bug bootstrap/92314] [10 regression] missing omp-device-properties', needed by 's-omp-device-properties-h'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92314 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #10 from Jakub Jelinek --- Should be fixed now.
[Bug bootstrap/92314] [10 regression] missing omp-device-properties', needed by 's-omp-device-properties-h'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92314 --- Comment #9 from Jakub Jelinek --- Author: jakub Date: Fri Nov 1 23:34:21 2019 New Revision: 277735 URL: https://gcc.gnu.org/viewcvs?rev=277735=gcc=rev Log: PR bootstrap/92314 * configure.ac: Don't look for omp-device-properties files from installed offloading compilers. Instead add tmake_file snippets for configured offloading targets and use files they generate. * Makefile.in (install): Don't depend on install-omp-device-properties. (install-omp-device-properties): Remove goal. * config/i386/t-omp-device: New file. * config/i386/t-intelmic (omp-device-properties): Remove goal. * config/nvptx/t-omp-device: New file. * config/nvptx/t-nvptx (omp-device-properties): Remove goal. * configure: Regenerated. Added: trunk/gcc/config/i386/t-omp-device trunk/gcc/config/nvptx/t-omp-device Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/config/i386/t-intelmic trunk/gcc/config/nvptx/t-nvptx trunk/gcc/configure trunk/gcc/configure.ac
[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88335 --- Comment #13 from Jakub Jelinek --- Author: jakub Date: Fri Nov 1 23:28:20 2019 New Revision: 277733 URL: https://gcc.gnu.org/viewcvs?rev=277733=gcc=rev Log: PR c++/88335 - Implement P1073R3: Immediate functions c-family/ * c-common.h (enum rid): Add RID_CONSTEVAL. * c-common.c (c_common_reswords): Add consteval. cp/ * cp-tree.h (struct lang_decl_fn): Add immediate_fn_p bit. (DECL_IMMEDIATE_FUNCTION_P, SET_DECL_IMMEDIATE_FUNCTION_P): Define. (enum cp_decl_spec): Add ds_consteval. (fold_non_dependent_expr): Add another tree argument defaulted to NULL_TREE. * name-lookup.h (struct cp_binding_level): Add immediate_fn_ctx_p member. * parser.c (cp_keyword_starts_decl_specifier_p): Adjust comments for C++11 and C++20 specifiers. Handle RID_CONSTEVAL. (CP_PARSER_FLAGS_ONLY_MUTABLE_OR_CONSTEXPR): Adjust comment. (CP_PARSER_FLAGS_CONSTEVAL): New. (cp_parser_skip_balanced_tokens): New forward declaration. (cp_parser_lambda_declarator_opt): Handle ds_consteval. Set current_binding_level->immediate_fn_ctx_p before parsing parameter list if decl-specifier-seq contains consteval specifier. (cp_parser_decl_specifier_seq): Handle RID_CONSTEVAL. (cp_parser_explicit_instantiation): Diagnose explicit instantiation with consteval specifier. (cp_parser_init_declarator): For consteval or into flags CP_PARSER_FLAGS_CONSTEVAL. (cp_parser_direct_declarator): If CP_PARSER_FLAGS_CONSTEVAL, set current_binding_level->immediate_fn_ctx_p in the sk_function_parms scope. (set_and_check_decl_spec_loc): Add consteval entry, formatting fix. * call.c (build_addr_func): For direct calls to immediate functions use build_address rather than decay_conversion. (build_over_call): Evaluate immediate function invocations. * error.c (dump_function_decl): Handle DECL_IMMEDIATE_FUNCTION_P. * semantics.c (expand_or_defer_fn_1): Use tentative linkage and don't call mark_needed for immediate functions. * typeck.c (cxx_sizeof_or_alignof_expr): Likewise. Formatting fix. (cp_build_addr_expr_1): Reject taking address of immediate function outside of immediate function. * decl.c (validate_constexpr_redeclaration): Diagnose consteval vs. non-consteval or vice versa redeclaration. Use SET_DECL_IMMEDIATE_FUNCTION_P if new_decl is immediate function. (check_tag_decl): Use %qs with keyword string to simplify translation. Handle ds_consteval. (start_decl): Adjust diagnostics for static or thread_local variables in immediate functions. (grokfndecl): Call sorry_at on virtual consteval. Use %qs with keyword to string to simplify translation. Diagnose consteval main. Use SET_DECL_IMMEDIATE_FUNCTION_P for consteval. (grokdeclarator): Handle consteval. Use %qs with keyword strings to simplify translation. Use separate ifs instead of chained else if for invalid specifiers. For constinit clear constinit_p rather than constexpr_p. * constexpr.c (find_immediate_fndecl): New function. (cxx_eval_outermost_constant_expr): Allow consteval calls returning void. Diagnose returning address of immediate function from consteval evaluation. (fold_non_dependent_expr_template): Add OBJECT argument, pass it through to cxx_eval_outermost_constant_expr. (fold_non_dependent_expr): Add OBJECT argument, pass it through to fold_non_dependent_expr_template. (fold_non_dependent_init): Adjust fold_non_dependent_expr_template caller. * method.c (defaulted_late_check): Adjust diagnostics for consteval. * lambda.c (maybe_add_lambda_conv_op): Copy over DECL_DECLARED_CONSTEXPR_P and DECL_IMMEDIATE_FUNCTION_P bits from callop to both artificial functions. * init.c (build_value_init): Don't do further processing if build_special_member_call returned a TREE_CONSTANT. Formatting fix. testsuite/ * g++.dg/cpp2a/consteval1.C: New test. * g++.dg/cpp2a/consteval2.C: New test. * g++.dg/cpp2a/consteval3.C: New test. * g++.dg/cpp2a/consteval4.C: New test. * g++.dg/cpp2a/consteval5.C: New test. * g++.dg/cpp2a/consteval6.C: New test. * g++.dg/cpp2a/consteval7.C: New test. * g++.dg/cpp2a/consteval8.C: New test. * g++.dg/cpp2a/consteval9.C: New test. * g++.dg/cpp2a/consteval10.C: New test. * g++.dg/cpp2a/consteval11.C: New test. * g++.dg/cpp2a/consteval12.C: New test. * g++.dg/cpp2a/consteval13.C: New test. * g++.dg/cpp2a/consteval14.C: New test. * g++.dg/ext/consteval1.C: New test. Added:
[Bug c++/91369] Implement P0784R7: constexpr new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91369
--- Comment #20 from Jakub Jelinek ---
Author: jakub
Date: Fri Nov 1 23:26:17 2019
New Revision: 277732
URL: https://gcc.gnu.org/viewcvs?rev=277732=gcc=rev
Log:
PR c++/91369 - Implement P0784R7: constexpr new
* cp-tree.h (CALL_FROM_NEW_OR_DELETE_P): Define.
* init.c (build_new_1, build_vec_delete_1, build_delete): Set
CALL_FROM_NEW_OR_DELETE_P on the CALL_EXPR to allocator functions.
* constexpr.c (is_std_allocator_allocate): Only allow
global replaceable allocator functions if CALL_FROM_NEW_OR_DELETE_P
or in std::allocate::{,de}allocate.
(potential_constant_expression_1): Likewise.
* g++.dg/cpp2a/constexpr-new6.C: New test.
* g++.dg/cpp2a/constexpr-new7.C: New test.
Added:
trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-new6.C
trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-new7.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/init.c
trunk/gcc/testsuite/ChangeLog
[Bug c/92326] wrong bound in zero-length array diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92326 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-11-01 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Target Milestone|--- |10.0 Ever confirmed|0 |1 Severity|normal |trivial
[Bug c/92326] New: wrong bound in zero-length array diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92326
Bug ID: 92326
Summary: wrong bound in zero-length array diagnostics
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
r277728 changed the formatting of zero-length arrays in diagnostics to include
their bound, but the change also inadvertently added the zero bound to flexible
array members (because they are gratuitously represented differently between
the front-ends). The test case below shows the problem. It only affects C
code:
$ cat x.c && gcc -O2 -S -Wall x.c
struct S0 { int n, a[0]; } s0;
struct Sx { int n, a[]; } sx = { 0 };
void f (void)
{
s0.a[0] = 0;
sx.a[0] = 0;
}
x.c: In function ‘f’:
x.c:6:7: warning: array subscript 0 is above array bounds of ‘int[0]’
[-Warray-bounds]
6 | s0.a[0] = 0;
| ^~~
x.c:1:20: note: while referencing ‘a’
1 | struct S0 { int n, a[0]; } s0;
|^
x.c:1:28: note: defined here ‘s0’
1 | struct S0 { int n, a[0]; } s0;
|^~
x.c:7:7: warning: array subscript 0 is above array bounds of ‘int[0]’
[-Warray-bounds]
7 | sx.a[0] = 0;
| ^~~
x.c:2:20: note: while referencing ‘a’
2 | struct Sx { int n, a[]; } sx = { 0 };
|^
x.c:2:27: note: defined here ‘sx’
2 | struct Sx { int n, a[]; } sx = { 0 };
| ^~
When compiled by the C++ front-end, the format of the arrays is as expected:
$ gcc -O2 -S -Wall -xc++ x.c
x.c: In function ‘void f()’:
x.c:6:9: warning: array subscript 0 is above array bounds of ‘int [0]’
[-Warray-bounds]
6 | s0.a[0] = 0;
| ~~^
x.c:1:20: note: while referencing ‘S0::a’
1 | struct S0 { int n, a[0]; } s0;
|^
x.c:1:28: note: defined here ‘s0’
1 | struct S0 { int n, a[0]; } s0;
|^~
x.c:7:9: warning: array subscript 0 is above array bounds of ‘int []’
[-Warray-bounds]
7 | sx.a[0] = 0;
| ~~^
x.c:2:20: note: while referencing ‘Sx::a’
2 | struct Sx { int n, a[]; } sx = { 0 };
|^
x.c:2:27: note: defined here ‘sx’
2 | struct Sx { int n, a[]; } sx = { 0 };
| ^~
[Bug tree-optimization/91647] [10 Regression] new FAILs for Warray-bounds-8 and Wstringop-overflow-3.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91647 --- Comment #14 from Martin Sebor --- Both Warray-bounds-8 and Wstringop-overflow-3.C pass with the Darwin cross now. Both the Darwin cross and a native GCC 10 now also issue the same warnings for the test case in comment #7. With the cross I see a bunch of failures in a few other tests (below) but those should get their own bug(s). c-c++-common/Warray-bounds-2.c c-c++-common/Warray-bounds.c gcc.dg/Warray-bounds-31.c gcc.dg/Wstringop-overflow-13.c
[Bug c++/69698] [meta-bug] flexible array members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69698 Bug 69698 depends on bug 91463, which changed state. Bug 91463 Summary: missing -Warray-bounds accessing past the end of a statically initialized flexible array member https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91463 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 91463, which changed state. Bug 91463 Summary: missing -Warray-bounds accessing past the end of a statically initialized flexible array member https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91463 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/91463] missing -Warray-bounds accessing past the end of a statically initialized flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91463
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Component|c |middle-end
Resolution|--- |FIXED
Target Milestone|--- |10.0
--- Comment #7 from Martin Sebor ---
GCC 10 now issues the following warning for the test case in comment #0:
pr91463.c: In function ‘f’:
pr91463.c:7:6: warning: array subscript 666 is above array bounds of ‘int[0]’
[-Warray-bounds]
7 | s.a[666] = 0; // missing -Warray-bounds
| ~~~^
pr91463.c:1:19: note: while referencing ‘a’
1 | struct S { int n, a[]; };
| ^
pr91463.c:3:10: note: defined here ‘s’
3 | struct S s = { 2, { 1, 0 } };
| ^
I agree that some of these problems can be detected earlier. It might be worth
moving some of the -Warray-bounds code out of tree-vrp.c and into some utility
function that could be called by earlier passes, or even by the front-ends
without optimization, to detect the basic problems. I'll keep that in mind as
a possible future project.
[Bug target/92322] Compilation (of gdrcopy) in cloud environments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92322 afernandez at odyhpc dot com changed: What|Removed |Added Resolution|DUPLICATE |FIXED --- Comment #3 from afernandez at odyhpc dot com --- Hi Andrew. It's a configuration issue, nothing wrong with the compiler as you mention. Thanks.
[Bug middle-end/92312] [10 Regression] bogus -Wstringop-overflow storing into a trailing array backed by larger buffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92312 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Summary|bogus -Wstringop-overflow |[10 Regression] bogus |storing into a trailing |-Wstringop-overflow storing |array backed by larger |into a trailing array |buffer |backed by larger buffer --- Comment #3 from Martin Sebor --- Fixed by r277728.
[Bug fortran/92311] Fortran and OpenMP use_device_ptr and OpenACC attach_ptr/dettach_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92311 --- Comment #4 from Nichols A. Romero --- Jakub, My apologies for wasting your time. I had asked a colleague to help me put a simplified test case together, after closer inspection it did not actually reproduce the use case from the larger scientific code. As far as I can tell, there is no bug with OpenMP frontend. Only a bug in my understanding of the use_device_ptr. I was told it was equivalent to OpenACC detach/attach, but I think this is not the case. Most examples that I find online are for passing pointers to CUDA library. I can now get the attach coded to compile with XLF and GCC 9.2 with OpenMP and they behave identically -- more importantly, it actually reflects that use case in the larger scientific code. The OpenACC code doesn't compile, but I think this may be because OpenACC 2.6 is only partially implemented in Fortran ???
[Bug fortran/92311] Fortran and OpenMP use_device_ptr and OpenACC attach_ptr/dettach_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92311 Nichols A. Romero changed: What|Removed |Added Attachment #47152|0 |1 is obsolete|| --- Comment #3 from Nichols A. Romero --- Created attachment 47156 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47156=edit OpenMP equivalent to OpenACC detach/attach
[Bug middle-end/91679] missing -Warray-bounds accessing a member array in a local buffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91679 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||10.0 Resolution|--- |FIXED Target Milestone|--- |10.0 Known to fail||7.3.0, 8.3.0, 9.2.0 --- Comment #4 from Martin Sebor --- With the patch GCC 10.0 diagnoses the test case like so: pr91679.c: In function ‘h’: pr91679.c:13:7: warning: array subscript 4 is above array bounds of ‘short int[1]’ [-Warray-bounds] 13 | p->a[4] = 4; // out of bounds, missing warning | ^~~ pr91679.c:4:9: note: while referencing ‘a’ 4 | short a[1]; | ^
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 91679, which changed state. Bug 91679 Summary: missing -Warray-bounds accessing a member array in a local buffer https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91679 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/86487] [7/8 Regression] insn does not satisfy its constraints on arm big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86487 --- Comment #13 from Jeffrey A. Law --- Author: law Date: Fri Nov 1 22:37:04 2019 New Revision: 277729 URL: https://gcc.gnu.org/viewcvs?rev=277729=gcc=rev Log: Backport from trunk 2019-02-20 Andre Vieira PR target/86487 * lra-constraints.c(uses_hard_regs_p): Fix handling of paradoxical SUBREGS. PR target/86487 * gcc.target/arm/pr86487.c: New. Added: branches/gcc-8-branch/gcc/testsuite/gcc.target/arm/pr86487.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/lra-constraints.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug c++/17314] Error message wrongly shows declared rather than inherited access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17314
kamilek1313 at poczta dot fm changed:
What|Removed |Added
CC||kamilek1313 at poczta dot fm
--- Comment #20 from kamilek1313 at poczta dot fm ---
I think the point of this issue was missed. It has nothing to do with
constructors/destructors, it can be reproduced with the following example:
class Grandparent {
protected:
int foo = 0;
};
struct Parent : private Grandparent {
};
struct Child : public Parent {
void bar() {foo = 1;}
};
Currently (GCC 9.2.0, also present in experimetal), the following error is
issued:
prog.cc: In member function 'void Child::bar()':
prog.cc:10:17: error: 'int Grandparent::foo' is protected within this context
10 | void bar() {foo = 1;}
| ^~~
prog.cc:3:9: note: declared protected here
3 | int foo = 0;
| ^~~
See Wandbox: https://wandbox.org/permlink/mwF205Xm6A3xcKGy
This error message is just wrong. Grandparent::foo is private within this
context, due to private inheritance. If it was protected, it would be
accessible by Child. Upon seeing this message, I have no clue what is wrong
(yeah, it is protected, so what?)
For comparison, clang 10 produces clear(ish) error message for the same code:
prog.cc:10:17: error: cannot cast 'Child' to its private base class
'Grandparent'
void bar() {foo = 1;}
^
prog.cc:6:17: note: declared private here
struct Parent : private Grandparent {
^~~
prog.cc:10:17: error: 'foo' is a private member of 'Grandparent'
void bar() {foo = 1;}
^
prog.cc:6:17: note: constrained by private inheritance here
struct Parent : private Grandparent {
^~~
prog.cc:3:9: note: member is declared here
int foo = 0;
^
2 errors generated.
[Bug rtl-optimization/92281] Inconsistent canonicalization of (minus (minus A B) C)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92281 --- Comment #6 from Segher Boessenkool --- (In reply to Richard Earnshaw from comment #5) > What I've shown is equivalent to (minus (minus (A) (B)) (C)), which is what > combine produces today. Are you saying that the documentation disagrees on > the overall shape of this and the compilers output right now? I am saying that a lot of what combine forms is not canonical form. There simply is no canonical form for many expressions. Every combine attempt results in one form, that is a very important feature as well as one of the main weaknesses of combine; but that one form is *not* canonical. > Minus isn't commutative, but in a 3-way version (A - B - C), the order of B > and C does not matter. ... - B - C is the same as ... - C - B. So you can > re-order the nesting to produce a canonical form. Sure. And where there isn't a canonical form, you can reorder it whatever way you want. That is why there *are* canonical forms: to reduce the number of forms everything has to deal with. But this does not always help, and some times it works *against* this goal. > > > > What targets would it break, and how? > > > > > > Hard to tell, until we try it. Mostly the 'breakage' would be some > > > combine > > > patterns might no-longer match if the target only had one and the ordering > > > were not canonical (leading to some missed optimizations). On targets > > > that > > > have both orderings, some patterns might become redundant and never match > > > unless directly generated by the back-end. > > > > The breakage will be that many targets optimise worse than they did before. > > And this is non-obvious to detect, usually. > > At present it's entirely random, since there's no attempt to create order. It usually preserves ordering. Simply by not changing things that do not need any change. But sometimes things are changed for no apparent reason. > Any matching that does occur is more by good luck (or overkill in providing > all the redundant variant forms). Yes, but any change that degrades code quality is still a regression, whether those targets just got lucky or that was by design. > > A lot of what combine does is *not* canonicalisation. But combine comes up > > with only one result for every attempted combination, making that a kind-of > > de-facto canonicalisation. > > > > And yes, that is what I asked: in both cases it combined the same insn with > > a simple pseudo move, in both cases on the RHS in that insn. And it came > > up with different results. > > > > This may be unavoidable, or combine does something weird, or the RTL that > > combine started with was non-canonical or unexpected in some other way, etc. > > > > So I'd like to know where the difference was introduced. Was it in combine > > at all, to start with? It can be in simplify-rtx as well for example. > > Combine is the prime user of simplify-rtx - perhaps I'm conflating the two, > but this is, in part, combine's problem because it's during the combine pass > that having matchers for all these variants becomes most important. I am not asking to shift the blame. I am asking to start to solve the problem. To do that we need to know where the problem *is*, if there actually is a problem, etc. Just more information is needed. simplify-rtx is very different from combine. Everything simplify-rtx does is a simplification(*). Many things combine does are *not*. That is one of the reasons combine still has its own "simplifier": it is not a simplifier. Some of what that does is good and useful. Some of it is questionable. Some of it is actively bad. (*) There are a few cases where simplify-rtx does a non-simplification. I try to weed those out.
[Bug tree-optimization/91647] [10 Regression] new FAILs for Warray-bounds-8 and Wstringop-overflow-3.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91647 --- Comment #13 from Martin Sebor --- Author: msebor Date: Fri Nov 1 21:09:20 2019 New Revision: 277728 URL: https://gcc.gnu.org/viewcvs?rev=277728=gcc=rev Log: PR middle-end/91679 - missing -Warray-bounds accessing a member array in a local buffer PR middle-end/91647 - new FAILs for Warray-bounds-8 and Wstringop-overflow-3.C PR middle-end/91463 - missing -Warray-bounds accessing past the end of a statically initialized flexible array member PR middle-end/92312 - bogus -Wstringop-overflow storing into a trailing array backed by larger buffer gcc/ChangeLog: PR middle-end/91679 PR middle-end/91647 PR middle-end/91463 PR middle-end/92312 * c-family/c-pretty-print.c (direct_abstract_declarator): Print bound in zero-length arrays. * gcc/c-family/c.opt (-Wzero-length-bounds): New option. * gcc/doc/invoke.texi (-Wzero-length-bounds): Document. * gimple-match-head.c (try_conditional_simplification): Use memcpy instead of a hand-rolled loop to avoid PR 92323. * tree-vrp.c (vrp_prop::check_array_ref): Handle trailing arrays with initializers. (vrp_prop::check_mem_ref): Handle declared struct objects. * tree.c (last_field): New function. (array_at_struct_end_p): Handle MEM_REF. (get_initializer_for): New helper. (component_ref_size): Add argument. Rename locals. Call get_initializer_for instead of fold_ctor_reference. Correct handling of flexible array members. * wide-int.h (generic_wide_int ::sign_mask): Assert invariant. gcc/testsuite/ChangeLog: PR middle-end/91679 PR middle-end/91647 PR middle-end/91463 PR middle-end/92312 * c-c++-common/Warray-bounds-2.c: Disable VRP. Adjust expected messages. * g++.dg/warn/Warray-bounds-8.C: Remove xfails. * gcc.dg/Warray-bounds-48.c: New test. * gcc.dg/Warray-bounds-49.c: New test. * gcc.dg/Wstringop-overflow-16.c: Adjust text of expected messages. * gcc.dg/Wstringop-overflow-21.c: New test. * gcc.dg/Wzero-length-array-bounds.c: New test. * gcc.dg/pr36902.c: Remove xfail. * gcc.dg/strlenopt-57.c: Add an expected warning. Added: trunk/gcc/testsuite/gcc.dg/Warray-bounds-48.c trunk/gcc/testsuite/gcc.dg/Warray-bounds-49.c trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-21.c trunk/gcc/testsuite/gcc.dg/Wzero-length-array-bounds.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/c-pretty-print.c trunk/gcc/c-family/c.opt trunk/gcc/doc/invoke.texi trunk/gcc/gimple-match-head.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c trunk/gcc/testsuite/g++.dg/warn/Warray-bounds-8.C trunk/gcc/testsuite/gcc.dg/Warray-bounds-46.c trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-16.c trunk/gcc/testsuite/gcc.dg/pr36902.c trunk/gcc/testsuite/gcc.dg/strlenopt-57.c trunk/gcc/tree-vrp.c trunk/gcc/tree.c trunk/gcc/tree.h trunk/gcc/wide-int.h
[Bug tree-optimization/92323] bogus -Warray-bounds after unrolling despite __builtin_unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92323 --- Comment #2 from Martin Sebor --- Author: msebor Date: Fri Nov 1 21:09:20 2019 New Revision: 277728 URL: https://gcc.gnu.org/viewcvs?rev=277728=gcc=rev Log: PR middle-end/91679 - missing -Warray-bounds accessing a member array in a local buffer PR middle-end/91647 - new FAILs for Warray-bounds-8 and Wstringop-overflow-3.C PR middle-end/91463 - missing -Warray-bounds accessing past the end of a statically initialized flexible array member PR middle-end/92312 - bogus -Wstringop-overflow storing into a trailing array backed by larger buffer gcc/ChangeLog: PR middle-end/91679 PR middle-end/91647 PR middle-end/91463 PR middle-end/92312 * c-family/c-pretty-print.c (direct_abstract_declarator): Print bound in zero-length arrays. * gcc/c-family/c.opt (-Wzero-length-bounds): New option. * gcc/doc/invoke.texi (-Wzero-length-bounds): Document. * gimple-match-head.c (try_conditional_simplification): Use memcpy instead of a hand-rolled loop to avoid PR 92323. * tree-vrp.c (vrp_prop::check_array_ref): Handle trailing arrays with initializers. (vrp_prop::check_mem_ref): Handle declared struct objects. * tree.c (last_field): New function. (array_at_struct_end_p): Handle MEM_REF. (get_initializer_for): New helper. (component_ref_size): Add argument. Rename locals. Call get_initializer_for instead of fold_ctor_reference. Correct handling of flexible array members. * wide-int.h (generic_wide_int ::sign_mask): Assert invariant. gcc/testsuite/ChangeLog: PR middle-end/91679 PR middle-end/91647 PR middle-end/91463 PR middle-end/92312 * c-c++-common/Warray-bounds-2.c: Disable VRP. Adjust expected messages. * g++.dg/warn/Warray-bounds-8.C: Remove xfails. * gcc.dg/Warray-bounds-48.c: New test. * gcc.dg/Warray-bounds-49.c: New test. * gcc.dg/Wstringop-overflow-16.c: Adjust text of expected messages. * gcc.dg/Wstringop-overflow-21.c: New test. * gcc.dg/Wzero-length-array-bounds.c: New test. * gcc.dg/pr36902.c: Remove xfail. * gcc.dg/strlenopt-57.c: Add an expected warning. Added: trunk/gcc/testsuite/gcc.dg/Warray-bounds-48.c trunk/gcc/testsuite/gcc.dg/Warray-bounds-49.c trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-21.c trunk/gcc/testsuite/gcc.dg/Wzero-length-array-bounds.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/c-pretty-print.c trunk/gcc/c-family/c.opt trunk/gcc/doc/invoke.texi trunk/gcc/gimple-match-head.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c trunk/gcc/testsuite/g++.dg/warn/Warray-bounds-8.C trunk/gcc/testsuite/gcc.dg/Warray-bounds-46.c trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-16.c trunk/gcc/testsuite/gcc.dg/pr36902.c trunk/gcc/testsuite/gcc.dg/strlenopt-57.c trunk/gcc/tree-vrp.c trunk/gcc/tree.c trunk/gcc/tree.h trunk/gcc/wide-int.h
[Bug c/91463] missing -Warray-bounds accessing past the end of a statically initialized flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91463 --- Comment #6 from Martin Sebor --- Author: msebor Date: Fri Nov 1 21:09:20 2019 New Revision: 277728 URL: https://gcc.gnu.org/viewcvs?rev=277728=gcc=rev Log: PR middle-end/91679 - missing -Warray-bounds accessing a member array in a local buffer PR middle-end/91647 - new FAILs for Warray-bounds-8 and Wstringop-overflow-3.C PR middle-end/91463 - missing -Warray-bounds accessing past the end of a statically initialized flexible array member PR middle-end/92312 - bogus -Wstringop-overflow storing into a trailing array backed by larger buffer gcc/ChangeLog: PR middle-end/91679 PR middle-end/91647 PR middle-end/91463 PR middle-end/92312 * c-family/c-pretty-print.c (direct_abstract_declarator): Print bound in zero-length arrays. * gcc/c-family/c.opt (-Wzero-length-bounds): New option. * gcc/doc/invoke.texi (-Wzero-length-bounds): Document. * gimple-match-head.c (try_conditional_simplification): Use memcpy instead of a hand-rolled loop to avoid PR 92323. * tree-vrp.c (vrp_prop::check_array_ref): Handle trailing arrays with initializers. (vrp_prop::check_mem_ref): Handle declared struct objects. * tree.c (last_field): New function. (array_at_struct_end_p): Handle MEM_REF. (get_initializer_for): New helper. (component_ref_size): Add argument. Rename locals. Call get_initializer_for instead of fold_ctor_reference. Correct handling of flexible array members. * wide-int.h (generic_wide_int ::sign_mask): Assert invariant. gcc/testsuite/ChangeLog: PR middle-end/91679 PR middle-end/91647 PR middle-end/91463 PR middle-end/92312 * c-c++-common/Warray-bounds-2.c: Disable VRP. Adjust expected messages. * g++.dg/warn/Warray-bounds-8.C: Remove xfails. * gcc.dg/Warray-bounds-48.c: New test. * gcc.dg/Warray-bounds-49.c: New test. * gcc.dg/Wstringop-overflow-16.c: Adjust text of expected messages. * gcc.dg/Wstringop-overflow-21.c: New test. * gcc.dg/Wzero-length-array-bounds.c: New test. * gcc.dg/pr36902.c: Remove xfail. * gcc.dg/strlenopt-57.c: Add an expected warning. Added: trunk/gcc/testsuite/gcc.dg/Warray-bounds-48.c trunk/gcc/testsuite/gcc.dg/Warray-bounds-49.c trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-21.c trunk/gcc/testsuite/gcc.dg/Wzero-length-array-bounds.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/c-pretty-print.c trunk/gcc/c-family/c.opt trunk/gcc/doc/invoke.texi trunk/gcc/gimple-match-head.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c trunk/gcc/testsuite/g++.dg/warn/Warray-bounds-8.C trunk/gcc/testsuite/gcc.dg/Warray-bounds-46.c trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-16.c trunk/gcc/testsuite/gcc.dg/pr36902.c trunk/gcc/testsuite/gcc.dg/strlenopt-57.c trunk/gcc/tree-vrp.c trunk/gcc/tree.c trunk/gcc/tree.h trunk/gcc/wide-int.h
[Bug middle-end/91679] missing -Warray-bounds accessing a member array in a local buffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91679 --- Comment #3 from Martin Sebor --- Author: msebor Date: Fri Nov 1 21:09:20 2019 New Revision: 277728 URL: https://gcc.gnu.org/viewcvs?rev=277728=gcc=rev Log: PR middle-end/91679 - missing -Warray-bounds accessing a member array in a local buffer PR middle-end/91647 - new FAILs for Warray-bounds-8 and Wstringop-overflow-3.C PR middle-end/91463 - missing -Warray-bounds accessing past the end of a statically initialized flexible array member PR middle-end/92312 - bogus -Wstringop-overflow storing into a trailing array backed by larger buffer gcc/ChangeLog: PR middle-end/91679 PR middle-end/91647 PR middle-end/91463 PR middle-end/92312 * c-family/c-pretty-print.c (direct_abstract_declarator): Print bound in zero-length arrays. * gcc/c-family/c.opt (-Wzero-length-bounds): New option. * gcc/doc/invoke.texi (-Wzero-length-bounds): Document. * gimple-match-head.c (try_conditional_simplification): Use memcpy instead of a hand-rolled loop to avoid PR 92323. * tree-vrp.c (vrp_prop::check_array_ref): Handle trailing arrays with initializers. (vrp_prop::check_mem_ref): Handle declared struct objects. * tree.c (last_field): New function. (array_at_struct_end_p): Handle MEM_REF. (get_initializer_for): New helper. (component_ref_size): Add argument. Rename locals. Call get_initializer_for instead of fold_ctor_reference. Correct handling of flexible array members. * wide-int.h (generic_wide_int ::sign_mask): Assert invariant. gcc/testsuite/ChangeLog: PR middle-end/91679 PR middle-end/91647 PR middle-end/91463 PR middle-end/92312 * c-c++-common/Warray-bounds-2.c: Disable VRP. Adjust expected messages. * g++.dg/warn/Warray-bounds-8.C: Remove xfails. * gcc.dg/Warray-bounds-48.c: New test. * gcc.dg/Warray-bounds-49.c: New test. * gcc.dg/Wstringop-overflow-16.c: Adjust text of expected messages. * gcc.dg/Wstringop-overflow-21.c: New test. * gcc.dg/Wzero-length-array-bounds.c: New test. * gcc.dg/pr36902.c: Remove xfail. * gcc.dg/strlenopt-57.c: Add an expected warning. Added: trunk/gcc/testsuite/gcc.dg/Warray-bounds-48.c trunk/gcc/testsuite/gcc.dg/Warray-bounds-49.c trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-21.c trunk/gcc/testsuite/gcc.dg/Wzero-length-array-bounds.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/c-pretty-print.c trunk/gcc/c-family/c.opt trunk/gcc/doc/invoke.texi trunk/gcc/gimple-match-head.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c trunk/gcc/testsuite/g++.dg/warn/Warray-bounds-8.C trunk/gcc/testsuite/gcc.dg/Warray-bounds-46.c trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-16.c trunk/gcc/testsuite/gcc.dg/pr36902.c trunk/gcc/testsuite/gcc.dg/strlenopt-57.c trunk/gcc/tree-vrp.c trunk/gcc/tree.c trunk/gcc/tree.h trunk/gcc/wide-int.h
[Bug middle-end/92312] bogus -Wstringop-overflow storing into a trailing array backed by larger buffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92312 --- Comment #2 from Martin Sebor --- Author: msebor Date: Fri Nov 1 21:09:20 2019 New Revision: 277728 URL: https://gcc.gnu.org/viewcvs?rev=277728=gcc=rev Log: PR middle-end/91679 - missing -Warray-bounds accessing a member array in a local buffer PR middle-end/91647 - new FAILs for Warray-bounds-8 and Wstringop-overflow-3.C PR middle-end/91463 - missing -Warray-bounds accessing past the end of a statically initialized flexible array member PR middle-end/92312 - bogus -Wstringop-overflow storing into a trailing array backed by larger buffer gcc/ChangeLog: PR middle-end/91679 PR middle-end/91647 PR middle-end/91463 PR middle-end/92312 * c-family/c-pretty-print.c (direct_abstract_declarator): Print bound in zero-length arrays. * gcc/c-family/c.opt (-Wzero-length-bounds): New option. * gcc/doc/invoke.texi (-Wzero-length-bounds): Document. * gimple-match-head.c (try_conditional_simplification): Use memcpy instead of a hand-rolled loop to avoid PR 92323. * tree-vrp.c (vrp_prop::check_array_ref): Handle trailing arrays with initializers. (vrp_prop::check_mem_ref): Handle declared struct objects. * tree.c (last_field): New function. (array_at_struct_end_p): Handle MEM_REF. (get_initializer_for): New helper. (component_ref_size): Add argument. Rename locals. Call get_initializer_for instead of fold_ctor_reference. Correct handling of flexible array members. * wide-int.h (generic_wide_int ::sign_mask): Assert invariant. gcc/testsuite/ChangeLog: PR middle-end/91679 PR middle-end/91647 PR middle-end/91463 PR middle-end/92312 * c-c++-common/Warray-bounds-2.c: Disable VRP. Adjust expected messages. * g++.dg/warn/Warray-bounds-8.C: Remove xfails. * gcc.dg/Warray-bounds-48.c: New test. * gcc.dg/Warray-bounds-49.c: New test. * gcc.dg/Wstringop-overflow-16.c: Adjust text of expected messages. * gcc.dg/Wstringop-overflow-21.c: New test. * gcc.dg/Wzero-length-array-bounds.c: New test. * gcc.dg/pr36902.c: Remove xfail. * gcc.dg/strlenopt-57.c: Add an expected warning. Added: trunk/gcc/testsuite/gcc.dg/Warray-bounds-48.c trunk/gcc/testsuite/gcc.dg/Warray-bounds-49.c trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-21.c trunk/gcc/testsuite/gcc.dg/Wzero-length-array-bounds.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/c-pretty-print.c trunk/gcc/c-family/c.opt trunk/gcc/doc/invoke.texi trunk/gcc/gimple-match-head.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c trunk/gcc/testsuite/g++.dg/warn/Warray-bounds-8.C trunk/gcc/testsuite/gcc.dg/Warray-bounds-46.c trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-16.c trunk/gcc/testsuite/gcc.dg/pr36902.c trunk/gcc/testsuite/gcc.dg/strlenopt-57.c trunk/gcc/tree-vrp.c trunk/gcc/tree.c trunk/gcc/tree.h trunk/gcc/wide-int.h
[Bug bootstrap/92314] [10 regression] missing omp-device-properties', needed by 's-omp-device-properties-h'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92314 Jakub Jelinek changed: What|Removed |Added Status|RESOLVED|ASSIGNED Last reconfirmed||2019-11-01 Resolution|INVALID |--- Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #8 from Jakub Jelinek --- Created attachment 47155 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47155=edit gcc10-pr92314.patch As per IRC discussions, here is only lightly tested approach that doesn't need the offloading compiler at gcc build time again.
[Bug fortran/92325] -fdump-tree-original and char(kind=4) initializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92325 anlauf at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5
[Bug fortran/92325] New: -fdump-tree-original and char(kind=4) initializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92325
Bug ID: 92325
Summary: -fdump-tree-original and char(kind=4) initializations
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: anlauf at gcc dot gnu.org
Target Milestone: ---
While looking at a different PR, I noticed that the following code
produces unexpected output from -fdump-tree-original:
program p
implicit none
character(len=1,kind=4):: a1 = 4_'A'
character(len=2,kind=4):: a2 = 4_'AB'
character(len=3,kind=4):: a3 = 4_'ABC'
print *, a1 // a2 // a3
end
gcc-10 & gcc-9 produce:
p ()
{
static character(kind=4) a1[1:1] = "A\x00\x00";
static character(kind=4) a2[1:2] = "A\x00\x00\x00B\x00\x00";
static character(kind=4) a3[1:3] = "A\x00\x00\x00B\x00\x00\x00C\x00\x00";
...
while gcc-7 and gcc-8 produce:
p ()
{
static character(kind=4) a1[1:1] = "A";
static character(kind=4) a2[1:2] = "A";
static character(kind=4) a3[1:3] = "A";
So gcc-7 and gcc-8 only display the first character of the initializer,
while gcc-9 and gcc-10 has initializers that appear to be one byte too
short, as they miss the final \x00 of the last character.
While this may be an entirely cosmetic issue, it would be helpful to have
this corrected. Any idea where I should be looking to fix this?
[Bug c/92324] New: ice in expand_direct_optab_fn, at internal-fn.c:2890
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92324
Bug ID: 92324
Summary: ice in expand_direct_optab_fn, at internal-fn.c:2890
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
This source code, with recent gcc trunk and compiler flag -O3,
unsigned a, b;
int c, d;
unsigned e(int f) {
if (a > f)
return a;
return f;
}
void g() {
for (; c; c++)
d = e(d);
b = d;
}
does this:
during RTL pass: expand
bug556.c: In function ‘g’:
bug556.c:8:6: internal compiler error: in expand_direct_optab_fn, at
internal-fn.c:2890
8 | void g() {
| ^
0x64ffc8 expand_direct_optab_fn
../../trunk/gcc/internal-fn.c:2890
0x936ec7 expand_call_stmt
../../trunk/gcc/cfgexpand.c:2640
0x936ec7 expand_gimple_stmt_1
../../trunk/gcc/cfgexpand.c:3710
0x936ec7 expand_gimple_stmt
../../trunk/gcc/cfgexpand.c:3875
[Bug tree-optimization/92323] bogus -Warray-bounds after unrolling despite __builtin_unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92323 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=92039 --- Comment #1 from Martin Sebor --- The loop uses a similar idiom as in pr92039.
[Bug tree-optimization/92323] New: bogus -Warray-bounds after unrolling despite __builtin_unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92323
Bug ID: 92323
Summary: bogus -Warray-bounds after unrolling despite
__builtin_unreachable
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
With the -Warray-bounds enhancement for pr91647, GCC issues a warning for the
unrolled loop in function f() below. No warning is issued for g(). The loop
in f() is unrolled but it results in pointless tests for the conditions that
the subsequent __builtin_unreachable call should obviate. The loop in g() is
transformed into a call to memmove which also seems suboptimal.
The code in f() was reduced from try_conditional_simplification() in
gimple-match-head.c.
$ cat z.c && gcc -O2 -S -Wall z.c
struct S { int a[5]; } s;
void sink (void*);
void f (unsigned n, struct S *p)
{
for (unsigned i = 1; i < n - 1; ++i)
s.a[i - 1] = p->a[i]; // bogus warning
if (n < 4 || n > 5)
__builtin_unreachable ();
}
void g (unsigned n, struct S *p)
{
if (n < 4 || n > 5)
__builtin_unreachable ();
for (unsigned i = 1; i < n - 1; ++i)
s.a[i - 1] = p->a[i];
}
z.c: In function ‘f’:
z.c:8:22: warning: array subscript 5 is above array bounds of ‘int[5]’
[-Warray-bounds]
8 | s.a[i - 1] = p->a[i]; // bogus warning
| ^~~
z.c:1:16: note: while referencing ‘a’
1 | struct S { int a[5]; } s;
|^
[Bug other/92121] Error using GCC 4.9.4 -- arch/x86/Makefile:166: *** CONFIG_RETPOLINE=y,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92121 Andrew Pinski changed: What|Removed |Added CC||afernandez at odyhpc dot com --- Comment #7 from Andrew Pinski --- *** Bug 92322 has been marked as a duplicate of this bug. ***
[Bug target/92322] Compilation (of gdrcopy) in cloud environments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92322 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #2 from Andrew Pinski --- My bet it is not picking up GCC 8.3.0 but an older version of the compiler. AGain this is not a compiler issue. *** This bug has been marked as a duplicate of bug 92121 ***
[Bug target/92322] Compilation (of gdrcopy) in cloud environments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92322 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c++ |target Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- The problem is not related to compiler directly but rather the compiler version that is being used does not support RETPOLINE but the kernel config you are using says to enable it. THIS IS NOT a compiler issue.
[Bug c++/92322] New: Compilation (of gdrcopy) in cloud environments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92322 Bug ID: 92322 Summary: Compilation (of gdrcopy) in cloud environments Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: afernandez at odyhpc dot com Target Milestone: --- Compilation (of gdrcopy) in cloud environments Hello, I've been trying to compile gdrcopy (https://github.com/NVIDIA/gdrcopy) in cloud environments but keep running into the same issue. The compilation is pretty standard: cd ~/gdrcopy sudo chmod +x config_arch make CUDA=/usr/local/cuda-10.1 all but the error message reads: GDRAPI_ARCH=X86 cd src/gdrdrv && \ make make[1]: Entering directory `/home/ody/gdrcopy/src/gdrdrv' Picking NVIDIA driver sources from NVIDIA_SRC_DIR=/usr/src/nvidia-418.87.00/nvidia. If that does not meet your expectation, you might have a stale driver still around and that might cause problems. make[2]: Entering directory `/usr/src/kernels/3.10.0-1062.4.1.el7.x86_64' arch/x86/Makefile:166: *** CONFIG_RETPOLINE=y, but not supported by the compiler. Compiler update recommended.. Stop. make[2]: Leaving directory `/usr/src/kernels/3.10.0-1062.4.1.el7.x86_64' make[1]: *** [module] Error 2 make[1]: Leaving directory `/home/ody/gdrcopy/src/gdrdrv' make: *** [driver] Error 2 The compiler version is 8.3.0 (began the installation with 9.2.0 but the CUDA toolkit doesn't take it yet) where RETPOLINE is obviously fine. I opened a case with the gdrcopy team and the full thread can be read at https://github.com/NVIDIA/gdrcopy/issues/93. My conclusion then, and now because the problem has resurfaced with Azure, is that the hypervisor is either interfering or the virtualization is preventing something from working together. Has anyone seen any similar issue or has any suggestion on what to try? Thanks.
[Bug fortran/92321] New: GCC 9.2.0 ICE: fexternal-blas with optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92321 Bug ID: 92321 Summary: GCC 9.2.0 ICE: fexternal-blas with optimization Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: bugreports.nwukie at gmail dot com Target Milestone: --- I experience an ICE with gfortran 9.2.0 compiling a matmul call within a subroutine using -fexternal-blas and -O3. Compiling without -fexternal-blas the compilation completes without failing. It looks like there were some recent modifications related to matmul optimizations that went into GCC9 as mentioned in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29550 INPUT: (test.f90) module mod_badmatmul implicit none contains subroutine test(c) real, intent(inout) :: c(3,3) real :: a(3,3), b(3,3) c = matmul(a, b) end subroutine test end module mod_badmatmul program main use mod_badmatmul, only: test implicit none real :: a(3,3) call test(a) end program main COMPILE LINE: gfortran -fexternal-blas -O3 test.f90 OUTPUT: f951: internal compiler error: in gfc_enforce_clean_symbol_state, at fortran/symbol.c:4273 libbacktrace could not find executable to open SYSTEM: OSX 10.14.6 Target: x86_64-apple-darwin18.7.0 Configured with: ./configure --enable-languages=c,c++,fortran Thread model: posix gcc version 9.2.0 (GCC) GNU Fortran (GCC) version 9.2.0 (x86_64-apple-darwin18.7.0) compiled by GNU C version 9.2.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP GNU Fortran2008 (GCC) version 9.2.0 (x86_64-apple-darwin18.7.0) compiled by GNU C version 9.2.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP
[Bug d/87818] D runtime does not build on FreeBSD.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87818 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-01 Ever confirmed|0 |1 --- Comment #4 from Rainer Orth --- As it happens, I ran into the same issue myself during an --enable-libphobos build on amd64-pc-freebsd12.0. Given that libphobos already *does* support FreeBSD, I gave the attached patch a try. Initially, I ran an --enable-multilib build, but that failed for the 32-bit multilib in two places: /vol/gcc/src/hg/trunk/freebsd/libphobos/src/std/math.d:1813:13: error: static as sert "Not implemented for this architecture" 1813 | static assert(0, "Not implemented for this architecture"); | /vol/gcc/src/hg/trunk/freebsd/libphobos/src/std/internal/math/gammafunction.d:259:5: error: static assert "missing MAXGAMMA for other real types" The reason is the same in both cases, but I didn't look long for what's going on here (the 32-bit multilib *does* work on Solaris/x86 and Linux/x86_64, so there's nothing fundamental here). With only the 64-bit multilib, test results for gdc and libphobos aren't too bad: === libphobos tests === Running target unix FAIL: libphobos.phobos/std/base64.d execution test FAIL: libphobos.phobos/std/datetime/systime.d execution test FAIL: libphobos.phobos/std/datetime/timezone.d execution test FAIL: libphobos.phobos/std/experimental/allocator/building_blocks/stats_collector.d execution test FAIL: libphobos.phobos/std/experimental/logger/core.d execution test FAIL: libphobos.phobos/std/experimental/logger/filelogger.d execution test FAIL: libphobos.phobos/std/experimental/logger/multilogger.d execution test FAIL: libphobos.phobos/std/file.d execution test FAIL: libphobos.phobos/std/mmfile.d execution test FAIL: libphobos.phobos/std/net/curl.d execution test FAIL: libphobos.phobos/std/parallelism.d execution test FAIL: libphobos.phobos/std/process.d execution test FAIL: libphobos.phobos/std/range/package.d execution test FAIL: libphobos.phobos/std/socket.d execution test FAIL: libphobos.phobos/std/stdio.d execution test FAIL: libphobos.phobos/std/zip.d execution test FAIL: libphobos.phobos_shared/std/base64.d execution test FAIL: libphobos.phobos_shared/std/datetime/systime.d execution test FAIL: libphobos.phobos_shared/std/datetime/timezone.d execution test FAIL: libphobos.phobos_shared/std/experimental/allocator/building_blocks/stats_collector.d execution test FAIL: libphobos.phobos_shared/std/experimental/logger/core.d execution test FAIL: libphobos.phobos_shared/std/experimental/logger/filelogger.d execution test FAIL: libphobos.phobos_shared/std/experimental/logger/multilogger.d execution test FAIL: libphobos.phobos_shared/std/file.d execution test FAIL: libphobos.phobos_shared/std/mmfile.d execution test FAIL: libphobos.phobos_shared/std/net/curl.d execution test FAIL: libphobos.phobos_shared/std/parallelism.d execution test FAIL: libphobos.phobos_shared/std/process.d execution test FAIL: libphobos.phobos_shared/std/range/package.d execution test FAIL: libphobos.phobos_shared/std/socket.d execution test FAIL: libphobos.phobos_shared/std/stdio.d execution test FAIL: libphobos.phobos_shared/std/zip.d execution test === libphobos Summary === # of expected passes724 # of unexpected failures32 === gdc tests === Running target unix FAIL: gdc.dg/lto/ltotests d_lto_ltotests_0.o-d_lto_ltotests_1.o link, -O0 -flto -flto-partition=none -fuse-linker-plugin (internal compiler error) FAIL: gdc.dg/lto/ltotests d_lto_ltotests_0.o-d_lto_ltotests_1.o link, -O2 -flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects (internal compiler error) FAIL: gdc.dg/lto/ltotests d_lto_ltotests_0.o-d_lto_ltotests_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin (internal compiler error) FAIL: gdc.dg/lto/ltotests d_lto_ltotests_0.o-d_lto_ltotests_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin (internal compiler error) FAIL: gdc.dg/lto/ltotests d_lto_ltotests_0.o-d_lto_ltotests_1.o link, -O0 -flto -fuse-linker-plugin -fno-fat-lto-objects (internal compiler error) FAIL: gdc.dg/lto/ltotests d_lto_ltotests_0.o-d_lto_ltotests_1.o link, -O2 -flto -fuse-linker-plugin (internal compiler error) FAIL: gdc.test/compilable/test5227.d (internal compiler error) FAIL: gdc.test/compilable/test5227.d output-exists test5227.o UNRESOLVED: gdc.test/runnable/dhry.d compilation failed to produce executable UNRESOLVED: gdc.test/runnable/dhry.d -shared-libphobos compilation failed to produce executable FAIL: gdc.test/runnable/eh.d execution test FAIL: gdc.test/runnable/eh.d -fPIC execution test FAIL: gdc.test/runnable/eh.d -shared-libphobos execution test FAIL:
[Bug d/87818] D runtime does not build on FreeBSD.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87818 Rainer Orth changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #3 from Rainer Orth --- Created attachment 47154 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47154=edit Initial patch
[Bug lto/91027] [10 regression] SEGV in hash_table::find_slot_with_hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91027 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #3 from Jan Hubicka --- > Hi, > this patch triggers another confusion in ipa-devirt. > It tries to build type inheritnace graph but since D frotnend produces > only functions with DECL_VIRTUAL but no BINFOs and other things it > segfaults eventually. > > Working around it makes it to work. So this adds new question why D > frontend needs to set DECL_VIRTUAL? I've finally managed to try this patch on sparc-sun-solaris2.11. It turns the previous SEGV into an ICE: during IPA pass: pure-const lto1: internal compiler error: in get_odr_type, at ipa-devirt.c:1908 0x715763 get_odr_type(tree_node*, bool) /vol/gcc/src/hg/trunk/local/gcc/ipa-devirt.c:1908 0x71a5a3 build_type_inheritance_graph() /vol/gcc/src/hg/trunk/local/gcc/ipa-devirt.c:2255 0x75f723 symbol_table::remove_unreachable_nodes(__FILE*) /vol/gcc/src/hg/trunk/local/gcc/ipa.c:319 0x414387 read_cgraph_and_symbols(unsigned int, char const**) /vol/gcc/src/hg/trunk/local/gcc/lto/lto-common.c:2906 0x3f7513 lto_main() /vol/gcc/src/hg/trunk/local/gcc/lto/lto.c:624
[Bug c++/92320] New: Constexpr function pointer derived from lambda is not accepted as template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92320
Bug ID: 92320
Summary: Constexpr function pointer derived from lambda is not
accepted as template parameter
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jleahy+gcc at gmail dot com
Target Milestone: ---
The following code is not accepted by the compiler, whereas I believe it is
well-formed according to the standard:
template
void templ() {}
void foo() {
constexpr auto * a = +[](){};
templ();
}
Here is a less condensed version that demonstrates a number of similar
circumstances: (only the very last case is rejected by GCC)
template
void templ() {}
void dummy(){}
void foo() {
constexpr int a = 7 + 3;
templ();
templ();
typedef void(FPtr)();
constexpr FPtr * b =
templ();
constexpr FPtr * c = [](){};
templ();
}
Generally speaking it seems that GCC is perfectly happy instantiating a
template with a constexpr (as you would hope) and with a constexpr function
pointer even, but only if that function pointer derives from a free function.
If a constexpr function pointer derives from the constexpr conversion of a
lambda to a function pointer than GCC rejects the code with an error like the
below:
error: 'foo()_FUN' is not a valid template argument for type
'void (*)()' because 'static constexpr void foo()_FUN()' has no
linkage
This code is accepted by clang.
[Bug fortran/92113] [8/9/10 regression] r276673 causes segfault in gfortran.dg/pr51434.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92113 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED Component|middle-end |fortran
[Bug fortran/90988] Wrong error message with variables named "PUBLIC*"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90988 --- Comment #3 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Nov 1 16:27:38 2019 New Revision: 277714 URL: https://gcc.gnu.org/viewcvs?rev=277714=gcc=rev Log: 2019-11-01 Steven G. Kargl PR fortran/90988 * decl.c (gfc_match_private, gfc_match_public): Fixed-form source code does not require whitespace between PRIVATE (or PUBLIC) and an entity. 2019-11-01 Steven G. Kargl PR fortran/90988 * gfortran.dg/pr90988_4.f: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr90988_4.f Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog
[Bug lto/70929] [7/8/9/10 regression] Cross-module inlining for functions having argument passed by reference is no longer working.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70929 --- Comment #14 from Martin Jambor --- I sent a more detailed analysis of the behavior of gimple_call_types_likely_match_p and the idea from comment #5 along with a patch that mostly removes the predicate to the mailing list: https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00016.html
[Bug middle-end/92113] [8/9/10 regression] r276673 causes segfault in gfortran.dg/pr51434.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92113
--- Comment #7 from Thomas Koenig ---
I had thought that this patch
Index: trans-decl.c
===
--- trans-decl.c(Revision 277486)
+++ trans-decl.c(Arbeitskopie)
@@ -1911,14 +1911,6 @@
if (sym->attr.associate_var)
GFC_DECL_ASSOCIATE_VAR_P (decl) = 1;
- /* We no longer mark __def_init as read-only so it does not take up
- space in the read-only section and dan go into the BSS instead,
- see PR 84487. Marking this as artificial means that OpenMP will
- treat this as predetermined shared. */
- if (sym->attr.vtab
- || (sym->name[0] == '_' && gfc_str_startswith (sym->name,
"__def_init")))
-DECL_ARTIFICIAL (decl) = 1;
-
return decl;
}
Index: trans-openmp.c
===
--- trans-openmp.c (Revision 277486)
+++ trans-openmp.c (Arbeitskopie)
@@ -119,11 +119,24 @@
enum omp_clause_default_kind
gfc_omp_predetermined_sharing (tree decl)
{
+ const char *name;
+ name = IDENTIFIER_POINTER (DECL_NAME (decl));
+
+ /* These variables are artificial, and need to be shared for OpenMP.
+ See PR 84487 and PR 92113. */
+
+ if (name[0] == '_')
+{
+ if (gfc_str_startswith (name, "__vtab") || strstr (name, "__def_init"))
+ return OMP_CLAUSE_DEFAULT_SHARED;
+}
+
/* Associate names preserve the association established during ASSOCIATE.
As they are implemented either as pointers to the selector or array
descriptor and shouldn't really change in the ASSOCIATE region,
this decl can be either shared or firstprivate. If it is a pointer,
use firstprivate, as it is cheaper that way, otherwise make it shared.
*/
+
if (GFC_DECL_ASSOCIATE_VAR_P (decl))
{
if (TREE_CODE (TREE_TYPE (decl)) == POINTER_TYPE)
would help, but apparently not - still segfaults on POWER.
So, it seems that it is the absence of DECL_READONLY, and not
the presence of DECL_ARTIFICIAL, that is the problem.
[Bug c++/92319] New: Macro expansion using the __VAOPT__ construct is incorrect when the variadic argument expands to nothing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92319 Bug ID: 92319 Summary: Macro expansion using the __VAOPT__ construct is incorrect when the variadic argument expands to nothing Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: eldlistmailingz at tropicsoft dot com Target Milestone: --- When the variadic arguments of a macro whose replacement lists uses the __VA_OPT__ construct expand to nothing the gcc implementation is incorrect. As an example from n4835 15.6.1 paragraph 3 shows: #define F(...) f(0 __VA_OPT__(,) __VA_ARGS__) #define EMP F(EMP) should expand to the exact same thing as F(), which is f(0). But in gcc, while F() expands to f(0), F(EMP) expands to f(0,). If you need a program which shows this incorrect expansion I can supply one for you but you should be able to see this for yourself pretty easily.
[Bug c++/92236] [concepts] Explain non-satisfaction in static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92236 --- Comment #5 from Jason Merrill --- Created attachment 47153 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47153=edit sketch of late evaulation something like this. not continuing to work on it.
[Bug c++/92236] [concepts] Explain non-satisfaction in static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92236 --- Comment #4 from Jason Merrill --- (In reply to Andrew Sutton from comment #2) > This is tricky because the condition reduces to true/false before the static > assertion evaluates it. We could introduce a new binary expression that > stores the original expression and it's computed value, and use that to hook > into diagnostics from the static assert. Can we avoid reducing concept checks in finish_id_expression_1? constexpr evaluation already handles them, I'd think we would just need to also handle them in fold or genericize or gimplify.
[Bug c++/92236] [concepts] Explain non-satisfaction in static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92236 --- Comment #3 from Jonathan Wakely --- Another idea would be to add a new flag which chooses between brief and verbose explanations of satisfaction failure during overload resolution. By default just say that an overload isn't viable because type X doesn't satisfy std::forward_iterator, but with -fsatisfy-me-harder show that it doesn't satisfy forward_iterator because it doesn't satisfy input_iterator because it doesn't satisfy readable because common_reference_t is an invalid type. That would allow you to debug unexpected satisfaction failures without having to edit the code to add a static_assert. The currently-commented-out code that replays the substitution could be controlled by that new flag.
[Bug sanitizer/90589] In Fedora 30 ps hangs using address sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90589 --- Comment #10 from Martin Liška --- @Jakub: Can you please take a look?
[Bug target/92287] Mismatches in the calling convention for zero sized types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92287 --- Comment #10 from Jozef Lawrynowicz --- (In reply to gnzlbg from comment #9) > > @josef > > > The MSP430 ABI is here: http://www.ti.com/lit/an/slaa534/slaa534.pdf > Although confusingly that document is wrong regarding passing structures and > unions by reference. As I mentioned before, structures and unions are always > passed by reference, regardless of size. > > Can you expand on this? That document says that aggregates smaller than > 32-bit are passed in registers. We were trying to update our code > documentation to cite the ABI specs and realized this. Do you have a link to > where the current behavior is specified? I think the ABI used to be correct regarding this, but then an optimization was added to the TI compiler to always passes structures/unions by registers. At least this is what I gleaned from searching the TI forums. In the past TI also confirmed to me directly that that structs/unions should always be passed by reference. I'll see if I can get them to update the ABI. If you are curious about what any back-end is trying to do regarding passing/returning by reference you could always check the implementation of TARGET_PASS_BY_REFERENCE or TARGET_RETURN_IN_MEMORY.
[Bug c++/83083] c++2a concepts without -fconcepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83083 Hannes Hauswedell changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Hannes Hauswedell --- fixed by current trunk
[Bug sanitizer/90589] In Fedora 30 ps hangs using address sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90589 --- Comment #9 from mccannd at uk dot ibm.com --- Still failing when I try the same in Fedora 31.
[Bug tree-optimization/92317] [10 Regression] ICE in slpeel_duplicate_current_defs_from_edges, at tree-vect-loop-manip.c:960 since r277569
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92317 --- Comment #2 from avieira at gcc dot gnu.org --- Actually upon a second look it has nothing to do with that, that get_loop_body doesn't make much sense there anyways. I believe that should have just been 'loop' as slpeel_tree_duplicate_loop_to_edge_cfg creates a copy of LOOP from LOOP if LOOP == SCALAR_LOOP. The problem here lies with using SCALAR_LOOP for an epilogue... not quite sure what is wrong though.
[Bug rtl-optimization/92281] Inconsistent canonicalization of (minus (minus A B) C)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92281 --- Comment #5 from Richard Earnshaw --- (In reply to Segher Boessenkool from comment #4) > (In reply to Richard Earnshaw from comment #2) > > Yes, but since > > (A - B) - C = A - B - C = A - C - B = (A - C) - B > > we can clearly swap the order of the two RHS operands here. > > My intent was to show the two rtx shapes, and that neither is a defined > canonical form. > > > This would be > > a special rule similar to the rules that we have that rewrite > > A - (B + C) > > as > > (A - B) - C. > > That isn't a canonical form, either! Not according to the documentation, > anyway. > What I've shown is equivalent to (minus (minus (A) (B)) (C)), which is what combine produces today. Are you saying that the documentation disagrees on the overall shape of this and the compilers output right now? > > My suggestion would be that we should have a rule here that re-orders things > > so > > that B is the most 'complex' operation and C the simplest, using the normal > > precedence ordering (complex > REG > CONST). > > But minus isn't commutative, and reordering with minus introduces negs which > is wrong (it is canonical to *remove* such negs). > Minus isn't commutative, but in a 3-way version (A - B - C), the order of B and C does not matter. ... - B - C is the same as ... - C - B. So you can re-order the nesting to produce a canonical form. > > > What targets would it break, and how? > > > > Hard to tell, until we try it. Mostly the 'breakage' would be some combine > > patterns might no-longer match if the target only had one and the ordering > > were not canonical (leading to some missed optimizations). On targets that > > have both orderings, some patterns might become redundant and never match > > unless directly generated by the back-end. > > The breakage will be that many targets optimise worse than they did before. > And this is non-obvious to detect, usually. At present it's entirely random, since there's no attempt to create order. Any matching that does occur is more by good luck (or overkill in providing all the redundant variant forms). > > > > What makes combine come up with something else for these two cases? > > > > Sorry, I don't understand what you're asking here? Why does it produce > > these two separate canoncializations in one compilation? I've no idea, > > hence the bug report. > > A lot of what combine does is *not* canonicalisation. But combine comes up > with only one result for every attempted combination, making that a kind-of > de-facto canonicalisation. > > And yes, that is what I asked: in both cases it combined the same insn with > a simple pseudo move, in both cases on the RHS in that insn. And it came > up with different results. > > This may be unavoidable, or combine does something weird, or the RTL that > combine started with was non-canonical or unexpected in some other way, etc. > > So I'd like to know where the difference was introduced. Was it in combine > at all, to start with? It can be in simplify-rtx as well for example. Combine is the prime user of simplify-rtx - perhaps I'm conflating the two, but this is, in part, combine's problem because it's during the combine pass that having matchers for all these variants becomes most important.
[Bug tree-optimization/92317] [10 Regression] ICE in slpeel_duplicate_current_defs_from_edges, at tree-vect-loop-manip.c:960 since r277569
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92317 --- Comment #1 from avieira at gcc dot gnu.org --- Confirmed. It seems get_loop_copy is returning NULL. I'm looking into it.
[Bug fortran/92318] New: Nondeterministic ICE with -mcmodel=large -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92318 Bug ID: 92318 Summary: Nondeterministic ICE with -mcmodel=large -O2 Product: gcc Version: 7.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jellby at yahoo dot com Target Milestone: --- Compiling this Fortran code with -mcmodel=large -O2 segfaults intermittently: subroutine diffeq (nvar,y,x1,x2,eps,h1,gvalue) implicit none real*8, parameter :: tiny=1.0d-30 integer i,nvar,nstep,maxstep real*8 x,x1,x2,h,h1,eps,hnext,hdid,y(*) real*8, allocatable :: dydx(:),yscal(:) logical terminate external gvalue terminate = .false. h = sign(h1,x2-x1) nstep = 0 maxstep = 100 allocate (dydx(nvar)) allocate (yscal(nvar)) do while (.not. terminate) do i = 1, nvar yscal(i) = abs(y(i)) + abs(h*dydx(i)) + tiny end do call bsstep (nvar,x,dydx,y,h,eps,yscal,hdid,hnext,gvalue) h = hnext nstep = nstep + 1 if (nstep .ge. maxstep) then terminate = .true. end if end do deallocate (dydx) deallocate (yscal) end $ /usr/bin/gfortran -c -mcmodel=large diffeq.f -o diffeq.o -O2 $ /usr/bin/gfortran -c -mcmodel=large diffeq.f -o diffeq.o -O2 diffeq.f:29:0: end internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. $ /usr/bin/gfortran -c -mcmodel=large diffeq.f -o diffeq.o -O2 $ /usr/bin/gfortran -c -mcmodel=large diffeq.f -o diffeq.o -O2 $ /usr/bin/gfortran --version GNU Fortran (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.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.
[Bug ipa/92074] [10 regression] 26% performance regression on Spec2017 548.exchange2_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92074 Kewen Lin changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #8 from Kewen Lin --- Closed it.
[Bug testsuite/92127] [10 regression] gcc.dg/vect/costmodel/ppc/costmodel-fast-math-vect-pr29925.c fails after r276645 on power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92127 Kewen Lin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Kewen Lin --- Test case fix has been committed.
[Bug bootstrap/92314] [10 regression] missing omp-device-properties', needed by 's-omp-device-properties-h'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92314 --- Comment #7 from Jakub Jelinek --- I'd suggest once you build the --enable-as-accelerator-for= compiler, install it in whatever temporary location you pick and then use nvptx-none=/path/to/that so that it can find it.
[Bug bootstrap/92314] [10 regression] missing omp-device-properties', needed by 's-omp-device-properties-h'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92314 Martin Liška changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #6 from Martin Liška --- Richi, we are suffering from this issue in our gcc10 package. Do you have any idea how can we fix that?
[Bug bootstrap/92316] [10 Regression] --enable-offload-targets=nvptx-none leads to build error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92316 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Martin Liška --- Yes, that would be a duplicate then. *** This bug has been marked as a duplicate of bug 92314 ***
[Bug bootstrap/92314] [10 regression] missing omp-device-properties', needed by 's-omp-device-properties-h'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92314 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #5 from Martin Liška --- *** Bug 92316 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/92317] New: [10 Regression] ICE in slpeel_duplicate_current_defs_from_edges, at tree-vect-loop-manip.c:960 since r277569
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92317
Bug ID: 92317
Summary: [10 Regression] ICE in
slpeel_duplicate_current_defs_from_edges, at
tree-vect-loop-manip.c:960 since r277569
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: avieira at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux-gnu
Target: aarch64-linux-gnu
Using aarch64 cross compiler one can see:
$ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/opt/pr87967.C
-O2 -fno-tree-pre -c -ftree-vectorize --param vect-epilogues-nomask=1
during GIMPLE pass: vect
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/opt/pr87967.C: In function
‘void fn3()’:
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/opt/pr87967.C:30:6: internal
compiler error: in slpeel_duplicate_current_defs_from_edges, at
tree-vect-loop-manip.c:960
30 | void fn3() {
| ^~~
0x173a226 slpeel_duplicate_current_defs_from_edges
../../gcc/tree-vect-loop-manip.c:960
0x173a68c slpeel_tree_duplicate_loop_to_edge_cfg(loop*, loop*, edge_def*)
../../gcc/tree-vect-loop-manip.c:1056
0x173f085 vect_do_peeling(_loop_vec_info*, tree_node*, tree_node*, tree_node**,
tree_node**, tree_node**, int, bool, bool, tree_node**,
auto_vec, 0ul>&)
../../gcc/tree-vect-loop-manip.c:2674
0x172f50a vect_transform_loop(_loop_vec_info*)
../../gcc/tree-vect-loop.c:8273
0x17596a5 try_vectorize_loop_1
../../gcc/tree-vectorizer.c:990
0x175989b try_vectorize_loop_1
../../gcc/tree-vectorizer.c:1027
0x1759967 try_vectorize_loop
../../gcc/tree-vectorizer.c:1045
0x1759b40 vectorize_loops()
../../gcc/tree-vectorizer.c:1127
0x15d7b3d execute
../../gcc/tree-ssa-loop.c:414
[Bug tree-optimization/92317] [10 Regression] ICE in slpeel_duplicate_current_defs_from_edges, at tree-vect-loop-manip.c:960 since r277569
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92317 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-01 CC||rguenth at gcc dot gnu.org Known to work||9.2.0 Target Milestone|--- |10.0 Ever confirmed|0 |1 Known to fail||10.0
[Bug bootstrap/92316] [10 Regression] --enable-offload-targets=nvptx-none leads to build error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92316 --- Comment #1 from Jakub Jelinek --- Dup of PR92314? The offloading compiler needs to be installed, when using the nvptx-none=/path form it needs to be under that /path root.
[Bug bootstrap/92316] New: [10 Regression] --enable-offload-targets=nvptx-none leads to build error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92316 Bug ID: 92316 Summary: [10 Regression] --enable-offload-targets=nvptx-none leads to build error Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- I can't build a compiler with offloading capability: $ ~/Programming/gcc/configure --enable-languages=c,c++,fortran,lto --prefix=/home/marxin/bin/gcc --disable-multilib --disable-libsanitizer --disable-bootstrap --enable-offload-targets=nvptx-none=/usr/nvptx-none --without-cuda-driver ... $ make ... make[2]: Entering directory '/dev/shm/objdir2/zlib' true "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CFLAGS=-g -O2" "CXXFLAGS=-g -O2" "CFLAGS_FOR_BUILD=-g -O2" "CFLAGS_FOR_TARGET=-g -O2" "INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_SCRIPT=/usr/bin/install -c" "LDFLAGS=-static-libstdc++ -static-libgcc " "LIBCFLAGS=-g -O2" "LIBCFLAGS_FOR_TARGET=-g -O2" "MAKE=make" "MAKEINFO=makeinfo --split-size=500 --split-size=500 " "PICFLAG=" "PICFLAG_FOR_TARGET=" "SHELL=/bin/sh" "EXPECT=expect" "RUNTEST=runtest" "RUNTESTFLAGS=" "exec_prefix=/home/marxin/bin/gcc" "infodir=/home/marxin/bin/gcc/share/info" "libdir=/home/marxin/bin/gcc/lib64" "prefix=/home/marxin/bin/gcc" "tooldir=/home/marxin/bin/gcc/x86_64-pc-linux-gnu" "AR=ar" "AS=as" "CC=gcc" "CXX=g++" "LD=/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld" "LIBCFLAGS=-g -O2" "NM=nm" "PICFLAG=" "RANLIB=ranlib" "DESTDIR=" DO=all multi-do # make make[2]: Leaving directory '/dev/shm/objdir2/zlib' make[2]: Entering directory '/dev/shm/objdir2/libbacktrace' make all-am make[3]: Entering directory '/dev/shm/objdir2/libbacktrace' true DO=all multi-do # make make[3]: Leaving directory '/dev/shm/objdir2/libbacktrace' make[2]: Leaving directory '/dev/shm/objdir2/libbacktrace' make[2]: Entering directory '/dev/shm/objdir2/libcpp' test -f config.h || (rm -f stamp-h1 && make stamp-h1) make[2]: Leaving directory '/dev/shm/objdir2/libcpp' make[2]: Entering directory '/dev/shm/objdir2/libdecnumber' make[2]: Nothing to be done for 'all'. make[2]: Leaving directory '/dev/shm/objdir2/libdecnumber' make[2]: Entering directory '/dev/shm/objdir2/gcc' make[2]: *** No rule to make target '/usr/nvptx-none/lib/gcc/x86_64-pc-linux-gnu/10.0.0/accel/nvptx-none/omp-device-properties', needed by 's-omp-device-properties-h'. Stop. make[2]: Leaving directory '/dev/shm/objdir2/gcc' make[1]: *** [Makefile:4359: all-gcc] Error 2 make[1]: Leaving directory '/dev/shm/objdir2' make: *** [Makefile:958: all] Error 2
[Bug bootstrap/92316] [10 Regression] --enable-offload-targets=nvptx-none leads to build error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92316 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-01 Known to work||9.2.0 Target Milestone|--- |10.0 Ever confirmed|0 |1 Known to fail||10.0
[Bug bootstrap/92301] [10 Regression] Wrong vectorizer code since r277566
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92301 Martin Liška changed: What|Removed |Added Keywords|needs-reduction |wrong-code Priority|P3 |P1 Known to work||9.2.0 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |10.0 Summary|bootstrap internal compiler |[10 Regression] Wrong |error: Aborted free(): |vectorizer code since |invalid next size (fast)|r277566 Known to fail||10.0
[Bug bootstrap/92314] [10 regression] missing omp-device-properties', needed by 's-omp-device-properties-h'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92314 --- Comment #4 from Dmitry G. Dyachenko --- Thank for clarification. Sorry for noise
[Bug bootstrap/92314] [10 regression] missing omp-device-properties', needed by 's-omp-device-properties-h'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92314 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Jakub Jelinek --- (In reply to Dmitry G. Dyachenko from comment #2) > I use system compiler for bootstrap: gcc9/Fedora31 > > Did I understood you correctly: I need offloading compiler installed after > r277662 if I say '--enable-offload-targets=nvptx-none' ? > > so invalid PR? You needed it always, see http://gcc.gnu.org/wiki/Offloading . Furthermore, the installed offloading compiler needs to be the same gcc snapshot (or at least almost, so that the LTO in between is compatible among other things). Previously one would run into issues only during testing though.
[Bug bootstrap/92314] [10 regression] missing omp-device-properties', needed by 's-omp-device-properties-h'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92314 --- Comment #2 from Dmitry G. Dyachenko --- I use system compiler for bootstrap: gcc9/Fedora31 Did I understood you correctly: I need offloading compiler installed after r277662 if I say '--enable-offload-targets=nvptx-none' ? so invalid PR?
[Bug libgomp/92315] [10 regression] libgomp.c/pr58392.c and several others FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92315 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-01 CC||avieira at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Yes, this broke with r277659 on other targets too.
[Bug bootstrap/92314] [10 regression] missing omp-device-properties', needed by 's-omp-device-properties-h'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92314
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
Do you have the offloading compiler installed in
/usr/local/gcc_current/lib{,exec}/gcc/... ?
Is it a recent version (r277662 or later)?
If it is installed, but say with a special DESTDIR or with different prefix at
install time, one needs to configure
--enable-offloading-targets=nvptx-none=/whatever/path/the/nvptx-none/compiler/is/installed/at/
[Bug libgomp/92315] New: [10 regression] libgomp.c/pr58392.c and several others FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92315 Bug ID: 92315 Summary: [10 regression] libgomp.c/pr58392.c and several others FAIL Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- Target: i386-pc-solaris2.11 Between 20191030 (r277634) and 20191031 (r277679), quite a number of libgomp tests began to FAIL on 64-bit Solaris/x86: +FAIL: libgomp.c++/../libgomp.c-c++-common/loop-1.c execution test +FAIL: libgomp.c++/simd-8.C execution test +FAIL: libgomp.c/../libgomp.c-c++-common/loop-1.c execution test +FAIL: libgomp.c/pr58392.c execution test +FAIL: libgomp.c/scan-19.c execution test +FAIL: libgomp.c/scan-20.c execution test +FAIL: libgomp.c/simd-10.c execution test +FAIL: libgomp.c/simd-12.c execution test +FAIL: libgomp.c/simd-13.c execution test +FAIL: libgomp.c/simd-6.c execution test +FAIL: libgomp.fortran/nestedfn5.f90 -O1 execution test +FAIL: libgomp.fortran/nestedfn5.f90 -O2 execution test +FAIL: libgomp.fortran/nestedfn5.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test +FAIL: libgomp.fortran/nestedfn5.f90 -O3 -g execution test +FAIL: libgomp.fortran/nestedfn5.f90 -Os execution test +FAIL: libgomp.fortran/simd1.f90 -O1 execution test +FAIL: libgomp.fortran/simd1.f90 -O2 execution test +FAIL: libgomp.fortran/simd1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test +FAIL: libgomp.fortran/simd1.f90 -O3 -g execution test +FAIL: libgomp.fortran/simd1.f90 -Os execution test For example. libgomp.c/pr58392.c aborts now: Thread 2 received signal SIGABRT, Aborted. [Switching to Thread 1 (LWP 1)] 0x7fffbe877fea in __lwp_sigqueue () from /lib/64/libc.so.1 (gdb) where #0 0x7fffbe877fea in __lwp_sigqueue () from /lib/64/libc.so.1 #1 0x7fffbe86e3d2 in thr_kill () from /lib/64/libc.so.1 #2 0x7fffbe7aab6c in raise () from /lib/64/libc.so.1 #3 0x7fffbe773661 in abort () from /lib/64/libc.so.1 #4 0x0040175e in main () at /vol/gcc/src/hg/trunk/local/libgomp/testsuite/libgomp.c/pr58392.c:51
[Bug libgomp/92315] [10 regression] libgomp.c/pr58392.c and several others FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92315 Rainer Orth changed: What|Removed |Added Target Milestone|--- |10.0
[Bug bootstrap/92314] New: [10 regression] missing omp-device-properties', needed by 's-omp-device-properties-h'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92314 Bug ID: 92314 Summary: [10 regression] missing omp-device-properties', needed by 's-omp-device-properties-h' Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: dimhen at gmail dot com Target Milestone: --- r277655 PASS r277686 FAIL sounds like stage 1 issue? configure --prefix=/usr/local/gcc_current --enable-checking=yes,df,fold,rtl,extra --enable-languages=c,c++,lto --disable-multilib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --enable-cet --with-tune=native make -j4 ... make[3]: Entering directory '/home/dimhen/build/gcc_current/gcc' make[3]: *** No rule to make target '/usr/local/gcc_current/lib/gcc/x86_64-pc-linux-gnu/10.0.0/accel/nvptx-none/omp-device-properties', needed by 's-omp-device-properties-h'. Stop.
[Bug testsuite/92310] New test case gcc.dg/vect/vect-epilogues.c introduced in r277659 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92310 Rainer Orth changed: What|Removed |Added Target|powerpc64*-linux-gnu|powerpc64*-linux-gnu, ||i386-pc-solaris2.11, ||sparc-sun-solaris2.11, ||armv8l-unknown-linux-gnueab ||ihf, i686-pc-linux-gnu, ||ia64-suse-linux-gnu, ||s390x-ibm-linux-gnu Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-01 CC||ro at gcc dot gnu.org Host|powerpc64*-linux-gnu| Target Milestone|--- |10.0 Ever confirmed|0 |1 Build|powerpc64*-linux-gnu| --- Comment #1 from Rainer Orth --- Happens on many targets.just not Linux/x86_64. The Solaris failures (sparc and x86) occur both for 32 and 64-bit.
[Bug testsuite/92127] [10 regression] gcc.dg/vect/costmodel/ppc/costmodel-fast-math-vect-pr29925.c fails after r276645 on power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92127 --- Comment #4 from Kewen Lin --- Author: linkw Date: Fri Nov 1 07:11:12 2019 New Revision: 277704 URL: https://gcc.gnu.org/viewcvs?rev=277704=gcc=rev Log: 2019-11-01 Kewen Lin PR testsuite/92127 * gcc.dg/vect/costmodel/ppc/costmodel-pr37194.c: Disable unroll. * gcc.dg/vect/costmodel/ppc/costmodel-fast-math-vect-pr29925.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-fast-math-vect-pr29925.c trunk/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-pr37194.c
[Bug tree-optimization/82803] Wildly excessive calls to __tls_get_addr with optimizations enabled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82803
Kamlesh Kumar changed:
What|Removed |Added
CC||kamleshbhalui at gmail dot com
--- Comment #13 from Kamlesh Kumar ---
Consider this little tweaked testcase in comment#1
static thread_local int s;
int g() ;
int f(unsigned int c) {
int *px = + c;
while (c--)
*px += g();
return *px;
}
gcc emits single call to __tls_get_addr.
