[Bug tree-optimization/85186] ifcvt can peel iterations affecting code form, and causing vectorization not to happen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85186 --- Comment #4 from Hans-Peter Nilsson --- I forgot to mention that this is likely a regression since gcc-4.7-era, but I haven't proved that elsewhere than on the original target (not x86_64-linux / sse2).
[Bug tree-optimization/85186] ifcvt can peel iterations affecting code form, and causing vectorization not to happen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85186 --- Comment #3 from Hans-Peter Nilsson --- Created attachment 43836 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43836&action=edit case 4
[Bug tree-optimization/85186] ifcvt can peel iterations affecting code form, and causing vectorization not to happen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85186 --- Comment #2 from Hans-Peter Nilsson --- Created attachment 43835 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43835&action=edit case 3
[Bug tree-optimization/85186] ifcvt can peel iterations affecting code form, and causing vectorization not to happen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85186 --- Comment #1 from Hans-Peter Nilsson --- Created attachment 43834 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43834&action=edit case 2
[Bug tree-optimization/85186] New: ifcvt can peel iterations affecting code form, and causing vectorization not to happen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85186 Bug ID: 85186 Summary: ifcvt can peel iterations affecting code form, and causing vectorization not to happen Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hp at gcc dot gnu.org Target Milestone: --- Created attachment 43833 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43833&action=edit original non-vectorizing case: 1 In a build for x86_64-linux (likely also other targets; this originates elsewhere) at r258635, drop in attached four test-cases into the dg/vect subdir. Observe, when running vect.exp: Running x/gcc/testsuite/gcc.dg/vect/vect.exp ... FAIL: gcc.dg/vect/prX-1.c scan-tree-dump-times vect "vectorized 1 loops" 1 FAIL: gcc.dg/vect/prX-1.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1 I.e. prX-1.c does not vectorize, while -2..4 does. Partial analysis: On inspection using gdb and dumps, this appears to be because the initialization appears to affect ifcvt (just as a catalyst) causing it to sort-of peel the first iteration of the to-be-vectorized loop, or something to that effect, anyway changing the form of the code such that it is not be recognizable for the loop vectorizer pass that comes next. 1: original (derived from some other gcc test long ago) 2: candidate loop with non-conditional contents: vectorizes. 3: arrays in candidate loop are moved global (i.e. aren't initialized right before the loop): vectorizes. 4: asm("" : : : "memory") inserted after initialization: vectorizes. All-in-all this PR isn't important (with the test-cases being artificial), but when revisiting if-conversion and/or investigates ifcvt vs. loop-vectorization issues, this PR may provide simplified test-cases of an underlying bug.
[Bug inline-asm/85185] Wider-than-expected load for struct member used as operand of inline-asm with memory clobber at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85185 --- Comment #2 from Zev Weiss --- I was wondering if I might be unwittingly violating some subtle rule like that; are the details of this documented? I don't see anything obvious in section 6.45.2.5 ("Input Operands") of the GCC manual, but perhaps I'm missing something or not looking in the right place. Also, would the undefinedness you describe extend to the remaining 32 bits above that as well? (I'm a bit unclear on why/how 32-bit values would enter the picture if the underlying variable is 16 bits and the hardware register is 64 -- is integer promotion applied to inline asm operands? If so, the selection of %ax on x86-64 seems odd.)
[Bug c++/84943] [8 Regression] internal compiler error: in build_call_a, at cp/call.c:374
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84943 Alexandre Oliva changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Alexandre Oliva --- Fixed
[Bug c++/84943] [8 Regression] internal compiler error: in build_call_a, at cp/call.c:374
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84943 --- Comment #5 from Alexandre Oliva --- Author: aoliva Date: Wed Apr 4 03:40:29 2018 New Revision: 259067 URL: https://gcc.gnu.org/viewcvs?rev=259067&root=gcc&view=rev Log: [PR c++/84943] mark function as used when taking its address fn[0]() ICEd because we would fold the INDIRECT_REF used for the array indexing while building the address for the call, after not finding the decl hiding there at first. But the decl would be exposed by the folding, and then lower layers would complain we had the decl, after all, but it wasn't one of the artificial or special functions that could be called without being marked as used. This patch arranges for a FUNCTION_DECL to be marked as used when taking its address, just like we already did when taking the address of a static function to call it as a member function (i.e. using the obj.fn() notation). However, we shouldn't mark functions as used when just performing overload resolution, lest we might instantiate templates we shouldn't, as in g++.dg/overload/template1.C, so we adjust mark_used to return early when testing conversions. for gcc/cp/ChangeLog PR c++/84943 * typeck.c (cp_build_addr_expr_1): Mark FUNCTION_DECL as used. * decl2.c (mark_used): Return without effects if tf_conv. for gcc/testsuite/ChangeLog PR c++/84943 * g++.dg/pr84943.C: New. * g++.dg/pr84943-2.C: New. Added: trunk/gcc/testsuite/g++.dg/pr84943-2.C trunk/gcc/testsuite/g++.dg/pr84943.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog
[Bug driver/85165] gcc (and g++) not complaining about few unknown file extensions like *.CC, *.Cc, *.cC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85165 Kiran Alladi changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Kiran Alladi --- @Andrew: Yes, your observation is right. This difference in behavior is due to windows and unix case sensitive nature. Hence resolving this issue. Thanks for your inputs.
[Bug inline-asm/85185] Wider-than-expected load for struct member used as operand of inline-asm with memory clobber at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85185 --- Comment #1 from Andrew Pinski --- I think the upper 16bits are considered as undefined when using inline-asm like this.
[Bug inline-asm/85185] New: Wider-than-expected load for struct member used as operand of inline-asm with memory clobber at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85185 Bug ID: 85185 Summary: Wider-than-expected load for struct member used as operand of inline-asm with memory clobber at -Og Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: inline-asm Assignee: unassigned at gcc dot gnu.org Reporter: zev+gccbug at bewilderbeest dot net Target Milestone: --- Created attachment 43832 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43832&action=edit Minimized reproducer In the attached test case, compiling with -Og generates a wider memory access than expected (4 bytes instead of 2, on the LP64 targets I'm dealing with) to load sub.a on line 12. -- $ nl -ba min.c 1 struct sub { 2short a, b; 3 }; 4 5 struct { 6int i; 7struct sub P; 8 } S; 9 10 static inline void inner(struct sub sub) 11 { 12asm("magic %0" :: "r" (sub.a) : "memory"); 13 } 14 15 void outer(void) 16 { 17inner(S.P); 18 } $ gcc -S -o - -Og min.c .file "min.c" .text .globl outer .type outer, @function outer: .LFB1: .cfi_startproc movl4+S(%rip), %eax #APP # 12 "min.c" 1 magic %ax # 0 "" 2 #NO_APP ret .cfi_endproc .LFE1: .size outer, .-outer .comm S,8,8 .ident "GCC: (GNU) 7.3.0" .section.note.GNU-stack,"",@progbits -- On x86-64 it ends up being relatively harmless because it uses a 16-bit register (%ax) as the actual operand used in the instruction, but on targets that only have full-width registers (riscv64 being the one at hand for me) this results in the instruction receiving a very different operand than desired (containing additional bytes from the neighboring struct member): -- $ riscv64-unknown-elf-gcc -S -o - -Og min.c .file "min.c" .option nopic .text .align 2 .globl outer .type outer, @function outer: addisp,sp,-16 lui a5,%hi(S) addia5,a5,%lo(S) lw a5,4(a5) sw a5,8(sp) #APP # 17 "min.c" 1 magic a5 # 0 "" 2 #NO_APP addisp,sp,16 jr ra .size outer, .-outer .comm S,8,8 .ident "GCC: (GNU) 7.2.0" -- This only occurs when compiling with -Og; -O0, -O1, -O2, and -O3 all generate the expected two-byte load (movzwl instead of movl on x86-64, lh or lhu instead of lw on riscv64). I've also found via a bit of haphazard guess-based experimentation that adding -ftree-sra to -Og produces a two-byte load as well. I've observed these same patterns (4-byte load at -Og, 2-byte load at all other -O levels or with -ftree-sra) on a number of different GCCs: - x86-64: 4.8.2 (Red Hat), 5.1.0 (source), 5.4.0 (Ubuntu), 7.2.0 (source), 7.3.0 (Void) - riscv64: 6.1.0 and 7.2.0 (both from source; I realize the former predates official upstream riscv support but is perhaps illustrative nonetheless) I've filed this on release 7.2.0 because that's the version where this is actually biting me -- and as mentioned above, is only actually causing problems on riscv, but the very similar code generation on x86 makes me suspect the underlying problem is target-independent (and has apparently existed for a while).
[Bug tree-optimization/85175] [8 regression] false-positive -Wformat-overflow= warning with gcc-8 -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85175 --- Comment #4 from Martin Sebor --- In general, sizing buffers for the minimum/maximum value of each directive's argument and choosing the appropriate length modifiers (e.g., %hhi for char or %hi for short) avoids these problems. The thinking behind the current behavior at level 1 is that an expression in some known range is a sign that the programmer may have made an effort to constrain the value, while an expression for which we have no range information may have been constrained and we just don't see it. When the known range doesn't constrain the value sufficiently, the warning triggers. An unknown range doesn't. The "fix" for a warning in the former case should in most cases be to simply constrain the variable either by using an appropriate length modifier in the directive or just before the call (e.g., via some form of an assertion or an equivalent of '((x < min || x > max) ? __builtin_unreachable () : (void)0). This works quite well except when the buffer is just big enough and when the warning exposes weaknesses in optimizations and/or unforeseen interactions with other transformations (usually jump-threading or the sanitizers). Rather than weakening the warnings our approach to these problems has been to improve the optimizers. I'm hoping this case can be dealt with the same way but I'm not familiar enough with the EVRP machinery yet to tell if that will be possible. As for -Wformat-overflow=2, an expression in an unknown range is treated as if it had the maximum range of its type. (I suppose we should also have level 3 where ranges are ignored and buffers are expected to be sized only according to argument type. I realize it's not what you're looking for but it would make it straightforward to write safe, warning-free code regardless of optimizations.)
[Bug c++/85092] [8 Regression] ICE under -std=gnu++1z in build_over_call under, at cp/call.c:8149
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85092 --- Comment #7 from Pavel Roskin --- I confirm that the issue has been fixed in the project I'm working on. Thank you!
[Bug c/85182] _Static_assert is less than useful in a static inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85182 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #5 from Martin Sebor --- The GCC feature that comes close to what you're looking for from _Static_assert are attributes error and warning. The difference is that the attributes are considered very late during translation while _Static_assert is evaluated very early, during parsing. Here's an example of how to set it up: $ cat static-assert.[hc] && gcc -O2 -S -Wall static-assert.c #include "static-assert.h" void f (void) { bar (1); } void g (void) { bar (0); } void h (int i) { bar (i); } void __attribute__ ((error ("my static assertion failed"))) my_static_assert_fail (void); void __attribute__ ((warning ("my static assertion unable to evaluate expression"))) my_static_assert_nonconst (void); static void inline __attribute__ ((always_inline)) my_static_assert (int expr) { if (!__builtin_constant_p (expr)) { my_static_assert_nonconst (); return; } if (expr) return; my_static_assert_fail (); } static inline void bar (int i) { my_static_assert (i); } In file included from static-assert.c:1: In function ‘my_static_assert’, inlined from ‘g’ at static-assert.h:24:3: static-assert.h:19:3: error: call to ‘my_static_assert_fail’ declared with attribute error: my static assertion failed my_static_assert_fail (); ^~~~ In function ‘my_static_assert’, inlined from ‘h’ at static-assert.h:24:3: static-assert.h:12:7: warning: call to ‘my_static_assert_nonconst’ declared with attribute warning: my static assertion unable to evaluate expression my_static_assert_nonconst (); ^~~~
[Bug libstdc++/85183] [8 Regression] std::variant move assignment mishandles move-only types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85183 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Jonathan Wakely --- Fixed - thanks!
[Bug libstdc++/85183] [8 Regression] std::variant move assignment mishandles move-only types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85183 --- Comment #1 from Jonathan Wakely --- Author: redi Date: Tue Apr 3 23:03:07 2018 New Revision: 259059 URL: https://gcc.gnu.org/viewcvs?rev=259059&root=gcc&view=rev Log: PR libstdc++/85183 fix std::variant move-assignment PR libstdc++/85183 * include/std/variant (_Move_assign_base::operator=): Fix incorrect value categories. * testsuite/20_util/variant/85183.cc: New. Added: trunk/libstdc++-v3/testsuite/20_util/variant/85183.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/variant
[Bug libstdc++/85183] [8 Regression] std::variant move assignment mishandles move-only types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85183 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Known to work||7.3.0 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |8.0 Known to fail||8.0.1
[Bug libstdc++/83625] std::experimental::filesystem::remove lstat()'s before remove() instead of checking errno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83625 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.5 --- Comment #1 from Jonathan Wakely --- (In reply to Andrew Gunnerson from comment #0) > This could cause the function to report an error if the path is deleted > between the stat() and remove() instead of returning false. Would it make > sense to always attempt remove() and return false if errno == ENOENT instead? This was done as part of PR 83626
[Bug libstdc++/85184] New: Remove __glibcxx_assert uses from std::variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85184 Bug ID: 85184 Summary: Remove __glibcxx_assert uses from std::variant Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- These assertions are being used to verify that the implementation works correctly, i.e. to catch logic errors. Users should not be paying for those checks at runtime. The assertions should be removed before we declare our C++17 support non-experimental.
[Bug libstdc++/85183] [8 Regression] std::variant move assignment mishandles move-only types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85183 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-03 Ever confirmed|0 |1
[Bug target/83562] broken destructors of thread_local objects on i686 mingw targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83562 Alexandre Pereira Nunes changed: What|Removed |Added CC||alexandre.nunes at gmail dot com --- Comment #1 from Alexandre Pereira Nunes --- I can confirm that on gcc 7.3.0 / i686-mingw64.
[Bug libstdc++/85183] New: [8 Regression] std::variant move assignment mishandles move-only types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85183 Bug ID: 85183 Summary: [8 Regression] std::variant move assignment mishandles move-only types Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: rs2740 at gmail dot com Target Milestone: --- Repro: #include struct moveonly { moveonly() noexcept { } moveonly(moveonly&&) noexcept { } moveonly& operator=(moveonly&&) noexcept { return *this; } ~moveonly() { } }; void test() { std::variant m1, m2; m1 = std::move(m2); } Compiles with 7. Breaks with 8: In file included from prog.cc:1: /opt/wandbox/gcc-head/include/c++/8.0.1/variant: In instantiation of 'void std::__detail::__variant::__erased_assign(void*, void*) [with _Lhs = moveonly&; _Rhs = const moveonly&]': /opt/wandbox/gcc-head/include/c++/8.0.1/variant:607:27: required from 'std::__detail::__variant::_Move_assign_base<, _Types>& std::__detail::__variant::_Move_assign_base<, _Types>::operator=(std::__detail::__variant::_Move_assign_base<, _Types>&&) [with bool = false; _Types = {moveonly}]' /opt/wandbox/gcc-head/include/c++/8.0.1/variant:648:12: required from here /opt/wandbox/gcc-head/include/c++/8.0.1/variant:258:42: error: use of deleted function 'constexpr moveonly& moveonly::operator=(const moveonly&)' __variant::__ref_cast<_Lhs>(__lhs) = __variant::__ref_cast<_Rhs>(__rhs); ~~~^~~~ prog.cc:3:8: note: 'constexpr moveonly& moveonly::operator=(const moveonly&)' is implicitly declared as deleted because 'moveonly' declares a move constructor or move assignment operator struct moveonly { ^~~~ In file included from prog.cc:1: /opt/wandbox/gcc-head/include/c++/8.0.1/variant: In instantiation of 'void std::__detail::__variant::__erased_ctor(void*, void*) [with _Lhs = moveonly&; _Rhs = const moveonly&]': /opt/wandbox/gcc-head/include/c++/8.0.1/variant:468:30: required from 'std::__detail::__variant::_Copy_ctor_base<, _Types>::_Copy_ctor_base(const std::__detail::__variant::_Copy_ctor_base<, _Types>&) [with bool = false; _Types = {moveonly}]' /opt/wandbox/gcc-head/include/c++/8.0.1/variant:509:7: required from 'std::__detail::__variant::_Move_assign_base<, _Types>& std::__detail::__variant::_Move_assign_base<, _Types>::operator=(std::__detail::__variant::_Move_assign_base<, _Types>&&) [with bool = false; _Types = {moveonly}]' /opt/wandbox/gcc-head/include/c++/8.0.1/variant:648:12: required from here /opt/wandbox/gcc-head/include/c++/8.0.1/variant:246:7: error: use of deleted function 'constexpr moveonly::moveonly(const moveonly&)' ::new (__lhs) _Type(__variant::__ref_cast<_Rhs>(__rhs)); ^~~ prog.cc:3:8: note: 'constexpr moveonly::moveonly(const moveonly&)' is implicitly declared as deleted because 'moveonly' declares a move constructor or move assignment operator struct moveonly { There are two bugs in the move assignment operator of _Move_assign_base primary template, presumably caused by copy-paste: * in the matching index case, it uses __erased_assign<_Types&, const _Types&> when it should be using __erased_assign<_Types&, _Types&&>. * in the mismatched index case, it copies __rhs to create __tmp (`_Move_assign_base __tmp(__rhs);`) when it should have moved from it.
[Bug c/85182] _Static_assert is less than useful in a static inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85182 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Andrew Pinski --- The call to the function is not needed to get the static assert to happen.
[Bug c/85182] _Static_assert is less than useful in a static inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85182 Adam Jackson changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #3 from Adam Jackson --- (In reply to jos...@codesourcery.com from comment #1) > This is how static assertions are defined in C11, not a bug in GCC: it's a > constraint violation if the constant expression compares equal to 0, > regardless of the context in which the declaration appears (thus, a > constraint violation in a function that is never called, for example). You missed my point. The diagnostic points me to the site of the declaration of the static inline, not of the call site. Let's make this more explicit: --- desoxy:~/git/junkdrawer% cat -n static-assert.h 1 static inline void bar(void) 2 { 3 const int y = 0; 4 _Static_assert(y, "called bar()"); 5 } desoxy:~/git/junkdrawer% cat -n static-assert.c 1 #include "static-assert.h" 2 void foo(void) { bar(); } desoxy:~/git/junkdrawer% gcc -O2 -c static-assert.c In file included from static-assert.c:1: static-assert.h: In function ‘bar’: static-assert.h:4:5: error: static assertion failed: "called bar()" _Static_assert(y, "called bar()"); ^~ --- Don't tell me "in file A included from this spot in B, you hit a static assert". Tell me "At this spot in A, this function defined in B hit a static assert". Because otherwise, with a less trivial assertion, I am going to have _no idea_ where the constraint was violated.
[Bug c/85182] _Static_assert is less than useful in a static inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85182 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- Invalid as explained. There is some GCC extensions to support what you want to do.
[Bug tree-optimization/85156] [8 Regression] ICE with -O1 -g: gimplification failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85156 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug rtl-optimization/85167] [6/7 Regression] shrink-wrap.c:333:15: runtime error with UBSAN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85167 Jakub Jelinek changed: What|Removed |Added Summary|[6/7/8 Regression] |[6/7 Regression] |shrink-wrap.c:333:15: |shrink-wrap.c:333:15: |runtime error with UBSAN|runtime error with UBSAN --- Comment #4 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug rtl-optimization/85167] [6/7/8 Regression] shrink-wrap.c:333:15: runtime error with UBSAN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85167 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Tue Apr 3 21:45:52 2018 New Revision: 259058 URL: https://gcc.gnu.org/viewcvs?rev=259058&root=gcc&view=rev Log: PR rtl-optimization/85167 * shrink-wrap.c (move_insn_for_shrink_wrap): Don't set bb_uses and bb_defs if *split_p, instead preinitialize it to NULL. * gcc.dg/pr85167.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr85167.c Modified: trunk/gcc/ChangeLog trunk/gcc/shrink-wrap.c trunk/gcc/testsuite/ChangeLog
[Bug c/85182] _Static_assert is less than useful in a static inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85182 --- Comment #1 from joseph at codesourcery dot com --- This is how static assertions are defined in C11, not a bug in GCC: it's a constraint violation if the constant expression compares equal to 0, regardless of the context in which the declaration appears (thus, a constraint violation in a function that is never called, for example).
[Bug tree-optimization/85156] [8 Regression] ICE with -O1 -g: gimplification failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85156 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Tue Apr 3 21:42:51 2018 New Revision: 259057 URL: https://gcc.gnu.org/viewcvs?rev=259057&root=gcc&view=rev Log: PR tree-optimization/85156 * builtins.c (fold_builtin_expect): Use save_expr on arg1 to avoid evaluating the argument multiple times. * c-c++-common/pr85156.c: New test. * gcc.c-torture/execute/pr85156.c: New test. Added: trunk/gcc/testsuite/c-c++-common/pr85156.c trunk/gcc/testsuite/gcc.c-torture/execute/pr85156.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog
[Bug c/85182] New: _Static_assert is less than useful in a static inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85182 Bug ID: 85182 Summary: _Static_assert is less than useful in a static inline Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: ajax at redhat dot com Target Milestone: --- Consider: --- desoxy:~/git/junkdrawer% cat -n static-assert.h 1 static inline void bar(void) 2 { 3 _Static_assert(0, "called bar()"); 4 } desoxy:~/git/junkdrawer% cat -n static-assert.c 1 #include "static-assert.h" 2 void foo(void) { bar(); } desoxy:~/git/junkdrawer% gcc -O2 -c static-assert.c In file included from static-assert.c:1: static-assert.h: In function ‘bar’: static-assert.h:3:5: error: static assertion failed: "called bar()" _Static_assert(0, "called bar()"); ^~ desoxy:~/git/junkdrawer% gcc --version | head -1 gcc (GCC) 8.0.1 20180317 (Red Hat 8.0.1-0.19) --- Note that the report locates the definition, not the call site. Effectively I'm being punished for avoiding the preprocessor, which seems wrong: --- desoxy:~/git/junkdrawer% cat -n static-assert.h 1 #define bar() do { \ 2 _Static_assert(0, "called bar()"); \ 3 } while (0) desoxy:~/git/junkdrawer% gcc -O2 -c static-assert.c In file included from static-assert.c:1: static-assert.c: In function ‘foo’: static-assert.h:2:9: error: static assertion failed: "called bar()" _Static_assert(0, "called bar()"); \ ^~ static-assert.c:2:18: note: in expansion of macro ‘bar’ void foo(void) { bar(); } ^~~ ---
[Bug target/85166] [nvptx, libgfortran] Libgomp fortran tests using stop in offloaded fns fail to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85166 --- Comment #2 from Thomas Koenig --- Does this fix the problem? Index: minimal.c === --- minimal.c (Revision 259055) +++ minimal.c (Arbeitskopie) @@ -187,3 +187,17 @@ sys_abort (void) abort(); } + +/* A numeric STOP statement. */ + +extern _Noreturn void stop_numeric (int, bool); +export_proto(stop_numeric); + +void +stop_numeric (int code, bool quiet) +{ + if (!quiet) +printf ("STOP %d\n", code); + + exit (code); +}
[Bug c++/85135] [7/8 Regression] ICE with invalid late-specified return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85135 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug target/85166] [nvptx, libgfortran] Libgomp fortran tests using stop in offloaded fns fail to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85166 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #1 from Thomas Koenig --- The easiest solution would be to add the symbol to the minmal libgfortran. Is there any reason why this would not work?
[Bug c++/85133] [7/8 Regression] [concepts] ICE with invalid concept used in variadic template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85133 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug middle-end/67486] ira-color.c sanitizer detects signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67486 David Binderman changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #6 from David Binderman --- I wonder if changing type of static array full_costs from int to long would help solve the problem. Adding vmakarov, who seems to be the author of most of this section of code.
[Bug c++/85118] [6/7/8 Regression] Error when using std::bind with a generic lambda - "cannot bind 'const volatile char&' to an rvalue of type 'const volatile char'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85118 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug middle-end/67486] ira-color.c sanitizer detects signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67486 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #5 from David Binderman --- Still seems to be present in gcc trunk revision 259004.
[Bug c++/85141] [6/7/8 Regression] ICE with pointer arithmetic of static member function address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85141 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/85060] [7/8 Regression] Object cannot call its inherited member function "without object"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85060 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jason Merrill --- Fixed.
[Bug c++/85148] [6/7/8 Regression] ICE with NSDMI and this pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85148 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/85113] [7/8 Regression] ICE with __builtin_constant_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85113 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jason Merrill --- Fixed.
[Bug c++/85101] C++17 ICE in build_over_call, at cp/call.c:8149
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85101 Bug 85101 depends on bug 85092, which changed state. Bug 85092 Summary: [8 Regression] ICE under -std=gnu++1z in build_over_call under, at cp/call.c:8149 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85092 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/85113] [7/8 Regression] ICE with __builtin_constant_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85113 --- Comment #3 from Jason Merrill --- Author: jason Date: Tue Apr 3 19:14:03 2018 New Revision: 259053 URL: https://gcc.gnu.org/viewcvs?rev=259053&root=gcc&view=rev Log: PR c++/85113 - ICE with constexpr and __builtin_constant_p. * constexpr.c (cxx_eval_builtin_function_call): Only defer __builtin_constant_p if ctx->quiet. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/ext/builtin12.C Modified: branches/gcc-7-branch/gcc/cp/ChangeLog branches/gcc-7-branch/gcc/cp/constexpr.c
[Bug c++/85092] [8 Regression] ICE under -std=gnu++1z in build_over_call under, at cp/call.c:8149
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85092 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jason Merrill --- Fixed.
[Bug c++/85092] [8 Regression] ICE under -std=gnu++1z in build_over_call under, at cp/call.c:8149
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85092 --- Comment #5 from Jason Merrill --- Author: jason Date: Tue Apr 3 19:13:42 2018 New Revision: 259052 URL: https://gcc.gnu.org/viewcvs?rev=259052&root=gcc&view=rev Log: PR c++/85092 - C++17 ICE with unused list constructor. * call.c (conv_binds_ref_to_prvalue): Also count ck_identity from a TARGET_EXPR. Added: trunk/gcc/testsuite/g++.dg/cpp0x/initlist99.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c
[Bug c++/85113] [7/8 Regression] ICE with __builtin_constant_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85113 --- Comment #2 from Jason Merrill --- Author: jason Date: Tue Apr 3 19:13:36 2018 New Revision: 259051 URL: https://gcc.gnu.org/viewcvs?rev=259051&root=gcc&view=rev Log: PR c++/85113 - ICE with constexpr and __builtin_constant_p. * constexpr.c (cxx_eval_builtin_function_call): Only defer __builtin_constant_p if ctx->quiet. Added: trunk/gcc/testsuite/g++.dg/ext/builtin12.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c
[Bug c++/85092] [8 Regression] ICE under -std=gnu++1z in build_over_call under, at cp/call.c:8149
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85092 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug tree-optimization/85175] [8 regression] false-positive -Wformat-overflow= warning with gcc-8 -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85175 --- Comment #3 from Arnd Bergmann --- (In reply to Martin Sebor from comment #2) > So with the change above GCC is doing a better but imperfect job of > determining the range. Changing the variable to unsigned constrains the > lower bound to zero and eliminates the warning even at -Os. Ok, so this is actually the same thing I saw with seven other files in the kernel (out of several hundred randconfig kernel builds on three architectures). In each case, we now have a signed integer range that appears to be constrained on one side after r257857, e.g. [-2147483647, 68] or [1, 2147483647] based on a partial range check, but the warning is still a false positive in the end. The one such warning we gained in the kernel that makes sense was this one (not sent yet): commit c18e88d296264d76f1a242ae95a43681cf198078 Author: Arnd Bergmann Date: Tue Apr 3 09:45:35 2018 +0200 bluetooth: fix hci name overflow gcc-8 warns that the index of the hci device could overflow the eight character array: net/bluetooth/hci_core.c: In function 'hci_register_dev': net/bluetooth/hci_core.c:3093:26: error: '%d' directive writing between 1 and 10 bytes into a region of size 5 [-Werror=format-overflow=] sprintf(hdev->name, "hci%d", id); ^~ net/bluetooth/hci_core.c:3093:22: note: directive argument in the range [0, 2147483647] sprintf(hdev->name, "hci%d", id); ^~~ net/bluetooth/hci_core.c:3093:2: note: 'sprintf' output between 5 and 14 bytes into a destination of size 8 sprintf(hdev->name, "hci%d", id); This uses snprintf() to enforce a valid string, and limits the range of the integer to 0... In practice this should not matter as we would not be able connect more than bluetooth hci's simultaneously. Signed-off-by: Arnd Bergmann diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c index 40d260f2bea5..9e2ad444d799 100644 --- a/net/bluetooth/hci_core.c +++ b/net/bluetooth/hci_core.c @@ -3075,13 +3075,14 @@ int hci_register_dev(struct hci_dev *hdev) /* Do not allow HCI_AMP devices to register at index 0, * so the index can be used as the AMP controller ID. +* Ensure the name fits into eight characters id < 1. */ switch (hdev->dev_type) { case HCI_PRIMARY: - id = ida_simple_get(&hci_index_ida, 0, 0, GFP_KERNEL); + id = ida_simple_get(&hci_index_ida, 0, 1, GFP_KERNEL); break; case HCI_AMP: - id = ida_simple_get(&hci_index_ida, 1, 0, GFP_KERNEL); + id = ida_simple_get(&hci_index_ida, 1, 1, GFP_KERNEL); break; default: return -EINVAL; @@ -3090,7 +3091,7 @@ int hci_register_dev(struct hci_dev *hdev) if (id < 0) return id; - sprintf(hdev->name, "hci%d", id); + snprintf(hdev->name, sizeof(hdev->name), "hci%d", id); hdev->id = id; BT_DBG("%p name %s bus %d", hdev, hdev->name, hdev->bus); The other new warnings are either the same kind as this one (the compiler should be able to figure it out), or the sort where the compiler is technically right about the string overflow based on the types, but we can easily prove that the range is more limited like in the ida_simple_get() case with correct limits (this is an extern function that returns an unused number within a strict range). Would it be sensible to only warn with -Wformat-overflow=1 on a signed integer if the overflow happens with an actual known limit, but not if the limit is euqal to the minimum/maximum representable numbers? The documentation for -Wformat-overflow=2 isn't completely clear on what behavior was intended here for the =1 and =2 case if the range is only bounded on one side.
[Bug c++/85118] [6/7/8 Regression] Error when using std::bind with a generic lambda - "cannot bind 'const volatile char&' to an rvalue of type 'const volatile char'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85118 --- Comment #6 from Jonathan Wakely --- ... and it's only a substitution failure anyway, not an error.
[Bug c++/85092] [8 Regression] ICE under -std=gnu++1z in build_over_call under, at cp/call.c:8149
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85092 --- Comment #4 from Jason Merrill --- *** Bug 85101 has been marked as a duplicate of this bug. ***
[Bug c++/85101] C++17 ICE in build_over_call, at cp/call.c:8149
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85101 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Jason Merrill --- Yes, dup. *** This bug has been marked as a duplicate of bug 85092 ***
[Bug c++/85101] C++17 ICE in build_over_call, at cp/call.c:8149
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85101 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug target/83402] PPC64 implementation of ./rs6000/emmintrin.h gives out of range for _mm_slli_epi32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83402 --- Comment #5 from Steven Munroe --- You need to look at the generated asm code. And see what the compiler is doing. Basically it should be generating a vspltisw vr,si for vec_splat_s32. But if the immediate signed int (si) is greater than 15, should failure with: error: argument 1 must be a 5-bit signed literal The vec_splats should work for any value as it will load a const vector from storage. Perhaps the compiler is generating bad code and not reporting it. Or the compiler is too smart and converting the vec_splat_s32 to the more general vec_splats under the covers. Look at the source Paul!
[Bug c++/84768] [7 Regression] ICE with failed class template argument deduction because of invalid template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84768 Paolo Carlini changed: What|Removed |Added Summary|[7/8 Regression] ICE with |[7 Regression] ICE with |failed class template |failed class template |argument deduction because |argument deduction because |of invalid template |of invalid template |parameter |parameter --- Comment #5 from Paolo Carlini --- Fixed in trunk.
[Bug c++/85118] [6/7/8 Regression] Error when using std::bind with a generic lambda - "cannot bind 'const volatile char&' to an rvalue of type 'const volatile char'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85118 Jonathan Wakely changed: What|Removed |Added Known to fail||6.4.0, 7.3.0, 8.0.1 --- Comment #5 from Jonathan Wakely --- GCC 5, Clang and EDG all compile it. GCC 6 onwards fail with: 85118.C: In instantiation of 'main():: [with auto:1 = {volatile char}]': 85118.C:114:51: required by substitution of 'template main()operator decltype (((const main()::*)((const main()::* const)0u))->operator()(static_cast(main::__lambda0::_FUN::) ...)) (*)(auto:1&& ...)() const [with auto:1 = {volatile char}]' 85118.C:79:56: required by substitution of 'template _Result std::_Bind<_Functor, _Bound_args>::operator()(_Args&&) volatile [with _Args = char; _Result = ]' 85118.C:121:12: required from here 85118.C:116:23: error: no matching function for call to 'isOneOf(volatile char)' return isOneOf(std::forward(params)...); ~~~^~~ 85118.C:101:6: note: candidate: bool isOneOf(const T&) [with T = volatile char] bool isOneOf(const T& ) ^~~ 85118.C:101:6: note: conversion of argument 1 would be ill-formed: 85118.C:116:23: error: invalid initialization of non-const reference of type 'const volatile char&' from an rvalue of type 'volatile char' return isOneOf(std::forward(params)...); ~~~^~~ 85118.C:107:6: note: candidate: template bool isOneOf(const T&, const FirstType&, const Tail& ...) bool isOneOf(const T& t, const FirstType& firstValue, const Tail&... tail) ^~~ 85118.C:107:6: note: template argument deduction/substitution failed: 85118.C:116:23: note: candidate expects at least 2 arguments, 1 provided return isOneOf(std::forward(params)...); ~~~^~~ 85118.C:76:10: warning: '_Result std::_Bind<_Functor, _Bound_args>::operator()(_Args&&) [with _Args = char; _Result = bool; _Functor = const main()::; _Bound_args = char]' used but never defined operator()(_Args&& __args); ^~~~ The error says "invalid initialization of non-const reference of type 'const volatile char&' from an rvalue of type 'volatile char'" which is bogus, because const volatile char& is not a non-const reference.
[Bug c++/85113] [7/8 Regression] ICE with __builtin_constant_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85113 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/84768] [7/8 Regression] ICE with failed class template argument deduction because of invalid template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84768 --- Comment #4 from paolo at gcc dot gnu.org --- Author: paolo Date: Tue Apr 3 17:53:05 2018 New Revision: 259049 URL: https://gcc.gnu.org/viewcvs?rev=259049&root=gcc&view=rev Log: /cp 2018-04-03 Paolo Carlini PR c++/84768 * pt.c (rewrite_template_parm): If the first argument is error_mark_node return it immediately. (build_deduction_guide): Check the return value of the latter for error_mark_node. (do_class_deduction): Check the return value of the latter. /testsuite 2018-04-03 Paolo Carlini PR c++/84768 * g++.dg/cpp1z/class-deduction52.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp1z/class-deduction52.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/85118] [6/7/8 Regression] Error when using std::bind with a generic lambda - "cannot bind 'const volatile char&' to an rvalue of type 'const volatile char'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85118 Jonathan Wakely changed: What|Removed |Added Attachment #43794|0 |1 is obsolete|| --- Comment #4 from Jonathan Wakely --- Created attachment 43831 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43831&action=edit reduced testcase
[Bug target/85181] New: Loading wrong source/dest registers for xviexpdp instruction with -O2 optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85181 Bug ID: 85181 Summary: Loading wrong source/dest registers for xviexpdp instruction with -O2 optimization Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: carll at gcc dot gnu.org Target Milestone: --- Created attachment 43830 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43830&action=edit test case for xviexpdp instruction With -O2 optimization, we load the data into the wrong VR registers. With -O0 we load and use the same VSR registers. The results of the test case is wrong with -O2 optimization but the correct expected result was obtained with -O0. The compiler used is GCC 8 mainline Revision: 258857 The attached test code was extracted from the Valgrind test_isa_3_0.c. When the test code was compiled on 4/2/2018 on a Power 9 system with the mainline GCC 8.0, Revision: 258857 with optimization -O0 I got the code: gcc -g -O0 -o test_xviexpdp test_xviexpdp.c objdump -S -d test_xviexpdp > test_xviexpdp.dump I get the following generated code. 15d4: 50 81 22 39 addir9,r2,-32432 15d8: 98 4e 00 7c lxvd2x vs0,0,r9 15dc: 50 02 80 f1 xxswapd vs12,vs0 15e0: 00 00 00 60 nop 15e4: 60 81 22 39 addir9,r2,-32416 15e8: 98 4e 00 7c lxvd2x vs0,0,r9 15ec: 50 02 60 f1 xxswapd vs11,vs0 15f0: 00 00 00 60 nop 15f4: 80 81 22 39 addir9,r2,-32384 15f8: 98 4e 00 7c lxvd2x vs0,0,r9 15fc: 50 02 00 f0 xxswapd vs0,vs0 1600: c0 5f 0c f0 xviexpdp vs0,vs12,vs11 The results of running the code was correct. The data was loaded into vs12 and vs11 and these are the registers used in the xviexpdp instruction. I verified in gdb that vs12 and vs11 have the expected values and vs0 is correct after the instruction. With -O2 we have 14f8: ce e8 1f 7c lvx v0,r31,r29 14fc: ce f8 a0 7d lvx v13,0,r31 1500: ce f0 3f 7c lvx v1,r31,r30 1504: c0 0f 0d f0 xviexpdp vs0,vs13,vs1 Note, we are loading v13 and v1, then use vs13 and vs1. I verified that v13 and v1 have the correct values. So, we appear to be loading the wrong register set. Not sure why the optimized code loads the wrong registers. I don't see any issues with the inline assembly. Note, same compiler compiled the next day, on 4/3/2018, on the same machine with -O0 I get slightly different unoptimized code that doesn't work. What changed overnight I don't know but it is really annoying I can't exactly reproduce things. 15d0: 00 00 00 60 nop 15d4: 50 81 22 39 addir9,r2,-32432 15d8: 98 4e 00 7c lxvd2x vs0,0,r9 15dc: 51 02 20 f0 xxswapd vs33,vs0Now using vs33 not vs12 15e0: 00 00 00 60 nop 15e4: 60 81 22 39 addir9,r2,-32416 15e8: 98 4e 00 7c lxvd2x vs0,0,r9 15ec: 51 02 a0 f1 xxswapd vs45,vs0Now using vs45 not vs11 15f0: 00 00 00 60 nop 15f4: 80 81 22 39 addir9,r2,-32384 15f8: 98 4e 00 7c lxvd2x vs0,0,r9 15fc: 50 02 00 f0 xxswapd vs0,vs0 1600: 91 04 00 f0 xxlor vs32,vs0,vs0Now using vs32 not vs0 1604: c0 6f 01 f0 xviexpdp vs0,vs1,vs13 Note, we load VS register indexes that are 32 more then what is used in the xviexpdp instruction. I get all zeros for the result today, that is not the correct result. Don't know why things are compiling differently today, but the test case result is wrong. The test does generate the same wrong code when compiled with -O2 as it did yesterday. NOTE, this may not be the only instruction where this issue is occurring. Still investigating.
[Bug c++/85149] [8 Regression] False branch of if constexpr instantiated in generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85149 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jason Merrill --- Fixed.
[Bug c++/64095] [C++14] Ellipsis at end of generic lambda parameter-declaration-clause should be parsed as a parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64095 --- Comment #10 from Jason Merrill --- Author: jason Date: Tue Apr 3 17:46:35 2018 New Revision: 259047 URL: https://gcc.gnu.org/viewcvs?rev=259047&root=gcc&view=rev Log: PR c++/64095 - auto... parameter pack. * parser.c (cp_parser_parameter_declaration): Handle turning autos into packs here. (cp_parser_parameter_declaration_list): Not here. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic16.C Modified: branches/gcc-7-branch/gcc/cp/ChangeLog branches/gcc-7-branch/gcc/cp/parser.c branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp1y/lambda-mangle-1.C
[Bug c++/85060] [7/8 Regression] Object cannot call its inherited member function "without object"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85060 --- Comment #6 from Jason Merrill --- Author: jason Date: Tue Apr 3 17:46:30 2018 New Revision: 259046 URL: https://gcc.gnu.org/viewcvs?rev=259046&root=gcc&view=rev Log: PR c++/85060 - wrong-code with call to base member in template. * search.c (any_dependent_bases_p): Check uses_template_parms rather than processing_template_decl. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/template/dependent-base3.C Modified: branches/gcc-7-branch/gcc/cp/ChangeLog branches/gcc-7-branch/gcc/cp/search.c
[Bug c++/85149] [8 Regression] False branch of if constexpr instantiated in generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85149 --- Comment #2 from Jason Merrill --- Author: jason Date: Tue Apr 3 17:41:12 2018 New Revision: 259043 URL: https://gcc.gnu.org/viewcvs?rev=259043&root=gcc&view=rev Log: PR c++/85149 - generic lambda and constexpr if. * pt.c (build_extra_args, add_extra_args): Split from tsubst_pack_expansion. (tsubst_expr) [IF_STMT]: Use them. * cp-tree.h (IF_STMT_EXTRA_ARGS): New. Added: trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-if17.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c
[Bug tree-optimization/85175] [8 regression] false-positive -Wformat-overflow= warning with gcc-8 -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85175 --- Comment #2 from Martin Sebor --- The warning appeared with r257857: r257857 | law | 2018-02-20 13:59:22 -0500 (Tue, 20 Feb 2018) | 8 lines PR middle-end/82123 PR tree-optimization/81592 PR middle-end/79257 * gimple-ssa-sprintf.c (format_integer): Query EVRP range analyzer for range data rather than using global data. The difference in the dump between the revision prior to it and r257857 is: Directive 2 at offset 2: "%d" Result: 1, 1, 11, 11 (3, 3, 13, 13) and Directive 2 at offset 2: "%d" Result: 1, 11, 11, 11 (3, 13, 13, 13) I.e., GCC now thinks the likely output of the %d directive is 11 bytes (the second number on the Result: line). Prior to r257857 the range type of the argument was VR_VARYING for which the warning doesn't trigger. With r257857 the range is [-2147483647, 3] of which the warning uses the larger bound to trigger. So with the change above GCC is doing a better but imperfect job of determining the range. Changing the variable to unsigned constrains the lower bound to zero and eliminates the warning even at -Os.
[Bug c++/85140] [6/7 Regression] ICE with invalid use of alignas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85140 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Summary|[6/7/8 Regression] ICE with |[6/7 Regression] ICE with |invalid use of alignas |invalid use of alignas --- Comment #4 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug c++/85147] [6/7 Regression] ICE with invalid variadic template-template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85147 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Summary|[6/7/8 Regression] ICE with |[6/7 Regression] ICE with |invalid variadic|invalid variadic |template-template parameter |template-template parameter --- Comment #4 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug c++/85134] [8 Regression] ICE with invalid constexpr in 'shared' OpenMP clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85134 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug driver/85165] gcc (and g++) not complaining about few unknown file extensions like *.CC, *.Cc, *.cC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85165 --- Comment #1 from Andrew Pinski --- I suspect this is a difference between windows and linux and due to case insensitivity rather than a difference in newer versions of GCC.
[Bug other/85161] [8 regression] Test case failures in libbacktrace on powerpc64 BE starting with r253456
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85161 Bill Seurer changed: What|Removed |Added CC||seurer at linux dot vnet.ibm.com --- Comment #2 from Bill Seurer --- I tried that patch and it looks like it works. All those failures I saw are gone and no new ones.
[Bug gcov-profile/85179] [GCOV] A label followed with a blank statement is wrongly marked as not executed in Gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85179 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug gcov-profile/85178] [GCOV] for(;;) statement is wrongly marked as not executed when there is a int array in its body in Gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85178 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug c++/85147] [6/7/8 Regression] ICE with invalid variadic template-template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85147 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Tue Apr 3 16:22:05 2018 New Revision: 259040 URL: https://gcc.gnu.org/viewcvs?rev=259040&root=gcc&view=rev Log: PR c++/85147 * pt.c (fixed_parameter_pack_p_1): Punt if parm is error_mark_node. * g++.dg/cpp0x/pr85147.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr85147.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug gcov-profile/83678] [GCOV] a pointer assignment before a break statment lead to incorrect coverage in gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83678 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-04-03 Target Milestone|--- |9.0 Ever confirmed|0 |1
[Bug gcov-profile/85178] [GCOV] for(;;) statement is wrongly marked as not executed when there is a int array in its body in Gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85178 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-03 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1
[Bug gcov-profile/85179] [GCOV] A label followed with a blank statement is wrongly marked as not executed in Gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85179 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-03 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1
[Bug c++/85140] [6/7/8 Regression] ICE with invalid use of alignas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85140 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Tue Apr 3 16:21:02 2018 New Revision: 259039 URL: https://gcc.gnu.org/viewcvs?rev=259039&root=gcc&view=rev Log: PR c++/85140 * name-lookup.c (handle_namespace_attrs): Return early if attributes is error_mark_node. * g++.dg/cpp0x/gen-attrs-64.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/gen-attrs-64.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/testsuite/ChangeLog
[Bug target/83402] PPC64 implementation of ./rs6000/emmintrin.h gives out of range for _mm_slli_epi32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83402 --- Comment #4 from Paul Clarke --- Created attachment 43829 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43829&action=edit unhelpful testcase $ gcc --version gcc (GCC) 8.0.1 20180402 (experimental) Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ gcc -o 83402 83402.c -DNO_WARN_X86_INTRINSICS -Wall -O3 -mcpu=power8 $ gcc -o 83402 83402.c -DNO_WARN_X86_INTRINSICS -Wall -mcpu=power8 $
[Bug c++/85134] [8 Regression] ICE with invalid constexpr in 'shared' OpenMP clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85134 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Tue Apr 3 16:20:02 2018 New Revision: 259038 URL: https://gcc.gnu.org/viewcvs?rev=259038&root=gcc&view=rev Log: PR c++/85134 * decl.c (cp_finish_decl): If ensure_literal_type_for_constexpr_object fails, after clearing DECL_DECLARED_CONSTEXPR_P don't return early, instead for static data members clear init and set DECL_EXTERNAL. * g++.dg/gomp/pr85134.C: New test. * g++.dg/cpp0x/constexpr-ice19.C: Expect one further error. Added: trunk/gcc/testsuite/g++.dg/gomp/pr85134.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-ice19.C
[Bug target/83402] PPC64 implementation of ./rs6000/emmintrin.h gives out of range for _mm_slli_epi32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83402 --- Comment #3 from Paul Clarke --- (In reply to Steven Munroe from comment #0) > The rs6000/emmintrin.h implementation of _mm_slli_epi32 reports: > error: argument 1 must be a 5-bit signed literal > > For constant shift values > 15. I thought this would be trivial to reproduce, but not able to provoke it. Do you have a testcase? I will attach the one I tried.
[Bug target/85169] [8 Regression] wrong code with vector member insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85169 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug fortran/79854] diagnostics: gfc_conv_constant_to_tree should be gfc_internal_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79854 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #5 from Thomas Koenig --- (In reply to Dominique d'Humieres from comment #4) > Would not it be better to use > > gcc_unreachable (); > > as it is done in numerous places? Sounds like a good idea to me. Dominique, do you want to prepare a patch along these lines?
[Bug middle-end/84514] powerpc sub optimal condition register reuse with extended inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84514 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-03 Component|target |middle-end Ever confirmed|0 |1
[Bug target/85169] [8 Regression] wrong code with vector member insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85169 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Tue Apr 3 16:06:19 2018 New Revision: 259037 URL: https://gcc.gnu.org/viewcvs?rev=259037&root=gcc&view=rev Log: PR target/85169 * config/i386/i386.c (ix86_expand_vector_set): Use HOST_WIDE_INT_1U << elt instead of 1 << elt. Formatting fix. * gcc.c-torture/execute/pr85169.c: New test. * gcc.target/i386/avx512f-pr85169.c: New test. * gcc.target/i386/avx512bw-pr85169.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr85169.c trunk/gcc/testsuite/gcc.target/i386/avx512bw-pr85169.c trunk/gcc/testsuite/gcc.target/i386/avx512f-pr85169.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/85180] New: Infinite (?) loop in RTL DSE optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180 Bug ID: 85180 Summary: Infinite (?) loop in RTL DSE optimizer Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: uweigand at gcc dot gnu.org CC: krebbel at gcc dot gnu.org Target Milestone: --- Target: s390x-ibm-linux Created attachment 43828 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43828&action=edit Test case - run with "cc1plus -O" When attempting to compile the attached testcase simply with "cc1plus -O" on a s390x-ibm-linux target, the compilation process never terminates. The problem appear to originate in the dse.c pass; building with -fno-dse makes the problem go away. I'm not completely sure that this is really an infinite loop, strictly speaking, or just some exponential time behavior somewhere. In any case, at the time the compiler hangs, it sits in a long chain of find_base_term calls ultimately originating at the canon_output_dependence in dse.c:1593 (record_store).
[Bug c++/85118] [6/7/8 Regression] Error when using std::bind with a generic lambda - "cannot bind 'const volatile char&' to an rvalue of type 'const volatile char'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85118 --- Comment #3 from Jonathan Wakely --- Started to be rejected with r233719 PR c++/69842 * method.c (forward_parm): Handle parameter packs. * lambda.c (maybe_add_lambda_conv_op): Use it for them. Still reducing it.
[Bug target/85126] [8 regression] gcc.target/powerpc/pr69946.c fails on powerpc64 BE starting with r254213
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85126 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||segher at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Segher Boessenkool --- Fixed.
[Bug target/85126] [8 regression] gcc.target/powerpc/pr69946.c fails on powerpc64 BE starting with r254213
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85126 --- Comment #1 from Segher Boessenkool --- Author: segher Date: Tue Apr 3 15:38:43 2018 New Revision: 259036 URL: https://gcc.gnu.org/viewcvs?rev=259036&root=gcc&view=rev Log: rs6000: Fix pr69946.c testcase (PR85126) After middle-end changes combine now gets fed different input, from which it makes different (but just as efficient) code. So remove the test for particular asm output. gcc/testsuite/ PR target/85126 * gcc.target/powerpc/pr69946: Adjust comment. Remove scan-assembler-times clause. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/powerpc/pr69946.c
[Bug libgcc/84292] __sync_add_and_fetch returns the old value instead of the new value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84292 --- Comment #4 from Maryse LEVAVASSEUR --- Hi Andreas, No problem for the delay, thanks for all !
[Bug target/85177] [8 Regression] wrong code with -O -fno-tree-ccp -fno-tree-sra -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85177 --- Comment #1 from Jakub Jelinek --- Created attachment 43827 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43827&action=edit gcc8-pr85177.patch Untested fix.
[Bug gcov-profile/85179] New: [GCOV] A label followed with a blank statement is wrongly marked as not executed in Gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85179 Bug ID: 85179 Summary: [GCOV] A label followed with a blank statement is wrongly marked as not executed in Gcov Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: yangyibiao at nju dot edu.cn CC: marxin at gcc dot gnu.org Target Milestone: --- $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 8-20170923-1ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,c++,go,brig,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --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 --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 --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 8.0.0 20170923 (experimental) [trunk revision 253118] (Ubuntu 8-20170923-1ubuntu2) $ cat small.c int a = 1; void main() { if (a) goto b; b:; } $ gcc -w --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov File 'small.c' Lines executed:80.00% of 5 Creating 'small.c.gcov' -:0:Source:small.c -:0:Graph:small.gcno -:0:Data:small.gcda -:0:Runs:1 -:0:Programs:1 -:1:int a = 1; 1:2:void main() { 1:3: if (a) 1:4:goto b; #:5:b:; 1:6:} Line #5 is wrongly marked as not executed.
[Bug c/39170] provide an option to silence -Wconversion warnings for bit-fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39170 Eric Gallager changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #19 from Eric Gallager --- (In reply to Manuel López-Ibáñez from comment #11) > (In reply to comment #10) > > However, with so many lines of legacy code out there using bit-filed that > > have > > been proven to work, it doesn't make sense to revisit/modify them. Would it > > be possible for gcc to provide a -Wbitfield-conversion flag in new releases > > and make 39170 an enhancement (preferably high priority)? > > Seriously, I am not the "maintainer" of GCC diagnostics That's David Malcolm; adding him on cc
[Bug gcov-profile/85178] New: [GCOV] for(;;) statement is wrongly marked as not executed when there is a int array in its body in Gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85178 Bug ID: 85178 Summary: [GCOV] for(;;) statement is wrongly marked as not executed when there is a int array in its body in Gcov Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: yangyibiao at nju dot edu.cn CC: marxin at gcc dot gnu.org Target Milestone: --- $ gcc -v gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 8-20170923-1ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,c++,go,brig,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --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 --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 --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 8.0.0 20170923 (experimental) [trunk revision 253118] (Ubuntu 8-20170923-1ubuntu2) $ cat small.c int a = 0; int b() { for (;;) { int c[1]; for (; 0;) return 0; for (; a <= 1;) return 0; } } void main() { b(); } $ gcc -w --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov File 'small.c' Lines executed:85.71% of 7 Creating 'small.c.gcov' -:0:Source:small.c -:0:Graph:small.gcno -:0:Data:small.gcda -:0:Runs:1 -:0:Programs:1 -:1:int a = 0; 1:2:int b() { #:3: for (;;) { -:4:int c[1]; 1:5:for (; 0;) 1:6: return 0; 1:7:for (; a <= 1;) 1:8: return 0; -:9: } -: 10:} 1: 11:void main() { b(); } Two marks are incorrect. Line #3 is wrongly marked as not executed and Line #6 is wrongly marked as executed. While Line #4 is removed, the result is correct.
[Bug middle-end/85139] [8 Regression] Spurious format truncation warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85139 --- Comment #2 from Martin Sebor --- To avoid the warning, cast the argument of the %04X directive to unsigned short: snprintf(s, sizeof(s), "usb:v%04Xp%04X*", (unsigned short)vn, (unsigned short)pn); (Note that even though casting an int to signed short will most likely work, it isn't strictly correct.)
[Bug debug/85176] ICE in force_decl_die, at dwarf2out.c:25910
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85176 v_lichevsky at tut dot by changed: What|Removed |Added Summary|ICE in force_decl_die, at |ICE in force_decl_die, at |dwarf2out.c:25922 |dwarf2out.c:25910 --- Comment #1 from v_lichevsky at tut dot by --- Reproduced this bug with gcc built from upstream sources, same revision as Debian package (r259004) and adjusted line number in the title: % ./pr85176/bin/x86_64-linux-gnu-g++-8 -O1 -flto -g1 test.cpp lto1: internal compiler error: in force_decl_die, at dwarf2out.c:25910 0x6d4f23 force_decl_die ../.././gcc/dwarf2out.c:25910 0x6d59ab flush_limbo_die_list ../.././gcc/dwarf2out.c:30951 0x6e0f55 dwarf2out_finish ../.././gcc/dwarf2out.c:30991
[Bug c++/85128] Local scope type(def) falsely assumed to change meaning of outer scope type(def)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85128 --- Comment #12 from Steffen Nurpmeso --- Or you could compile with -std=c++98 Yes, thanks for the opportunity. I would rather not, the fix was simple and only affected this class and its specializations (of 383, 315 public interface). > (we had override, as a macro that expanded to virtual) Yuck. But still thinking that is better than what has been standardized, since the "const" suffix (i call it that way..) has to be given at the definition or you have an error, doing the same for the other one is an error by itself! #?0[steffen@essex tmp]$ cat t.cc #include class A{ char const *m_cp; public: A(void):m_cp(NULL){} virtual ~A(void){} virtual char const *msg(void) const {return m_cp;} }; class B : A{ public: char const *msg(void) const override; }; char const *B::msg(void) const override {return "why-o-why";} int main(void){ A o1; B o2; printf("o1=%s o2=%s\n", o1.msg(), o2.msg()); return 0; } #?0[steffen@essex tmp]$ g++ -W -Wall -pedantic -o zt t.cc t.cc:13:32: error: virt-specifiers in 'msg' not allowed outside a class definition char const *B::msg(void) const override {return "why-o-why";} ^~~~ Really, really yuck. Imho. Being explicit and not using tags or fully blown IDEs seems obsolete it seems, i for one like documentation free sources and then _pub _ove TextWriter::~TextWriter(void){.. says this is public and overrides a virtual at glance. Changes more for the humans than the machines i would appreciate more. (All imho, of course.) Ciao. Sorry for the noise, anyway, bug was on my side.
[Bug rtl-optimization/80791] [8 regression] test case gcc.dg/sms-1.c fail2 starting with r247885
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80791 --- Comment #18 from Bill Schmidt --- In the before case, it appears that later optimization is able to remove the i_12 add by adjusting the loop counter. After ivopts: i_12 = i_5 + 4; ivtmp.10_17 = ivtmp.10_18 + 32; Before SMS: r174 = (SI)r164 + 32 r164 = zext(r174) So in effect we have added the shift into the loop to remove an add that we are able to later remove anyway. The two adds are related but the add and the shift are not.
[Bug rtl-optimization/80791] [8 regression] test case gcc.dg/sms-1.c fail2 starting with r247885
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80791 --- Comment #17 from Bill Schmidt --- Sure. My point is that the modeling that's being done doesn't accurately predict the actual loop performance. What we need to do is figure out why.
[Bug gcov-profile/83678] [GCOV] a pointer assignment before a break statment lead to incorrect coverage in gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83678 --- Comment #1 from Yibiao Yang --- simpler reproducer: void main() { while (1) { int a; &a; if (0) break; if (1) break; } } $ gcc-8 small.c -fprofile-arcs -ftest-coverage; ./a.out gcov-8 small.c; cat small.c.gcov -:0:Source:small.c -:0:Graph:small.gcno -:0:Data:small.gcda -:0:Runs:1 -:0:Programs:1 1:1:void main() { -:2: while (1) { -:3:int a; -:4:&a; -:5:if (0) 1:6: break; -:7:if (1) 1:8: break; -:9: } 1: 10:} Line #6 is wrongly marked as executed.
[Bug rtl-optimization/80791] [8 regression] test case gcc.dg/sms-1.c fail2 starting with r247885
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80791 --- Comment #16 from amker at gcc dot gnu.org --- (In reply to Bill Schmidt from comment #15) > It's a bit shift, but the result is still that it is now in the loop instead > of outside the loop, and the total cost of the loop has increased. But the addition for "ivtmp.10_17 = ivtmp.10_18 + 32;" is now removed?