[Bug c/61240] [4.8/4.9/4.10 Regression] Incorrect warning integer overflow in expression on pointer-pointer subtraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61240 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- Maybe best would be to remove the optimization in pointer_diff altogether. Mine for now.
[Bug c/61240] [4.8/4.9/4.10 Regression] Incorrect warning integer overflow in expression on pointer-pointer subtraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61240 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- But in that case we should have an adequate replacement on the match_and_simplify side.
[Bug c/61240] [4.8/4.9/4.10 Regression] Incorrect warning integer overflow in expression on pointer-pointer subtraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61240 --- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org --- But C++ has its own pointer_diff version that doesn't do such optimization. With my change the C FE would generate the same expr as the C++ FE. And FEs shouldn't perform such optimizations anyway.
[Bug middle-end/60070] An option to disable all floating-pont
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60070 thopre01 at gcc dot gnu.org changed: What|Removed |Added CC||thopre01 at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |thopre01 at gcc dot gnu.org --- Comment #2 from thopre01 at gcc dot gnu.org --- It seems to me that the comment from Peter Anvin rather advocates for a target independent option to check whether float are used or not. I'm actually working on such a patch and should have soon something to show.
[Bug target/61357] Patch for 60969 causes MIPS regressions in register allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61357 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|rtl-optimization|target Resolution|--- |FIXED Target Milestone|--- |4.10.0 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01237.html
[Bug bootstrap/62005] New: [4.10 regression] with --enable-checking=rtl : loop-unroll.c:2095:10: error: function may return address of local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62005 Bug ID: 62005 Summary: [4.10 regression] with --enable-checking=rtl : loop-unroll.c:2095:10: error: function may return address of local variable Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: dimhen at gmail dot com r213523, r213529 FAIL r213316 PASS ~/src/gcc_r213529/configure --enable-checking=rtl make [...] make[3]: Entering directory `/home/dimhen/build/gcc_r213529_rtl/gcc' /home/dimhen/build/gcc_r213529_rtl/./prev-gcc/xg++ -B/home/dimhen/build/gcc_r213529_rtl/./prev-gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/home/dimhen/build/gcc_r213529_rtl/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/home/dimhen/build/gcc_r213529_rtl/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/home/dimhen/build/gcc_r213529_rtl/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/home/dimhen/build/gcc_r213529_rtl/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/home/dimhen/src/gcc_r213529/libstdc++-v3/libsupc++ -L/home/dimhen/build/gcc_r213529_rtl/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/dimhen/build/gcc_r213529_rtl/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -c -g -O2 -gtoggle -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -DHAVE_CONFIG_H -I. -I. -I/home/dimhen/src/gcc_r213529/gcc -I/home/dimhen/src/gcc_r213529/gcc/. -I/home/dimhen/src/gcc_r213529/gcc/../include -I/home/dimhen/src/gcc_r213529/gcc/../libcpp/include -I/home/dimhen/build/gcc_r213529_rtl/./gmp -I/home/dimhen/src/gcc_r213529/gmp -I/home/dimhen/build/gcc_r213529_rtl/./mpfr -I/home/dimhen/src/gcc_r213529/mpfr -I/home/dimhen/src/gcc_r213529/mpc/src -I/home/dimhen/src/gcc_r213529/gcc/../libdecnumber -I/home/dimhen/src/gcc_r213529/gcc/../libdecnumber/bid -I../libdecnumber -I/home/dimhen/src/gcc_r213529/gcc/../libbacktrace -DCLOOG_INT_GMP -I/home/dimhen/build/gcc_r213529_rtl/./cloog/include -I/home/dimhen/src/gcc_r213529/cloog/include -I/home/dimhen/build/gcc_r213529_rtl/./isl/include -I/home/dimhen/src/gcc_r213529/isl/include -o loop-unroll.o -MT loop-unroll.o -MMD -MP -MF ./.deps/loop-unroll.TPo /home/dimhen/src/gcc_r213529/gcc/loop-unroll.c /home/dimhen/src/gcc_r213529/gcc/loop-unroll.c: In function 'rtx_def** get_ivts_expr(rtx, iv_to_split*)': /home/dimhen/src/gcc_r213529/gcc/loop-unroll.c:2095:10: error: function may return address of local variable [-Werror=return-local-addr] return ret; ^ /home/dimhen/src/gcc_r213529/gcc/loop-unroll.c:2087:20: note: declared here get_ivts_expr (rtx expr, struct iv_to_split *ivts) ^ cc1plus: all warnings being treated as errors make[3]: *** [loop-unroll.o] Error 1 make[3]: Leaving directory `/home/dimhen/build/gcc_r213529_rtl/gcc'
[Bug c++/62003] Possible bug in std::complex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62003 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-08-04 Version|unknown |4.8.1 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Please provide the output of 'gcc -v' as requested at http://gcc.gnu.org/bugs
[Bug bootstrap/62005] [4.10 regression] with --enable-checking=rtl : loop-unroll.c:2095:10: error: function may return address of local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62005 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||glisse at gcc dot gnu.org Target Milestone|--- |4.10.0 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Hmm, the warning is true if ivts-n_loc == 0. Marc?
[Bug target/61713] ICE when building c++ code with atomic functions for thumb1 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61713 --- Comment #5 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Mon Aug 4 10:03:32 2014 New Revision: 213555 URL: https://gcc.gnu.org/viewcvs?rev=213555root=gccview=rev Log: PR 61713: ICE when expanding single-threaded version of atomic_test_and_set. PR target/61713 * gcc/optabs.c (expand_atomic_test_and_set): Do not try to emit move to subtarget in serial version if result is ignored. PR target/61713 * gcc.dg/pr61756.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr61756.c Modified: trunk/gcc/ChangeLog trunk/gcc/optabs.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/62004] dead type-unsafe load replaces type-safe load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62004 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-04 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Heh, interesting set of events ;) Now it is interesting how much we desire to perform the tail-merging - we _could_ change the alias sets of loads (and stores...) to a common one (either if they are equal or just zero otherwise). Depends on how much we like this kind of pessimization. Same for the RTL bits of course. Btw, I still see the conditional execution after RTL expansion, just cfglayout mode doesn't have unconditonal gotos for the edges.
[Bug ipa/61998] [4.10 Regression] ICE: Segmentation fault with -Wsuggest-final-types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61998 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.10.0
[Bug bootstrap/62005] [4.10 regression] with --enable-checking=rtl : loop-unroll.c:2095:10: error: function may return address of local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62005 --- Comment #2 from Marc Glisse glisse at gcc dot gnu.org --- Ah, I didn't test with --enable-ckecking=rtl. We could split the maybe part of the warning and downgrade it to Wextra, but I'd rather keep it at least in Wall, which means we need to change the loop-unroll code anyway. The code is not easy to understand. For instance, I don't see where n_loc can be set to any value other than 1? That would make it easy to simplify this loop...
[Bug c++/62006] New: Bad code generation with -O3 (possibly due to -ftree-partial-pre)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006 Bug ID: 62006 Summary: Bad code generation with -O3 (possibly due to -ftree-partial-pre) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tkoeppe at google dot com Created attachment 33231 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33231action=edit Demonstrates bad code generation with -O3 I was writing some code to demonstrate custom allocators with fancy pointers. While testing it with GCC, I noticed memory corruption when compiling with -O3. Jonathan Wakely had a quick look and narrowed it down to -O2 -ftree-partial-pre; with just -O2 the code works. I don't have any insights in the problem, so I'm just attaching the full code. You can tell that it's broken by passing the program through valgrind, or simply by noting that it prints all container elements as zero, rather than their actual values. (Incidentally, I believe there's a similar problem in Clang: http://llvm.org/bugs/show_bug.cgi?id=20524)
[Bug rtl-optimization/34716] application segfaults when compiled with -O2, but works well with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34716 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-08-04 CC||ktietz at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #7 from Kai Tietz ktietz at gcc dot gnu.org --- As 5.1 is now already for some time no more in maintenance it would be interesting to learn if that problem is still there for more current version (4.9, 4.8) gcc.
[Bug rtl-optimization/34716] application segfaults when compiled with -O2, but works well with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34716 --- Comment #8 from Kai Tietz ktietz at gcc dot gnu.org --- (In reply to Kai Tietz from comment #7) As 5.1 is now already for some time no more in maintenance it would be interesting to learn if that problem is still there for more current version (4.9, 4.8) gcc. Of course I mean 4.1
[Bug fortran/62007] New: default(none) conflicts with iteration variable in openmp parallel loop simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62007 Bug ID: 62007 Summary: default(none) conflicts with iteration variable in openmp parallel loop simd Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: alexander.grund at mailbox dot tu-dresden.de If you use the default(none) clause in a parallel loop simd construct gfortran will complain about having not set the iteration variable in a private/shared clause: error: 'i_ct' not specified in enclosing parallel If you however do specify it in a private clause, gfortran will yield: Error: !$OMP PARALLEL DO SIMD iteration variable present on clause other than LINEAR at (1) Trivial example: !$omp parallel do simd default(none) do i_ct = 1, 10 ... end do If you use a normal parallel do both variants work.
[Bug fortran/62007] default(none) conflicts with iteration variable in openmp parallel loop simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62007 Alexander Grund alexander.grund at mailbox dot tu-dresden.de changed: What|Removed |Added Severity|normal |major
[Bug fortran/62007] default(none) conflicts with iteration variable in openmp parallel loop simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62007 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-08-04 Ever confirmed|0 |1 Severity|major |normal --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Could you provide a complete test code?
[Bug tree-optimization/62006] Bad code generation with -O3 (possibly due to -ftree-partial-pre)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-04 Component|c++ |tree-optimization Version|unknown |4.9.1 Ever confirmed|0 |1 Known to fail||4.10.0, 4.8.2, 4.9.1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- N.B. compile with -std=c++11 I can't tell whether it's a regression without rewriting some of the code to avoid features that aren't supported prior to 4.8
[Bug fortran/62007] default(none) conflicts with iteration variable in openmp parallel loop simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62007 --- Comment #2 from Alexander Grund alexander.grund at mailbox dot tu-dresden.de --- Created attachment 33232 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33232action=edit Working example
[Bug fortran/62007] default(none) conflicts with iteration variable in openmp parallel loop simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62007 --- Comment #3 from Alexander Grund alexander.grund at mailbox dot tu-dresden.de --- Created attachment 33233 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33233action=edit Broken example
[Bug fortran/62007] default(none) conflicts with iteration variable in openmp parallel loop simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62007
--- Comment #4 from Alexander Grund alexander.grund at mailbox dot
tu-dresden.de ---
I attached 2 testcases. Both are the same files but with different file
endings. The .f works, the .F90 doesn't (it shows the reported behavior)
compile both with gfortran -fopenmp {file}
[Bug rtl-optimization/61672] Less redundant instructions deleted by pre_delete after r208113.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61672 --- Comment #1 from Yuri Rumyantsev ysrumyan at gmail dot com --- Any comments will be appreciated.
[Bug libstdc++/61909] Small function optimization not applied to small objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61909 --- Comment #4 from lukeocamden at gmail dot com --- (In reply to Jonathan Wakely from comment #3) (In reply to lukeocamden from comment #2) (In reply to Jonathan Wakely from comment #1) This is by design. I don't really follow - do you mean a consequence of the design, or does the standard mandate copying/moving the object into the heap, or does using the heap have some other benefit? None of the above. I mean the author of our std::function intentionally chose to only avoid the heap for function pointers /** * Trait identifying location-invariant types, meaning that the * address of the object (or any of its members) will not escape. * Also implies a trivial copy constructor and assignment operator. */ If this doesn't offer a clear advantage, should I try to come up with a patch to support small objects too?
[Bug libstdc++/61909] Small function optimization not applied to small objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61909 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- I already have a patch to do it
[Bug rtl-optimization/61672] Less redundant instructions deleted by pre_delete after r208113.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61672 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- This only changes the way we represent mem_attrs. It seems to me that eventually mem_attr comparison doesn't work as expected? Note sure where PRE looks at the stmts - LCM looks like bitmap stuff only, I only see canon_true_dependence calls that may make a difference. Also please specify the target you used to reproduce this.
[Bug tree-optimization/62006] Bad code generation with -O3 (possibly due to -ftree-partial-pre)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- There is only a single extra PRE performed by partial-PRE. I'll have a look.
[Bug other/61963] CilkPlus Array Notation ICE in build_array_notation_ref on malformed function arguments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61963 Nick Tomlinson nick.tomlinson at arm dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Nick Tomlinson nick.tomlinson at arm dot com --- I built GCC r213543 this morning, and have found that the code in the minimal reproducer no longer produces an ICE - good work! :D - Thanks.
[Bug c++/62003] Possible bug in std::complex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62003 --- Comment #2 from Daniel Wilczak wilczak at ii dot uj.edu.pl --- OS version Windows 7, 64-bit. gcc version: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/lto-wrapper.exe Target: mingw32 Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 --build=mingw32 --without-pic --enable-shared --enable-static --with-gnu-ld --enable-lto --enable-libssp --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --with-gmp=/usr/src/pkg/gmp-5.1.2-1-mingw32-src/bld --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --with-mpfr= --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-libgomp --enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/mingw --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T Thread model: win32 gcc version 4.8.1 (GCC)
[Bug other/62008] New: CilkPlus Array Notation ICE in build_array_notation_ref when trying to build a multidimensional array from a pointer.
20140804 (experimental) Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug c++/62003] Possible bug in std::complex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62003 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Target||mingw32 Status|WAITING |UNCONFIRMED Ever confirmed|1 |0 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- I can't reproduce this on GNU/Linux, so it might be a target issue.
[Bug c++/62003] Possible bug in std::complex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62003 --- Comment #4 from Daniel Wilczak wilczak at ii dot uj.edu.pl --- Me neither - on GNU/Linux the program runs normally. Daniel W dniu 2014-08-04 13:32, redi at gcc dot gnu.org pisze: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62003 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Target||mingw32 Status|WAITING |UNCONFIRMED Ever confirmed|1 |0 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- I can't reproduce this on GNU/Linux, so it might be a target issue.
[Bug c++/61455] Internal compiler error, and other confused errors, when using array notation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61455 Nick Tomlinson nick.tomlinson at arm dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Nick Tomlinson nick.tomlinson at arm dot com --- I built GCC r213543 this morning, and have found that the code in the minimal reproducer no longer produces an ICE - good work! :D - Thanks.
[Bug bootstrap/62009] New: Bootstrap failure on i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62009 Bug ID: 62009 Summary: Bootstrap failure on i686 Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: izamyatin at gmail dot com Target: i686 After r213517 | tbsaunde | 2014-08-02 15:34:54 +0400 (Sat, 02 Aug 2014) | 27 lines convert many uses of pointer_map to hash_map gcc/c-family/ * cilk.c: Use hash_map instead of pointer_map. gcc/c/ * c-typeck.c: Use hash_map instead of pointer_map. gcc/cp/ * optimize.c, semantics.c: Use hash_map instead of pointer_map. gcc/ * hash-map.h (default_hashmap_traits::mark_key_deleted): Fix cast. (hash_map::remove): New method. (hash_map::traverse): New method. * cgraph.h, except.c, except.h, gimple-ssa-strength-reduction.c, ipa-utils.c, lto-cgraph.c, lto-streamer.h, omp-low.c, predict.c, tree-cfg.c, tree-cfgcleanup.c, tree-eh.c, tree-eh.h, tree-inline.c, tree-inline.h, tree-nested.c, tree-sra.c, tree-ssa-loop-im.c, tree-ssa-loop-ivopts.c, tree-ssa-reassoc.c, tree-ssa-structalias.c, tree-ssa.c, tree-ssa.h, var-tracking.c: Use hash_map instead of pointer_map. bootstrap for the following configuration CC=gcc -m32 CXX=g++ -m32 ../src-trunk/configure --enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-in-ld i686-linux --with-fpmath=sse --enable-languages=c,c++,fortran,java,lto,objc fails like: ../../src-trunk/gcc/dwarf2cfi.c:706:1: internal compiler error: in splice, at vec.h:844 def_cfa_0 (dw_cfa_location *old_cfa, dw_cfa_location *new_cfa) ^ 0x8c0c15f vec_edge_var_map, va_heap, vl_embed::splice(vec_edge_var_map, va_heap, vl_embed) ../../src-trunk/gcc/vec.h:844 0x8c0bd72 vec_edge_var_map, va_heap, vl_ptr::splice(vec_edge_var_map, va_heap, vl_ptr) ../../src-trunk/gcc/vec.h:1495 0x8c0b783 vec_edge_var_map, va_heap, vl_ptr::safe_splice(vec_edge_var_map, va_heap, vl_ptr) ../../src-trunk/gcc/vec.h:1512 0x8c06770 redirect_edge_var_map_dup(edge_def*, edge_def*) ../../src-trunk/gcc/tree-ssa.c:113 0x859bbac redirect_edge_succ_nodup(edge_def*, basic_block_def*) ../../src-trunk/gcc/cfghooks.c:437 0x8c068e3 ssa_redirect_edge(edge_def*, basic_block_def*) ../../src-trunk/gcc/tree-ssa.c:173 0x8a2c86b gimple_try_redirect_by_replacing_jump ../../src-trunk/gcc/tree-cfg.c:5419 0x8a2c90b gimple_redirect_edge_and_branch ../../src-trunk/gcc/tree-cfg.c:5450 0x859b940 redirect_edge_and_branch(edge_def*, basic_block_def*) ../../src-trunk/gcc/cfghooks.c:356 0x8a38335 remove_forwarder_block ../../src-trunk/gcc/tree-cfgcleanup.c:445 0x8a38b5b cleanup_tree_cfg_bb ../../src-trunk/gcc/tree-cfgcleanup.c:633 0x8a38c57 cleanup_tree_cfg_1 ../../src-trunk/gcc/tree-cfgcleanup.c:675 0x8a38d88 cleanup_tree_cfg_noloop ../../src-trunk/gcc/tree-cfgcleanup.c:731 0x8a38ea2 cleanup_tree_cfg() ../../src-trunk/gcc/tree-cfgcleanup.c:786 0x8906f96 execute_function_todo ../../src-trunk/gcc/passes.c:1702 0x8906426 do_per_function ../../src-trunk/gcc/passes.c:1476 0x89072c5 execute_todo ../../src-trunk/gcc/passes.c:1806 Please submit a full bug report,
[Bug tree-optimization/62006] Bad code generation with -O3 (possibly due to -ftree-partial-pre)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- It looks ok what PRE does (it's not really a partial partial redundancy but a full redundndancy). The bug also reproduces with -O2 -ftree-partial-pre. Disabling loop optimizations and cddce2 hides the bug. With PPRE enabled CDDCE2 removes the stores to D.46421.diff (again I see nothing wrong with doing that). Btw, this all happens in _M_range_initialize. (-fno-strict-aliasing fixes the bug as well). Note that I see stores as OffPtrBase to automatic objects: - MEM[(struct OffPtrBase *)D.46421].diff = _70; and loads from OffPtr via this: _16 = MEM[(struct OffPtr *)this_4(D)].D.43564; or remaining stores: MEM[(struct OffPtrBase *)this_4(D) + 16B].diff = iftmp.15_41; I also see: _74 = (sizetype) _47; iftmp.10_75 = D.46429.D.43564 + _74; __last.3_77 = (long int) iftmp.10_75; __first.4_78 = (long int) D.46430.D.43564; _79 = __last.3_77 - __first.4_78; which effectively subtracts two unrelated addresses of automatic objects (b - undefined behavior!) I think the testcase is simply bogus. Can you explain what the fancy pointers do? Disabling points-to analysis also fixes the testcase. Note that with points-to analysis you cannot reach any other object with offsetting the address of an object.
[Bug rtl-optimization/61672] Less redundant instructions deleted by pre_delete after r208113.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61672 --- Comment #3 from Yuri Rumyantsev ysrumyan at gmail dot com --- Created attachment 33235 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33235action=edit file to reproduce Need to be compiled with -m32 -O3 -Wframe-larger-than=1728 -std=gnu++11 -fpic options.
[Bug tree-optimization/62006] Bad code generation with -O3 (possibly due to -ftree-partial-pre)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006 --- Comment #4 from Thomas Köppe tkoeppe at google dot com --- Ah, you're right, this offset pointer computation as it stands is undefined behaviour. The intended use is to use those pointers only within a preallocated arena, so that the pointers would indeed live in a common object (a large array). I shall change the allocator to an arena allocator and rerun the test. The intended use for offset pointers is to inter-process communication; a vector with the fancy-pointer allocator can be used from two separate processes.
[Bug rtl-optimization/61672] Less redundant instructions deleted by pre_delete after r208113.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61672 --- Comment #4 from Yuri Rumyantsev ysrumyan at gmail dot com --- Richard, I put into attachment original file. For compiler built 20140208 and 20140730 I've got: grep -c redundant test.cc.179r.pre (20140208) 3825 grep -c redundant test.182r.pre (20140730) 314. Note also that the following warning is emitted: art/runtime/interpreter/interpreter_goto_table_impl.cc:2436:1: warning: the frame size of 3408 bytes is larger than 1728 bytes [-Wframe-larger-than=]
[Bug tree-optimization/62006] Bad code generation with -O3 (possibly due to -ftree-partial-pre)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Btw, points-to handles this conservatively, so -fno-tree-pta isn't a real fix either. We didn't yet spot the real bogus transform. But indeed makes sure you are computing differences within one arena only.
[Bug rtl-optimization/61672] Less redundant instructions deleted by pre_delete after r208113.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61672 --- Comment #5 from Yuri Rumyantsev ysrumyan at gmail dot com --- Richard, I put the original file into 61672 attachment and add comments for reproducing. 2014-08-04 15:16 GMT+04:00 rguenth at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61672 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- This only changes the way we represent mem_attrs. It seems to me that eventually mem_attr comparison doesn't work as expected? Note sure where PRE looks at the stmts - LCM looks like bitmap stuff only, I only see canon_true_dependence calls that may make a difference. Also please specify the target you used to reproduce this. -- You are receiving this mail because: You reported the bug.
[Bug fortran/62007] default(none) conflicts with iteration variable in openmp parallel loop simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62007
Harald Anlauf anlauf at gmx dot de changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #5 from Harald Anlauf anlauf at gmx dot de ---
(In reply to Alexander Grund from comment #4)
I attached 2 testcases. Both are the same files but with different file
endings. The .f works, the .F90 doesn't (it shows the reported behavior)
compile both with gfortran -fopenmp {file}
The reason you get no error with the .f file is that it is
a Fortran fixed format source file.
If you add -ffree-form to the gfortran options, you get the
same error.
I think the problem is that the simd directive belongs to
OpenMP 4.0 and your gfortran supports only 3.1.
You'll have to wait until OpenMP 4 is supported by gfortran.
[Bug testsuite/20003] libmudflap.cth timeouts too short
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20003 Frank Ch. Eigler fche at redhat dot com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |WONTFIX --- Comment #7 from Frank Ch. Eigler fche at redhat dot com --- mudflap has been retired
[Bug web/45782] When updating a bug, an error can be thrown if an email cannot be sent to a recipient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45782 Frank Ch. Eigler fche at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #4 from Frank Ch. Eigler fche at redhat dot com --- problem appears to have been corrected
[Bug fortran/62007] default(none) conflicts with iteration variable in openmp parallel loop simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62007 --- Comment #6 from Alexander Grund alexander.grund at mailbox dot tu-dresden.de --- gfortran 4.9.1 supports OpenMP 4.0 Removing the default(none) clause removes the error message, so it certainly IS supported. Besides that: Even the error message mentiones !$OMP PARALLEL DO SIMD so it is recognized.
[Bug bootstrap/62009] Bootstrap failure in vec.h::splice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62009 jgreenhalgh at gcc dot gnu.org changed: What|Removed |Added Target|i686|i686, ||arm-none-linux-gnueabihf Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-04 CC||jgreenhalgh at gcc dot gnu.org Summary|Bootstrap failure on i686 |Bootstrap failure in ||vec.h::splice Ever confirmed|0 |1 --- Comment #1 from jgreenhalgh at gcc dot gnu.org --- I saw something very similar on ARM, but I couldn't reproduce it across two other bootstraps with the same configuration, nor did I see the ICE when trying to resume the build by typing make. .../configure --with-cpu=cortex-a9 --with-fpu=neon-fp16 --with-mode=thumb --with-float=hard --enable-languages=c,c++,fortran /work/jamgre01//gcc-src/gcc/tree-ssa-pre.c: In function ‘pre_expr_d* bitmap_find_leader(bitmap_set_t, unsigned int)’: /work/jamgre01//gcc-src/gcc/tree-ssa-pre.c:1837:1: internal compiler error: in splice, at vec.h:844 bitmap_find_leader (bitmap_set_t set, unsigned int val) ^ 0xaa2927 vec_edge_var_map, va_heap, vl_embed::splice(vec_edge_var_map, va_heap, vl_embed) /work/jamgre01//gcc-src/gcc/vec.h:844 0xaa253d vec_edge_var_map, va_heap, vl_ptr::splice(vec_edge_var_map, va_heap, vl_ptr) /work/jamgre01//gcc-src/gcc/vec.h:1495 0xaa1fab vec_edge_var_map, va_heap, vl_ptr::safe_splice(vec_edge_var_map, va_heap, vl_ptr) /work/jamgre01//gcc-src/gcc/vec.h:1512 0xa9ddbb redirect_edge_var_map_dup(edge_def*, edge_def*) /work/jamgre01//gcc-src/gcc/tree-ssa.c:113 0x4d8bfd redirect_edge_succ_nodup(edge_def*, basic_block_def*) /work/jamgre01//gcc-src/gcc/cfghooks.c:437 0xa9dee5 ssa_redirect_edge(edge_def*, basic_block_def*) /work/jamgre01//gcc-src/gcc/tree-ssa.c:173 0x8fd663 gimple_try_redirect_by_replacing_jump /work/jamgre01//gcc-src/gcc/tree-cfg.c:5419 0x8fd6e7 gimple_redirect_edge_and_branch /work/jamgre01//gcc-src/gcc/tree-cfg.c:5450 0x4d89d5 redirect_edge_and_branch(edge_def*, basic_block_def*) /work/jamgre01//gcc-src/gcc/cfghooks.c:356 0x907a79 remove_forwarder_block /work/jamgre01//gcc-src/gcc/tree-cfgcleanup.c:445 0x9080a7 cleanup_tree_cfg_bb /work/jamgre01//gcc-src/gcc/tree-cfgcleanup.c:633 0x90818d cleanup_tree_cfg_1 /work/jamgre01//gcc-src/gcc/tree-cfgcleanup.c:675 0x9082cb cleanup_tree_cfg_noloop /work/jamgre01//gcc-src/gcc/tree-cfgcleanup.c:731 0x9083bd cleanup_tree_cfg() /work/jamgre01//gcc-src/gcc/tree-cfgcleanup.c:786 0x90897f execute_cleanup_cfg_post_optimizing /work/jamgre01//gcc-src/gcc/tree-cfgcleanup.c:1081 0x908b29 execute /work/jamgre01//gcc-src/gcc/tree-cfgcleanup.c:1143 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions.
[Bug tree-optimization/62006] Bad code generation with -O3 (possibly due to -ftree-partial-pre)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006 --- Comment #6 from Thomas Köppe tkoeppe at google dot com --- Created attachment 33236 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33236action=edit Fixed demo that doesn't have UB on account of invalid pointer arithmetic Here's a (very lazily) fixed version of the code that allocates from an arena that is a single, large array. The same problem persists in both GCC and Clang.
[Bug rtl-optimization/61672] Less redundant instructions deleted by pre_delete after r208113.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61672 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-08-04 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 33237 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33237action=edit patch Ok, I see stuff like the following in the 179r.pre dump differences @@ -1524,6 +1524,11 @@ Loads : (insn_list:REG_DEP_TRUE 21 (nil)) Stores : (nil) + Pattern ( 0): (mem/f:SI (plus:SI (reg/v/f:SI 93 [ pfile ]) +(const_int 12 [0xc])) [3 pfile_5(D)-u_buff+0 S4 A32]) +Loads : (insn_list:REG_DEP_TRUE 19 (nil)) + Stores : (nil) + Pattern ( 0): (mem/f:SI (plus:SI (reg/v/f:SI 83 [ buff ]) (const_int 12 [0xc])) [3 buff_6-limit+0 S4 A32]) Loads : (insn_list:REG_DEP_TRUE 9 (nil)) @@ -1536,11 +1541,11 @@ Pattern ( 0): (mem/f:SI (plus:SI (reg/v/f:SI 93 [ pfile ]) (const_int 12 [0xc])) [3 pfile_5(D)-u_buff+0 S4 A32]) -Loads : (insn_list:REG_DEP_TRUE 19 (insn_list:REG_DEP_TRUE 7 (nil))) +Loads : (insn_list:REG_DEP_TRUE 7 (nil)) Stores : (nil) Ah, gcse ends up calling exp_equiv_p which does /* Can't merge two expressions in different alias sets, since we can decide that the expression is transparent in a block when it isn't, due to it being set with the different alias set. Also, can't merge two expressions with different MEM_ATTRS. They could e.g. be two different entities allocated into the same space on the stack (see e.g. PR25130). In that case, the MEM addresses can be the same, even though the two MEMs are absolutely not equivalent. But because really all MEM attributes should be the same for equivalent MEMs, we just use the invariant that MEMs that have the same attributes share the same mem_attrs data structure. */ if (MEM_ATTRS (x) != MEM_ATTRS (y)) return 0; cfgcleanup.c has similar code. Untested fix attached, with this we create the same code for the pr58464 testcase.
[Bug rtl-optimization/61672] [4.9/4.10 Regression] Less redundant instructions deleted by pre_delete after r208113.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61672 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |4.9.2 Summary|Less redundant instructions |[4.9/4.10 Regression] Less |deleted by pre_delete after |redundant instructions |r208113.|deleted by pre_delete after ||r208113.
[Bug bootstrap/62009] Bootstrap failure in vec.h::splice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62009 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Valgrind show: ==20810== Invalid read of size 8 ==20810==at 0xBA4A6F: redirect_edge_var_map_dup(edge_def*, edge_def*) (vec.h:1184) ==20810==by 0x675552: redirect_edge_succ_nodup(edge_def*, basic_block_def*) (cfghooks.c:437) ==20810==by 0xA18098: gimple_redirect_edge_and_branch(edge_def*, basic_block_def*) (tree-cfg.c:5419) ==20810==by 0x6753C9: redirect_edge_and_branch(edge_def*, basic_block_def*) (cfghooks.c:356) ==20810==by 0x675482: remove_branch(edge_def*) (cfghooks.c:398) ==20810==by 0x67F062: remove_path(edge_def*) (cfgloopmanip.c:384) ==20810==by 0xAFE5C2: canonicalize_loop_induction_variables(loop*, bool, unroll_level, bool) (tree-ssa-loop-ivcanon.c:845) ==20810==by 0xAFEE4F: tree_unroll_loops_completely_1(bool, bool, vecloop*, va_heap, vl_ptr, loop*) (tree-ssa-loop-ivcanon.c:1149) ==20810==by 0xAFEDD0: tree_unroll_loops_completely_1(bool, bool, vecloop*, va_heap, vl_ptr, loop*) (tree-ssa-loop-ivcanon.c:1123) ==20810==by 0xAFF802: tree_unroll_loops_completely(bool, bool) (tree-ssa-loop-ivcanon.c:1193) ==20810==by 0x92D88C: execute_one_pass(opt_pass*) (passes.c:2149) ==20810==by 0x92DE15: execute_pass_list_1(opt_pass*) (passes.c:2201) ==20810== Address 0x55a5f08 is 152 bytes inside a block of size 208 free'd ==20810==at 0x40298D0: free (vg_replace_malloc.c:468) ==20810==by 0xBA52ED: hash_tablehash_mapedge_def*, auto_vec_edge_var_map, 0ul, default_hashmap_traits::hash_entry, xcallocator, true::find_slot_with_hash(edge_def* const, unsigned int, insert_option) (hash-table.h:1370) ==20810==by 0xBA4A61: redirect_edge_var_map_dup(edge_def*, edge_def*) (hash-map.h:177) ==20810==by 0x675552: redirect_edge_succ_nodup(edge_def*, basic_block_def*) (cfghooks.c:437) ==20810==by 0xA18098: gimple_redirect_edge_and_branch(edge_def*, basic_block_def*) (tree-cfg.c:5419) ==20810==by 0x6753C9: redirect_edge_and_branch(edge_def*, basic_block_def*) (cfghooks.c:356) ==20810==by 0x675482: remove_branch(edge_def*) (cfghooks.c:398) ==20810==by 0x67F062: remove_path(edge_def*) (cfgloopmanip.c:384) ==20810==by 0xAFE5C2: canonicalize_loop_induction_variables(loop*, bool, unroll_level, bool) (tree-ssa-loop-ivcanon.c:845) ==20810==by 0xAFEE4F: tree_unroll_loops_completely_1(bool, bool, vecloop*, va_heap, vl_ptr, loop*) (tree-ssa-loop-ivcanon.c:1149) ==20810==by 0xAFEDD0: tree_unroll_loops_completely_1(bool, bool, vecloop*, va_heap, vl_ptr, loop*) (tree-ssa-loop-ivcanon.c:1123) ==20810==by 0xAFF802: tree_unroll_loops_completely(bool, bool) (tree-ssa-loop-ivcanon.c:1193) ==20810== ==20810== Conditional jump or move depends on uninitialised value(s) ==20810==at 0xECD18A: register_active_defs(df_ref_d*) (sparseset.h:147) ==20810==by 0xECD23E: update_df_init(rtx_def*, rtx_def*) (fwprop.c:878) ==20810==by 0xECD564: try_fwprop_subst(df_ref_d*, rtx_def**, rtx_def*, rtx_def*, bool) (fwprop.c:945) ==20810==by 0xECDA5A: forward_propagate_into(df_ref_d*) (fwprop.c:1320) ==20810==by 0xECDFE7: (anonymous namespace)::pass_rtl_fwprop::execute(function*) (fwprop.c:1457) ==20810==by 0x92D88C: execute_one_pass(opt_pass*) (passes.c:2149) ==20810==by 0x92DE15: execute_pass_list_1(opt_pass*) (passes.c:2201) ==20810==by 0x92DE27: execute_pass_list_1(opt_pass*) (passes.c:2202) ==20810==by 0x92DE68: execute_pass_list(function*, opt_pass*) (passes.c:2212) ==20810==by 0x6997AF: expand_function(cgraph_node*) (cgraphunit.c:1776) ==20810==by 0x69ADD3: compile() (cgraphunit.c:1910) ==20810==by 0x69C874: finalize_compilation_unit() (cgraphunit.c:2331) ==20810== Uninitialised value was created by a heap allocation ==20810==at 0x4028510: malloc (vg_replace_malloc.c:291) ==20810==by 0xFC8D27: xmalloc (xmalloc.c:147) ==20810==by 0x9CE0A4: sparseset_alloc(unsigned long) (sparseset.c:33) ==20810==by 0xECCA82: fwprop_init() (fwprop.c:1401) ==20810==by 0xECDF5A: (anonymous namespace)::pass_rtl_fwprop::execute(function*) (fwprop.c:1441) ==20810==by 0x92D88C: execute_one_pass(opt_pass*) (passes.c:2149) ==20810==by 0x92DE15: execute_pass_list_1(opt_pass*) (passes.c:2201) ==20810==by 0x92DE27: execute_pass_list_1(opt_pass*) (passes.c:2202) ==20810==by 0x92DE68: execute_pass_list(function*, opt_pass*) (passes.c:2212) ==20810==by 0x6997AF: expand_function(cgraph_node*) (cgraphunit.c:1776) ==20810==by 0x69ADD3: compile() (cgraphunit.c:1910) ==20810==by 0x69C874: finalize_compilation_unit() (cgraphunit.c:2331)
[Bug tree-optimization/62006] Bad code generation with -O3 (possibly due to -ftree-partial-pre)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Smells like a duplicate of PR49330 - still always returning 1 from base_alias_check doesn't fix the original testcase. Which also fails with -O -ftree-pre -ftree-partial-pre -fstrict-aliasing btw.
[Bug tree-optimization/62006] Bad code generation with -O3 (possibly due to -ftree-partial-pre)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- The fixed demog works for me (GCC 4.9 and 4.8 at least).
[Bug fortran/62010] New: OpenMP simd produces wrong results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62010 Bug ID: 62010 Summary: OpenMP simd produces wrong results Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: alexander.grund at mailbox dot tu-dresden.de Created attachment 33238 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33238action=edit Testcase 1 Using the OpenMP 4.0 SIMD construct results in wrong calculation results in some cases. (See testcase 1) To reproduce: simply run: gfortran-4.9 gfortranBug.f ./a.out gfortran-4.9 gfortranBug.f -fopenmp ./a.out Output: size 12 36.016765295885790 size 12 35.454228116260587 Expected: Same for both cases.
[Bug target/61948] [ARM] [4.10 regression] ICE with DImode shift by 1 bit (in copyprop_hardreg_forward_1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61948 cbaylis at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from cbaylis at gcc dot gnu.org --- Fixed in r213376 Mailing list thread: https://gcc.gnu.org/ml/gcc-patches/2014-07/msg02009.html
[Bug tree-optimization/62006] Bad code generation with -O3 (possibly due to -ftree-partial-pre)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006 --- Comment #9 from Thomas Köppe tkoeppe at google dot com --- Argh, yes, I compiled the wrong file... indeed, the arena version works with GCC 4.8.2 for me, too, and in Clang as well. So... not an issue, I suppose? The desired real application will be for containers allocated in shared memory, which is presumably obtained from some opaque system feature.
[Bug fortran/62010] OpenMP simd produces wrong results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62010 --- Comment #1 from Alexander Grund alexander.grund at mailbox dot tu-dresden.de --- Created attachment 33239 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33239action=edit Testcase 2
[Bug fortran/62010] OpenMP simd produces wrong results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62010 --- Comment #2 from Alexander Grund alexander.grund at mailbox dot tu-dresden.de --- Related to this: In some cases OpenMP simd crashes while that crash is fixed by removing an unrelated piece of code. See Testcase 2. Run with: gfortran-4.9 gfortranBug.f -cpp ./a.out gfortran-4.9 gfortranBug.f -cpp -fopenmp ./a.out Output: size 12 x 10 x 5 -29032800293.326649 size 12 x 10 x 5 3554.004000376 Expected: Same output And to crash run with: gfortran-4.9 gfortranBug.f -cpp -D CRASH ./a.out gfortran-4.9 gfortranBug.f -cpp -D CRASH -fopenmp ./a.out Output: size 12 x 10 x 5 3840.3482323232652 size 12 x 10 x 5 Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
[Bug target/61948] [ARM] [4.10 regression] ICE with DImode shift by 1 bit (in copyprop_hardreg_forward_1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61948 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.10.0
[Bug tree-optimization/62006] Bad code generation with -O3 (possibly due to -ftree-partial-pre)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006 --- Comment #10 from rguenther at suse dot de rguenther at suse dot de --- On Mon, 4 Aug 2014, tkoeppe at google dot com wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006 --- Comment #9 from Thomas Köppe tkoeppe at google dot com --- Argh, yes, I compiled the wrong file... indeed, the arena version works with GCC 4.8.2 for me, too, and in Clang as well. So... not an issue, I suppose? I think the issue only triggers when you end up using automatic variables for the difference computation.
[Bug tree-optimization/62006] Bad code generation with -O3 (possibly due to -ftree-partial-pre)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006 --- Comment #11 from Thomas Köppe tkoeppe at google dot com --- Created attachment 33240 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33240action=edit Further fixing: Uses uintptr_ts for the difference On Jonathan's suggestion I changed the distance computation to go through a uintptr_t conversion. Jonathan suggested compiling with -fno-elide-constructors, and indeed the attached code breaks when that option is passed. As you said, the UB caused by the distance computations of automatic objects seems to be the stumbling point.
[Bug rtl-optimization/61672] [4.9/4.10 Regression] Less redundant instructions deleted by pre_delete after r208113.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61672 --- Comment #7 from Yuri Rumyantsev ysrumyan at gmail dot com --- It really fixes the issue. Thanks.
[Bug rtl-optimization/62011] New: False Data Dependency in popcnt instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62011 Bug ID: 62011 Summary: False Data Dependency in popcnt instruction Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: debiandev at gmail dot com On Sandy/Ivy Bridge and Haswell processors, the instruction: popcnt src, dest appears to have a false dependency on the destination register dest. Even though the instruction only writes to it, the instruction will wait until dest is ready before executing. This causes a loss in performance as explained here: http://stackoverflow.com/questions/25078285/replacing-a-32-bit-loop-count-variable-with-64-bit-introduces-crazy-performance
[Bug tree-optimization/62012] New: Loop is not vectorized after function inlining (SCEV)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62012 Bug ID: 62012 Summary: Loop is not vectorized after function inlining (SCEV) Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ysrumyan at gmail dot com We noticed that for one important benchmark using '-lto' options leads to performance degradation which is caused by not-vectorizing the hottest loop after function inlining. I can able to reproduce this deficiency using simple test-case: if we passed class by reference to function (it need to be compiled with -DPARAM macros) loop is vectorized: g++ -Ofast -m64 -march=core-avx2 -c test.cpp -fdump-tree-vect-details -fopenmp -DPARAM; grep 'note: vectorized' test.cpp.114t.vect test.cpp:45:1: note: vectorized 1 loops in function. But if we compile it without macros we get: g++ -Ofast -m64 -march=core-avx2 -c test.cpp -fdump-tree-vect-details -fopenmp; grep 'note: vectorized' test.cpp.114t.vect test.cpp:45:1: note: vectorized 0 loops in function. It looks like SCEV issue.
[Bug tree-optimization/62012] Loop is not vectorized after function inlining (SCEV)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62012 --- Comment #1 from Yuri Rumyantsev ysrumyan at gmail dot com --- Created attachment 33241 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33241action=edit test-case to reproduce Options to compile are: -Ofast -m64 -march=core-avx2 -fopenmp and macros -DPARAM can be used to get vectorizable version of test.
[Bug rtl-optimization/62004] dead type-unsafe load replaces type-safe load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62004 --- Comment #2 from vries at gcc dot gnu.org --- Created attachment 33242 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33242action=edit patch to fix if-conversion (In reply to Richard Biener from comment #1) Heh, interesting set of events ;) Now it is interesting how much we desire to perform the tail-merging - we _could_ change the alias sets of loads (and stores...) to a common one (either if they are equal or just zero otherwise). Depends on how much we like this kind of pessimization. Same for the RTL bits of course. Btw, I still see the conditional execution after RTL expansion, just cfglayout mode doesn't have unconditonal gotos for the edges. Right, when doing fdump-rtl-all, it looks like fallthrough, but it isn't, I forgot. So it's just if-conversion that does the wrong thing. Attached patch fixes 4.8 if-conversion in a conservative way (I suppose we want a conservative fix for 4.8 and 4.9). OK for testing?
[Bug target/62013] New: [4.8/4.9 Regresion] cc1plus doesn't terminate when called with -g on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62013 Bug ID: 62013 Summary: [4.8/4.9 Regresion] cc1plus doesn't terminate when called with -g on arm-linux-gnueabihf Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Created attachment 33243 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33243action=edit test case seen on the 4.8 and 4.9 branch, cc1plus doesn't terminate. omitting the -g lets the command succeed. $ g++ -v -std=c++0x -c -g -O2 qmltextgenerator.cpp Program received signal SIGINT, Interrupt. 0x0054920c in canonicalize_values_star(variable_def**, dataflow_set_def*) () (gdb) bt #0 0x0054920c in canonicalize_values_star(variable_def**, dataflow_set_def*) () #1 0x0054b0c2 in ?? () #2 0x0054ca08 in ?? () #3 0x0054d8ba in ?? () #4 0x0039928a in execute_one_pass(opt_pass*) () #5 0x00399448 in execute_pass_list(opt_pass*) () #6 0x00399452 in execute_pass_list(opt_pass*) () #7 0x00399452 in execute_pass_list(opt_pass*) () #8 0x00244a8c in ?? () #9 0x00245ca4 in compile() () #10 0x00246030 in finalize_compilation_unit() () #11 0x00158fc4 in cp_write_global_declarations() () #12 0x00409394 in ?? () #13 0x0040aad0 in toplev_main(int, char**) () #14 0xb6d4f630 in __libc_start_main (main=0x111e19 main, argc=26, argv=0xbefff604, init=optimized out, fini=0x7b2af5 __libc_csu_fini, rtld_fini=0xb6fe24e5 _dl_fini, stack_end=0xbefff604) at libc-start.c:287 #15 0x00112058 in _start () defaults are -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb
[Bug target/62013] [4.8/4.9 Regresion] cc1plus doesn't terminate when called with -g on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62013 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktkachov at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from ktkachov at gcc dot gnu.org --- I'm willing to bet this is a duplicate of 61033 that also involves a qmltextgenerator.ii preprocessed reproducer file ;) It goes into an infinite loop for me on arm-none-eabi with 4.9 and passes with current trunk. Didn't try 4.8, I expect it fails there like you say. I don't remember if it was fixed in trunk and the fix not backported or just made latent. *** This bug has been marked as a duplicate of bug 61033 ***
[Bug debug/61033] Infinite loop in variable tracking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61033 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||doko at gcc dot gnu.org --- Comment #3 from ktkachov at gcc dot gnu.org --- *** Bug 62013 has been marked as a duplicate of this bug. ***
[Bug debug/61033] Infinite loop in variable tracking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61033 ktkachov at gcc dot gnu.org changed: What|Removed |Added Keywords||compile-time-hog Target|arm-linux-gnueabi |arm-linux-gnueabi, ||arm-none-eabi Known to work||4.10.0, 4.7.4 Known to fail||4.8.3, 4.9.1 --- Comment #4 from ktkachov at gcc dot gnu.org --- Filling in some fields, this still fails on the 4.8 and 4.9 branches but works on trunk.
[Bug middle-end/60102] [4.9/4.10 Regression] powerpc fp-bit ices at dwf_regno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60102 --- Comment #16 from edmarwjr at gcc dot gnu.org --- Author: edmarwjr Date: Mon Aug 4 16:34:34 2014 New Revision: 213596 URL: https://gcc.gnu.org/viewcvs?rev=213596root=gccview=rev Log: PR target/60102 [libgcc] 2014-07-31 Rohit rohitarul...@freescale.com * config/rs6000/linux-unwind.h (ppc_fallback_frame_state): Update based on change in SPE high register numbers and 3 HTM registers. [gcc] 2014-07-31 Rohit rohitarul...@freescale.com * config/rs6000/rs6000.c (rs6000_reg_names) : Add SPE high register names. (alt_reg_names) : Likewise. (rs6000_dwarf_register_span) : For SPE high registers, replace dwarf register numbers with GCC hard register numbers. (rs6000_init_dwarf_reg_sizes_extra) : Likewise. (rs6000_dbx_register_number): For SPE high registers, return dwarf register number for the corresponding GCC hard register number. * config/rs6000/rs6000.h (FIRST_PSEUDO_REGISTER) : Update based on 32 newly added GCC hard register numbers for SPE high registers. (DWARF_FRAME_REGISTERS) : Likewise. (DWARF_REG_TO_UNWIND_COLUMN) : Likewise. (DWARF_FRAME_REGNUM) : Likewise. (FIXED_REGISTERS) : Likewise. (CALL_USED_REGISTERS) : Likewise. (CALL_REALLY_USED_REGISTERS) : Likewise. (REG_ALLOC_ORDER) : Likewise. (enum reg_class) : Likewise. (REG_CLASS_NAMES) : Likewise. (REG_CLASS_CONTENTS) : Likewise. (SPE_HIGH_REGNO_P) : New macro to identify SPE high registers. * gcc.target/powerpc/pr60102.c: New testcase. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/rs6000.h trunk/gcc/config/rs6000/rs6000.md trunk/libgcc/ChangeLog trunk/libgcc/config/rs6000/linux-unwind.h
[Bug fortran/62010] OpenMP simd produces wrong results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62010 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- The testcases look invalid to me. If you make j1 private, then it is uninitialized in the loop, so if the program doesn't crash, it is by pure luck. The other variables listed in private clause are not used in the simd loop at all, so it doesn't make any sense to list them there. So, just remove all private clauses and you should be fine.
[Bug fortran/62010] OpenMP simd produces wrong results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62010 Alexander Grund alexander.grund at mailbox dot tu-dresden.de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Alexander Grund alexander.grund at mailbox dot tu-dresden.de --- You are right. It seems i missed that when I changed the code the last time and forgot that it is private and not firstprivate. Without that it works. Thanks for that!
[Bug middle-end/60102] [4.9/4.10 Regression] powerpc fp-bit ices at dwf_regno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60102 --- Comment #17 from edmarwjr at gcc dot gnu.org --- Author: edmarwjr Date: Mon Aug 4 16:48:53 2014 New Revision: 213597 URL: https://gcc.gnu.org/viewcvs?rev=213597root=gccview=rev Log: PR target/60102 [libgcc] 2014-08-04 Rohit rohitarul...@freescale.com * config/rs6000/linux-unwind.h (ppc_fallback_frame_state): Update based on change in SPE high register numbers and 3 HTM registers. [gcc] 2014-08-04 Rohit rohitarul...@freescale.com * config/rs6000/rs6000.c (rs6000_reg_names) : Add SPE high register names. (alt_reg_names) : Likewise. (rs6000_dwarf_register_span) : For SPE high registers, replace dwarf register numbers with GCC hard register numbers. (rs6000_init_dwarf_reg_sizes_extra) : Likewise. (rs6000_dbx_register_number): For SPE high registers, return dwarf register number for the corresponding GCC hard register number. * config/rs6000/rs6000.h (FIRST_PSEUDO_REGISTER) : Update based on 32 newly added GCC hard register numbers for SPE high registers. (DWARF_FRAME_REGISTERS) : Likewise. (DWARF_REG_TO_UNWIND_COLUMN) : Likewise. (DWARF_FRAME_REGNUM) : Likewise. (FIXED_REGISTERS) : Likewise. (CALL_USED_REGISTERS) : Likewise. (CALL_REALLY_USED_REGISTERS) : Likewise. (REG_ALLOC_ORDER) : Likewise. (enum reg_class) : Likewise. (REG_CLASS_NAMES) : Likewise. (REG_CLASS_CONTENTS) : Likewise. (SPE_HIGH_REGNO_P) : New macro to identify SPE high registers. [gcc/testsuite] 2014-08-04 Rohit rohitarul...@freescale.com * gcc.target/powerpc/pr60102.c: New testcase. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/powerpc/pr60102.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/rs6000/rs6000.c branches/gcc-4_9-branch/gcc/config/rs6000/rs6000.h branches/gcc-4_9-branch/gcc/config/rs6000/rs6000.md branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/libgcc/ChangeLog branches/gcc-4_9-branch/libgcc/config/rs6000/linux-unwind.h
[Bug middle-end/60102] [4.9/4.10 Regression] powerpc fp-bit ices at dwf_regno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60102 --- Comment #18 from edmarwjr at gcc dot gnu.org --- Author: edmarwjr Date: Mon Aug 4 16:55:07 2014 New Revision: 213598 URL: https://gcc.gnu.org/viewcvs?rev=213598root=gccview=rev Log: [gcc/testsuite] 2014-08-04 Rohit rohitarul...@freescale.com PR target/60102 * gcc.target/powerpc/pr60102.c: New testcase. Added: trunk/gcc/testsuite/gcc.target/powerpc/pr60102.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug debug/61033] [4.8/4.9 Regression] Infinite loop in variable tracking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61033 cbaylis at gcc dot gnu.org changed: What|Removed |Added CC||cbaylis at gcc dot gnu.org --- Comment #5 from cbaylis at gcc dot gnu.org --- Created attachment 33244 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33244action=edit Reduced test case $ arm-unknown-linux-gnueabihf-gcc -S -O2 -g reduced1.cpp
[Bug debug/61033] [4.8/4.9 Regression] Infinite loop in variable tracking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61033 --- Comment #6 from cbaylis at gcc dot gnu.org --- git bisect points to r211625 as the revision which fixes/hides this bug on trunk. 2014-06-13 Richard Biener rguent...@suse.de * tree-ssa-pre.c (eliminate_dom_walker::before_dom_children): Rewrite to propagate the VN result into all uses where possible and to remove stmts becoming dead because of that. (eliminate): Generalize stmt removal handling, remove in reverse dominator order to support proper debug stmt generation. Update stmts before removing stmts. * tree-ssa-propagate.c (propagate_tree_value): Remove bogus assert.
[Bug bootstrap/62005] [4.10 regression] with --enable-checking=rtl : loop-unroll.c:2095:10: error: function may return address of local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62005 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- I've posted a loop-unroll.c fix. That said, an interesting question is why we don't warn about this without rtl checking, the function still returns address of the parameter. Is that because it is inlined in that case and so we don't warn then?
[Bug libstdc++/61374] string_view::operator string() is buggy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61374 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Mon Aug 4 18:50:14 2014 New Revision: 213601 URL: https://gcc.gnu.org/viewcvs?rev=213601root=gccview=rev Log: Backported from mainline 2014-06-01 Jonathan Wakely jwak...@redhat.com PR libstdc++/61374 * include/experimental/string_view (operator basic_string): Correct order of arguments. (to_string): Replace with member function. Add inline specifiers. Remove unused header. Remove _S_empty_rep and allow _M_str to be null. * testsuite/experimental/string_view/cons/char/1.cc: Adjust to new default constructor semantics. * testsuite/experimental/string_view/cons/wchar_t/1.cc: Likewise. * testsuite/experimental/string_view/operations/copy/char/1.cc: Fix copyright dates. Remove unused header. * testsuite/experimental/string_view/operations/copy/wchar_t/1.cc: Likewise. * testsuite/experimental/string_view/operations/data/char/1.cc: Fix copyright dates. Adjust to new default constructor semantics. * testsuite/experimental/string_view/operations/data/wchar_t/1.cc: Likewise. * testsuite/experimental/string_view/operations/to_string/1.cc: New. Added: branches/gcc-4_9-branch/libstdc++-v3/testsuite/experimental/string_view/operations/to_string/ branches/gcc-4_9-branch/libstdc++-v3/testsuite/experimental/string_view/operations/to_string/1.cc - copied, changed from r213600, branches/gcc-4_9-branch/libstdc++-v3/testsuite/experimental/string_view/operations/copy/char/1.cc Modified: branches/gcc-4_9-branch/libstdc++-v3/ChangeLog branches/gcc-4_9-branch/libstdc++-v3/include/experimental/string_view branches/gcc-4_9-branch/libstdc++-v3/include/experimental/string_view.tcc branches/gcc-4_9-branch/libstdc++-v3/testsuite/experimental/string_view/cons/char/1.cc branches/gcc-4_9-branch/libstdc++-v3/testsuite/experimental/string_view/cons/wchar_t/1.cc branches/gcc-4_9-branch/libstdc++-v3/testsuite/experimental/string_view/operations/copy/char/1.cc branches/gcc-4_9-branch/libstdc++-v3/testsuite/experimental/string_view/operations/copy/wchar_t/1.cc branches/gcc-4_9-branch/libstdc++-v3/testsuite/experimental/string_view/operations/data/char/1.cc branches/gcc-4_9-branch/libstdc++-v3/testsuite/experimental/string_view/operations/data/wchar_t/1.cc
[Bug libstdc++/58962] Pretty printers use obsolete Python syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58962 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Mon Aug 4 18:50:30 2014 New Revision: 213604 URL: https://gcc.gnu.org/viewcvs?rev=213604root=gccview=rev Log: 2014-08-04 Samuel Bronson naes...@gmail.com Backport r212453 from trunk 2014-07-11 Samuel Bronson naes...@gmail.com Matthias Klose d...@ubuntu.com PR libstdc++/58962 * python/libstdcxx/v6/printers.py: Port to Python 2+3 (imap): New compat function. (izip): Likewise. (Iterator): New mixin to allow writing iterators in Python 3 style regardless of which version we're running on. [Python3] (long) New compat alias for int. * testsuite/lib/gdb-test.exp: Port to Python 2+3 (print syntax) Backport r210625 from trunk 2014-05-19 Jonathan Wakely jwak...@redhat.com * python/libstdcxx/v6/printers.py: Use Python3 raise syntax. Modified: branches/gcc-4_9-branch/libstdc++-v3/ChangeLog branches/gcc-4_9-branch/libstdc++-v3/python/libstdcxx/v6/printers.py branches/gcc-4_9-branch/libstdc++-v3/testsuite/lib/gdb-test.exp
[Bug libstdc++/61390] error in nested template parameter in ext/pb_ds header file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61390 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Mon Aug 4 18:50:25 2014 New Revision: 213603 URL: https://gcc.gnu.org/viewcvs?rev=213603root=gccview=rev Log: Backported from mainline 2014-06-10 Jonathan Wakely jwak...@redhat.com PR libstdc++/61390 * include/ext/pb_ds/detail/bin_search_tree_/traits.hpp (bin_search_tree_traits): Do not redeclare template-parameters. * testsuite/util/testsuite_iterators.h (test_container): Likewise. Modified: branches/gcc-4_9-branch/libstdc++-v3/ChangeLog branches/gcc-4_9-branch/libstdc++-v3/include/ext/pb_ds/detail/bin_search_tree_/traits.hpp branches/gcc-4_9-branch/libstdc++-v3/testsuite/util/testsuite_iterators.h
[Bug libstdc++/61374] string_view::operator string() is buggy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61374 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- fixed for 4.9.2
[Bug bootstrap/62005] [4.10 regression] with --enable-checking=rtl : loop-unroll.c:2095:10: error: function may return address of local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62005 --- Comment #4 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #3) That said, an interesting question is why we don't warn about this without rtl checking, the function still returns address of the parameter. Is that because it is inlined in that case and so we don't warn then? That seems likely, RTL checking may make the function large enough not to be inlined. Compiling without RTL checking but with -fkeep-inline-functions probably warns as well then.
[Bug debug/61033] [4.8/4.9 Regression] Infinite loop in variable tracking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61033 --- Comment #7 from Michael Collison michael.collison at linaro dot org --- Charlie, I still feel that the var tracking pass should be able to protect itself from an infinite loop. On 8/4/2014 11:43 AM, cbaylis at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61033 --- Comment #6 from cbaylis at gcc dot gnu.org --- git bisect points to r211625 as the revision which fixes/hides this bug on trunk. 2014-06-13 Richard Biener rguent...@suse.de * tree-ssa-pre.c (eliminate_dom_walker::before_dom_children): Rewrite to propagate the VN result into all uses where possible and to remove stmts becoming dead because of that. (eliminate): Generalize stmt removal handling, remove in reverse dominator order to support proper debug stmt generation. Update stmts before removing stmts. * tree-ssa-propagate.c (propagate_tree_value): Remove bogus assert.
[Bug libstdc++/61390] error in nested template parameter in ext/pb_ds header file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61390 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.2 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- fixed for 4.9.2
[Bug libstdc++/58962] Pretty printers use obsolete Python syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58962 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.10.0 |4.9.2 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org --- backported for 4.9.2
[Bug c++/49718] please allow no_instrument_function attribute in class member definition/declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49718 bradley_small at hotmail dot com changed: What|Removed |Added CC||bradley_small at hotmail dot com --- Comment #5 from bradley_small at hotmail dot com --- This behavior still appears in version 4.8 g++-4.8 (Debian 4.8.3-6) 4.8.3
[Bug c++/49718] please allow no_instrument_function attribute in class member definition/declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49718 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to bradley_small from comment #5) This behavior still appears in version 4.8 g++-4.8 (Debian 4.8.3-6) 4.8.3 To be expected, it was only fixed in January, prior to the GCC 4.9.0 release.
[Bug bootstrap/62005] [4.10 regression] with --enable-checking=rtl : loop-unroll.c:2095:10: error: function may return address of local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62005 --- Comment #5 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Marc Glisse from comment #4) Compiling without RTL checking but with -fkeep-inline-functions probably warns as well then. Uh, for some reason -fkeep-inline-functions does not preserve static functions, but it does preserve static inline functions (so it warns if I add inline on the definition of get_ivts_expr). I couldn't find a -fkeep-static-functions.
[Bug target/62014] New: [AArch64] Using -mgeneral-regs-only may lead to ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62014 Bug ID: 62014 Summary: [AArch64] Using -mgeneral-regs-only may lead to ICE Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: e.menezes at samsung dot com Created attachment 33245 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33245action=edit This patch should fix this issue, though it needs a test-case. In some cases, when the LRA spills a register into an FP register, with the option -mgeneral-regs-only specified, there is an ICE. It seems to be caused by the LRA assuming that the FP registers are always available and not being told when they aren't by the target.
[Bug target/62014] [AArch64] Using -mgeneral-regs-only may lead to ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62014 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- + /* Do not spill into FP registers when -mgeneral-regs-only is specified. * You are missing a / in your comment.
[Bug target/62014] [AArch64] Using -mgeneral-regs-only may lead to ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62014 --- Comment #2 from Evandro Menezes e.menezes at samsung dot com --- (In reply to Andrew Pinski from comment #1) + /* Do not spill into FP registers when -mgeneral-regs-only is specified. * You are missing a / in your comment. Ermahgerd!
[Bug target/62014] [AArch64] Using -mgeneral-regs-only may lead to ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62014 Evandro Menezes e.menezes at samsung dot com changed: What|Removed |Added Attachment #33245|0 |1 is obsolete|| --- Comment #3 from Evandro Menezes e.menezes at samsung dot com --- Created attachment 33246 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33246action=edit This patch should fix this issue, though it needs a test-case
[Bug libstdc++/61946] [4.8/4.9/4.10 Regression] rope construction, passing allocator referenct without const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61946 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Mon Aug 4 22:16:44 2014 New Revision: 213611 URL: https://gcc.gnu.org/viewcvs?rev=213611root=gccview=rev Log: Backported from mainline 2014-07-29 Jonathan Wakely jwak...@redhat.com PR libstdc++/61946 * include/ext/rope (rope::rope(char_producer_CharT*, size_t, bool, const allocator_type)): Pass non-const allocator to _S_new_RopeFunction. * testsuite/ext/rope/61946.cc: New. Added: branches/gcc-4_8-branch/libstdc++-v3/testsuite/ext/rope/61946.cc Modified: branches/gcc-4_8-branch/libstdc++-v3/ChangeLog branches/gcc-4_8-branch/libstdc++-v3/include/ext/rope
[Bug libstdc++/61946] [4.8/4.9/4.10 Regression] rope construction, passing allocator referenct without const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61946 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Mon Aug 4 22:31:51 2014 New Revision: 213612 URL: https://gcc.gnu.org/viewcvs?rev=213612root=gccview=rev Log: Backported from mainline 2014-07-29 Jonathan Wakely jwak...@redhat.com PR libstdc++/61946 * include/ext/rope (rope::rope(char_producer_CharT*, size_t, bool, const allocator_type)): Pass non-const allocator to _S_new_RopeFunction. * testsuite/ext/rope/61946.cc: New. Added: branches/gcc-4_9-branch/libstdc++-v3/testsuite/ext/rope/61946.cc Modified: branches/gcc-4_9-branch/libstdc++-v3/ChangeLog branches/gcc-4_9-branch/libstdc++-v3/include/ext/rope
[Bug libstdc++/61946] [4.8/4.9/4.10 Regression] rope construction, passing allocator referenct without const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61946 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.8.4 Known to fail||4.3.0, 4.8.3, 4.9.1 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- fixed for 4.8.4
[Bug ipa/62015] New: ipa-cp-clone uses a clone that is too specialized for the call context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62015
Bug ID: 62015
Summary: ipa-cp-clone uses a clone that is too specialized for
the call context
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: oremanj at mit dot edu
In the C++ program below, interprocedural constant propagation cloning creates
a clone of A::adjust() specialized for adjust(Side::Invalid, false). This clone
is then used for an adjust(side, false) call when there is no way to prove side
== Side::Invalid. This bug is present in gcc 4.8.2, is not present in 4.7.3,
and is still present in a version compiled from today's SVN. Using an
optimization level less than -O3 or passing -fno-ipa-cp-clone prevents the bug
from manifesting. The onset of the bug was bisected to commit r193410.
$ cat t.cc
extern C int printf(const char *fmt, ...);
struct Side {
enum _Value { Left, Right, Invalid };
constexpr Side() : _value(Invalid) {}
constexpr Side(_Value value) : _value(value) {}
operator _Value() const { return (_Value)_value; }
private:
char _value;
};
struct A {
void init();
void adjust(Side side, bool final);
void move(Side side);
};
void A::init()
{
adjust(Side::Invalid, false);
}
__attribute__((noinline))
void A::adjust(Side side, bool final)
{
printf(adjust: side is %d, final %d\n, (int)side, final);
}
void A::move(Side side)
{
printf(move: side is %d\n, (int)side);
adjust(side, false);
adjust(side, true);
}
int main()
{
A t;
t.move(Side::Left);
}
$ g++49 -v
Using built-in specs.
COLLECT_GCC=g++49
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc49/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local --disable-nls
--libdir=/usr/local/lib/gcc49 --libexecdir=/usr/local/libexec/gcc49
--program-suffix=49 --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/gcc49/include/c++/
--with-libiconv-prefix=/usr/local --with-system-zlib --disable-rpath
--enable-languages=c,c++ --mandir=/usr/local/man
--infodir=/usr/local/info/gcc49 --disable-initfini-array
--disable-install-libiberty
Thread model: posix
gcc version 4.10.0 20140804 (experimental) (GCC)
$ g++49 -Wall -Wextra -o t t.cc -std=c++11 -O3
$ ./t
move: side is 0
adjust: side is 2, final 0
adjust: side is 0, final 1
The output should be 'side is 0' on all three lines.
[Bug go/61308] gccgo: ICE in Expression::check_bounds [GoSmith]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61308 --- Comment #3 from Ian Lance Taylor ian at airs dot com --- Test committed to master repository as fixedbugs/bug489.go.
[Bug go/61866] FAIL: ./index0-out.go execution, -O0 -g -fno-var-tracking-assignments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61866 --- Comment #1 from ian at gcc dot gnu.org ian at gcc dot gnu.org --- Author: ian Date: Tue Aug 5 02:58:15 2014 New Revision: 213616 URL: https://gcc.gnu.org/viewcvs?rev=213616root=gccview=rev Log: PR go/61308 PR go/61866 compiler: Don't cast index expr to int before bounds check. This fixes http://gcc.gnu.org/PR61866 : on a 32-bit system, casting an int64 index to int drops the upper 32 bits of the value, and thus can cause an out-of-range index to appear to be in range. This undoes part of change 1318:fa6e0c716dba (https://codereview.appspot.com/104610044) and therefore breaks http://gcc.gnu.org/PR61308 again. I have a separate patch for that (http://codereview.appspot.com/122020043). In addition to undoing part of that change, this patch adds code to avoid a compiler crash. This changes PR61308 from a compiler crash to an incorrect error message. Modified: trunk/gcc/go/gofrontend/expressions.cc
[Bug go/61308] gccgo: ICE in Expression::check_bounds [GoSmith]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61308 --- Comment #4 from ian at gcc dot gnu.org ian at gcc dot gnu.org --- Author: ian Date: Tue Aug 5 02:58:15 2014 New Revision: 213616 URL: https://gcc.gnu.org/viewcvs?rev=213616root=gccview=rev Log: PR go/61308 PR go/61866 compiler: Don't cast index expr to int before bounds check. This fixes http://gcc.gnu.org/PR61866 : on a 32-bit system, casting an int64 index to int drops the upper 32 bits of the value, and thus can cause an out-of-range index to appear to be in range. This undoes part of change 1318:fa6e0c716dba (https://codereview.appspot.com/104610044) and therefore breaks http://gcc.gnu.org/PR61308 again. I have a separate patch for that (http://codereview.appspot.com/122020043). In addition to undoing part of that change, this patch adds code to avoid a compiler crash. This changes PR61308 from a compiler crash to an incorrect error message. Modified: trunk/gcc/go/gofrontend/expressions.cc
[Bug go/61308] gccgo: ICE in Expression::check_bounds [GoSmith]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61308 --- Comment #5 from ian at gcc dot gnu.org ian at gcc dot gnu.org --- Author: ian Date: Tue Aug 5 03:10:53 2014 New Revision: 213617 URL: https://gcc.gnu.org/viewcvs?rev=213617root=gccview=rev Log: PR go/61308 compiler: Handle enclosing vars for function type in function lit. This fixes a dumb bug in which the enclosing vars were incorrectly cleared when a function literal contains a reference to a function type. The test for this will go into the master repository in the change at http://codereview.appspot.com/121200043 . Modified: branches/gcc-4_9-branch/gcc/go/gofrontend/parse.cc
[Bug go/61308] gccgo: ICE in Expression::check_bounds [GoSmith]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61308 --- Comment #6 from ian at gcc dot gnu.org ian at gcc dot gnu.org --- Author: ian Date: Tue Aug 5 03:11:17 2014 New Revision: 213618 URL: https://gcc.gnu.org/viewcvs?rev=213618root=gccview=rev Log: PR go/61308 compiler: Handle enclosing vars for function type in function lit. This fixes a dumb bug in which the enclosing vars were incorrectly cleared when a function literal contains a reference to a function type. The test for this will go into the master repository in the change at http://codereview.appspot.com/121200043 . Modified: trunk/gcc/go/gofrontend/parse.cc
