[Bug bootstrap/70704] [6 Regression] AIX bootstrap comparison failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #52 from Jakub Jelinek --- Fixed. As for adding testcases, that is not trivial, we'd need to add a new framework for that that would compile some tests both with -fchecking and -fno-checking, and strip/sanitize the result and compare that.
[Bug bootstrap/70704] [6 Regression] AIX bootstrap comparison failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704 --- Comment #51 from Jakub Jelinek --- Author: jakub Date: Tue Apr 26 06:10:43 2016 New Revision: 235430 URL: https://gcc.gnu.org/viewcvs?rev=235430&root=gcc&view=rev Log: PR bootstrap/70704 * configure.ac (--enable-stage1-checking): For --disable-checking or implicit --enable-checking, make sure extra flag matches in between stage1 and later checking. * configure: Regenerated. gcc/ * configure.ac (--enable-checking): Document extra flag, for non-release builds default to --enable-checking=yes,extra. If misc checking and extra checking, define CHECKING_P to 2 instead of 1. * common.opt (fchecking=): Add. * doc/invoke.texi (-fchecking=): Document. * doc/install.texi: Document --enable-checking changes. * configure: Regenerated. * config.in: Regenerated. gcc/cp/ * pt.c (build_non_dependent_expr): Use flag_checking > 1 instead of just flag_checking. Modified: trunk/ChangeLog trunk/configure trunk/configure.ac trunk/gcc/ChangeLog trunk/gcc/common.opt trunk/gcc/config.in trunk/gcc/configure trunk/gcc/configure.ac trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/doc/install.texi trunk/gcc/doc/invoke.texi
[Bug bootstrap/70704] [6 Regression] AIX bootstrap comparison failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704 --- Comment #50 from Jakub Jelinek --- Author: jakub Date: Tue Apr 26 06:08:20 2016 New Revision: 235429 URL: https://gcc.gnu.org/viewcvs?rev=235429&root=gcc&view=rev Log: PR bootstrap/70704 * pt.c (build_non_dependent_expr): Temporarily disable flag_checking guarded code. Modified: branches/gcc-6-branch/gcc/cp/ChangeLog branches/gcc-6-branch/gcc/cp/pt.c
[Bug c++/70796] New: [DR 1030] Initialization order with braced-init-lists still broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70796 Bug ID: 70796 Summary: [DR 1030] Initialization order with braced-init-lists still broken Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: rs2740 at gmail dot com Target Milestone: --- The following modified test case (replacing postfix ++ with prefix and adjusting the expected values accordingly) from PR61382 still aborts on Wandbox (http://melpon.org/wandbox/permlink/IQojTl16DtIxCd2M) and also gives a bogus -Wsequence-point warning: struct A { int i,j; A(int i,int j):i(i),j(j){} }; int main() { int i = 0; A a{++i, ++i}; if (a.i != 1 || a.j != 2) __builtin_abort(); }
[Bug c++/66561] __builtin_LINE at al. should yield constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66561 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-04-26 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||4.9.3, 5.3.0, 6.0 --- Comment #1 from Martin Sebor --- Working on a patch for GCC 7.
[Bug middle-end/70795] New: [7 Regression] gcc/libjava/interpret.cc:1948:1: ICE: in binds_to_current_def_p, at symtab.c:2232
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70795 Bug ID: 70795 Summary: [7 Regression] gcc/libjava/interpret.cc:1948:1: ICE: in binds_to_current_def_p, at symtab.c:2232 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 libtool: compile: /test/gnu/gcc/objdir/./gcc/xgcc -shared-libgcc -B/test/gnu/gcc/objdir/./gcc -nostdinc++ -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc+ +-v3/src -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/libsupc++/.libs -B/opt/gnu/gcc/gcc-7/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-7/hppa2.0w-hp-hpux11.1 1/lib/ -isystem /opt/gnu/gcc/gcc-7/hppa2.0w-hp-hpux11.11/include -isystem /opt/gnu/gcc/gcc-7/hppa2.0w-hp-hpux11.11/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc/libjava -I./include -I./gcj -I../../../gcc/libjava -Iinclude -I../../../gcc/li bjava/include -I../../../gcc/libjava/classpath/include -Iclasspath/include -I../../../gcc/libjava/classpath/native/fdlibm -I../../../gcc/libjava/../boehm-gc/include -I../boehm-gc/include -I../../../gcc/libjava/libltdl -I../../../gcc/libjava /libltdl -I../../../gcc/libjava/.././libjava/../libgcc -I../../../gcc/libjava/../zlib -I../../../gcc/libjava/../libffi/include -I../libffi/include -fno-rtti -fnon-call-exceptions -pthread -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSE T_BITS=64 -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\"/opt/gnu/gcc/gcc-7\" -DTOOLEXEC LIBDIR=\"/opt/gnu/gcc/gcc-7/lib\" -DJAVA_HOME=\"/opt/gnu/gcc/gcc-7\" -DBOOT_CLAS S_PATH=\"/opt/gnu/gcc/gcc-7/share/java/libgcj-7.0.0.jar\" -DJAVA_EXT_DIRS=\"/opt /gnu/gcc/gcc-7/share/java/ext\" -DGCJ_ENDORSED_DIRS=\"/opt/gnu/gcc/gcc-7/share/j ava/gcj-endorsed\" -DGCJ_VERSIONED_LIBDIR=\"/opt/gnu/gcc/gcc-7/lib/gcj-7.0.0-17\ " -DPATH_SEPARATOR=\":\" -DECJ_JAR_FILE=\"\" -DLIBGCJ_DEFAULT_DATABASE=\"/opt/gn u/gcc/gcc-7/lib/gcj-7.0.0-17/classmap.db\" -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\ "gcj-7.0.0-17/classmap.db\" -fwrapv -g -O2 -MT interpret.lo -MD -MP -MF .deps/in terpret.Tpo -c ../../../gcc/libjava/interpret.cc -fPIC -DPIC -o .libs/interpret.o _GLOBAL__I_65535_0_.._.._.._gcc_libjava_interpret.cc_E29B42DF_0x4efdcb59/1100 () @7aeeb5e8 Type: function definition analyzed Visibility: force_output public artificial constructor References: Referring: Availability: available First run: 0 Function flags: body static_constructor (priority:65535) Called by: Calls: _GLOBAL__sub_I_interpret.cc/861 (1.00 per call) ../../../gcc/libjava/interpret.cc: In function '': ../../../gcc/libjava/interpret.cc:1948:1: internal compiler error: in binds_to_current_def_p, at symtab.c:2232 } ^ This is revision 235394.
[Bug libstdc++/70794] New: vector.push_back() crashes with std::bad_alloc after 2^32 calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70794 Bug ID: 70794 Summary: vector.push_back() crashes with std::bad_alloc after 2^32 calls Product: gcc Version: 5.3.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: numien at deathwyrm dot com Target Milestone: --- Created attachment 38340 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38340&action=edit Minimal test program Despite std::vector::max_size() returning 18446744073709551615, a test program to repeatedly call std::vector::push_back() crashes on the 4294967297th iteration with a std::bad_alloc exception. I am compiling in 64-bit mode, and my system should have plenty of memory. The fact it's reaching exactly 2^32 indicates to me that it's likely a bug. The test program I used is attached.
[Bug c++/70792] Incorrect sequence point warning with uniform initializer syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70792 --- Comment #2 from Jason Turner --- Follow up, this is a better test case that does not pass by && struct MyType { MyType(int i, int j, int k, int l) : sum(i + j + k + l) { } int sum; }; int main() { int i = 0; std::cout << MyType{ ++i, ++i, ++i, ++i }.sum << '\n'; }
[Bug target/70098] PowerPC64: eigen hits ICE following invalid register assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70098 --- Comment #11 from Bill Schmidt --- Author: wschmidt Date: Mon Apr 25 22:29:49 2016 New Revision: 235424 URL: https://gcc.gnu.org/viewcvs?rev=235424&root=gcc&view=rev Log: [gcc] 2016-04-25 Bill Schmidt Backport from mainline 2016-03-14 Segher Boessenkool PR target/70098 * config/rs6000/rs6000.md (*ctr_internal1, *ctr_internal2, *ctr_internal5, *ctr_internal6): Also allow "d" as output. (define_split for the GPR case): Use int_reg_operand instead of gpc_reg_operand for the output. [gcc/testsuite] 2016-04-25 Bill Schmidt Backport from mainline 2016-03-14 Segher Boessenkool PR target/70098 * lib/target-supports.exp (check_effective_target_powerpc64_no_dm): New function. * g++.dg/pr70098.C: New testcase. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/pr70098.C Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/rs6000/rs6000.md branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/lib/target-supports.exp
[Bug target/70098] PowerPC64: eigen hits ICE following invalid register assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70098 --- Comment #10 from Bill Schmidt --- Author: wschmidt Date: Mon Apr 25 22:28:36 2016 New Revision: 235423 URL: https://gcc.gnu.org/viewcvs?rev=235423&root=gcc&view=rev Log: [gcc] 2016-04-25 Bill Schmidt Backport from mainline 2016-03-14 Segher Boessenkool PR target/70098 * config/rs6000/rs6000.md (*ctr_internal1, *ctr_internal2, *ctr_internal5, *ctr_internal6): Also allow "d" as output. (define_split for the GPR case): Use int_reg_operand instead of gpc_reg_operand for the output. [gcc/testsuite] 2016-04-25 Bill Schmidt Backport from mainline 2016-03-14 Segher Boessenkool PR target/70098 * lib/target-supports.exp (check_effective_target_powerpc64_no_dm): New function. * g++.dg/pr70098.C: New testcase. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/pr70098.C Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/rs6000/rs6000.md branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/testsuite/lib/target-supports.exp
[Bug c++/70793] New: g++ does not accept some forms of "friend" declaration for builtin types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70793 Bug ID: 70793 Summary: g++ does not accept some forms of "friend" declaration for builtin types Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jpmarath at gmail dot com Target Milestone: --- This fails to compile: struct S { friend short ; } s; with gcc 5.3.1, the reported error is (compile with -std=c++14): --- 2 : error: friend declaration does not name a class or function friend short ; ^ Compilation failed --- The strange thing is that g++ accepts "friend short int;" : struct S { friend short int; } s; clang++ 3.8 accepts both forms.
[Bug c++/70792] Incorrect sequence point warning with uniform initializer syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70792 --- Comment #1 from Jason Turner --- Note: I tested this code further and the compiler seems to be generating incorrect code based on this standard, not just warning incorrectly.
[Bug c++/70792] New: Incorrect sequence point warning with uniform initializer syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70792 Bug ID: 70792 Summary: Incorrect sequence point warning with uniform initializer syntax Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lefticus at gmail dot com Target Milestone: --- The following code: #include struct Do_Call { template Do_Call(const Func &f, T && ... t) { f(std::forward(t)...); } }; int main() { const auto sum = [](int w, int x, int y, int z) { return w + x + y + z; }; int i = 0; Do_Call{sum, ++i, ++i, ++i, ++i}; } Generates the -Wsequence-point warning for the variable 'i'. However, the standard states: "Within the initializer-list of a braced-init-list, the initializer-clauses, including any that result from pack expansions (14.5.3), are evaluated in the order in which they appear. That is, every value computation and side effect associated with a given initializer-clause is sequenced before every value computation and side effect associated with any initializer-clause that follows it in the comma-separated list of the initializer-list. [Note: This evaluation ordering holds regardless of the semantics of the initialization; for example, it applies when the elements of the initializer-list are interpreted as arguments of a constructor call, even though ordinarily there are no sequencing constraints on the arguments of a call. —end note ]" The "Note: This evaluation ordering holds regardless of the semantics of the initialization; for example, it applies when the elements of the initializer-list are interpreted as arguments of a constructor call, even though ordinarily there are no sequencing constraints on the arguments of a call. —end note" is the most applicable to this bug report. This occurs in all versions tested between 4.7.3->6
[Bug c/70791] New: -Wnested-externs prints inconsistent column number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70791 Bug ID: 70791 Summary: -Wnested-externs prints inconsistent column number Product: gcc Version: 6.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: egall at gwmail dot gwu.edu Target Milestone: --- Host: i386-apple-darwin9.8.0 Target: i386-apple-darwin9.8.0 Build: i386-apple-darwin9.8.0 Say I have the following file: $ cat undeclared.c char *foo(char *); int bar(void) { char *baz = foo(UNDECLARED_MACRO("")); } When I compile it like this, gcc says: $ /usr/local/bin/gcc -c -Wimplicit -Wnested-externs -Wint-conversion undeclared.c undeclared.c: In function ‘bar’: undeclared.c:4:18: warning: implicit declaration of function ‘UNDECLARED_MACRO’ [-Wimplicit-function-declaration] char *baz = foo(UNDECLARED_MACRO("")); ^ undeclared.c:4:2: warning: nested extern declaration of ‘UNDECLARED_MACRO’ [-Wnested-externs] char *baz = foo(UNDECLARED_MACRO("")); ^ undeclared.c:4:18: warning: passing argument 1 of ‘foo’ makes pointer from integer without a cast [-Wint-conversion] char *baz = foo(UNDECLARED_MACRO("")); ^ undeclared.c:1:7: note: expected ‘char *’ but argument is of type ‘int’ char *foo(char *); ^ I would expect the warning from -Wnested-externs to point to the same column as the other 2 warnings. (Of course, ideally the 3 would be combined into a single warning, but that's a separate issue) My gcc version info: $ /usr/local/bin/gcc -v Using built-in specs. COLLECT_GCC=/usr/local/bin/gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i386-apple-darwin9.8.0/6.0.0/lto-wrapper Target: i386-apple-darwin9.8.0 Configured with: ../configure --disable-werror --enable-languages=c,c++,lto,objc,obj-c++ --enable-stage1-checking=release -C --with-system-libunwind --enable-secureplt --enable-frame-pointer --enable-version-specific-runtime-libs --enable-assert --enable-fat --enable-portable-binary --enable-browser-plugin --enable-gconf-peer --enable-libgcj-debug --enable-gc-debug --enable-interpreter --enable-aot-compile-rpm --enable-java-home --with-x --enable-collections --enable-gstreamer-peer --enable-xmlj --enable-qt-peer --enable-debug --enable-local-sockets --without-isl --enable-objc-gc --enable-maintainer-mode --enable-host-shared CC=/usr/local/bin/gcc CXX=/usr/local/bin/g++ AUTOCONF=/usr/local/bin/autoconf AUTOHEADER=/usr/local/bin/autoheader AUTOM4TE=/usr/local/bin/autom4te AUTORECONF=/usr/local/bin/autoreconf AUTOSCAN=/usr/local/bin/autoscan AUTOUPDATE=/usr/local/bin/autoupdate IFNAMES=/usr/local/bin/ifnames Thread model: posix gcc version 6.0.0 20151007 (experimental) (GCC)
[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667 --- Comment #17 from Alexander Cherepanov --- On 2016-04-25 17:34, joseph at codesourcery dot com wrote: > Or it could simply document an additional requirement on the C library > used with GCC (that the case of exact overlap works), just as it documents > the requirement that some functions such as memcpy be provided even in the > freestanding case. The compiler and library implementations need to > cooperate to produce a conforming C implementation. 1. Is glibc community ready to provide such guarantee? The doc[1] doesn't currently mention an exception for exact overlap. [1] https://www.gnu.org/software/libc/manual/html_node/Copying-Strings-and-Arrays.html#index-memcpy 2. I agree that it should be documented. Together with the assumption that memcpy doesn't clobber errno. 3. The decision affects the whole Free Software community. If memcpy with exact overlap inserted be gcc are legitimized then users cannot use tools like valgrind to catch such cases in their own code. (And neither _FORTIFY_SOURCE nor UBSan seem to catch overlapping memcpy now.) So it effectively leads to legitimizing such memcpy in user's code too. Making memcpy closer to a simple assignment (C11, 6.5.16.1p3) could be a good thing. Maybe even fix C std or POSIX? BTW llvm bug is here: https://llvm.org/bugs/show_bug.cgi?id=11763 . It also contains links to valgrind discussions.
[Bug c++/70790] New: Can't mangle noexcept expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70790 Bug ID: 70790 Summary: Can't mangle noexcept expressions Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: eric.niebler at gmail dot com Target Milestone: --- #include template void foo(T, typename std::enable_if())), int>::type) { } int main() { foo(0,0); } Results in: Test.cpp: In instantiation of ‘void foo(T, typename std::enable_if())), int>::type) [with T = int; typename std::enable_if())), int>::type = int]’: Test.cpp:19:6: sorry, unimplemented: mangling noexcept_expr void foo(T, typename std::enable_if())), int>::type) ^
[Bug middle-end/70773] Profiling makes sudoku solver slower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70773 --- Comment #5 from PeteVine --- The issue seems to be purely about soft division. (I was either using no -mcpu or -mcpu=cortex-a5) Compiling for e.g Cortex-A7, doesn't need to lower any library calls and even though hardware division is not used in the vanilla case, it is after profiling. The profiled binary even shows a benefit under qemu-arm so I can safely guess the issue is non-existent when targeting similar ARM parts.
[Bug bootstrap/70704] [6 Regression] AIX bootstrap comparison failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704 --- Comment #49 from David Edelsohn --- Can we add some testcases to ensure that -fchecking and similar flags don't accidentally affect code generation due to future changes?
[Bug bootstrap/70704] [6 Regression] AIX bootstrap comparison failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704 --- Comment #48 from David Edelsohn --- Commenting out the fold_non_dependent_expr call seems to work for me using the build method that regularly was failing before.
[Bug c/12245] [4.9/5/6/7 regression] Uses lots of memory when compiling large initialized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245 Franc[e]sco changed: What|Removed |Added CC||lolisamurai at waifu dot club --- Comment #59 from Franc[e]sco --- I can confirm this still happens in gcc 4.9.3 (gentoo linux, amd64), here's an example: https://ideone.com/J699eJ
[Bug c++/70789] New: cilk test fib-tplt.cc occasionally fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70789 Bug ID: 70789 Summary: cilk test fib-tplt.cc occasionally fails Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: bernds at gcc dot gnu.org Target Milestone: --- Target: x86_64-pc-linux-gnu I've had a test run fail with FAIL: g++.dg/cilk-plus/CK/fib-tplt.cc -g -fcilkplus execution test This was while testing the -m32 variant. I've let the test run in a loop for a few hours, and it seems to fail sporadically with a segfault, almost certainly not because of the fairly harmless patch I was testing. I've tried to load the coredump into gdb, unfortunately it's not very informative. (gdb) bt #0 0x1c46 in ?? () #1 0xf76d3587 in ?? () #2 0xf76d3347 in ?? () #3 0x in ?? () Tagging it as wrong-code although I'm not sure whether the testcase is valid. We seem not to have a libcilkrts component.
[Bug c++/67247] ICE on std::forward args&& inside nested lambda function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67247 tower120 changed: What|Removed |Added Known to work||6.0 --- Comment #4 from tower120 --- Reduced case [Forwarding captured variadic arguments inside lambda] : https://godbolt.org/g/D7lXEA template int g(T... t) { return 0; } template void f(Args&&... args) { auto lm = [&](auto&&..._args) { auto f = [&]{g(std::forward(_args)...);}; //auto f = [&]{g(_args...);}; /* THIS ONE OK */ return f(); }; lm(args...); } int main() { f(2, 5, 7); } Error "_args was not declared" on 4.9.x ICE on 5.x Ok on 6.x
[Bug target/68273] [5/6/7 Regression] Wrong code on mips/mipsel due to (invalid?) peeking at alignments in function_arg.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68273 --- Comment #33 from Aurelien Jarno --- (In reply to Hector Oron from comment #32) > (In reply to Richard Biener from comment #31) > > eipa_sra introduces the remaining SSA name with non-default alignment via > > [PATCH] > For the record, Debian now have the patch from comment #32 in its version of GCC 5 and 6. This fixes a few more issues than reported here, in addition to graphviz, it also fixes subversion and jq.
[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667 --- Comment #16 from Patrick J. LoPresti --- Well, Valgrind itself is another real-world example. Tools like Valgrind cannot distinguish invalid memcpy() calls by the programmer from invalid memcpy() calls emitted by GCC. You can, of course, redefine every standard interface you like and simply document it. That would be awful engineering -- as in this case -- but you could do it.
[Bug bootstrap/70704] [6 Regression] AIX bootstrap comparison failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704 Jakub Jelinek changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #47 from Jakub Jelinek --- So, I believe it is the: /* When checking, try to get a constant value for all non-dependent expressions in order to expose bugs in *_dependent_expression_p and constexpr. */ if (flag_checking && cxx_dialect >= cxx11 /* Don't do this during nsdmi parsing as it can lead to unexpected recursive instantiations. */ && !parsing_nsdmi ()) fold_non_dependent_expr (expr); hunk in cp/pt.c (build_nondependent_expr), which results both in some extra DECL_UIDs being created (in theory it could be fine), but also in funcdef_no differences etc.: #0 _Z24allocate_struct_functionP9tree_nodeb (fndecl=0x7061b280, abstract_p=false) at /home/dje/src/gcc-6.0.1-RC2/gcc/function.c:4874 #1 0x10070e60 in _Z24start_preparsed_functionP9tree_nodeS0_i (decl1=0x7061b280, attrs=0x0, flags=1) at /home/dje/src/gcc-6.0.1-RC2/gcc/cp/decl.c:14059 #2 0x105feb9c in _Z16instantiate_declP9tree_nodeib (d=0x7061b280, defer_ok=0, expl_inst_class_mem_p=false) at /home/dje/src/gcc-6.0.1-RC2/gcc/cp/pt.c:21969 #3 0x1094fd38 in _Z9mark_usedP9tree_nodei (decl=0x7061b280, complain=0) at /home/dje/src/gcc-6.0.1-RC2/gcc/cp/decl2.c:5273 #4 0x1023262c in _ZL15build_over_callP11z_candidateii (cand=0x306323c0, flags=262145, complain=0) at /home/dje/src/gcc-6.0.1-RC2/gcc/cp/call.c:7707 #5 0x10221f8c in _Z23build_new_function_callP9tree_nodePP3vecIS0_5va_gc8vl_embedEbi (fn=0x7045e468, args=0x2ff200f0, koenig_p=false, complain=0) at /home/dje/src/gcc-6.0.1-RC2/gcc/cp/call.c:4152 #6 0x100dba64 in _Z16finish_call_exprP9tree_nodePP3vecIS0_5va_gc8vl_embedEbbi (fn=0x7045e468, args=0x2ff200f0, disallow_virtual=false, koenig_p=false, complain=0) at /home/dje/src/gcc-6.0.1-RC2/gcc/cp/semantics.c:2461 #7 0x105e30ac in _Z21tsubst_copy_and_buildP9tree_nodeS0_iS0_bb (t=0x7061e180, args=0x0, complain=0, in_decl=0x0, function_p=false, integral_constant_expression_p=true) at /home/dje/src/gcc-6.0.1-RC2/gcc/cp/pt.c:16629 #8 0x105a4bf8 in _Z39instantiate_non_dependent_expr_internalP9tree_nodei (expr=0x7061e180, complain=0) at /home/dje/src/gcc-6.0.1-RC2/gcc/cp/pt.c:5640 #9 0x114c1278 in _Z23fold_non_dependent_exprP9tree_node (t=0x7061e180) at /home/dje/src/gcc-6.0.1-RC2/gcc/cp/constexpr.c:4388 #10 0x10606e08 in _Z24build_non_dependent_exprP9tree_node (expr=0x7061e180) at /home/dje/src/gcc-6.0.1-RC2/gcc/cp/pt.c:23631 As stage1 is built with the default --enable-stage1-checking, the result between stage1 and stage2 auto-host.h is: CHECKING_P, ENABLE_GC_CHECKING, ENABLE_GIMPLE_CHECKING, ENABLE_RTL_FLAG_CHECKING, ENABLE_TREE_CHECKING, ENABLE_TYPES_CHECKING, and allocate_struct_function allocates a new cfun->funcdef_no, which is then emitted in the LFB..*/LFE..* labels, seems to affect the debug info (which on AIX is emitted in both stage2 and stage3) etc. Additionally, wonder if retrieve_specialization's if (flag_checking) verify_unstripped_args (args); couldn't also affect bootstrap, but haven't seen that during bootstrap. The question is what to do, comment out the fold_non_dependent_expr stuff altogether on the release branch (at least temporarily), guard with some other option (which unlike -fchecking would be documented to possibly affect code generation and which would be based on some other configure checking flag (and the default for that flag would be always the same between stage1 and later stages), something different? I'm in any case starting a bootstrap now with the fold_non_dependent_expr call commented out.
[Bug libstdc++/70788] LaTeX formulae in doxygen comments should be suppressed in man-page output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70788 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-04-25 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Errors from the Debian package include several due to this issue: usr/share/man/man3/__gnu_cxx.3cxx.gz 1319: a space character is not allowed in an escape name usr/share/man/man3/__gnu_debug::_Safe_unordered_container_base.3cxx.gz 111: warning [p 2, 2.2i]: can't break line usr/share/man/man3/__gnu_parallel.3cxx.gz 2415: warning: numeric expression expected (got `r') usr/share/man/man3/__gnu_pbds::detail::left_child_next_sibling_heap_const_iterator_.3cxx.gz 11: warning [p 1, 1.8i]: can't break line usr/share/man/man3/__gnu_pbds::detail::left_child_next_sibling_heap_node_point_const_iterator_.3cxx.gz 5: warning [p 1, 0.8i]: can't break line usr/share/man/man3/std::_Hashtable.3cxx.gz 211: warning [p 2, 7.2i]: can't break line usr/share/man/man3/std::__debug::map.3cxx.gz 200: warning [p 2, 4.8i]: can't break line usr/share/man/man3/std::__debug::multimap.3cxx.gz 200: warning [p 2, 5.0i]: can't break line usr/share/man/man3/std::__debug::unordered_map.3cxx.gz 209: warning [p 2, 6.3i]: can't break line usr/share/man/man3/std::__debug::unordered_multimap.3cxx.gz 209: warning [p 2, 6.7i]: can't break line usr/share/man/man3/std::__profile::map.3cxx.gz 182: warning [p 2, 4.0i]: can't break line usr/share/man/man3/std::__profile::multimap.3cxx.gz 176: warning [p 2, 3.7i]: can't break line usr/share/man/man3/std::__profile::unordered_map.3cxx.gz 119: warning [p 2, 0.0i]: can't break line usr/share/man/man3/std::__profile::unordered_multimap.3cxx.gz 116: warning [p 2, 0.0i]: can't break line usr/share/man/man3/std::error_condition.3cxx.gz 17: warning [p 1, 2.0i]: can't break line usr/share/man/man3/std::exponential_distribution.3cxx.gz 30: warning: numeric expression expected (got `m') usr/share/man/man3/std::extreme_value_distribution.3cxx.gz 94: a space character is not allowed in an escape name usr/share/man/man3/std::fisher_f_distribution.3cxx.gz 103: a space character is not allowed in an escape name usr/share/man/man3/std::gamma_distribution.3cxx.gz 30: normal or special character expected (got `\&') usr/share/man/man3/std::linear_congruential_engine.3cxx.gz 97: a space character is not allowed in an escape name usr/share/man/man3/std::lognormal_distribution.3cxx.gz 99: a space character is not allowed in an escape name usr/share/man/man3/std::map.3cxx.gz 179: warning [p 2, 4.7i]: can't break line usr/share/man/man3/std::multimap.3cxx.gz 172: warning [p 2, 4.2i]: can't break line usr/share/man/man3/std::normal_distribution.3cxx.gz 102: a space character is not allowed in an escape name usr/share/man/man3/std::queue.3cxx.gz 197: warning: macro `c'' not defined usr/share/man/man3/std::regex_iterator.3cxx.gz 42: warning [p 1, 4.0i]: can't break line usr/share/man/man3/std::regex_token_iterator.3cxx.gz 51: warning [p 1, 5.8i]: can't break line usr/share/man/man3/std::student_t_distribution.3cxx.gz 100: a space character is not allowed in an escape name usr/share/man/man3/std::subtract_with_carry_engine.3cxx.gz 99: a space character is not allowed in an escape name usr/share/man/man3/std::unordered_map.3cxx.gz 306: warning [p 3, 6.0i]: can't break line usr/share/man/man3/std::unordered_multimap.3cxx.gz 306: warning [p 3, 6.8i]: can't break line usr/share/man/man3/std::weibull_distribution.3cxx.gz 94: a space character is not allowed in an escape name
[Bug libstdc++/70788] New: LaTeX formulae in doxygen comments should be suppressed in man-page output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70788 Bug ID: 70788 Summary: LaTeX formulae in doxygen comments should be suppressed in man-page output Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: documentation Severity: minor Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- Doxygen's formula support only works for HTML and LaTeX output, so the generated man pages contain garbled LaTeX such as "x_{i+1}tarrow(ax_{i} + c) d ]"
[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667 --- Comment #15 from joseph at codesourcery dot com --- On Sun, 24 Apr 2016, lopresti at gmail dot com wrote: > That said, this is clearly a real bug in GCC. memcpy has a well-defined > interface; GCC emits calls violating that interface; therefore GCC is buggy. I > do not see why this is even controversial. (Also see Julian Seward's > description of real-world problems in comment 5.) As far as I know, that does not describe real-world problems on any target supported by GCC. > GCC either needs to provide its own mempcy or it needs to respect the > interface. The cost of the latter is surely trivial, especially since many > cases could be optimized by alias analysis. Or it could simply document an additional requirement on the C library used with GCC (that the case of exact overlap works), just as it documents the requirement that some functions such as memcpy be provided even in the freestanding case. The compiler and library implementations need to cooperate to produce a conforming C implementation.
[Bug sanitizer/70712] False positive from AddressSanitizer with use of 'alignas'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70712 --- Comment #5 from Roger Orr --- Thank you. I can confirm that the fix also resolves the original problem from which I derived the sample program.
[Bug bootstrap/70704] [6 Regression] AIX bootstrap comparison failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704 --- Comment #46 from Jakub Jelinek --- So, my current thinking is that this is related to make -jN bootstrap doing stage1 checking by default. Guess with --enable-stage1-checking=release it would bootstrap fine, but haven't verified that. But, what I see is that if I build build/ggc-none.o with stage1 cc1plus with additional -fno-checking -g0, the result is the same as when it is built with stage2 cc1plus -g0, and similarly if it is built with stage1 cc1plus with -g0, the result is the same when it is built with stage2 cc1plus -g0 -fchecking. I've applied the https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594#c20 hack (only the tree.c part of it) and I can see that with -fchecking there are different DECL_UIDs (more of them too) created.
[Bug ipa/70760] [6/7 regression] wrong generated code for std::make_unique with -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70760 --- Comment #9 from rguenther at suse dot de --- On Mon, 25 Apr 2016, david.abdurachmanov at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70760 > > --- Comment #8 from David Abdurachmanov com> --- > Should I continue testing the 2nd patch, or dump whatever is currently built > and restart with the patch from your latest comment? I think the patch from the last comment is most correct, the 2nd is wrong. The first one is safest at this point.
[Bug go/70787] No time and child info with -pg and gccgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70787 --- Comment #1 from Dominik Vogt --- (I've also tried setting GMON_OUT_PREFIX so that the gmon.out file does not get overwritten by different threads, but in either case only one dump file is created.)
[Bug tree-optimization/68030] Redundant address calculations in vectorized loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68030 amker at gcc dot gnu.org changed: What|Removed |Added CC||amker at gcc dot gnu.org --- Comment #5 from amker at gcc dot gnu.org --- (In reply to Kirill Yukhin from comment #4) > Hello Bin, > Is it possible to handle the issue using current ivopt? Not yet I think. IIUC, this is the same issue as PR69710. We need to teach vectorizer about CSE opportunities. I had a scratch patch fixing it in a way just as mentioned in #comment2, I will revisit it after work on if-conversion. According to Richard's comment, I may need to make it a general fix, for example, share this facility among different optimizers that need to insert code in pre-header. Thanks.
[Bug go/70787] New: No time and child info with -pg and gccgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70787 Bug ID: 70787 Summary: No time and child info with -pg and gccgo Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: vogt at linux dot vnet.ibm.com CC: cmang at google dot com, krebbel at gcc dot gnu.org Target Milestone: --- It looks like the -pg option does something wrong for Go programs. Example: This program just wastes time in sub functions: -- main.go -- package main func foo () { var i int i = 0 for (i < 1000) { i++ } } func bar () { var i int i = 0 for (i < 1000) { i++ } } func main () { var i int i = 0 for (i < 100) { foo(); foo(); bar(); i++ } } -- snip -- $ gccgo -pg -O0 main.go $ ./a.out $ prof ./a.out gmoun.out => index % timeself childrencalled name 0.000.00 300/300 main.main [8] [1] 0.00.000.00 300 frame_dummy [1] ^^^ (actual run time was about 5 seconds) Even for this very simple program without Go library dependencies, no timing information seems to be dumped into the gmon.out file. Function calls have all been counted in the "frame_dummy" bucket (double checked that functios have not been inlied). My vague first guess is that maybe the timing information is written to to some place in memory but is read from a different place when generating gmon.out because the profiling code is not aware of Gccgo's threading model(?).
[Bug ada/70786] New: Missing "not" breaks Ada.Text_IO.Get_Immediate(File, Item, Available)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70786 Bug ID: 70786 Summary: Missing "not" breaks Ada.Text_IO.Get_Immediate(File, Item, Available) Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: ktamp at chem dot uoa.gr Target Milestone: --- OS: Arch Linux x64 GCC version: 5.3.0 Missing "not" in line #671 of a-textio.adb causes Get_Immediate(File, Item, Available) to throw an exception when key "[" is pressed. This also affects processing of keypresses when function keys F5 to F12 are pressed. Get_Immediate(File, Item) does not have the same issue because "not" is there (line #611): "(if not Is_Start_Of_Encoding (Character'Val (ch), File.WC_Method)" Example code (run and press e.g. key F12): with Ada.Text_IO; use Ada.Text_IO; procedure Test is C : Character; Available : Boolean; begin Get_Immediate (C); loop Put (Integer'Image (Character'Pos (C))); Get_Immediate (C, Available); exit when not Available; end loop; end Test;
[Bug tree-optimization/68030] Redundant address calculations in vectorized loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68030 Kirill Yukhin changed: What|Removed |Added CC||amker.cheng at gmail dot com --- Comment #4 from Kirill Yukhin --- Hello Bin, Is it possible to handle the issue using current ivopt?
[Bug ipa/70760] [6/7 regression] wrong generated code for std::make_unique with -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70760 --- Comment #8 from David Abdurachmanov --- Should I continue testing the 2nd patch, or dump whatever is currently built and restart with the patch from your latest comment?
[Bug ipa/70785] LTO bootstrap with IPA PTA is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70785 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-04-25 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Mine.
[Bug ipa/70785] New: LTO bootstrap with IPA PTA is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70785 Bug ID: 70785 Summary: LTO bootstrap with IPA PTA is broken Product: gcc Version: 6.0 Status: UNCONFIRMED Keywords: lto, wrong-code Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- gen* in stage2 are miscompiled.
[Bug c/67784] Incorrect parsing when using declarations in for loops and typedefs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67784 --- Comment #10 from Marek Polacek --- Sorry about that. I'll have another look.
[Bug ipa/70760] [6/7 regression] wrong generated code for std::make_unique with -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70760 --- Comment #7 from Richard Biener --- It looks to me we are using the wrong predicates but maybe the GIMPLE side is somewhat disconnected here. Index: gcc/tree-ssa-structalias.c === --- gcc/tree-ssa-structalias.c (revision 235404) +++ gcc/tree-ssa-structalias.c (working copy) @@ -4642,9 +4642,7 @@ find_func_aliases_for_call (struct funct get_constraint_for (lhsop, &lhsc); rhs = get_function_part_constraint (fi, fi_result); - if (fndecl - && DECL_RESULT (fndecl) - && DECL_BY_REFERENCE (DECL_RESULT (fndecl))) + if (aggregate_value_p (lhsop, gimple_call_fntype (t))) { auto_vec tem; tem.quick_push (rhs); @@ -4658,9 +4656,7 @@ find_func_aliases_for_call (struct funct /* If we pass the result decl by reference, honor that. */ if (lhsop - && fndecl - && DECL_RESULT (fndecl) - && DECL_BY_REFERENCE (DECL_RESULT (fndecl))) + && aggregate_value_p (lhsop, gimple_call_fntype (t))) { struct constraint_expr lhs; struct constraint_expr *rhsp; looks correct to me and would also work for indirect calls (though those are probably "safe" because we don't optimize them very well as we think having its address taken makes optimization not possible - sth where IPA PTA needs to be improved).
[Bug ipa/70760] [6/7 regression] wrong generated code for std::make_unique with -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70760 --- Comment #6 from David Abdurachmanov --- Will do, results will be late today or tomorrow.
[Bug bootstrap/70704] [6 Regression] AIX bootstrap comparison failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704 --- Comment #45 from Jakub Jelinek --- I don't think M4 env var should make a difference in this case, in the release tarballs the gengtype-lex.c file is already built (on x86_64-linux) and nothing should be changing that. That said, I've managed to reproduce the miscompare on build/ggc-none.o as an example of very small source file, even with -g0. But it looks really weird. First of all, it seems that the system g++ 4.8 and g++ 6.1-rc2 is probably ABI incompatible, at least my attempts to mix stage1 and stage2 objects into the same binary failed miserably. I've rebuilt stage2-gcc/ cc1plus with CXXFLAGS='-g -O0', thus most if not all *.o files linked into it should be (like in stage1) built without optimizations, and still see the differences. Trying to find out where the differences start now using parallel gdb sessions.
[Bug ipa/70760] [6/7 regression] wrong generated code for std::make_unique with -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70760 --- Comment #5 from rguenther at suse dot de --- On Mon, 25 Apr 2016, david.abdurachmanov at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70760 > > --- Comment #4 from David Abdurachmanov com> --- > I will test the second patch. Will take a few hours (it's millions of lines in > C++). Thanks. Just in case also test the first variant - the second (not sure what unpatched GCC does) runs into a miscompile when LTO bootstrapping with IPA PTA enabled. This all looks a bit fishy (and I failed to create a small testcase even though I tried for half an hour)
[Bug preprocessor/16358] -Wno-system-headers hides warning caused by user header vs system header conflict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16358 --- Comment #11 from niva at niisi dot msk.ru --- (in reply to Martin Sebor in comment #10) Implementation of -Wmacro-redefined (with possibility of turning this warning to error) would solve the problem of our users.
[Bug target/70454] --with-arch=native isn't applied to 32-bit x86 target library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70454 --- Comment #5 from hjl at gcc dot gnu.org --- Author: hjl Date: Mon Apr 25 12:41:43 2016 New Revision: 235411 URL: https://gcc.gnu.org/viewcvs?rev=235411&root=gcc&view=rev Log: Revert the last change in libatomic Need to properly check if -march=i486 is really needed for -m32 build of libatomic on Linux/x86 and Linux/x86-64. PR target/70454 * configure.tgt (XCFLAGS): Revert the last change. Modified: trunk/libatomic/ChangeLog trunk/libatomic/configure.tgt
[Bug ipa/70760] [6/7 regression] wrong generated code for std::make_unique with -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70760 --- Comment #4 from David Abdurachmanov --- I will test the second patch. Will take a few hours (it's millions of lines in C++).
[Bug fortran/70697] ICE on EVENT WAIT with array element UNTIL_COUNT argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70697 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-04-25 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Confirmed from 5.3.1 up to trunk (7.0). 5.3.0 gives the errors pr70697.f90:3:18: type(event_type) done[*] 1 Error: Derived type 'event_type' at (1) is being used before it is defined pr70697.f90:4:2: event wait(done,until_count=nc(1)) 1 Error: Unclassifiable statement at (1)
[Bug ipa/70760] [6/7 regression] wrong generated code for std::make_unique with -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70760 --- Comment #3 from Richard Biener --- Where _1(D) is # PT = struct __single_object & _1(D) = ; This is in a function deemed local (a ISRA specialization) and thus it looks like we think there are no callers. There are indeed callers but to different ISRA specializations. I suppose (again) it is IPA ICF that merges them. There seems to be a disconnect between what versioning does to DECL_RESULT (and DECL_BY_REFERENCE) and what IPA PTA does vs. non-IPA PTA with regard to such results. non-IPA just looks at gimple_call_return_slot_opt_p while IPA only looks at DECL_BY_REFERENCE. Index: gcc/tree-ssa-structalias.c === --- gcc/tree-ssa-structalias.c (revision 235404) +++ gcc/tree-ssa-structalias.c (working copy) @@ -4658,9 +4658,11 @@ find_func_aliases_for_call (struct funct /* If we pass the result decl by reference, honor that. */ if (lhsop - && fndecl - && DECL_RESULT (fndecl) - && DECL_BY_REFERENCE (DECL_RESULT (fndecl))) + && ((fndecl + && DECL_RESULT (fndecl) + && DECL_BY_REFERENCE (DECL_RESULT (fndecl))) + || (gimple_call_return_slot_opt_p (t) + && TREE_ADDRESSABLE (TREE_TYPE (lhsop) { struct constraint_expr lhs; struct constraint_expr *rhsp; fixes that but the following should also work (but is obviously less safe). Index: gcc/tree-ssa-structalias.c === --- gcc/tree-ssa-structalias.c (revision 235404) +++ gcc/tree-ssa-structalias.c (working copy) @@ -4658,9 +4658,8 @@ find_func_aliases_for_call (struct funct /* If we pass the result decl by reference, honor that. */ if (lhsop - && fndecl - && DECL_RESULT (fndecl) - && DECL_BY_REFERENCE (DECL_RESULT (fndecl))) + && gimple_call_return_slot_opt_p (t) + && TREE_ADDRESSABLE (TREE_TYPE (lhsop))) { struct constraint_expr lhs; struct constraint_expr *rhsp; so can you test the latter on your app? I'm giving it IPA PTA + LTO bootstrap testing.
[Bug ipa/70760] [6/7 regression] wrong generated code for std::make_unique with -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70760 --- Comment #2 from Richard Biener --- First DCE after IPA PTA does @@ -18217,7 +9762,6 @@ MEM[(struct ParameterDescription *)_5].D.481734.D.343802._vptr.ParameterDescriptionNode = &MEM[(void *)&_ZTVN3edm20ParameterDescriptionIiEE + 16B]; _18 = *__args#1_7(D); MEM[(struct ParameterDescription *)_5].value_ = _18; - MEM[(struct _Head_base *)_1(D)]._M_head_impl = _5; return _1(D); :
[Bug tree-optimization/70771] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in operator[], at vec.h:714
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70771 --- Comment #3 from amker at gcc dot gnu.org --- Had patch for this and PR70775, will send for review after testing.
[Bug tree-optimization/70780] [6/7 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70780 --- Comment #7 from Richard Biener --- Author: rguenth Date: Mon Apr 25 10:50:46 2016 New Revision: 235408 URL: https://gcc.gnu.org/viewcvs?rev=235408&root=gcc&view=rev Log: 2016-04-25 Richard Biener PR tree-optimization/70780 * tree-ssa-pre.c (compute_antic_aux): Also return true if the block wasn't visited yet. (compute_antic): Mark blocks with abnormal preds as visited as they have a final empty antic-in solution already. * gcc.dg/torture/pr70780.c: New testcase. Added: branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr70780.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/testsuite/ChangeLog branches/gcc-6-branch/gcc/tree-ssa-pre.c
[Bug tree-optimization/70780] [6/7 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70780 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener --- Fixed.
[Bug tree-optimization/70780] [6/7 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70780 --- Comment #5 from Richard Biener --- Author: rguenth Date: Mon Apr 25 10:49:55 2016 New Revision: 235407 URL: https://gcc.gnu.org/viewcvs?rev=235407&root=gcc&view=rev Log: 2016-04-25 Richard Biener PR tree-optimization/70780 * tree-ssa-pre.c (compute_antic_aux): Also return true if the block wasn't visited yet. (compute_antic): Mark blocks with abnormal preds as visited as they have a final empty antic-in solution already. * gcc.dg/torture/pr70780.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr70780.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-pre.c
[Bug middle-end/22141] [4.9/5/6/7 Regression] Missing optimization when storing structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22141 Richard Biener changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #34 from Richard Biener --- *** Bug 70784 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/70784] Merge multiple short stores of immediates into wider stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70784 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Richard Biener --- Dup. Note we already have two passes that can do related transforms. 1) bswap which can detect adjacent loads (that then feed a (non-)bswap sequence to build a larger value) 2) basic-block vectorization (which does not consider (all) non-vector types for BLKmode vectorization) 2) has the additional limitation to only consider same-sized sub-stores so doing this in the general framework of 1) may be easier. Adding a new pass only considering adjacent stores may also be possible. *** This bug has been marked as a duplicate of bug 22141 ***
[Bug rtl-optimization/70784] Merge multiple short stores of immediates into wider stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70784 --- Comment #4 from ktkachov at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #3) > Also note that finding the heuristics when to use this (for -Os it is of > course clearer) is hard, if the pointer is sufficiently aligned or if the > target is strict alignment it is of course easier. And the RTL DSE patch > caused some SPEC regressions on powerpc*. Thanks for pointing me to PR22141. I was hoping to structure this in such a way as to pass down the merged byte sequence to a target hook together with information about the original store+setup sequence and have the target emit the most profitable sequence using any target-specific knowledge and tricks it may have (like prefer two movls isntead of movabsq in your example above). We could provide some helper functions for extracting immediates from the byte vector (like dse_decode_int in your patch or a wrapper around builtin_strncpy_read_str from builtins.c). The default implementation of the hook would be a conservative sequence that emits a sequence of stores up to word_mode in width (avoiding unaligned stores for STRICT_ALIGN or SLOW_UNALIGNED_ACCESS targets), perhaps reusing some store_by_pieces infrastructure. For the heuristics question I've found tracking setup instructions as well as stores to work well. That is, from the original store sequence keep track not only of the store insns but also the instructions that move immediates into the registers to be stored. And the new sequence would be rejected if the total number of stores is not smaller, or if the total store+setup cost is higher than the old store+setup cost. Of course, that would depend on the backend estimating the cost of synthesising immediates, which the aarch64 target (at least) does. I think a gimple implementation of this would suffer from such a drawback, in that it would not know whether the new wider immediates are actually profitable unless it consulted RTX costs, which we wouldn't want at gimple level.
[Bug libstdc++/70767] std::numeric_limits::digits is wrong unless --std=c++11 used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70767 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-04-25 Component|c++ |libstdc++ Target Milestone|--- |7.0 Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- (In reply to Marc Glisse from comment #1) > http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559 > It has status CD1, I don't remember if that means it applies retroactively > or not. LWG is less consistent than CWG about stating which issue resolutions are considered DRs, and so apply retroactively. The libstdc++ policy is to treat most of them as applying retroactively anyway, because that's the most useful approach. Although our current behaviour is correct according to C++98, I see no reason not to define the specializations for cv-qualified types in C++98.
[Bug rtl-optimization/70784] Merge multiple short stores of immediates into wider stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70784 --- Comment #3 from Jakub Jelinek --- Also note that finding the heuristics when to use this (for -Os it is of course clearer) is hard, if the pointer is sufficiently aligned or if the target is strict alignment it is of course easier. And the RTL DSE patch caused some SPEC regressions on powerpc*.
[Bug rtl-optimization/70784] Merge multiple short stores of immediates into wider stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70784 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Please see PR22141 which even had a RTL implementation (in the DSE pass). I think it would be much better handling this (together with bitfields) in some late GIMPLE pass as opposed to RTL pass. And note that using movabsq instead of two movls on x86_64 is very likely a pessimization as opposed to optimization, so one needs to watch the costs too.
[Bug rtl-optimization/70784] Merge multiple short stores of immediates into wider stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70784 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-04-25 Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- I have an idea to implement this at the RTL level by finding consecutive stores of immediates, creating a byte vector resulting from the merged immediate values, and re-emitting it using a new wider (and shorter) sequence.
[Bug rtl-optimization/70784] New: Merge multiple short stores of immediates into wider stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70784 Bug ID: 70784 Summary: Merge multiple short stores of immediates into wider stores Product: gcc Version: unknown Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ktkachov at gcc dot gnu.org CC: ramana at gcc dot gnu.org Target Milestone: --- Consider the code: struct bar { int a; char b; char c; char d; char e; char f; char g; }; // packed 64-bit structure void foozero (struct bar *p) { p->b = 0; p->a = 0; p->c = 0; p->d = 0; p->e = 0; } On aarch64 we currently generate: foozero: str wzr, [x0] strbwzr, [x0, 4] strbwzr, [x0, 5] strbwzr, [x0, 6] strbwzr, [x0, 7] ret But could generate a single 64-bit store: foozero: str xzr, [x0] ret Also, for: void foo (struct bar *p) { p->b = 0; p->a = 0; p->c = 0; p->d = 1; p->e = 0; } we could generate: foo: mov x1, #0x1 str x1, [x0] Other targets could benefit from this too. x86_64 currently generates for 'foo': foo: .LFB0: .cfi_startproc movl$0, (%rdi) movb$0, 4(%rdi) movb$0, 5(%rdi) movb$1, 6(%rdi) movb$0, 7(%rdi) ret but could genereate: foo: .LFB0: .cfi_startproc movabsq $281474976710656, %rax movq%rax, (%rdi) ret
[Bug driver/70783] New: -spec option behavior is different to implicit spec file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70783 Bug ID: 70783 Summary: -spec option behavior is different to implicit spec file Product: gcc Version: 4.8.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: andreas.g.jhoss at gmx dot de Target Milestone: --- Created attachment 38339 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38339&action=edit The failing specs file I can verify that easily on every Linux system with native compiler Anyway I am using a gcc backcross compiler (Linux->Windows-Linux) with one substitute rule. Is this a lack of documentation or a bug ? I put a spec file in /usr/lib/gcc/i686-pc-linux-gnu/4.8.5/specs or wherever the specfile is searched and add a substitute rule (See attached file) But the substitue rule is only recognized if I do the gcc call with option -specs= Working : g++ r:\test.cpp -nojhdefaultlibs -o r:\test -specs=q:/gnuwinh5/bin/../lib/gcc/i686-pc-linux-gnu/4.8.5/ Reading specs from q:/gnuwinh5/bin/../lib/gcc/i686-pc-linux-gnu/4.8.5/specs Reading specs from q:/gnuwinh5/bin/../lib/gcc/i686-pc-linux-gnu/4.8.5/specs COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=q:/gnuwinh5/bin/../libexec/gcc/i686-pc-linux-gnu/4.8.5/lto-wrapper.exe Target: i686-pc-linux-gnu .. Not Working : If am using the implicit specs file with same path but option is not recognized. Reading specs from q:/gnuwinh5/bin/../lib/gcc/i686-pc-linux-gnu/4.8.5/specs COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=q:/gnuwinh5/bin/../libexec/gcc/i686-pc-linux-gnu/4.8.5/lto-wrapper.exe g++: error: unrecognized command line option '-nojhdefaultlibs' Target: i686-pc-linux-gnu .. It doesn't matter what substitute rule I define and also where I define it makes no difference
[Bug tree-optimization/70771] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in operator[], at vec.h:714
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70771 --- Comment #2 from amker at gcc dot gnu.org --- Also like PR70775, this case failed the change allows single argument PHIs in if-cvt now. It looks like there is something wrong when handling single argument PHIs. Before the change, we simple return false in ifcvt_convertible_phi_p and skip if-conversion for such form loops.
[Bug bootstrap/70704] [6 Regression] AIX bootstrap comparison failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704 Michael Haubenwallner changed: What|Removed |Added CC||michael.haubenwallner@ssi-s ||chaefer.com --- Comment #44 from Michael Haubenwallner --- Created attachment 38338 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38338&action=edit FLEX listens to M4 envvar, unset. Does it help to set M4=/opt/freeware/bin/m4 in the environment, so configure is forced to take GNU m4? Once upon a time, I've had similar problems here, although with older gcc, and use attached patch to fix it - maybe it is of some help here as well. Problem is that flex does listen to the M4 environment variable. Dependent on PATH, configure may find AIX m4 (/usr/bin) or GNU m4 (/opt/freeware/bin). When M4=AIX-m4, flex-generated code breaks.
[Bug tree-optimization/70780] [6/7 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70780 --- Comment #4 from Richard Biener --- Ok, so we now find (properly) that *d is loop invariant in while (b) but fail to detect *d as possibly trapping. That is supposed to be prevented (in PRE) by the loop exit but I messed up iteration and thus the solution we use for insertion is not final.
[Bug debug/70764] PASS->FAIL: gcc.dg/guality/pr41447-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70764 --- Comment #3 from Nick Clifton --- Hi Kyrylo, > FAIL: tmp is -1, not 0 > FAIL: tmp2 is -1, not 0 > FAIL: gcc.dg/guality/pr41447-1.c -O2 -flto -fno-use-linker-plugin > -flto-partition=none execution test Would you mind uploading this binary so that I can have a look at it ? > There are optimisation levels where the test passes though. > For example: > PASS: gcc.dg/guality/pr41447-1.c -O2 -flto -fuse-linker-plugin > -fno-fat-lto-objects. Could you upload this one too, so that I can compare it ? > Perhaps we should XFAIL the test for aarch64? Not yet - we need to know why the test is failing for the aarch64. Cheers Nick
[Bug tree-optimization/70777] x*x pessimised to pow(x,2) with -Og -ffast-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70777 --- Comment #4 from rguenther at suse dot de --- On Mon, 25 Apr 2016, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70777 > > Jakub Jelinek changed: > >What|Removed |Added > > CC||jakub at gcc dot gnu.org > > --- Comment #3 from Jakub Jelinek --- > Well, we could also optimize pow (x, 2) to x * x at expansion time. We did in the past but removed that "feature". We could also canonicalize to POWI instead (not losing the fact x * x didn't set errno, etc.).
[Bug tree-optimization/70780] [6/7 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70780 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- Will have a look.
[Bug tree-optimization/70777] x*x pessimised to pow(x,2) with -Og -ffast-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70777 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Well, we could also optimize pow (x, 2) to x * x at expansion time.
[Bug c/70779] -trapv does not generate trapping vode for integer conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70779 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Richard Biener --- conversions from unsigned to signed are not undefined but implementation defined and not covered by -ftrapv. Instead GCC documents its implementation defined behavior as modulo-2 reduction.
[Bug c++/70778] internal compiler error: in tsubst, at cp/pt.c:12158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70778 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-04-25 Ever confirmed|0 |1 Known to fail||4.8.5, 7.0 --- Comment #2 from Richard Biener --- Confirmed on trunk.
[Bug tree-optimization/70777] x*x pessimised to pow(x,2) with -Og -ffast-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70777 Richard Biener 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 --- Mine. We should remove the canonicalization done in fold as reassoc does it now (and better). Probably not going to be fixed for older releases (though we could gate the transform appropriately).
[Bug c++/70776] [4.9/5/6/7 Regression] ICE on invalid code on x86_64-linux-gnu: Segmentation fault (program cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70776 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2016-04-25 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Confirmed. Infinite recursion via #0 0x00b0051e in ggc_internal_alloc ( size=, f=, s=, n=) at /space/rguenther/src/svn/trunk/gcc/ggc-page.c:1267 #1 0x00d3e569 in ggc_internal_cleared_alloc (size=40, f=0x0, s=0, n=1) at /space/rguenther/src/svn/trunk/gcc/ggc-common.c:116 #2 0x013e9456 in ggc_internal_cleared_alloc (s=40) at /space/rguenther/src/svn/trunk/gcc/ggc.h:148 #3 0x013e948a in ggc_alloc_cleared_tree_node_stat (s=40) at /space/rguenther/src/svn/trunk/gcc/ggc.h:292 #4 0x013ef8c2 in make_tree_vec_stat (len=2) at /space/rguenther/src/svn/trunk/gcc/tree.c:2281 #5 0x0081467f in coerce_template_parms ( parms=, args=, in_decl=, complain=0, require_all_args=true, use_default_args=true) at /space/rguenther/src/svn/trunk/gcc/cp/pt.c:7594 #6 0x008151a1 in coerce_innermost_template_parms ( parms=, args=, in_decl=, complain=0, require_all_args=true, use_default_args=true) at /space/rguenther/src/svn/trunk/gcc/cp/pt.c:7820 #7 0x00817ceb in lookup_template_class_1 ( d1=, arglist=, in_decl=, context=, entering_scope=0, complain=0) at /space/rguenther/src/svn/trunk/gcc/cp/pt.c:8297 #8 0x0081ae6b in lookup_template_class ( d1=, arglist=, in_decl=, context=, entering_scope=0, complain=0) at /space/rguenther/src/svn/trunk/gcc/cp/pt.c:8638 #9 0x008274a3 in tsubst_aggr_type (t=, args=, complain=0, in_decl=, entering_scope=0) at /space/rguenther/src/svn/trunk/gcc/cp/pt.c:11425 #10 0x0082fe5d in tsubst (t=, args=, complain=0, in_decl=) at /space/rguenther/src/svn/trunk/gcc/cp/pt.c:12895 #11 0x00833e7d in tsubst_qualified_id ( qualified_id=, args=, complain=0, in_decl=, done=true, address_p=false) at /space/rguenther/src/svn/trunk/gcc/cp/pt.c:13734 ... Clang detects: > clang++ -S t.ii t.ii:6:34: fatal error: recursive template instantiation exceeded maximum depth of 256 Not sure if the testcase is thus invalid (but we should diagnose it instead of crashing).
[Bug tree-optimization/70775] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70775 Richard Biener changed: What|Removed |Added Priority|P3 |P1 CC||amker at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Probably a latent issue.
[Bug middle-end/70773] Profiling makes sudoku solver slower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70773 --- Comment #4 from Richard Biener --- It possibly does value profiling figuring out a common division/modulo value and then making all other values unlikely (and thus cold).
[Bug c/70772] Wrong warning about unspecified behavior for comparison with string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70772 Richard Biener changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2016-04-25 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Confirmed.
[Bug tree-optimization/70771] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in operator[], at vec.h:714
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70771 Richard Biener changed: What|Removed |Added Priority|P3 |P1 CC||amker at gcc dot gnu.org
[Bug c++/70768] [6/7 Regression] Increased compilation time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70768 Richard Biener changed: What|Removed |Added Keywords||compile-time-hog, ||memory-hog Status|RESOLVED|REOPENED Last reconfirmed||2016-04-25 Resolution|INVALID |--- Target Milestone|--- |6.2 Summary|Increased compilation time |[6/7 Regression] Increased ||compilation time Ever confirmed|0 |1 --- Comment #5 from Richard Biener --- I think this kind of memory usage increase is a bug.
[Bug target/70763] Use SSE for DImode load/store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70763 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement
[Bug tree-optimization/70780] [6/7 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70780 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 --- Comment #2 from Jakub Jelinek --- Seems starting with that revision we hoist *d before the loop (which would be ok only if it is guarded by if (b), as if b is false, it is completely valid that d is NULL or uninitialized etc. and causes trap). Richard, can you please have a look?
[Bug c++/70781] [6/7 Regression] ICE on invalid C++ code with lambda expressions on x86_64-linux-gnu in finish_expr_stmt, at cp/semantics.c:677
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70781 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-04-25 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |6.0 Summary|ICE on invalid C++ code |[6/7 Regression] ICE on |with lambda expressions on |invalid C++ code with |x86_64-linux-gnu in |lambda expressions on |finish_expr_stmt, at|x86_64-linux-gnu in |cp/semantics.c:677 |finish_expr_stmt, at ||cp/semantics.c:677 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r233183.
[Bug tree-optimization/70780] [6/7 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70780 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-04-25 CC||jakub at gcc dot gnu.org Target Milestone|--- |6.0 Summary|wrong code at -O2 and -O3 |[6/7 Regression] wrong code |on x86_64-linux-gnu |at -O2 and -O3 on ||x86_64-linux-gnu Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r234970.