[Bug rtl-optimization/81423] [6/7/8 Regression] Wrong code at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81423 --- Comment #6 from Uroš Bizjak --- (In reply to Segher Boessenkool from comment #5) > There are a few issues here. > > 1) I cannot reproduce it: a trunk x86_64-linux compiler stores to > memory in that insn 20 (the testcase from comment 3). Just re-checked with todays SVN. There are two (insn 20) RTXes; one in the function itself, the second one (the problematic one) in the inlined copy in the main function.
[Bug tree-optimization/81418] [8 Regression] ICE in vect_get_vec_def_for_stmt_copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81418 --- Comment #3 from Richard Biener --- Hrm. So whenever a reducing pattern is exercised in the reduction "chain" we cannot handle regular uses of the PHI as we basically have to force a single_defuse_cycle. So we can't vectorize this case but we fail to reject it.
[Bug tree-optimization/81162] [8 Regression] UBSAN switch triggers incorrect optimization in SLSR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81162 --- Comment #11 from rguenther at suse dot de --- On Mon, 17 Jul 2017, bernd.edlinger at hotmail dot de wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81162 > > Bernd Edlinger changed: > >What|Removed |Added > > CC||bernd.edlinger at hotmail > dot de > > --- Comment #10 from Bernd Edlinger --- > The test case don't run if gcc-4.6 is host compiler, > this means it links against the host compiler libubsan.so.0 > which is not really the correct thing to do: > > Setting LD_LIBRARY_PATH to > :/home/ed/gnu/gcc-build/gcc:/home/ed/gnu/gcc-build/gcc/32:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/./libatomic/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/./libcilkrts/.libs::/home/ed/gnu/gcc-build/gcc:/home/ed/gnu/gcc-build/gcc/32:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/./libatomic/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/./libcilkrts/.libs:/home/ed/gnu/gcc-build/./gmp/.libs:/home/ed/gnu/gcc-build/./prev-gmp/.libs:/home/ed/gnu/gcc-build/./mpfr/src/.libs:/home/ed/gnu/gcc-build/./prev-mpfr/src/.libs:/home/ed/gnu/gcc-build/./mpc/src/.libs:/home/ed/gnu/gcc-build/./prev-mpc/src/.libs:/home/ed/gnu/gcc-build/./isl/.libs:/home/ed/gnu/gcc-build/./prev-isl/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libsanitizer/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libmpx/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libvtv/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libcilkrts/.libs:/home/ed/gnu/gcc -build/x86_64-pc-linux-gnu/libssp/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libgomp/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libitm/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libatomic/.libs:/home/ed/gnu/gcc-build/./gcc:/home/ed/gnu/gcc-build/./prev-gcc:/home/ed/gnu/gcc-build/./gmp/.libs:/home/ed/gnu/gcc-build/./prev-gmp/.libs:/home/ed/gnu/gcc-build/./mpfr/src/.libs:/home/ed/gnu/gcc-build/./prev-mpfr/src/.libs:/home/ed/gnu/gcc-build/./mpc/src/.libs:/home/ed/gnu/gcc-build/./prev-mpc/src/.libs:/home/ed/gnu/gcc-build/./isl/.libs:/home/ed/gnu/gcc-build/./prev-isl/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libsanitizer/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libmpx/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libvtv/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libcilkrts/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libssp/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libgo mp/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libitm/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libatomic/.libs:/home/ed/gnu/gcc-build/./gcc:/home/ed/gnu/gcc-build/./prev-gcc > spawn [open ...]^M > ./pr81162.exe: error while loading shared libraries: libubsan.so.0: cannot > open > shared object file: No such file or directory > FAIL: gcc.dg/pr81162.c execution test You need to move it to ubsan/
[Bug middle-end/81443] gcc-7.1.0/MIPS N32: build/genrecog.o: virtual memory exhausted: Cannot allocate memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81443 --- Comment #2 from Joshua Kinard --- (In reply to Richard Biener from comment #1) > What file is it compiling? As far as I can tell, it looks somewhat random. I initially thought that 'build/genrecog.o' was a single file, but after several re-runs, I noticed there's several files getting compiled that must get merged into genrecog.o. I was running a parallel build, too, though (only -j3, 2x SMP machine), so I could have been seeing the other parallel thread(s) running. I've restarted the builod where it stopped using -j1. It takes about an hour to get back to where it will stop. I'll report what that file is, and then launch it again and see if it stays consistent.
[Bug tree-optimization/81162] [8 Regression] UBSAN switch triggers incorrect optimization in SLSR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81162 --- Comment #12 from Bill Schmidt --- Right, sorry about the ubsan dependency screwup. I'll move the test case later today.
[Bug middle-end/81441] slowdown due to -fpeel-loops and -ftracer added by -fprofile-use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81441 Joost VandeVondele changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #2 from Joost VandeVondele --- No, this is profile-use after a profile-generate, so standard PGO setup. The profile-generate is using the same benchmark for generation, so coverage should be good.
[Bug tree-optimization/81354] [5/6 Regression] Segmentation fault in SSA Strength Reduction using -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81354 Bill Schmidt changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot gnu.org --- Comment #4 from Bill Schmidt --- Yes, mine.
[Bug middle-end/28859] GCC calls malloc from within signal context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28859 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-07-17 Ever confirmed|0 |1 --- Comment #5 from Martin Liška --- Do I understand it that practically impossible to handle that as we would have to somehow detect all malloc-family functions triggered after a crash_signal is executed? In case of PR81382 we either need to have layout class not containing of types that can possibly allocate a memory via malloc, or we can have an env variable that will prevent displaying of locations if crash_signal happened? Would it be welcomed one of there approaches?
[Bug libstdc++/79162] [7 Regression] [C++17] ambiguity in string assignment due to string_view overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79162 Jonathan Wakely changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #15 from Jonathan Wakely --- Thanks, Daniel. Let's reopen this to make the T -> const T& changes.
[Bug middle-end/28859] GCC calls malloc from within signal context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28859 --- Comment #6 from rguenther at suse dot de --- On Mon, 17 Jul 2017, marxin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28859 > > Martin Liška changed: > >What|Removed |Added > > Status|UNCONFIRMED |NEW >Last reconfirmed||2017-07-17 > Ever confirmed|0 |1 > > --- Comment #5 from Martin Liška --- > Do I understand it that practically impossible to handle that as we would have > to somehow detect all malloc-family functions triggered after a crash_signal > is > executed? > > In case of PR81382 we either need to have layout class not containing of types > that can possibly allocate a memory via malloc, or we can have an env variable > that will prevent displaying of locations if crash_signal happened? Would it > be > welcomed one of there approaches? I think it's just not possible to easily do sth here, so we shouldn't care too much IMHO.
[Bug sanitizer/63361] Test case c-c++-common/ubsan/float-cast-overflow-1.c fails on Pentium2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63361
Martin Liška changed:
What|Removed |Added
Status|WAITING |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
--- Comment #9 from Martin Liška ---
Nice, confirmed. There's minimal reproducer:
cat float-cast-overflow-1.i
int
main (void)
{
volatile double d;
volatile long long ll;
d = 0.0;
d = 0x7fffLL;
(ll) = (d) -5.0;
return 0;
}
I'll take a look. Thanks.
[Bug middle-end/28859] GCC calls malloc from within signal context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28859 --- Comment #7 from Martin Liška --- Yep, let's forget about it ;)
[Bug sanitizer/63361] Test case c-c++-common/ubsan/float-cast-overflow-1.c fails on Pentium2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63361 --- Comment #10 from Martin Liška --- It's a typical x87 code, where registers have better precision that a double. Thus adding -ffloat-store fixed the test-case, I'll send a patch.
[Bug sanitizer/63361] Test case c-c++-common/ubsan/float-cast-overflow-1.c fails on Pentium2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63361 --- Comment #11 from Martin Liška --- Created attachment 41771 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41771&action=edit Patch candidate Can you please test the attached patch on Pentium 2 machine?
[Bug c/6906] warn about asserts with side effects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6906 felix changed: What|Removed |Added CC||felix.von.s at posteo dot de --- Comment #7 from felix --- What's wrong with the __builtin_pure_p approach? Sure, the diagnostics generated by __attribute__((warning)) will be ugly, but it's still something. It's also very simple to implement: it's just !TREE_SIDE_EFFECTS(). In fact, I patched my copy of GCC to add __builtin_pure_p defined just like that and it seems to work fine. Might submit it soon (I didn't write any tests, though).
[Bug sanitizer/63361] Test case c-c++-common/ubsan/float-cast-overflow-1.c fails on Pentium2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63361 --- Comment #12 from Jakub Jelinek --- Comment on attachment 41771 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41771 Patch candidate I don't think we want to add -ffloat-store unconditionally, only for targets that really need it.
[Bug tree-optimization/81461] Optimization for removing same variable comparisons in loop: while(it != end1 && it != end2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81461
--- Comment #2 from Antony Polukhin ---
(In reply to Richard Biener from comment #1)
> jump threading
Thanks, now I know hot the transformation of
for (;it != end && it != *chunks + 128; ++it) {
sum += *it;
}
into
new_end = (it <= end && end <= *chunks + 128 ? end : *chunks + 128);
for (;new_end; ++it) {
sum += *it;
}
is called!
Loop unswitching will also do the job, but it produces a ~5 instructions longer
assembly because of the loop's body duplication:
if (it <= end && end <= *chunks + 128) {
for (;it != end;
++it) { sum += *it; } // duplicated
} else {
for (;it != *chunks + 128;
++it) { sum += *it; } // duplicated
}
[Bug c/6906] warn about asserts with side effects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6906 --- Comment #8 from owner at bugs dot debian.org --- Thank you for the additional information you have supplied regarding this Bug report. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Debian GCC Maintainers If you wish to submit further information on this problem, please send it to 123...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system.
[Bug sanitizer/63361] Test case c-c++-common/ubsan/float-cast-overflow-1.c fails on Pentium2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63361 --- Comment #13 from Martin Liška --- (In reply to Jakub Jelinek from comment #12) > Comment on attachment 41771 [details] > Patch candidate > > I don't think we want to add -ffloat-store unconditionally, only for targets > that really need it. Ok, thus can you please help me how to do a condition of affected x87 CPUs?
[Bug middle-end/70140] Inefficient expansion of __builtin_mempcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70140 --- Comment #6 from Martin Liška --- Created attachment 41772 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41772&action=edit Patch candidate I'm going to prepare some test-cases for that. Does it look good?
[Bug tree-optimization/81462] [8 Regression] ICE in estimate_bb_frequencies at gcc/predict.c:3546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81462 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #1 from Jan Hubicka --- Created attachment 41773 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41773&action=edit Patch I am testing.
[Bug target/81466] New: [SH]: Error: syntax error in @(disp,[Rn, gbr, pc]) when building with -mlra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81466 Bug ID: 81466 Summary: [SH]: Error: syntax error in @(disp,[Rn, gbr, pc]) when building with -mlra Product: gcc Version: 7.1.0 URL: https://people.debian.org/~glaubitz/webkit2gtk_2.16.5- 1-mlra_sh4.build Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: glaubitz at physik dot fu-berlin.de Target Milestone: --- Target: sh*-*-* Created attachment 41774 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41774&action=edit Intermediate source for MapPrototype.cpp (gzipped) After running into #81426 when trying to build webkit2gtk on Debian sh4 unstable, I tried building with "-mlra". While this actually fixed #81246, another issue was exposed that only shows when using "-mlra": [ 21%] Building CXX object Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/runtime/MapPrototype.cpp.o cd /<>/obj-sh4-linux-gnu/Source/JavaScriptCore && /usr/bin/c++ -DBUILDING_GTK__=1 -DBUILDING_JavaScriptCore -DBUILDING_WITH_CMAKE=1 -DDATA_DIR=\"share\" -DGETTEXT_PACKAGE=\"WebKit2GTK-4.0\" -DHAVE_CONFIG_H=1 -DJavaScriptCore_EXPORTS -DLIBDIR=\"/usr/lib/sh4-linux-gnu\" -DSTATICALLY_LINKED_WITH_WTF -DUSER_AGENT_GTK_MAJOR_VERSION=\"604\" -DUSER_AGENT_GTK_MINOR_VERSION=\"1\" -DWEBKITGTK_API_VERSION_STRING=\"4.0\" -isystem /usr/include/glib-2.0 -isystem /usr/lib/sh4-linux-gnu/glib-2.0/include -I/<>/obj-sh4-linux-gnu -I/<>/Source/JavaScriptCore -I/<>/Source/JavaScriptCore/.. -I/<>/Source/JavaScriptCore/API -I/<>/Source/JavaScriptCore/ForwardingHeaders -I/<>/Source/JavaScriptCore/assembler -I/<>/Source/JavaScriptCore/b3 -I/<>/Source/JavaScriptCore/b3/air -I/<>/Source/JavaScriptCore/bindings -I/<>/Source/JavaScriptCore/builtins -I/<>/Source/JavaScriptCore/bytecode -I/<>/Source/JavaScriptCore/bytecompiler -I/<>/Source/JavaScriptCore/dfg -I/<>/Source/JavaScriptCore/disassembler -I/<>/Source/JavaScriptCore/disassembler/udis86 -I/<>/Source/JavaScriptCore/disassembler/ARM64 -I/<>/Source/JavaScriptCore/domjit -I/<>/Source/JavaScriptCore/ftl -I/<>/Source/JavaScriptCore/heap -I/<>/Source/JavaScriptCore/debugger -I/<>/Source/JavaScriptCore/inspector -I/<>/Source/JavaScriptCore/inspector/agents -I/<>/Source/JavaScriptCore/inspector/augmentable -I/<>/Source/JavaScriptCore/inspector/remote -I/<>/Source/JavaScriptCore/interpreter -I/<>/Source/JavaScriptCore/jit -I/<>/Source/JavaScriptCore/llint -I/<>/Source/JavaScriptCore/parser -I/<>/Source/JavaScriptCore/profiler -I/<>/Source/JavaScriptCore/replay -I/<>/Source/JavaScriptCore/runtime -I/<>/Source/JavaScriptCore/tools -I/<>/Source/JavaScriptCore/wasm -I/<>/Source/JavaScriptCore/wasm/js -I/<>/Source/JavaScriptCore/yarr -I/<>/obj-sh4-linux-gnu/DerivedSources/ForwardingHeaders -I/<>/obj-sh4-linux-gnu/DerivedSources/JavaScriptCore -I/<>/obj-sh4-linux-gnu/DerivedSources/JavaScriptCore/inspector -I/<>/Source/bmalloc -I/<>/Source/WTF -I/<>/obj-sh4-linux-gnu/DerivedSources -I/<>/Source/ThirdParty -g1 -O2 -fdebug-prefix-map=/<>=. -specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -mlra -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -DENABLE_ASSEMBLER=0 -DNDEBUG -DG_DISABLE_CAST_CHECKS -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -DENABLE_ASSEMBLER=0 -DNDEBUG -DG_DISABLE_CAST_CHECKS -fno-exceptions -fno-strict-aliasing -fno-rtti -std=c++1y -fPIC -Wall -Wextra -Wcast-align -Wformat-security -Wmissing-format-attribute -Wpointer-arith -Wundef -Wwrite-strings -o CMakeFiles/JavaScriptCore.dir/runtime/MapPrototype.cpp.o -c /<>/Source/JavaScriptCore/runtime/MapPrototype.cpp (...) /tmp/cck5XKuE.s: Assembler messages: /tmp/cck5XKuE.s:3780: Error: syntax error in @(disp,[Rn, gbr, pc]) /tmp/cck5XKuE.s:3780: Error: invalid operands for opcode /tmp/cck5XKuE.s:3787: Error: syntax error in @(disp,[Rn, gbr, pc]) /tmp/cck5XKuE.s:3787: Error: invalid operands for opcode Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/build.make:18583: recipe for target 'Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/runtime/MapPrototype.cpp.o' failed make[3]: *** [Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/runtime/MapPrototype.cpp.o] Error 1 Dropping "-mlra" from the command line above fixes the issue. Full log in [1]. Attaching the output from running with "-save-temps". > [1] https://people.debian.org/~glaubitz/webkit2gtk_2.16.5-1-mlra_sh4.build
[Bug sanitizer/63361] Test case c-c++-common/ubsan/float-cast-overflow-1.c fails on Pentium2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63361 --- Comment #14 from Jakub Jelinek --- grep FLT_EVAL_METHOD config/*/* says the only problematic arches are i?86, s390*, m68k*, arm and maybe aarch64. add-ieee-options has just i?86 and m68k (clearly wrong, because it really should not use [istarget i?86-*-*] but [check_effective_target_ia32] ieee.exp seems to do that properly. So, I think you should add -ffloat-store if ia32, or if m68k-*-*, and add -mieee if alpha* or sh*.
[Bug target/81466] [SH]: Error: syntax error in @(disp,[Rn, gbr, pc]) when building with -mlra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81466 --- Comment #1 from John Paul Adrian Glaubitz --- Created attachment 41775 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41775&action=edit Generated assembly for MapPrototype.cpp (gzipped)
[Bug target/81426] [SH]: unable to find a register to spill in class 'R0_REGS' when building webkit2gtk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81426 --- Comment #6 from John Paul Adrian Glaubitz --- (In reply to Oleg Endo from comment #5) > This sounds like a different issue. Can you please create another PR for > that with the title "syntax error in @(disp,[Rn, gbr, pc]) when compiling > with -mlra" and attach the reproducer? Done: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81466 Dropping "-mlra" from the command line fixes the issue.
[Bug middle-end/70992] Infinite recursion between fold_build2_stat_loc and fold_binary_loc w/ -fwrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70992 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #5 from Marek Polacek --- I can confirm that even Comment 4 is the same extract_muldiv_1 <-> fold_plusminus_mult_expr issue: ((2147483648 / 0) * 2) + 2 <-> 2 * (2147483648 / 0 + 1) So the question is: where should we break the tie?
[Bug gcov-profile/81442] error: verify_flow_info: REG_BR_PROB is set but cfg probability is not during RTL pass: outof_cfglayout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81442 cesar at gcc dot gnu.org changed: What|Removed |Added CC||cesar at gcc dot gnu.org --- Comment #4 from cesar at gcc dot gnu.org --- I posted a patch that fixes this issue on July 13, 2017: https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00750.html It is pending review.
[Bug middle-end/81443] gcc-7.1.0/MIPS N32: build/genrecog.o: virtual memory exhausted: Cannot allocate memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81443 --- Comment #3 from Joshua Kinard --- It's just build/genrecog.c. I had a stale build environment file that was still sending "-j3" to 'make'. I fixed that and restarted from where it last left off, and it gets to genrecog.c and spent about ~20 minutes doing something to that file before exhausting all virtual memory (so it claims). Here's the last 'ps' output I got right before it stopped: # ps uw 7054 | grep [g]enrecog portage 7054 99.5 47.0 2056256 979712 pts/1 R+ 09:36 20:57 /var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/build/./prev-gcc/cc1plus -quiet -nostdinc++ -I . -I build -I /var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/gcc-7.1.0/gcc -I /var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/gcc-7.1.0/gcc/build -I /var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/gcc-7.1.0/gcc/../include -I /var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/gcc-7.1.0/gcc/../libcpp/include -iprefix /var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/build/prev-gcc/../../../lib/gcc/mips64-unknown-linux-gnu/7.1.0/ -isystem /var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/build/./prev-gcc/include -isystem /var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/build/./prev-gcc/include-fixed -D_GNU_SOURCE -D IN_GCC -D HAVE_CONFIG_H -D GENERATOR_FILE -isystem /var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/build/prev-mips64-unknown-linux-gnu/libstdc++-v3/include/mips64-unknown-linux-gnu -isystem /var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/build/prev-mips64-unknown-linux-gnu/libstdc++-v3/include -isystem /var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/gcc-7.1.0/libstdc++-v3/libsupc++ /var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/gcc-7.1.0/gcc/genrecog.c -meb -quiet -dumpbase genrecog.c -march=mips3 -mtune=mips3 -mplt -mabi=n32 -mllsc -mips3 -mno-shared -auxbase-strip build/genrecog.o -gtoggle -O2 -Wextra -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wsuggest-attribute=format -Woverloaded-virtual -Wpedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -fno-PIE -o - This particular MIPS machine, an old Silicon Graphics platform, has memory issues in the kernel (limited to 2GB of main memory because of what I think is a hardware quirk I haven't figured out how to work around yet), but this is the first time I've ever seen it run out of virtual memory compiling something in the last 10 years. It just recently completed gcc-6.3.0 across multiple ISAs and ABIs about a week ago (it's a build machine), and also did gcc-7.1.0 in O32 under glibc and uclibc-ng. So this is why I suspect there is something wrong with the MIPS-III/N32 case. I have not tried MIPS-IV yet (the machine only supports the older four MIPS ISAs). I do not have a bootstrapped N32 userland under a different libc other than glibc. I also lack a pure N64 userland to test with as well. The CPU is ~600MHz with 2MB of L2 cache, so I find that it spending 20+ minutes on one C file to be rather abnormal, and I think there's a runawaysomethinggoing on (linked list allocation or such?). If there's something else I can grab with gdb or forcing a coredump, let me know what commands to run.
[Bug c/46742] -Wparentheses unexpectedly misses some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46742 --- Comment #4 from Franz Sirl --- APPEARS_TO_BE_BOOLEAN_EXPR_P was introduced with r141340 (PR 7543), but I cannot find a discussion on why this suppression makes sense. When I disable it I only see 3 places where it triggers in trunk: gcc/cp/lex.c:115:24: warning: suggest parentheses around operand of '!' or change '&' to '&&' or '!' to '~' [-Wparentheses] libdecnumber/decNumber.c:6036:11: warning: suggest parentheses around operand of '!' or change '&' to '&&' or '!' to '~' [-Wparentheses] libgcc/libgcc2.c:1949:36: warning: suggest parentheses around operand of '!' or change '&' to '&&' or '!' to '~' [-Wparentheses] To my eyes in all 3 cases a '&&' would be clearer, so the warning shouldn't be suppressed? If changing the behaviour of -Wparentheses after this long time is considered a problem, maybe we could add the stricter check to the relatively new -Wlogical-not-parentheses like clang? Note: clang documents -Wlogical-not-parentheses for comparison AND bitwise operators, GCC only for comparison operators.
[Bug middle-end/70992] Infinite recursion between fold_build2_stat_loc and fold_binary_loc w/ -fwrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70992 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #6 from Alexander Monakov --- We can simply fold A / 0 * B and A / 0 + B to 1 / 0 or 0 / 0. I wonder why fold_plusminus_mult_expr puts the addition inside, that doesn't appear useful?
[Bug tree-optimization/81462] [8 Regression] ICE in estimate_bb_frequencies at gcc/predict.c:3546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81462 Markus Trippelsdorf changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #2 from Markus Trippelsdorf --- Looks like a dup of PR81318.
[Bug c/81453] relational expression involving null pointer not diagnosed with -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81453 Eric Gallager changed: What|Removed |Added CC||egall at gwmail dot gwu.edu --- Comment #1 from Eric Gallager --- Related: bug 7651
[Bug tree-optimization/81403] [8 Regression] wrong code at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81403
--- Comment #5 from Richard Biener ---
So this is during partial-PRE insertion where after PRE insertion of
Found partial redundancy for expression {bit_not_expr,_13} (0020)
Inserted _33 = ~_3;
in predecessor 5 (0014)
Created phi prephitmp_34 = PHI <_33(5), _8(6)>
in block 7 (0020)
we value-replace 0020 by prephitmp_34 and thus during partial-PRE
phi-translation
find, when translating _14 & 10393, _8 for _14 (0020) to be translated across
the edge exposing the range.
On the other edge we get from translating _14 & 10393 all the way to
translating
var_9.5_12 = var_9 as operand which leads us to var_9.1_2 = var_9 and
ultimatively
to _8 via "simplification" of ~_3 which has a leader of _33 (fine IMHO), but
unfortunately _33 has a value number of _8.
So PRE doing any insertion of a lexically equivalent expression will
necessarily
end up with a SCCVN value-number that might have range info that is not valid
there. Thus:
tree result = vn_nary_op_lookup_pieces (newnary->length,
newnary->opcode,
newnary->type,
&newnary->op[0],
&nary);
if (result && is_gimple_min_invariant (result))
return get_or_alloc_expr_for_constant (result);
expr = pre_expr_pool.allocate ();
expr->kind = NARY;
expr->id = 0;
if (nary)
{
PRE_EXPR_NARY (expr) = nary;
new_val_id = nary->value_id;
get_or_alloc_expression_id (expr);
}
needs adjustment to push away range-info.
[Bug tree-optimization/81403] [8 Regression] wrong code at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81403 --- Comment #6 from Richard Biener --- Kind-of a duplicate of PR80620 as well. Testing a patch.
[Bug gcov-profile/81442] error: verify_flow_info: REG_BR_PROB is set but cfg probability is not during RTL pass: outof_cfglayout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81442 --- Comment #5 from Tom de Vries --- (In reply to cesar from comment #4) > I posted a patch that fixes this issue on July 13, 2017: > > https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00750.html > > It is pending review. Assuming this is indeed the same issue (which is not easy to verify on the spot because the link you posted does not mention a specific ICE it's trying to fix, nor does it reference a PR where the problem is shown in more detail), the patches handle the issue in different ways: - handle the case that there's an edge with uninitialized probability - initialize probability on some edges At first glance I'd say that one doesn't necessarily exclude the other.
[Bug c/46742] -Wparentheses unexpectedly misses some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46742 --- Comment #5 from Franz Sirl --- Actually, after seeing a large bunch of justified warnings in our codebase with the disabled APPEARS_TO_BE_BOOLEAN_EXPR_P check, I wonder if a new option like -Wbool-bitwise-parentheses (thus not depending on the logical NOT) would make sense? Note that this is heavily influenced by my code reading/code debugging POV, I really hate it if I need lots of context to decide whether a statement in a codebase unknown to me is correct or not. A warning like -Wbool-bitwise-parentheses encourages programmers to make their intention clear from the start. Or, in the best case, even uncovers coding bugs or typos early.
[Bug middle-end/81464] [8 Regression] ICE in expand_omp_for_static_chunk, at omp-expand.c:4236
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81464 --- Comment #3 from Tom de Vries --- Minimal example: ... program main implicit none real, dimension(:,:),allocatable :: a, b, c real :: sm allocate (a(2,2), b(2,2), c(2,2)) call random_number(a) call random_number(b) c = matmul(a,b) sm = sum(c) deallocate(a,b,c) end program main ... The assert happens in expand_omp_for_static_chunk when trying to expand a region from bb71 to bb72: ... (gdb) p region.entry.index $1 = 71 (gdb) p region.exit.index $2 = 72 ... In other words: ... ;; basic block 71, loop depth 0, freq 48, maybe hot ;;prev block 69, next block 67, flags: (NEW) ;;pred: 69 [always] (FALLTHRU) #pragma omp for schedule(static,2) for (ivtmp_87 = 0; ivtmp_87 < _144; ivtmp_87 = + 1) ;;succ: 67 [always] (FALLTHRU) ;;72 [never (guessed)] ... ;; basic block 72, loop depth 0, freq 47, maybe hot ;; Invalid sum of incoming frequencies 269, should be 47 ;;prev block 63, next block 70, flags: (NEW) ;;pred: 46 [always] (FALLTHRU) ;;71 [never (guessed)] # .MEM_88 = PHI <.MEM_86(46), .MEM_86(71)> #pragma omp return(nowait) ;;succ: 70 [always] (FALLTHRU) ... When we're ICE-ing, we're executing a bit: ... /* When we redirect the edge from trip_update_bb to iter_part_bb, we remove arguments of the phi nodes in fin_bb. We need to create appropriate phi nodes in iter_part_bb instead. */ ... When we look at fin_bb, we see indeed that one of the arguments of the phi has been dropped.: ... (gdb) call debug_bb (fin_bb) ;; basic block 72, loop depth 0, freq 47, maybe hot ;; prev block 100, next block 70, flags: (NEW) ;; pred: 98 [never (guessed)] (FALSE_VALUE) # .MEM_88 = PHI <.MEM_86(98)> ;; succ: 70 [always] (FALLTHRU) ... But since the arguments were equal anyway, this is fine, and there's no need to do anything. Tentative patch: ... diff --git a/gcc/omp-expand.c b/gcc/omp-expand.c index 929c530..089bffc 100644 --- a/gcc/omp-expand.c +++ b/gcc/omp-expand.c @@ -4206,6 +4206,10 @@ expand_omp_for_static_chunk (struct omp_region *region, source_location locus; phi = psi.phi (); + if (operand_equal_p (gimple_phi_arg_def (phi, 0), + gimple_phi_arg_def (phi, 1), 0)) + continue; + t = gimple_phi_result (phi); gcc_assert (t == redirect_edge_var_map_result (vm)); ...
[Bug preprocessor/71681] header.gcc file lookup is broken for -remap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71681 Andris Pavenis changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Andris Pavenis --- Fix is committed. Closing
[Bug middle-end/70140] Inefficient expansion of __builtin_mempcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70140
--- Comment #7 from Wilco ---
(In reply to Martin Liška from comment #6)
> Created attachment 41772 [details]
> Patch candidate
>
> I'm going to prepare some test-cases for that. Does it look good?
Yes, it now inlines small constant sizes. However large and variable sized
copies have the wrong return value:
void *f1(void *p, void *q) { return __builtin_mempcpy(p, q, 256); }
f1:
mov x2, 256
b memcpy
[Bug other/52992] Incorrect sprintf format in fixincludes/fixincl.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52992 Andris Pavenis changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||andris at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |andris at gcc dot gnu.org --- Comment #1 from Andris Pavenis --- Fixed by r186759 soon after submitting of the bug [andris@localhost gcc]$ svn propget --revprop -r 186759 svn:log 2012-04-24 Tristan Gingold * fixincl.c (fix_with_system): Add missing specifier. * configure.ac: Default to twoprocess on vms. * configure: Regenerate. (Old bug cleanup)
[Bug target/81456] [7/8 Regression] x86-64 optimizer makes wrong decision when optimizing for size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81456
--- Comment #2 from James Greenhalgh ---
(In reply to Martin Liška from comment #1)
> Confirmed, started with r238594.
The cost model relies on the target giving a reasonable approximation for an
instruction size through ix86_rtx_costs.
The basic branch structure looks like:
t = mod
if (a / b % 2)
t = b - mod
In RTL, this looks like:
(insn 14 13 15 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 99)
(const_int 0 [0]))) "foo.c":5 3 {*cmpsi_ccno_1}
(expr_list:REG_DEAD (reg:SI 99)
(nil)))
(jump_insn 15 14 16 2 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref:DI 22)
(pc))) "foo.c":5 617 {*jcc_1}
(expr_list:REG_DEAD (reg:CCZ 17 flags)
(int_list:REG_BR_PROB 2 (nil)))
-> 22)
(note 16 15 17 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(insn 17 16 22 3 (parallel [
(set (reg/v:SI 93 [ ])
(minus:SI (reg/v:SI 95 [ b ])
(reg/v:SI 93 [ ])))
(clobber (reg:CC 17 flags))
]) "foo.c":5 273 {*subsi_1}
(expr_list:REG_DEAD (reg/v:SI 95 [ b ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(code_label 22 17 25 4 1 (nil) [1 uses])
That is to say, we're starting with a comparison, a branch and a subtract. We
want to know if that sequence is cheaper than a subtract a and conditional
select.
In the cost model, we take an approximation for the branch and comparison of
COST_N_INSNS(2) and the backend tells us the cost of a subtract is
COST_N_INSNS(1). Thus, the cost before transformation is COST_N_INSNS (3) ==
12.
After the transformation, we create this RTL:
(insn 31 0 32 (set (reg:SI 102)
(reg/v:SI 93 [ ])) 82 {*movsi_internal}
(nil))
(insn 32 31 33 (parallel [
(set (reg:SI 101)
(minus:SI (reg/v:SI 95 [ b ])
(reg/v:SI 93 [ ])))
(clobber (reg:CC 17 flags))
]) 273 {*subsi_1}
(nil))
(insn 33 32 34 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 99)
(const_int 0 [0]))) 3 {*cmpsi_ccno_1}
(nil))
(insn 34 33 0 (set (reg/v:SI 93 [ ])
(if_then_else:SI (ne (reg:CCZ 17 flags)
(const_int 0 [0]))
(reg:SI 101)
(reg:SI 102))) 966 {*movsicc_noc}
(nil))
That is a set to protect the "false" value, the same subtract, a comparison to
set the flags, and a conditional move. When we ask the backend to give us costs
for this it gives us COST_N_INSNS(1) for the set, COST_N_INSNS(1) for the
subtract, COST_N_INSNS(1) for the comparison, and COST_N_INSNS(2) for the
conditional move. That's a total cost of COST_N_INSNS(5) == 20 for the whole
sequence. 20 > 12, so from the perspective of the ifcvt cost model this is a
bad transformation.
Note that ifcvt is not aware that an extra set will be introduced after the
original subtract, nor does it care about the final movl %edx, %eax as that is
unconditional. I thinks it is being asked to trade test, branch, subtract for
set, subtract, test branch - when you spell it out like that it should be clear
why it makes the decision it does.
I can't treproduce your comment about -m32 - I still see branches at -Os.
[Bug c/81467] New: AVX-512 support for inline assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81467
Bug ID: 81467
Summary: AVX-512 support for inline assembly
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: alekshs at hotmail dot com
Target Milestone: ---
I'm trying some avx-512 code with the inline assembly.
1) Clobbering xmm16-31 and k-type registers won't work. I guess it won't work
in ymm16-31 or zmm16-31 either:
error: unknown register name ‘%xmm16’ in ‘asm’
error: unknown register name ‘%k1’ in ‘asm’
2) I'm having a problem trying to issue a
"VMOVDQU32 0(%0), %%ZMM0 {k1}{z}\n"
I also tried it with
"VMOVDQU32 0(%0), %%ZMM0 {%k1}{z}\n"
and
"VMOVDQU32 0(%0), %%ZMM0 {%%k1}{z}\n"
and I also added % and %% in front of the z flag to see if it'll work. It's
possible I'm doing something wrong in the syntax although I tried several
permutations. Googling for examples didn't get me any meaningful results.
[Bug go/81393] Bootstrap failure on s390x-linux while building libgo against recent glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81393 Jakub Jelinek changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #5 from Jakub Jelinek --- Only on the trunk. Could you please backport it to release branches as well? I think all of gcc 7, 6 and 5 are affected by this.
[Bug libstdc++/81468] New: is_constructible gives the wrong answer for time_point construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81468
Bug ID: 81468
Summary: is_constructible gives the wrong answer for time_point
construction
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: howard.hinnant at gmail dot com
Target Milestone: ---
This should compile, but does not:
#include
#include
template
using sys_time = std::chrono::time_point;
int
main()
{
using namespace std;
using namespace std::chrono;
static_assert(!is_constructible,
sys_time>{}, "");
//sys_time s{sys_time{123ms}};
}
[Bug libstdc++/81469] New: std::uncaught_exception should be marked as deprecated for C++1z
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81469 Bug ID: 81469 Summary: std::uncaught_exception should be marked as deprecated for C++1z Product: gcc Version: 7.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: daniel.gutson at intel dot com Target Milestone: --- I think that in C++1z/17, std::uncaught_exception should be marked as [[deprecated]].
[Bug bootstrap/81470] New: [8 Regression] Bootstrap comparison failures in gcc/ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81470 Bug ID: 81470 Summary: [8 Regression] Bootstrap comparison failures in gcc/ada Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: rai...@emrich-ebersheim.de Target Milestone: --- With current trunk revision 250281 I get several bootstrap comparison failures in gcc/ada on x86_64-w64-mingw bootstrap with msys2. That's a regression against trunk. Bootstrap comparison failure! gcc/ada/ali-util.o differs gcc/ada/ali.o differs gcc/ada/b_gnatb.o differs gcc/ada/checks.o differs gcc/ada/erroutc.o differs gcc/ada/expander.o differs gcc/ada/exp_aggr.o differs gcc/ada/exp_attr.o differs gcc/ada/exp_ch3.o differs gcc/ada/exp_ch4.o differs gcc/ada/exp_ch5.o differs gcc/ada/exp_ch6.o differs gcc/ada/exp_dbug.o differs gcc/ada/exp_disp.o differs gcc/ada/freeze.o differs gcc/ada/gnat1drv.o differs gcc/ada/gnatbind.o differs gcc/ada/lib-xref.o differs gcc/ada/output.o differs gcc/ada/par.o differs gcc/ada/prep.o differs gcc/ada/prepcomp.o differs gcc/ada/restrict.o differs gcc/ada/rtsfind.o differs gcc/ada/s-os_lib.o differs gcc/ada/scn.o differs gcc/ada/sem_attr.o differs gcc/ada/sem_ch12.o differs gcc/ada/sem_ch13.o differs gcc/ada/sem_ch6.o differs gcc/ada/sem_ch8.o differs gcc/ada/sem_eval.o differs gcc/ada/sem_prag.o differs gcc/ada/sem_warn.o differs gcc/ada/sinput-d.o differs gcc/ada/stringt.o differs gcc/ada/switch-b.o differs gcc/ada/switch-c.o differs gcc/ada/targparm.o differs gcc/ada/tree_io.o differs gcc/ada/widechar.o differs
[Bug c/81471] New: internal compiler error: in curr_insn_transform, at lra-constraints.c:3495
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81471
Bug ID: 81471
Summary: internal compiler error: in curr_insn_transform, at
lra-constraints.c:3495
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gcp at sjeng dot org
Target Milestone: ---
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)
-Wall -Wextra -pipe -O3 -g -ffast-math -march=native -flto -fopenmp -std=c++11
-DNDEBUG -D_CONSOLE
UCTSearch.cpp:130:1: error: unable to generate reloads for:
}
^
(insn 1085 1084 1086 88 (set (reg:DI 538 [ D.12393 ])
(zero_extend:DI (rotatert:SI (subreg:SI (reg/v:DI 321 [ s0 ]) 0)
(const_int -23 [0xffe9] Random.cpp:30 590
{*bmi2_rorxsi3_1_zext}
(nil))
UCTSearch.cpp:130:1: internal compiler error: in curr_insn_transform, at
lra-constraints.c:3495
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
lto-wrapper: fatal error: /usr/bin/g++-5.real returned 1 exit status
compilation terminated.
/usr/bin/ld.bfd.real: error: lto-wrapper failed
The offending function is:
uint64 Random::random(void) {
const uint64 s0 = s[0];
uint64 s1 = s[1];
const uint64 result = s0 + s1;
s1 ^= s0;
s[0] = Utils::rotl(s0, 55) ^ s1 ^ (s1 << 14);<<<
s[1] = Utils::rotl(s1, 36);
return result;
}
In another module there is:
inline uint32 rotl(const uint32 x, const int k) {
return (x << k) | (x >> (32 - k));
}
Note that the code is buggy, the rotl should be using 64-bit integers. But gcc
shouldn't ICE.
[Bug libstdc++/81469] std::uncaught_exception should be marked as deprecated for C++1z
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81469 emi_cuenca at hotmail dot com changed: What|Removed |Added CC||emi_cuenca at hotmail dot com --- Comment #1 from emi_cuenca at hotmail dot com --- Please assign this bug to me
[Bug other/81345] -Wall resets -Wstringop-overflow to 1 from the default 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81345 Martin Sebor changed: What|Removed |Added Known to fail|7.1.0 |8.0 --- Comment #7 from Martin Sebor --- Removing 7.1 from Known to fail versions because unlike 8.0 (prior to r247401) it doesn't use LangEnabledBy for -Wstringop-overflow.
[Bug tree-optimization/81162] [8 Regression] UBSAN switch triggers incorrect optimization in SLSR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81162 --- Comment #13 from Bill Schmidt --- Author: wschmidt Date: Mon Jul 17 19:12:11 2017 New Revision: 250284 URL: https://gcc.gnu.org/viewcvs?rev=250284&root=gcc&view=rev Log: 2017-07-17 Bill Schmidt PR tree-optimization/81162 * gcc.dg/pr81162.c: Move this to... * gcc.dg/ubsan/pr81162.c: ...here. Added: trunk/gcc/testsuite/gcc.dg/ubsan/pr81162.c Removed: trunk/gcc/testsuite/gcc.dg/pr81162.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/81468] is_constructible gives the wrong answer for time_point construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81468
--- Comment #1 from Daniel Krügler ---
It seems that the implementation simply forgot to constrain overload
resolution, since this is the complete definition of the affected constructor:
template
constexpr time_point(const time_point& __t)
: __d(__t.time_since_epoch())
{ }
The constraints were added by LWG 1177,
http://cplusplus.github.io/LWG/lwg-defects.html#1177
[Bug libgomp/81386] [8 regression] libgomp.fortran/appendix-a/a.16.1.f90 fails starting with 249424
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81386 --- Comment #2 from seurer at gcc dot gnu.org --- Created attachment 41776 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41776&action=edit Assembler for fails
[Bug libgomp/81386] [8 regression] libgomp.fortran/appendix-a/a.16.1.f90 fails starting with 249424
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81386 --- Comment #3 from seurer at gcc dot gnu.org --- Created attachment 41777 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41777&action=edit Assembler for works
[Bug libgomp/81386] [8 regression] libgomp.fortran/appendix-a/a.16.1.f90 fails starting with 249424
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81386 --- Comment #4 from seurer at gcc dot gnu.org --- Looking at the difference in generated code. The more recent (failing) builds are generating a whole bunch of vector ops where the old (working) code did not. < failing code (r250280) > last working code (r249423) 171d170 < addis 8,2,.LC1@toc@ha 174,187d172 < addi 8,8,.LC1@toc@l < addis 10,2,.LC3@toc@ha < std 22,-80(1) < std 23,-72(1) < addi 10,10,.LC3@toc@l < std 24,-64(1) < std 25,-56(1) < addis 9,2,.LC2@toc@ha < std 26,-48(1) < std 27,-40(1) < addi 9,9,.LC2@toc@l < vspltisw 4,4 < std 28,-32(1) < std 30,-16(1) 190,191c175,176 < vspltisw 6,6 < vspltisw 7,5 --- > li 9,1 > mtctr 9 194,196c179,180 < std 0,16(1) < lis 0,0xfffe < std 31,-8(1) --- > std 22,-80(1) > std 23,-72(1) 199c183 < vspltisw 8,2 --- > lis 7,0x1062 202,203c186,187 < ori 0,0,0xb560 < lxvd2x 45,0,8 --- > std 24,-64(1) > std 25,-56(1) 206,210c190 < lxvd2x 37,0,10 < li 10,2500 < mtctr 10 < lxvd2x 44,0,9 < vspltisw 9,3 --- > ori 7,7,0x4dd3 212a193,201 > li 10,1 > std 26,-48(1) > std 27,-40(1) > std 28,-32(1) > std 30,-16(1) > std 0,16(1) > lis 0,0xfffe > std 31,-8(1) > ori 0,0,0xb560 227,232d215 < .LBB28: < .loc 1 31 0 < vspltisw 10,1 < .LBE28: < .loc 1 26 0 < xxpermdi 45,45,45,2 234,236c217,219 < addis 9,29,0x1 < addi 9,9,-25536 < .p2align 4,,15 --- > addis 8,29,0x1 > addi 8,8,-25540 > .p2align 5,,31 238c221 < .LBB29: --- > .LBB28: 240,256c223,230 < vmulosw 11,13,12 < vmulesw 0,13,12 < vsraw 1,13,5 < vmrgew 0,11,0 < vsraw 0,0,6 < vsubuwm 1,0,1 < vslw 0,1,7 < vsubuwm 0,0,1 < vslw 0,0,8 < vadduwm 0,0,1 < vslw 0,0,9 < vsubuwm 0,13,0 < vadduwm 13,13,4 < vadduwm 0,0,10 < xxpermdi 0,32,32,2 < stxvd2x 0,0,9 < addi 9,9,16 --- > mulhwu 9,10,7 > srwi 9,9,6 > mulli 9,9,1000 > subf 9,9,10 > addi 10,10,1 > addi 9,9,1 > stwu 9,4(8) > .loc 1 30 0
[Bug libgomp/81386] [8 regression] libgomp.fortran/appendix-a/a.16.1.f90 fails starting with 249424
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81386 --- Comment #5 from Bill Schmidt --- The code is being vectorized in the "fails" dump and not being vectorized in the "works" dump. This cannot be due to r249424, which does gimple folding on some Power-specific built-ins, for this is a generic test case that makes no use of such built-ins. So either you have misidentified the revision responsible, or the code is somehow being compiled differently so that vectorization happens in one case and not the other. Bill
[Bug target/81471] internal compiler error: in curr_insn_transform, at lra-constraints.c:3495
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81471 --- Comment #1 from Uroš Bizjak --- (In reply to Gian-Carlo Pascutto from comment #0) > In another module there is: Please provide a compilable source file (preferably minimized) that triggers the ICE, as instructed in [1]. [1] https://gcc.gnu.org/bugs/
[Bug target/81225] [6/7 Regression] ICE with -mavx512ifma -O3 -ffloat-store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81225 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Mon Jul 17 19:38:29 2017 New Revision: 250285 URL: https://gcc.gnu.org/viewcvs?rev=250285&root=gcc&view=rev Log: Backported from mainline 2017-06-30 Jakub Jelinek PR target/81225 * config/i386/sse.md (vec_extract_lo_): For V8FI, V16FI and VI8F_256 iterators, use instead of nonimmediate_operand and instead of m for the input operand. For V8FI iterator, always split if input is a MEM. For V16FI and V8SF_256 iterators, don't test if both operands are MEM if . For VI4F_256 iterator, use instead of register_operand and instead of v for the input operand. Make sure both operands aren't MEMs for if not . * gcc.target/i386/pr81225.c: New test. Added: branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr81225.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/i386/sse.md branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug c++/81258] [7/8 Regression] ICE on C++1z code with invalid decomposition declaration: in cp_finish_decl, at cp/decl.c:6760
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81258 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Mon Jul 17 19:39:23 2017 New Revision: 250286 URL: https://gcc.gnu.org/viewcvs?rev=250286&root=gcc&view=rev Log: Backported from mainline 2017-07-04 Jakub Jelinek PR c++/81258 * parser.c (cp_parser_decomposition_declaration): Diagnose invalid forms of structured binding initializers. * g++.dg/cpp1z/decomp21.C (foo): Adjust expected diagnostics. * g++.dg/cpp1z/decomp30.C: New test. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp1z/decomp30.C Modified: branches/gcc-7-branch/gcc/cp/ChangeLog branches/gcc-7-branch/gcc/cp/parser.c branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp1z/decomp21.C
[Bug sanitizer/81066] sanitizer_stoptheworld_linux_libcdep.cc:276:22: error: aggregate ‘sigaltstack handler_stack’ has incomplete type and cannot be defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81066 --- Comment #15 from Jakub Jelinek --- Author: jakub Date: Mon Jul 17 19:41:08 2017 New Revision: 250287 URL: https://gcc.gnu.org/viewcvs?rev=250287&root=gcc&view=rev Log: Backported from mainline 2017-07-14 Jakub Jelinek PR sanitizer/81066 * sanitizer_common/sanitizer_linux.h: Cherry-pick upstream r307969. * sanitizer_common/sanitizer_linux.cc: Likewise. * sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc: Likewise. * tsan/tsan_platform_linux.cc: Likewise. Modified: branches/gcc-7-branch/libsanitizer/ChangeLog branches/gcc-7-branch/libsanitizer/sanitizer_common/sanitizer_linux.cc branches/gcc-7-branch/libsanitizer/sanitizer_common/sanitizer_linux.h branches/gcc-7-branch/libsanitizer/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc branches/gcc-7-branch/libsanitizer/tsan/tsan_platform_linux.cc
[Bug tree-optimization/81365] [7/8 Regression] GCC miscompiles swap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81365 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Mon Jul 17 19:42:37 2017 New Revision: 250288 URL: https://gcc.gnu.org/viewcvs?rev=250288&root=gcc&view=rev Log: PR tree-optimization/81365 * tree-ssa-phiprop.c (propagate_with_phi): When considering hoisting aggregate moves onto bb predecessor edges, make sure there are no loads that could alias the lhs in between the start of bb and the loads from *phi. * g++.dg/torture/pr81365.C: New test. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/torture/pr81365.C Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/tree-ssa-phiprop.c
[Bug tree-optimization/81354] [5/6 Regression] Segmentation fault in SSA Strength Reduction using -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81354 --- Comment #5 from Bill Schmidt --- Doesn't reproduce for powerpc64le. I'll have to build a cross.
[Bug target/81471] internal compiler error: in curr_insn_transform, at lra-constraints.c:3495
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81471
--- Comment #2 from Gian-Carlo Pascutto ---
#include
inline uint32_t rotl(const uint32_t x, const int k) {
return (x << k) | (x >> (32 - k));
}
uint64_t s[2];
uint64_t random(void) {
const uint64_t s0 = s[0];
uint64_t s1 = s[1];
const uint64_t result = s0 + s1;
s1 ^= s0;
s[0] = rotl(s0, 55) ^ s1 ^ (s1 << 14);
s[1] = rotl(s1, 36);
return result;
}
int main(void) {
int x = random();
return 0;
}
According to https://godbolt.org/g/8CVJ9a this is broken in all current gcc
versions, not just 5.4.0.
[Bug tree-optimization/81428] [7/8 Regression] ICE: in build_one_cst, at tree.c:2079 with -O2. Fixed point division.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81428 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Mon Jul 17 19:45:59 2017 New Revision: 250289 URL: https://gcc.gnu.org/viewcvs?rev=250289&root=gcc&view=rev Log: PR tree-optimization/81428 * match.pd (X / X -> one): Don't optimize _Fract divisions, as 1 can't be built for those types. * gcc.dg/fixed-point/pr81428.c: New test. Added: branches/gcc-7-branch/gcc/testsuite/gcc.dg/fixed-point/pr81428.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/match.pd branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug target/81471] internal compiler error: in curr_insn_transform, at lra-constraints.c:3495
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81471 --- Comment #3 from Gian-Carlo Pascutto --- Note the flags, -march=native in this case was Intel Haswell. -O3 -march=haswell is required to trigger this.
[Bug target/81471] internal compiler error: in curr_insn_transform, at lra-constraints.c:3495
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81471
--- Comment #4 from Gian-Carlo Pascutto ---
Further reduced testcase:
#include
uint64_t f(uint64_t x) {
return ((uint32_t)x << 55) | ((uint32_t)x >> -23);
}
This makes it more clear the code is UB, but AFAIK a compiler ICE doesn't fall
under allowable UB :-)
[Bug target/81471] internal compiler error: in curr_insn_transform, at lra-constraints.c:3495
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81471 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-07-17 Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Ever confirmed|0 |1 --- Comment #5 from Uroš Bizjak --- Created attachment 41778 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41778&action=edit Patch in testing I have a patch.
[Bug target/81471] internal compiler error: in curr_insn_transform, at lra-constraints.c:3495
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81471
--- Comment #6 from Uroš Bizjak ---
(In reply to Gian-Carlo Pascutto from comment #4)
> Further reduced testcase:
>
> #include
>
> uint64_t f(uint64_t x) {
> return ((uint32_t)x << 55) | ((uint32_t)x >> -23);
> }
>
> This makes it more clear the code is UB, but AFAIK a compiler ICE doesn't
> fall under allowable UB :-)
I have following, somehow less UB testcase:
--cut here--
/* PR target/81471 */
/* { dg-do compile { target { ! ia32 } } } */
/* { dg-options "-O2 -mbmi2" } */
static inline unsigned int rotl (unsigned int x, int k)
{
return (x << k) | (x >> (32 - k));
}
unsigned long long test (unsigned int z)
{
return rotl (z, 55);
}
--cut here--
[Bug target/81471] [5/6/7/8 Regression] internal compiler error: in curr_insn_transform, at lra-constraints.c:3495
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81471 Uroš Bizjak changed: What|Removed |Added Keywords|ra | Target Milestone|--- |5.5 Summary|internal compiler error: in |[5/6/7/8 Regression] |curr_insn_transform, at |internal compiler error: in |lra-constraints.c:3495 |curr_insn_transform, at ||lra-constraints.c:3495
[Bug libgomp/81386] [8 regression] libgomp.fortran/appendix-a/a.16.1.f90 fails starting with 249424
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81386 --- Comment #6 from seurer at gcc dot gnu.org --- So here is comparing 249423 (works) with 249424 (fails): seurer@genoa:~/gcc/build/gcc-test2$ svn info $GCC_SRC . . . Revision: 249423 . . . seurer@genoa:~/gcc/build/gcc-test2$ /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/libgomp/testsuite/libgomp.fortran/appendix-a/a.16.1.f90 -B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/ -B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/.libs -I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp -I/home/seurer/gcc/gcc-test2/libgomp/testsuite/../../include -I/home/seurer/gcc/gcc-test2/libgomp/testsuite/.. -fmessage-length=0 -fno-diagnostics-show-caret -Wno-hsa -fdiagnostics-color=never -fopenmp -O3 -g -B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/../libgfortran/.libs -fintrinsic-modules-path=/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp -L/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/.libs -L/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/../libgfortran/.libs -lgfortran -foffload=-lgfortran -lm -o ./a.16.1.exe seurer@genoa:~/gcc/build/gcc-test2$ ./a.16.1.exe X( 1 ) =55000. , Y( 1 ) =2. X( 2 ) =45010. , Y( 2 ) =4. X( 3 ) =45020. , Y( 3 ) =6. X( 4 ) =45030. , Y( 4 ) =8. X( 5 ) =45040. , Y( 5 ) =10.000 X( 6 ) =45050. , Y( 6 ) =12.000 X( 7 ) =45060. , Y( 7 ) =14.000 X( 8 ) =45070. , Y( 8 ) =16.000 X( 9 ) =45080. , Y( 9 ) =18.000 X( 10 ) =45090. , Y( 10 ) =20.000 seurer@genoa:~/gcc/build/gcc-test$ svn info $GCC_SRC Path: /home/seurer/gcc/gcc-test Working Copy Root Path: /home/seurer/gcc/gcc-test . . . Revision: 249424 . . . seurer@genoa:~/gcc/build/gcc-test$ /home/seurer/gcc/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/build/gcc-test/gcc/ /home/seurer/gcc/gcc-test/libgomp/testsuite/libgomp.fortran/appendix-a/a.16.1.f90 -B/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/ -B/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/.libs -I/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp -I/home/seurer/gcc/gcc-test/libgomp/testsuite/../../include -I/home/seurer/gcc/gcc-test/libgomp/testsuite/.. -fmessage-length=0 -fno-diagnostics-show-caret -Wno-hsa -fdiagnostics-color=never -fopenmp -O3 -g3 -B/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/../libgfortran/.libs -fintrinsic-modules-path=/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp -L/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/.libs -L/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/../libgfortran/.libs -lgfortran -foffload=-lgfortran -lm -o ./a.16.1.exe seurer@genoa:~/gcc/build/gcc-test$ ./a.16.1.exe Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x3fff98cb9a9f in ??? Segmentation fault (core dumped) The options were the same: < .string "8 8.0.0 20170620 (experimental) [trunk revision 249424] -mcpu=power8 -g3 -O3 -fmessage-length=0 -fopenmp -fintrinsic-modules-path=/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp -foffload=-lgfortran -fintrinsic-modules-path finclude" --- > .string " 8.0.0 20170620 (experimental) [trunk revision 249423] > -mcpu=power8 -g3 -O3 -fmessage-length=0 -fopenmp > -fintrinsic-modules-path=/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp > -foffload=-lgfortran -fintrinsic-modules-path finclude" 11c11 < .file 1 "/home/seurer/gcc/gcc-test/libgomp/testsuite/libgomp.fortran/appendix-a/a.16.1.f90" --- > .file 1 > "/home/seurer/gcc/gcc-test2/libgomp/testsuite/libgomp.fortran/appendix-a/a.16.1.f90" 171d170 < addis 8,2,.LC1@toc@ha 174,187d172 < addi 8,8,.LC1@toc@l < addis 10,2,.LC3@toc@ha < std 22,-80(1) < std 23,-72(1) < addi 10,10,.LC3@toc@l < std 24,-64(1) < std 25,-56(1) < addis 9,2,.LC2@toc@ha < std 26,-48(1) < std 27,-40(1) < addi 9,9,.LC2@toc@l < vspltisw 4,4 < std 28,-32(1) < std 30,-16(1) 190,191c175,176 < vspltisw 6,6 < vspltisw 7,5 --- > li 9,1 > mtctr 9 194,196c179,180 < std 0,16(1) < lis 0,0xfffe < std 31,-8(1) --- > std 22,-80(1) > std 23,-72(1) 199c18
[Bug libgomp/81386] [8 regression] libgomp.fortran/appendix-a/a.16.1.f90 fails starting with 249424
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81386 Bill Schmidt changed: What|Removed |Added CC||carll at gcc dot gnu.org --- Comment #7 from Bill Schmidt --- (In reply to Bill Schmidt from comment #5) > The code is being vectorized in the "fails" dump and not being vectorized in > the "works" dump. This cannot be due to r249424, which does gimple folding > on some Power-specific built-ins, for this is a generic test case that makes > no use of such built-ins. > > So either you have misidentified the revision responsible, or the code is > somehow being compiled differently so that vectorization happens in one case > and not the other. > > Bill Sorry, I got mixed up. In introducing new multiply built-ins, Carl also introduced some of the standard patterns that were previously not supported for the POWER back ends, which allowed vectorization to occur that wouldn't have before. Very sorry for the mischaracterization. Carl, we'll need you to investigate. I assume that the semantics for the standard patterns have been implemented incorrectly. Let me know if you want to discuss. Bill
[Bug libgomp/81386] [8 regression] libgomp.fortran/appendix-a/a.16.1.f90 fails starting with 249424
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81386 --- Comment #8 from Bill Schmidt --- Carl, please revert the patch until you have time to investigate. This will cause havoc every time we vectorize with these patterns.
[Bug lto/78795] LTO causes undefined reference errors when linking with GMP "make check"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78795 --- Comment #12 from Marc Glisse --- (In reply to Vincent Lefèvre from comment #11) > On Debian, after path canonicalization, this is /usr/lib/bfd-plugins, but > only packages should manage files under /usr/lib (unlike /usr/local, for > instance). I've sent a mail to the Debian GCC Maintainers so that they > provide a symlink: > > https://lists.debian.org/debian-gcc/2016/12/msg00122.html For the record, Debian (testing+unstable) recently added this symlink.
[Bug bootstrap/81459] GNAT 7.1.0 build failed on the Debian 9/x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81459 --- Comment #3 from Eric Botcazou --- > 3) Next combinations have been tested: > > --enable-languages=c,ada > > --enable-languages=c,c++,ada This one should be fine. If this doesn't work, then use the system compiler instead of GNAT GPL as base compiler.
[Bug tree-optimization/81455] [7/8 Regression] Compile-time hog w/ -O1 -funswitch-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81455 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-07-17 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r239523.
[Bug target/81456] [7/8 Regression] x86-64 optimizer makes wrong decision when optimizing for size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81456 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-07-17 CC||jgreenhalgh at gcc dot gnu.org, ||marxin at gcc dot gnu.org Known to work||6.4.0 Summary|x86-64 optimizer makes |[7/8 Regression] x86-64 |wrong decision when |optimizer makes wrong |optimizing for size |decision when optimizing ||for size Ever confirmed|0 |1 Known to fail||7.1.0, 8.0 --- Comment #1 from Martin Liška --- Confirmed, started with r238594.
[Bug tree-optimization/81354] [5/6 Regression] Segmentation fault in SSA Strength Reduction using -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81354 --- Comment #2 from rguenther at suse dot de --- On Tue, 11 Jul 2017, marxin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81354 > > Martin Liška changed: > >What|Removed |Added > > Status|UNCONFIRMED |NEW >Last reconfirmed||2017-07-11 > CC||marxin at gcc dot gnu.org, >||rguenth at gcc dot gnu.org > Known to work||4.5.4, 4.6.4, 4.7.4, 4.8.5, >||4.9.4, 7.1.0, 8.0 > Summary|Segmentation fault in SSA |[5/6 Regression] >|Strength Reduction using|Segmentation fault in SSA >|-O3 |Strength Reduction using >||-O3 > Ever confirmed|0 |1 > Known to fail||5.4.0, 6.4.0 > > --- Comment #1 from Martin Liška --- > Confirmed, fixed on trunk by r236440 and was introduced by r217914. Richi is > it > a subject of backport maybe? No, I'm quite sure r236440 just made it latent and the bug still exists (try a gimple FE input directly into SLSR).
[Bug sanitizer/81460] New: [8 Regression] ICE in force_constant_size, at gimplify.c:684
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81460
Bug ID: 81460
Summary: [8 Regression] ICE in force_constant_size, at
gimplify.c:684
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
It's mine:
$ cat
/home/marxin/BIG/Programming/llvm-project/dragonegg/test/compilator/local/2007-02-16-VariableSizeStructArg.c
// RUN: %llvmgcc -S -w %s -o -
// PR1170
int f(int a, struct {int b[a];} c) { return c.b[0]; }
int g(struct {int b[1];} c) {
return c.b[0];
}
$ ./xgcc -B.
/home/marxin/BIG/Programming/llvm-project/dragonegg/test/compilator/local/2007-02-16-VariableSizeStructArg.c
-fsanitize=address -c
/home/marxin/BIG/Programming/llvm-project/dragonegg/test/compilator/local/2007-02-16-VariableSizeStructArg.c:3:14:
warning: anonymous struct declared inside parameter list will not be visible
outside of this definition or declaration
int f(int a, struct {int b[a];} c) { return c.b[0]; }
^~
/home/marxin/BIG/Programming/llvm-project/dragonegg/test/compilator/local/2007-02-16-VariableSizeStructArg.c:5:7:
warning: anonymous struct declared inside parameter list will not be visible
outside of this definition or declaration
int g(struct {int b[1];} c) {
^~
during GIMPLE pass: sanopt
/home/marxin/BIG/Programming/llvm-project/dragonegg/test/compilator/local/2007-02-16-VariableSizeStructArg.c:
In function ‘f’:
/home/marxin/BIG/Programming/llvm-project/dragonegg/test/compilator/local/2007-02-16-VariableSizeStructArg.c:3:5:
internal compiler error: in force_constant_size, at gimplify.c:684
int f(int a, struct {int b[a];} c) { return c.b[0]; }
^
0x907396 force_constant_size
../../gcc/gimplify.c:684
0x90df27 gimple_add_tmp_var(tree_node*)
../../gcc/gimplify.c:722
0xbd614e sanitize_rewrite_addressable_params
../../gcc/sanopt.c:910
0xbd69e4 execute
../../gcc/sanopt.c:1030
[Bug sanitizer/81460] [8 Regression] ICE in force_constant_size, at gimplify.c:684
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81460 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-07-17 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug middle-end/59521] __builtin_expect not effective in switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59521 Yuri Gribov changed: What|Removed |Added Attachment #41737|0 |1 is obsolete|| --- Comment #13 from Yuri Gribov --- Created attachment 41770 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41770&action=edit Yet another patch Ok, this one works both for __builtin_expect and -fprofile-generate and survives bootstrap on x64. I've modified switch decision tree creation to select pivot value based on probabilities rather than number of values on left and right (somewhat similar to ID3 algorithm for decision trees). If patch looks fine in general, I'll add tests and submit for review.
[Bug tree-optimization/81461] New: Optimization for removing same variable comparisons in loop: while(it != end1 && it != end2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81461
Bug ID: 81461
Summary: Optimization for removing same variable comparisons in
loop: while(it != end1 && it != end2)
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
Simple iteration by std::deque elements produces suboptimal code. For example
#include
unsigned sum(std::deque cont) {
unsigned sum = 0;
for (unsigned v : cont)
sum += v;
return sum;
}
produces the following loop:
.L2:
cmp rcx, rdx
je .L1
add eax, DWORD PTR [rdx]
add rdx, 4
cmp rdx, rsi
jne .L2
mov rdx, QWORD PTR [r8+8]
add r8, 8
lea rsi, [rdx+512]
jmp .L2
The loop has two comparisons in it and behaves as the following C code:
unsigned sum_like0(unsigned** chunks, unsigned* end) {
unsigned sum = 0;
for (unsigned* it = *chunks; it != end; it = *(++chunks)) {
for (;it != end && it != *chunks + 128; ++it) {
sum += *it;
}
}
return sum;
}
Note the `it != end && it != *chunks + 128` condition. It could be simplified:
if `end` belongs to `[it, *chunks + 128]` change the condition to `it != end`
and use the condition `it != *chunks + 128` otherwise. Such optimization
removes the cmp from the loop and produces a much more faster loop:
.L15:
add eax, DWORD PTR [rdx]
add rdx, 4
cmp rdx, rcx
jne .L15
Synthetic tests show up to 2 times better performance. Assembly outputs:
https://godbolt.org/g/L7Mr4M
[Bug target/81069] nvptx offloading: "-O1" execution test of "libgomp.oacc-fortran/nested-function-1.f90" timeout/FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81069 --- Comment #7 from Tom de Vries --- Author: vries Date: Mon Jul 17 07:49:22 2017 New Revision: 250256 URL: https://gcc.gnu.org/viewcvs?rev=250256&root=gcc&view=rev Log: Insert diverging jump alap in nvptx_single 2017-07-17 Tom de Vries PR target/81069 * config/nvptx/nvptx.c (nvptx_single): Insert diverging branch as late as possible. Modified: trunk/gcc/ChangeLog trunk/gcc/config/nvptx/nvptx.c
[Bug tree-optimization/81462] New: [8 Regression] ICE in estimate_bb_frequencies at gcc/predict.c:3546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81462 Bug ID: 81462 Summary: [8 Regression] ICE in estimate_bb_frequencies at gcc/predict.c:3546 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: hubicka at ucw dot cz Target Milestone: --- $ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ipa/devirt-50.C -O1 -fno-ipa-pure-const during GIMPLE pass: profile_estimate /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ipa/devirt-50.C: In function ‘int main()’: /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ipa/devirt-50.C:17:5: internal compiler error: in to_reg_br_prob_base, at profile-count.h:189 } ^ 0xcedbf0 profile_probability::to_reg_br_prob_base() const ../../gcc/profile-count.h:189 0xcebc05 estimate_bb_frequencies(bool) ../../gcc/predict.c:3546 0xce9712 tree_estimate_probability(bool) ../../gcc/predict.c:2815 0xcec3b3 execute ../../gcc/predict.c:3688
[Bug middle-end/81376] unnecessary cast before comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81376 Yuri Gribov changed: What|Removed |Added CC||tetra2005 at gmail dot com --- Comment #2 from Yuri Gribov --- Thanks, will take this one too (maybe after PR57371 is finally accepted).
[Bug tree-optimization/81463] New: [8 Regression] ICE in scale_loop_profile at gcc/cfgloopmanip.c:603
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81463 Bug ID: 81463 Summary: [8 Regression] ICE in scale_loop_profile at gcc/cfgloopmanip.c:603 Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: hubicka at ucw dot cz Target Milestone: --- Following ICEs: $ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/l_fma_run_float_2.c -Ofast -fno-guess-branch-probability ... during GIMPLE pass: vect /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/l_fma_2.h: In function ‘test_neg_add_noneg_add’: /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/l_fma_2.h:70:1: internal compiler error: in probability_in_gcov_type, at profile-count.h:215 test_neg_add_noneg_add (TYPE *a, TYPE *b, TYPE *c, TYPE *d, int n) ^~ 0x76bc31 profile_probability::probability_in_gcov_type(long, long) ../../gcc/profile-count.h:215 0x76bc31 scale_loop_profile(loop*, profile_probability, long) ../../gcc/cfgloopmanip.c:603 0xe34be5 vect_do_peeling(_loop_vec_info*, tree_node*, tree_node*, tree_node**, int, bool, bool) ../../gcc/tree-vect-loop-manip.c:1772 0xe27c90 vect_transform_loop(_loop_vec_info*) ../../gcc/tree-vect-loop.c:7316 0xe46d43 vectorize_loops() ../../gcc/tree-vectorizer.c:745
[Bug middle-end/81464] New: [8 Regression] ICE in expand_omp_for_static_chunk, at omp-expand.c:4236
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81464 Bug ID: 81464 Summary: [8 Regression] ICE in expand_omp_for_static_chunk, at omp-expand.c:4236 Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Starting from r247495, we ICE on: $ gcc /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/matmul_15.f90 -O1 --param parloops-chunk-size=2 -ftree-parallelize-loops=2 during GIMPLE pass: ompexpssa /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/matmul_15.f90:28:0: sm = sm + sum(c) internal compiler error: in expand_omp_for_static_chunk, at omp-expand.c:4236 0xacdfd4 expand_omp_for_static_chunk ../../gcc/omp-expand.c:4236 0xad70b6 expand_omp_for ../../gcc/omp-expand.c:5840 0xad845a expand_omp ../../gcc/omp-expand.c:7903 0xad8666 expand_omp ../../gcc/omp-expand.c:7889 0xadae3d execute_expand_omp ../../gcc/omp-expand.c:8127
[Bug middle-end/54123] inline functions not optimized as well as static inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54123 Yuri Gribov changed: What|Removed |Added CC||tetra2005 at gmail dot com --- Comment #4 from Yuri Gribov --- This was fixed in r206723. Ok to close?
[Bug ipa/81465] New: ICE in estimate_edge_growth at gcc/ipa-inline.h:85 on s390x target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81465 Bug ID: 81465 Summary: ICE in estimate_edge_growth at gcc/ipa-inline.h:85 on s390x target Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: hubicka at ucw dot cz, marxin at gcc dot gnu.org Target Milestone: --- Host: x86_64-linux-gnu Target: s390x-linux-gnu With a cross compiler: $ ./xg++ -B. /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/abi/nvptx-nrv1.C -fno-early-inlining -Os during IPA pass: inline /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/abi/nvptx-nrv1.C:68:1: internal compiler error: in estimate_edge_growth, at ipa-inline.h:86 } ^ 0xee24ee estimate_edge_growth ../../gcc/ipa-inline.h:85 0xee2f2f estimate_size_after_inlining(cgraph_node*, cgraph_edge*) ../../gcc/ipa-inline-analysis.c:300 0x19bc15b caller_growth_limits ../../gcc/ipa-inline.c:186 0x19bc94e can_inline_edge_p ../../gcc/ipa-inline.c:383 0x19bfc81 update_caller_keys ../../gcc/ipa-inline.c:1344 0x19c1cb2 inline_small_functions ../../gcc/ipa-inline.c:2047 0x19c3168 ipa_inline ../../gcc/ipa-inline.c:2438 0x19c3e44 execute ../../gcc/ipa-inline.c:2847
[Bug tree-optimization/81396] [7/8 Regression] Optimization of reading Little-Endian 64-bit number with portable code has a regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81396 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Mon Jul 17 08:14:16 2017 New Revision: 250257 URL: https://gcc.gnu.org/viewcvs?rev=250257&root=gcc&view=rev Log: PR tree-optimization/81396 * tree-ssa-math-opts.c (struct symbolic_number): Add n_ops field. (init_symbolic_number): Initialize it to 1. (perform_symbolic_merge): Add n_ops from both operands into the new n_ops. (find_bswap_or_nop): Don't consider n->n == cmpnop computations without base_addr as useless if they need more than one operation. (bswap_replace): Handle !bswap case for NULL base_addr. * gcc.dg/tree-ssa/pr81396.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr81396.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-math-opts.c
[Bug middle-end/54123] inline functions not optimized as well as static inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54123 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug middle-end/81464] [8 Regression] ICE in expand_omp_for_static_chunk, at omp-expand.c:4236
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81464 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- This is when searching for a PHI for vop .MEM_NNN, but apparently there is no such PHI. I'm afraid I'm not familiar with this part of code to know why it is trying to do that.
[Bug middle-end/81464] [8 Regression] ICE in expand_omp_for_static_chunk, at omp-expand.c:4236
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81464 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-07-17 CC||vries at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- CCing Tom as the author of r227437.
[Bug target/81069] nvptx offloading: "-O1" execution test of "libgomp.oacc-fortran/nested-function-1.f90" timeout/FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81069 Tom de Vries changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #8 from Tom de Vries --- Test-case libgomp.oacc-fortran/nested-function-1.f90 passing again, marking resolved-fixed.
[Bug middle-end/80929] [7/8 Regression] Division with constant no more optimized to mult highpart
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80929 --- Comment #1 from Georg-Johann Lay --- Author: gjl Date: Mon Jul 17 08:56:06 2017 New Revision: 250258 URL: https://gcc.gnu.org/viewcvs?rev=250258&root=gcc&view=rev Log: PR 80929 * config/avr/avr.c (avr_mul_highpart_cost): New static function. (avr_rtx_costs_1) [TRUNCATE]: Use it to compute mul_highpart cost. [LSHIFTRT, outer_code = TRUNCATE]: Same. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c
[Bug ipa/81323] IPA-VRP doesn't handle return values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81323 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2017-07-17 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- We do not have "return functions" but all IPA propagations just work on the acyclic graph call arg -> callee. Eventually we have a dup for this somewhere.
[Bug go/81324] libgo does not build with glibc 2.18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81324 Richard Biener changed: What|Removed |Added Target|powerpc64-linux |powerpc64-linux, ||x86_64-linux Status|UNCONFIRMED |NEW Last reconfirmed||2017-07-17 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Seen this as well on x86_64, since that no longer enabling go for bootstrap.
[Bug regression/81331] [8 Regression] FAIL: 21_strings/basic_string/modifiers/insert/char/1.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81331 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug middle-end/80929] [7/8 Regression] Division with constant no more optimized to mult highpart
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80929 --- Comment #2 from Georg-Johann Lay --- Author: gjl Date: Mon Jul 17 09:06:39 2017 New Revision: 250259 URL: https://gcc.gnu.org/viewcvs?rev=250259&root=gcc&view=rev Log: Backport from 2017-07-17 trunk r250258. PR 80929 * config/avr/avr.c (avr_mul_highpart_cost): New static function. (avr_rtx_costs_1) [TRUNCATE]: Use it to compute mul_highpart cost. [LSHIFTRT, outer_code = TRUNCATE]: Same. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/avr/avr.c
[Bug c/81342] LTO: lto1: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81342
Richard Biener changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|--- |INVALID
--- Comment #6 from Richard Biener ---
Well, if you do
gcc -m32 -flto -c x.c
you can't simply "objcopy" that x.o file to 64bits as objcopy doesn't know
how to handle LTO bytecode.
I suppose lto-wrapper could diagnose mismatched -m32/-m64 (but those are
target flags).
The solution is to _not_ use -flto for the 32bit bootloader part. Thus
${PREFIX}gcc -c $CFLAGS -m32 code32.c -o code32.o32 -fno-lto
${PREFIX}objcopy -O elf64-x86-64 code32.o32 code32.o
[Bug c++/81347] g++ confused by namespaces and friend classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81347 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Richard Biener --- Sounds like a bug in libc++ headers to me -> file to the LLVM project.
[Bug middle-end/80929] [7/8 Regression] Division with constant no more optimized to mult highpart
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80929 --- Comment #3 from Georg-Johann Lay --- Author: gjl Date: Mon Jul 17 09:09:42 2017 New Revision: 250260 URL: https://gcc.gnu.org/viewcvs?rev=250260&root=gcc&view=rev Log: Backport from 2017-07-17 trunk r250258. PR 80929 * config/avr/avr.c (avr_mul_highpart_cost): New static function. (avr_rtx_costs_1) [TRUNCATE]: Use it to compute mul_highpart cost. [LSHIFTRT, outer_code = TRUNCATE]: Same. Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/avr/avr.c
