[Bug tree-optimization/71264] [5 Regression] ICE in convert_move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71264 --- Comment #24 from Richard Biener --- Author: rguenth Date: Fri Jan 20 08:01:27 2017 New Revision: 244683 URL: https://gcc.gnu.org/viewcvs?rev=244683&root=gcc&view=rev Log: 2017-01-20 Richard Biener PR tree-optimization/71264 * gcc.dg/vect/pr71264.c: Make sure memory is aligned. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/pr71264.c
[Bug other/79046] g++ -print-file-name=plugin uses full version number in path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79046 --- Comment #10 from Jakub Jelinek --- Author: jakub Date: Fri Jan 20 08:27:29 2017 New Revision: 244684 URL: https://gcc.gnu.org/viewcvs?rev=244684&root=gcc&view=rev Log: PR other/79046 liboffloadmic/ * aclocal.m4: Regenerated. * Makefile.in: Regenerated. libcilkrts/ * aclocal.m4: Regenerated. * Makefile.in: Regenerated. Modified: trunk/libcilkrts/ChangeLog trunk/libcilkrts/Makefile.in trunk/libcilkrts/aclocal.m4 trunk/libmpx/ChangeLog trunk/liboffloadmic/ChangeLog trunk/liboffloadmic/Makefile.in trunk/liboffloadmic/aclocal.m4
[Bug ipa/71190] [7 Regression] ICE in assemble_variable_contents, at varasm.c:2054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71190 --- Comment #14 from Martin Liška --- Author: marxin Date: Fri Jan 20 08:44:35 2017 New Revision: 244687 URL: https://gcc.gnu.org/viewcvs?rev=244687&root=gcc&view=rev Log: Fix IPA CP where it forgot to add a reference in cgraph (PR ipa/71190). 2017-01-20 Martin Liska PR ipa/71190 * cgraph.h (maybe_create_reference): Remove argument and update comment. * cgraphclones.c (cgraph_node::create_virtual_clone): Remove one argument. * ipa-cp.c (create_specialized_node): Likewise. * symtab.c (symtab_node::maybe_create_reference): Handle VAR_DECLs and ADDR_EXPRs and select ipa_ref_use type. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraph.h trunk/gcc/cgraphclones.c trunk/gcc/ipa-cp.c trunk/gcc/symtab.c
[Bug ipa/71190] [7 Regression] ICE in assemble_variable_contents, at varasm.c:2054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71190 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Martin Liška --- Fixed.
[Bug ipa/71207] [5/6 Regression] gcc 5.3 and 6.1 generates wrong code with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71207 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Martin Liška --- Fixed on all active branches.
[Bug ipa/71207] [5/6 Regression] gcc 5.3 and 6.1 generates wrong code with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71207 --- Comment #9 from Martin Liška --- Author: marxin Date: Fri Jan 20 08:49:08 2017 New Revision: 244688 URL: https://gcc.gnu.org/viewcvs?rev=244688&root=gcc&view=rev Log: Fix wrong assumption in contains_type_p (PR ipa/71207). 2017-01-20 Martin Liska Backport from mainline 2017-01-17 Martin Liska PR ipa/71207 * ipa-polymorphic-call.c (contains_type_p): Fix wrong assumption and add comment. 2017-01-20 Martin Liska Backport from mainline 2017-01-17 Martin Liska PR ipa/71207 * g++.dg/ipa/pr71207.C: New test. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/ipa/pr71207.C Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/ipa-polymorphic-call.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug ipa/71207] [5/6 Regression] gcc 5.3 and 6.1 generates wrong code with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71207 --- Comment #10 from Martin Liška --- Author: marxin Date: Fri Jan 20 08:49:16 2017 New Revision: 244689 URL: https://gcc.gnu.org/viewcvs?rev=244689&root=gcc&view=rev Log: Fix wrong assumption in contains_type_p (PR ipa/71207). 2017-01-20 Martin Liska Backport from mainline 2017-01-17 Martin Liska PR ipa/71207 * ipa-polymorphic-call.c (contains_type_p): Fix wrong assumption and add comment. 2017-01-20 Martin Liska Backport from mainline 2017-01-17 Martin Liska PR ipa/71207 * g++.dg/ipa/pr71207.C: New test. Added: branches/gcc-6-branch/gcc/testsuite/g++.dg/ipa/pr71207.C Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/ipa-polymorphic-call.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/79148] stack addresses are spilled to stack slots on x86-64 at -Os instead of rematerializing the addresses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79148 Richard Biener changed: What|Removed |Added Keywords||missed-optimization, ra Target||x86_64-*-* CC||vmakarov at gcc dot gnu.org Version|unknown |6.3.0 --- Comment #1 from Richard Biener --- A smaller testcase would be nice...
[Bug tree-optimization/79151] Missed BB vectorization with strided/scalar stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79151
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-01-20
Version|unknown |7.0
Blocks||53947
Summary|Missed vectorization with |Missed BB vectorization
|identical formulas |with strided/scalar stores
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
The basic-block vectorizer does not yet consider strided/scalar stores as a
source in its search for vectorization opportunities so it gives up very early.
Basically it searchs for groups of stores that can be vectorized with a vector
store and
then looks at how many of the feeding stmts it can include.
Handling this particular case is hard in the current scheme (or rather
expensive).
Confirmed.
"Fixing" the testcase to
void scalar(const double *restrict a, const double *restrict b,
double x, double *ar, double *br)
{
double ra, rb;
int i;
ra = a[0] + a[1]/x - 1.0/(a[0]-a[1]);
rb = b[0] + b[1]/x - 1.0/(b[0]-b[1]);
ar[0] = ra;
ar[1] = rb;
}
fails as well with
t.c:12:1: note: Build SLP for _1 = *a_14(D);
t.c:12:1: note: Build SLP for _7 = *b_17(D);
t.c:12:1: note: Build SLP failed: different interleaving chains in one node _7
= *b_17(D);
t.c:12:1: note: Re-trying with swapped operands of stmts 1
t.c:12:1: note: Build SLP for _1 = *a_14(D);
t.c:12:1: note: Build SLP for _9 = _8 / x_15(D);
t.c:12:1: note: Build SLP failed: different operation in stmt _9 = _8 /
x_15(D);
t.c:12:1: note: original stmt _1 = *a_14(D);
but we could handle this with "construction from scalars" and just get
confused by the first mismatch and optimistically trying to swap operands.
As said above the SLP finding algorithm is very much too greedy (with too many
accumulated hacks).
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug c/79152] -Wimplicit-fallthrough false positive triggered by goto statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79152 Richard Biener changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2017-01-20 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug c/79153] -Wimplicit-fallthrough missed warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79153 Richard Biener changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2017-01-20 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug rtl-optimization/79149] bad optimization on MIPS and ARM leading to excessive stack usage in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79149 --- Comment #1 from Arnd Bergmann --- Additional information: I see the same behavior to a varying degree on most other architectures (but notably not x86) using the preprocessed source from the MIPS kernel configuration, these are always one run with -fno-sched-critical-path-heuristic -fno-sched-dep-count-heuristic and one run without: === /home/arnd/cross-gcc/bin/aarch64-linux-gcc-5.2.1 === ../../crypto/wp512.c:987:1: warning: the frame size of 224 bytes is larger than 100 bytes [-Wframe-larger-than=] ../../crypto/wp512.c:987:1: warning: the frame size of 368 bytes is larger than 100 bytes [-Wframe-larger-than=] === /home/arnd/cross-gcc/bin/alpha-linux-gcc-4.9.3 === ../../crypto/wp512.c:987:1: warning: the frame size of 240 bytes is larger than 100 bytes [-Wframe-larger-than=] ../../crypto/wp512.c:987:1: warning: the frame size of 1136 bytes is larger than 100 bytes [-Wframe-larger-than=] === /home/arnd/cross-gcc/bin/am33_2.0-linux-gcc-4.9.3 === ../../crypto/wp512.c:987:1: warning: the frame size of 2092 bytes is larger than 100 bytes [-Wframe-larger-than=] ../../crypto/wp512.c:987:1: warning: the frame size of 2084 bytes is larger than 100 bytes [-Wframe-larger-than=] === /home/arnd/cross-gcc/bin/am33_2.0-linux-gcc-5.2.1 === ../../crypto/wp512.c:987:1: warning: the frame size of 2084 bytes is larger than 100 bytes [-Wframe-larger-than=] ../../crypto/wp512.c:987:1: warning: the frame size of 2208 bytes is larger than 100 bytes [-Wframe-larger-than=] === /home/arnd/cross-gcc/bin/cris-linux-gcc-4.9.3 === ../../crypto/wp512.c:987:1: warning: the frame size of 272 bytes is larger than 100 bytes [-Wframe-larger-than=] ../../crypto/wp512.c:987:1: warning: the frame size of 272 bytes is larger than 100 bytes [-Wframe-larger-than=] === /home/arnd/cross-gcc/bin/frv-linux-gcc-4.9.3 === ../../crypto/wp512.c:987:1: warning: the frame size of 296 bytes is larger than 100 bytes [-Wframe-larger-than=] ../../crypto/wp512.c:987:1: warning: the frame size of 1128 bytes is larger than 100 bytes [-Wframe-larger-than=] === /home/arnd/cross-gcc/bin/hppa64-linux-gcc-4.9.3 === ../../crypto/wp512.c:987:1: warning: the frame size of 192 bytes is larger than 100 bytes [-Wframe-larger-than=] ../../crypto/wp512.c:987:1: warning: the frame size of 1128 bytes is larger than 100 bytes [-Wframe-larger-than=] === /home/arnd/cross-gcc/bin/hppa-linux-gcc-4.9.3 === ../../crypto/wp512.c:987:1: warning: the frame size of 276 bytes is larger than 100 bytes [-Wframe-larger-than=] ../../crypto/wp512.c:987:1: warning: the frame size of 644 bytes is larger than 100 bytes [-Wframe-larger-than=] === /home/arnd/cross-gcc/bin/i386-linux-gcc-4.9.3 === ../../crypto/wp512.c:987:1: warning: the frame size of 352 bytes is larger than 100 bytes [-Wframe-larger-than=] ../../crypto/wp512.c:987:1: warning: the frame size of 352 bytes is larger than 100 bytes [-Wframe-larger-than=] === /home/arnd/cross-gcc/bin/m32r-linux-gcc-4.9.3 === ../../crypto/wp512.c:987:1: warning: the frame size of 332 bytes is larger than 100 bytes [-Wframe-larger-than=] ../../crypto/wp512.c:987:1: warning: the frame size of 716 bytes is larger than 100 bytes [-Wframe-larger-than=] === /home/arnd/cross-gcc/bin/m68k-linux-gcc-6.0.0 === ../../crypto/wp512.c:987:1: warning: the frame size of 364 bytes is larger than 100 bytes [-Wframe-larger-than=] ../../crypto/wp512.c:987:1: warning: the frame size of 364 bytes is larger than 100 bytes [-Wframe-larger-than=] === /home/arnd/cross-gcc/bin/microblaze-linux-gcc-4.9.3 === ../../crypto/wp512.c:987:1: warning: the frame size of 280 bytes is larger than 100 bytes [-Wframe-larger-than=] ../../crypto/wp512.c:987:1: warning: the frame size of 1108 bytes is larger than 100 bytes [-Wframe-larger-than=] === /home/arnd/cross-gcc/bin/mips64-linux-gcc-4.9.3 === ../../crypto/wp512.c:987:1: warning: the frame size of 208 bytes is larger than 100 bytes [-Wframe-larger-than=] ../../crypto/wp512.c:987:1: warning: the frame size of 1328 bytes is larger than 100 bytes [-Wframe-larger-than=] === /home/arnd/cross-gcc/bin/mips-linux-gcc-4.9.3 === ../../crypto/wp512.c:987:1: warning: the frame size of 272 bytes is larger than 100 bytes [-Wframe-larger-than=] ../../crypto/wp512.c:987:1: warning: the frame size of 1096 bytes is larger than 100 bytes [-Wframe-larger-than=] === /home/arnd/cross-gcc/bin/mips-linux-gcc-7.0.0 === ../../crypto/wp512.c:987:1: warning: the frame size of 304 bytes is larger than 100 bytes [-Wframe-larger-than=] ../../crypto/wp512.c:987:1: warning: the frame size of 1128 bytes is larger than 100 bytes [-Wframe-larger-than=] === /home/arnd/cross-gcc/bin/powerpc64-linux-gcc-4.9.3 === ../../crypto/wp512.c:987:1: warning: the frame size of 144 bytes is larger than 100 bytes [-Wframe-larger-than=] ../../crypto/wp512.c:987:1: warning: the frame size of 1088 bytes is larger than 100 bytes [-Wframe-larger-than=] === /home/arnd/cross-gcc/bin/powerpc-linux-gcc-4.9.3 === ../../crypto/wp512.c:987:1: wa
[Bug tree-optimization/79159] [7 regression] spurious array-bounds warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79159 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0 --- Comment #2 from Richard Biener --- I will have a looksee.
[Bug fortran/79157] gfortran crashed on sparc with openmpi build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79157 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-01-20 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Could you please post the file conftestf.f? TIA.
[Bug ipa/79043] Wrong code with optimize(("-fno-strict-aliasing")) and always_inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79043 --- Comment #4 from Martin Liška --- Author: marxin Date: Fri Jan 20 09:33:15 2017 New Revision: 244691 URL: https://gcc.gnu.org/viewcvs?rev=244691&root=gcc&view=rev Log: Reload global options when strict aliasing is dropped (PR ipa/79043). 2017-01-20 Martin Liska Backport from mainline 2017-01-13 Martin Liska PR ipa/79043 * function.c (set_cfun): Add new argument force. * function.h (set_cfun): Likewise. * ipa-inline-transform.c (inline_call): Use the function when strict alising from is dropped for function we inline to. 2017-01-20 Martin Liska Backport from mainline 2017-01-13 Martin Liska PR ipa/79043 * gcc.c-torture/execute/pr79043.c: New test. Added: branches/gcc-6-branch/gcc/testsuite/gcc.c-torture/execute/pr79043.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/function.c branches/gcc-6-branch/gcc/function.h branches/gcc-6-branch/gcc/ipa-inline-transform.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug ipa/79043] Wrong code with optimize(("-fno-strict-aliasing")) and always_inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79043 --- Comment #5 from Martin Liška --- Fixed on GCC 6 branch, following 2 revisions will be needed to fix GCC 5 branch: r231095 and r231125. I've been testing the GCC 5 branch.
[Bug lto/69188] [5/6/7 Regression] ICE when linking objects at different optimization levels with LTO and profile generation enabled. (Works with 4.9.3.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69188 --- Comment #20 from Martin Liška --- Author: marxin Date: Fri Jan 20 09:45:04 2017 New Revision: 244692 URL: https://gcc.gnu.org/viewcvs?rev=244692&root=gcc&view=rev Log: Do not declare artificial variables in tree-profile.c to have a definition (PR lto/69188). 2017-01-20 Martin Liska PR lto/69188 * gcc.dg/lto/pr69188_0.c: New test. * gcc.dg/lto/pr69188_1.c: New test. 2017-01-20 Martin Liska PR lto/69188 * tree-profile.c (init_ic_make_global_vars): Do not call finalize_decl. (gimple_init_gcov_profiler): Likewise. Added: trunk/gcc/testsuite/gcc.dg/lto/pr69188_0.c trunk/gcc/testsuite/gcc.dg/lto/pr69188_1.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-profile.c
[Bug lto/69188] [5/6 Regression] ICE when linking objects at different optimization levels with LTO and profile generation enabled. (Works with 4.9.3.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69188 Martin Liška changed: What|Removed |Added Summary|[5/6/7 Regression] ICE when |[5/6 Regression] ICE when |linking objects at |linking objects at |different optimization |different optimization |levels with LTO and profile |levels with LTO and profile |generation enabled. (Works |generation enabled. (Works |with 4.9.3.)|with 4.9.3.) Known to fail|7.0 | --- Comment #21 from Martin Liška --- Fixed on trunk.
[Bug c/79152] -Wimplicit-fallthrough false positive triggered by goto statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79152
--- Comment #2 from Jakub Jelinek ---
Simplified testcase:
int
foo (int x, char *y)
{
switch (x)
{
case 1:
goto lab1;
goto lab2;
x = y[0];
lab2:
lab1:
x += y[1];
}
return x;
}
[Bug c/79152] -Wimplicit-fallthrough false positive triggered by goto statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79152 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- Mine.
[Bug c/79153] -Wimplicit-fallthrough missed warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79153 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Mine.
[Bug c/79153] -Wimplicit-fallthrough missed warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79153 --- Comment #3 from Jakub Jelinek --- Adding default: break; to the inner switch doesn't help, adding any non-switch statement after the inner switch helps.
[Bug tree-optimization/79159] [7 regression] spurious array-bounds warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79159
Richard Biener changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
--- Comment #3 from Richard Biener ---
Suspiciously similar to PR71437 we have different ASSERT_EXPR order for the
first if (i_1 < _9) / if (_2 > _i_3) condition which downthread leads to
different value numbers. In this case the "good" order is the other one
though...
(but it produces the same good symbolic range):
here i_1 = [0, 0] and _9 is VARYING.
Visiting statement:
i_2 = ASSERT_EXPR ;
Applying pattern match.pd:695, generic-match.c:64
Applying pattern match.pd:732, generic-match.c:10709
Intersecting
[-INF, _9 + -1] EQUIVALENCES: { i_1 } (1 elements)
and
[0, 0]
Applying pattern match.pd:1771, generic-match.c:1258
Applying pattern match.pd:1771, generic-match.c:1258
to
[-INF, _9 + -1] EQUIVALENCES: { i_1 } (1 elements)
Found new range for i_2: [-INF, _9 + -1]
Visiting statement:
_36 = ASSERT_EXPR <_9, _9 > i_2>;
Intersecting
[i_2 + 1, +INF] EQUIVALENCES: { _9 } (1 elements)
and
VARYING
to
[i_2 + 1, +INF] EQUIVALENCES: { _9 } (1 elements)
Found new range for _36: [i_2 + 1, +INF]
and for the bad case, i_3 is [0, 0], _2 is VARYING:
Visiting statement:
_40 = ASSERT_EXPR <_2, _2 > i_3>;
Intersecting
[1, +INF] EQUIVALENCES: { _2 } (1 elements)
and
VARYING
to
[1, +INF] EQUIVALENCES: { _2 } (1 elements)
Found new range for _40: [1, +INF]
Visiting statement:
i_36 = ASSERT_EXPR ;
Intersecting
[-INF, 2147483646] EQUIVALENCES: { i_3 } (1 elements)
and
[0, 0]
to
[0, 0] EQUIVALENCES: { i_3 } (1 elements)
Intersecting
[0, 0] EQUIVALENCES: { i_3 } (1 elements)
and
[0, +INF]
to
[0, 0] EQUIVALENCES: { i_3 } (1 elements)
Found new range for i_36: [0, 0]
Final ranges are
i_2: [-INF, _9 + -1] EQUIVALENCES: { i_1 } (1 elements)
_36: [i_2 + 1, +INF] EQUIVALENCES: { _9 } (1 elements)
vs.
i_36: [0, 2147483646] EQUIVALENCES: { i_3 } (1 elements)
_40: [1, +INF] EQUIVALENCES: { _2 } (1 elements)
and the array ref we warn for has
j_11: [-INF, _56 + -1] EQUIVALENCES: { j_54 } (1 elements)
vs.
j_1: [9, 2147483646] EQUIVALENCES: { j_54 } (1 elements)
where we simply give up for the symbolic range case on the GCC 6 branch.
So the issue is not really VRP but that peeling of the inner loop
sometimes produces an extra copy with an out-of-bound access and even
VRP cannot prove the block is never reached. It's guarded by if (_4 > j_54)
and we have
_4: [9, +INF] EQUIVALENCES: { _2 _40 _41 _45 _46 _50 _51 _55 _56 } (9
elements)
j_54: [9, +INF(OVF)]
[Bug middle-end/60762] [ASAN] -fsanitize=address fails with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60762 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-01-20 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Martin Liška --- Can't reproduce, may I close the issue?
[Bug bootstrap/78985] [7 Regression] profiledbootstrap failure by -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78985 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Does it worth reducing the test-case? If so, I can help you.
[Bug bootstrap/78985] [7 Regression] profiledbootstrap failure by -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78985 --- Comment #2 from rguenther at suse dot de --- On Fri, 20 Jan 2017, marxin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78985 > > Martin Liška changed: > >What|Removed |Added > > CC||marxin at gcc dot gnu.org > > --- Comment #1 from Martin Liška --- > Does it worth reducing the test-case? > If so, I can help you. Possibly yes (but it's FDO...). I guess we need to paper over it or fix the uninit pass. So maybe bisecting is more useful
[Bug fortran/79157] gfortran crashed on sparc with openmpi build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79157 --- Comment #2 from Igor Kozhukhov --- Created attachment 40551 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40551&action=edit conftestf.c test C file from configure
[Bug fortran/79157] gfortran crashed on sparc with openmpi build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79157 --- Comment #3 from Igor Kozhukhov --- Created attachment 40552 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40552&action=edit conftestf.f test fortran file from configure
[Bug fortran/79157] gfortran crashed on sparc with openmpi build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79157 --- Comment #4 from Igor Kozhukhov --- how to use test files: gcc -DNDEBUG -g -O2 -mcpu=v9 -D_REENTRANT -finline-functions -fno-strict-aliasing -I. -c conftest.c gfortran -g -O2 conftestf.f conftest.o -o conftest i have tested by gcc-5.4 - gfortran failed, but with gcc-6.3 - gfortran-6 works fine. and i was able to build openmpi on sparc by gcc-6.3
[Bug fortran/79157] gfortran crashed on sparc with openmpi build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79157 --- Comment #5 from Igor Kozhukhov --- forgot to add info about gcc-6 $ gcc-6 -v Using built-in specs. COLLECT_GCC=gcc-6 COLLECT_LTO_WRAPPER=/usr/gcc/6/lib/gcc/sparcv9-sun-solaris2.11/6.3.0/lto-wrapper Target: sparcv9-sun-solaris2.11 Configured with: ../configure --prefix=/usr/gcc/6 --build=sparcv9-sun-solaris2.11 --bindir=/usr/gcc/6/bin --sbindir=/usr/gcc/6/sbin --libdir=/usr/gcc/6/lib --libexecdir=/usr/gcc/6/lib --infodir=/usr/gcc/6/share/info --mandir=/usr/gcc/6/share/man --target=sparcv9-sun-solaris2.11 --enable-targets=sparc-sun-solaris2.11 --enable-shared --enable-plugins --enable-lto --enable-initfini-array --enable-tls --enable-threads=posix --without-gnu-ld --with-ld=/usr/bin/ld --with-system-zlib gcc_cv_ld_as_needed=no --enable-languages=c,c++,fortran,objc,go --with-gnu-as --with-as=/usr/bin/gas Thread model: posix gcc version 6.3.0 (GCC) i have the same bootstrap for gcc-5 & gcc-6 in 64bits: gcc + GNU AS + illumos ld i have GNU binutils 64bits too. i'm using 64bits bootstrap on my intel & sparc a long time from gcc-4.8.
[Bug middle-end/79161] New: possibly lost DCE optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79161
Bug ID: 79161
Summary: possibly lost DCE optimization
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: skvadrik at gmail dot com
Target Milestone: ---
Created attachment 40553
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40553&action=edit
a.c
Consider the following example (a.c in attach):
static void f(const char *s)
{
for (; *s++ == '0'; );
}
int main(int argc, char **argv)
{
const char *s0 = argv[1];
for (int x = 0; x < 10; ++x) f(s0);
return 0;
}
Clang thinks this can be optimized to just 'return 0':
$ clang++-3.9 -c -O2 a.c -oa.o && objdump -d a.o
clang-3.9: warning: treating 'c' input as 'c++' when in C++ mode, this behavior
is deprecated
a.o: file format elf64-x86-64
Disassembly of section .text:
:
0: 31 c0 xor%eax,%eax
2: c3 retq
While GCC doesn't:
$ g++ -c -O2 a.c -oa.o && objdump -d a.o
a.o: file format elf64-x86-64
Disassembly of section .text.startup:
:
0: 48 8b 4e 08 mov0x8(%rsi),%rcx
4: ba 00 ca 9a 3b mov$0x3b9aca00,%edx
9: 0f 1f 80 00 00 00 00nopl 0x0(%rax)
10: 48 89 c8mov%rcx,%rax
13: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
18: 48 83 c0 01 add$0x1,%rax
1c: 80 78 ff 30 cmpb $0x30,-0x1(%rax)
20: 74 f6 je 18
22: 83 ea 01sub$0x1,%edx
25: 75 e9 jne10
27: 31 c0 xor%eax,%eax
29: c3 retq
I'm not sure if optimization is rightful but it looks correct to me. I don't
see any side effects in 'f' function.
[Bug rtl-optimization/79149] bad optimization on MIPS and ARM leading to excessive stack usage in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79149 Arnd Bergmann changed: What|Removed |Added Attachment #40546|0 |1 is obsolete|| --- Comment #2 from Arnd Bergmann --- Created attachment 40554 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40554&action=edit wp512 reference source code, standalone version After checking a bit more, I found that the reference source code implementation does behave exactly like the in-kernel version after all, and I was able to do some performance timing (using qemu-user) on it as well. Building Whirlpool.c using "mips64el-linux-gnuabi64-gcc-5 -O2 -Wframe-larger-than=100 Whirlpool.c -o Whirlpool-mips-smallstack -fno-sched-critical-path-heuristic -fno-sched-dep-count-heuristic" in this case uses 256 bytes of stack in the processBuffer and run for 87 seconds doing 1000 iterations in qemu, while the version without "fno-sched-critical-path-heuristic -fno-sched-dep-count-heuristic" takes 230 seconds and needs 1520 bytes of stack. The extra time is apparently spent spilling registers to the stack. The same test with arm32 shows a less significant version of the same behavior, with the stack shrinking from 832 to 352 bytes, and the time improving from 301 seconds to 217 seconds. Obviously it would be helpful to do the same tests on actual hardware, as benchmarking in an emulated machine can be very misleading.
[Bug rtl-optimization/79121] [6 Regression] invalid expansion of sign-extend unsigned plus left shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79121 --- Comment #4 from Richard Earnshaw --- Author: rearnsha Date: Fri Jan 20 11:43:58 2017 New Revision: 244702 URL: https://gcc.gnu.org/viewcvs?rev=244702&root=gcc&view=rev Log: [expand] Fix for PR rtl-optimization/79121 incorrect expansion of extend plus left shift When generating a shift from an extended value moving from one to two machine registers, the type of the right shift is for the most significant word should be determined by the signedness of the inner type, not the signedness of the result type. gcc: PR rtl-optimization/79121 * expr.c (expand_expr_real_2, case LSHIFT_EXPR): Look at the signedness of the inner type when shifting an extended value. gcc/testsuite: * gcc.c-torture/execute/pr79121.c: New test. Added: branches/gcc-6-branch/gcc/testsuite/gcc.c-torture/execute/pr79121.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/expr.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/79161] possibly lost DCE / invariant motion optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79161
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-01-20
CC||rguenth at gcc dot gnu.org
Component|middle-end |tree-optimization
Summary|possibly lost DCE |possibly lost DCE /
|optimization|invariant motion
||optimization
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
f reads from memory (which may trap). We fail the opportunity to hoist f as
loop invariant which is because we choose to inline it (and we can't move
invariant sub-loops). Confirmed for that.
Note I think we do not necessarily have to preserve the possible trap so we
fail to optimize the loop in
f (const char * s)
{
char _2;
[0.00%]:
[0.00%]:
# s_3 = PHI
s_5 = s_3 + 1;
_2 = *s_3;
if (_2 == 48)
goto ; [0.00%]
else
goto ; [0.00%]
[0.00%]:
return;
as dead which we do not because we can't prove the finiteness of this loop
(because of the implementation detail how we do that).
[Bug rtl-optimization/79121] [6/7 Regression] invalid expansion of sign-extend unsigned plus left shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79121 Richard Earnshaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Summary|[6 Regression] invalid |[6/7 Regression] invalid |expansion of sign-extend|expansion of sign-extend |unsigned plus left shift|unsigned plus left shift --- Comment #5 from Richard Earnshaw --- Fixed on gcc-6 and trunk.
[Bug c/64279] Warning missing for "(cond) ? A : A" / if(cond) expr1; else expr1; // same expression in if and else branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64279 --- Comment #6 from Marek Polacek --- Author: mpolacek Date: Fri Jan 20 12:02:50 2017 New Revision: 244705 URL: https://gcc.gnu.org/viewcvs?rev=244705&root=gcc&view=rev Log: PR c/64279 * c-common.h (do_warn_duplicated_branches_r): Declare. * c-gimplify.c (c_genericize): Walk the function tree calling do_warn_duplicated_branches_r. * c-warn.c (expr_from_macro_expansion_r): New. (do_warn_duplicated_branches): New. (do_warn_duplicated_branches_r): New. * c.opt (Wduplicated-branches): New option. * c-typeck.c (build_conditional_expr): Warn about duplicated branches. * call.c (build_conditional_expr_1): Warn about duplicated branches. * semantics.c (finish_expr_stmt): Build statement using the proper location. * doc/invoke.texi: Document -Wduplicated-branches. * fold-const.c (operand_equal_p): Handle MODIFY_EXPR, INIT_EXPR, COMPOUND_EXPR, PREDECREMENT_EXPR, PREINCREMENT_EXPR, POSTDECREMENT_EXPR, POSTINCREMENT_EXPR, CLEANUP_POINT_EXPR, EXPR_STMT, STATEMENT_LIST, and RETURN_EXPR. For non-pure non-const functions return 0 only when not OEP_LEXICOGRAPHIC. (fold_build_cleanup_point_expr): Use the expression location when building CLEANUP_POINT_EXPR. * tree-core.h (enum operand_equal_flag): Add OEP_LEXICOGRAPHIC. * tree.c (add_expr): Handle error_mark_node. * c-c++-common/Wduplicated-branches-1.c: New test. * c-c++-common/Wduplicated-branches-10.c: New test. * c-c++-common/Wduplicated-branches-11.c: New test. * c-c++-common/Wduplicated-branches-12.c: New test. * c-c++-common/Wduplicated-branches-2.c: New test. * c-c++-common/Wduplicated-branches-3.c: New test. * c-c++-common/Wduplicated-branches-4.c: New test. * c-c++-common/Wduplicated-branches-5.c: New test. * c-c++-common/Wduplicated-branches-6.c: New test. * c-c++-common/Wduplicated-branches-7.c: New test. * c-c++-common/Wduplicated-branches-8.c: New test. * c-c++-common/Wduplicated-branches-9.c: New test. * c-c++-common/Wimplicit-fallthrough-7.c: Coalesce dg-warning. * g++.dg/cpp0x/lambda/lambda-switch.C: Move dg-warning. * g++.dg/ext/builtin-object-size3.C: Likewise. * g++.dg/gomp/loop-1.C: Likewise. * g++.dg/warn/Wduplicated-branches1.C: New test. * g++.dg/warn/Wduplicated-branches2.C: New test. Added: trunk/gcc/testsuite/c-c++-common/Wduplicated-branches-1.c trunk/gcc/testsuite/c-c++-common/Wduplicated-branches-10.c trunk/gcc/testsuite/c-c++-common/Wduplicated-branches-11.c trunk/gcc/testsuite/c-c++-common/Wduplicated-branches-12.c trunk/gcc/testsuite/c-c++-common/Wduplicated-branches-2.c trunk/gcc/testsuite/c-c++-common/Wduplicated-branches-3.c trunk/gcc/testsuite/c-c++-common/Wduplicated-branches-4.c trunk/gcc/testsuite/c-c++-common/Wduplicated-branches-5.c trunk/gcc/testsuite/c-c++-common/Wduplicated-branches-6.c trunk/gcc/testsuite/c-c++-common/Wduplicated-branches-7.c trunk/gcc/testsuite/c-c++-common/Wduplicated-branches-8.c trunk/gcc/testsuite/c-c++-common/Wduplicated-branches-9.c trunk/gcc/testsuite/g++.dg/warn/Wduplicated-branches1.C trunk/gcc/testsuite/g++.dg/warn/Wduplicated-branches2.C Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.h trunk/gcc/c-family/c-gimplify.c trunk/gcc/c-family/c-warn.c trunk/gcc/c-family/c.opt trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/semantics.c trunk/gcc/doc/invoke.texi trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/Wimplicit-fallthrough-7.c trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-switch.C trunk/gcc/testsuite/g++.dg/ext/builtin-object-size3.C trunk/gcc/testsuite/g++.dg/gomp/loop-1.C trunk/gcc/tree-core.h trunk/gcc/tree.c
[Bug libstdc++/72792] allocator_traits is too strict about rebinding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72792 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Fri Jan 20 12:03:36 2017 New Revision: 244706 URL: https://gcc.gnu.org/viewcvs?rev=244706&root=gcc&view=rev Log: PR72792 detect allocator pointer types without invalid rebinding PR libstdc++/72792 * include/bits/alloc_traits.h (__allocator_traits_base::__diff_type) (__allocator_traits_base::__size_type): Remove. (allocator_traits::_Ptr): New class template to detect const and void pointer types without instantiating pointer_traits::rebind unnecessarily. (allocator_traits::_Diff): Likewise for detecting difference_type. (allocator_traits::_Size): New class template to detect size_type without instantiating make_unsigned unnecessarily. * include/bits/ptr_traits.h (pointer_traits::element_type): Use __detected_or_t instead of __detected_or_t_. * include/std/type_traits (__detected_or_t_): Remove. * testsuite/20_util/allocator_traits/members/pointers.cc: New test. Added: trunk/libstdc++-v3/testsuite/20_util/allocator_traits/members/pointers.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/alloc_traits.h trunk/libstdc++-v3/include/bits/ptr_traits.h trunk/libstdc++-v3/include/std/type_traits
[Bug c/64279] Warning missing for "(cond) ? A : A" / if(cond) expr1; else expr1; // same expression in if and else branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64279 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Marek Polacek --- Done for GCC 7.
[Bug ipa/70366] [6 Regression] chromium fails to build with LTO due to segfault in ipa-inline-transform.c:inline_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70366 --- Comment #8 from Martin Liška --- Author: marxin Date: Fri Jan 20 12:04:46 2017 New Revision: 244708 URL: https://gcc.gnu.org/viewcvs?rev=244708&root=gcc&view=rev Log: 2016-03-26 Richard Biener Prathamesh Kulkarni 2017-01-20 Martin Liska Backport from mainline 2016-03-26 Richard Biener Prathamesh Kulkarni PR ipa/70366 * ipa-inline-transform.c (inline_call): Pass opts_for_fn (to->decl) instead of TREE_OPTIMIZATION (DECL_FUNCTION_SPECIFIC_OPTIMIZATION (to->decl)) as 2nd argument to cl_optimization_restore(). Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/ipa-inline-transform.c
[Bug libstdc++/79162] New: [7 Regression] [C++17] ambiguity in string assignment due to string_view overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79162
Bug ID: 79162
Summary: [7 Regression] [C++17] ambiguity in string assignment
due to string_view overload
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#include
int main() {
std::string s;
s = {"abc", 1};
}
This compiled with GCC 6, but with 7 gives:
s.cc: In function ‘int main()’:
s.cc:5:15: error: ambiguous overload for ‘operator=’ (operand types are
‘std::__cxx11::string {aka std::__cxx11::basic_string}’ and
‘’)
s = {"abc", 1};
^
In file included from /home/jwakely/gcc/7/include/c++/7.0.0/string:52:0,
from s.cc:1:
/home/jwakely/gcc/7/include/c++/7.0.0/bits/basic_string.h:627:7: note:
candidate: std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator=(const
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char;
_Traits = std::char_traits; _Alloc = std::allocator]
operator=(const basic_string& __str)
^~~~
/home/jwakely/gcc/7/include/c++/7.0.0/bits/basic_string.h:680:7: note:
candidate: std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::operator=(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&&) [with
_CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]
operator=(basic_string&& __str)
^~~~
/home/jwakely/gcc/7/include/c++/7.0.0/bits/basic_string.h:747:7: note:
candidate: std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::operator=(std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::__sv_type) [with _CharT = char; _Traits = std::char_traits;
_Alloc = std::allocator; std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::__sv_type = std::basic_string_view]
operator=(__sv_type __sv)
^~~~
[Bug ipa/79043] Wrong code with optimize(("-fno-strict-aliasing")) and always_inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79043 --- Comment #6 from Martin Liška --- Author: marxin Date: Fri Jan 20 12:09:22 2017 New Revision: 244709 URL: https://gcc.gnu.org/viewcvs?rev=244709&root=gcc&view=rev Log: Reload global options when strict aliasing is dropped (PR ipa/79043). 2017-01-20 Martin Liska Backport from mainline 2017-01-13 Martin Liska PR ipa/79043 * function.c (set_cfun): Add new argument force. * function.h (set_cfun): Likewise. * ipa-inline-transform.c (inline_call): Use the function when strict alising from is dropped for function we inline to. 2017-01-20 Martin Liska Backport from mainline 2017-01-13 Martin Liska PR ipa/79043 * gcc.c-torture/execute/pr79043.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/gcc.c-torture/execute/pr79043.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/function.c branches/gcc-5-branch/gcc/function.h branches/gcc-5-branch/gcc/ipa-inline-transform.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug libstdc++/79162] [7 Regression] [C++17] ambiguity in string assignment due to string_view overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79162 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0
[Bug ipa/79043] Wrong code with optimize(("-fno-strict-aliasing")) and always_inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79043 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Martin Liška --- Fixed on gcc 5 branch.
[Bug c++/40901] Access qualifiers of embedded templates are discarded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40901
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Last reconfirmed|2012-02-01 00:00:00 |
Resolution|--- |FIXED
Target Milestone|--- |4.9.0
--- Comment #5 from Jonathan Wakely ---
This seems to have been fixed for 4.9.0
Comment 1 now gives:
a.cc: In function ‘int main()’:
a.cc:17:11: error: ‘template struct A::s’ is private
within this context
cout << A::s<10>::value << endl;
^
a.cc:7:10: note: declared private here
struct s {
^
Comment 2 now gives:
a.cc:7:9: error: ‘template > struct A::s’ is private within
this context
int i = A::s<10>::value;
^
a.cc:2:25: note: declared private here
template struct s {
^
And comment 3 now gives:
a.cc:12:1: error: ‘struct C::Private’ is private within this context
exploit::type x2; // should be an error
^~~
a.cc:3:10: note: declared private here
struct Private { };
^~~
[Bug c++/59002] [meta-bug] Access checking in templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59002 Bug 59002 depends on bug 40901, which changed state. Bug 40901 Summary: Access qualifiers of embedded templates are discarded https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40901 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug rtl-optimization/79149] bad optimization on MIPS and ARM leading to excessive stack usage in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79149 --- Comment #3 from Andrew Pinski --- There is another bug referring to the pre-register allocation schedule messing up. X86 does not have this scheduler turNed on by default.
[Bug rtl-optimization/79149] bad optimization on MIPS and ARM leading to excessive stack usage in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79149 --- Comment #4 from Andrew Pinski --- Can you try -fno-sched-insns?
[Bug c++/79163] New: Access-checking not done in template argument list of partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79163
Bug ID: 79163
Summary: Access-checking not done in template argument list of
partial specialization
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Blocks: 59002
Target Milestone: ---
Access-checking is not done in the template-id of a class template partial
specialization, but is done in the body.
This breaks the "detection idiom" as used by std::allocator_traits and
std::pointer_traits, because the check for whether a substituted type is valid
ignores access, and then an invalid type gets used.
template
using void_t = void;
template
struct Detect
{ using type = int; };
template
struct Detect>
{ using type = typename T::type; };
class X { using type = long; };
Detect::type i;
This should compile, but issues five very similar errors, but using three
different locations:
access.cc: In instantiation of ‘struct Detect’:
access.cc:14:10: required from here
access.cc:10:3: error: ‘using type = long int’ is private within this context
{ using type = typename T::type; };
^
access.cc:12:28: note: declared private here
class X { using type = long; };
^
access.cc:10:3: error: ‘using type = long int’ is private within this context
{ using type = typename T::type; };
^
access.cc:12:28: note: declared private here
class X { using type = long; };
^
access.cc:10:34: error: ‘using type = long int’ is private within this context
{ using type = typename T::type; };
^
access.cc:12:28: note: declared private here
class X { using type = long; };
^
access.cc:10:34: error: ‘using type = long int’ is private within this context
{ using type = typename T::type; };
^
access.cc:12:28: note: declared private here
class X { using type = long; };
^
access.cc:14:1: error: ‘using type = long int’ is private within this context
Detect::type i;
^
access.cc:12:28: note: declared private here
class X { using type = long; };
^
Clang compiles this successfully, although EDG fails in the same way as GCC
(but only issues one error):
"access.cc", line 10: error: type "X::type" (declared at line 12) is
inaccessible
{ using type = typename T::type; };
^
detected during instantiation of class "Detect [with T=X]"
at line 14
1 error detected in the compilation of "access.cc".
This has some similarities to Bug 40901 but that was fixed in 4.9.0
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59002
[Bug 59002] [meta-bug] Access checking in templates
[Bug c/79164] New: -Wduplicated-branches and macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79164
Bug ID: 79164
Summary: -Wduplicated-branches and macros
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
-Wduplicated-branches doesn't warn on
#include
int *
f (int i)
{
if (i > 9)
return NULL;
else
return NULL;
}
because at least one expression from both arms comes from a macro. But in this
case we should apparently warn. We'll have to compare the expressions
side-by-side and decide if they're the same even from the macro expansion point
of view.
[Bug c/79164] -Wduplicated-branches and macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79164 Marek Polacek changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-01-20 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Mine.
[Bug c++/79163] Access-checking not done in template argument list of partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79163
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-01-20
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
With 4.9 and earlier you only get the error once:
access.cc: In instantiation of ‘struct Detect’:
access.cc:14:10: required from here
access.cc:12:28: error: ‘using type = long int’ is private
class X { using type = long; };
^
access.cc:10:34: error: within this context
{ using type = typename T::type; };
^
So the repeated diagnostics is a regression, but it would be better not to
issue any diagnostics at all.
[Bug go/79146] [7 Regression] Bootstrapping go on s390x fails; redefined symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79146 --- Comment #3 from Richard Biener --- Didn't really help: [ 2448s] ../s390x-suse-linux/libgo/.libs/libgo.so: undefined reference to `math_ big.hasVectorFacility' [ 2448s] collect2: error: ld returned 1 exit status
[Bug c/79152] -Wimplicit-fallthrough false positive triggered by goto statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79152
--- Comment #4 from Marek Polacek ---
I think the problem is that
1988 /* Don't warn for a non-case label followed by a statement:
1989case 0:
1990 foo ();
1991label:
1992 bar ();
1993 as these are likely intentional. */
1994 if (!case_label_p (&gimplify_ctxp->case_labels, label))
1995 {
1996 gsi_next (&gsi);
1997 if (gsi_end_p (gsi) || gimple_code (gsi_stmt (gsi)) !=
GIMPLE_LABEL)
1998 return false;
1999 }
doesn't handle consecutive non-case labels.
[Bug fortran/79165] New: [7 Regression] 100% compile-time increase between r244557 and r244598
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79165 Bug ID: 79165 Summary: [7 Regression] 100% compile-time increase between r244557 and r244598 Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: compile-time-hog Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org CC: vehre at gcc dot gnu.org Target Milestone: --- http://gcc.opensuse.org/c++bench-czerny/pb11/pb11-summary.txt-1-0.html I almost bet it's r244587?
[Bug fortran/79165] [7 Regression] 100% compile-time increase between r244557 and r244598
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79165
--- Comment #1 from Richard Biener ---
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(revision 244586)
+++ gcc/fortran/trans-expr.c(revision 244587)
@@ -1839,11 +1839,10 @@ gfc_get_tree_for_caf_expr (gfc_expr *exp
}
/* Make sure the backend_decl is present before accessing it. */
- if (expr->symtree->n.sym->backend_decl == NULL_TREE)
-expr->symtree->n.sym->backend_decl
- = gfc_get_symbol_decl (expr->symtree->n.sym);
- caf_decl = expr->symtree->n.sym->backend_decl;
- gcc_assert (caf_decl);
+ caf_decl = expr->symtree->n.sym->backend_decl == NULL_TREE
+ ? gfc_get_symbol_decl (expr->symtree->n.sym)
+ : expr->symtree->n.sym->backend_decl;
+
if (expr->symtree->n.sym->ts.type == BT_CLASS)
{
if (expr->ref && expr->ref->type == REF_ARRAY)
removes setting expr->symtree->n.sym->backend_decl?
[Bug fortran/79165] [7 Regression] 100% compile-time increase between r244557 and r244598
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79165 Richard Biener changed: What|Removed |Added CC||uros at gcc dot gnu.org Target Milestone|--- |7.0 --- Comment #2 from Richard Biener --- Though ia64 doesn't show the regression which would point at r244591.
[Bug fortran/79165] [7 Regression] 100% compile-time increase between r244557 and r244598
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79165 --- Comment #3 from Uroš Bizjak --- (In reply to Richard Biener from comment #2) > Though ia64 doesn't show the regression which would point at r244591. Almost unbeliveable, the patch effectively just adds two rarely used patterns. What happens if you back the mentioned patch out?
[Bug bootstrap/78985] [7 Regression] profiledbootstrap failure by -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78985 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-01-20 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Martin Liška --- I'll try to bisect that, on aarch64 machine I see: ../../gcc/config/aarch64/cortex-a57-fma-steering.c: In member function ‘void func_fma_steering::analyze()’: ../../gcc/config/aarch64/cortex-a57-fma-steering.c:979:53: error: ‘head’ may be used uninitialized in this function [-Werror=maybe-uninitialized] this->analyze_fma_fmul_insn (forest, chain, head); ^ ../../gcc/config/aarch64/cortex-a57-fma-steering.c:979:53: error: ‘forest’ may be used uninitialized in this function [-Werror=maybe-uninitialized] ../../gcc/config/aarch64/cortex-a57-fma-steering.c:979:53: error: ‘chain’ may be used uninitialized in this function [-Werror=maybe-uninitialized] I'll try to bisect..
[Bug bootstrap/78985] [7 Regression] profiledbootstrap failure by -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78985 --- Comment #4 from rguenther at suse dot de --- On Fri, 20 Jan 2017, marxin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78985 > > Martin Liška changed: > >What|Removed |Added > > Status|UNCONFIRMED |NEW >Last reconfirmed||2017-01-20 >Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot > gnu.org > Ever confirmed|0 |1 > > --- Comment #3 from Martin Liška --- > I'll try to bisect that, on aarch64 machine I see: > > ../../gcc/config/aarch64/cortex-a57-fma-steering.c: In member function ‘void > func_fma_steering::analyze()’: > ../../gcc/config/aarch64/cortex-a57-fma-steering.c:979:53: error: ‘head’ may > be > used uninitialized in this function [-Werror=maybe-uninitialized] > this->analyze_fma_fmul_insn (forest, chain, head); > ^ > ../../gcc/config/aarch64/cortex-a57-fma-steering.c:979:53: error: ‘forest’ may > be used uninitialized in this function [-Werror=maybe-uninitialized] > ../../gcc/config/aarch64/cortex-a57-fma-steering.c:979:53: error: ‘chain’ may > be used uninitialized in this function [-Werror=maybe-uninitialized] > > I'll try to bisect.. Yes, aarch64 has a similar issue.
[Bug bootstrap/78985] [7 Regression] profiledbootstrap failure by -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78985 --- Comment #5 from Martin Liška --- (In reply to rguent...@suse.de from comment #4) > On Fri, 20 Jan 2017, marxin at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78985 > > > > Martin Liška changed: > > > >What|Removed |Added > > > > Status|UNCONFIRMED |NEW > >Last reconfirmed||2017-01-20 > >Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot > > gnu.org > > Ever confirmed|0 |1 > > > > --- Comment #3 from Martin Liška --- > > I'll try to bisect that, on aarch64 machine I see: > > > > ../../gcc/config/aarch64/cortex-a57-fma-steering.c: In member function ‘void > > func_fma_steering::analyze()’: > > ../../gcc/config/aarch64/cortex-a57-fma-steering.c:979:53: error: ‘head’ > > may be > > used uninitialized in this function [-Werror=maybe-uninitialized] > > this->analyze_fma_fmul_insn (forest, chain, head); > > ^ > > ../../gcc/config/aarch64/cortex-a57-fma-steering.c:979:53: error: ‘forest’ > > may > > be used uninitialized in this function [-Werror=maybe-uninitialized] > > ../../gcc/config/aarch64/cortex-a57-fma-steering.c:979:53: error: ‘chain’ > > may > > be used uninitialized in this function [-Werror=maybe-uninitialized] > > > > I'll try to bisect.. > > Yes, aarch64 has a similar issue. This is aarch64 machine :) Do you remember whether profiledbootstrap used to succeed (for bisect start)?
[Bug fortran/79165] [7 Regression] 100% compile-time increase for polyhedron aermod between r244557 and r244598
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79165 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-01-20 CC||chefmax at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Richard Biener --- r244557: 19.77s r244586: 34.18s r244587: 33.91s so neither party is guilty... bisecting. r244575: 19.66s r244581: 33.84s r244578: 19.82s r244580: 19.76s r244581: 19.88s (?!) (just svn up -r and make all-gcc each time)
[Bug fortran/79165] [7 Regression] 100% compile-time increase for polyhedron aermod between r244557 and r244598
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79165 --- Comment #5 from Richard Biener --- (In reply to Richard Biener from comment #4) > r244557: 19.77s > r244586: 34.18s > r244587: 33.91s > > so neither party is guilty... bisecting. > > r244575: 19.66s > r244581: 33.84s > r244578: 19.82s > r244580: 19.76s > r244581: 19.88s (?!) ^^^ err, forgot the make all-gcc here it's really r244581, the tree.c hunk.
[Bug fortran/79165] [7 Regression] 100% compile-time increase for polyhedron aermod between r244557 and r244598
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79165 Richard Biener changed: What|Removed |Added Priority|P3 |P1 --- Comment #6 from Richard Biener --- build_translation_unit_decl is called exactly _once_ ... but it looks like the linemap operation screws up sth. Compiler command I used for reproducing: > ./f951 -quiet aermod.f90 -fno-checking -Ofast -march=core-avx2 -funroll-loops
[Bug target/79160] gcc.target/powerpc/vsx-elemrev-4.c fails on powerpc BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79160 Bill Schmidt changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot gnu.org --- Comment #2 from Bill Schmidt --- I'll look into it...
[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72785 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #23 from ktkachov at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #22) > (In reply to dhowe...@redhat.com from comment #21) > > (In reply to Markus Trippelsdorf from comment #20) > > > *** Bug 78879 has been marked as a duplicate of this bug. *** > > > > Kernel bug or not, it should be noted that this means that you cannot use > > gcc from r236831 to compile any kernel from the introduction and use of > > ilog2() to the current day - and these kernel versions cannot be > > retroactively fixed. > > No. I build allmodconfig kernels regularly with gcc trunk and it works fine. I still hit this when building an allmodconfig arm64 kernel with trunk
[Bug c++/78656] Fix-it suggestion for std::alocator doesn't include std::allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78656 --- Comment #3 from David Malcolm --- Author: dmalcolm Date: Fri Jan 20 14:36:46 2017 New Revision: 244715 URL: https://gcc.gnu.org/viewcvs?rev=244715&root=gcc&view=rev Log: C++: fix fix-it hints for misspellings within explicit namespaces gcc/cp/ChangeLog: PR c++/77829 PR c++/78656 * cp-tree.h (suggest_alternatives_for): Add bool param. (suggest_alternative_in_explicit_scope): New decl. * error.c (qualified_name_lookup_error): When SCOPE is a namespace that isn't the global one, call new function suggest_alternative_in_explicit_scope, only calling suggest_alternatives_for if it fails, and disabling near match searches fort that case. When SCOPE is the global namespace, pass true for new param to suggest_alternatives_for to allow for fuzzy name lookups. * lex.c (unqualified_name_lookup_error): Pass true for new param to suggest_alternatives_for. * name-lookup.c (consider_binding_level): Add forward decl. (suggest_alternatives_for): Add "suggest_misspellings" param, using it to conditionalize the fuzzy name-lookup code. (suggest_alternative_in_explicit_scope): New function. * parser.c (cp_parser_primary_expression): When calling finish_id_expression, pass location of id_expression rather than that of id_expr_token. (cp_parser_id_expression): Convert local "unqualified_id" from tree to cp_expr to avoid implicitly dropping location information. gcc/testsuite/ChangeLog: PR c++/77829 PR c++/78656 * g++.dg/spellcheck-pr77829.C: New test case. * g++.dg/spellcheck-pr78656.C: New test case. Added: trunk/gcc/testsuite/g++.dg/spellcheck-pr77829.C trunk/gcc/testsuite/g++.dg/spellcheck-pr78656.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/error.c trunk/gcc/cp/lex.c trunk/gcc/cp/name-lookup.c trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/79156] incorrect c++ usage in gcc7 void function returns a value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79156 --- Comment #4 from mib.bugzilla at gmail dot com --- Thank you so much! (That means I won't need to change the Intel compiler to accommodate). Best regards
[Bug target/79166] New: [ARM] Implement neon_valid_immediate tricks for BYTES_BIG_ENDIAN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79166 Bug ID: 79166 Summary: [ARM] Implement neon_valid_immediate tricks for BYTES_BIG_ENDIAN Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ktkachov at gcc dot gnu.org Target Milestone: --- As a result of the fix for PR 71270 the various tricks that neon_valid_immediate can do to splat a constant across a vector have been restricted to all but the most basic ones on BYTES_BIG_ENDIAN. This is a PR to track implementing them properly on big-endian targets. See also https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00381.html
[Bug rtl-optimization/70681] [6/7 Regression] FAIL: gcc.dg/ira-shrinkwrap-prep-2.c gcc.dg/pr10474.c on arm and powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70681 Nick Clifton changed: What|Removed |Added CC||nickc at gcc dot gnu.org --- Comment #3 from Nick Clifton --- Hi Guys, I would like to close out this PR, so that it is no longer considered a regression delaying the creation of the gcc 7 branch. I propose changing the comments in the two test cases like this: -/* XFAIL due to PR70681. */ +/* The XFAILs are because these targets produce better code without + shrinkwrapping, and hence the optimization is not triggered. See + PR70681 for more details. */ Which I think captures the essence of the reason for XFAILing. I have verified that the ARM and POWERPC compilers do indeed produce code sequences with fewer overall instructions, although the shorter code path through the test functions is usually one instruction longer without the shrinkwrapping. (But the longer code path is usually two or three instructions shorter). So - is it OK to apply the uploaded patch to the mainline ? Cheers Nick
[Bug target/79166] [ARM] Implement neon_valid_immediate tricks for BYTES_BIG_ENDIAN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79166 ktkachov at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Target||armeb Target Milestone|--- |8.0
[Bug c++/77829] Bad fix-it for nested-name-specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77829 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed by r244715; marking as resolved.
[Bug c++/78656] Fix-it suggestion for std::alocator doesn't include std::allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78656 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from David Malcolm --- Should be fixed by r244715; marking as resolved.
[Bug target/71270] [7 Regression] fortran regression after fix SLP PR58135
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71270 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from ktkachov at gcc dot gnu.org --- Fixed. Opened PR 79166 for tracking codegen improvements for big-endian that can be done as a result of https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00381.html
[Bug rtl-optimization/70681] [6/7 Regression] FAIL: gcc.dg/ira-shrinkwrap-prep-2.c gcc.dg/pr10474.c on arm and powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70681 --- Comment #4 from Nick Clifton --- Created attachment 40555 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40555&action=edit Proposed patch
[Bug target/71270] [7 Regression] fortran regression after fix SLP PR58135
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71270 --- Comment #11 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Fri Jan 20 14:36:57 2017 New Revision: 244716 URL: https://gcc.gnu.org/viewcvs?rev=244716&root=gcc&view=rev Log: [ARM] PR target/71270 fix neon_valid_immediate for big-endian PR target/71270 * config/arm/arm.c (neon_valid_immediate): Reject vector constants in big-endian mode when they are not a single duplicated value. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c
[Bug c++/77829] Bad fix-it for nested-name-specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77829 --- Comment #2 from David Malcolm --- Author: dmalcolm Date: Fri Jan 20 14:36:46 2017 New Revision: 244715 URL: https://gcc.gnu.org/viewcvs?rev=244715&root=gcc&view=rev Log: C++: fix fix-it hints for misspellings within explicit namespaces gcc/cp/ChangeLog: PR c++/77829 PR c++/78656 * cp-tree.h (suggest_alternatives_for): Add bool param. (suggest_alternative_in_explicit_scope): New decl. * error.c (qualified_name_lookup_error): When SCOPE is a namespace that isn't the global one, call new function suggest_alternative_in_explicit_scope, only calling suggest_alternatives_for if it fails, and disabling near match searches fort that case. When SCOPE is the global namespace, pass true for new param to suggest_alternatives_for to allow for fuzzy name lookups. * lex.c (unqualified_name_lookup_error): Pass true for new param to suggest_alternatives_for. * name-lookup.c (consider_binding_level): Add forward decl. (suggest_alternatives_for): Add "suggest_misspellings" param, using it to conditionalize the fuzzy name-lookup code. (suggest_alternative_in_explicit_scope): New function. * parser.c (cp_parser_primary_expression): When calling finish_id_expression, pass location of id_expression rather than that of id_expr_token. (cp_parser_id_expression): Convert local "unqualified_id" from tree to cp_expr to avoid implicitly dropping location information. gcc/testsuite/ChangeLog: PR c++/77829 PR c++/78656 * g++.dg/spellcheck-pr77829.C: New test case. * g++.dg/spellcheck-pr78656.C: New test case. Added: trunk/gcc/testsuite/g++.dg/spellcheck-pr77829.C trunk/gcc/testsuite/g++.dg/spellcheck-pr78656.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/error.c trunk/gcc/cp/lex.c trunk/gcc/cp/name-lookup.c trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/70681] [6/7 Regression] FAIL: gcc.dg/ira-shrinkwrap-prep-2.c gcc.dg/pr10474.c on arm and powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70681 --- Comment #5 from ktkachov at gcc dot gnu.org --- Fine with me, Nick. But I suppose gcc-patches is the place to ask, I think Segher also had something to say for shrink-wrapping
[Bug libstdc++/79156] incorrect c++ usage in gcc7 void function returns a value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79156 --- Comment #5 from Jonathan Wakely --- In cases like this where it's just a dumb bug in our library headers (in a non-standard extension which hadn't been adequately tested) we'd definitely rather fix it here, not require other compilers to workaround it. Please do continue to report any errors like this that you find, thanks.
[Bug other/78068] warning: implicit declaration of function ‘time’; did you mean ‘nice’? [-Wimplicit-function-declaration]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78068 David Malcolm changed: What|Removed |Added Depends on||69968 --- Comment #4 from David Malcolm --- I had a go at fixing this by introducing a "require_close_matches" flag to best_match (When set, it would require an edit distance of 1), and turning it on for just this warning. Unfortunately this broke the scanf<->sacnf transposition detection in one of the testcases. Maybe this would be a valid approach if we implemented transposition handling when computing the edit distance. (transposition-handling is PR 69968). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69968 [Bug 69968] RFC: Use Damerau-Levenshtein within spellcheck.c, rather than Levenshtein
[Bug c++/77284] [5/6 Regression] ICE on valid C++11 code using initializer list: in potential_constant_expression_1, at cp/constexpr.c:5480
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77284 --- Comment #7 from Marek Polacek --- Author: mpolacek Date: Fri Jan 20 15:12:26 2017 New Revision: 244721 URL: https://gcc.gnu.org/viewcvs?rev=244721&root=gcc&view=rev Log: PR c++/77545 PR c++/77284 * constexpr.c (potential_constant_expression_1): Handle CLEANUP_STMT. * g++.dg/cpp0x/range-for32.C: New test. * g++.dg/cpp0x/range-for33.C: New test. Added: branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp0x/range-for32.C branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp0x/range-for33.C Modified: branches/gcc-6-branch/gcc/cp/ChangeLog branches/gcc-6-branch/gcc/cp/constexpr.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug c++/77545] [7 Regression] ICE on valid C++11 code: in potential_constant_expression_1, at cp/constexpr.c:5480
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77545 --- Comment #5 from Marek Polacek --- Author: mpolacek Date: Fri Jan 20 15:12:26 2017 New Revision: 244721 URL: https://gcc.gnu.org/viewcvs?rev=244721&root=gcc&view=rev Log: PR c++/77545 PR c++/77284 * constexpr.c (potential_constant_expression_1): Handle CLEANUP_STMT. * g++.dg/cpp0x/range-for32.C: New test. * g++.dg/cpp0x/range-for33.C: New test. Added: branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp0x/range-for32.C branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp0x/range-for33.C Modified: branches/gcc-6-branch/gcc/cp/ChangeLog branches/gcc-6-branch/gcc/cp/constexpr.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug c++/77284] [5 Regression] ICE on valid C++11 code using initializer list: in potential_constant_expression_1, at cp/constexpr.c:5480
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77284 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Summary|[5/6 Regression] ICE on |[5 Regression] ICE on valid |valid C++11 code using |C++11 code using |initializer list: in|initializer list: in |potential_constant_expressi |potential_constant_expressi |on_1, at|on_1, at |cp/constexpr.c:5480 |cp/constexpr.c:5480 --- Comment #8 from Marek Polacek --- Fixed.
[Bug libstdc++/69240] Missing inequality operators for every param_type in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69240 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #1 from Jonathan Wakely --- Fixed for gcc 7.
[Bug libstdc++/69240] Missing inequality operators for every param_type in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69240 --- Comment #2 from Jonathan Wakely --- Author: redi Date: Fri Jan 20 15:28:48 2017 New Revision: 244722 URL: https://gcc.gnu.org/viewcvs?rev=244722&root=gcc&view=rev Log: PR69240 Define inequality operators for param types PR libstdc++/69240 * include/bits/random.h (uniform_real_distribution::param_type) (normal_distribution::param_type, lognormal_distribution::param_type) (gamma_distribution::param_type, chi_squared_distribution::param_type) (cauchy_distribution::param_type, fisher_f_distribution::param_type) (student_t_distribution::param_type) (bernoulli_distribution::param_type, binomial_distribution::param_type) (geometric_distribution::param_type) (negative_binomial_distribution::param_type) (poisson_distribution::param_type) (exponential_distribution::param_type) (weibull_distribution::param_type) (extreme_value_distribution::param_type) (discrete_distribution::param_type) (piecewise_constant_distribution::param_type) (piecewise_linear_distribution::param_type): Define operator!=. * include/bits/uniform_int_dist.h (uniform_int_distribution::param_type): Likewise. * include/ext/random (beta_distribution::param_type) (rice_distribution::param_type, nakagami_distribution::param_type) (pareto_distribution::param_type, k_distribution::param_type) (arcsine_distribution::param_type, hoyt_distribution::param_type) (triangular_distribution::param_type) (von_mises_distribution::param_type) (hypergeometric_distribution::param_type) (logistic_distribution::param_type) (uniform_on_sphere_distribution::param_type) (uniform_inside_sphere_distribution::param_type): Likewise. * testsuite/26_numerics/random/bernoulli_distribution/cons/parms.cc: Test construction with param_type. * testsuite/26_numerics/random/binomial_distribution/cons/parms.cc: Likewise. * testsuite/26_numerics/random/cauchy_distribution/cons/parms.cc: Likewise. * testsuite/26_numerics/random/chi_squared_distribution/cons/parms.cc: Likewise. * testsuite/26_numerics/random/exponential_distribution/cons/parms.cc: Likewise. * testsuite/26_numerics/random/extreme_value_distribution/cons/ parms.cc: Likewise. * testsuite/26_numerics/random/fisher_f_distribution/cons/parms.cc: Likewise. * testsuite/26_numerics/random/gamma_distribution/cons/parms.cc: Likewise. * testsuite/26_numerics/random/geometric_distribution/cons/parms.cc: Likewise. * testsuite/26_numerics/random/lognormal_distribution/cons/parms.cc: Likewise. * testsuite/26_numerics/random/negative_binomial_distribution/cons/ parms.cc: Likewise. * testsuite/26_numerics/random/normal_distribution/cons/parms.cc: Likewise. * testsuite/26_numerics/random/poisson_distribution/cons/parms.cc: Likewise. * testsuite/26_numerics/random/student_t_distribution/cons/parms.cc: Likewise. * testsuite/26_numerics/random/uniform_int_distribution/cons/parms.cc: Likewise. * testsuite/26_numerics/random/uniform_real_distribution/cons/parms.cc: Likewise. * testsuite/26_numerics/random/weibull_distribution/cons/parms.cc: Likewise. * testsuite/ext/random/arcsine_distribution/cons/parms.cc: Likewise. * testsuite/ext/random/beta_distribution/cons/parms.cc: Likewise. * testsuite/ext/random/hoyt_distribution/cons/parms.cc: Likewise. * testsuite/ext/random/hypergeometric_distribution/cons/parms.cc: Likewise. * testsuite/ext/random/k_distribution/cons/parms.cc: Likewise. * testsuite/ext/random/logistic_distribution/cons/parms.cc: Likewise. * testsuite/ext/random/nakagami_distribution/cons/parms.cc: Likewise. * testsuite/ext/random/normal_mv_distribution/cons/parms.cc: Likewise. * testsuite/ext/random/pareto_distribution/cons/parms.cc: Likewise. * testsuite/ext/random/rice_distribution/cons/parms.cc: Likewise. * testsuite/ext/random/triangular_distribution/cons/parms.cc: Likewise. * testsuite/ext/random/uniform_inside_sphere_distribution/cons/ parms.cc: Likewise. * testsuite/ext/random/von_mises_distribution/cons/parms.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/random.h trunk/libstdc++-v3/include/bits/uniform_int_dist.h trunk/libstdc++-v3/include/ext/random trunk/libstdc++-v3/testsuite/26_numerics/random/bernoulli_distribution/cons/parms.cc trunk/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/cons/parms.cc trunk/libstdc++-v3/testsuite/26_numerics/random/cauchy_distribution/con
[Bug libstdc++/66145] [5/6/7 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145 --- Comment #30 from Jonathan Wakely --- I don't plan to change this for gcc 5 and gcc 6, because changing the type of exception thrown by the library doesn't seem appropriate for a minor release within the 5.x or 6.x series.
[Bug target/77455] [AArch64] eh_return implementation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77455 --- Comment #3 from wilco at gcc dot gnu.org --- Author: wilco Date: Fri Jan 20 15:34:41 2017 New Revision: 244724 URL: https://gcc.gnu.org/viewcvs?rev=244724&root=gcc&view=rev Log: This patch simplifies the handling of EH return. We force the use of the frame pointer so the return location is always at FP + 8. This means we can emit a simple volatile access in EH_RETURN_HANDLER_RTX without needing md patterns, splitters and frame offset calculations. The new implementation also fixes various bugs in aarch64_final_eh_return_addr, which does not work with -fomit-frame-pointer, alloca or outgoing arguments. Backport from mainline gcc/ PR target/77455 * config/aarch64/aarch64.md (eh_return): Remove pattern and splitter. * config/aarch64/aarch64.h (AARCH64_EH_STACKADJ_REGNUM): Remove. (EH_RETURN_HANDLER_RTX): New define. * config/aarch64/aarch64.c (aarch64_frame_pointer_required): Force frame pointer in EH return functions. (aarch64_expand_epilogue): Add barrier for eh_return. (aarch64_final_eh_return_addr): Remove. (aarch64_eh_return_handler_rtx): New function. * config/aarch64/aarch64-protos.h (aarch64_final_eh_return_addr): Remove. (aarch64_eh_return_handler_rtx): New prototype. testsuite/ PR target/77455 * gcc.target/aarch64/eh_return.c: New test. Added: branches/gcc-6-branch/gcc/testsuite/gcc.target/aarch64/eh_return.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/aarch64/aarch64-protos.h branches/gcc-6-branch/gcc/config/aarch64/aarch64.c branches/gcc-6-branch/gcc/config/aarch64/aarch64.h branches/gcc-6-branch/gcc/config/aarch64/aarch64.md branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug c++/78014] -Wformat -vs- size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78014
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment #4 from David Malcolm ---
I wonder if it would be useful to have some kind of "-Wportability" or
somesuch: warn about code that, although it might work OK on the user's current
configuration, would be problematic on other configurations.
This sounds useful for the end-user, but hard to implement (could be done
piecemeal, I suppose).
(and "portability" would cover a lot of aspects: 32-bit vs 64-bit, little vs
big-endian, etc etc).
What should a warning for the code in comment #0 look like?
test.c:5: format code '%lu' assumes 'unsigned long', but argument is 'size_t'
[-Wportability]
printf("got %lu\n", x);
~~^
%zu
or somesuch?
Or even, brainstorming here, give it some knowledge of other archs e.g.:
test.c:5: format code '%lu' assumes 'unsigned long', but argument is 'size_t';
this will break on NAMES_OF_ARCHS_HERE [-Wportability=i686,ppcle]
printf("got %lu\n", x);
~~^
%zu
(not sure that this last one is a good idea, but mentioning it for sake of
argument)
[Bug target/79166] [ARM] Implement neon_valid_immediate tricks for BYTES_BIG_ENDIAN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79166 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-01-20 Ever confirmed|0 |1
[Bug bootstrap/78985] [7 Regression] profiledbootstrap failure by -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78985 --- Comment #6 from rguenther at suse dot de --- On January 20, 2017 3:07:37 PM GMT+01:00, "marxin at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78985 > >--- Comment #5 from Martin Liška --- >(In reply to rguent...@suse.de from comment #4) >> On Fri, 20 Jan 2017, marxin at gcc dot gnu.org wrote: >> >> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78985 >> > >> > Martin Liška changed: >> > >> >What|Removed |Added >> > > >> > Status|UNCONFIRMED |NEW >> >Last reconfirmed||2017-01-20 >> >Assignee|unassigned at gcc dot gnu.org |marxin at >gcc dot gnu.org >> > Ever confirmed|0 |1 >> > >> > --- Comment #3 from Martin Liška --- >> > I'll try to bisect that, on aarch64 machine I see: >> > >> > ../../gcc/config/aarch64/cortex-a57-fma-steering.c: In member >function ‘void >> > func_fma_steering::analyze()’: >> > ../../gcc/config/aarch64/cortex-a57-fma-steering.c:979:53: error: >‘head’ may be >> > used uninitialized in this function [-Werror=maybe-uninitialized] >> > this->analyze_fma_fmul_insn (forest, chain, head); >> > ^ >> > ../../gcc/config/aarch64/cortex-a57-fma-steering.c:979:53: error: >‘forest’ may >> > be used uninitialized in this function >[-Werror=maybe-uninitialized] >> > ../../gcc/config/aarch64/cortex-a57-fma-steering.c:979:53: error: >‘chain’ may >> > be used uninitialized in this function >[-Werror=maybe-uninitialized] >> > >> > I'll try to bisect.. >> >> Yes, aarch64 has a similar issue. > >This is aarch64 machine :) Do you remember whether profiledbootstrap >used to >succeed (for bisect start)? It used to, yes. It at least works on the branch.
[Bug target/78397] The stack is not 8 bytes aligned on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78397 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #6 from Richard Earnshaw --- Not a gcc bug.
[Bug target/77455] [AArch64] eh_return implementation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77455 wilco at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from wilco at gcc dot gnu.org --- Fixed in GCC6 and GCC7
[Bug rtl-optimization/79149] bad optimization on MIPS and ARM leading to excessive stack usage in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79149 --- Comment #5 from Arnd Bergmann --- -fno-schedule-insns is comparable in stack frame size to "-fno-sched-critical-path-heuristic -fno-sched-dep-count-heuristic" on all architectures (give or take a few bytes), but actually produces much better code. In my simulated mips64 run, I see these numbers: -O2: 49.0Mbit/s -O2 -fno-sched-critical-path-heuristic -fno-sched-dep-count-heuristic: 109.7 Mbit/s -O2 -fno-schedule-insns: 179.2 Mbit/s The trend is the same on arm an aarch64 for emulated runs, and I confirmed earlier that the results on real hardware are comparable to what we get in qemu.
[Bug c/79152] -Wimplicit-fallthrough false positive triggered by goto statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79152 --- Comment #5 from Marek Polacek --- Author: mpolacek Date: Fri Jan 20 16:28:16 2017 New Revision: 244726 URL: https://gcc.gnu.org/viewcvs?rev=244726&root=gcc&view=rev Log: PR c/79152 * gimplify.c (should_warn_for_implicit_fallthrough): Handle consecutive non-case labels. * c-c++-common/Wimplicit-fallthrough-35.c: New test. Added: trunk/gcc/testsuite/c-c++-common/Wimplicit-fallthrough-35.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog
[Bug c++/79118] [7 Regression] internal compiler error: in cxx_eval_bit_field_ref, at cp/constexpr.c:2258
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79118 Nathan Sidwell changed: What|Removed |Added Status|NEW |ASSIGNED CC||nathan at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org
[Bug c/79152] -Wimplicit-fallthrough false positive triggered by goto statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79152 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Marek Polacek --- Fixed.
[Bug target/65782] Assembly failure (invalid register for .seh_savexmm) with -O3 -mavx512f on mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65782 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- For the xmm16 to xmm31 registers a possible workaround could be to turn those registers fixed on mingw (thus unavailable for register allocation and not call saved). See PR79127.
[Bug target/79127] [7 Regression] Error: invalid register for .seh_savexmm in matmul_i4.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79127 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #16 from Jakub Jelinek --- The bootstrap should be fixed now, for the rest let's use PR65782.
[Bug testsuite/78421] [7 Regression] vect-strided-a-u8-i2-gap.c fails on armeb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78421 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-01-20 CC||nickc at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Nick Clifton --- Hi Guys, I have proposed an extended version of Richard's patch to fix this regression: https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01615.html Cheers Nick
[Bug c++/79167] New: LHS of assignment operator side-effect sequenced before RHS computation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79167
Bug ID: 79167
Summary: LHS of assignment operator side-effect sequenced
before RHS computation
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ronen at barzel dot org
Target Milestone: ---
Created attachment 40556
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40556&action=edit
g++ --save-temps output
According to http://en.cppreference.com/w/cpp/language/eval_order,
20) In every simple assignment expression E1=E2 and every compound
assignment expression E1@=E2, every value computation and side-effect of E2 is
sequenced before every value computation and side effect of E1
But in this case, the size of the map gets incremented by the LHS before
m.size() gets evaluated on the RHS:
#include
#include
#include
int main(int argc, char *argv[])
{
std::map m;
m["bug"] = m.size();
assert(m["bug"] == 0);
return 0;
}
i.e. m["bug"] should be equal to 0 but it is getting set to 1.
version:
$ g++ --version
g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
Copyright (C) 2015 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.
$
To reproduce:
$ g++ bug.cpp
$ ./a.out
a.out: bug.cpp:9: int main(int, char**): Assertion `m["bug"] == 0' failed.
Aborted
$
[Bug c++/79167] assignment operator LHS side-effect sequenced before RHS computation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79167 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- (In reply to ronen from comment #0) > According to http://en.cppreference.com/w/cpp/language/eval_order, > > 20) In every simple assignment expression E1=E2 and every compound > assignment expression E1@=E2, every value computation and side-effect of E2 > is sequenced before every value computation and side effect of E1 Items 14-21 are marked "since C++17" GCC 5 was released two years ago, long before that change was made to the C++17 draft, and it has quite minimal C++17 support.
