[Bug swing/38198] DefaultTableColumnModel.java: redundant call to new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38198 David Binderman changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from David Binderman --- Source code gone.
[Bug gjdoc/38191] gjdoc/Main.java: dead local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38191 David Binderman changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from David Binderman --- Source code gone.
[Bug xml/38189] Java: set but not used local variable in tight loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38189 David Binderman changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from David Binderman --- Source code gone.
[Bug classpath/38192] SwingCallbackHandler.java: remove unused local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38192 David Binderman changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from David Binderman --- Source code gone.
[Bug classpath/38195] ClassRmicCompiler.java: remove unused variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38195 David Binderman changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from David Binderman --- Source code gone.
[Bug classpath/38193] HashMap.java: unused local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38193 David Binderman changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from David Binderman --- Source code gone.
[Bug swing/38194] DefaultListSelectionModel.java: remove dead for loop ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38194 David Binderman changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from David Binderman --- Source code gone.
[Bug classpath/38176] Java: 4 * use of toUpperCase/toLowerCase().equals()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38176 David Binderman changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from David Binderman --- Source code gone.
[Bug classpath/38197] JobSheetsSupported.java: unused local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38197 David Binderman changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from David Binderman --- Source code gone.
[Bug middle-end/78401] SciMark v2.0 Composite test runs 1,5 times slower under GCC 6.2 than under Clang 3.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78401 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Uroš Bizjak --- Phoronix Scimark 2.0 tests were faulty [1]. [1] https://kristerw.blogspot.si/2017/07/phoronix-scimark-benchmarking-results.html
[Bug c++/38841] valgrind finds problem for broken C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38841 David Binderman changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from David Binderman --- Seems fixed to me.
[Bug other/79703] [meta-bug] SciMark 2.0 performance issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79703 Bug 79703 depends on bug 78401, which changed state. Bug 78401 Summary: SciMark v2.0 Composite test runs 1,5 times slower under GCC 6.2 than under Clang 3.9 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78401 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug middle-end/78402] SciMark v2.0 Dense LU Matrix Factorization test runs more than 2 times slower under GCC 6.2 than under Clang 3.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78402 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Uroš Bizjak --- Phoronix Scimark 2.0 tests were faulty [1]. [1] https://kristerw.blogspot.si/2017/07/phoronix-scimark-benchmarking-results.html
[Bug other/79703] [meta-bug] SciMark 2.0 performance issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79703 Bug 79703 depends on bug 78402, which changed state. Bug 78402 Summary: SciMark v2.0 Dense LU Matrix Factorization test runs more than 2 times slower under GCC 6.2 than under Clang 3.9 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78402 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug middle-end/78404] SciMark v2.0 Sparse Matrix Multiply test is 20% slower under GCC 6.2 than under Clang 3.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78404 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Uroš Bizjak --- Phoronix Scimark 2.0 tests were faulty [1]. [1] https://kristerw.blogspot.si/2017/07/phoronix-scimark-benchmarking-results.html
[Bug other/79703] [meta-bug] SciMark 2.0 performance issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79703 Bug 79703 depends on bug 78403, which changed state. Bug 78403 Summary: SciMark v2.0 Jacobi Successive Over-Relaxation test is 30% slower under GCC 6.2 than under Clang 3.9 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78403 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug middle-end/78403] SciMark v2.0 Jacobi Successive Over-Relaxation test is 30% slower under GCC 6.2 than under Clang 3.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78403 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Uroš Bizjak --- Phoronix Scimark 2.0 tests were faulty [1]. [1] https://kristerw.blogspot.si/2017/07/phoronix-scimark-benchmarking-results.html
[Bug other/79703] [meta-bug] SciMark 2.0 performance issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79703 Bug 79703 depends on bug 78404, which changed state. Bug 78404 Summary: SciMark v2.0 Sparse Matrix Multiply test is 20% slower under GCC 6.2 than under Clang 3.9 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78404 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug other/79703] [meta-bug] SciMark 2.0 performance issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79703 --- Comment #2 from Uroš Bizjak --- Please note that Phoronix SciMark 2.0 benchmark is faulty [1]. [1] https://kristerw.blogspot.si/2017/07/phoronix-scimark-benchmarking-results.html
[Bug tree-optimization/43424] -O2 -floop-parallelize-all causes verify_stmts failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43424 David Binderman changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from David Binderman --- Seems fixed to me.
[Bug rtl-optimization/38518] Excessive compile time with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38518 --- Comment #12 from David Binderman --- With recent gcc: no -O flag: 2 seconds -O2: 24 seconds -O3: 247 seconds I'll have a look at -ftime-report.
[Bug rtl-optimization/60668] simplify-rtx.c:1676: minor tidyup in if ... else chain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60668 David Binderman changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from David Binderman --- Code no longer seems to exist in source code file.
[Bug c/81524] Bogus or missing warnings when dereferencing pointer to deallocated stack memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81524 --- Comment #4 from Martin Liška --- (In reply to Fredrik Hederstierna from comment #3) > Isn't AddressSanitizer checking in run-time? There are several tools that > can find this bugs in runtime I think like Valgrind, but I need to find this > at compile-time. Yes, it's run-time checking. > > I use embedded arm-eabi target and cannot add memory for instrumentation > with compile AddressSanitizer, or can AddressSanitizer do jobs alos in > compile-time without adding code size for run-time instrumentation? No, it verifies stuff just in compile time. Well I understand the arm-eabi is not a good target for AddressSanization. Maybe you will be able to run the code on x86_64 in a testing environment where you can catch various undefined behavior stuff. Please be note that AddressSanitizer is much powerful tool that a compile-time checking, because due to multiple compilation modules or conservative assumptions that compiler has to do, one can't find these issues in compile time.
[Bug c/81524] Bogus or missing warnings when dereferencing pointer to deallocated stack memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81524 --- Comment #5 from Martin Liška --- > No, it verifies stuff just in compile time. Well I understand the arm-eabi Sorry, 'just in run-time'.
[Bug tree-optimization/63822] tree-chkp.c: missing init for local variable found_valid ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63822 David Binderman changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from David Binderman --- Variable is now initialised at its declaration.
[Bug ipa/61145] valgrind finds problems in ipa_analyze_node
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61145 David Binderman changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from David Binderman --- Problem seems to have gone away.
[Bug middle-end/66600] sign_mask meets valgrind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66600 David Binderman changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from David Binderman --- Problem seems to have gone away.
[Bug boehm-gc/66884] trunk/boehm-gc/cord/cordbscs.c:455: bad if ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66884 David Binderman changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from David Binderman --- boehm-gc source code not in the compiler anymore.
[Bug c++/71570] [6/7/8 regression] ICE on invalid variable capture in cxx_incomplete_type_diagnostic, at cp/typeck2.c:551
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71570 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #8 from Paolo Carlini --- Seems easy, I have a patchlet in testing.
[Bug c++/49409] some possible new warnings for strange code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49409 David Binderman changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from David Binderman --- Four out of five cases solved is good enough, in my view.
[Bug rtl-optimization/81559] New: [8 Regression] ICE: verify_flow_info failed (error: non-cold basic block 4 reachable only by paths crossing the cold partition) on 32-bit BE powerpc target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81559
Bug ID: 81559
Summary: [8 Regression] ICE: verify_flow_info failed (error:
non-cold basic block 4 reachable only by paths
crossing the cold partition) on 32-bit BE powerpc
target
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: powerpc-*-linux-gnu
gcc-8.0.0-alpha20170723 snapshot ICEs when compiling the following snippet w/
-O2 (-O3, -Ofast) -freorder-blocks-and-partition:
int yj, z5;
void
tz (int ih)
{
if (z5 == 0)
return;
if (z5 == 1)
{
int *ef = (int *)&ef;
while (ef != 0)
{
hr:
yj /= (z5 != 0) ? 0 : *ef;
}
}
ih = (!!ih && !!z5);
yj /= ih;
if (yj != 0)
{
yj = 1;
goto hr;
}
}
% powerpc-e300c3-linux-gnu-gcc-8.0.0-alpha20170723 -O2
-freorder-blocks-and-partition -c jwf88471.c
jwf88471.c: In function 'tz':
jwf88471.c:27:1: error: non-cold basic block 4 reachable only by paths crossing
the cold partition
}
^
during RTL pass: ce3
jwf88471.c:27:1: internal compiler error: verify_flow_info failed
0x76ac45 verify_flow_info()
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20170723/work/gcc-8-20170723/gcc/cfghooks.c:259
0x13e81e4 checking_verify_flow_info
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20170723/work/gcc-8-20170723/gcc/cfghooks.h:198
0x13e81e4 if_convert
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20170723/work/gcc-8-20170723/gcc/ifcvt.c:5448
0x13e9c9c execute
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20170723/work/gcc-8-20170723/gcc/ifcvt.c:5594
This PR can be a duplicate of PR81301.
[Bug libgcc/66883] config/epiphany/udivsi3-float.c:52: bad if test ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66883 David Binderman changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from David Binderman --- Seems fixed to me.
[Bug tree-optimization/81556] Wrong code at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81556 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Started with r242075.
[Bug rtl-optimization/69084] lra-remat.c:165: dead function ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69084 David Binderman changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from David Binderman --- Function seems gone to me.
[Bug middle-end/69085] gcc/emit-rtl.c:2671: dead function ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69085 David Binderman changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from David Binderman --- This function now does get called from other places.
[Bug libgcc/61152] Missing GCC Runtime Library Exception in some files that are included in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61152 --- Comment #8 from sh at gcc dot gnu.org --- Author: sh Date: Wed Jul 26 08:31:09 2017 New Revision: 250558 URL: https://gcc.gnu.org/viewcvs?rev=250558&root=gcc&view=rev Log: [RTEMS] Add GCC Runtime Library Exception gcc/ PR libgcc/61152 * config/aarch64/rtems.h: Add GCC Runtime Library Exception. Format changes. * config/arm/rtems.h: Likewise. * config/bfin/rtems.h: Likewise. * config/i386/rtemself.h: Likewise. * config/lm32/rtems.h: Likewise. * config/m32c/rtems.h: Likewise. * config/m68k/rtemself.h: Likewise. * config/microblaze/rtems.h: Likewise. * config/mips/rtems.h: Likewise. * config/moxie/rtems.h: Likewise. * config/nios2/rtems.h: Likewise. * config/rs6000/rtems.h: Likewise. * config/rtems.h: Likewise. * config/sh/rtems.h: Likewise. * config/sh/rtemself.h: Likewise. * config/sparc/rtemself.h: Likewise. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/aarch64/rtems.h branches/gcc-7-branch/gcc/config/arm/rtems.h branches/gcc-7-branch/gcc/config/bfin/rtems.h branches/gcc-7-branch/gcc/config/i386/rtemself.h branches/gcc-7-branch/gcc/config/lm32/rtems.h branches/gcc-7-branch/gcc/config/m32c/rtems.h branches/gcc-7-branch/gcc/config/m68k/rtemself.h branches/gcc-7-branch/gcc/config/microblaze/rtems.h branches/gcc-7-branch/gcc/config/mips/rtems.h branches/gcc-7-branch/gcc/config/moxie/rtems.h branches/gcc-7-branch/gcc/config/nios2/rtems.h branches/gcc-7-branch/gcc/config/rs6000/rtems.h branches/gcc-7-branch/gcc/config/rtems.h branches/gcc-7-branch/gcc/config/sh/rtems.h branches/gcc-7-branch/gcc/config/sh/rtemself.h branches/gcc-7-branch/gcc/config/sparc/rtemself.h branches/gcc-7-branch/gcc/config/v850/rtems.h
[Bug tree-optimization/81556] [7/8 Regression] Wrong code at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81556 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |7.2 Summary|Wrong code at -O2 |[7/8 Regression] Wrong code ||at -O2 --- Comment #3 from Jakub Jelinek --- But it is indeed true that this seems to be reassoc. That pass shouldn't be resetting the range info, instead it shouldn't reuse SSA_NAMEs unless they must have the same value as before. It has code to avoid the reusing, but most likely this is a corner case that isn't handled well. I'll have a look.
[Bug tree-optimization/81455] [7 Regression] Compile-time hog w/ -O1 -funswitch-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81455 --- Comment #5 from Richard Biener --- Author: rguenth Date: Wed Jul 26 08:36:34 2017 New Revision: 250560 URL: https://gcc.gnu.org/viewcvs?rev=250560&root=gcc&view=rev Log: 2017-07-26 Richard Biener Backport from mainline 2017-06-02 Richard Biener Markus Eisenmann PR libstdc++/80721 * libsupc++/eh_alloc.cc (pool::free): Keep list properly sorted and add missing freelist item merging cases. 2017-06-18 Richard Biener PR tree-optimization/81410 * tree-vect-stmts.c (vectorizable_load): Properly adjust for the gap in the ! slp_perm SLP case after each group. * gcc.dg/vect/pr81410.c: New testcase. 2017-07-25 Richard Biener PR tree-optimization/81455 * tree-ssa-loop-unswitch.c (find_loop_guard): Make sure to not walk in cycles when looking for guards. * gcc.dg/pr81455.c: New testcase. 2017-07-25 Richard Biener PR middle-end/81505 * fold-const.c (fold_negate_const): TREE_OVERFLOW should be sticky. * gcc.dg/ubsan/pr81505.c: New testcase. 2017-07-04 Jakub Jelinek PR target/81175 * gcc.target/i386/pr69255-2.c (foo): Use the return value of the gather. 2017-06-28 Jakub Jelinek PR target/81175 * config/i386/i386.c (ix86_init_mmx_sse_builtins): Use def_builtin rather than def_builtin_pure for __builtin_ia32_gatherpf*. 2017-06-26 Richard Biener PR target/81175 * config/i386/i386.c (ix86_init_mmx_sse_builtins): Use def_builtin_pure for all gather builtins. * gfortran.dg/pr81175.f: New testcase. 2017-06-21 Marc Glisse * config/i386/i386.c (struct builtin_isa): New field pure_p. Reorder for compactness. (def_builtin, def_builtin2, ix86_add_new_builtins): Handle pure_p. (def_builtin_pure, def_builtin_pure2): New functions. (ix86_init_mmx_sse_builtins) [__builtin_ia32_stmxcsr]: Mark as pure. * gcc.dg/tree-ssa/addadd.c: Un-XFAIL. * gcc.dg/tree-ssa/addadd-2.c: New file. Added: branches/gcc-7-branch/gcc/testsuite/gcc.dg/pr81455.c branches/gcc-7-branch/gcc/testsuite/gcc.dg/ubsan/pr81505.c branches/gcc-7-branch/gcc/testsuite/gcc.dg/vect/pr81410.c branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/getround.c branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr81175.f Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/i386/i386.c branches/gcc-7-branch/gcc/fold-const.c branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr69255-2.c branches/gcc-7-branch/gcc/tree-ssa-loop-unswitch.c branches/gcc-7-branch/gcc/tree-vect-stmts.c branches/gcc-7-branch/libstdc++-v3/ChangeLog branches/gcc-7-branch/libstdc++-v3/libsupc++/eh_alloc.cc
[Bug c++/81410] [5/6/7 Regression] -O3 breaks code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81410 --- Comment #12 from Richard Biener --- Author: rguenth Date: Wed Jul 26 08:36:34 2017 New Revision: 250560 URL: https://gcc.gnu.org/viewcvs?rev=250560&root=gcc&view=rev Log: 2017-07-26 Richard Biener Backport from mainline 2017-06-02 Richard Biener Markus Eisenmann PR libstdc++/80721 * libsupc++/eh_alloc.cc (pool::free): Keep list properly sorted and add missing freelist item merging cases. 2017-06-18 Richard Biener PR tree-optimization/81410 * tree-vect-stmts.c (vectorizable_load): Properly adjust for the gap in the ! slp_perm SLP case after each group. * gcc.dg/vect/pr81410.c: New testcase. 2017-07-25 Richard Biener PR tree-optimization/81455 * tree-ssa-loop-unswitch.c (find_loop_guard): Make sure to not walk in cycles when looking for guards. * gcc.dg/pr81455.c: New testcase. 2017-07-25 Richard Biener PR middle-end/81505 * fold-const.c (fold_negate_const): TREE_OVERFLOW should be sticky. * gcc.dg/ubsan/pr81505.c: New testcase. 2017-07-04 Jakub Jelinek PR target/81175 * gcc.target/i386/pr69255-2.c (foo): Use the return value of the gather. 2017-06-28 Jakub Jelinek PR target/81175 * config/i386/i386.c (ix86_init_mmx_sse_builtins): Use def_builtin rather than def_builtin_pure for __builtin_ia32_gatherpf*. 2017-06-26 Richard Biener PR target/81175 * config/i386/i386.c (ix86_init_mmx_sse_builtins): Use def_builtin_pure for all gather builtins. * gfortran.dg/pr81175.f: New testcase. 2017-06-21 Marc Glisse * config/i386/i386.c (struct builtin_isa): New field pure_p. Reorder for compactness. (def_builtin, def_builtin2, ix86_add_new_builtins): Handle pure_p. (def_builtin_pure, def_builtin_pure2): New functions. (ix86_init_mmx_sse_builtins) [__builtin_ia32_stmxcsr]: Mark as pure. * gcc.dg/tree-ssa/addadd.c: Un-XFAIL. * gcc.dg/tree-ssa/addadd-2.c: New file. Added: branches/gcc-7-branch/gcc/testsuite/gcc.dg/pr81455.c branches/gcc-7-branch/gcc/testsuite/gcc.dg/ubsan/pr81505.c branches/gcc-7-branch/gcc/testsuite/gcc.dg/vect/pr81410.c branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/getround.c branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr81175.f Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/i386/i386.c branches/gcc-7-branch/gcc/fold-const.c branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr69255-2.c branches/gcc-7-branch/gcc/tree-ssa-loop-unswitch.c branches/gcc-7-branch/gcc/tree-vect-stmts.c branches/gcc-7-branch/libstdc++-v3/ChangeLog branches/gcc-7-branch/libstdc++-v3/libsupc++/eh_alloc.cc
[Bug target/81175] [7 Regression] EXC_BAD_ACCESS in ::slpeel_duplicate_current_defs_from_edges(edge, edge, edge, edge) at is-a.h:192
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81175 --- Comment #8 from Richard Biener --- Author: rguenth Date: Wed Jul 26 08:36:34 2017 New Revision: 250560 URL: https://gcc.gnu.org/viewcvs?rev=250560&root=gcc&view=rev Log: 2017-07-26 Richard Biener Backport from mainline 2017-06-02 Richard Biener Markus Eisenmann PR libstdc++/80721 * libsupc++/eh_alloc.cc (pool::free): Keep list properly sorted and add missing freelist item merging cases. 2017-06-18 Richard Biener PR tree-optimization/81410 * tree-vect-stmts.c (vectorizable_load): Properly adjust for the gap in the ! slp_perm SLP case after each group. * gcc.dg/vect/pr81410.c: New testcase. 2017-07-25 Richard Biener PR tree-optimization/81455 * tree-ssa-loop-unswitch.c (find_loop_guard): Make sure to not walk in cycles when looking for guards. * gcc.dg/pr81455.c: New testcase. 2017-07-25 Richard Biener PR middle-end/81505 * fold-const.c (fold_negate_const): TREE_OVERFLOW should be sticky. * gcc.dg/ubsan/pr81505.c: New testcase. 2017-07-04 Jakub Jelinek PR target/81175 * gcc.target/i386/pr69255-2.c (foo): Use the return value of the gather. 2017-06-28 Jakub Jelinek PR target/81175 * config/i386/i386.c (ix86_init_mmx_sse_builtins): Use def_builtin rather than def_builtin_pure for __builtin_ia32_gatherpf*. 2017-06-26 Richard Biener PR target/81175 * config/i386/i386.c (ix86_init_mmx_sse_builtins): Use def_builtin_pure for all gather builtins. * gfortran.dg/pr81175.f: New testcase. 2017-06-21 Marc Glisse * config/i386/i386.c (struct builtin_isa): New field pure_p. Reorder for compactness. (def_builtin, def_builtin2, ix86_add_new_builtins): Handle pure_p. (def_builtin_pure, def_builtin_pure2): New functions. (ix86_init_mmx_sse_builtins) [__builtin_ia32_stmxcsr]: Mark as pure. * gcc.dg/tree-ssa/addadd.c: Un-XFAIL. * gcc.dg/tree-ssa/addadd-2.c: New file. Added: branches/gcc-7-branch/gcc/testsuite/gcc.dg/pr81455.c branches/gcc-7-branch/gcc/testsuite/gcc.dg/ubsan/pr81505.c branches/gcc-7-branch/gcc/testsuite/gcc.dg/vect/pr81410.c branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/getround.c branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr81175.f Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/i386/i386.c branches/gcc-7-branch/gcc/fold-const.c branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr69255-2.c branches/gcc-7-branch/gcc/tree-ssa-loop-unswitch.c branches/gcc-7-branch/gcc/tree-vect-stmts.c branches/gcc-7-branch/libstdc++-v3/ChangeLog branches/gcc-7-branch/libstdc++-v3/libsupc++/eh_alloc.cc
[Bug sanitizer/81505] [5/6/7 Regression] ICE in tree-ssa-loop-manip.c:95 with -fsanitize=signed-integer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81505 --- Comment #4 from Richard Biener --- Author: rguenth Date: Wed Jul 26 08:36:34 2017 New Revision: 250560 URL: https://gcc.gnu.org/viewcvs?rev=250560&root=gcc&view=rev Log: 2017-07-26 Richard Biener Backport from mainline 2017-06-02 Richard Biener Markus Eisenmann PR libstdc++/80721 * libsupc++/eh_alloc.cc (pool::free): Keep list properly sorted and add missing freelist item merging cases. 2017-06-18 Richard Biener PR tree-optimization/81410 * tree-vect-stmts.c (vectorizable_load): Properly adjust for the gap in the ! slp_perm SLP case after each group. * gcc.dg/vect/pr81410.c: New testcase. 2017-07-25 Richard Biener PR tree-optimization/81455 * tree-ssa-loop-unswitch.c (find_loop_guard): Make sure to not walk in cycles when looking for guards. * gcc.dg/pr81455.c: New testcase. 2017-07-25 Richard Biener PR middle-end/81505 * fold-const.c (fold_negate_const): TREE_OVERFLOW should be sticky. * gcc.dg/ubsan/pr81505.c: New testcase. 2017-07-04 Jakub Jelinek PR target/81175 * gcc.target/i386/pr69255-2.c (foo): Use the return value of the gather. 2017-06-28 Jakub Jelinek PR target/81175 * config/i386/i386.c (ix86_init_mmx_sse_builtins): Use def_builtin rather than def_builtin_pure for __builtin_ia32_gatherpf*. 2017-06-26 Richard Biener PR target/81175 * config/i386/i386.c (ix86_init_mmx_sse_builtins): Use def_builtin_pure for all gather builtins. * gfortran.dg/pr81175.f: New testcase. 2017-06-21 Marc Glisse * config/i386/i386.c (struct builtin_isa): New field pure_p. Reorder for compactness. (def_builtin, def_builtin2, ix86_add_new_builtins): Handle pure_p. (def_builtin_pure, def_builtin_pure2): New functions. (ix86_init_mmx_sse_builtins) [__builtin_ia32_stmxcsr]: Mark as pure. * gcc.dg/tree-ssa/addadd.c: Un-XFAIL. * gcc.dg/tree-ssa/addadd-2.c: New file. Added: branches/gcc-7-branch/gcc/testsuite/gcc.dg/pr81455.c branches/gcc-7-branch/gcc/testsuite/gcc.dg/ubsan/pr81505.c branches/gcc-7-branch/gcc/testsuite/gcc.dg/vect/pr81410.c branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/getround.c branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr81175.f Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/i386/i386.c branches/gcc-7-branch/gcc/fold-const.c branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr69255-2.c branches/gcc-7-branch/gcc/tree-ssa-loop-unswitch.c branches/gcc-7-branch/gcc/tree-vect-stmts.c branches/gcc-7-branch/libstdc++-v3/ChangeLog branches/gcc-7-branch/libstdc++-v3/libsupc++/eh_alloc.cc
[Bug libstdc++/80721] Sorting/Merging of free EH-emergency buffer may wrong or uncomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80721 --- Comment #9 from Richard Biener --- Author: rguenth Date: Wed Jul 26 08:36:34 2017 New Revision: 250560 URL: https://gcc.gnu.org/viewcvs?rev=250560&root=gcc&view=rev Log: 2017-07-26 Richard Biener Backport from mainline 2017-06-02 Richard Biener Markus Eisenmann PR libstdc++/80721 * libsupc++/eh_alloc.cc (pool::free): Keep list properly sorted and add missing freelist item merging cases. 2017-06-18 Richard Biener PR tree-optimization/81410 * tree-vect-stmts.c (vectorizable_load): Properly adjust for the gap in the ! slp_perm SLP case after each group. * gcc.dg/vect/pr81410.c: New testcase. 2017-07-25 Richard Biener PR tree-optimization/81455 * tree-ssa-loop-unswitch.c (find_loop_guard): Make sure to not walk in cycles when looking for guards. * gcc.dg/pr81455.c: New testcase. 2017-07-25 Richard Biener PR middle-end/81505 * fold-const.c (fold_negate_const): TREE_OVERFLOW should be sticky. * gcc.dg/ubsan/pr81505.c: New testcase. 2017-07-04 Jakub Jelinek PR target/81175 * gcc.target/i386/pr69255-2.c (foo): Use the return value of the gather. 2017-06-28 Jakub Jelinek PR target/81175 * config/i386/i386.c (ix86_init_mmx_sse_builtins): Use def_builtin rather than def_builtin_pure for __builtin_ia32_gatherpf*. 2017-06-26 Richard Biener PR target/81175 * config/i386/i386.c (ix86_init_mmx_sse_builtins): Use def_builtin_pure for all gather builtins. * gfortran.dg/pr81175.f: New testcase. 2017-06-21 Marc Glisse * config/i386/i386.c (struct builtin_isa): New field pure_p. Reorder for compactness. (def_builtin, def_builtin2, ix86_add_new_builtins): Handle pure_p. (def_builtin_pure, def_builtin_pure2): New functions. (ix86_init_mmx_sse_builtins) [__builtin_ia32_stmxcsr]: Mark as pure. * gcc.dg/tree-ssa/addadd.c: Un-XFAIL. * gcc.dg/tree-ssa/addadd-2.c: New file. Added: branches/gcc-7-branch/gcc/testsuite/gcc.dg/pr81455.c branches/gcc-7-branch/gcc/testsuite/gcc.dg/ubsan/pr81505.c branches/gcc-7-branch/gcc/testsuite/gcc.dg/vect/pr81410.c branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/getround.c branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr81175.f Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/i386/i386.c branches/gcc-7-branch/gcc/fold-const.c branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr69255-2.c branches/gcc-7-branch/gcc/tree-ssa-loop-unswitch.c branches/gcc-7-branch/gcc/tree-vect-stmts.c branches/gcc-7-branch/libstdc++-v3/ChangeLog branches/gcc-7-branch/libstdc++-v3/libsupc++/eh_alloc.cc
[Bug libstdc++/80721] Sorting/Merging of free EH-emergency buffer may wrong or uncomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80721 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||7.1.1 Resolution|--- |FIXED Known to fail||7.1.0 --- Comment #8 from Richard Biener --- Fixed for GCC 7.2.
[Bug c++/70693] valgrind error in get_visual_column
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70693 David Binderman changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from David Binderman --- Problem seems to have gone away.
[Bug tree-optimization/81455] [7 Regression] Compile-time hog w/ -O1 -funswitch-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81455 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||7.1.1 Resolution|--- |FIXED Known to fail||7.1.0 --- Comment #6 from Richard Biener --- Fixed.
[Bug target/81175] [7 Regression] EXC_BAD_ACCESS in ::slpeel_duplicate_current_defs_from_edges(edge, edge, edge, edge) at is-a.h:192
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81175 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||7.1.1, 8.0 Resolution|--- |FIXED Known to fail|8.0 | --- Comment #9 from Richard Biener --- Fixed.
[Bug other/71325] intl/dcigettext.c:588]: (style) Redundant condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71325 David Binderman changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from David Binderman --- Bug should be reported elsewhere.
[Bug target/81550] [8 regression] gcc.target/powerpc/loop_align.c fails starting with r250482
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81550 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug tree-optimization/81554] [8 Regression] 25% performance regression in Himeno benchmark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81554 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-07-26 CC||hubicka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Bah. I wonder if we should drop to -fwrapv semantics (thus RTL semantics) at some point after GIMPLE loop optimizations, preferably before reassoc after loop. It shouldn't be too difficult to implement that (well, just a "bit" ugly) to try benchmarking it. To do it "cleanly" we'd add/change the optimization node associated with cfun. In a new pass_late_gimple_begin do pop_cfun (); push_cfun (); unless fwrapv/ftrapv is already set, of course. Going to try sth like that.
[Bug rtl-optimization/65628] valgrind error in improve_allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65628 David Binderman changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from David Binderman --- Problem seems to have gone away.
[Bug ipa/81520] [8 Regression] ICE: in function_and_variable_visibility, at ipa-visibility.c:639
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81520 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Liška --- Fixed.
[Bug sanitizer/81186] SIGSEGV when using Address Sanitizer with nested functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81186 Martin Liška changed: What|Removed |Added Known to work||8.0 Known to fail||7.1.0 --- Comment #3 from Martin Liška --- Fixed on trunk so far.
[Bug sanitizer/81186] SIGSEGV when using Address Sanitizer with nested functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81186 --- Comment #2 from Martin Liška --- Author: marxin Date: Wed Jul 26 08:52:37 2017 New Revision: 250561 URL: https://gcc.gnu.org/viewcvs?rev=250561&root=gcc&view=rev Log: Move non-local goto expansion after parm_birth_insn (PR sanitize/81186). 2017-07-26 Martin Liska PR sanitize/81186 * function.c (expand_function_start): Make expansion of nonlocal_goto_save_area after parm_birth_insn. 2017-07-26 Martin Liska PR sanitize/81186 * gcc.dg/asan/pr81186.c: New test. Added: trunk/gcc/testsuite/gcc.dg/asan/pr81186.c Modified: trunk/gcc/ChangeLog trunk/gcc/function.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/81555] [5/6/7/8 Regression] Wrong code at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81555 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Known to work||4.8.5 Target Milestone|--- |7.2 Summary|Wrong code at -O1 |[5/6/7/8 Regression] Wrong ||code at -O1 Known to fail||5.4.0, 6.3.0, 7.1.0 --- Comment #5 from Richard Biener --- Note that with -O2 it also fails with GCC 5 and 6. GCC 4.8 is fine.
[Bug c/57961] Excessive memory use with -O0 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57961 David Binderman changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from David Binderman --- Code now compiles happily in under 1Gig.
[Bug lto/81487] [mingw32] ld.exe: error: asprintf failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81487 --- Comment #4 from Georg-Johann Lay --- Author: gjl Date: Wed Jul 26 08:58:37 2017 New Revision: 250562 URL: https://gcc.gnu.org/viewcvs?rev=250562&root=gcc&view=rev Log: lto-plugin/ Backport from 2017-07-21 trunk r250428. PR lto/81487 * lto-plugin.c (claim_file_handler): Use xasprintf instead of asprintf. [hi!=0]: Swap hi and lo arguments supplied to xasprintf. gcc/ Backport from 2017-07-25 trunk r250499. PR 81487 * hsa-brig.c (brig_init): Use xasprintf instead of asprintf. * gimple-pretty-print.c (dump_probability): Same. * tree-ssa-structalias.c (alias_get_name): Same. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/gimple-pretty-print.c branches/gcc-7-branch/gcc/hsa-brig.c branches/gcc-7-branch/gcc/tree-ssa-structalias.c branches/gcc-7-branch/lto-plugin/ChangeLog branches/gcc-7-branch/lto-plugin/lto-plugin.c
[Bug libgcc/78779] libgcc/soft-fp/op-common.h:900: possible missing break ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78779 David Binderman changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #4 from David Binderman --- As per Joseph's comment.
[Bug pch/78508] valgrind error in gt_pch_note_object when compiling C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78508 David Binderman changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from David Binderman --- Problem seems to have gone away.
[Bug lto/81487] [mingw32] ld.exe: error: asprintf failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81487 Georg-Johann Lay changed: What|Removed |Added Target Milestone|--- |7.2
[Bug tree-optimization/80613] [8 Regression] ICE in is_gimple_reg_type with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80613 David Binderman changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from David Binderman --- Problem seems solved to me.
[Bug rtl-optimization/81559] [8 Regression] ICE: verify_flow_info failed (error: non-cold basic block 4 reachable only by paths crossing the cold partition) on 32-bit BE powerpc target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81559 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Target Milestone|--- |8.0 --- Comment #1 from Richard Biener --- Honza?
[Bug c/81306] valgrind error for function warn_for_multistatement_macros in file c-warn.c line 2474
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81306 --- Comment #4 from Marek Polacek --- I've reproduced the issue but don't know what to do about it, it doesn't seem to be a bug in the warning. I looks like the macro maps contains holes: cc1: note: token 77 has x-location == y-location == 0 78: 0, 0 cc1: note: token 78 has x-location == y-location == 0 79: 0, 0 cc1: note: token 79 has x-location == y-location == 0 80: 0, 0 cc1: note: token 80 has x-location == y-location == 0 81: 0, 0 cc1: note: token 81 has x-location == y-location == 0 82: 0, 0 cc1: note: token 82 has x-location == y-location == 0 83: 0, 0 cc1: note: token 83 has x-location == y-location == 0 84: 0, 0 cc1: note: token 84 has x-location == y-location == 0 85: 0, 0 cc1: note: token 85 has x-location == y-location == 0 86: 0, 0 cc1: note: token 86 has x-location == y-location == 0 87: 0, 0 cc1: note: token 87 has x-location == y-location == 0 88: 0, 0 cc1: note: token 88 has x-location == y-location == 0 89: 0, 0 cc1: note: token 89 has x-location == y-location == 0 90: 0, 0 cc1: note: token 90 has x-location == y-location == 0
[Bug c/81306] valgrind error for function warn_for_multistatement_macros in file c-warn.c line 2474
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81306
--- Comment #5 from Marek Polacek ---
And I wonder if that's what this comment in dump_location_info talks about:
1187 for (unsigned int i = 0; i < MACRO_MAP_NUM_MACRO_TOKENS (map); i++)
1188 {
1189 source_location x = MACRO_MAP_LOCATIONS (map)[2 * i];
1190 source_location y = MACRO_MAP_LOCATIONS (map)[(2 * i) + 1];
1191
1192 /* linemap_add_macro_token encodes token numbers in an expansion
1193 by putting them after MAP_START_LOCATION. */
1194
1195 /* I'm typically seeing 4 uninitialized entries at the end of
1196 0xafafafaf.
1197 This appears to be due to macro.c:replace_args
1198 adding 2 extra args for padding tokens; presumably there may
1199 be a leading and/or trailing padding token injected,
1200 each for 2 more location slots.
1201 This would explain there being up to 4 source_locations slots
1202 that may be uninitialized. */
[Bug tree-optimization/81558] Loop not vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81558 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Blocks||53947 --- Comment #1 from Richard Biener --- The inner loop in foo2 is completely unrolled by GCC and imgY_org[y][x] is _32 = (long unsigned int) y_103; _33 = _32 * 8; _34 = imgY_org.8_31 + _33; _35 = *_34; where *_34 aliases *orgptr. Thus it's not possible to vectorize this without a runtime alias check. The innermost loop in foo1 is vectorized, the unrolled loop in foo2 is not basic-block vectorized because basic-block vectorization runs into the very same dependence issue. Does LLVM do a runtime alias check here? For foo1 GCC adds a runtime alias check (BB vectorization cannot version for aliasing). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug c/81306] valgrind error for function warn_for_multistatement_macros in file c-warn.c line 2474
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81306 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-07-26 Ever confirmed|0 |1 --- Comment #6 from Marek Polacek --- So, confirmed, but clueless.
[Bug rtl-optimization/38518] Excessive compile time with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38518 --- Comment #13 from Richard Biener --- Also look at gcc.opensuse.org/ in the c++bench "random" part. At -O2 it shows df live&initialized regs: 12.12 (31%) usr backwards jump threading: 6.44 (17%) usr the backwards jump threading thing is new. Jeff? At -O3 it runs OOM on vangelis, czerny reports 3.9GB memory use and besides the above: load CSE after reload : 120.58 (70%) usr I try to add most "interesting" compile-time/memory-use testcases to the C++ tester "random" part so we can track time-report / memory usage issues there. I think I've seen the load CSE after reload issue elsewhere, too.
[Bug c/81543] attribute may_alias on function and variable declarations silently accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81543 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- may_alias is the only attribute that is missing a handler in c_common_attribute_table.
[Bug rtl-optimization/38518] Excessive compile time with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38518 Richard Biener changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #14 from Richard Biener --- Actually CCing Jeff now -- see last comment, backward jump-threading compile-time hog at -O2.
[Bug c/81543] attribute may_alias on function and variable declarations silently accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81543
--- Comment #3 from Marek Polacek ---
But adding one wouldn't help because
487 /* If we require a type, but were passed a decl, set up to make a
488 new type and update the one in the decl. ATTR_FLAG_TYPE_IN_PLACE
489 would have applied if we'd been passed a type, but we cannot
modify
490 the decl's type in place here. */
491 if (spec->type_required && DECL_P (*anode))
492 {
493 anode = &TREE_TYPE (*anode);
494 flags &= ~(int) ATTR_FLAG_TYPE_IN_PLACE;
495 }
[Bug c/81453] relational expression involving null pointer not diagnosed with -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81453 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-07-26 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1
[Bug c/81453] relational expression involving null pointer not diagnosed with -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81453 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|mpolacek at gcc dot gnu.org|unassigned at gcc dot gnu.org
[Bug fortran/81552] -finit-integer=n is restricted to 32-bit INTEGER.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81552 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |NEW Last reconfirmed||2017-07-26 Summary|-finit-integer=n|-finit-integer=n is ||restricted to 32-bit ||INTEGER. Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Dominique d'Humieres --- > In fact, N is an 32-bit INTEGER in the range [-2147483648 ; 2147483647] This is true even for arrays of 64-bit INTEGER: integer(8) :: i(4) print *, i end compiled with -finit-integer=2147483648 gives at run time -2147483648 -2147483648 -2147483648 -2147483648 at least since gcc 4.8.5.
[Bug tree-optimization/81556] [7/8 Regression] Wrong code at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81556 --- Comment #4 from Jakub Jelinek --- Created attachment 41832 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41832&action=edit gcc8-pr81556.patch Untested fix. The current code whether a SSA_NAME can be reused or not is based on whether all the rhs2 ops are the same from the toplevel stmt (and whether there is powi/negate). That should work fine as long as the number of ops is the same after optimization, but in this case there is a removal of reduncant op, at which point that doesn't work anymore.
[Bug libgcc/78779] libgcc/soft-fp/op-common.h:900: possible missing break ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78779 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Resolution|WONTFIX |FIXED --- Comment #5 from Jakub Jelinek --- Well, WONTFIX is weird, because this has been actually fixed in r244884 in GCC and in af1a265da09829f9042619c885c64eb8567a59ce in glibc.
[Bug fortran/81499] internal compiler error when compiling gfortran code with user-defined derived type i/o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81499 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-07-26 CC||jvdelisle at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed. If I compile the code with an instrumented compiler, I get ASAN:DEADLYSIGNAL = ==6481==ERROR: AddressSanitizer: stack-overflow on address 0x7fff5bc00ff8 (pc 0x0001002be1d1 bp 0x7fff5bc01010 sp 0x7fff5bc01000 T0) #0 0x1002be1d0 in derived_inaccessible(gfc_symbol*) (/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.6.0/8.0.0/f951+0x1002be1d0) #1 0x1002be4d3 in derived_inaccessible(gfc_symbol*) (/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.6.0/8.0.0/f951+0x1002be4d3) #2 0x1002be4d3 in derived_inaccessible(gfc_symbol*) (/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.6.0/8.0.0/f951+0x1002be4d3) #3 0x1002be4d3 in derived_inaccessible(gfc_symbol*) (/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.6.0/8.0.0/f951+0x1002be4d3) #4 0x1002be4d3 in derived_inaccessible(gfc_symbol*) (/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.6.0/8.0.0/f951+0x1002be4d3) #5 0x1002be4d3 in derived_inaccessible(gfc_symbol*) (/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.6.0/8.0.0/f951+0x1002be4d3) ... The code compiles and gives the expected results at run time if remove the line (circular TYPEs) type (tape_type), pointer :: ref => null() ! if this line is commented out, the code will compile Likely related to pr46244.
[Bug tree-optimization/81554] [8 Regression] 25% performance regression in Himeno benchmark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81554 --- Comment #3 from Richard Biener --- Created attachment 41833 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41833&action=edit patch While we do this transform late with the attached patch it doesn't help (noisy) performance. Before: Score based on Pentium III 600MHz using Fortran 77: 19.465005 Score based on Pentium III 600MHz using Fortran 77: 19.558720 Score based on Pentium III 600MHz using Fortran 77: 19.546069 Score based on Pentium III 600MHz using Fortran 77: 19.572887 Score based on Pentium III 600MHz using Fortran 77: 19.528043 Score based on Pentium III 600MHz using Fortran 77: 19.477979 Score based on Pentium III 600MHz using Fortran 77: 19.534370 Score based on Pentium III 600MHz using Fortran 77: 19.562271 Score based on Pentium III 600MHz using Fortran 77: 19.495751 Score based on Pentium III 600MHz using Fortran 77: 19.542132 After: Score based on Pentium III 600MHz using Fortran 77: 19.436746 Score based on Pentium III 600MHz using Fortran 77: 19.510495 Score based on Pentium III 600MHz using Fortran 77: 19.479649 Score based on Pentium III 600MHz using Fortran 77: 19.470079 Score based on Pentium III 600MHz using Fortran 77: 19.470537 Score based on Pentium III 600MHz using Fortran 77: 19.539023 Score based on Pentium III 600MHz using Fortran 77: 19.421880 Score based on Pentium III 600MHz using Fortran 77: 19.504202 Score based on Pentium III 600MHz using Fortran 77: 19.545846 Score based on Pentium III 600MHz using Fortran 77: 19.571152 Either the transform is required pre-loop opts or flag_wrapv pessimizes stuff. I suppose some additional pass re-shuffling would be in order, like moving the block late_gimple_start, reassoc, strength_reduction to after vrp, phi_only_cprop so VRP has the chance to compute good !flag_wrapv ranges late. That results in Score based on Pentium III 600MHz using Fortran 77: 19.076637 Score based on Pentium III 600MHz using Fortran 77: 19.141776 Score based on Pentium III 600MHz using Fortran 77: 19.078936 Score based on Pentium III 600MHz using Fortran 77: 19.146834 Score based on Pentium III 600MHz using Fortran 77: 19.098964 Score based on Pentium III 600MHz using Fortran 77: 19.098782 Score based on Pentium III 600MHz using Fortran 77: 19.127632 Score based on Pentium III 600MHz using Fortran 77: 19.095203 Score based on Pentium III 600MHz using Fortran 77: 19.111919 Score based on Pentium III 600MHz using Fortran 77: 18.993788 thus looks even worse ;) (all the above is with just -O3 on a Broadwell system) I guess reassoc is necessary for DOM to do a good CSE job. OTOH tracer and path splitting should enable more reassoc/SLSR so should be before (but they shouldn't care about flag_wrapv). Thus if we do NEXT_PASS (pass_sprintf_length, true); NEXT_PASS (pass_split_paths); NEXT_PASS (pass_tracer); NEXT_PASS (pass_thread_jumps); NEXT_PASS (pass_vrp, false /* warn_array_bounds_p */); /* The only const/copy propagation opportunities left after DOM and VRP should be due to degenerate PHI nodes. So rather than run the full propagators, run a specialized pass which only examines PHIs to discover const/copy propagation opportunities. */ NEXT_PASS (pass_phi_only_cprop); /* Dumbing down to -fwrapv for reassoc to work and forwprop folding not hindered by undefined overflow disabling transforms. Matches semantics of RTL. */ NEXT_PASS (pass_late_gimple_start); NEXT_PASS (pass_reassoc, false /* insert_powi_p */); NEXT_PASS (pass_strength_reduction); NEXT_PASS (pass_dominator, false /* may_peel_loop_headers_p */); /* The only const/copy propagation opportunities left after DOM and VRP should be due to degenerate PHI nodes. So rather than run the full propagators, run a specialized pass which only examines PHIs to discover const/copy propagation opportunities. */ NEXT_PASS (pass_phi_only_cprop); NEXT_PASS (pass_strlen); NEXT_PASS (pass_thread_jumps); NEXT_PASS (pass_dse); we end up with Score based on Pentium III 600MHz using Fortran 77: 19.467136 Score based on Pentium III 600MHz using Fortran 77: 19.489240 Score based on Pentium III 600MHz using Fortran 77: 19.413257 Score based on Pentium III 600MHz using Fortran 77: 19.285549 Score based on Pentium III 600MHz using Fortran 77: 19.352476 Score based on Pentium III 600MHz using Fortran 77: 19.487067 Score based on Pentium III 600MHz using Fortran 77: 19.513724 Score based on Pentium III 600MHz using Fortran 77: 19.515330 Score based on Pentium III 600MHz using Fortran 77: 19.523810 Score based on Pentium III 600MHz using Fortran 77: 19.518709 Anyway, some more detailed analysis is required here [note I didn't try to reproduce the slowdown]. Pass shuffling is always "interesting"...
[Bug fortran/81411] intrinsic polymorphic assignment run time error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81411 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-07-26 CC||pault at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed for gfortran supporting "Assignment to an allocatable polymorphic variable", i.e., 7 and trunk. Compiling the test with an instrumented compiler gives at run time calling display subroutine ASAN:DEADLYSIGNAL = ==6560==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 0x000103b42b44 bp 0x7fff5c0bdf40 sp 0x7fff5c0bdf00 T0) ==6560==The signal is caused by a READ memory access. ==6560==Hint: address points to the zero page. #0 0x103b42b43 in __display_module_MOD_display (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/./a.out+0x11b43) #1 0x103b42d46 in MAIN__ (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/./a.out+0x11d46) #2 0x103b43916 in main (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/./a.out+0x12916) #3 0x7fff9e181234 in start (/usr/lib/system/libdyld.dylib+0x5234) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/./a.out+0x11b43) in __display_module_MOD_display ==6560==ABORTING Program received signal SIGABRT: Process abort signal.
[Bug rtl-optimization/38518] Excessive compile time with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38518 --- Comment #15 from David Binderman --- (In reply to David Binderman from comment #12) > With recent gcc: > > no -O flag: 2 seconds > > -O2: 24 seconds > > -O3: 247 seconds Those numbers for a version of trunk gcc with lots of checking. Without checking, I get gcc trunk with -O3 in 4 mins 56 seconds and release gcc 7.1.1 in 3 minutes 38 seconds, so it still looks like it's going backwards. From -ftime-report on trunk gcc with -O3: $ grep "([0-9][0-9]\%) usr" report.out df live&initialized regs: 45.04 (16%) usr 0.06 ( 2%) sys 45.74 (15%) wall 0 kB ( 0%) ggc load CSE after reload : 174.76 (60%) usr 0.07 ( 2%) sys 176.23 (60%) wall 10 kB ( 0%) ggc $ So I think that confirms what Richard is seeing.
[Bug middle-end/46932] Inefficient code sequence to access local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46932 --- Comment #5 from Wilco --- Author: wilco Date: Wed Jul 26 10:49:17 2017 New Revision: 250564 URL: https://gcc.gnu.org/viewcvs?rev=250564&root=gcc&view=rev Log: Fix PR46932: Block auto increment on frame pointer Block auto increment on frame pointer references. This is never beneficial since the SFP expands into SP+C or FP+C during register allocation. The generated code for the testcase is now as expected: str x30, [sp, -32]! strbw0, [sp, 31] add x0, sp, 31 bl foo3 ldr x30, [sp], 32 ret gcc/ PR middle-end/46932 * auto-inc-dec.c (parse_add_or_inc): Block autoinc on sfp. gcc/testsuite/ PR middle-end/46932 * gcc.dg/pr46932.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr46932.c Modified: trunk/gcc/ChangeLog trunk/gcc/auto-inc-dec.c trunk/gcc/testsuite/ChangeLog
[Bug ipa/81293] sanitized g++ crashes heap-use-after-free gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors_format.inc:543 in printf_common
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81293 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||5.4.0, 6.4.0, 7.1.0 Resolution|--- |FIXED Known to fail|5.4.0, 6.4.0, 7.1.0 | --- Comment #4 from Martin Liška --- It's fine for GCC 5,6,7 branches, thus closing as resolved.
[Bug sanitizer/81275] [5/6/7/8 Regression] -fsanitize=thread produce incorrect -Wreturn-type warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81275
Jakub Jelinek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
Marek, could we reuse the fallthrough warning infrastructure for this to
determine whether there is a possible fallthrough or not?
Though, trying:
int
foo (int a, int b, int c)
{
switch (c)
{
case 5:
switch (a)
{
case 0:
switch (b)
{
default:
return 0;
}
break;
#ifdef FT
case 7:
break;
#endif
default:
return 0;
}
case 6:
return 7;
}
return 8;
}
we don't warn about the fallthrough from case 5 to case 6 no matter if FT is
defined (in that case there is obvious fallthrough, say for foo (7, 0, 5), or
when FT is not defined (then there isn't, but gimple_seq_may_fallthru doesn't
know that). Whether a label is emitted after a switch (for the break; label)
is determined already in the FEs based on whether any break; is present, no
matter if reachable or not. So indeed, dead code such as the break; in your
#c0 testcase, or whatever other code followed by a break, is able to confuse
the gimplifier and eh lowering into assuming there might be fallthrough.
While the -Wreturn-type warning is emitted after cfg is built, the problem is
if we decide to emit the try/finally with a finally_tmp variable to avoid
duplicating the cleanup actions, then while after building cfg we optimize away
obviously unreachable code, we have no SSA form yet and thus determining if the
finally_tmp.N variable is always the same in all paths might be expensive.
At -O0 that actually isn't optimized by anything until assembly is emited, so
we still see in the assembly:
testl %eax, %eax
jne .L9
movl$0, %ebx
movl$0, %r12d
jmp .L4
.L9:
movl$0, %ebx
movl$0, %r12d
.L4:
// Here both %ebx and %r12d are 0 (set the same on both paths reaching this
// label.
leaq-17(%rbp), %rax
movq%rax, %rdi
// Here we run ~C()
call_ZN1CD1Ev
// Now we test whether it is 1, which is never, in that case we fall through
// into returning without a value.
cmpl$1, %r12d
jne .L10
nop
jmp .L1
.L10:
movl%ebx, %eax
.L1:
addq$32, %rsp
popq%rbx
popq%r12
popq%rbp
ret
So, if we can't do anyuthing for this at the gimplifier level, we'd need to add
an optimization in the cfg pass that would look for cases like:
;; basic block 4, loop depth 0
;;pred: 3
[0.00%] [count: INV]:
D.2315 = 0;
finally_tmp.0 = 0;
goto ; [INV] [count: INV]
;;succ: 6
;; basic block 5, loop depth 0
;;pred: 3
[0.00%] [count: INV]:
D.2315 = 0;
finally_tmp.0 = 0;
;;succ: 6
;; basic block 6, loop depth 0
;;pred: 4
;;5
C::~C (&c);
switch (finally_tmp.0) [INV] [count: INV], case 1: [INV]
[count: INV]>
and optimize that switch into goto ; after checking that finally_tmp.0 var
is not addressable, not modified in the bb with the switch and set to the same
value at the end of all predecessor bbs.
But that would be an optimization, not sure if we want to do that generally for
-O0, or limit it to somehow specially marked finally_tmp.NN variables.
[Bug tree-optimization/81555] [5/6/7/8 Regression] Wrong code at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81555 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-07-26 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #6 from Martin Liška --- So with -O2 it started to output '0, 0' in r234764. For -O1 it started to output '0, 0' in r236338.
[Bug rtl-optimization/81553] [7/8 Regression] ICE in immed_wide_int_const, at emit-rtl.c:607
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81553 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-07-26 CC||bernds at codesourcery dot com, ||marxin at gcc dot gnu.org Summary|[8 Regression] ICE in |[7/8 Regression] ICE in |immed_wide_int_const, at|immed_wide_int_const, at |emit-rtl.c:607 |emit-rtl.c:607 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r244817.
[Bug ipa/81541] Potential size optimisation: reusing common function endings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81541 Martin Liška changed: What|Removed |Added CC|mliska at suse dot cz | Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Thanks for filling this, it will probably need some sharing of infrastructure of current IPA split and IPA ICF. I will read the post and think about it more.
[Bug c/79153] -Wimplicit-fallthrough missed warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79153 --- Comment #7 from Marek Polacek --- No WONTFIX, we ought to be able to handle this.
[Bug sanitizer/81275] [5/6/7/8 Regression] -fsanitize=thread produce incorrect -Wreturn-type warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81275
--- Comment #5 from Marek Polacek ---
(In reply to Jakub Jelinek from comment #4)
> Marek, could we reuse the fallthrough warning infrastructure for this to
> determine whether there is a possible fallthrough or not?
> Though, trying:
> int
> foo (int a, int b, int c)
> {
> switch (c)
> {
> case 5:
> switch (a)
> {
> case 0:
> switch (b)
> {
> default:
> return 0;
> }
> break;
> #ifdef FT
> case 7:
> break;
> #endif
> default:
> return 0;
> }
> case 6:
> return 7;
> }
> return 8;
> }
>
> we don't warn about the fallthrough from case 5 to case 6 no matter if FT is
> defined (in that case there is obvious fallthrough, say for foo (7, 0, 5), or
> when FT is not defined (then there isn't, but gimple_seq_may_fallthru
> doesn't know that).
Unfortunately, not yet, because -Wimplicit-fallthrough doesn't scan nested
switches (PR79153).
[Bug target/79793] Incorrect stack alignment for interrupt handler in 64-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79793 H.J. Lu changed: What|Removed |Added Attachment #41830|0 |1 is obsolete|| --- Comment #14 from H.J. Lu --- Created attachment 41834 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41834&action=edit An untested patch
[Bug middle-end/70992] Infinite recursion between fold_build2_stat_loc and fold_binary_loc w/ -fwrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70992 --- Comment #8 from Marek Polacek --- Author: mpolacek Date: Wed Jul 26 11:53:17 2017 New Revision: 250566 URL: https://gcc.gnu.org/viewcvs?rev=250566&root=gcc&view=rev Log: PR middle-end/70992 * tree.c (build2_stat): Don't set TREE_CONSTANT on divisions by zero. * gcc.dg/overflow-warn-1.c: Adjust dg-error. * gcc.dg/overflow-warn-2.c: Likewise. * gcc.dg/overflow-warn-3.c: Likewise. * gcc.dg/overflow-warn-4.c: Likewise. * gcc.dg/torture/pr70992-2.c: New test. * gcc.dg/torture/pr70992.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr70992-2.c trunk/gcc/testsuite/gcc.dg/torture/pr70992.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/overflow-warn-1.c trunk/gcc/testsuite/gcc.dg/overflow-warn-2.c trunk/gcc/testsuite/gcc.dg/overflow-warn-3.c trunk/gcc/testsuite/gcc.dg/overflow-warn-4.c trunk/gcc/tree.c
[Bug target/79041] aarch64 backend emits R_AARCH64_ADR_PREL_PG_HI21 relocation despite -mpc-relative-literal-loads option being used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79041 --- Comment #10 from Wilco --- Author: wilco Date: Wed Jul 26 11:55:03 2017 New Revision: 250567 URL: https://gcc.gnu.org/viewcvs?rev=250567&root=gcc&view=rev Log: Disable pr79041-2.c with -mabi=ilp32. gcc/testsuite/ PR target/79041 * gcc.target/aarch64/pr79041-2.c: Don't run in ILP32. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/aarch64/pr79041-2.c
[Bug middle-end/70992] Infinite recursion between fold_build2_stat_loc and fold_binary_loc w/ -fwrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70992 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug middle-end/70992] Infinite recursion between fold_build2_stat_loc and fold_binary_loc w/ -fwrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70992 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Marek Polacek --- Fixed for GCC 8.
[Bug target/79041] aarch64 backend emits R_AARCH64_ADR_PREL_PG_HI21 relocation despite -mpc-relative-literal-loads option being used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79041 --- Comment #11 from Wilco --- Author: wilco Date: Wed Jul 26 11:57:57 2017 New Revision: 250569 URL: https://gcc.gnu.org/viewcvs?rev=250569&root=gcc&view=rev Log: Disable pr79041-2.c with -mabi=ilp32. gcc/testsuite/ PR target/79041 * gcc.target/aarch64/pr79041-2.c: Don't run in ILP32. Modified: branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/testsuite/gcc.target/aarch64/pr79041-2.c
[Bug web/81560] New: Error in C documentation regarding min/max substitute macros MIN/MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81560 Bug ID: 81560 Summary: Error in C documentation regarding min/max substitute macros MIN/MAX Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: um4711 at mutluit dot com Target Milestone: --- On this documentation page an example for defining a macro MIN(X,Y) is given: https://gcc.gnu.org/onlinedocs/gcc-3.4.2/gcc/Min-and-Max.html There is a bug in the definition. It reads: #define MIN(X,Y) ((X) < (Y) ? : (X) : (Y)) It can't compile; it of course needs to be changed to: #define MIN(X,Y) ((X) < (Y) ? (X) : (Y))
[Bug gcov-profile/81561] New: [7/8 Regression] Segfault in gcov with -a argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81561 Bug ID: 81561 Summary: [7/8 Regression] Segfault in gcov with -a argument Product: gcc Version: 7.0 URL: https://bugzilla.suse.com/show_bug.cgi?id=1050487 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 41835 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41835&action=edit gcno file Originally comes from openSUSE bugzilla.
[Bug gcov-profile/81561] [7/8 Regression] Segfault in gcov with -a argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81561 --- Comment #1 from Martin Liška --- Created attachment 41836 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41836&action=edit gcda file
[Bug gcov-profile/81561] [7/8 Regression] Segfault in gcov with -a argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81561 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-07-26 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Mine.
[Bug c/81448] False positive -Werror=multistatement-macros in openssl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81448
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-07-26
Ever confirmed|0 |1
--- Comment #7 from Marek Polacek ---
I think this is a real bug now:
void baz (void);
#define FOO for (int i = 0; i < 10; i++)
#define BAR \
void bar (void) \
{ \
FOO \
baz (); \
return; \
}
BAR
the warning is fooled because the "body" (baz();) and "next" are coming from
the same expansion, and "guard" isn't.
[Bug gcov-profile/81561] [7/8 Regression] Segfault in gcov with -a argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81561 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |7.2
[Bug fortran/54072] BOZ with -std=f2008: wrongly accepted to TRANSFER/ABS/...; two BOZ not rejected for IOR/IEOR/IAND
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54072 --- Comment #5 from Dominique d'Humieres --- See also pr81509.
[Bug fortran/81509] Wrong compilation error: iand/ieor/ior + boz + -std=f2008
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81509 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |NEW Last reconfirmed||2017-07-26 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #3 from Dominique d'Humieres --- (1) Work around: wrap the boz-literal-constant inside an INT, e.g., program p implicit none write(*,*) iand(int(z'1A2B3C4D' ),3), iand(8, int(z'1A2B3C4D' )) write(*,*) ior(int(z'1A2B3C4D' ),3), ior(8, int(z'1A2B3C4D' )) write(*,*) ieor(int(z'1A2B3C4D' ),3), ieor(8, int(z'1A2B3C4D' )) write(*,*) iand(int(o'123456' ),4), iand(7, int(o'123456' )) write(*,*) ior(int(o'123456' ),4), ior(7, int(o'123456' )) write(*,*) ieor(int(o'123456' ),4), ieor(7, int(o'123456' )) write(*,*) iand(int(b'001011101'),5), iand(6, int(b'001011101')) write(*,*) ior(int(b'001011101'),5), ior(6, int(b'001011101')) write(*,*) ieor(int(b'001011101'),5), ieor(6, int(b'001011101')) end program p (2) From https://gcc.gnu.org/onlinedocs/gfortran/BOZ-literal-constants.html#BOZ-literal-constants > In all other cases, the BOZ literal constant is converted to an INTEGER value > with the largest decimal representation. i.e., INTEGER(16) in 64-bit mode and INTEGER(8) in 32-bit mode. IMO it is compatible with > The processor shall allow the position of the leftmost nonzero bit to be > at least z - 1, where z is the maximum value that could result from invoking > the intrinsic function STORAGE_SIZE (13.8.175) with an argument that is > a real or integer scalar of any kind supported by the processor. Note that the (invalid, see pr54072) code program p implicit none print *, kind(iand(b'001011101',b'101')) print *, kind(ieor(b'001011101',b'101')) print *, kind(ior(b'001011101',b'101')) end program p gives 16 16 16 in 64-bit mode, and 8 8 8 in 32-bit mode. (3) I agree that the KIND should not be checked for boz-literal-constant.
