[Bug c++/16994] [meta-bug] VLA and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16994 Bug 16994 depends on bug 91002, which changed state. Bug 91002 Summary: ICE in make_ssa_name_fn, at tree-ssanames.c:271 with VLA type in reinterpret_cast https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91002 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/88256] [7/8/9/10 Regression] ICE: Segmentation fault (in make_ssa_name_fn) with VLA cast, C++ FE missing DECL_EXPRs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88256 Eric Gallager changed: What|Removed |Added CC||ignat.loskutov at gmail dot com --- Comment #11 from Eric Gallager --- *** Bug 91002 has been marked as a duplicate of this bug. ***
[Bug c++/91002] ICE in make_ssa_name_fn, at tree-ssanames.c:271 with VLA type in reinterpret_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91002 Eric Gallager changed: What|Removed |Added Status|NEW |RESOLVED CC||egallager at gcc dot gnu.org Blocks||16994 Depends on|16994 | Resolution|--- |DUPLICATE --- Comment #4 from Eric Gallager --- Does this really require every single other bug with C++ VLAs to be fixed first before it can be closed? I think rather that the "Depends on" and "Blocks" fields are switched; so I'm correcting them now. (In reply to Arseny Solokha from comment #3) > (In reply to Richard Biener from comment #2) > > One of the many duplicates with VLAs > > missing DECL_EXPRs. > > Namely, PR88256. Closing as a dup of it then. *** This bug has been marked as a duplicate of bug 88256 *** Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16994 [Bug 16994] [meta-bug] VLA and C++
[Bug middle-end/91515] missed optimization: no tailcall for types of class MEMORY
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91515 Peter Cordes changed: What|Removed |Added CC||peter at cordes dot ca --- Comment #1 from Peter Cordes --- The real missed optimization is that GCC is returning its own incoming arg instead of returning the copy of it that create() will return in RAX. This is what blocks tailcall optimization; it doesn't "trust" the callee to return what it's passing as RDI. See https://stackoverflow.com/a/57597039/224132 for my analysis (the OP asked the same thing on SO before reporting this, but forgot to link it in the bug report.) The RAX return value tends to rarely be used, but probably it should be; it's less likely to have just been reloaded recently. RAX is more likely to be ready sooner than R12 for out-of-order exec. Either reloaded earlier (still in the callee somewhere if it's complex and/or non-leaf) or never spilled/reloaded. So we're not even gaining a benefit from saving/restoring R12 to hold our incoming RDI. Thus it's not worth the extra cost (in code-size and instructions executed), IMO. Trust the callee to return the pointer in RAX.
[Bug tree-optimization/91571] New: TBAA does not work for ao_ref created by ao_ref_init_from_ptr_and_size()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91571
Bug ID: 91571
Summary: TBAA does not work for ao_ref created by
ao_ref_init_from_ptr_and_size()
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: fxue at os dot amperecomputing.com
Target Milestone: ---
Given a SSA_NAME pointer, its type information is discarded by
ao_ref_init_from_ptr_and_size() when building an ao_ref from the pointer, thus
TBAA for this kind of ao_ref is actually disabled. Related code snippet:
else
{
gcc_assert (POINTER_TYPE_P (TREE_TYPE (ptr)));
ref->base = build2 (MEM_REF, char_type_node,
ptr, null_pointer_node);
..
}
.
ref->ref_alias_set = 0;
ref->base_alias_set = 0;
If enabled, some optimizations relying on this could produce better result.
Here is an example for IPA-CP, but not just it (others include dse,
strlen-opt).
struct A
{
int a;
};
struct B
{
int b;
};
void f2 (struct A *pa, struct B *pb)
{
...
}
void f1(int v, struct A *pa, struct B *pb)
{
pa->a = 1;
pb->b = v;
f2 (pa, pb);
}
The ao_ref for f2's argument "pa" is setup by ao_ref_init_from_ptr_and_size(),
AA can not disambiguate pa->a and pb->b due to loss of original type
information, and IPA-CP gets a conservative conclusion that constant "1"
assigned to pa->a can not reach f2(pa, pb), then misses a chance of constant
propagation.
I check uses of ao_ref_init_from_ptr_and_size(), it is mainly used in alias
analysis on function call arguments. That's better to enable TBAA in this
scenario, but not sure is there any special consideration about it?
[Bug c/91206] -Wformat doesn't warn for %hd with char parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91206 --- Comment #6 from Eric Gallager --- (In reply to Eric Gallager from comment #5) > (In reply to Nick Desaulniers from comment #4) > > Thanks for the feedback, in https://reviews.llvm.org/rL369791, Nathan made > > [unsigned] char -> [unsigned]short warn only for -Wformat-pedantic, not > > -Wformat. > > there's a request for GCC to support -Wformat-pedantic, too, in bug 67479, > so IMO this bug should stay open as a reminder to make GCC's > -Wformat-pedantic warn on this, too, once the flag is added. ...or maybe, if leaving this one closed, at least mark it as a dup of bug 67479
[Bug c/91206] -Wformat doesn't warn for %hd with char parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91206 --- Comment #5 from Eric Gallager --- (In reply to Nick Desaulniers from comment #4) > Thanks for the feedback, in https://reviews.llvm.org/rL369791, Nathan made > [unsigned] char -> [unsigned]short warn only for -Wformat-pedantic, not > -Wformat. there's a request for GCC to support -Wformat-pedantic, too, in bug 67479, so IMO this bug should stay open as a reminder to make GCC's -Wformat-pedantic warn on this, too, once the flag is added.
[Bug c++/81676] Wrong warning with unused-but-set-parameter within 'if constexpr'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81676 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Marek Polacek --- Fixed.
[Bug c/89180] [meta-bug] bogus/missing -Wunused warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89180 Bug 89180 depends on bug 81676, which changed state. Bug 81676 Summary: Wrong warning with unused-but-set-parameter within 'if constexpr' https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81676 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/81676] Wrong warning with unused-but-set-parameter within 'if constexpr'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81676 --- Comment #6 from Marek Polacek --- Author: mpolacek Date: Wed Aug 28 02:22:29 2019 New Revision: 274982 URL: https://gcc.gnu.org/viewcvs?rev=274982=gcc=rev Log: PR c++/81676 - bogus -Wunused warnings in constexpr if. * semantics.c (maybe_mark_exp_read_r): New function. (finish_if_stmt): Call it on THEN_CLAUSE and ELSE_CLAUSE. * g++.dg/cpp1z/constexpr-if31.C: New test. * g++.dg/cpp1z/constexpr-if32.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-if31.C trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-if32.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug c++/87403] [Meta-bug] Issues that suggest a new warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 Bug 87403 depends on bug 91428, which changed state. Bug 91428 Summary: Please warn on if constexpr (std::is_constant_evaluated()) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91428 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/91428] Please warn on if constexpr (std::is_constant_evaluated())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91428 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek --- Done in GCC 10.1.
[Bug c++/91428] Please warn on if constexpr (std::is_constant_evaluated())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91428 --- Comment #3 from Marek Polacek --- Author: mpolacek Date: Wed Aug 28 02:03:48 2019 New Revision: 274981 URL: https://gcc.gnu.org/viewcvs?rev=274981=gcc=rev Log: PR c++/91428 - warn about std::is_constant_evaluated in if constexpr. * cp-tree.h (decl_in_std_namespace_p): Declare. * semantics.c (is_std_constant_evaluated_p): New. (finish_if_stmt_cond): Warn about "std::is_constant_evaluated ()" in an if-constexpr. * typeck.c (decl_in_std_namespace_p): No longer static. * g++.dg/cpp2a/is-constant-evaluated9.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp2a/is-constant-evaluated9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/semantics.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/91564] [8/9/10 Regression] ICE in gimplify_expr, at gimplify.c:14147
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91564 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2019-08-28 CC||kargl at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from kargl at gcc dot gnu.org --- I have a patch.
[Bug tree-optimization/85741] [meta-bug] bogus/missing -Wformat-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85741 Bug 85741 depends on bug 91567, which changed state. Bug 91567 Summary: [10 Regression] Spurious -Wformat-overflow warnings building glibc (32-bit only) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91567 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/91567] [10 Regression] Spurious -Wformat-overflow warnings building glibc (32-bit only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91567 Martin Sebor changed: What|Removed |Added Keywords||patch Target||ilp32 Status|ASSIGNED|RESOLVED Host||lp64 Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #3 from Martin Sebor --- Patch (https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01843.html) committed in r274976. Please open new bugs for any outstanding issues in the Glibc build.
[Bug tree-optimization/91567] [10 Regression] Spurious -Wformat-overflow warnings building glibc (32-bit only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91567 --- Comment #2 from Martin Sebor --- Author: msebor Date: Tue Aug 27 23:31:44 2019 New Revision: 274976 URL: https://gcc.gnu.org/viewcvs?rev=274976=gcc=rev Log: PR tree-optimization/91567 - Spurious -Wformat-overflow warnings building glibc (32-bit only) gcc/ChangeLog: PR tree-optimization/91567 * gimple-ssa-sprintf.c (get_string_length): Handle more forms of lengths of unknown strings. * vr-values.c (vr_values::extract_range_basic): Set strlen upper bound to PTRDIFF_MAX - 2. gcc/testsuite/ChangeLog: PR tree-optimization/91567 * gcc.dg/tree-ssa/builtin-snprintf-6.c: Xfail a subset of assertions on targets other than x86_64 to work around PR 83543. * gcc.dg/tree-ssa/builtin-sprintf-warn-22.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-22.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-sprintf.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-snprintf-6.c trunk/gcc/vr-values.c
[Bug tree-optimization/83543] strlen of a local array member not optimized on some targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83543 --- Comment #7 from Martin Sebor --- Author: msebor Date: Tue Aug 27 23:31:44 2019 New Revision: 274976 URL: https://gcc.gnu.org/viewcvs?rev=274976=gcc=rev Log: PR tree-optimization/91567 - Spurious -Wformat-overflow warnings building glibc (32-bit only) gcc/ChangeLog: PR tree-optimization/91567 * gimple-ssa-sprintf.c (get_string_length): Handle more forms of lengths of unknown strings. * vr-values.c (vr_values::extract_range_basic): Set strlen upper bound to PTRDIFF_MAX - 2. gcc/testsuite/ChangeLog: PR tree-optimization/91567 * gcc.dg/tree-ssa/builtin-snprintf-6.c: Xfail a subset of assertions on targets other than x86_64 to work around PR 83543. * gcc.dg/tree-ssa/builtin-sprintf-warn-22.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-22.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-sprintf.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-snprintf-6.c trunk/gcc/vr-values.c
[Bug c++/91262] using template type parameter after typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91262 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-08-27 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1
[Bug tree-optimization/91570] [10 Regression] ICE in get_range_strlen_dynamic on a conditional of two strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91570 Martin Sebor changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-08-27 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Target Milestone|--- |10.0 Ever confirmed|0 |1
[Bug tree-optimization/91570] New: [10 Regression] ICE in get_range_strlen_dynamic on a conditional of two strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91570
Bug ID: 91570
Summary: [10 Regression] ICE in get_range_strlen_dynamic on a
conditional of two strings
Product: gcc
Version: 9.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: ---
A snprintf call with the conditional expression involving a string of known
length (zero) and another of some minimum length (at least 1) triggers an ICE
in the get_range_strlen_dynamic function newly added in r274933.
$ cat z.c && gcc -O2 -S -Wall -fdump-tree-strlen=/dev/stdout z.c
extern char a[], b[];
void f (int i)
{
a[0] = 0;
b[0] = '1';
const char *p = i ? b : a;
if (__builtin_snprintf (0, 0, "%s", p) < 4)
__builtin_abort ();
}
;; Function f (f, funcdef_no=0, decl_uid=1926, cgraph_uid=1, symbol_order=0)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2 3 4 5 6
;; 2 succs { 3 4 }
;; 3 succs { 4 }
;; 4 succs { 5 6 }
;; 5 succs { }
;; 6 succs { 1 }
z.c:10: __builtin_snprintf: objsize = 9223372036854775807, fmtstr = "%s"
Directive 1 at offset 0: "%s"
during GIMPLE pass: strlen
dump file: /dev/stdout
EMERGENCY DUMP:
f (int i)
{
int _1;
char[] * iftmp.0_2;
[local count: 1073741824]:
a[0] = 0;
b[0] = 49;
if (i_6(D) != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870912]:
[local count: 1073741824]:
# iftmp.0_2 = PHI <(2), (3)>
_1 = __builtin_snprintf (0B, 0, "%s", iftmp.0_2);
if (_1 <= 3)
goto ; [0.00%]
else
goto ; [100.00%]
[count: 0]:
__builtin_abort ();
[local count: 1073741824]:
return;
}
z.c: In function ‘f’:
z.c:3:6: internal compiler error: Segmentation fault
3 | void f (int i)
| ^
0x11c54ca crash_signal
/src/gcc/svn/gcc/toplev.c:326
0x815854 contains_struct_check(tree_node const*, tree_node_structure_enum, char
const*, int, char const*)
/src/gcc/svn/gcc/tree.h:3632
0x84e032 wi::extended_tree<192>::extended_tree(tree_node const*)
/src/gcc/svn/gcc/tree.h:5802
0x84cedf generic_wide_int >::generic_wide_int(tree_node const* const&)
/src/gcc/svn/gcc/wide-int.h:782
0x84ca19 wi::to_widest(tree_node const*)
/src/gcc/svn/gcc/tree.h:5729
0x84ca3b tree_int_cst_lt(tree_node const*, tree_node const*)
/src/gcc/svn/gcc/tree.h:5982
0x14bdde1 get_range_strlen_dynamic
/src/gcc/svn/gcc/tree-ssa-strlen.c:916
0x14be432 get_range_strlen_dynamic(tree_node*, c_strlen_data*, vr_values
const*)
/src/gcc/svn/gcc/tree-ssa-strlen.c:1037
0x2047374 get_string_length
/src/gcc/svn/gcc/gimple-ssa-sprintf.c:1980
0x204796b format_string
/src/gcc/svn/gcc/gimple-ssa-sprintf.c:2170
0x2049274 format_directive
/src/gcc/svn/gcc/gimple-ssa-sprintf.c:2730
0x204b522 compute_format_length
/src/gcc/svn/gcc/gimple-ssa-sprintf.c:3532
0x204cdec handle_printf_call(gimple_stmt_iterator*, vr_values const*)
/src/gcc/svn/gcc/gimple-ssa-sprintf.c:4199
0x14c8560 strlen_check_and_optimize_call
/src/gcc/svn/gcc/tree-ssa-strlen.c:4445
0x14c8ed3 check_and_optimize_stmt
/src/gcc/svn/gcc/tree-ssa-strlen.c:4581
0x14c9a08 strlen_dom_walker::before_dom_children(basic_block_def*)
/src/gcc/svn/gcc/tree-ssa-strlen.c:4808
0x1fbf79c dom_walker::walk(basic_block_def*)
/src/gcc/svn/gcc/domwalk.c:309
0x14c9cdc printf_strlen_execute
/src/gcc/svn/gcc/tree-ssa-strlen.c:4872
0x14c9f72 execute
/src/gcc/svn/gcc/tree-ssa-strlen.c:4974
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/91563] [9 regression] wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91563 --- Comment #5 from Guillaume Morin --- Jakub mentioned that r273135 fixed the abort() in the trunk. I noticed that this revision had already been backported to the gcc-9 branch as r274532. So I built the gcc-9 branch and I can confirm that it does fix the problem.
[Bug target/88082] ICE in change_address_1, at emit-rtl.c:2286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88082 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | Status|ASSIGNED|NEW Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #3 from Martin Liška --- It's fixed by your commit r268798. Feel free to close the issue it's a dup of PR89233. Thanks.
[Bug c++/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222 --- Comment #15 from Jason Merrill --- (In reply to Jason Merrill from comment #13) > But that still doesn't make the types the same, and the use of the variable > in 2.ii has undefined behavior because it is accessing the value of the > object through the wrong type, so the warning is correct. We may want to > allow it anyway for C compatibility. Thoughts? This does seem like significant trouble to make something work that isn't actually valid C++, and it isn't hard to fix the code by giving the struct a name. Is the problematic header part of publicly available source code or only the benchmark?
[Bug target/88617] ICE in ix86_compute_frame_layout, at config/i386/i386.c:11238 since r248029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88617 --- Comment #3 from Daniel Santos --- (In reply to Martin Liška from comment #2) > @Daniel: Can you please take a look? My apologies for missing this one! I'll take a look.
[Bug fortran/91565] [8/9/10 Regression] ICE in gfc_simplify_reshape, at fortran/simplify.c:6707 etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91565 --- Comment #2 from kargl at gcc dot gnu.org --- (In reply to kargl from comment #1) > (In reply to G. Steinmetz from comment #0) > > ICE hits gfortran-8 and higher - this changed just before 20180525. > > Starting with correct code z0.f90, then providing wrong orders > > (accepted up to gfortran-7) : > > > > > > $ cat z0.f90 > > program p > >integer, parameter :: a(2) = [2,1] > >print *, reshape([1,2,3,4,5,6], [2,3], order=a) > > end > > > > $ gfortran-10 z0.f90 && ./a.out > >1 4 2 5 3 6 > > > > > > > > $ cat z1.f90 # not a permutation > > program p > >integer, parameter :: a(2) = [2,2] > >print *, reshape([1,2,3,4,5,6], [2,3], order=a) > > end > > > > > > If I understand correctly, this is invalid because 'a' is > not a permutation of the [1, 2, ..., n] where n = size(shape). > I have a fix for this. Hmmm. This is messed up. check.c(gfc_check_reshape) is doing some of the work that is done in simplify.c(gfc__simplity_reshape). These two functions can probably use a rewrite to avoid duplication of effort.
[Bug c++/91563] [9 regression] wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91563 Jonathan Wakely changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2019-08-27 Ever confirmed|0 |1 --- Comment #4 from Jonathan Wakely --- You're right, sorry. GCC warns about the memset, but that warning is apparently given for cases that are not undefined, just questionable: mozilla_jwakely0/test_gcc9.cc:41:51: warning: ‘void* memset(void*, int, size_t)’ writing to an object of non-trivial type ‘struct E’; use assignment instead [-Wclass-memaccess] Confirmed then.
[Bug fortran/91565] [8/9/10 Regression] ICE in gfc_simplify_reshape, at fortran/simplify.c:6707 etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91565 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2019-08-27 CC||kargl at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to G. Steinmetz from comment #0) > ICE hits gfortran-8 and higher - this changed just before 20180525. > Starting with correct code z0.f90, then providing wrong orders > (accepted up to gfortran-7) : > > > $ cat z0.f90 > program p >integer, parameter :: a(2) = [2,1] >print *, reshape([1,2,3,4,5,6], [2,3], order=a) > end > > $ gfortran-10 z0.f90 && ./a.out >1 4 2 5 3 6 > > > > $ cat z1.f90 # not a permutation > program p >integer, parameter :: a(2) = [2,2] >print *, reshape([1,2,3,4,5,6], [2,3], order=a) > end > > If I understand correctly, this is invalid because 'a' is not a permutation of the [1, 2, ..., n] where n = size(shape). I have a fix for this.
[Bug rtl-optimization/91569] New: Optimisation test case and unnecessary XOR-OR pair instead of MOV.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91569
Bug ID: 91569
Summary: Optimisation test case and unnecessary XOR-OR pair
instead of MOV.
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: cubitect at gmail dot com
Target Milestone: ---
I wasn't entirely sure where to post this, but I have a very simple test
problem that shows some missed optimisation potential. The task is to cast
an integer to a long and replace the second lowest byte of the result with
a constant (4). Below are three ways to achieve this:
long opt_test1(int num) // opt_test1:
{ // movslq %edi, %rax
union { // mmovb $4, %ah
long q; // ret
struct { char l,h; };
} a;
a.q = num;
a.h = 4;
return a.q;
}
The union here is modelled after the structure of a r?x register which
contains the low and high byte registers: ?l and ?h. The cast and second
byte assignment can be done in one instruction each. The optimiser manages
to understand this and gives the optimal instructions.
long opt_test2(int num) // opt_test2:
{ // movl%edi, %eax
long a = num; // xor %ah, %ah
a &= (-1UL ^ 0xff00); // orb $4, %ah
a |= (4 << 8); // cltq
return a; // ret
}
This solution, based on a bitwise AND and OR, is interesting. The optimiser
recognised that I am interested in the second byte and makes use of the 'ah'
register, but why is there a XOR and an OR rather than an a single,
equivalent MOV? Similarly the (MOV + CLTQ) can be replaced outright with
MOVSLQ. Notable here is that some older versions (such as "gcc-4.8.5 -O3")
give results that correspond more to the C code:
andl$-65281, %edi
orl $1024, %edi
movslq %edi, %rax
ret
which is actually better than the output for gcc-9.2.
long opt_test3(int num) // opt_test3:
{ // movslq %edi, %rdi
long a = num; // movq%rdi, -8(%rsp)
((char*))[1] = 4; // movb$4, -7(%rsp)
return a; // movq-8(%rsp), %rax
} // ret
This is the straightforwards approach, addressing the second byte in memory.
I am including this because LLVM manages to recognise that the stack is not
actually necessary and goes for a register based solution.
As far as I could tell, these results seem quite consistent across most GCC
versions and across all optimisation levels above -O0. However, I obtained
the assembly code above using:
$ gcc-9.2 opt_tests.c -S -O3 -Wall -Wextra -pedantic
[Bug fortran/91496] !GCC$ directives error if mistyped or unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91496 --- Comment #3 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Tue Aug 27 19:16:33 2019 New Revision: 274966 URL: https://gcc.gnu.org/viewcvs?rev=274966=gcc=rev Log: 2019-08-27 Harald Anlauf PR fortran/91496 * gfortran.h: Extend struct gfc_iterator for loop annotations. * array.c (gfc_copy_iterator): Copy loop annotations by IVDEP, VECTOR, and NOVECTOR pragmas. * decl.c (gfc_match_gcc_ivdep, gfc_match_gcc_vector) (gfc_match_gcc_novector): New matcher functions handling IVDEP, VECTOR, and NOVECTOR pragmas. * match.h: Declare prototypes of matcher functions handling IVDEP, VECTOR, and NOVECTOR pragmas. * parse.c (decode_gcc_attribute, parse_do_block) (parse_executable): Decode IVDEP, VECTOR, and NOVECTOR pragmas; emit warning for unrecognized pragmas instead of error. * trans-stmt.c (gfc_trans_simple_do, gfc_trans_do): Add code to emit annotations for IVDEP, VECTOR, and NOVECTOR pragmas. * gfortran.texi: Document IVDEP, VECTOR, and NOVECTOR pragmas. PR fortran/91496 * gfortran.dg/pr91496.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/pr91496.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/gfortran.texi trunk/gcc/fortran/match.h trunk/gcc/fortran/parse.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/91567] [10 Regression] Spurious -Wformat-overflow warnings building glibc (32-bit only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91567 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-08-27 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Thanks, I'm working on it. https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01827.html
[Bug c++/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222 Jason Merrill changed: What|Removed |Added Attachment #46765|0 |1 is obsolete|| --- Comment #14 from Jason Merrill --- Created attachment 46769 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46769=edit clear TYPE_NAME in free_lang_data for extern "C" anonymous types Here's a more focused variant of my earlier patch.
[Bug c++/91506] Incorrectly issued error: parameter may not have variably modified type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91506 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Started with r166167.
[Bug c++/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222 --- Comment #13 from Jason Merrill --- Ah, I was reading the passage a bit wrong: where the extern "C" matters is not on the type, but on the variable (ml_bssnrest_). Because it's extern "C", declarations in different translation units correspond even though we can't use the same type in both. But that still doesn't make the types the same, and the use of the variable in 2.ii has undefined behavior because it is accessing the value of the object through the wrong type, so the warning is correct. We may want to allow it anyway for C compatibility. Thoughts?
[Bug tree-optimization/91568] internal compiler error: in vect_schedule_slp_instance, at tree-vect-slp.c:3922
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91568 --- Comment #1 from Matt Wala --- Created attachment 46768 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46768=edit Full compiler output
[Bug tree-optimization/91568] New: internal compiler error: in vect_schedule_slp_instance, at tree-vect-slp.c:3922
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91568 Bug ID: 91568 Summary: internal compiler error: in vect_schedule_slp_instance, at tree-vect-slp.c:3922 Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: wala1 at illinois dot edu Target Milestone: --- Created attachment 46767 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46767=edit helmrouts3d.f file causing internal compile error Hi, The attached file leads to an internal compile error when compiled as follows: $ gfortran -Wall -g -ffixed-form -fno-second-underscore -fPIC -std=legacy -Ofast -fopenmp helmrouts3d.f ... during GIMPLE pass: vect helmrouts3d.f:717:0: 717 | subroutine h3dall(nterms,z,scale,hvec,ifder,hder) | internal compiler error: in vect_schedule_slp_instance, at tree-vect-slp.c:3922 0x7f249db9c09a __libc_start_main ../csu/libc-start.c:308 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions. Version: $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:hsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 9.2.1-4' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-9 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 9.2.1 20190821 (Debian 9.2.1-4)
[Bug tree-optimization/91567] New: [10 Regression] Spurious -Wformat-overflow warnings building glibc (32-bit only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91567
Bug ID: 91567
Summary: [10 Regression] Spurious -Wformat-overflow warnings
building glibc (32-bit only)
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jsm28 at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
Target Milestone: ---
r274933 ("PR tree-optimization/83431 - -Wformat-truncation may incorrectly
report truncation") introduced spurious -Wformat-truncation warnings on the
following code, built with -O2 -Wall, for 32-bit systems only (e.g. x86_64 -m32
or -mx32 but not -m64). This is reduced from a build failure building glibc
for such systems with GCC trunk.
void f (char *);
void
g (char *s1, char *s2)
{
char b[1025];
__SIZE_TYPE__ n = __builtin_strlen (s1), d = __builtin_strlen (s2);
if (n + d + 1 >= 1025)
return;
__builtin_sprintf (b, "%s.%s", s1, s2);
f (b);
}
t.c: In function 'g':
t.c:9:26: warning: '%s' directive writing up to 2147483645 bytes into a region
of size 1025 [-Wformat-overflow=]
9 | __builtin_sprintf (b, "%s.%s", s1, s2);
| ^~
t.c:9:3: note: '__builtin_sprintf' output between 2 and 4294967292 bytes into a
destination of size 1025
9 | __builtin_sprintf (b, "%s.%s", s1, s2);
| ^~
[Bug fortran/91566] New: [9/10 Regression] ICE in gfc_constructor_copy, at fortran/constructor.c:103
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91566 Bug ID: 91566 Summary: [9/10 Regression] ICE in gfc_constructor_copy, at fortran/constructor.c:103 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20180624 and 20180708 : $ cat z1.f90 program p print *, -merge([3,4], 0, [.false.,.true.]) end $ cat z2.f90 program p print *, 2 + merge([3,4], 0, [.false.,.true.]) end $ gfortran-9-20180624 z1.f90 && ./a.out 0 -4 $ gfortran-10-20190825 -c z1.f90 f951: internal compiler error: Segmentation fault 0xb3acef crash_signal ../../gcc/toplev.c:326 0x13f7bac splay_tree_foreach ../../libiberty/splay-tree.c:577 0x5fe5f4 gfc_constructor_copy(splay_tree_s*) ../../gcc/fortran/constructor.c:103 0x5e5cab reduce_unary ../../gcc/fortran/arith.c:1267 0x5e5ccf reduce_unary ../../gcc/fortran/arith.c:1270 0x5e651f eval_intrinsic ../../gcc/fortran/arith.c:1609 0x620307 simplify_intrinsic_op ../../gcc/fortran/expr.c:1180 0x620307 gfc_simplify_expr(gfc_expr*, int) ../../gcc/fortran/expr.c:2198 0x68d4e6 resolve_operator ../../gcc/fortran/resolve.c:4310 0x68d4e6 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:6944 0x684e5b gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11416 0x694fbf gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:10460 0x684fe9 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11406 0x687ca7 resolve_codes ../../gcc/fortran/resolve.c:16921 0x687d6e gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:16956 0x67581c resolve_all_program_units ../../gcc/fortran/parse.c:6073 0x67581c gfc_parse_file() ../../gcc/fortran/parse.c:6320 0x6bf60f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug fortran/91565] New: [8/9/10 Regression] ICE in gfc_simplify_reshape, at fortran/simplify.c:6707 etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91565 Bug ID: 91565 Summary: [8/9/10 Regression] ICE in gfc_simplify_reshape, at fortran/simplify.c:6707 etc. Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- ICE hits gfortran-8 and higher - this changed just before 20180525. Starting with correct code z0.f90, then providing wrong orders (accepted up to gfortran-7) : $ cat z0.f90 program p integer, parameter :: a(2) = [2,1] print *, reshape([1,2,3,4,5,6], [2,3], order=a) end $ gfortran-10 z0.f90 && ./a.out 1 4 2 5 3 6 $ cat z1.f90 # not a permutation program p integer, parameter :: a(2) = [2,2] print *, reshape([1,2,3,4,5,6], [2,3], order=a) end $ cat z2.f90 # size of order and shape differs program p integer, parameter :: a(1) = 1 print *, reshape([1,2,3,4,5,6], [2,3], order=a) end $ cat z3.f90 # shape of order and shape differs program p integer, parameter :: a(1,2) = 1 print *, reshape([1,2,3,4,5,6], [2,3], order=a) end $ gfortran-7 z3.f90 && ./a.out 1 3 4 -1 0 0 $ $ gfortran-10-20190825 -c z1.f90 f951: internal compiler error: in gfc_simplify_reshape, at fortran/simplify.c:6707 0x6a6a99 gfc_simplify_reshape(gfc_expr*, gfc_expr*, gfc_expr*, gfc_expr*) ../../gcc/fortran/simplify.c:6707 0x62ef5b do_simplify ../../gcc/fortran/intrinsic.c:4556 0x6395ee gfc_intrinsic_func_interface(gfc_expr*, int) ../../gcc/fortran/intrinsic.c:4931 0x6907a1 resolve_unknown_f ../../gcc/fortran/resolve.c:2896 0x6907a1 resolve_function ../../gcc/fortran/resolve.c:3233 0x68ce2d gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:6951 0x684e5b gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11416 0x694fbf gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:10460 0x684fe9 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11406 0x687ca7 resolve_codes ../../gcc/fortran/resolve.c:16921 0x687d6e gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:16956 0x67581c resolve_all_program_units ../../gcc/fortran/parse.c:6073 0x67581c gfc_parse_file() ../../gcc/fortran/parse.c:6320 0x6bf60f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug target/91528] [10 Regression] ICE in ix86_expand_prologue at i386.c:7844 since r274481
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91528 Uroš Bizjak changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com --- Comment #13 from Uroš Bizjak --- Fixed.
[Bug target/91528] [10 Regression] ICE in ix86_expand_prologue at i386.c:7844 since r274481
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91528 --- Comment #12 from uros at gcc dot gnu.org --- Author: uros Date: Tue Aug 27 17:23:59 2019 New Revision: 274962 URL: https://gcc.gnu.org/viewcvs?rev=274962=gcc=rev Log: PR target/91528 * config/i386/i386-features.c (convert_scalars_to_vector): Update crtl->stack_realign_needed, crtl->stack_realign_tried and crtl->stack_realign_processed. Update crtl->drap_reg by calling targetm.calls.get_drap_rtx. If drap_rtx is non-null then Update crtl->args.internal_arg_pointer and call fixup_tail_calls. testsuite/ChangeLog: PR target/91528 * gcc.target/i386/pr91528.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr91528.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386-features.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/91564] New: [8/9/10 Regression] ICE in gimplify_expr, at gimplify.c:14147
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91564 Bug ID: 91564 Summary: [8/9/10 Regression] ICE in gimplify_expr, at gimplify.c:14147 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects gfortran-8 an higher, has changed before 20180525 : (one argument more than the library-kill) $ cat z1.f90 program p call kill (1, 2, 3) end $ gfortran-7 -c z1.f90 $ $ gfortran-10-20190825 -c z1.f90 z1.f90:2:0: 2 |call kill (1, 2, 3) | internal compiler error: in gimplify_expr, at gimplify.c:14147 0x90827a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:14147 0x9110e9 gimplify_modify_expr ../../gcc/gimplify.c:5747 0x906efd gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:13135 0x909c88 gimplify_stmt(tree_node**, gimple**) ../../gcc/gimplify.c:6779 0x907b5b gimplify_statement_list ../../gcc/gimplify.c:1849 0x907b5b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:13579 0x909c88 gimplify_stmt(tree_node**, gimple**) ../../gcc/gimplify.c:6779 0x90a621 gimplify_bind_expr ../../gcc/gimplify.c:1417 0x907c1b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:13336 0x909c88 gimplify_stmt(tree_node**, gimple**) ../../gcc/gimplify.c:6779 0x90a621 gimplify_bind_expr ../../gcc/gimplify.c:1417 0x907c1b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:13336 0x909c88 gimplify_stmt(tree_node**, gimple**) ../../gcc/gimplify.c:6779 0x90b0ca gimplify_body(tree_node*, bool) ../../gcc/gimplify.c:14381 0x90b3b5 gimplify_function_tree(tree_node*) ../../gcc/gimplify.c:14525 0x7b9e37 cgraph_node::analyze() ../../gcc/cgraphunit.c:667 0x7bc7f7 analyze_functions ../../gcc/cgraphunit.c:1126 0x7bd152 symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.c:2840 $ gfortran-10-20190825-debug -c z1.f90 gimplification failed: 3 constant 3> z1.f90:2:0: 2 |call kill (1, 2, 3) | internal compiler error: gimplification failed 0x9f2a81 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:14144 0xa05658 gimplify_modify_expr ../../gcc/gimplify.c:5747 #...
[Bug c++/91563] [9 regression] wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91563 --- Comment #3 from Guillaume Morin --- Jonathan, Are you sure? I modified the code to print std::is_trivially_copyable::value and it does print "1". Am I missing something obvious?
[Bug c++/91563] [9 regression] wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91563 --- Comment #2 from Jakub Jelinek --- Just a note from bisection, stopped aborting on trunk with r273135, and started to abort in r260318.
[Bug c++/91563] [9 regression] wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91563 --- Comment #1 from Jonathan Wakely --- The program's behaviour is undefined, because memset can't be used for writing to non-trivially copyable types.
[Bug testsuite/91562] [10 regression] gcc.dg/strlenopt-8.c fails starting with r274933
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91562 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #2 from Martin Sebor --- Yes, I must have missed updating the name of the dump. It should be strlen1.
[Bug c++/83431] -Wformat-truncation may incorrectly report truncation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83431 --- Comment #8 from Martin Sebor --- Author: msebor Date: Tue Aug 27 16:18:27 2019 New Revision: 274961 URL: https://gcc.gnu.org/viewcvs?rev=274961=gcc=rev Log: gcc/testsuite/ChangeLog: PR c++/83431 PR testsuite/91562 * gcc.dg/strlenopt-8.c: Adjust pass/dump name. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/strlenopt-8.c
[Bug testsuite/91562] [10 regression] gcc.dg/strlenopt-8.c fails starting with r274933
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91562 --- Comment #1 from Martin Sebor --- Author: msebor Date: Tue Aug 27 16:18:27 2019 New Revision: 274961 URL: https://gcc.gnu.org/viewcvs?rev=274961=gcc=rev Log: gcc/testsuite/ChangeLog: PR c++/83431 PR testsuite/91562 * gcc.dg/strlenopt-8.c: Adjust pass/dump name. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/strlenopt-8.c
[Bug fortran/91556] Problems with better interface checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-08-27 Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #9 from Thomas Koenig --- After r274937, the new flag -fallow-argument-mismatch can also be used. Now, I agree that the error message can be improved - the _formal_... argument names can be improved, it would probably a better idea to refer to the place that the declaration came from in that case. I'll do this, but it will probably be a couple of weeks until I can come up with something - too many things happening in Real Life (TM) at the moment.
[Bug c++/91563] New: [9 regression] wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91563
Bug ID: 91563
Summary: [9 regression] wrong code
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: guillaume at morinfr dot org
Target Milestone: ---
Created attachment 46766
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46766=edit
test program
Hi,
The attached program aborts with gcc 9.x -O{1,2,3} (including recent version of
the Debian package which has picked recent fixes to the gcc 9 branch). Adding
-fno-strict-aliasing does not make any difference. Full example is uploaded at
https://godbolt.org/z/We99i_
It seems to work correctly with gcc 8.x and the gcc trunk on goldbot.org.
Thank you.
[Bug c++/91506] Incorrectly issued error: parameter may not have variably modified type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91506 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-08-27 Ever confirmed|0 |1
[Bug libstdc++/91558] [C++11] should not be constexpr until C++14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91558
--- Comment #4 from Jonathan Wakely ---
(In reply to Yichen Yan from comment #3)
> (In reply to Jonathan Wakely from comment #1)
> > (In reply to Yichen Yan from comment #0)
> > > Detail:
> > > Constexpr for is in C++14 if I don't misunderstand. But a lot of
> > > testcases under libstdc++-v3/testsuite/26_numerics/complex/ (e.g.
> > > dr844.cc)
> >
> > Are you sure? That test doesn't seem to care about constexpr.
>
> Yes, check_ret_type require its template argument and argument to be
> constexpr.
No it doesn't:
template
typename __gnu_cxx::__enable_if::__value,
bool>::__type
check_ret_type(T)
{ return true; }
[Bug testsuite/91562] New: [10 regression] gcc.dg/strlenopt-8.c fails starting with r274933
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91562
Bug ID: 91562
Summary: [10 regression] gcc.dg/strlenopt-8.c fails starting
with r274933
Product: gcc
Version: 10.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: ---
Did this test case get missed when the others were updated?
Executing on host: /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/strlenopt-8.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -O2 -fdump-tree-strlen -lm -o ./strlenopt-8.exe
(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/strlenopt-8.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -O2 -fdump-tree-strlen -lm -o ./strlenopt-8.exe
PASS: gcc.dg/strlenopt-8.c (test for excess errors)
Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/build/gcc-test/gcc::/home/seurer/gcc/build/gcc-test/gcc:/home/seurer/gcc/build/gcc-test/./gmp/.libs:/home/seurer/gcc/build/gcc-test/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test/./isl/.libs:/home/seurer/gcc/build/gcc-test/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.2.0/lib64
Execution timeout is: 300
spawn [open ...]
PASS: gcc.dg/strlenopt-8.c execution test
gcc.dg/strlenopt-8.c: dump file does not exist
UNRESOLVED: gcc.dg/strlenopt-8.c scan-tree-dump-times strlen "strlen \\(" 0
gcc.dg/strlenopt-8.c: dump file does not exist
UNRESOLVED: gcc.dg/strlenopt-8.c scan-tree-dump-times strlen "strcpy \\(" 0
gcc.dg/strlenopt-8.c: dump file does not exist
UNRESOLVED: gcc.dg/strlenopt-8.c scan-tree-dump-times strlen "strcat \\(" 0
gcc.dg/strlenopt-8.c: dump file does not exist
UNRESOLVED: gcc.dg/strlenopt-8.c scan-tree-dump-times strlen "strchr \\(" 0
gcc.dg/strlenopt-8.c: dump file does not exist
UNRESOLVED: gcc.dg/strlenopt-8.c scan-tree-dump-times strlen "stpcpy \\(" 0
testcase /home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/dg.exp completed in 0
seconds
=== gcc Summary ===
# of expected passes2
# of unresolved testcases 5
[Bug c++/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222 --- Comment #12 from Jan Hubicka --- > Created attachment 46765 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46765=edit > clear TYPE_NAME in free_lang_data for anonymous types > > Perhaps like this? It seems that this will disable ODR handling of all anonymous types, not only those declared as "extern C". We make use of the info (by mangling them to ) to handle them during devirtualization and also TBAA. So perhaps we want to be more specific here? Honza
[Bug c++/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222 --- Comment #11 from Jason Merrill --- Created attachment 46765 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46765=edit clear TYPE_NAME in free_lang_data for anonymous types Perhaps like this?
[Bug target/88082] ICE in change_address_1, at emit-rtl.c:2286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88082 Martin Liška changed: What|Removed |Added Keywords||needs-bisection Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-08-27 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- You're right, let me bisect that first.
[Bug d/91561] New: [Regression] Internal Compiler Error: type ‘ubyte[]’ can not be mapped to C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91561
Bug ID: 91561
Summary: [Regression] Internal Compiler Error: type ‘ubyte[]’
can not be mapped to C++
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: bugzilla at allegrodvt dot com
Target Milestone: ---
The following code compiles on gdc-8.2 but failed on gdc-9.2:
--
extern(C++) :
alias ubyte[] Array;
class Interface
{
abstract void getArray(ref Array a);
}
void main()
{
}
---
The error is:
error: Internal Compiler Error: type ‘ubyte[]’ can not be mapped to C++
6 | abstract void getArray(ref Array a);
| ^
[Bug target/88082] ICE in change_address_1, at emit-rtl.c:2286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88082 Ilya Leoshkevich changed: What|Removed |Added CC||iii at linux dot ibm.com --- Comment #1 from Ilya Leoshkevich --- Hello Martin, do you per chance remember the failing revision? With r274945 and stable gcc 9.1.1 it seems to work fine: $ ./build/gcc/cc1 gcc/testsuite/c-c++-common/pr59037.c -Os -march=z14 ; echo $? 0 $ gcc-9 gcc/testsuite/c-c++-common/pr59037.c -Os -march=z14 ; echo $? 0
[Bug lto/87500] ICE in discriminator_for_local_entity, at cp/mangle.c:1967
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87500 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Martin Liška --- Fixed on trunk with r265714. I'm going to close it.
[Bug lto/88140] [9/10 Regression] ICE: verify_gimple failed since r266325
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88140 --- Comment #14 from Jan Hubicka --- > @Honza: Can we close this? Array simplification is still disabled - we need to figure how how to represent them...
[Bug c++/69571] [C++11] invalid alignas on a typedef accepted, reduces alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69571 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- related/dup: bug 90847
[Bug lto/87501] lto1: error: Alias and target's section differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87501 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org
[Bug c++/69572] [C++11] invalid alignas accepted in many contexts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69572 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek --- related/dup: bug 90847
[Bug lto/88081] [7/8/9/10 Regression] ICE in lto_varpool_replace_node, at lto/lto-symtab.c:109
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88081 --- Comment #6 from Martin Liška --- @Honza: Reminder.
[Bug target/88083] ICE in find_constant_pool_ref_1, at config/s390/s390.c:8231
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88083 --- Comment #2 from Martin Liška --- @Ilya: Can we close this?
[Bug lto/88140] [9/10 Regression] ICE: verify_gimple failed since r266325
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88140 --- Comment #13 from Martin Liška --- @Honza: Can we close this?
[Bug target/88615] ICE in change_address_1, at emit-rtl.c:2286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88615 Martin Liška changed: What|Removed |Added CC||amodra at gcc dot gnu.org, ||gcc-bugzilla at gcc dot gnu.org --- Comment #1 from Martin Liška --- Can you s390x guys take a look?
[Bug target/88617] ICE in ix86_compute_frame_layout, at config/i386/i386.c:11238 since r248029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88617 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- @Daniel: Can you please take a look?
[Bug rtl-optimization/88652] sel-sched.c:1545:11: runtime error: index 2 out of bounds for type 'long unsigned int [2]'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88652 --- Comment #5 from Martin Liška --- > > Looks like you're right :) I'll fix that, then. > Any update on this, please?
[Bug tree-optimization/90213] UBSAN: signed integer overflow: -5621332293356458048 * 8 cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90213 --- Comment #6 from Richard Biener --- Hmm, I think I eventually wanted to backport it...
[Bug c++/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222 --- Comment #10 from Jan Hubicka --- > > > > They aren't in the anonymous namespace, but they are themselves anonymous, > > so they have no linkage. The standard says, > > > > A type without linkage shall not be used as the type of a variable or > > function with external linkage unless > > — the entity has C language linkage (7.5), or > > — the entity is declared within an unnamed namespace (7.3.1), or > > — the entity is not odr-used (3.2) or is defined in the same translation > > unit. > > > > Here 1.ii is OK under the third bullet, and 2.ii under the first bullet. > > Within extern "C" I guess we need to do structural comparison for anonymous > > types rather than rely on the ODR. > > Honza? In order to disable this for ODR merging, we need to arrange the (already long) TYPE_DECL condition in tree.c:need_assembler_name_p to be false for them or C++ get_assembler_name langhook to return NULL in this case. I wonder how we can arrange that? Honza
[Bug libstdc++/91558] [C++11] should not be constexpr until C++14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91558 --- Comment #3 from Yichen Yan --- (In reply to Jonathan Wakely from comment #1) > (In reply to Yichen Yan from comment #0) > > Detail: > > Constexpr for is in C++14 if I don't misunderstand. But a lot of > > testcases under libstdc++-v3/testsuite/26_numerics/complex/ (e.g. dr844.cc) > > Are you sure? That test doesn't seem to care about constexpr. Yes, check_ret_type require its template argument and argument to be constexpr. > > runs with C++11 and check for constexpr (and pass). > > > > I haven't found some manual or doc explaining that, and wonder if this is a > > bug or some feature? > > The mailing lists are a better place to ask a question like that. > > Adding constexpr to std::complex was done by r166171 many years ago. I think > at the time implementations were allowed to add constexpr as a conforming > extension. I don't see a compelling reason to change it now. I see. Thanks for your reply.
[Bug c/89549] [7/8/9/10 Regression] -Wmisleading-indentation is disabled from this point onwards, since column-tracking was disabled due to the size of the code/headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89549 --- Comment #10 from Martin Liška --- @David: May I please remind this?
[Bug target/89623] Can't build mips-wrs-vxworks cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89623 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Liška --- Then let's close this.
[Bug tree-optimization/90213] UBSAN: signed integer overflow: -5621332293356458048 * 8 cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90213 --- Comment #5 from Martin Liška --- @Richi: Can we close this?
[Bug c++/90613] [10 Regression] Debug info size increase after r271467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90613 --- Comment #1 from Martin Liška --- @Nathan: May I please remind this?
[Bug c++/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222
--- Comment #9 from Martin Liška ---
(In reply to Jason Merrill from comment #8)
> (In reply to Jan Hubicka from comment #2)
> > 2.ii:62:3: warning: ‘ml_bssnrest_’ violates the C++ One Definition Rule
> > [-Wodr]
> >62 | } ml_bssnrest_;
> > | ^
> > 1.ii:2:8: note: type ‘struct ’ defined in anonymous namespace cannot
> > match across the translation unit boundary
> > 2 | struct {
> > |^
> > 2.ii:2:15: note: the incompatible type defined in another translation unit
> > 2 | extern struct {
> > | ^
> > 1.ii:62:3: note: ‘ml_bssnrest_’ was previously declared here
> >62 | } ml_bssnrest_;
> > | ^
> >
> > Now I wonder why C++ FE makes the struct anonymous namespace when it is
> > declared with extern "C".
> > I have checked that type_in_anonymous_namespace_p(prevailing_type) returns
> > true because mangled name is which comes from C++ FE.
> >
> > I will check in the patch to avoid ICE. Jason, can you please look if it is
> > correct to consider these types anonymous?
>
> They aren't in the anonymous namespace, but they are themselves anonymous,
> so they have no linkage. The standard says,
>
> A type without linkage shall not be used as the type of a variable or
> function with external linkage unless
> — the entity has C language linkage (7.5), or
> — the entity is declared within an unnamed namespace (7.3.1), or
> — the entity is not odr-used (3.2) or is defined in the same translation
> unit.
>
> Here 1.ii is OK under the third bullet, and 2.ii under the first bullet.
> Within extern "C" I guess we need to do structural comparison for anonymous
> types rather than rely on the ODR.
Honza?
[Bug libstdc++/91558] [C++11] should not be constexpr until C++14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91558 Jonathan Wakely changed: What|Removed |Added Resolution|WONTFIX |INVALID --- Comment #2 from Jonathan Wakely --- Also, C++11 requires constexpr for the standard specializations, std::complex, std::complex, and std::complex. The effect of instantiating the primary template is unspecified by the standard, so we're allowed to make it constexpr.
[Bug tree-optimization/90970] A suspicious code in builtins.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90970 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-08-27 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 libstdc++/91558] [C++11] should not be constexpr until C++14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91558 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Jonathan Wakely --- (In reply to Yichen Yan from comment #0) > Detail: > Constexpr for is in C++14 if I don't misunderstand. But a lot of > testcases under libstdc++-v3/testsuite/26_numerics/complex/ (e.g. dr844.cc) Are you sure? That test doesn't seem to care about constexpr. > runs with C++11 and check for constexpr (and pass). > > I haven't found some manual or doc explaining that, and wonder if this is a > bug or some feature? The mailing lists are a better place to ask a question like that. Adding constexpr to std::complex was done by r166171 many years ago. I think at the time implementations were allowed to add constexpr as a conforming extension. I don't see a compelling reason to change it now.
[Bug target/91560] Try harder for AVX non-AVX2 cross-lane permutations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91560 Jakub Jelinek changed: What|Removed |Added CC||hjl.tools at gmail dot com, ||uros at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- For f1 clang emits: vpermilps $144, %xmm1, %xmm2 # xmm2 = xmm1[0,0,1,2] vextractf128$1, %ymm1, %xmm3 vblendps$8, %xmm1, %xmm3, %xmm1 # xmm1 = xmm3[0,1,2],xmm1[3] vpermilps $147, %xmm1, %xmm1 # xmm1 = xmm1[3,0,1,2] vinsertf128 $1, %xmm1, %ymm2, %ymm1 vblendps$1, %ymm0, %ymm1, %ymm0 # ymm0 = ymm0[0],ymm1[1,2,3,4,5,6,7] and for f2: vextractf128$1, %ymm1, %xmm2 vshufpd $1, %xmm2, %xmm1, %xmm2 # xmm2 = xmm1[1],xmm2[0] vmovddup%xmm1, %xmm1# xmm1 = xmm1[0,0] vinsertf128 $1, %xmm2, %ymm1, %ymm1 vblendps$3, %ymm0, %ymm1, %ymm0 # ymm0 = ymm0[0,1],ymm1[2,3,4,5,6,7]
[Bug target/91560] New: Try harder for AVX non-AVX2 cross-lane permutations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91560
Bug ID: 91560
Summary: Try harder for AVX non-AVX2 cross-lane permutations
Product: gcc
Version: 9.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
On:
typedef float __v8sf __attribute__((vector_size (32)));
typedef double __v4df __attribute__((vector_size (32)));
typedef int __v8si __attribute__((vector_size (32)));
typedef long long __v4di __attribute__((vector_size (32)));
#ifdef __clang__
#define S(x, y, t, ...) __builtin_shufflevector (x, y, __VA_ARGS__)
#else
#define S(x, y, t, ...) __builtin_shuffle (x, y, (t) { __VA_ARGS__ })
#endif
__v8sf f1 (__v8sf x, __v8sf y) { return S (x, y, __v8si, 0, 8, 9, 10, 11, 12,
13, 14 ); }
__v8sf f2 (__v8sf x, __v8sf y) { return S (x, y, __v8si, 0, 1, 8, 9, 10, 11,
12, 13 ); }
__v8sf f3 (__v8sf x, __v8sf y) { return S (x, y, __v8si, 0, 1, 2, 3, 8, 9, 10,
11 ); }
__v8sf f4 (__v8sf x, __v8sf y) { return S (x, y, __v8si, 7, 7, 7, 7, 7, 7, 7, 7
); }
__v4df f5 (__v4df x, __v4df y) { return S (x, y, __v4di, 0, 4, 5, 6 ); }
__v4df f6 (__v4df x, __v4df y) { return S (x, y, __v4di, 0, 1, 4, 5 ); }
__v4df f7 (__v4df x, __v4df y) { return S (x, y, __v4di, 3, 3, 3, 3 ); }
LLVM generates for -O2 -mavx -mno-avx2 shorter code for f1 and f2 (but worse
code for f5), GCC simply gives up for f1/f2 and then expands the shuffle as
lots of BIT_FIELD_REF extractions plus vector creation.
Wonder if ix86_expand_vec_perm_const_1 for the if (TARGET_AVX && !TARGET_AVX2)
and 32-byte vectors shouldn't try harder (though, with rightly estimated
costs).
The above permutations are what is used for OpenMP scans in scan-13.c (and
variant thereof with double instead of float) and reason why we don't vectorize
using 32-byte vectors.
[Bug c/91554] if (!__builtin_constant_p (fn_arg)) warning_function() works in inline when fn_arg is int, not when it is void *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91554 --- Comment #4 from Zack Weinberg --- (In reply to Richard Biener from comment #3) > I guess you want to use > > __builtin_constant_p (b != 0) > > instead. That wouldn't do what I want. The goal is to warn for any argument _other than_ a compile-time null pointer. `!__builtin_constant_p(b) || b != 0` does just that (it might be easier to understand the De Morgan equivalent `!(__builtin_constant_p(b) && b == 0)`. This is in aid of deprecating the second argument to gettimeofday (see https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;h=75453bbda865c7d51df39177caef40b16e086dcf#l53 and https://sourceware.org/git/?p=glibc.git;a=blob;f=manual/time.texi;h=cb234bd08fae1841034a2bdccf4e1d246be23034#l557 ). > The docs don't explain what a "constant at compile time" is > so whether for example the address of a global or the address of an > automatic var would be "constant". But I'd say the above incorrectly > disregards the NULL-pointer case. It seems like this code pre-dates tree optimizations, I would suggest removing these lines 8470 || AGGREGATE_TYPE_P (TREE_TYPE (arg)) 8471 || POINTER_TYPE_P (TREE_TYPE (arg)) (and fixing the comment above to match) and seeing if that breaks anything.
[Bug libquadmath/91559] New: math/x2y2m1q.c assumes FE_TONEAREST defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91559 Bug ID: 91559 Summary: math/x2y2m1q.c assumes FE_TONEAREST defined Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libquadmath Assignee: unassigned at gcc dot gnu.org Reporter: joel at gcc dot gnu.org Target Milestone: --- newlib has been updated to always provide an fenv.h with prototypes for the required methods. Unfortunately, this has triggered code in math/x2y2m1q.c which incorrectly assumes FE_TONEAREST is always defined. Per POSIX, the rounding mode and exception mode constants only need to be supported if they are defined. A check for existence of fenv.h is an insufficient check. http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/fenv.h.html ../../../../gnu-mirror-gcc-0f81292cb0a/libquadmath/math/x2y2m1q.c:57:26: error: 'FE_TONEAREST' undeclared (first use in this function) 57 | SET_RESTORE_ROUNDF128 (FE_TONEAREST); | ^~~~ This showed up on x86_64 but is likely to show up on all newlib targets which do not have the target specific fenv support. The solution is just to wrap all calls using fenv.h constants with an #ifdef on the constant used as POSIX indicates.
[Bug lto/91478] FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g1 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91478 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #29 from Martin Liška --- Should be fixed now.
[Bug lto/91478] FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g1 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91478 --- Comment #28 from Martin Liška --- Author: marxin Date: Tue Aug 27 13:36:15 2019 New Revision: 274955 URL: https://gcc.gnu.org/viewcvs?rev=274955=gcc=rev Log: Share a prevailing name for remove debug info symbols w/ LTO. 2019-08-27 Martin Liska PR lto/91478 * simple-object-elf.c (simple_object_elf_copy_lto_debug_sections): First find a WEAK HIDDEN symbol in symbol table that will be preserved. Later, use the symbol name for all removed symbols. Modified: trunk/libiberty/ChangeLog trunk/libiberty/simple-object-elf.c
[Bug c/91554] if (!__builtin_constant_p (fn_arg)) warning_function() works in inline when fn_arg is int, not when it is void *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91554 --- Comment #3 from Richard Biener --- It's obviously 8462 /* If this expression has side effects, show we don't know it to be a 8463 constant. Likewise if it's a pointer or aggregate type since in 8464 those case we only want literals, since those are only optimized 8465 when generating RTL, not later. 8466 And finally, if we are compiling an initializer, not code, we 8467 need to return a definite result now; there's not going to be any 8468 more optimization done. */ 8469 if (TREE_SIDE_EFFECTS (arg) 8470 || AGGREGATE_TYPE_P (TREE_TYPE (arg)) 8471 || POINTER_TYPE_P (TREE_TYPE (arg)) 8472 || cfun == 0 8473 || folding_initializer 8474 || force_folding_builtin_constant_p) 8475 return integer_zero_node; that causes this, I guess you want to use __builtin_constant_p (b != 0) instead. The docs don't explain what a "constant at compile time" is so whether for example the address of a global or the address of an automatic var would be "constant". But I'd say the above incorrectly disregards the NULL-pointer case.
[Bug c/91554] if (!__builtin_constant_p (x)) warning_function() works in inline when x is int, not when x is void *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91554
--- Comment #2 from Zack Weinberg ---
Additional fun detail:
```
static inline int
thefun (void *a, void *b)
{
if (!__builtin_constant_p((__UINTPTR_TYPE__)b) || b != 0)
thefun_called_with_nonnull_arg();
return real_thefun(a, b);
}
```
still warns for any use of `thefun`, but
```
static inline int
thefun (void *a, void *b)
{
if (!__builtin_constant_p((short)(__UINTPTR_TYPE__)b) || b != 0)
thefun_called_with_nonnull_arg();
return real_thefun(a, b);
}
```
works as intended! `(int)(__UINTPTR_TYPE__)` also works as intended on targets
where __UINTPTR_TYPE__ is bigger than int.
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/builtins.c;h=f902e246f1f347be4d4dc04e339fa865393039fe#l8462
looks suspicious to me. Note also the STRIP_NOPS shortly above, which might
explain why it matters whether the pointer is cast to a different-sized integer
type.
[Bug ipa/91468] Suspicious codes in ipa-prop.c and ipa-cp.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91468 --- Comment #3 from Martin Jambor --- I have proposed a patch on the mailing list: https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01820.html
[Bug c++/91415] Invalid warning for C++17 sequencing of shift operator E1<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91415 --- Comment #10 from Jakub Jelinek --- Partially fixed, needs more work, so keeping this open.
[Bug libstdc++/91558] New: [C++11] should not be constexpr until C++14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91558 Bug ID: 91558 Summary: [C++11] should not be constexpr until C++14 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: yichen.yan at inf dot ethz.ch Target Milestone: --- Detail: Constexpr for is in C++14 if I don't misunderstand. But a lot of testcases under libstdc++-v3/testsuite/26_numerics/complex/ (e.g. dr844.cc) runs with C++11 and check for constexpr (and pass). I haven't found some manual or doc explaining that, and wonder if this is a bug or some feature?
[Bug tree-optimization/91470] [10 Regression] bogus uninitialized warning in trans-intrinsic.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91470
--- Comment #3 from rguenther at suse dot de ---
On Tue, 27 Aug 2019, marxin at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91470
>
> Martin Liška changed:
>
>What|Removed |Added
>
>Keywords|needs-reduction |
> Status|UNCONFIRMED |NEW
>Last reconfirmed||2019-08-27
> CC||marxin at gcc dot gnu.org
> Ever confirmed|0 |1
>
> --- Comment #2 from Martin Liška ---
> There's a reduced test-case:
>
> $ cat pr91470.ii
> int input_location, global_trees_0, gfc_conv_intrinsic_findloc_body,
> gfc_conv_intrinsic_findloc_loopblock, gfc_conv_intrinsic_findloc_tmp,
> gfc_conv_intrinsic_findloc_found, gfc_conv_intrinsic_findloc_loop;
> enum tree_code { COND_EXPR };
> struct A {};
> struct B {
> int pre;
> int expr;
> };
> void fn1(B *, B *);
> void fn2(int *, int *);
> int *fn3(int *);
> void fn4(int, tree_code, int *, int *, int *, int);
> void fn5(B *, int *);
> void fn6() {
> A array_arg, value_arg, dim_arg, mask_arg, kind_arg, back_arg;
> int *forward_branch;
> B arrayse, valuese, maskse, backse;
> int i;
> value_arg = array_arg;
> mask_arg = dim_arg;
> back_arg = kind_arg;
> for (i = 0; i < 2; i++) {
> fn5(, _conv_intrinsic_findloc_loop);
> fn1(, __null);
> fn2(_conv_intrinsic_findloc_body, );
> fn4(input_location, COND_EXPR, _trees_0,
> _conv_intrinsic_findloc_tmp, _conv_intrinsic_findloc_found,
> 0);
> if (i == 0)
> forward_branch = fn3(_conv_intrinsic_findloc_loopblock);
> }
> fn4(input_location, COND_EXPR, _trees_0, ,
> forward_branch,
> 0);
> }
So this is basically
int x;
for (int i = 0; i < 2; ++i)
if (i == 0) x = bar();
baz(x);
with making sure we do _not_ thread / header copy / unroll this.
The uninit pass warns about the default def flowing into the loop PHI
node here.
[Bug c++/91415] Invalid warning for C++17 sequencing of shift operator E1<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91415 --- Comment #9 from Jakub Jelinek --- Author: jakub Date: Tue Aug 27 12:37:30 2019 New Revision: 274952 URL: https://gcc.gnu.org/viewcvs?rev=274952=gcc=rev Log: PR c++/91415 * c-common.c (verify_tree): For LSHIFT_EXPR, RSHIFT_EXPR, COMPONENT_REF and ARRAY_REF in cxx_dialect >= cxx17 mode handle it like COMPOUND_EXPR rather than normal expression. * g++.dg/warn/sequence-pt-4.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/sequence-pt-4.C Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/91470] [10 Regression] bogus uninitialized warning in trans-intrinsic.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91470
Martin Liška changed:
What|Removed |Added
Keywords|needs-reduction |
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-08-27
CC||marxin at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Martin Liška ---
There's a reduced test-case:
$ cat pr91470.ii
int input_location, global_trees_0, gfc_conv_intrinsic_findloc_body,
gfc_conv_intrinsic_findloc_loopblock, gfc_conv_intrinsic_findloc_tmp,
gfc_conv_intrinsic_findloc_found, gfc_conv_intrinsic_findloc_loop;
enum tree_code { COND_EXPR };
struct A {};
struct B {
int pre;
int expr;
};
void fn1(B *, B *);
void fn2(int *, int *);
int *fn3(int *);
void fn4(int, tree_code, int *, int *, int *, int);
void fn5(B *, int *);
void fn6() {
A array_arg, value_arg, dim_arg, mask_arg, kind_arg, back_arg;
int *forward_branch;
B arrayse, valuese, maskse, backse;
int i;
value_arg = array_arg;
mask_arg = dim_arg;
back_arg = kind_arg;
for (i = 0; i < 2; i++) {
fn5(, _conv_intrinsic_findloc_loop);
fn1(, __null);
fn2(_conv_intrinsic_findloc_body, );
fn4(input_location, COND_EXPR, _trees_0,
_conv_intrinsic_findloc_tmp, _conv_intrinsic_findloc_found, 0);
if (i == 0)
forward_branch = fn3(_conv_intrinsic_findloc_loopblock);
}
fn4(input_location, COND_EXPR, _trees_0, , forward_branch,
0);
}
[Bug libgomp/91530] Several libgomp.*/scan-* tests FAIL without avx_runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91530
--- Comment #5 from Jakub Jelinek ---
Created attachment 46764
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46764=edit
gcc10-pr91530-sse2.patch
Patch to hopefully fix the scan-{13,17}.c FAILs without avx_runtime.
[Bug testsuite/91549] [10 regression] gcc.dg/wrapped-binop-simplify.c fails starting with r274925
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91549 --- Comment #10 from rdapp at gcc dot gnu.org --- Author: rdapp Date: Tue Aug 27 12:08:58 2019 New Revision: 274951 URL: https://gcc.gnu.org/viewcvs?rev=274951=gcc=rev Log: PR testsuite/91549 gcc/testsuite/ChangeLog: * gcc.dg/wrapped-binop-simplify.c: Test only on x86, s390 with lp64. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/wrapped-binop-simplify.c
[Bug lto/91478] FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g1 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91478 Martin Liška changed: What|Removed |Added Keywords||patch --- Comment #27 from Martin Liška --- Patch has been sent: https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01813.html
[Bug lto/41731] The linker plugin should support translations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41731 --- Comment #2 from joseph at codesourcery dot com --- https://gcc.gnu.org/ml/gcc-patches/2009-10/msg01016.html
[Bug testsuite/91549] [10 regression] gcc.dg/wrapped-binop-simplify.c fails starting with r274925
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91549 --- Comment #9 from Uroš Bizjak --- (In reply to rdapp from comment #8) > > Yes, I think so. > > Is this an OK to commit? :) > > I checked it on s390 and x86_64 with -m64 and -m31/-m32. OK. Please go ahead.
[Bug testsuite/91549] [10 regression] gcc.dg/wrapped-binop-simplify.c fails starting with r274925
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91549 --- Comment #8 from rdapp at linux dot ibm.com --- > Yes, I think so. Is this an OK to commit? :) I checked it on s390 and x86_64 with -m64 and -m31/-m32.
