[Bug c++/53574] ICE with -fstack-usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53574 --- Comment #4 from Jakub Jelinek --- No, it went away likely with r189298. Let me check in the testcase and close the PR.
[Bug c++/61323] 'static' and 'const' attributes cause non-type template argument matching failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61323 --- Comment #2 from paolo at gcc dot gnu.org --- Author: paolo Date: Mon Oct 16 08:25:31 2017 New Revision: 253777 URL: https://gcc.gnu.org/viewcvs?rev=253777&root=gcc&view=rev Log: 2017-10-16 Paolo Carlini PR c++/61323 * g++.dg/cpp0x/constexpr-61323.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-61323.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug middle-end/82556] [8 Regression] internal compiler error in curr_insn_transform, at lra-constraints.c:4307
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82556 Christoph Berg changed: What|Removed |Added CC||myon at debian dot org --- Comment #2 from Christoph Berg --- gcc-7 in Debian unstable is also affected: 16923: // gcc version 7.2.1 20171014 (Debian 7.2.0-10) 16923: // 16923: // /<>/build/../src/backend/access/transam/xloginsert.c: In function 'XLogInsert': 16923: // /<>/build/../src/backend/access/transam/xloginsert.c:468:1: internal compiler error: in curr_insn_transform, at lra-constraints.c:4320
[Bug c++/61323] 'static' and 'const' attributes cause non-type template argument matching failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61323 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.2 --- Comment #3 from Paolo Carlini --- Fixed for 7.2.0.
[Bug c++/53574] ICE with -fstack-usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53574 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Mon Oct 16 08:36:06 2017 New Revision: 253778 URL: https://gcc.gnu.org/viewcvs?rev=253778&root=gcc&view=rev Log: PR c++/53574 * g++.dg/other/pr53574.C: New test. Added: trunk/gcc/testsuite/g++.dg/other/pr53574.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/61351] ICE on valid when deducing template arguments with nested expansions of the same pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61351 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Paolo Carlini --- Dup. *** This bug has been marked as a duplicate of bug 61341 ***
[Bug c++/61341] ICE for variadic templates: tsubst at cp/pt.c:11313, tree check: expected class ‘expression’, have ‘type’ (integer_type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61341 Paolo Carlini changed: What|Removed |Added CC||richard-gccbugzilla@metafoo ||.co.uk --- Comment #6 from Paolo Carlini --- *** Bug 61351 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/82472] [8 Regression] ICE in generate_code_for_partition, at tree-loop-distribution.c:1145
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82472 amker at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from amker at gcc dot gnu.org --- (In reply to Arseny Solokha from comment #4) > Can this PR be closed now? Yes, I think it's fixed. Thanks.
[Bug c++/67100] ICE(in type_dependent_expression_p) on macro function + user defined literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67100 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #5 from Paolo Carlini --- Fixed in 5.1.0.
[Bug c++/67466] Project segfaulting, working with other compilers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67466 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Paolo Carlini --- Closing then.
[Bug c++/53574] ICE with -fstack-usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53574 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug middle-end/62263] Good codegen for bitwise rotate requires code that is technically undefined behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62263 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek --- With the recent changes on the trunk, I'm getting optimal generated code at least on x86_64/i686 for all reasonable and less reasonable patterns I've tried. Of course, one can write arbitrarily weirdo patterns and not everything will be recognized.
[Bug target/82498] Missed optimization for x86 rotate instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82498 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Jakub Jelinek --- Fixed.
[Bug c++/82561] New: [8 regression] crash on internal compiler error: in cp_tree_equal, at cp/tree.c:3778
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82561 Bug ID: 82561 Summary: [8 regression] crash on internal compiler error: in cp_tree_equal, at cp/tree.c:3778 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: sylvestre at debian dot org Target Milestone: --- Trying to build Firefox using g++8 (from Debian exp), version 8-20170923-1 /usr/bin/g++-8 -std=gnu++11 -c -I/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/system_wrappers -include /root/firefox-gcc-last/config/gcc_hidden.h -DDEBUG=1 -std=gnu++11 -o jsatom.o -c -I/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/system_wrappers -include /root/firefox-gcc-last/config/gcc_hidden.h -DDEBUG=1 -DENABLE_BINARYDATA -DENABLE_SIMD -DENABLE_WASM_THREAD_OPS -DWASM_HUGE_MEMORY -DJS_CACHEIR_SPEW -DENABLE_SHARED_ARRAY_BUFFER -DEXPORT_JS_API -DJS_HAS_CTYPES '-DDLL_PREFIX="lib"' '-DDLL_SUFFIX=".so"' -DFFI_BUILDING -DMOZ_HAS_MOZGLUE -I/root/firefox-gcc-last/js/src -I/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/js/src -I/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/js/src/ctypes/libffi/include -I/root/firefox-gcc-last/js/src/ctypes/libffi/src/x86 -I/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include -I/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include/nspr -fPIC -DMOZILLA_CLIENT -include /root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/js/src/js-confdefs.h -MD -MP -MF -Wall -Wc++11-compat -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wc++14-compat -Wc++1z-compat -Wduplicated-cond -Wimplicit-fallthrough -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=free-nonheap-object -Wformat -Wformat-overflow=2 -Wno-noexcept-type -fno-rtti -fno-exceptions -fno-math-errno -pthread -pipe -g -freorder-blocks -O3 -fno-omit-frame-pointer -Werror -Wno-shadow -Werror=format $OLDPWD/jsatom.cpp In file included from /root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include/mozilla/HashFunctions.h:50:0, from /root/firefox-gcc-last/js/src/jsatom.h:10, from /root/firefox-gcc-last/js/src/jsatominlines.h:10, from /root/firefox-gcc-last/jsatom.cpp:2: /root/firefox-gcc-last/js/src/jit/RegisterSets.h: In member function 'void js::jit::SpecializedRegSet::add(js::jit::FloatRegister)': /root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include/mozilla/Assertions.h:417:71: internal compiler error: in cp_tree_equal, at cp/tree.c:3778 static_assert(mozilla::detail::AssertionConditionType::isValid, \ ^ /root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include/mozilla/Assertions.h:432:5: note: in expansion of macro 'MOZ_VALIDATE_ASSERT_CONDITION_TYPE' MOZ_VALIDATE_ASSERT_CONDITION_TYPE(expr); \ ^~ /root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include/mozilla/Assertions.h:450:39: note: in expansion of macro 'MOZ_ASSERT_HELPER1' #define MOZ_RELEASE_ASSERT_GLUE(a, b) a b ^ /root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include/mozilla/Assertions.h:452:3: note: in expansion of macro 'MOZ_RELEASE_ASSERT_GLUE' MOZ_RELEASE_ASSERT_GLUE( \ ^~~ /root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include/mozilla/MacroArgs.h:16:26: note: in expansion of macro 'MOZ_CONCAT2' #define MOZ_CONCAT(x, y) MOZ_CONCAT2(x, y) ^~~ /root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include/mozilla/MacroArgs.h:73:51: note: in expansion of macro 'MOZ_CONCAT' #define MOZ_PASTE_PREFIX_AND_ARG_COUNT_GLUE(a, b) a b ^ /root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include/mozilla/MacroArgs.h:75:3: note: in expansion of macro 'MOZ_PASTE_PREFIX_AND_ARG_COUNT_GLUE' MOZ_PASTE_PREFIX_AND_ARG_COUNT_GLUE( \ ^~~ /root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include/mozilla/Assertions.h:453:5: note: in expansion of macro 'MOZ_PASTE_PREFIX_AND_ARG_COUNT' MOZ_PASTE_PREFIX_AND_ARG_COUNT(MOZ_ASSERT_HELPER, __VA_ARGS__), \ ^~ /root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include/mozilla/Assertions.h:457:27: note: in expansion of macro 'MOZ_RELEASE_ASSERT' # define MOZ_ASSERT(...) MOZ_RELEASE_ASSERT(__VA_ARGS__) ^~ /root/firefox-gcc-last/js/src/jit/RegisterSets.h:930:9: note: in expansion of macro 'MOZ_ASSERT' MOZ_ASSERT(!has(reg)); ^~ Please submit a full bug report, with preprocessed source if appropriate. Building the preproccessed file
[Bug c++/82561] [8 regression] crash on internal compiler error: in cp_tree_equal, at cp/tree.c:3778
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82561 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-10-16 CC||trippels at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Markus Trippelsdorf --- (In reply to Sylvestre Ledru from comment #0) > Building the preproccessed file doesn't trigger the bug. > I haven't been able to generate a test case yet. Could you please attach it nonetheless?
[Bug c++/82561] [8 regression] crash on internal compiler error: in cp_tree_equal, at cp/tree.c:3778
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82561 --- Comment #2 from Sylvestre Ledru --- Created attachment 42375 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42375&action=edit preprocessed file
[Bug c/71996] -fdump-translation-unit fails to dump string literals of type char16_t/char32_t/wchar_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71996 Nathan Sidwell changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nathan at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #3 from Nathan Sidwell --- The raw dump is not an interchange format.
[Bug c++/47346] access control for nested type is ignored in class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47346 Jonathan Wakely changed: What|Removed |Added CC||ville.voutilainen at gmail dot com --- Comment #16 from Jonathan Wakely --- *** Bug 58896 has been marked as a duplicate of this bug. ***
[Bug c++/58896] Incorrect handling of a private nested type of a template specialization in the main template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58896 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- I don't think it's relevant that one of the types is a specialization of the other, the same thing happens with unrelated classes, which is PR 47346. *** This bug has been marked as a duplicate of bug 47346 ***
[Bug c++/59002] [meta-bug] Access checking in templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59002 Bug 59002 depends on bug 58896, which changed state. Bug 58896 Summary: Incorrect handling of a private nested type of a template specialization in the main template https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58896 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/61471] redeclaration of default-argument in function template declaration not caught
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61471 --- Comment #4 from Jonathan Wakely --- Fixed in GCC 5.1.0: d.cc:2:31: error: redeclaration of ‘template void f(int)’ may not have default arguments [-fpermissive] template void f(int=3); // ill-formed ^ If we don't have one, we should add a testcase for this and close it.
[Bug c++/61471] redeclaration of default-argument in function template declaration not caught
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61471 --- Comment #5 from Jonathan Wakely --- *** Bug 61472 has been marked as a duplicate of this bug. ***
[Bug c++/61472] added default-argument in later declaration of function template not caught
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61472 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Jonathan Wakely --- Like PR 61471, this is fixed in 5.1.0, probably by the same patch, so I'm marking it as a dup. *** This bug has been marked as a duplicate of bug 61471 ***
[Bug c++/61471] redeclaration of default-argument in function template declaration not caught
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61471 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Paolo Carlini --- Dup. *** This bug has been marked as a duplicate of bug 15339 ***
[Bug c++/15339] [DR217] Adding default arguments to function templates in redeclarations should be forbidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15339 Paolo Carlini changed: What|Removed |Added CC||filip.roseen at gmail dot com --- Comment #19 from Paolo Carlini --- *** Bug 61471 has been marked as a duplicate of this bug. ***
[Bug c++/82561] [8 regression] crash on internal compiler error: in cp_tree_equal, at cp/tree.c:3778
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82561 --- Comment #3 from Markus Trippelsdorf --- OK, thanks. Can you please also attach the --save-temps -fdirectives-only file?
[Bug c++/82561] [8 regression] crash on internal compiler error: in cp_tree_equal, at cp/tree.c:3778
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82561 --- Comment #4 from Sylvestre Ledru --- Created attachment 42376 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42376&action=edit the .s
[Bug c++/82561] [8 regression] crash on internal compiler error: in cp_tree_equal, at cp/tree.c:3778
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82561 --- Comment #5 from Sylvestre Ledru --- Created attachment 42377 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42377&action=edit the .ii
[Bug c++/82561] [8 regression] crash on internal compiler error: in cp_tree_equal, at cp/tree.c:3778
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82561 Markus Trippelsdorf changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever confirmed|1 |0 --- Comment #6 from Markus Trippelsdorf --- Thanks. Unfortunately I cannot reproduce the issue.
[Bug c++/82561] [8 regression] crash on internal compiler error: in cp_tree_equal, at cp/tree.c:3778
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82561 Sylvestre Ledru changed: What|Removed |Added CC||doko at debian dot org --- Comment #7 from Sylvestre Ledru --- I asked Doko to upload a new version of gcc 8 into Debian so that I can test again (at least about a month old). If still occurring, I will try to get a test case.
[Bug c++/82560] [7/8 Regression] Temporary object created as a default argument not destructed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82560
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work||6.4.0
Keywords||wrong-code
Last reconfirmed||2017-10-16
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=49372
Ever confirmed|0 |1
Summary|Temporary object created as |[7/8 Regression] Temporary
|a default argument not |object created as a default
|destructed |argument not destructed
Target Milestone|--- |7.3
Known to fail||7.2.0, 8.0
--- Comment #1 from Jonathan Wakely ---
Confirmed:
extern "C" int printf(const char*, ...);
struct Foo {
Foo(const char *) {
printf("%p\tFoo(const char*)\n", this);
}
Foo(const Foo&) {
printf("%p\tFoo(const Foo&)\n", this);
}
~Foo() {
printf("%p\t~Foo()\n", this);
}
};
struct Bar {
Bar(Foo foo = "implicitly casted to Foo") : foo_(foo) {
printf("%p\tBar(Foo)\n", this);
}
~Bar() {
printf("%p\t~Bar()\n", this);
}
Foo foo_;
};
template
struct unique_ptr
{
unique_ptr(T* p) : p(p) { }
~unique_ptr() { delete p; }
T* p;
};
int main()
{
{
printf("OK:\n");
unique_ptr p1(new Bar);
}
{
printf("Wrong:\n");
unique_ptr p2(new Bar());
}
}
[Bug c++/82562] New: Incorrect warning: use copy-assignment or copy-initialization instead when copying build objects.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82562 Bug ID: 82562 Summary: Incorrect warning: use copy-assignment or copy-initialization instead when copying build objects. Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: andi at mozilla dot com Target Milestone: --- Trying to build firefox with gcc8 I get this error, when building with treat -Werror: /usr/bin/g++-8 -std=gnu++11 -o RegExp.o -c -I/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/system_wrappers -include /root/firefox-gcc-last/config/gcc_hidden.h -DDEBUG=1 -DENABLE_BINARYDATA -DENABLE_SIMD -DENABLE_WASM_THREAD_OPS -DWASM_HUGE_MEMORY -DJS_CACHEIR_SPEW -DENABLE_SHARED_ARRAY_BUFFER -DEXPORT_JS_API -DJS_HAS_CTYPES '-DDLL_PREFIX="lib"' '-DDLL_SUFFIX=".so"' -DFFI_BUILDING -DMOZ_HAS_MOZGLUE -I/root/firefox-gcc-last/js/src -I/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/js/src -I/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/js/src/ctypes/libffi/include -I/root/firefox-gcc-last/js/src/ctypes/libffi/src/x86 -I/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include -I/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include/nspr -fPIC -DMOZILLA_CLIENT -include /root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/js/src/js-confdefs.h -MD -MP -MF .deps/RegExp.o.pp -Wall -Wc++11-compat -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wc++14-compat -Wc++1z-compat -Wduplicated-cond -Wimplicit-fallthrough -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=free-nonheap-object -Wformat -Wformat-overflow=2 -Wno-noexcept-type -fno-rtti -fno-exceptions -fno-math-errno -pthread -pipe -g -freorder-blocks -O3 -fno-omit-frame-pointer -Werror -Wno-shadow -Werror=format -fno-strict-aliasing /root/firefox-gcc-last/js/src/builtin/RegExp.cpp In file included from /root/firefox-gcc-last/js/src/builtin/RegExp.cpp:24:0: /root/firefox-gcc-last/js/src/vm/NativeObject-inl.h: In member function 'void js::NativeObject::copyDenseElements(uint32_t, const JS::Value*, uint32_t)': /root/firefox-gcc-last/js/src/vm/NativeObject-inl.h:155:67: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of non-trivially copyable type 'class js::HeapSlot'; use copy-assignment or copy-initialization instead [-Werror=class-memaccess] memcpy(&elements_[dstStart], src, count * sizeof(HeapSlot)); ^ In file included from /root/firefox-gcc-last/js/src/jsatom.h:15:0, from /root/firefox-gcc-last/js/src/vm/Runtime.h:22, from /root/firefox-gcc-last/js/src/jscntxt.h:21, from /root/firefox-gcc-last/js/src/vm/RegExpObject.h:15, from /root/firefox-gcc-last/js/src/builtin/RegExp.h:10, from /root/firefox-gcc-last/js/src/builtin/RegExp.cpp:7: /root/firefox-gcc-last/js/src/gc/Barrier.h:655:7: note: 'class js::HeapSlot' declared here class HeapSlot : public WriteBarrieredBase ^~~~ In file included from /root/firefox-gcc-last/js/src/builtin/RegExp.cpp:24:0: /root/firefox-gcc-last/js/src/vm/NativeObject-inl.h: In member function 'void js::NativeObject::initDenseElements(const JS::Value*, uint32_t)': /root/firefox-gcc-last/js/src/vm/NativeObject-inl.h:184:52: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of non-trivially copyable type 'class js::HeapSlot'; use copy-assignment or copy-initialization instead [-Werror=class-memaccess] memcpy(elements_, src, count * sizeof(HeapSlot)); I don't think that the warning is valid since what we try to do is copy in eleements_ the number of 'count' elements of type HeadSlop from src.
[Bug c++/82560] [7/8 Regression] Temporary object created as a default argument not destructed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82560
--- Comment #2 from Jonathan Wakely ---
Further reduced:
extern "C" int printf(const char*, ...);
struct Foo {
Foo(const char *) {
printf("%p\tFoo(const char*)\n", this);
}
~Foo() {
printf("%p\t~Foo()\n", this);
}
};
struct Bar {
Bar(Foo foo = "") { }
~Bar() { }
};
int main()
{
delete new Bar();
}
[Bug c++/82560] [7/8 Regression] Temporary object created as a default argument not destructed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82560 Jonathan Wakely changed: What|Removed |Added CC||nathan at gcc dot gnu.org --- Comment #3 from Jonathan Wakely --- Seems to have started with r244882
[Bug libstdc++/57925] discrete_distribution can be improved to O(1) per sampling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57925 --- Comment #10 from Timon Knigge --- (In reply to Jonathan Wakely from comment #9) > Yes it's still open, so a fix would be welcome. Please see > http://gcc.gnu.org/contribute.html if you want to contribute a fix for it. W.r.t. to the 'legal' paragraph: I work at Google which would assert ownership over the code by default. Is the CLA the FSF already has with them sufficient?
[Bug c++/82562] Incorrect warning: use copy-assignment or copy-initialization instead when copying build objects.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82562 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-10-16 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- (In reply to Andi from comment #0) > In file included from /root/firefox-gcc-last/js/src/builtin/RegExp.cpp:24:0: > /root/firefox-gcc-last/js/src/vm/NativeObject-inl.h: In member function > 'void js::NativeObject::initDenseElements(const JS::Value*, uint32_t)': > /root/firefox-gcc-last/js/src/vm/NativeObject-inl.h:184:52: error: 'void* > memcpy(void*, const void*, size_t)' writing to an object of non-trivially > copyable type 'class js::HeapSlot'; use copy-assignment or > copy-initialization instead [-Werror=class-memaccess] > memcpy(elements_, src, count * sizeof(HeapSlot)); > > I don't think that the warning is valid since what we try to do is copy in > eleements_ the number of 'count' elements of type HeadSlop from src. Why would that mean it's not valid? Is the class trivially-copyable or not? If it isn't, then using memcpy is undefined. Please read https://gcc.gnu.org/bugs/ and provide the preprocessed code.
[Bug c++/82562] Incorrect warning: use copy-assignment or copy-initialization instead when copying build objects.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82562 Markus Trippelsdorf changed: What|Removed |Added Status|WAITING |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |INVALID --- Comment #2 from Markus Trippelsdorf --- https://github.com/ricardoquesada/Spidermonkey/blob/4a75ea2543408bd1b2c515aa95901523eeef7858/js/src/gc/Barrier.h#L940 Class HeapSlot is not trivially-copyable.
[Bug sanitizer/82501] AddressSanitizer does not handle negative offset for first global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501 Martin Liška changed: What|Removed |Added URL||https://github.com/google/s ||anitizers/issues/869 --- Comment #2 from Martin Liška --- I've just done upstream bug for this.
[Bug tree-optimization/82545] [7/8 Regression] -O2: ICE in gimple_split_edge, at tree-cfg.c:2838, during GIMPLE pass sanopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82545
--- Comment #6 from Martin Liška ---
What we do:
a ()
{
int b;
int b.0_1;
[100.00%] [count: INV]:
__builtin_setjmp_setup (0B, &);
goto ; [99.96%] [count: INV]
[0.12%] [count: INV]:
:
__builtin_setjmp_receiver (&);
goto ; [100.00%] [count: INV]
[0.12%] [count: INV]:
# b_12(ab) = PHI
__builtin___asan_handle_no_return ();
ABNORMAL_DISPATCHER (0);
[99.96%] [count: INV]:
[99.96%] [count: INV]:
# b_13(ab) = PHI
b.0_1 = b_13(ab);
c (b.0_1);
[99.92%] [count: INV]:
b_15(ab) = ASAN_POISON ();
d ();
[99.88%] [count: INV]:
return;
}
We expand ASAN_POISON and we propagate ASAN report function on all edges. In
this case -> is an abnormal edge, that we can't split.
Thoughts?
[Bug c++/61414] enum class bitfield size-checking failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61414 Sam van Kampen changed: What|Removed |Added CC||sam at segfault dot party --- Comment #13 from Sam van Kampen --- I've sent a patch that adds the warning flag -Wbitfield-enum-conversion to gcc-patches, and the gcc mailing list now also has a thread on the bug, and I thought I might share them on the bug tracker: The patch: https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00989.html The thread on the bug: https://gcc.gnu.org/ml/gcc/2017-10/msg00121.html
[Bug gcov-profile/82527] Branch probabilities does not match on optimized switch cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82527
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|--- |INVALID
--- Comment #2 from Martin Liška ---
Thanks for the issue. Note that order of branches which go from switch
statement to corresponding case labels is not ordered.
With new GCC 8.1, we'll come up with '-w' option. Then you'll see the
connections (edges):
$ rm *.gcda && gcc pr82527.c --coverage && ./a.out && gcov -abw pr82527.c &&
cat pr82527.c.gcov
0dddFile
'pr82527.c'
Lines executed:83.33% of 12
Branches executed:100.00% of 5
Taken at least once:80.00% of 5
No calls
Creating 'pr82527.c.gcov'
-:0:Source:pr82527.c
-:0:Graph:pr82527.gcno
-:0:Data:pr82527.gcda
-:0:Runs:1
-:0:Programs:1
-:1:#include
-:2:int
function main called 1 returned 100% blocks executed 91%
1:3:main ()
-:4:{
101:5: for (int i = 0; i < 100; i++)
1:5-block 0 (BB 2)
100:5-block 1 (BB 9)
101:5-block 2 (BB 10)
branch 0 taken 99% (BB 3)
branch 1 taken 1% (fallthrough) (BB 11)
-:6:{
100:7: switch (i)
100:7-block 0 (BB 3)
branch 0 taken 1% (BB 4)
branch 1 taken 0% (BB 6)
branch 2 taken 99% (BB 7)
-:8:{
1:9:case 0:
1: 10: printf ("0");
1: 10-block 0 (BB 4)
call0 returned 100%
1: 11: break;
#: 12:case :
#: 13: break;
$: 13-block 0 (BB 6)
99: 14:default:
99: 15: printf ("d");
99: 15-block 0 (BB 7)
call0 returned 100%
99: 16: break;
-: 17:}
-: 18:}
1: 19: return 0;
1: 19-block 0 (BB 11)
-: 20:}
$ rm *.gcda && gcc -O3 pr82527.c --coverage && ./a.out && gcov -abw pr82527.c
&& cat pr82527.c.gcov
0dddFile
'pr82527.c'
Lines executed:100.00% of 9
Branches executed:100.00% of 4
Taken at least once:75.00% of 4
No calls
Creating 'pr82527.c.gcov'
-:0:Source:pr82527.c
-:0:Graph:pr82527.gcno
-:0:Data:pr82527.gcda
-:0:Runs:1
-:0:Programs:1
-:1:#include
-:2:int
function main called 1 returned 100% blocks executed 100%
1:3:main ()
-:4:{
101:5: for (int i = 0; i < 100; i++)
1:5-block 0 (BB 2)
100:5-block 1 (BB 8)
101:5-block 2 (BB 9)
branch 0 taken 99% (BB 3)
branch 1 taken 1% (fallthrough) (BB 10)
-:6:{
100:7: switch (i)
100:7-block 0 (BB 3)
branch 0 taken 1% (BB 4)
branch 1 taken 99% (BB 6)
branch 2 taken 0% (BB 8)
-:8:{
1:9:case 0:
1: 10: printf ("0");
1: 10-block 0 (BB 4)
call0 returned 100%
1: 11: break;
-: 12:case :
-: 13: break;
99: 14:default:
99: 15: printf ("d");
99: 15-block 0 (BB 6)
call0 returned 100%
99: 16: break;
-: 17:}
-: 18:}
-: 19: return 0;
-: 20:}
And you're right w/ -O3 it goes to a different BB and order is changed.
Hope it will help you? I'm closing it as invalid.
[Bug target/82442] vect/pr31699.c fails on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82442 --- Comment #1 from Wilco --- Author: wilco Date: Mon Oct 16 13:26:20 2017 New Revision: 253786 URL: https://gcc.gnu.org/viewcvs?rev=253786&root=gcc&view=rev Log: Fix PR82442 Recently the gcc.dg/vect/pr31699.c was modified to check for vect_float effective target instead for vect_double. As a result it now fails on armhf. Fix by avoiding double. Tested on armhf, aarch64 and x64. gcc/testsuite/ PR target/82442 * gcc.dg/vect/pr31699.c: Fix testcase. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/pr31699.c
[Bug tree-optimization/82563] New: [8 Regression] [graphite] ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.c:709
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82563
Bug ID: 82563
Summary: [8 Regression] [graphite] ICE in
check_loop_closed_ssa_def, at
tree-ssa-loop-manip.c:709
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-8.0.0-alpha20171015 (r253772) ICEs when compiling the following snippet w/
-O3 (or -Ofast) -floop-nest-optimize (or -floop-parallelize-all):
int tj, cw, xf;
void
zp (int *ei)
{
for (;;)
{
int hd = 0;
if (cw != 0 && xf != 0)
{
for (hd = 0; hd < 3; ++hd)
cw = (tj != 0) ? 0 : *ei;
for (;;)
{
}
}
while (tj != 0)
tj = &hd;
}
}
% gcc-8.0.0-alpha20171015 -O3 -floop-nest-optimize -w -c dyx0j2oa.c
during GIMPLE pass: graphite
dyx0j2oa.c: In function 'zp':
dyx0j2oa.c:4:1: internal compiler error: in check_loop_closed_ssa_def, at
tree-ssa-loop-manip.c:709
zp (int *ei)
^~
check_loop_closed_ssa_def() has been introduced in r253161.
[Bug c++/80567] bogus fixit hint for undeclared memset: else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80567
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment #2 from David Malcolm ---
Seen also with:
void test ()
{
FILE *f;
}
for which g++ prints the nonsensical:
t.cc: In function ‘void test()’:
t.cc:3:3: error: ‘FILE’ was not declared in this scope
FILE *f;
^~~~
t.cc:3:9: error: ‘f’ was not declared in this scope
FILE *f;
^
t.cc:3:9: note: suggested alternative: ‘if’
FILE *f;
^
if
[Bug target/82498] Missed optimization for x86 rotate instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82498 --- Comment #17 from Jack Lloyd --- Thank you!
[Bug c++/64931] ICE on function with deduced return type and input is instantiated template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64931 --- Comment #3 from paolo at gcc dot gnu.org --- Author: paolo Date: Mon Oct 16 14:21:17 2017 New Revision: 253788 URL: https://gcc.gnu.org/viewcvs?rev=253788&root=gcc&view=rev Log: 2017-10-16 Paolo Carlini PR c++/64931 * g++.dg/cpp1y/auto-fn43.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp1y/auto-fn43.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/64931] ICE on function with deduced return type and input is instantiated template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64931 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.2 --- Comment #4 from Paolo Carlini --- Fixed in 6.2.0.
[Bug c/82564] New: ICE at -O1 and above: in assign_stack_temp_for_type, at function.c:783
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82564
Bug ID: 82564
Summary: ICE at -O1 and above: in assign_stack_temp_for_type,
at function.c:783
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
This seems to affect at least as early as 4.8.x.
$ gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.0 20171016 (experimental) [trunk revision 253785] (GCC)
$
$ gcctk -O0 small.c
$
$ gcctk -O1 small.c
during RTL pass: expand
small.c: In function ‘main’:
small.c:17:5: internal compiler error: in assign_stack_temp_for_type, at
function.c:783
a = f ();
~~^~
0x973b2b assign_stack_temp_for_type(machine_mode, long, tree_node*)
../../gcc-source-trunk/gcc/function.c:783
0x973be3 assign_temp(tree_node*, int, int)
../../gcc-source-trunk/gcc/function.c:999
0x7d4914 expand_call(tree_node*, rtx_def*, int)
../../gcc-source-trunk/gcc/calls.c:3135
0x907710 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc-source-trunk/gcc/expr.c:10869
0x91a63d expand_normal
../../gcc-source-trunk/gcc/expr.h:282
0x91a63d store_field
../../gcc-source-trunk/gcc/expr.c:6843
0x916631 expand_assignment(tree_node*, tree_node*, bool)
../../gcc-source-trunk/gcc/expr.c:5170
0x7e95aa expand_call_stmt
../../gcc-source-trunk/gcc/cfgexpand.c:2664
0x7e95aa expand_gimple_stmt_1
../../gcc-source-trunk/gcc/cfgexpand.c:3585
0x7e95aa expand_gimple_stmt
../../gcc-source-trunk/gcc/cfgexpand.c:3751
0x7eb442 expand_gimple_basic_block
../../gcc-source-trunk/gcc/cfgexpand.c:5754
0x7f0e46 execute
../../gcc-source-trunk/gcc/cfgexpand.c:6361
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$
--
int main ()
{
int t = 8;
typedef struct
{
char v[t];
} B;
B a, b;
B __attribute__ ((noinline)) f ()
{
return b;
}
a = f ();
return 0;
}
[Bug c++/61414] enum class bitfield size-checking needs a separate warning flag controlling it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61414 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=39170 Blocks||44209 Summary|enum class bitfield |enum class bitfield |size-checking failure |size-checking needs a ||separate warning flag ||controlling it --- Comment #14 from Eric Gallager --- (In reply to Jonathan Wakely from comment #7) > At the very least there should be a -Wxxx switch controlling this option so > it can be disabled. Agreed, that falls under bug 44209; retitling this one accordingly. (In reply to Sam van Kampen from comment #13) > I've sent a patch that adds the warning flag -Wbitfield-enum-conversion to > gcc-patches, and the gcc mailing list now also has a thread on the bug, and > I thought I might share them on the bug tracker: > > The patch: > https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00989.html > > The thread on the bug: > https://gcc.gnu.org/ml/gcc/2017-10/msg00121.html The name chosen for the flag makes it sound kinda related to bug 39170 but I guess the "enum" in the middle is enough of a differentiator. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44209 [Bug 44209] [meta-bug] Some warnings are not linked to diagnostics options
[Bug c++/82565] New: Concept and lambda return type deduction cause compilation to crash with "mmap: Cannot allocate memory"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82565
Bug ID: 82565
Summary: Concept and lambda return type deduction cause
compilation to crash with "mmap: Cannot allocate
memory"
Product: gcc
Version: 7.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haaawk at gmail dot com
Target Milestone: ---
Created attachment 42378
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42378&action=edit
file that crashes compilation "g++ -fconcepts crash.cpp"
The file I attached crashes the following compilation:
g++ -fconcepts crash.cpp
both on GCC 7.1.1 and GCC 7.2.
GCC 7.1.1 gives the following result:
crash.cpp: In instantiation of ‘run_test():: [with auto:1 =
const std::__cxx11::basic_string]’:
crash.cpp:9:12: required from here
crash.cpp:49:58: internal compiler error: Segmentation fault
return object.visit([] (auto& x) { return x.empty(); });
GCC 7.2 gives the following result:
crash.cpp: In instantiation of 'run_test():: [with auto:1 =
const std::__cxx11::basic_string]':
crash.cpp:9:12: required from here
crash.cpp:49:58: internal compiler error: Segmentation fault
return object.visit([] (auto& x) { return x.empty(); });
^
mmap: Cannot allocate memory
The file compiles correctly after commenting out line 31 which applies Concept
to visit method:
requires Concept()(std::declval()))>()
or after explicit declaration of the return type to "-> bool" on lambda in line
49:
return object.visit([] (auto& x) -> bool { return x.empty(); });
Below I'm pasting the content of the crash.cpp file:
#include
#include
#include
#include
template
concept bool Concept() {
return requires(T t, const std::string& s, const std::vector& v) {
{ t(s) } -> ReturnType;
{ t(v) } -> ReturnType;
};
}
struct test {
enum class kind {
string, vector
};
struct data {
data() { }
~data() { }
union {
std::string _str;
std::vector _v;
};
};
kind _kind;
std::unique_ptr _data;
template
requires Concept()(std::declval()))>()
decltype(auto) visit(Visitor&& visitor) const {
switch (_kind) {
case kind::string:
return visitor(_data->_str);
case kind::vector:
return visitor(_data->_v);
}
abort();
}
};
bool run_test() {
test object;
object._kind = test::kind::string;
object._data = std::make_unique();
new (&object._data->_str) std::string("hello test");
return object.visit([] (auto& x) { return x.empty(); });
}
int main() {
std::cout << run_test() << std::endl;
return 0;
}
[Bug middle-end/82564] ICE at -O1 and above: in assign_stack_temp_for_type, at function.c:783
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82564 --- Comment #1 from Andrew Pinski --- There might be a dup of this bug already filed too.
[Bug middle-end/82564] ICE at -O1 and above: in assign_stack_temp_for_type, at function.c:783
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82564 --- Comment #2 from Andrew Pinski --- Related to PR 8081.
[Bug c++/82566] New: Internal compiler error in type deduction (with C++11)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82566 Bug ID: 82566 Summary: Internal compiler error in type deduction (with C++11) Product: gcc Version: 4.9.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: peter.gottschling at simunova dot com Target Milestone: --- Compiler error occurs only with g++-4.9. Other g++ versions (e.g. 4.7, 5, 7) work smoothly. Preprocessed source attached.
[Bug c++/82566] Internal compiler error in type deduction (with C++11)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82566 --- Comment #1 from Peter Gottschling --- Created attachment 42379 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42379&action=edit Preprocessed source compressed with bzip2.
[Bug fortran/82567] New: [6/7/8] gfortran takes a long time to compile a simple implied-do with -Optimization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82567 Bug ID: 82567 Summary: [6/7/8] gfortran takes a long time to compile a simple implied-do with -Optimization. Product: gcc Version: 6.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: chinoune.mehdi at hotmail dot com Target Milestone: --- gfortran takes about 11s to compile this simple subroutine with -O1 : SUBROUTINE sub() IMPLICIT NONE INTEGER, PARAMETER :: n = 1 REAL, ALLOCATABLE :: x(:) REAL :: xc, h INTEGER :: i ALLOCATE( x(n) ) xc = 100. h = xc/n x = h*[(i,i=1,n)] ! Replacing the previous line with one of these lines gives faster compilation ! x = [(i*h,i=1,n)] ! x = (100./n) *[(i,i=1,n)] END SUBROUTINE sub time gfortran -O1 -c test.f90: real0m11.167s the time increases with n (-O1) : n| 1 | 2 | 3 | 4 - time | 11s | 25s | 43s | 1m7s and decrease with the level of optimization (n=2) : -Ox | -O1 | -O2 | -O3 | -Ofast --- time | 20s | 15s | 15s | 8s tested with gfortran 6/7/8 Linux-64 and gfortran-7 MinGW-64
[Bug fortran/82568] New: ICE with do-loop inside BLOCK inside omp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82568 Bug ID: 82568 Summary: ICE with do-loop inside BLOCK inside omp Product: gcc Version: 6.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: chinoune.mehdi at hotmail dot com Target Milestone: --- gfortran gives an internal compiler error with this code : PROGRAM OMP_BLOCK IMPLICIT NONE INTEGER :: I !,J !$OMP PARALLEL DO !PRIVATE(J) ! Declaring j outside of OMP and put it in private solves the problem DO I=1,2 BLOCK INTEGER :: J DO J=1,2 PRINT*,I,J END DO END BLOCK END DO END PROGRAM OMP_BLOCK tested with gfortran 6/7/8 Linux-64 and gfortran-7 MinGW-64
[Bug c++/82566] Internal compiler error in type deduction (with C++11)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82566 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #2 from Markus Trippelsdorf --- gcc 4.9 isn't supported anymore. See the gcc homepage for the list of currently supported releases.
[Bug other/82547] wide_int is not setting overflow properly for large unsigned add/subtract calculations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82547
--- Comment #1 from Andrew Macleod ---
On a further note, this appears to be because wide_int tries not to use all the
words is it can sign extend?
the sequence with the issue is:
Mn = wi::min_value (128, UNSIGNED);
Mx = wi::max_value (128, UNSIGNED);
Mxminus2 = wi::sub (Mx, 2, UNSIGNED, &ov);
x = wi::sub (Mn, Mxminus2 , UNSIGNED, &ov2);
fprintf (stderr, "ov %d ov2 %d\n", ov, ov2);
if I look at Mn, I see:
(gdb) p Mn.dump()
[...,0], precision = 128
(gdb) p Mn
$14 = { = {val = {0, 140737488344128, 34794152}, len = 1,
precision = 128}, static is_sign_extended = }
So the precision is 128, but len is set to 1 on a 64 bit host.
Same thing happens for Mx.
Then when wi::sub_large is called, it does the calculation and checks:
if (len * HOST_BITS_PER_WIDE_INT < prec)
{
val[len] = mask0 - mask1 - borrow;
len++;
if (overflow)
*overflow = false;
}
Since both values have a len of 1, and precision is 128, it decides there
cannot be an overflow. It seems to be ignoring that fgact that sign-extension
may exist.
Interestingly, if I remove that entire hunk of code, and and let it do the
general check for overflow which follows, It works as I would expect.
Of course, I have no idea what the side effects of that are...
I leave it in the hands of a wide_int expert.
[Bug fortran/82511] [7/8 Regression] ICE Bad IO basetype (12) on attempted read or write of entire DEC structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82511 --- Comment #7 from Fritz Reese --- Author: foreese Date: Mon Oct 16 17:40:53 2017 New Revision: 253791 URL: https://gcc.gnu.org/viewcvs?rev=253791&root=gcc&view=rev Log: 2017-10-16 Fritz Reese PR fortran/82511 Treat UNION components as DT comp. in I/O lists. gcc/fortran/ChangeLog: PR fortran/82511 * trans-io.c (transfer_expr): Treat BT_UNION as BT_DERIVED. gcc/testsuite/ChangeLog: PR fortran/82511 * gfortran.dg/dec_structure_22.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/dec_structure_22.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-io.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/81758] [7/8 Regression] [OOP] Broken vtab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758 --- Comment #9 from Thomas Koenig --- I just checked on powerpc64 with a rather current trunk with gfc::bank testing status:0 (PASSED): Performance: 2888199.6889235629 gfc::vector testing status:0 (PASSED): Performance: 2108461.4164096378 gfc::list testing status:0 (PASSED): Performance: 2108461.4164096378 gfc::tree testing status:0 (PASSED): Performance: 327471.70199407206 gfc::dictionary testing status:0 (PASSED): Performance: 281461.77688575117 16383 gfc::graph testing status:5 (FAILED) Multi-index sort testing status:0 (PASSED): Performance: 120529.43369575262 Dynamic type inferrence slowdown: 0.2418 67110738.2064877 0.5810 67110738.20648772.4023336875488646 Is this an indication of success or of failure?
[Bug fortran/82511] [7/8 Regression] ICE Bad IO basetype (12) on attempted read or write of entire DEC structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82511 Fritz Reese changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Fritz Reese --- (In reply to Steve Kargl from comment #4) ... > > program bug > structure /bckt/ > union > map >character*16 c16 > end map > end union > end structure > record /bckt/ bucket > character(len=16) :: rec1 = 'ABCDEFGHIJKLMNOP' > 100 format(A16) > read(rec1, 100) bckt > end program bug > > where one is trying read into the definition of the structure. > Is the above suppose to compile? Because it does. [...] Steve- on second glance, the above program is correct, even though it is misleading. It compiles because there is no IMPLICIT NONE, so the variable BCKT is an implicit variable created at the point of use. The program above behaves equivalently if STRUCTURE /bckt/ is never declared, and issues an appropriate error with IMPLICIT NONE: program bug implicit none structure /bckt/ [...] read(rec1, 100) bckt end program bug $ gfortran -fdec-structure bug.for bug.for:12:26: read(rec1, 100) bckt 1 Error: Symbol ‘bckt’ at (1) has no IMPLICIT type
[Bug fortran/81758] [7/8 Regression] [OOP] Broken vtab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758 --- Comment #10 from DIL --- (In reply to Thomas Koenig from comment #9) > I just checked on powerpc64 with a rather current trunk with > > gfc::bank testing status:0 (PASSED): Performance: > 2888199.6889235629 > gfc::vector testing status:0 (PASSED): Performance: > 2108461.4164096378 > gfc::list testing status:0 (PASSED): Performance: > 2108461.4164096378 > gfc::tree testing status:0 (PASSED): Performance: > 327471.70199407206 > gfc::dictionary testing status:0 (PASSED): Performance: > 281461.77688575117 >16383 > gfc::graph testing status:5 (FAILED) > Multi-index sort testing status:0 (PASSED): Performance: > 120529.43369575262 > Dynamic type inferrence slowdown: 0.2418 67110738.2064877 0.5810 > 67110738.20648772.4023336875488646 > > Is this an indication of success or of failure? It is a failure, seems to occur along the same code path, but without a SegFault.
[Bug middle-end/82567] [6/7/8] gfortran takes a long time to compile a simple implied-do with -Optimization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82567 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-10-16 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed. The test compiles in a fraction of a second with -fno-frontend-optimize. The change occurred between revisions r197010 (2013-03-23, fast) and r197238 (2013-03-29, slow), likely r197217.
[Bug fortran/82568] [6/7/8] ICE with do-loop inside BLOCK inside omp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82568 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-10-16 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from 4.5.4 up to trunk (8.0). I don't know if the code is valid.
[Bug fortran/82567] [6/7/8] gfortran takes a long time to compile a simple implied-do with -Optimization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82567 --- Comment #2 from Dominique d'Humieres --- > The change occurred between revisions r197010 (2013-03-23, fast) and r197238 > (2013-03-29, slow), likely r197217. More likely r197216.
[Bug fortran/25297] Support for STRUCTURE/END STRUCTURE and RECORD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25297 Fritz Reese changed: What|Removed |Added CC||foreese at gcc dot gnu.org Resolution|WONTFIX |FIXED Assignee|unassigned at gcc dot gnu.org |foreese at gcc dot gnu.org --- Comment #5 from Fritz Reese --- For the record: support for DEC STRUCTURE/RECORD was introduced in r235999 in gcc-7 and was also backported to gcc-6. Marking this as FIXED.
[Bug fortran/81048] [6/7/8 Regression] incorrect derived type initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81048 --- Comment #5 from Paul Thomas --- Author: pault Date: Mon Oct 16 18:48:56 2017 New Revision: 253793 URL: https://gcc.gnu.org/viewcvs?rev=253793&root=gcc&view=rev Log: 2017-10-16 Paul Thomas PR fortran/81048 * resolve.c (resolve_symbol): Ensure that derived type array results get default initialization. 2017-10-16 Paul Thomas PR fortran/81048 * gfortran.dg/derived_init_4.f90 : New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/derived_init_4.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/resolve.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug other/82569] New: [8 regression] failure in 177.mesa cpu2000 test case after r253530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82569
Bug ID: 82569
Summary: [8 regression] failure in 177.mesa cpu2000 test case
after r253530
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at gcc dot gnu.org
Target Milestone: ---
This failure was notice on a powerpc64 be system. Specifically, a power6
system.
The test case 177.mesa in the spec2000 test cases began failing with revision
253530 with a segmentation fault. The failure occurs in "write_color_span" but
I traced it to a bad value in a parameter being passed to an earlier function.
I noticed this when targeting power6x but the same bad code is generated for
power6. power7/power8 generate different code. I only saw the segmentation
fauit when the code was compiled with -O3.
(running in gdb...)
run -frames 1000 -meshfile mesa.in -ppmfile mesa.ppm
Program received signal SIGSEGV, Segmentation fault.
0x1006087c in .write_color_span ()
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.192.el6.ppc64
(gdb) up
#1 0x100792f4 in .gl_write_texture_span ()
(gdb) up
#2 0x100952f4 in .general_textured_triangle ()
(gdb) x/10i $pc-24
0x100952dc <.general_textured_triangle+3420>:std r16,120(r1)
0x100952e0 <.general_textured_triangle+3424>:ld r5,29104(r1)
0x100952e4 <.general_textured_triangle+3428>:ld r6,29088(r1)
0x100952e8 <.general_textured_triangle+3432>:ld r3,29200(r1)
0x100952ec <.general_textured_triangle+3436>:std r12,29112(r1)
0x100952f0 <.general_textured_triangle+3440>:bl 0x10079080
<.gl_write_texture_span>
=> 0x100952f4 <.general_textured_triangle+3444>:nop
0x100952f8 <.general_textured_triangle+3448>:ld r12,29112(r1)
0x100952fc <.general_textured_triangle+3452>:lwz r9,29148(r1)
0x10095300 <.general_textured_triangle+3456>:lwz r10,29124(r1)
So, if I compare the parameter values at this point in the working (r253529)
and failing (r253530) code r6 holds the bad parm value:
failing:
(gdb) info registers
...
r6 0xfff007a17587891077242
Works:
(gdb) info registers
...
r6 0x7a 122
Why does this happen? When it fails the value that is computed earlier in the
code for the parameter
iy = ((fy) >> 11);
is stored via an "stw" and then loaded via a "ld". If there is any leftover
garbage in the memory it will fail. It doesn't always fail as sometimes the
memory has 0 in the bytes not stored to via the stw and loaded via the ld.
So, looking at the assembly output:
works:
0x10094f9c <.general_textured_triangle+2092>:srawi r8,r4,11
0x10094fa0 <.general_textured_triangle+2096>:std r8,29256(r1)
...
0x100952c0 <.general_textured_triangle+2896>:ld r10,29256(r1)
(this is then stored again and loaded into r6 for the function call via
std/ld)
fails:
0x10094d84 <.general_textured_triangle+2052>:srawi r9,r3,11
0x10094d88 <.general_textured_triangle+2056>:stw r9,29268(r1)
...
0x10095094 <.general_textured_triangle+2836>:ld r10,29264(r1)
(this is then stored again and loaded into r6 for the function call via
std/ld)
Something in this revision causes the (working) std to be replaced by a stw.
The source is really ugly and is a bunch of macros defined in functions that
then #include code that uses the macros. (Good grief, who wrote this?) I
haven't been able to whittle down the code much from the original source.
Trying to duplicate the problem from scratch also hasn't worked; with both
253529 and 253530 the store after the >> is an stw and the parameter load for
the function call is an lwa.
If I generate a .i from the code this is the "bad" part:
# 483 "tritemp.h"
{
int subTriangle;
GLfixed fx, fxLeftEdge, fxRightEdge, fdxLeftEdge, fdxRightEdge;
GLfixed fdxOuter;
int idxOuter;
float dxOuter;
GLfixed fError, fdError;
float adjx, adjy;
GLfixed fy;
int iy;
GLdepth *zRow;
int dZRowOuter, dZRowInner;
GLfixed fz, fdzOuter, fdzInner;
GLfixed fr, fdrOuter, fdrInner;
GLfixed fg, fdgOuter, fdgInner;
GLfixed fb, fdbOuter, fdbInner;
GLfixed fa, fdaOuter, fdaInner;
# 518 "tritemp.h"
GLfloat sLeft, dsOuter, dsInner;
GLfloat tLeft, dtOuter, dtInner;
GLfloat wLeft, dwOuter, dwInner;
GLfloat uLeft, duOuter, duInner;
GLfloat vLeft, dvOuter, dvInner;
for (subTriangle=0;
[Bug sanitizer/82545] [7/8 Regression] -O2: ICE in gimple_split_edge, at tree-cfg.c:2838, during GIMPLE pass sanopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82545 --- Comment #7 from Ivo Raisr --- If no viable solution to splitting an abnormal edge is found, I wonder if we could actually prevent getting into this situation?
[Bug fortran/52832] [F03] ASSOCIATE construct with proc-pointer selector is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52832 --- Comment #7 from Paul Thomas --- Author: pault Date: Mon Oct 16 19:44:04 2017 New Revision: 253794 URL: https://gcc.gnu.org/viewcvs?rev=253794&root=gcc&view=rev Log: 2017-10-16 Paul Thomas PR fortran/52832 * match.c (gfc_match_associate): Before failing the association try again, allowing a proc pointer selector. PR fortran/80120 PR fortran/81903 PR fortran/82121 * primary.c (gfc_match_varspec): Introduce 'tgt_expr', which points to the associate selector, if any. Go through selector references, after resolution for variables, to catch any full or section array references. If a class associate name does not have the same declared type as the selector, resolve the selector and copy the declared type to the associate name. Before throwing a no implicit type error, resolve all allowed selector expressions, and copy the resulting typespec. PR fortran/67543 * resolve.c (resolve_assoc_var): Selector must cannot be the NULL expression and it must have a type. PR fortran/78152 * resolve.c (resolve_symbol): Allow associate names to be coarrays. 2017-10-16 Paul Thomas PR fortran/78512 * gfortran.dg/associate_9.f03 : Remove XFAIL. * gfortran.dg/associate_26.f90 : New test. PR fortran/80120 * gfortran.dg/associate_27.f90 : New test. PR fortran/81903 * gfortran.dg/associate_28.f90 : New test. PR fortran/82121 * gfortran.dg/associate_29.f90 : New test. PR fortran/67543 * gfortran.dg/associate_30.f90 : New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_26.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_27.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_28.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_29.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_30.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/match.c branches/gcc-7-branch/gcc/fortran/primary.c branches/gcc-7-branch/gcc/fortran/resolve.c branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_9.f03
[Bug fortran/82121] [7/8 Regression] Unclassifiable statement during compilation when assigning to a Character array in a derived type contained in a ASSOCIATE statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82121 --- Comment #3 from Paul Thomas --- Author: pault Date: Mon Oct 16 19:44:04 2017 New Revision: 253794 URL: https://gcc.gnu.org/viewcvs?rev=253794&root=gcc&view=rev Log: 2017-10-16 Paul Thomas PR fortran/52832 * match.c (gfc_match_associate): Before failing the association try again, allowing a proc pointer selector. PR fortran/80120 PR fortran/81903 PR fortran/82121 * primary.c (gfc_match_varspec): Introduce 'tgt_expr', which points to the associate selector, if any. Go through selector references, after resolution for variables, to catch any full or section array references. If a class associate name does not have the same declared type as the selector, resolve the selector and copy the declared type to the associate name. Before throwing a no implicit type error, resolve all allowed selector expressions, and copy the resulting typespec. PR fortran/67543 * resolve.c (resolve_assoc_var): Selector must cannot be the NULL expression and it must have a type. PR fortran/78152 * resolve.c (resolve_symbol): Allow associate names to be coarrays. 2017-10-16 Paul Thomas PR fortran/78512 * gfortran.dg/associate_9.f03 : Remove XFAIL. * gfortran.dg/associate_26.f90 : New test. PR fortran/80120 * gfortran.dg/associate_27.f90 : New test. PR fortran/81903 * gfortran.dg/associate_28.f90 : New test. PR fortran/82121 * gfortran.dg/associate_29.f90 : New test. PR fortran/67543 * gfortran.dg/associate_30.f90 : New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_26.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_27.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_28.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_29.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_30.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/match.c branches/gcc-7-branch/gcc/fortran/primary.c branches/gcc-7-branch/gcc/fortran/resolve.c branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_9.f03
[Bug fortran/80120] [7/8 Regression] Incorrect error with associate construct and character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80120 --- Comment #4 from Paul Thomas --- Author: pault Date: Mon Oct 16 19:44:04 2017 New Revision: 253794 URL: https://gcc.gnu.org/viewcvs?rev=253794&root=gcc&view=rev Log: 2017-10-16 Paul Thomas PR fortran/52832 * match.c (gfc_match_associate): Before failing the association try again, allowing a proc pointer selector. PR fortran/80120 PR fortran/81903 PR fortran/82121 * primary.c (gfc_match_varspec): Introduce 'tgt_expr', which points to the associate selector, if any. Go through selector references, after resolution for variables, to catch any full or section array references. If a class associate name does not have the same declared type as the selector, resolve the selector and copy the declared type to the associate name. Before throwing a no implicit type error, resolve all allowed selector expressions, and copy the resulting typespec. PR fortran/67543 * resolve.c (resolve_assoc_var): Selector must cannot be the NULL expression and it must have a type. PR fortran/78152 * resolve.c (resolve_symbol): Allow associate names to be coarrays. 2017-10-16 Paul Thomas PR fortran/78512 * gfortran.dg/associate_9.f03 : Remove XFAIL. * gfortran.dg/associate_26.f90 : New test. PR fortran/80120 * gfortran.dg/associate_27.f90 : New test. PR fortran/81903 * gfortran.dg/associate_28.f90 : New test. PR fortran/82121 * gfortran.dg/associate_29.f90 : New test. PR fortran/67543 * gfortran.dg/associate_30.f90 : New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_26.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_27.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_28.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_29.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_30.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/match.c branches/gcc-7-branch/gcc/fortran/primary.c branches/gcc-7-branch/gcc/fortran/resolve.c branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_9.f03
[Bug fortran/78152] [6/7/8 Regression] coarray and associate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78152 --- Comment #15 from Paul Thomas --- Author: pault Date: Mon Oct 16 19:44:04 2017 New Revision: 253794 URL: https://gcc.gnu.org/viewcvs?rev=253794&root=gcc&view=rev Log: 2017-10-16 Paul Thomas PR fortran/52832 * match.c (gfc_match_associate): Before failing the association try again, allowing a proc pointer selector. PR fortran/80120 PR fortran/81903 PR fortran/82121 * primary.c (gfc_match_varspec): Introduce 'tgt_expr', which points to the associate selector, if any. Go through selector references, after resolution for variables, to catch any full or section array references. If a class associate name does not have the same declared type as the selector, resolve the selector and copy the declared type to the associate name. Before throwing a no implicit type error, resolve all allowed selector expressions, and copy the resulting typespec. PR fortran/67543 * resolve.c (resolve_assoc_var): Selector must cannot be the NULL expression and it must have a type. PR fortran/78152 * resolve.c (resolve_symbol): Allow associate names to be coarrays. 2017-10-16 Paul Thomas PR fortran/78512 * gfortran.dg/associate_9.f03 : Remove XFAIL. * gfortran.dg/associate_26.f90 : New test. PR fortran/80120 * gfortran.dg/associate_27.f90 : New test. PR fortran/81903 * gfortran.dg/associate_28.f90 : New test. PR fortran/82121 * gfortran.dg/associate_29.f90 : New test. PR fortran/67543 * gfortran.dg/associate_30.f90 : New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_26.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_27.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_28.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_29.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_30.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/match.c branches/gcc-7-branch/gcc/fortran/primary.c branches/gcc-7-branch/gcc/fortran/resolve.c branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_9.f03
[Bug fortran/81903] [OOP] problem with ASSOCIATE and class pointer (Invalid character in name at)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81903 --- Comment #5 from Paul Thomas --- Author: pault Date: Mon Oct 16 19:44:04 2017 New Revision: 253794 URL: https://gcc.gnu.org/viewcvs?rev=253794&root=gcc&view=rev Log: 2017-10-16 Paul Thomas PR fortran/52832 * match.c (gfc_match_associate): Before failing the association try again, allowing a proc pointer selector. PR fortran/80120 PR fortran/81903 PR fortran/82121 * primary.c (gfc_match_varspec): Introduce 'tgt_expr', which points to the associate selector, if any. Go through selector references, after resolution for variables, to catch any full or section array references. If a class associate name does not have the same declared type as the selector, resolve the selector and copy the declared type to the associate name. Before throwing a no implicit type error, resolve all allowed selector expressions, and copy the resulting typespec. PR fortran/67543 * resolve.c (resolve_assoc_var): Selector must cannot be the NULL expression and it must have a type. PR fortran/78152 * resolve.c (resolve_symbol): Allow associate names to be coarrays. 2017-10-16 Paul Thomas PR fortran/78512 * gfortran.dg/associate_9.f03 : Remove XFAIL. * gfortran.dg/associate_26.f90 : New test. PR fortran/80120 * gfortran.dg/associate_27.f90 : New test. PR fortran/81903 * gfortran.dg/associate_28.f90 : New test. PR fortran/82121 * gfortran.dg/associate_29.f90 : New test. PR fortran/67543 * gfortran.dg/associate_30.f90 : New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_26.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_27.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_28.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_29.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_30.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/match.c branches/gcc-7-branch/gcc/fortran/primary.c branches/gcc-7-branch/gcc/fortran/resolve.c branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_9.f03
[Bug tree-optimization/78512] [7 Regression] r242674 miscompiles Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78512 --- Comment #9 from Paul Thomas --- Author: pault Date: Mon Oct 16 19:44:04 2017 New Revision: 253794 URL: https://gcc.gnu.org/viewcvs?rev=253794&root=gcc&view=rev Log: 2017-10-16 Paul Thomas PR fortran/52832 * match.c (gfc_match_associate): Before failing the association try again, allowing a proc pointer selector. PR fortran/80120 PR fortran/81903 PR fortran/82121 * primary.c (gfc_match_varspec): Introduce 'tgt_expr', which points to the associate selector, if any. Go through selector references, after resolution for variables, to catch any full or section array references. If a class associate name does not have the same declared type as the selector, resolve the selector and copy the declared type to the associate name. Before throwing a no implicit type error, resolve all allowed selector expressions, and copy the resulting typespec. PR fortran/67543 * resolve.c (resolve_assoc_var): Selector must cannot be the NULL expression and it must have a type. PR fortran/78152 * resolve.c (resolve_symbol): Allow associate names to be coarrays. 2017-10-16 Paul Thomas PR fortran/78512 * gfortran.dg/associate_9.f03 : Remove XFAIL. * gfortran.dg/associate_26.f90 : New test. PR fortran/80120 * gfortran.dg/associate_27.f90 : New test. PR fortran/81903 * gfortran.dg/associate_28.f90 : New test. PR fortran/82121 * gfortran.dg/associate_29.f90 : New test. PR fortran/67543 * gfortran.dg/associate_30.f90 : New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_26.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_27.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_28.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_29.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_30.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/match.c branches/gcc-7-branch/gcc/fortran/primary.c branches/gcc-7-branch/gcc/fortran/resolve.c branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_9.f03
[Bug fortran/67543] ICE on associate with improper association
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67543 --- Comment #3 from Paul Thomas --- Author: pault Date: Mon Oct 16 19:44:04 2017 New Revision: 253794 URL: https://gcc.gnu.org/viewcvs?rev=253794&root=gcc&view=rev Log: 2017-10-16 Paul Thomas PR fortran/52832 * match.c (gfc_match_associate): Before failing the association try again, allowing a proc pointer selector. PR fortran/80120 PR fortran/81903 PR fortran/82121 * primary.c (gfc_match_varspec): Introduce 'tgt_expr', which points to the associate selector, if any. Go through selector references, after resolution for variables, to catch any full or section array references. If a class associate name does not have the same declared type as the selector, resolve the selector and copy the declared type to the associate name. Before throwing a no implicit type error, resolve all allowed selector expressions, and copy the resulting typespec. PR fortran/67543 * resolve.c (resolve_assoc_var): Selector must cannot be the NULL expression and it must have a type. PR fortran/78152 * resolve.c (resolve_symbol): Allow associate names to be coarrays. 2017-10-16 Paul Thomas PR fortran/78512 * gfortran.dg/associate_9.f03 : Remove XFAIL. * gfortran.dg/associate_26.f90 : New test. PR fortran/80120 * gfortran.dg/associate_27.f90 : New test. PR fortran/81903 * gfortran.dg/associate_28.f90 : New test. PR fortran/82121 * gfortran.dg/associate_29.f90 : New test. PR fortran/67543 * gfortran.dg/associate_30.f90 : New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_26.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_27.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_28.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_29.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_30.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/match.c branches/gcc-7-branch/gcc/fortran/primary.c branches/gcc-7-branch/gcc/fortran/resolve.c branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_9.f03
[Bug fortran/52832] [F03] ASSOCIATE construct with proc-pointer selector is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52832 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED CC||pault at gcc dot gnu.org Resolution|--- |FIXED --- Comment #8 from Paul Thomas --- Fixed on trunk and 7-branch. Thanks for the report. Paul
[Bug fortran/80120] [7/8 Regression] Incorrect error with associate construct and character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80120 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Paul Thomas --- Fixed on trunk and 7-branch. Thanks for the report. Paul
[Bug fortran/81903] [OOP] problem with ASSOCIATE and class pointer (Invalid character in name at)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81903 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Paul Thomas --- Fixed on trunk and 7-branch. Thanks for the report. Paul
[Bug fortran/82121] [7/8 Regression] Unclassifiable statement during compilation when assigning to a Character array in a derived type contained in a ASSOCIATE statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82121 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Paul Thomas --- Fixed on trunk and 7-branch. Thanks for the report. Paul
[Bug fortran/67543] ICE on associate with improper association
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67543 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED CC||pault at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Paul Thomas --- Fixed on trunk and 7-branch. Thanks for the report. Paul
[Bug fortran/78152] [6/7/8 Regression] coarray and associate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78152 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Paul Thomas --- Fixed on trunk and 7-branch. I am sorry, I don't have the time to go back to 6-branch and fix it there. Thanks for the report. Paul
[Bug c++/82570] New: Lambda fails to compile because it doesn't meet constexpr requirements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82570 Bug ID: 82570 Summary: Lambda fails to compile because it doesn't meet constexpr requirements Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: andysem at mail dot ru Target Milestone: --- Created attachment 42380 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42380&action=edit A testcase that shows the problem. The attached program fails to compile with the following command line: g++-7 -std=gnu++1z -o test_constexpr_lambda test_constexpr_lambda.cpp test_constexpr_lambda.cpp: In instantiation of ‘foo(Pred):: [with Pred = main()::]’: test_constexpr_lambda.cpp:12:7: required from ‘struct foo(Pred) [with Pred = main()::]::’ test_constexpr_lambda.cpp:10:9: required from ‘void foo(Pred) [with Pred = main()::]’ test_constexpr_lambda.cpp:25:33: required from here test_constexpr_lambda.cpp:14:18: error: uninitialized variable ‘buf’ in ‘constexpr’ function unsigned char buf[4]; ^~~ test_constexpr_lambda.cpp:2:13: error: ‘void iterate(Body) [with Body = foo(Pred) [with Pred = main()::]::]’, declared using local type ‘foo(Pred) [with Pred = main()::]::’, is used but never defined [-fpermissive] inline void iterate(Body body) ^~~ test_constexpr_lambda.cpp:2:13: warning: ‘void iterate(Body) [with Body = foo(Pred) [with Pred = main()::]::]’ used but never defined The program compiles with -std=gnu++14. It also compiles successfully with gcc 6.3.0 and -std=gnu++1z (i.e. this is a regression since gcc 6). I believe, this is a compiler bug because (a) neither the lambda nor the calling code are marked constexpr and (b) according to [expr.prim.lambda.closure]/4 the lambda should only be considered constexpr if it meets constexpr requirements (otherwise it should be compiled as a regular runtime function). g++-7 -v Using built-in specs. COLLECT_GCC=g++-7 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.2.0-1mind1' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 7.2.0 (Ubuntu 7.2.0-1mind1)
[Bug fortran/81758] [7/8 Regression] [OOP] Broken vtab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758 --- Comment #11 from Thomas Koenig --- With r241438, the test passes.
[Bug fortran/81758] [7/8 Regression] [OOP] Broken vtab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758 --- Comment #12 from Thomas Koenig --- And with r241439, the test fails. Andre, any ideas?
[Bug tree-optimization/82571] New: missing strlen optimization for memchr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82571
Bug ID: 82571
Summary: missing strlen optimization for memchr
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: ---
The result of a call to memchr(a, '\0', sizeof a) where a is a nul-terminated
string is the same as (a + strlen (a)). GCC could use this equivalence to
optimize code like that in functions f0() and f1() the same way it optimizes
functions g0() and g1().
$ gcc -O2 -S -fdump-tree-optimized=/dev/stdout a.c
;; Function f0 (f0, funcdef_no=0, decl_uid=1815, cgraph_uid=0, symbol_order=0)
f0 ()
{
char * p;
char a[9];
[100.00%] [count: INV]:
__builtin_memcpy (&a, "012345", 7);
p_3 = __builtin_memchr (&a, 0, 9);
if (p_3 == 0B)
goto ; [0.04%] [count: 0]
else
goto ; [99.96%] [count: INV]
[0.04%] [count: 0]:
__builtin_abort ();
[99.96%] [count: INV]:
a ={v} {CLOBBER};
return;
}
;; Function f1 (f1, funcdef_no=1, decl_uid=1820, cgraph_uid=1, symbol_order=1)
f1 ()
{
char * p;
char a[9];
long int p.0_1;
long int a.1_2;
long int _3;
[100.00%] [count: INV]:
__builtin_memcpy (&a, "012345", 7);
p_8 = __builtin_memchr (&a, 0, 9);
p.0_1 = (long int) p_8;
a.1_2 = (long int) &a;
_3 = p.0_1 - a.1_2;
if (_3 != 6)
goto ; [0.04%] [count: 0]
else
goto ; [99.96%] [count: INV]
[0.04%] [count: 0]:
__builtin_abort ();
[99.96%] [count: INV]:
a ={v} {CLOBBER};
return;
}
;; Function g0 (g0, funcdef_no=2, decl_uid=1825, cgraph_uid=2, symbol_order=2)
g0 ()
{
[100.00%] [count: INV]:
return;
}
;; Function g1 (g1, funcdef_no=3, decl_uid=1830, cgraph_uid=3, symbol_order=3)
g1 ()
{
[100.00%] [count: INV]:
return;
}
[Bug other/82569] [8 regression] failure in 177.mesa cpu2000 test case after r253530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82569 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-10-16 Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- > So, if I compare the parameter values at this point in the working (r253529) > and failing (r253530) code r6 holds the bad parm value: > > failing: > (gdb) info registers > ... > r6 0xfff007a 17587891077242 > > Works: > (gdb) info registers > ... > r6 0x7a 122 > > > Why does this happen? When it fails the value that is computed earlier in > the code for the parameter > > iy = ((fy) >> 11); > > is stored via an "stw" and then loaded via a "ld". If there is any leftover > garbage in the memory it will fail. It doesn't always fail as sometimes the > memory has 0 in the bytes not stored to via the stw and loaded via the ld. > > So, looking at the assembly output: > > works: >0x10094f9c <.general_textured_triangle+2092>: srawi r8,r4,11 >0x10094fa0 <.general_textured_triangle+2096>: std r8,29256(r1) > ... >0x100952c0 <.general_textured_triangle+2896>: ld r10,29256(r1) >(this is then stored again and loaded into r6 for the function call via > std/ld) > > fails: >0x10094d84 <.general_textured_triangle+2052>: srawi r9,r3,11 >0x10094d88 <.general_textured_triangle+2056>: stw r9,29268(r1) > ... >0x10095094 <.general_textured_triangle+2836>: ld r10,29264(r1) >(this is then stored again and loaded into r6 for the function call via > std/ld) > > Something in this revision causes the (working) std to be replaced by a stw. Thanks for the preliminary analysis. The change is supposed (1) to have an effect only when there is an uninitialized variable in the code and (2) to disable an unwarranted optimization. That being said, it might also be far-reaching enough to either expose another bug or trigger a conflict with another part of the RTL back-end. Can you attach a preprocessed testcase and a command line? FWIW I have access to gcc110 in the Compile Farm.
[Bug middle-end/82567] [6/7/8] gfortran takes a long time to compile a simple implied-do with -Optimization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82567 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org Component|fortran |middle-end Target Milestone|--- |7.3 --- Comment #3 from Thomas Koenig --- Some time reports: $ gfortran -ffrontend-optimize -ftime-report pr82567.f90 Execution times (seconds) phase parsing : 0.18 ( 5%) usr 0.01 ( 8%) sys 0.19 ( 5%) wall 5542 kB (11%) ggc phase opt and generate : 3.55 (95%) usr 0.10 (83%) sys 3.66 (95%) wall 43204 kB (88%) ggc $ gfortran -O -ftime-report pr82567.f90 Execution times (seconds) phase parsing : 0.20 ( 1%) usr 0.01 (11%) sys 0.21 ( 1%) wall 5543 kB (15%) ggc phase opt and generate : 26.96 (99%) usr 0.08 (89%) sys 27.07 (99%) wall 30881 kB (84%) ggc The problem seems to be that we generate a load of statements like (*(real(kind=4)[1] * restrict) atmp.1.data)[0] = NON_LVALUE_EXPR <__var_1_constr>; (*(real(kind=4)[1] * restrict) atmp.1.data)[1] = __var_1_constr * 2.0e+0; (*(real(kind=4)[1] * restrict) atmp.1.data)[2] = __var_1_constr * 3.0e+0; (*(real(kind=4)[1] * restrict) atmp.1.data)[3] = __var_1_constr * 4.0e+0; for the test case as written below. For the other versions, we actually do not convert the array descriptor.
[Bug c++/82560] [7/8 Regression] Temporary object created as a default argument not destructed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82560 Nathan Sidwell changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org
[Bug c++/69078] [C++14] function local static not initialized when only used in a generic/variadic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69078
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #5 from Christophe Lyon ---
Hi,
I couldn't find the email where this patch was posted, so I reply here.
I've noticed that the new testcase:
> PR c++/69078
> * g++.dg/cpp1y/lambda-generic-69078-1.C: New.
fails on arm-none-eabi
--with-mode default
--with-cpu default
--with-fpu default
(that is, when the default arm target is an old, less-capable cpu).
The test fails to link for lack of __sync_synchronize.
In other occasions, a fix for this kind of problem was to add
// { dg-require-thread-fence "" }
but this doesn't work here, as this dg proc is only defined in the libstdc++
testsuite.
How to skip it here?
[Bug sanitizer/82353] [8 Regression] runtime ubsan crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82353 --- Comment #10 from Vladimir Makarov --- Author: vmakarov Date: Mon Oct 16 20:34:53 2017 New Revision: 253796 URL: https://gcc.gnu.org/viewcvs?rev=253796&root=gcc&view=rev Log: 2017-10-16 Vladimir Makarov PR sanitizer/82353 * lra.c (collect_non_operand_hard_regs): Don't ignore operator locations. * lra-lives.c (bb_killed_pseudos, bb_gen_pseudos): Move up. (make_hard_regno_born, make_hard_regno_dead): Update bb_killed_pseudos and bb_gen_pseudos for fixed regs. Modified: trunk/gcc/ChangeLog trunk/gcc/lra-lives.c trunk/gcc/lra.c
[Bug other/82569] [8 regression] failure in 177.mesa cpu2000 test case after r253530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82569 --- Comment #2 from seurer at gcc dot gnu.org --- This is one of those SPEC tests so I can't post the whole .i. I will see if I can extract part of it that still shows the same bad STW/LD behavior. I probably will not get to it until tomorrow, though.
[Bug debug/58150] debug info about definition of enum class not emitted if the declaration was already used in a class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58150 npl at chello dot at changed: What|Removed |Added CC||npl at chello dot at --- Comment #2 from npl at chello dot at --- Created attachment 42381 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42381&action=edit another testcase I was generating a testcase before discovering this bug. Problem is the same: A class/struct using a prototyped, not yet defined "enum class" will prevent that debug information for this "enum class" to be emitted. Only if no class/struct uses a "enum class" before its defined, the debug info will be available. Affected: GCC 5.3.0, GCC 6.4.0, GCC 7.2.0 Please fix this, it really makes debugging a pain
[Bug c++/82572] New: throw on line by itself in constexpr function aborts compile even if never reached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82572
Bug ID: 82572
Summary: throw on line by itself in constexpr function aborts
compile even if never reached
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ekchew at lgl dot kos.net
Target Milestone: ---
This code will not compile in C++14:
constexpr void foo() {
if(true)
return;
throw "What am I doing here?";
}
Error:
gccbug.cc: In function 'constexpr void foo()':
gccbug.cc:4:8: error: expression '' is not a constant
expression
throw "What am I doing here?";
^~~
Build:
COLLECT_GCC=g++-7
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/7.2.0/libexec/gcc/x86_64-apple-darwin16.7.0/7.2.0/lto-wrapper
Target: x86_64-apple-darwin16.7.0
Configured with: ../configure --build=x86_64-apple-darwin16.7.0
--prefix=/usr/local/Cellar/gcc/7.2.0
--libdir=/usr/local/Cellar/gcc/7.2.0/lib/gcc/7
--enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-7
--with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr
--with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl
--with-system-zlib --enable-checking=release --with-pkgversion='Homebrew GCC
7.2.0' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues
--disable-nls --with-native-system-header-dir=/usr/include
--with-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk
Thread model: posix
gcc version 7.2.0 (Homebrew GCC 7.2.0)
[Bug tree-optimization/71867] Optimizer generates code dereferencing a null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71867
--- Comment #10 from asmwarrior ---
Is it related to pointer casting? I see this post:
https://stackoverflow.com/questions/36816363/gcc-4-9-3-more-aggressive-null-pointer-check-removal
Some one reported that the Null check was removed in the following code
void someFunc(struct MyStruct *s)
{
if (s != NULL)
{
cout << s->someField << endl;
delete s;
}
}
I see comments in that question, and some one suggest using
`-fno-strict-aliasing` option.
@Vadim, dose wx use some cast? I see some macros in wx3.1's source like:
// this cast does some more checks at compile time as it uses static_cast
// internally
//
// note that it still has different semantics from dynamic_cast<> and so can't
// be replaced by it as long as there are any compilers not supporting it
#define wxDynamicCast(obj, className) \
((className *) wxCheckDynamicCast( \
const_cast(static_cast(\
const_cast(static_cast(obj, \
&className::ms_classInfo))
[Bug tree-optimization/82574] New: wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82574
Bug ID: 82574
Summary: wrong code at -O3 on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
This seems to be a recent regression.
$ gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.0 20171016 (experimental) [trunk revision 253793] (GCC)
$
$ gcctk -O2 small.c; ./a.out; echo $?
0
$ gcc-7.2.0 -O3 small.c; ./a.out; echo $?
0
$
$ gcctk -O3 small.c; ./a.out; echo $?
1
$
---
char a, b, c, d[2][3];
int main ()
{
for (; a < 2; a++)
for (b = 0; b < 3; b++)
if (c)
d[a][b] = 1;
return d[0][0];
}
[Bug c++/82572] throw on line by itself in constexpr function aborts compile even if never reached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82572 Andrew Pinski changed: What|Removed |Added Depends on||80061 --- Comment #1 from Andrew Pinski --- I think this is almost a dup of bug 80061. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80061 [Bug 80061] error on constexpr function with an unevaluated throw
[Bug ada/82573] GNAT.Registry doesn't read/write with HKEY_LOCAL_MACHINE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82573 Andrew John Hughes changed: What|Removed |Added CC||gnu_andrew at member dot fsf.org --- Comment #1 from Andrew John Hughes --- This doesn't seem to be related to GNU Classpath.
[Bug rtl-optimization/78911] [6 Regression] Infinite loop at -O2/O3 optimization levels while trying to compile server.c from Wine-2.0-rc2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78911 Viktor Yu. Kovalskii changed: What|Removed |Added CC||vityokster at gmail dot com --- Comment #17 from Viktor Yu. Kovalskii --- We try investigate source of this error in two different bugzilla's: https://bugs.gentoo.org/613128 https://bugs.winehq.org/show_bug.cgi?id=42406 I hope information from this bug reports will be very helpful. Right now this bug reproduced with gcc-6.4.0 and wine-2.17.
[Bug other/78808] target_clones not applying to openmp functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78808 --- Comment #9 from Steven Noonan --- Actually, I lied. It's not quite working. It's obviously close though. The following examples of the issue are using my n-body implementation: https://github.com/tycho/nbody Each of the variants of n-body have a bunch of link issues: $ make CFOPTIMIZE="-O3 -march=core2" [...] nbody_CPU_SOA.o: In function `_ComputeGravitation_SOA.default.8': nbody_CPU_SOA.c:(.text+0x1e): undefined reference to `_ComputeGravitation_SOA._omp_fn.0._GLOBAL___ComputeGravitation_SOA.ifunc' nbody_CPU_SOA.o: In function `_ComputeGravitation_SOA.arch_skylake.4': nbody_CPU_SOA.c:(.text+0x59b): undefined reference to `_ComputeGravitation_SOA._omp_fn.0._GLOBAL___ComputeGravitation_SOA.ifunc' nbody_CPU_SOA.o: In function `_ComputeGravitation_SOA.arch_haswell.5': nbody_CPU_SOA.c:(.text+0x63b): undefined reference to `_ComputeGravitation_SOA._omp_fn.0._GLOBAL___ComputeGravitation_SOA.ifunc' nbody_CPU_SOA.o: In function `_ComputeGravitation_SOA.arch_sandybridge.6': nbody_CPU_SOA.c:(.text+0x6db): undefined reference to `_ComputeGravitation_SOA._omp_fn.0._GLOBAL___ComputeGravitation_SOA.ifunc' [...] Symbols in nbody_CPU_SOA.o: $ nm src/nbody_CPU_SOA.o 00a0 t bodyBodyInteraction 0c00 T ComputeGravitation_SOA 0610 t _ComputeGravitation_SOA.arch_haswell.5 06b0 t _ComputeGravitation_SOA.arch_sandybridge.6 0570 t _ComputeGravitation_SOA.arch_skylake.4 t _ComputeGravitation_SOA.default.8 0bb0 i _ComputeGravitation_SOA._GLOBAL___ComputeGravitation_SOA.ifunc 0290 t _ComputeGravitation_SOA._omp_fn.0.arch_haswell.2 0400 t _ComputeGravitation_SOA._omp_fn.0.arch_sandybridge.3 0120 t _ComputeGravitation_SOA._omp_fn.0.arch_skylake.1 0750 t _ComputeGravitation_SOA._omp_fn.0.default.7 U _ComputeGravitation_SOA._omp_fn.0._GLOBAL___ComputeGravitation_SOA.ifunc 0b60 t _ComputeGravitation_SOA._omp_fn.0.resolver 0bb0 t _ComputeGravitation_SOA.resolver U __cpu_indicator_init U __cpu_model U GOMP_loop_end_nowait U GOMP_loop_ull_guided_next U GOMP_loop_ull_guided_start U GOMP_parallel r .LC0 0004 r .LC1 0008 r .LC2 r .LC4 0010 r .LC5 U libtime_cpu_to_wall There's a second issue as well. If I tell it to build with -march=native, I get compile errors: $ make CFOPTIMIZE="-O3 -march=native" V=1 make -C libc11 libc11.a make -C libtime libtime.a make -C src nbody gcc -O3 -march=native -std=gnu11 -fno-strict-aliasing -D_GNU_SOURCE -DLIBTIME_STATIC -DUSE_OPENMP -DHAVE_SIMD -DNO_CUDA -DUSE_LIBC11 -I../libc11/include -I../libtime/include -Wall -Wdeclaration-after-statement -Werror=implicit -Werror=undef -Wmissing-declarations -Wmissing-prototypes -Wno-declaration-after-statement -Wno-long-long -Wno-overlength-strings -Wno-unknown-pragmas -Wold-style-definition -Wstrict-prototypes -pthread -fopenmp -MMD -c -o nbody_CPU_AOS.o nbody_CPU_AOS.c gcc -O3 -march=native -std=gnu11 -fno-strict-aliasing -D_GNU_SOURCE -DLIBTIME_STATIC -DUSE_OPENMP -DHAVE_SIMD -DNO_CUDA -DUSE_LIBC11 -I../libc11/include -I../libtime/include -Wall -Wdeclaration-after-statement -Werror=implicit -Werror=undef -Wmissing-declarations -Wmissing-prototypes -Wno-declaration-after-statement -Wno-long-long -Wno-overlength-strings -Wno-unknown-pragmas -Wold-style-definition -Wstrict-prototypes -pthread -fopenmp -MMD -c -o nbody_CPU_AOS_tiled.o nbody_CPU_AOS_tiled.c gcc -O3 -march=native -std=gnu11 -fno-strict-aliasing -D_GNU_SOURCE -DLIBTIME_STATIC -DUSE_OPENMP -DHAVE_SIMD -DNO_CUDA -DUSE_LIBC11 -I../libc11/include -I../libtime/include -Wall -Wdeclaration-after-statement -Werror=implicit -Werror=undef -Wmissing-declarations -Wmissing-prototypes -Wno-declaration-after-statement -Wno-long-long -Wno-overlength-strings -Wno-unknown-pragmas -Wold-style-definition -Wstrict-prototypes -pthread -fopenmp -MMD -c -o nbody_CPU_SOA.o nbody_CPU_SOA.c gcc -O3 -march=native -std=gnu11 -fno-strict-aliasing -D_GNU_SOURCE -DLIBTIME_STATIC -DUSE_OPENMP -DHAVE_SIMD -DNO_CUDA -DUSE_LIBC11 -I../libc11/include -I../libtime/include -Wall -Wdeclaration-after-statement -Werror=implicit -Werror=undef -Wmissing-declarations -Wmissing-prototypes -Wno-declaration-after-statement -Wno-long-long -Wno-overlength-strings -Wno-unknown-pragmas -Wold-style-definition -Wstrict-prototypes -pthread -fopenmp -MMD -c -o nbody_CPU_SOA_tiled.o nbody_CPU_SOA_tiled.c In file included from nbody_CPU_AOS.c:42:0: nbody_CPU_AOS.c: In function ‘_ComputeGravitation_AOS.arch_skylake.4’: nbody_util.h:114:21: error: SSE register return with SSE disabled static DECLARE_AOS(_ ## Name) ^ nbody_util.h:96:2: note: in definition of macro ‘DECLARE_AOS’ Name( \ ^~~~ nbody_CPU_AOS.c:47:1: note
