[Bug target/80865] broken compilation on Mac OS X 10.5 / powerpc: unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80865 --- Comment #9 from Iain Sandoe --- (In reply to Christian Cornelssen from comment #7) > I have made the time-consuming effort of building and testing gcc-7.2.0 with > varying subsets of the four patchsets proposed with attachment 42124 > [details]. Thanks for doing this! I have building work going on here (to repair water damage to my office) and temporarily had to relocate - at present, I don't have access to my PPC Darwin machines. Hopefully, the works will complete in a month or so, and i'll be back to normal (please be patient - but I don't believe another 7.x release is scheduled in that time). Note that the patches solve individual problems, it would be reasonable to apply them independently. > * Patchset 1/4 copies stack alignment changes previously applied to aix.h. > This seems to cause 15 additional testsuite failures > involving gcc/testsuite/gcc.dg/builtin-apply4.c and > gcc/testsuite/gcc.dg/torture/stackalign/builtin-apply-4.c. > The failures are related to the builtins around __builtin_apply > as defined in gcc/builtins.c. > I'd leave that patchset out. The patch was originally required to allow bootstrap to complete, so clearly some intervening change has made that unnecessary - but I'd like to identify what (and if there are other implications). > * Patchset 2/4 turns out to be necessary and sufficient for the non-Ada > build to succeed. If you want a minimal patchset, stick to that one. > Given as attachment 42304 [details] now. > * Patchset 3/4 seems reasonable (marking longjmp noreturn), > but does not contribute changes to the test summary. Are you building Fortran? IIRC, that patch was required for Fortran bootstrap to complete. > * Patchset 4/4 looks reasonable (selecting Darwin thread headers), > but is Ada-related, thus irrelevant for non-Ada builds. Well, generally I build for all the supported languages including Ada, Fortran (and Java where supported) so generally I will keep patches to allow all of those to succeed. > > Attaching the gcc7 testsuite log diff showing the removal of > alignment test failures when only patchset 2 (attachment 42304 [details] > instead of attachment 42124 [details]) is used.
[Bug target/80865] broken compilation on Mac OS X 10.5 / powerpc: unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80865 --- Comment #8 from Christian Cornelssen --- Created attachment 42305 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42305&action=edit differences in non-Ada testsuite results when switching from attachment 42124 to attachment 42304
[Bug target/80865] broken compilation on Mac OS X 10.5 / powerpc: unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80865 --- Comment #7 from Christian Cornelssen --- I have made the time-consuming effort of building and testing gcc-7.2.0 with varying subsets of the four patchsets proposed with attachment 42124. * Patchset 1/4 copies stack alignment changes previously applied to aix.h. This seems to cause 15 additional testsuite failures involving gcc/testsuite/gcc.dg/builtin-apply4.c and gcc/testsuite/gcc.dg/torture/stackalign/builtin-apply-4.c. The failures are related to the builtins around __builtin_apply as defined in gcc/builtins.c. I'd leave that patchset out. * Patchset 2/4 turns out to be necessary and sufficient for the non-Ada build to succeed. If you want a minimal patchset, stick to that one. Given as attachment 42304 now. * Patchset 3/4 seems reasonable (marking longjmp noreturn), but does not contribute changes to the test summary. * Patchset 4/4 looks reasonable (selecting Darwin thread headers), but is Ada-related, thus irrelevant for non-Ada builds. Attaching the gcc7 testsuite log diff showing the removal of alignment test failures when only patchset 2 (attachment 42304 instead of attachment 42124) is used.
[Bug target/80865] broken compilation on Mac OS X 10.5 / powerpc: unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80865 --- Comment #6 from Christian Cornelssen --- Created attachment 42304 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42304&action=edit Patchset 2 from patch-darwin-ppc-2017-01-msg02971.diff, sufficient for non-Ada builds to succeed
[Bug target/82408] cross-compiling for arm64 problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82408 --- Comment #13 from Peter Bohning --- Okay, amazingly I have a computer again. I tried what you suggested and it didn't work. I need a libstdc++ library for aarch. Like I said several times, I already have the linaro toolchain, what I want is the host and target aarch libraries. So again, I'm in the exact same situation... I will try to just copy the linaro stdc++ library and hope it works but I really should be able to compile it using the linaro toolchain, which again comes back to these C++ errors.
[Bug target/82411] const is not always read-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82411 Segher Boessenkool changed: What|Removed |Added Target|Powerpc*-*-*|powerpc*-*-* --- Comment #4 from Segher Boessenkool --- That what it means yes. You can use it as a workaround. There is no option yet to put only writable data in sdata.
[Bug tree-optimization/82432] Missed constant propagation of return values of non-inlined static functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82432 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement --- Comment #2 from Andrew Pinski --- I think the get_constant issue is a dup of bug 81323. But the rest is harder due to it being a struct rather than a scalar.
[Bug ipa/81323] IPA-VRP doesn't handle return values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81323 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/82432] Missed constant propagation of return values of non-inlined static functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82432 --- Comment #1 from Peter Cordes --- Meant to add https://godbolt.org/g/K9CxQ6 before submitting. And to say I wasn't sure tree-optimization was the right component. I did check that -flto didn't do this optimization either. Is it worth opening a separate bug for making .clone versions of functions with a more convenient calling convention? Obviously that can gain performance, but can make debugging harder. https://stackoverflow.com/a/46549978/224132 is right that compilers *could* do this, but there are probably good reasons why they don't.
[Bug tree-optimization/82432] New: Missed constant propagation of return values of non-inlined static functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82432
Bug ID: 82432
Summary: Missed constant propagation of return values of
non-inlined static functions
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: peter at cordes dot ca
Target Milestone: ---
static __attribute((noinline))
int get_constant() { /* optionally stuff with side effects */
return 42; }
movl$42, %eax
ret
// Consider the case where this is large enough to not inline (even without an
attribute), but still returns a constant. e.g. a success/fail status that we
can prove is always success, or just the current implementation always returns
success but the callers still check.
int call_constant() { return 10 - get_constant(); }
callget_constant()
movl$10, %edx
subl%eax, %edx
movl%edx, %eax
ret
Even though the function didn't inline so we still have to call it, its return
value is a compile-time constant.
call get_constant
mov $(10-42), %eax
ret
would be a better way to compile this. It potentially breaks a data dependency
chain, and saves instructions. And enables further constprop if the caller
isn't trivial and does more with the return value.
For return values passed by hidden pointer, it avoids store-forwarding latency.
If we want the value in memory, we can use the copy the callee put there. If
we made a .clone version that uses a custom calling convention, we could have
the callee skip storing the return value if it's constant for all callers.
(Hmm, checking this could cost a lot of compile time, especially with LTO. The
simpler version is to only optimize it away for small objects that are really
constant, not just from constant propagation from one caller's args.)
One useful case is returning a std::optional<>. Even if the .value() is
unknown, it might be known that there *is* a value, so the caller doesn't have
to check the `bool` member.
libstdc++'s optional is not trivially-copyable even if T is, so it returns
via hidden pointer for optional. (libc++ does implement it that way, so
it returns packed into a register in x86-64, but clang also still checks the
return value when it doesn't inline.
https://stackoverflow.com/a/46546636/224132)
int baz() {
return 1 + get_std_optional_int().value();
}
subq$24, %rsp
leaq8(%rsp), %rdi
callget_std_optional_int()
cmpb$0, 12(%rsp)
je .L98
movl8(%rsp), %eax
addq$24, %rsp
addl$1, %eax
ret
baz() [clone .cold.49]:
.L98:
callabort
This obviously simplifies the call site some if we don't have to check the
return value.
But we still have to provide storage space unless we make a
nonstandard-calling-convention clone of get_std_optional_int() which ideally
returns in %eax and %edx. (Returning small objects packed less tightly into
multiple registers would probably be a win in general for non-constant return
values, if we want to start cloning static functions and discarding the
ABI-compliant definition. Or with LTO or whole-program, as this post argues:
https://stackoverflow.com/a/46549978/224132)
[Bug target/82411] const is not always read-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82411 --- Comment #3 from Kees Cook --- To clarify, using -mno-sdata means all things are removed from sdata, not just const, yes? I'd like to be able to leave writable stuff there, to avoid any additional performance penalty.
[Bug c++/80471] (gcc extension) Forwarding-reference `auto` function parameters do not follow the same rules as template functions or generic lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80471 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #2 from Paolo Carlini --- Works fine with the released 7.1.0.
[Bug c++/80471] (gcc extension) Forwarding-reference `auto` function parameters do not follow the same rules as template functions or generic lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80471 --- Comment #1 from paolo at gcc dot gnu.org --- Author: paolo Date: Wed Oct 4 21:25:20 2017 New Revision: 253432 URL: https://gcc.gnu.org/viewcvs?rev=253432&root=gcc&view=rev Log: 2017-10-04 Paolo Carlini PR c++/80471 * g++.dg/cpp1y/pr80471.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp1y/pr80471.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug ada/82393] Compilation error on cygwin64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82393 --- Comment #10 from Eric Botcazou --- > PS : Do you know we certainly live separated by 3,5 km at Toulouse City ? > I live at 35, rue Edmond Rostand 31200 ... :-) OK, this is a small world. :-)
[Bug ada/82393] Compilation error on cygwin64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82393 --- Comment #9 from Eric Botcazou --- > Trace of check ada runtests You can do 'make mail-report.log' after 'make -k check' to have a report. The results are acceptable although gnat.dg/entry_queues.adb and c380004, which probably come from the same underlying issue, would need to be investigated.
[Bug ada/82393] Compilation error on cygwin64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82393 Eric Botcazou changed: What|Removed |Added Status|WAITING |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #8 from Eric Botcazou --- Fixing.
[Bug c++/78131] Inconsistent evaluation for `constexpr` lambdas in templates between `static_assert`, `if constexpr(…)` and `constexpr` variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78131 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #2 from Paolo Carlini --- Fixed in trunk.
[Bug c++/78131] Inconsistent evaluation for `constexpr` lambdas in templates between `static_assert`, `if constexpr(…)` and `constexpr` variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78131 --- Comment #1 from paolo at gcc dot gnu.org --- Author: paolo Date: Wed Oct 4 20:58:52 2017 New Revision: 253431 URL: https://gcc.gnu.org/viewcvs?rev=253431&root=gcc&view=rev Log: 2017-10-04 Paolo Carlini PR c++/78131 * g++.dg/cpp1z/constexpr-lambda17.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-lambda17.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/54367] [meta-bug] lambda expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367 Bug 54367 depends on bug 78018, which changed state. Bug 78018 Summary: [C++14] "internal compiler error: Segmentation fault" with templates and lambdas https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78018 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/78018] [C++14] "internal compiler error: Segmentation fault" with templates and lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78018 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED CC|andipeer at gmx dot net| Blocks||54367 Resolution|--- |FIXED Target Milestone|--- |6.4 --- Comment #3 from Paolo Carlini --- Fixed in 6.4.0. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367 [Bug 54367] [meta-bug] lambda expressions
[Bug c++/78018] [C++14] "internal compiler error: Segmentation fault" with templates and lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78018 --- Comment #2 from paolo at gcc dot gnu.org --- Author: paolo Date: Wed Oct 4 20:34:03 2017 New Revision: 253430 URL: https://gcc.gnu.org/viewcvs?rev=253430&root=gcc&view=rev Log: 2017-10-04 Paolo Carlini PR c++/78018 * g++.dg/cpp1y/lambda-generic-78018.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-78018.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/81236] Crash when calling a template member function from generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81236 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.3 --- Comment #8 from Jason Merrill --- Fixed for 7.3/8.
[Bug c++/80935] [C++1z] incorrect error 'uninitialized variable in constexpr function' when conditionally declaring variable inside lambda inside template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80935 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.3 --- Comment #6 from Jason Merrill --- Fixed for 7.3/8.
[Bug c++/80767] Eager instantiation of generic lambda body when not required
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80767 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.3 --- Comment #7 from Jason Merrill --- Fixed for 7.3/8.
[Bug driver/31350] gcc -v --help puts some output on std. out, and some on std. error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31350 Ladislas de Toldi changed: What|Removed |Added CC||ladislas at leka dot io --- Comment #3 from Ladislas de Toldi --- I confirm this is also the case for avr-gcc This is what I get to stderr: --- Using built-in specs. Reading specs from /usr/local/Cellar/avr-gcc/7.2.0/lib/gcc/avr/7.2.0/device-specs/specs-avr2 COLLECT_GCC=avr-gcc COLLECT_LTO_WRAPPER=/usr/local/Cellar/avr-gcc/7.2.0/libexec/gcc/avr/7.2.0/lto-wrapper Target: avr Configured with: ../configure --target=avr --prefix=/usr/local/Cellar/avr-gcc/7.2.0 --enable-languages=c,c++ --with-ld=/usr/local/opt/avr-binutils/bin/avr-ld --with-as=/usr/local/opt/avr-binutils/bin/avr-as --disable-nls --disable-libssp --disable-shared --disable-threads --disable-libgomp --with-dwarf2 Thread model: single gcc version 7.2.0 (GCC)
[Bug c++/81525] [7 Regression] Invalid codegen with constexpr variable template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81525 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Jason Merrill --- Fixed.
[Bug other/82368] [8 regression] with r253275 several new test cases in libbacktrace fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82368 --- Comment #6 from seurer at gcc dot gnu.org --- The title is correct, the new failures did show up starting with r253275. I mistyped it in my description and there doesn't appear to be a way to update that, sorry.
[Bug c++/82406] [7 Regression] Rejects a valid snippet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82406 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jason Merrill --- Backported the fix.
[Bug c++/82406] [7 Regression] Rejects a valid snippet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82406 --- Comment #2 from Jason Merrill --- Author: jason Date: Wed Oct 4 17:47:51 2017 New Revision: 253425 URL: https://gcc.gnu.org/viewcvs?rev=253425&root=gcc&view=rev Log: PR c++/82406 - C++17 error with noexcept function type * g++.dg/ext/attrib54.C: New. Added: trunk/gcc/testsuite/g++.dg/ext/attrib54.C
[Bug c++/82406] [7 Regression] Rejects a valid snippet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82406 --- Comment #1 from Jason Merrill --- Author: jason Date: Wed Oct 4 17:47:08 2017 New Revision: 253424 URL: https://gcc.gnu.org/viewcvs?rev=253424&root=gcc&view=rev Log: PR c++/82406 - C++17 error with noexcept function type PR c++/70029 - ICE with ref-qualifier and -flto gcc/ * langhooks.h (struct lang_hooks_for_types): Add copy_lang_qualifiers. * langhooks-def.h (LANG_HOOKS_COPY_LANG_QUALIFIERS): Default to NULL. (LANG_HOOKS_FOR_TYPES_INITIALIZER): Use it. * tree.c (verify_type): Re-enable TYPE_CANONICAL main variant check. (build_type_attribute_qual_variant): Use copy_lang_qualifiers. gcc/cp/ * tree.c (cxx_copy_lang_qualifiers): New. * cp-tree.h: Declare it. * cp-objcp-common.h: Define LANG_HOOKS_COPY_LANG_QUALIFIERS. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/ext/attrib54.C branches/gcc-7-branch/gcc/testsuite/g++.dg/lto/pr70029_0.C Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/cp/ChangeLog branches/gcc-7-branch/gcc/cp/cp-objcp-common.h branches/gcc-7-branch/gcc/cp/cp-tree.h branches/gcc-7-branch/gcc/cp/tree.c branches/gcc-7-branch/gcc/langhooks-def.h branches/gcc-7-branch/gcc/langhooks.h branches/gcc-7-branch/gcc/tree.c
[Bug c++/70029] [8 Regression] ICE with C++11 and -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70029 --- Comment #17 from Jason Merrill --- Author: jason Date: Wed Oct 4 17:47:08 2017 New Revision: 253424 URL: https://gcc.gnu.org/viewcvs?rev=253424&root=gcc&view=rev Log: PR c++/82406 - C++17 error with noexcept function type PR c++/70029 - ICE with ref-qualifier and -flto gcc/ * langhooks.h (struct lang_hooks_for_types): Add copy_lang_qualifiers. * langhooks-def.h (LANG_HOOKS_COPY_LANG_QUALIFIERS): Default to NULL. (LANG_HOOKS_FOR_TYPES_INITIALIZER): Use it. * tree.c (verify_type): Re-enable TYPE_CANONICAL main variant check. (build_type_attribute_qual_variant): Use copy_lang_qualifiers. gcc/cp/ * tree.c (cxx_copy_lang_qualifiers): New. * cp-tree.h: Declare it. * cp-objcp-common.h: Define LANG_HOOKS_COPY_LANG_QUALIFIERS. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/ext/attrib54.C branches/gcc-7-branch/gcc/testsuite/g++.dg/lto/pr70029_0.C Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/cp/ChangeLog branches/gcc-7-branch/gcc/cp/cp-objcp-common.h branches/gcc-7-branch/gcc/cp/cp-tree.h branches/gcc-7-branch/gcc/cp/tree.c branches/gcc-7-branch/gcc/langhooks-def.h branches/gcc-7-branch/gcc/langhooks.h branches/gcc-7-branch/gcc/tree.c
[Bug middle-end/82407] [8 Regression][meta-bug] qsort_chk fallout tracking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82407 Bug 82407 depends on bug 82396, which changed state. Bug 82396 Summary: [8 Regression] qsort comparator non-negative on sorted output: 4 in ready_sort_real in haifa scheduler https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82396 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug rtl-optimization/82396] [8 Regression] qsort comparator non-negative on sorted output: 4 in ready_sort_real in haifa scheduler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82396 Steve Ellcey changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #10 from Steve Ellcey --- I am still seeing a build failure on aarch64. /home/sellcey/cavium-pr-27386/obj/gcc/aarch64-unknown-linux-gnu/libstdc++-v3/include/bits/deque.tcc:626:7: error: qsort comparator non-negative on sorted output: 8 } ^ during RTL pass: sched2 /home/sellcey/cavium-pr-27386/obj/gcc/aarch64-unknown-linux-gnu/libstdc++-v3/include/bits/deque.tcc:626:7: internal compiler error: qsort checking failed 0x5e3aaf qsort_chk_error ../../../src/gcc/gcc/vec.c:222 0x14edcb7 qsort_chk(void*, unsigned long, unsigned long, int (*)(void const*, void const*)) ../../../src/gcc/gcc/vec.c:274 0x1400727 ready_sort_real ../../../src/gcc/gcc/haifa-sched.c:3087 0x1406c03 schedule_block(basic_block_def**, void*) ../../../src/gcc/gcc/haifa-sched.c:6749 0xd846eb schedule_region ../../../src/gcc/gcc/sched-rgn.c:3174 0xd846eb schedule_insns() ../../../src/gcc/gcc/sched-rgn.c:3513 0xd84b6b schedule_insns() ../../../src/gcc/gcc/sched-rgn.c:3498 0xd84b6b rest_of_handle_sched2 ../../../src/gcc/gcc/sched-rgn.c:3737 0xd84b6b execute ../../../src/gcc/gcc/sched-rgn.c:3873
[Bug ada/82393] Compilation error on cygwin64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82393 --- Comment #7 from Didier G --- Attached, the trace of ada run tests. Please, feel free to inform me about output files to watch. I will do my best to review and report them. Best Regards, Didier. PS : Do you know we certainly live separated by 3,5 km at Toulouse City ? I live at 35, rue Edmond Rostand 31200 ... :-)
[Bug ada/82393] Compilation error on cygwin64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82393 --- Comment #6 from Didier G --- Created attachment 42303 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42303&action=edit Trace of check ada runtests
[Bug c++/54367] [meta-bug] lambda expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367 Bug 54367 depends on bug 71946, which changed state. Bug 71946 Summary: asm in toplevel lambda function rejected https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71946 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/71946] asm in toplevel lambda function rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71946 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC|paolo.carlini at oracle dot com| Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org Target Milestone|--- |8.0 --- Comment #9 from Paolo Carlini --- Fixed.
[Bug c++/71946] asm in toplevel lambda function rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71946 --- Comment #8 from paolo at gcc dot gnu.org --- Author: paolo Date: Wed Oct 4 17:21:21 2017 New Revision: 253423 URL: https://gcc.gnu.org/viewcvs?rev=253423&root=gcc&view=rev Log: /cp 2017-10-04 Paolo Carlini Andrew Pinski PR c++/71946 * parser.c (cp_parser_lambda_body): Set parser->in_function_body. /testsuite 2017-10-04 Paolo Carlini Andrew Pinski PR c++/71946 * g++.dg/cpp0x/lambda/lambda-asm1.C: New. * g++.dg/cpp0x/lambda/lambda-stmtexpr1.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-asm1.C trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-stmtexpr1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/82369] "optimizes" indexed addressing back into two pointer increments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82369
--- Comment #4 from amker at gcc dot gnu.org ---
Hmm, with expansion, IVOPTs can find address type uses as:
Group 0:
Type: ADDRESS
Use 0.0:
At stmt:_25 = *_6;
At pos: *_6
IV struct:
Type: const __m128i_u * {ref-all}
Base: (const __m128i_u * {ref-all}) src_15(D)
Step: 32
Object: (void *) src_15(D)
Biv: N
Overflowness wrto loop niter: Overflow
Group 1:
Type: ADDRESS
Use 1.0:
At stmt:*dstu.2_9 = _23;
At pos: *dstu.2_9
IV struct:
Type: __m128i_u * {ref-all}
Base: (__m128i_u * {ref-all}) dst_12(D)
Step: 16
Object: (void *) dst_12(D)
Biv: N
Overflowness wrto loop niter: Overflow
Group 2:
Type: COMPARE
Use 2.0:
At stmt:if (end_dst_14 > dstu_22)
At pos: dstu_22
IV struct:
Type: uintptr_t
Base: (uintptr_t) dst_12(D) + 16
Step: 16
Biv: Y
Overflowness wrto loop niter: Overflow
Group 3:
Type: ADDRESS
Use 3.0:
At stmt:_24 = *_8;
At pos: *_8
IV struct:
Type: const __m128i_u * {ref-all}
Base: (const __m128i_u * {ref-all}) (src_15(D) + 16)
Step: 32
Object: (void *) src_15(D)
Biv: N
Overflowness wrto loop niter: Overflow
But it's less likely to express all address type uses with dstu because they
have different base object. In general, we don't allow expressing reference to
one base object using pointer pointing to different base object. This case is
a bit tricky because the addresses are computed and casted from uintptr_t,
which means we can assume result pointers are valid to point to any address?
Even it's valid to rewrite load like MEM[src_dst_offset + dstu << 1], it's hard
to do so in current IVOPTs because it's implemented on the basis of
base_object.
Richi, any comments?
Thanks,
bin
[Bug rtl-optimization/82396] [8 Regression] qsort comparator non-negative on sorted output: 4 in ready_sort_real in haifa scheduler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82396 --- Comment #9 from Wilco --- Author: wilco Date: Wed Oct 4 16:40:44 2017 New Revision: 253419 URL: https://gcc.gnu.org/viewcvs?rev=253419&root=gcc&view=rev Log: Revert r253399: PR rtl-optimization/82396 * haifa-sched.c (autopref_multipass_init): Simplify initialization. (autopref_rank_data): Simplify sort order. * sched-int.h (autopref_multipass_data_): Remove multi_mem_insn_p, min_offset and max_offset. Modified: trunk/gcc/ChangeLog trunk/gcc/haifa-sched.c trunk/gcc/sched-int.h
[Bug tree-optimization/82429] strcpy to stpcpy transformation disabled in strict mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82429 --- Comment #2 from joseph at codesourcery dot com --- Strictly, that a program declares stpcpy should be irrelevant if the declaration is outside system headers, because it could declare and define it for some other purpose (even if the prototype matches). If declared *in system headers*, stpcpy can be assumed to have POSIX semantics; likewise if __builtin_stpcpy is called by the program (because calling __builtin_stpcpy implies it's OK to generate a call to stpcpy for such a call, so stpcpy can be assumed to have POSIX semantics).
[Bug tree-optimization/82405] Function not inlined for switch and suboptimal assembly is generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82405 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug ipa/67368] Inlining failed due to no_sanitize_address and always_inline conflict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368 Loïc Yhuel changed: What|Removed |Added CC||loic.yhuel at gmail dot com --- Comment #4 from Loïc Yhuel --- (In reply to Andrey Ryabinin from comment #3) > Nope, it was prohibited because no_sanitize_address didn't work for inlined > function https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59600. So this case should work : functions inlined into a no_sanitize_address function would have the sanitizer disabled. Unlike the opposite, which could crash, this one only could fail to detect issues at runtime, so perhaps it should only be a warning.
[Bug c++/82405] Function not inlined for switch and suboptimal assembly is generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82405
--- Comment #11 from Andrew Pinski ---
Thinking about this some more, this is a not a hoisting problem but a sinking
problem.
basically we have:
int f(void);
int h(void);
int g(int a)
{
if (a)
return f() + 10;
return h() + 10;
}
Which should be converted into:
int g1(int a)
{
int t;
if (a)
t = f();
else
t = h();
return t + 10;
}
We handle hoisting just fine; just not sinking common.
So we don't need reassoc in the original testcase if we do sinking.
[Bug target/82430] [5/6/7/8 Regression] Suboptimal code generated because of unnecessary "pxor xmm0, xmm0"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82430 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- Dup of bug 82409. *** This bug has been marked as a duplicate of bug 82409 ***
[Bug target/82409] Superflous pxor instructions in the generated assembly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82409 Andrew Pinski changed: What|Removed |Added CC||antoshkka at gmail dot com --- Comment #3 from Andrew Pinski --- *** Bug 82430 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/82369] "optimizes" indexed addressing back into two pointer increments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82369
--- Comment #3 from amker at gcc dot gnu.org ---
Given IR dump before IVOPTs:
[15.00%] [count: INV]:
_1 = dst_12(D) + bytes_13(D);
end_dst_14 = (uintptr_t) _1;
srcu_16 = (uintptr_t) src_15(D);
dstu_17 = (uintptr_t) dst_12(D);
_2 = dstu_17 * 2;
_3 = srcu_16 - _2;
[100.00%] [count: INV]:
# dstu_10 = PHI
_4 = dstu_10 * 2;
_5 = _3 + _4;
_6 = (const __m128i_u * {ref-all}) _5;
_25 = *_6;
When ivopts tries to find address type IV for "*_6", the base it has is like:
(const __m128i_u * {ref-all}) ((uintptr_t) dst_12(D) * 2 + _3)
If we do more aggressive expansion for "_3", we could have:
(const __m128i_u * {ref-all}) (srcu_16)
So without the expansion, we can't find the base object for the address in
alloc_iv, that's why we failed to classify _6 as an address type IV. As a
result, addressing mode is not considered in choosing candidate, thus wrong
candidate chosen in the end.
OTOH, we surely don't want to do aggressive expansion because that introduces
more code into loop. One possible fix is to do aggressive expansion for
analysis purpose, rather than unconditionally (or for code generation purpose).
For example, we can try aggressive expansion when alloc_iv fails to find base
object, see if it can do better.
Thanks,
bin
[Bug c++/82373] syntax error in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82373 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Wed Oct 4 16:15:36 2017 New Revision: 253418 URL: https://gcc.gnu.org/viewcvs?rev=253418&root=gcc&view=rev Log: PR c++/82373 * error.c (dump_function_decl): If show_return, call dump_type_suffix on the same return type dump_type_prefix has been called on. * g++.dg/cpp1y/pr82373.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp1y/pr82373.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c trunk/gcc/testsuite/ChangeLog
[Bug c++/81525] [7 Regression] Invalid codegen with constexpr variable template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81525 --- Comment #11 from Jason Merrill --- Author: jason Date: Wed Oct 4 15:38:24 2017 New Revision: 253415 URL: https://gcc.gnu.org/viewcvs?rev=253415&root=gcc&view=rev Log: PR c++/81525 - broken handling of auto in generic lambda. * pt.c (tsubst_decl) [VAR_DECL]: Use strip_innermost_template_args. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp1y/lambda-generic-auto1.C Modified: branches/gcc-7-branch/gcc/cp/ChangeLog branches/gcc-7-branch/gcc/cp/pt.c
[Bug ada/82393] Compilation error on cygwin64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82393 --- Comment #5 from Didier G --- OK. Build succeed. Tests in progress ...
[Bug c++/81525] [7 Regression] Invalid codegen with constexpr variable template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81525 --- Comment #10 from Jason Merrill --- Author: jason Date: Wed Oct 4 15:37:09 2017 New Revision: 253414 URL: https://gcc.gnu.org/viewcvs?rev=253414&root=gcc&view=rev Log: PR c++/81525 - broken handling of auto in generic lambda. * pt.c (tsubst_decl) [VAR_DECL]: Use strip_innermost_template_args. Added: trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-auto1.C trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-const4a.C - copied, changed from r253410, trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-const4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-const4.C
[Bug tree-optimization/82429] strcpy to stpcpy transformation disabled in strict mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82429
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
Well, it matches the behavior of the stpcpy function in strict mode:
If you try:
char *stpcpy (char *, const char *);
char *foo (char *p) { return stpcpy (p, "abcd"); }
char *bar (char *p) { return __builtin_stpcpy (p, "abcd"); }
then in strict mode only bar will be optimized into memcpy or (inlined memcpy),
while foo will call stpcpy.
[Bug fortran/82431] [8 Regression] Rejects 416.gamess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82431 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-10-04 CC||dominiq at gcc dot gnu.org, ||tkoenig at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Thomas Koenig --- This was an intentional change introduced by https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=253286 -std=legacy should allow compilation. If that works, we can then discuss if we close this bug as WONTFIX or as INVALID :-)
[Bug target/82430] [5/6/7/8 Regression] Suboptimal code generated because of unnecessary "pxor xmm0, xmm0"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82430 Jakub Jelinek changed: What|Removed |Added CC||uros at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Oops, no, that change only changed xorpd into pxor. The actual change that introduced the xoring was r201308, aka PR57954 and PR57988. So can you explain why you think the xors aren't necessary to avoid partial sse dependency stalls?
[Bug testsuite/82412] [8 regression] gfortran.dg/graphite/pr42334-1.f fails starting with r253342
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82412 --- Comment #3 from seurer at gcc dot gnu.org --- Oh, and ISL is what comes from contrib/download_prerequisites. isl-0.18 in this case.
[Bug c++/82424] [8 Regression] ICE in tree check: expected record_type or union_type or qual_union_type, have typename_type in lookup_base, at cp/search.c:203
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82424 Nathan Sidwell changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-10-04 Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org Ever confirmed|0 |1
[Bug testsuite/82412] [8 regression] gfortran.dg/graphite/pr42334-1.f fails starting with r253342
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82412 seurer at gcc dot gnu.org changed: What|Removed |Added CC||seurer at gcc dot gnu.org --- Comment #2 from seurer at gcc dot gnu.org --- Created attachment 42302 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42302&action=edit Tree dump for gfortran.dg/graphite/pr42334-1.f I am still seeing the same thing with r253411. I am attaching a tree dump.
[Bug target/82430] [5/6/7/8 Regression] Suboptimal code generated because of unnecessary "pxor xmm0, xmm0"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82430 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- We started doing it with r203387 and it is intentional. See http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00722.html for more details.
[Bug fortran/82431] [8 Regression] Rejects 416.gamess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82431 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug fortran/82431] New: [8 Regression] Rejects 416.gamess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82431 Bug ID: 82431 Summary: [8 Regression] Rejects 416.gamess Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- 416.gamess now fails to build with the following. Is there a workaround available to slilence the error? SPEC is known to have many mismatching sizes. /space/rguenther/install-trunk/usr/local/bin/gfortran -c -o ecp.fppized.o -Ofast -march=native -floop-nest-optimize --param graphite-allow-codegen-errors=1 --param graphite-max-nb-scop-params=0 --param graphite-max-arrays-per-scop=0 -Wl,-rpath=/space/rguenther/install-trunk/usr/local/lib64 -DSPEC_CPU_LP64 -ffixed-form ecp.fppized.f ecp.fppized.f:402:15: CALL ZFN(ZFNLM,NPNP-1,ZLM,LMF,LMX,LMY,LMZ) 1 Error: Actual argument contains too few elements for dummy argument 'zfnlm' (121/125) at (1) ecp.fppized.f:544:18: CALL ZFN(ZFNLM,NPNP-1,ZLM,LMF,LMX,LMY,LMZ) 1 Error: Actual argument contains too few elements for dummy argument 'zfnlm' (121/125) at (1) ecp.fppized.f:739:24: CALL ZFN(ZFNLM,NPNP-1,ZLM,LMF,LMX,LMY,LMZ) 1 Error: Actual argument contains too few elements for dummy argument 'zfnlm' (121/125) at (1) ecp.fppized.f:994:18: CALL ZFN(ZFNLMC,NPCPL-1,ZLM,LMF,LMX,LMY,LMZ) 1 Error: Actual argument contains too few elements for dummy argument 'zfnlm' (121/125) at (1) ecp.fppized.f:998:18: CALL ZFN(ZFNLMB,NPBPL-1,ZLM,LMF,LMX,LMY,LMZ) 1 Error: Actual argument contains too few elements for dummy argument 'zfnlm' (121/125) at (1) specmake: *** [ecp.fppized.o] Error 1 specmake: *** Waiting for unfinished jobs
[Bug target/82430] [5/6/7/8 Regression] Suboptimal code generated because of unnecessary "pxor xmm0, xmm0"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82430 Richard Biener changed: What|Removed |Added Target||x86_64-*-* Known to work||4.8.5 Target Milestone|--- |5.5 Summary|[4.9 Regression] Suboptimal |[5/6/7/8 Regression] |code generated because of |Suboptimal code generated |unnecessary "pxor xmm0, |because of unnecessary |xmm0" |"pxor xmm0, xmm0"
[Bug target/82430] New: [4.9 Regression] Suboptimal code generated because of unnecessary "pxor xmm0, xmm0"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82430
Bug ID: 82430
Summary: [4.9 Regression] Suboptimal code generated because of
unnecessary "pxor xmm0, xmm0"
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
Following code snippets
unsigned my_mul(unsigned a) {
return a * 1.5;
}
unsigned my_div(unsigned a) {
return a / 1.5;
}
Generate assemblies that have "pxor xmm0, xmm0" as a first instruction:
my_mul(unsigned int):
pxor xmm0, xmm0 <=== This is not necessary
mov edi, edi
cvtsi2sdq xmm0, rdi
mulsd xmm0, QWORD PTR .LC0[rip]
cvttsd2si rax, xmm0
ret
my_div(unsigned int):
pxor xmm0, xmm0 <=== This is not necessary
mov edi, edi
cvtsi2sdq xmm0, rdi
divsd xmm0, QWORD PTR .LC0[rip]
cvttsd2si rax, xmm0
ret
The regression was introduced with GCC 4.9. GCC-4.8 and previous versions were
generating assembly without pxor:
my_mul(unsigned int):
mov edi, edi
cvtsi2sd xmm0, rdi
mulsd xmm0, QWORD PTR .LC0[rip]
cvttsd2si rax, xmm0
ret
my_div(unsigned int):
mov edi, edi
cvtsi2sd xmm0, rdi
divsd xmm0, QWORD PTR .LC0[rip]
cvttsd2si rax, xmm0
ret
[Bug debug/82425] [8 regression] gcc.dg/guality/inline-params-2.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82425 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-10-04 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |8.0 Ever confirmed|0 |1
[Bug tree-optimization/82429] New: strcpy to stpcpy transformation disabled in strict mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82429
Bug ID: 82429
Summary: strcpy to stpcpy transformation disabled in strict
mode
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
In https://gcc.gnu.org/ml/gcc/2017-10/msg00010.html Jakub explains that the
strcpy to stpcpy optimizing transformation that is normally disabled in strict
conformance modes (e.g., with -std=c11 rather than -std=gnu11) is meant to be
enabled by defining _GNU_SOURCE, or _POSIX_C_SOURCE=200809, or
_XOPEN_SOURCE=700, or various other feature test macros that cause stpcpy to be
declared in system headers.
However, as the test case below shows (from
https://gcc.gnu.org/ml/gcc/2017-10/msg00015.html in the same thread), this is
not what actually happens. What appears to be necessary in addition to
defining one of the feature test macros above is also explicitly declaring the
stpcpy function in the program. A declaration alone in one of the system
headers is not sufficient. This seems like a bug. Explicitly declaring a
standard function that's already declared in a system header shouldn't have an
impact on the quality of emitted code.
$ cat z.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout
-std=c11 -D_GNU_SOURCE z.c
#include
#if STPCPY
extern char* stpcpy (char*, const char*);
#endif
void __attribute__ ((noclone)) f (char *d, const char *s)
{
strcpy (d, s); // with -D_GNU_SOURCE strcpy is expected to be transformed
to stpcpy
if (__builtin_strlen (d) != __builtin_strlen (s))
__builtin_abort ();
}
;; Function f (f, funcdef_no=4, decl_uid=1972, cgraph_uid=4, symbol_order=4)
__attribute__((noclone))
f (char * d, const char * s)
{
long unsigned int _1;
long unsigned int _2;
[100.00%] [count: INV]:
strcpy (d_4(D), s_5(D)); // strcpy not transformed to stpcpy
_1 = __builtin_strlen (d_4(D));
_2 = __builtin_strlen (s_5(D));
if (_1 != _2)
goto ; [0.04%] [count: 0]
else
goto ; [99.96%] [count: INV]
[0.04%] [count: 0]:
__builtin_abort ();
[99.96%] [count: INV]:
return;
}
$ gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout -std=c11
-D_GNU_SOURCE -DSTPCPY z.c
;; Function f (f, funcdef_no=4, decl_uid=1975, cgraph_uid=4, symbol_order=4)
__attribute__((noclone))
f (char * d, const char * s)
{
long unsigned int _1;
long unsigned int _2;
char * _8;
long unsigned int _9;
long unsigned int _10;
[100.00%] [count: INV]:
_8 = __builtin_stpcpy (d_4(D), s_5(D)); // strcpy transformed to stpcpy
_9 = (long unsigned int) _8;
_10 = (long unsigned int) d_4(D);
_1 = _9 - _10;
_2 = __builtin_strlen (s_5(D));
if (_1 != _2)
goto ; [0.04%] [count: 0]
else
goto ; [99.96%] [count: INV]
[0.04%] [count: 0]:
__builtin_abort ();
[99.96%] [count: INV]:
return;
}
[Bug tree-optimization/82397] [8 Regression] qsort comparator non-negative on sorted output: 1 in vect_analyze_data_ref_accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82397 --- Comment #4 from rguenther at suse dot de --- On Wed, 4 Oct 2017, amonakov at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82397 > > --- Comment #3 from Alexander Monakov --- > Is it possible to simply invoke data_ref_compare_tree always, without checking > operand_equal_p beforehand? It's possible to canonicalize commutative chains > in > data_ref_compare_tree, or - even better - while generating trees in the first > place; I don't understand why the operand_equal_p checks are there, they seem > more costly than what data_ref_compare_tree does. I believe we exactly left them there because they catches more equalities and data_ref_compare_tree was supposed to only order non-equal ones.
[Bug libgomp/82428] New: Builtins for openacc gang/worker/vector id/size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82428
Bug ID: 82428
Summary: Builtins for openacc gang/worker/vector id/size
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
We have openacc test-cases using the following nvptx idiom:
...
__asm__ volatile ("mov.u32 %0,%%ctaid.x;" : "=r" (g));
__asm__ volatile ("mov.u32 %0,%%tid.y;" : "=r" (w));
__asm__ volatile ("mov.u32 %0,%%tid.x;" : "=r" (v));
...
Typically this is done guarded with acc_on_device (acc_device_nvidia), and
skipping -O0:
...
/* This code uses nvptx inline assembly guarded with acc_on_device, which is
not optimized away at -O0, and then confuses the target assembler.
{ dg-skip-if "" { *-*-* } { "-O0" } { "" } } */
...
It would be better to have generic openacc builtins
__builtin__goacc_{gang,worker,vector}_{id,size}, and use those in the testcase
instead. These could be used at -O0, and without the need to guarded them with
acc_on_device.
[Bug other/82368] [8 regression] with r253275 several new test cases in libbacktrace fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82368 --- Comment #5 from Andrey Guskov --- Please update the bug header: s/235275/253275/
[Bug other/82368] [8 regression] with r253275 several new test cases in libbacktrace fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82368 --- Comment #4 from Andrey Guskov --- Damn. Sorry for the false alarm. The correct revision had to be r253275.
[Bug libstdc++/82427] gcc-7.2.1 error: '::mktime' has not been declared using ::mktime;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82427 Jonathan Wakely changed: What|Removed |Added Resolution|FIXED |INVALID
[Bug tree-optimization/80155] [7/8 regression] Performance regression with code hoisting enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155 --- Comment #32 from Thomas Preud'homme --- (In reply to rguent...@suse.de from comment #31) > On Wed, 4 Oct 2017, prathamesh3492 at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155 > > > > prathamesh3492 at gcc dot gnu.org changed: > > > >What|Removed |Added > > > > CC||prathamesh3492 at gcc dot > > gnu.org > > > > --- Comment #30 from prathamesh3492 at gcc dot gnu.org --- > > Hi Richard, > > I tried your patch in comment #9 with the fix in comment #13 but since > > tree-ssa-pre.c appears to be refactored, the fix doesn't apply anymore and > > ICE > > resurfaces. Could you guide me what fix I should apply to reproduce the > > regression ? IIUC the issue here is that code-hoisting is increasing > > register > > pressure thus causing the extra spill ? And GIMPLE does not seem to have > > cost > > model for register allocation. > > > > Are you planning to take a look at this PR soon ? If not I would like to > > give a > > try and would be grateful for suggestions on how to approach this bug. > > Thanks! > > Neither am I planning to look at this soon nor do I have a good idea > how to approach this bug. > > My ideas were to compute register pressure & update it during elimination > and thus avoid adding uses that increase pressure over some point. While > that might mitigate the issue it isn't in any way applying a cost model > to individual inserts. [nor is computing/updating register pressure easy] Hi, Looking at the testcase I attached to this ticket I'm regrettably not so sure they are representative of the issue we were facing which resulted from too much register pressure. With so few variable this is probably hitting some other bug. I'll try and come up with a better reduced testcase. Best regards.
[Bug other/82368] [8 regression] with r253275 several new test cases in libbacktrace fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82368 --- Comment #3 from Ian Lance Taylor --- Andrey: do you have more details? I don't see how this change, which does not affect the generated code in any way, could possibly cause a SPEC failure.
[Bug libstdc++/82427] gcc-7.2.1 error: '::mktime' has not been declared using ::mktime;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82427 mgansser at alice dot de changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #3 from mgansser at alice dot de --- Thank you for identifying the cause.
[Bug tree-optimization/82421] [8 Regression] [graphite] ICE: tree check: expected ssa_name, have integer_cst in get_rename, at graphite-isl-ast-to-gimple.c:1127
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82421 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 --- Probably trivial to fix tho I have a quite complex patch in development that fixes it as well.
[Bug tree-optimization/82422] [8 Regression][graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:248
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82422 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-10-04 Version|unknown |8.0 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |8.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Mine.
[Bug c++/82414] [5 Regression] Issue with ODR/LTO in G++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82414 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.5
[Bug testsuite/82412] [8 regression] gfortran.dg/graphite/pr42334-1.f fails starting with r253342
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82412 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0 --- Comment #1 from Richard Biener --- Can you check after my last update to the testcases? What ISL version are you using?
[Bug c++/82410] [7/8 Regression] ICE in replace_placeholders_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82410 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |7.3
[Bug c++/82406] [7 Regression] Rejects a valid snippet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82406 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/82405] Function not inlined for switch and suboptimal assembly is generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82405 --- Comment #10 from rguenther at suse dot de --- On Tue, 3 Oct 2017, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82405 > > --- Comment #9 from Jakub Jelinek --- > So it means maybe llvm performs more advanced switchconv in this case, at > least > judging from the #c0 assembly snippet. We look solely for PHIs which have > arguments SSA_NAMEs initialized in the cases to constants, while in order to > optimize this without -ffast-math, it would need to handle at least a couple > of > stmts where the operands match except for some constant argument that is > changing. > > [20.00%]: > _5 = r_4(D) * 4.0e+0; > _6 = r_4(D) * _5; > goto ; [100.00%] > > [20.00%]: > _7 = r_4(D) * 3.1415000181188397618825547397136688232421875e+0; > _8 = r_4(D) * _7; > goto ; [100.00%] > > So, in the above case we'd look from the PHI with _6 and _8 arguments, and see > that the because the def stmt isn't assignment from constant, we'd notice it > is > a binary (or unary or ternary) assign where one of the operands is identical > (r_4(D), while the other one is another SSA_NAME defined in the case, and we'd > loop to that, seeing another assign where one operand is the same and another > one is a constant. Thus, we'd build a table with the 4.0e+0 and > 3.1415000181188397618825547397136688232421875e+0 constants, and after > the load from the table did _21 = r_4(D) * value_loaded_from_table_20; _22 = > r_4(D) * _21; > The question is if we'd require all operands matching except for one which > could be a constant eventually, or something different (allow some small > number > of constant arguments to a computation). > > Or should we have a separate pass that performs such an optimization (noticing > similar code blocks with just changing constant parameters and merge the > blocks > except for computing the parameters)? Looks like sth for tail-merging / code hoisting? Of course we need to reassoc first (if valid). If the whole thing were if()s it may be PRE would already catch it.
[Bug tree-optimization/82402] [5/6/7/8 Regression] error: SSA_NAME_OCCURS_IN_ABNORMAL_PHI should be set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82402 Richard Biener changed: What|Removed |Added Keywords||ice-checking Priority|P3 |P2 CC||rguenth at gcc dot gnu.org Version|unknown |8.0 Target Milestone|--- |8.0 --- Comment #4 from Richard Biener --- Note AB or not AB isn't really relevant on virtuals...
[Bug c++/82401] [8 Regression] error: qsort comparator non-negative on sorted output: 1 in insert_late_enum_def_bindings on an invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82401 Richard Biener changed: What|Removed |Added Keywords||ice-checking Version|unknown |8.0 Target Milestone|--- |8.0 Summary|error: qsort comparator |[8 Regression] error: qsort |non-negative on sorted |comparator non-negative on |output: 1 in|sorted output: 1 in |insert_late_enum_def_bindin |insert_late_enum_def_bindin |gs on an invalid code |gs on an invalid code
[Bug libstdc++/82427] gcc-7.2.1 error: '::mktime' has not been declared using ::mktime;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82427 Jonathan Wakely changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from Jonathan Wakely --- Confirmed as a package bug, not a GCC bug: # 24 "/usr/include/pthread.h" 2 3 4 # 1 "chromaprint/libavutil/time.h" 1 3 4 # 29 "chromaprint/libavutil/time.h" 3 4 int64_t av_gettime(void); # 38 "chromaprint/libavutil/time.h" 3 4 int64_t av_gettime_relative(void); Using -Ichromaprint/avutil causes that file to be found instead of the standard header.
[Bug rtl-optimization/82398] [8 Regression] error: qsort comparator non-negative on sorted output: 2 in fill_vec_av_set at gcc/sel-sched.c:3725
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82398 Richard Biener changed: What|Removed |Added Keywords||ice-checking Version|unknown |8.0 Target Milestone|--- |8.0 Summary|error: qsort comparator |[8 Regression] error: qsort |non-negative on sorted |comparator non-negative on |output: 2 in|sorted output: 2 in |fill_vec_av_set at |fill_vec_av_set at |gcc/sel-sched.c:3725|gcc/sel-sched.c:3725
[Bug libstdc++/82427] gcc-7.2.1 error: '::mktime' has not been declared using ::mktime;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82427 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-10-04 Component|libgcc |libstdc++ Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- This has nothing to do with libgcc. The answer is probably that you've got some heaer file called time.h in your include paths, and that is being found instead of /usr/include/time.h WHen creating this bug you were asked to read https://gcc.gnu.org/bugs/ so please provide the information it asks for. The preprocessed source will show which time.h is being used (or you could check the preprocessed source yourself, and see if it's including /usr/include/time.h or some other file).
[Bug tree-optimization/80155] [7/8 regression] Performance regression with code hoisting enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155 --- Comment #31 from rguenther at suse dot de --- On Wed, 4 Oct 2017, prathamesh3492 at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155 > > prathamesh3492 at gcc dot gnu.org changed: > >What|Removed |Added > > CC||prathamesh3492 at gcc dot > gnu.org > > --- Comment #30 from prathamesh3492 at gcc dot gnu.org --- > Hi Richard, > I tried your patch in comment #9 with the fix in comment #13 but since > tree-ssa-pre.c appears to be refactored, the fix doesn't apply anymore and ICE > resurfaces. Could you guide me what fix I should apply to reproduce the > regression ? IIUC the issue here is that code-hoisting is increasing register > pressure thus causing the extra spill ? And GIMPLE does not seem to have cost > model for register allocation. > > Are you planning to take a look at this PR soon ? If not I would like to give > a > try and would be grateful for suggestions on how to approach this bug. > Thanks! Neither am I planning to look at this soon nor do I have a good idea how to approach this bug. My ideas were to compute register pressure & update it during elimination and thus avoid adding uses that increase pressure over some point. While that might mitigate the issue it isn't in any way applying a cost model to individual inserts. [nor is computing/updating register pressure easy]
[Bug target/82418] Division on a constant is suboptimal because of not using imul instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82418 Marc Glisse changed: What|Removed |Added Target||x86_64-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2017-10-04 Ever confirmed|0 |1
[Bug target/82418] Division on a constant is suboptimal because of not using imul instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82418 --- Comment #4 from Marc Glisse --- (In reply to Alexander Monakov from comment #3) > it's likely that your test measured something else, You are right, my test was bogus and clang's version is faster.
[Bug libgcc/82427] New: gcc-7.2.1 error: '::mktime' has not been declared using ::mktime;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82427 Bug ID: 82427 Summary: gcc-7.2.1 error: '::mktime' has not been declared using ::mktime; Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: martin.gansser at gmail dot com Target Milestone: --- when trying to compile miam-player on Fedora27 with gcc7 the following error message appears: g++ -c -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -g -std=gnu++11 -Wall -W -D_REENTRANT -fPIC -DUSE_SWRESAMPLE=1 -DMIAMACOUSTID_LIBRARY -DQT_MULTIMEDIA_LIB -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_SQL_LIB -DQT_CORE_LIB -I. -Ichromaprint -Ichromaprint/libavutil -Ichromaprint -I../core -I../core/3rdparty -I../core/3rdparty/QtAV -isystem /usr/include/qt5 -isystem /usr/include/qt5/QtMultimedia -isystem /usr/include/qt5/QtWidgets -isystem /usr/include/qt5/QtGui -isystem /usr/include/qt5/QtNetwork -isystem /usr/include/qt5/QtSql -isystem /usr/include/qt5/QtCore -Idebug/.moc -isystem /usr/include/libdrm -I. -I/usr/lib64/qt5/mkspecs/linux-g++ -o debug/.obj/mbrelease.o mbrelease.cpp make[1]: Leaving directory '/builddir/build/BUILD/Miam-Player-1a21b01a86c4cbcfe8fc6d99cf6e595838856b11/src/acoustid' In file included from /usr/include/c++/7/chrono:41:0, from /usr/include/qt5/QtCore/qobject.h:59, from /usr/include/qt5/QtCore/QObject:1, from mbrelease.h:5, from mbrelease.cpp:1: /usr/include/c++/7/ctime:64:11: error: '::clock' has not been declared using ::clock; ^ /usr/include/c++/7/ctime:65:11: error: '::difftime' has not been declared using ::difftime; ^~~~ /usr/include/c++/7/ctime:66:11: error: '::mktime' has not been declared using ::mktime; ^~ /usr/include/c++/7/ctime:67:11: error: '::time' has not been declared using ::time; ^~~~ /usr/include/c++/7/ctime:68:11: error: '::asctime' has not been declared using ::asctime; ^~~ /usr/include/c++/7/ctime:69:11: error: '::ctime' has not been declared using ::ctime; ^ /usr/include/c++/7/ctime:70:11: error: '::gmtime' has not been declared using ::gmtime; ^~ /usr/include/c++/7/ctime:71:11: error: '::localtime' has not been declared using ::localtime; ^ /usr/include/c++/7/ctime:72:11: error: '::strftime' has not been declared using ::strftime; ^~~~ make[1]: *** [Makefile:555: debug/.obj/mbrelease.o] Error 1 make[1]: *** Waiting for unfinished jobs full error message http://koji.rpmfusion.org/kojifiles/work/tasks/878/160878/build.log How can i solve this ? Many thanks
[Bug tree-optimization/82374] #pragma GCC optimize is not applied to openmp-generated functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82374 --- Comment #4 from Thomas Schwinge --- Author: tschwinge Date: Wed Oct 4 11:13:24 2017 New Revision: 253402 URL: https://gcc.gnu.org/viewcvs?rev=253402&root=gcc&view=rev Log: Adjust test cases for attributes propagation changes for OMP outlined regions PR tree-optimization/82374 * c-c++-common/goacc/kernels-double-reduction-n.c: Adjust for attributes propagation changes for OMP outlined regions. * c-c++-common/goacc/kernels-double-reduction.c: Likewise. * c-c++-common/goacc/kernels-reduction.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/goacc/kernels-double-reduction-n.c trunk/gcc/testsuite/c-c++-common/goacc/kernels-double-reduction.c trunk/gcc/testsuite/c-c++-common/goacc/kernels-reduction.c
[Bug target/82418] Division on a constant is suboptimal because of not using imul instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82418 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #3 from Alexander Monakov --- Marc, gcc code cannot be "several times" faster, it's likely that your test measured something else, can you share it? Clang's approach is also preferable because it doesn't tie up a temporary register to hold the immediate.
[Bug c/82413] [8 Regression] -O0 crash (ICE in decompose, at tree.h:5179)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82413 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from rsandifo at gcc dot gnu.org --- Patch applied.
[Bug c/82413] [8 Regression] -O0 crash (ICE in decompose, at tree.h:5179)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82413 --- Comment #5 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Wed Oct 4 10:50:19 2017 New Revision: 253401 URL: https://gcc.gnu.org/viewcvs?rev=253401&root=gcc&view=rev Log: PR82413: Mismatched precisions in build_range_check build_range_check explicitly allows LOW and HIGH to be a different type from EXP, so we need to use w::to_widest when comparing a value based on HIGH with a value based on EXP's type. 2017-10-04 Richard Sandiford gcc/ PR tree-optimization/82413 * fold-const.c (build_range_check): Use widest_int when comparing the maximum ETYPE value with HIGH. gcc/testsuite/ PR tree-optimization/82413 * g++.dg/pr82413.C: New test. Added: trunk/gcc/testsuite/g++.dg/pr82413.C Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/82397] [8 Regression] qsort comparator non-negative on sorted output: 1 in vect_analyze_data_ref_accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82397 --- Comment #3 from Alexander Monakov --- Is it possible to simply invoke data_ref_compare_tree always, without checking operand_equal_p beforehand? It's possible to canonicalize commutative chains in data_ref_compare_tree, or - even better - while generating trees in the first place; I don't understand why the operand_equal_p checks are there, they seem more costly than what data_ref_compare_tree does.
[Bug fortran/77296] [F03] Compiler Error with allocatable string and associate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77296 --- Comment #4 from Paul Thomas --- Author: pault Date: Wed Oct 4 10:43:45 2017 New Revision: 253400 URL: https://gcc.gnu.org/viewcvs?rev=253400&root=gcc&view=rev Log: 2017-10-04 Paul Thomas PR fortran/60458 PR fortran/77296 * resolve.c (resolve_assoc_var): Deferred character type associate names must not receive an integer conatant length. * symbol.c (gfc_is_associate_pointer): Deferred character length functions also require an associate pointer. * trans-decl.c (gfc_get_symbol_decl): Deferred character length functions or derived type components require the assoc name to have variable string length. * trans-stmt.c (trans_associate_var): Set the string length of deferred string length associate names. The address expression is not needed for allocatable, pointer or dummy targets. Change the comment about defered string length targets. 2017-10-04 Paul Thomas PR fortran/77296 * gfortran.dg/associate_32.f03 : New test. Added: trunk/gcc/testsuite/gfortran.dg/associate_32.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/60458] Error message on associate: deferred type parameter and requires either the pointer or allocatable attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60458 --- Comment #8 from Paul Thomas --- Author: pault Date: Wed Oct 4 10:43:45 2017 New Revision: 253400 URL: https://gcc.gnu.org/viewcvs?rev=253400&root=gcc&view=rev Log: 2017-10-04 Paul Thomas PR fortran/60458 PR fortran/77296 * resolve.c (resolve_assoc_var): Deferred character type associate names must not receive an integer conatant length. * symbol.c (gfc_is_associate_pointer): Deferred character length functions also require an associate pointer. * trans-decl.c (gfc_get_symbol_decl): Deferred character length functions or derived type components require the assoc name to have variable string length. * trans-stmt.c (trans_associate_var): Set the string length of deferred string length associate names. The address expression is not needed for allocatable, pointer or dummy targets. Change the comment about defered string length targets. 2017-10-04 Paul Thomas PR fortran/77296 * gfortran.dg/associate_32.f03 : New test. Added: trunk/gcc/testsuite/gfortran.dg/associate_32.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/82426] Missed tree-slp-vectorization on -O2 and -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82426 --- Comment #3 from Allan Jensen --- Note it appears the fact it can do it at all in -Os is new in gcc 7
[Bug c++/71946] asm in toplevel lambda function rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71946
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC||paolo.carlini at oracle dot com
Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle
dot com
--- Comment #7 from Paolo Carlini ---
I believe Andrew is right, it's just matter of setting the flag. The below
passes all my tests so far:
Index: parser.c
===
--- parser.c(revision 253396)
+++ parser.c(working copy)
@@ -10557,6 +10557,7 @@ cp_parser_lambda_body (cp_parser* parser, tree lam
{
bool nested = (current_function_decl != NULL_TREE);
bool local_variables_forbidden_p = parser->local_variables_forbidden_p;
+ bool in_function_body = parser->in_function_body;
if (nested)
push_function_context ();
else
@@ -10567,6 +10568,7 @@ cp_parser_lambda_body (cp_parser* parser, tree lam
save_omp_privatization_clauses (omp_privatization_save);
/* Clear this in case we're in the middle of a default argument. */
parser->local_variables_forbidden_p = false;
+ parser->in_function_body = true;
/* Finish the function call operator
- class_specifier
@@ -10653,6 +10655,7 @@ cp_parser_lambda_body (cp_parser* parser, tree lam
restore_omp_privatization_clauses (omp_privatization_save);
parser->local_variables_forbidden_p = local_variables_forbidden_p;
+ parser->in_function_body = in_function_body;
if (nested)
pop_function_context();
else
[Bug rtl-optimization/82396] [8 Regression] qsort comparator non-negative on sorted output: 4 in ready_sort_real in haifa scheduler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82396 Wilco changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Wilco --- Fixed
[Bug middle-end/82407] [8 Regression][meta-bug] qsort_chk fallout tracking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82407 Bug 82407 depends on bug 82396, which changed state. Bug 82396 Summary: [8 Regression] qsort comparator non-negative on sorted output: 4 in ready_sort_real in haifa scheduler https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82396 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug rtl-optimization/82396] [8 Regression] qsort comparator non-negative on sorted output: 4 in ready_sort_real in haifa scheduler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82396 --- Comment #7 from Wilco --- Author: wilco Date: Wed Oct 4 10:27:26 2017 New Revision: 253399 URL: https://gcc.gnu.org/viewcvs?rev=253399&root=gcc&view=rev Log: Fix PR82396: qsort comparator non-negative on sorted output r253236 broke AArch64 bootstrap. Earlier revision r253071 changed scheduling behaviour on AArch64 as autopref scheduling no longer checks the base. This patch fixes the bootstrap failure and cleans up autopref scheduling. The code is greatly simplified. Sort accesses on the offset first, and only if the offsets are the same fall back to other comparisons in rank_for_schedule. This doesn't at all restore the original behaviour since we no longer compare the base address, but it now defines a total sorting order. More work will be required to improve the sorting so that only loads/stores with the same base are affected. gcc/ PR rtl-optimization/82396 * haifa-sched.c (autopref_multipass_init): Simplify initialization. (autopref_rank_data): Simplify sort order. * sched-int.h (autopref_multipass_data_): Remove multi_mem_insn_p, min_offset and max_offset. Modified: trunk/gcc/ChangeLog trunk/gcc/haifa-sched.c trunk/gcc/sched-int.h
