[Bug bootstrap/70650] [6 regression] bootstrap failure: ICE in emit_move_insn, at expr.c:3546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70650 --- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #17 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> --- [...] > Just for the record, with your patch a sparc-sun-solaris2.12 bootstrap > is well into stage2, so the immediate failure is gone. Will be a couple > more hours before I have testsuite results. Finished now. Results are good with the exception of FAIL: g++.dg/abi/empty13.C -std=gnu++11 execution test FAIL: g++.dg/abi/empty13.C -std=gnu++14 execution test FAIL: g++.dg/abi/empty13.C -std=gnu++98 execution test Rainer
[Bug c++/70494] [5 regression] Internal Compiler Error: Capturing an array of vectors in a lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70494 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 Summary|[5/6 regression] Internal |[5 regression] Internal |Compiler Error: Capturing |Compiler Error: Capturing |an array of vectors in a|an array of vectors in a |lambda |lambda --- Comment #4 from Jason Merrill --- Fixed for GCC 6 for now.
[Bug c++/70494] [5/6 regression] Internal Compiler Error: Capturing an array of vectors in a lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70494 --- Comment #3 from Jason Merrill --- Author: jason Date: Fri Apr 15 04:02:49 2016 New Revision: 235003 URL: https://gcc.gnu.org/viewcvs?rev=235003&root=gcc&view=rev Log: PR c++/70494 * decl.c (cxx_maybe_build_cleanup): Handle non-decls. * typeck2.c (split_nonconstant_init_1): Use it. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-array2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/typeck2.c
[Bug target/70674] [4.9/5/6 regression] S/390: Memory access below stack pointer in epilogue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70674 Andreas Krebbel changed: What|Removed |Added Keywords||wrong-code Target||s390x-ibm-linux Priority|P3 |P1 CC||arnez at linux dot vnet.ibm.com, ||doko at gcc dot gnu.org, ||uweigand at gcc dot gnu.org Host||s390x-ibm-linux Build||s390x-ibm-linux
[Bug target/70674] New: [4.9/5/6 regression] S/390: Memory access below stack pointer in epilogue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70674
Bug ID: 70674
Summary: [4.9/5/6 regression] S/390: Memory access below stack
pointer in epilogue
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
Target Milestone: ---
Created attachment 38276
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38276&action=edit
Fix proposal
t.c:
void foo (void) { volatile int a = 5; (void) a; }
cc1 -O2 -fno-omit-frame-pointer -march=z10 -mtune=z196 t.c
The assignment to a is moved by the scheduler *after* the stack pointer
restore. While not being a problem in this example in other circumstances this
might cause data corruption if e.g. a signal handler gets triggered in between.
foo:
ldgr%f2,%r11
ldgr%f0,%r15
lay %r15,-168(%r15)
lgr %r11,%r15
lgdr%r15,%f0 <- stack pointer restore
mvhi164(%r11),5 <- stack write for variable a
l %r1,164(%r11)
lgdr%r11,%f2
br %r14
The variable access is done through the framepointer which does not conflict
with the restore of r15.
The problem was latent in the backend but was so far hidden by doing the
restore of r11 and r15 in the same instruction - a load multiple. However,
there always was the potential problem of doing the stack access with a
temporary register assigned by the compiler.
[Bug c++/70528] [5 Regression] bogus error: constructor required before non-static data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70528 Jason Merrill changed: What|Removed |Added Summary|[5/6 Regression] bogus |[5 Regression] bogus error: |error: constructor required |constructor required before |before non-static data |non-static data member |member | --- Comment #12 from Jason Merrill --- Fixed in 6 for now.
[Bug c++/70528] [5/6 Regression] bogus error: constructor required before non-static data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70528 --- Comment #11 from Jason Merrill --- Author: jason Date: Fri Apr 15 02:23:05 2016 New Revision: 235002 URL: https://gcc.gnu.org/viewcvs?rev=235002&root=gcc&view=rev Log: PR c++/70528 * class.c (type_has_constexpr_default_constructor): Return true for an implicitly declared constructor. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr70528.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-ctor12.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-default-ctor.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-ice6.C trunk/gcc/testsuite/g++.dg/cpp0x/inh-ctor19.C
[Bug target/66033] rs6000 nops removed by rtl_dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66033 --- Comment #5 from Alan Modra --- Comment #4 was added to the wrong bug. Not fixed on gcc-5 branch.
[Bug rtl-optimization/68814] [6 regression] gcc.dg/pr63594-2.c fails since r226005
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68814 Alan Modra changed: What|Removed |Added Status|REOPENED|ASSIGNED CC||amodra at gmail dot com Target Milestone|6.0 |4.9.4
[Bug fortran/70673] ICE with module containing functions with allocatable character scalars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70673 --- Comment #2 from David Kinniburgh --- Ah, maybe I reduced this too far as a1 and a2 are obviously uninitialized... Is this better - it also produces an ICE? module m contains subroutine s(in) character(*), intent(in) :: in character(:), allocatable :: a a = in a = a return contains integer function f1() f1 = 0 end function f1 end subroutine s integer function f2(a) character(*), intent(in) :: a character(:), allocatable :: in in = a in = in f2 = 0 end function f2 end module m
[Bug rtl-optimization/68814] [6 regression] gcc.dg/pr63594-2.c fails since r226005
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68814 Segher Boessenkool changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #5 from Segher Boessenkool --- PR70672 has a testcase that fails without the big rotate/shift patch. The BITS_BIG_ENDIAN patch needs backporting.
[Bug target/70672] [5] Wrong code for little endian bitfield modification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70672 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Segher Boessenkool --- This is a dup of 68814, which wasn't backported yet. *** This bug has been marked as a duplicate of bug 68814 ***
[Bug rtl-optimization/68814] [6 regression] gcc.dg/pr63594-2.c fails since r226005
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68814 --- Comment #4 from Segher Boessenkool --- *** Bug 70672 has been marked as a duplicate of this bug. ***
[Bug fortran/70673] ICE with module containing functions with allocatable character scalars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70673 --- Comment #1 from David Kinniburgh --- Ah, maybe I reduced this too far as a1 and a2 are obviously uninitialized, but still...
[Bug fortran/70673] New: ICE with module containing functions with allocatable character scalars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70673 Bug ID: 70673 Summary: ICE with module containing functions with allocatable character scalars Product: gcc Version: fortran-dev Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: davidgkinniburgh at yahoo dot co.uk Target Milestone: --- module m contains subroutine s character(:), allocatable :: a1 a1 = a1 return contains integer function f1() f1 = 0 end function f1 end subroutine s integer function f2() character(:), allocatable :: a2 f2 = 0 ! this line causes a seg fault! a2 = a2 end function f2 end module m # The above do-nothing construction gives an ICE. Difficult for me to know why but it is probably something to do with the allocatable character scalars. As far as I know, it is legal Fortran. P.S. Thanks Paul, Dominique et al. for the recent push on the these things. gcc version 6.0.0 20160410 (experimental) (GCC) :: mingw build from equation.com running on x86_w64.
[Bug target/70669] PowerPC __float128 does not support direct move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70669 Michael Meissner changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Michael Meissner --- Fixed in subversion id 234995.
[Bug target/70669] PowerPC __float128 does not support direct move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70669 --- Comment #2 from Michael Meissner --- Author: meissner Date: Thu Apr 14 23:21:30 2016 New Revision: 234995 URL: https://gcc.gnu.org/viewcvs?rev=234995&root=gcc&view=rev Log: [gcc] 2016-04-14 Michael Meissner PR target/70669 * config/rs6000/rs6000.c (rs6000_init_hard_regno_mode_ok): Add direct move handlers for KFmode. Change TFmode handlers test from FLOAT128_IEEE_P to FLOAT128_VECTOR_P. [gcc/testsuite] 2016-04-14 Michael Meissner PR target/70669 * gcc.target/powerpc/pr70669.c: New test. Added: trunk/gcc/testsuite/gcc.target/powerpc/pr70669.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/testsuite/ChangeLog
[Bug target/70669] PowerPC __float128 does not support direct move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70669 --- Comment #3 from Michael Meissner --- Fixed in subversion id 234995.
[Bug libstdc++/70360] --enable-vtable-verify
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70360 ctice at gcc dot gnu.org changed: What|Removed |Added CC||ctice at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ctice at gcc dot gnu.org --- Comment #5 from ctice at gcc dot gnu.org --- On initial investigation it seems to be a problem that some things are being built with -fpie but the linker, when making libraries, wants them to be compiled -fPIC. I'll post more later as I figure it out.
[Bug target/70672] [5] Wrong code for little endian bitfield modification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70672 Segher Boessenkool changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org --- Comment #2 from Segher Boessenkool --- Yes, and probably prerequisites as well, and it is really way too big for backporting. Investigating; mine.
[Bug target/70669] PowerPC __float128 does not support direct move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70669 --- Comment #1 from Michael Meissner --- Created attachment 38275 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38275&action=edit Proposed patch to fix the problem
[Bug middle-end/61409] [4.9/5/6 regression] -Wmaybe-uninitialized false-positive with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61409 --- Comment #16 from Jeffrey A. Law --- AFAICT tree-ssa-uninit won't look at the predicate associated with an undefined PHI argument and test it against the predicate for the actual use. ie, given this PHI from the testcase: ;; basic block 6, loop depth 0 ;;pred: 9 ;;5 # ptr_1 = PHI We want to look at the control dependent path that leads to the edge (9,5). For this test, that edge is control dependent on bb2: ;; basic block 2, loop depth 0 ;;pred: ENTRY if (i_4(D) != 0) goto ; else goto ; ie, we know that for ptr_1 to take the value ptr_5 that i_4 != 0 must be false. So the guard for the edge (9,5) is NOT i_4 != 0. And in this testcase, the actual use of ptr_1 is guarded by: if (i_4(D) != 0) goto ; else goto ; When i_4 != 0 is true, then we'll get to the use. So the guard for the use is i_4 != 0 Those two guards can never both be true. So there's no way at runtime for the value ptr_5 to flow into ptr_1 and then into the use of ptr_1 in bb7. And AFAICT, tree-ssa-uninit.c doesn't have the code to do that kind of analysis.
[Bug c++/70647] Feature request: warning for self-moving in constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70647
--- Comment #4 from Matt Godbolt ---
Agreed re: cast/FE.
I couldn't quite get your example to fail as the "o" parameter is unusued
(which would be a good clue!
#include // for std::move
struct B {
int a; int b;
B(B &&o)
: a(b),
b(o.a) {}
};
passes just fine though; which is grist for the mill for bug 19808 being fixed
(e.g. https://godbolt.org/g/QHLCQv )
Thanks again!
[Bug c/65083] Can not indirectly call some C11 atomic library functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65083 Chris Quenelle changed: What|Removed |Added CC||chris.quenelle at oracle dot com --- Comment #5 from Chris Quenelle --- How hard would it be for someone to backport this to an earlier gcc release? Could we cherry pick this backwards for a Solaris update if we wanted to, or does it depend on other GCC 6 changes?
[Bug c++/70647] Feature request: warning for self-moving in constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70647
--- Comment #3 from Manuel López-Ibáñez ---
> --- Comment #2 from Matt Godbolt ---
> Thanks Manuel. Interestingly this does elicit a warning:
>
> struct B {
> int a; int b;
> B(B &&o)
> : a(static_cast(a)),
> b(std::move(o.b)) {}
> };
Most probable, the FE removes the cast before reaching this warning, so the
warning does not see an expression. If you cast to something non trivial,
it remains an expression and the warning doesn't try to look inside it.
I wonder what happens if you do a(b), a(a). Does it still warn? My guess
would be yes. If so, it is just checking for equality on both sides, no
attempt to look within expressions nor track initialisation.
[Bug bootstrap/70652] [6 Regression] r234966 causes bootstrap to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70652 --- Comment #7 from Martin Sebor --- Created attachment 38274 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38274&action=edit Patch to replace C++ VLAs with alloca. For future reference, the attached patch gets around the problem by replacing C++ VLAs in libjava with __builtin_alloca(). libjava already uses __builtin_alloca() so the change would be in line with this practice. At the same time, libjava contains C++ throw statements so it seems that it must already link with libsupc++ which provides the required C++ exception support, including the unresolved __cxa_throw_bad_array_length function, so there may be a better solution to the problem than replacing the safer VLAs with the unsafe builtin.
[Bug c++/70528] [5/6 Regression] bogus error: constructor required before non-static data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70528 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-04-14 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/69517] [7 regression] SEGV on a VLA with excess initializer elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69517 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|5.4 |7.0 Summary|[5/6 regression] SEGV on a |[7 regression] SEGV on a |VLA with excess initializer |VLA with excess initializer |elements|elements --- Comment #12 from Jakub Jelinek --- Retargetting at GCC 7.
[Bug c++/16994] [meta-bug] VLA and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16994 Bug 16994 depends on bug 70588, which changed state. Bug 70588 Summary: SIGBUS on a VLA larger than SIZE_MAX / 2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70588 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug c++/70588] SIGBUS on a VLA larger than SIZE_MAX / 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70588 Martin Sebor changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #9 from Martin Sebor --- Reopening since the fix was reverted due to bug 70652.
[Bug c++/70019] VLA size overflow not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70019 Martin Sebor changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #6 from Martin Sebor --- Reopening since the fix was reverted due to bug 70652.
[Bug c++/16994] [meta-bug] VLA and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16994 Bug 16994 depends on bug 70019, which changed state. Bug 70019 Summary: VLA size overflow not detected https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70019 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug c++/69517] [5/6 regression] SEGV on a VLA with excess initializer elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69517 Martin Sebor changed: What|Removed |Added Summary|[5 regression] SEGV on a|[5/6 regression] SEGV on a |VLA with excess initializer |VLA with excess initializer |elements|elements --- Comment #11 from Martin Sebor --- Restoring 6 regression since the fix was reverted due to bug 70652.
[Bug target/70672] [5] Wrong code for little endian bitfield modification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70672 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Note that the patch had at least one follow-up.
[Bug target/70672] New: [5] Wrong code for little endian bitfield modification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70672
Bug ID: 70672
Summary: [5] Wrong code for little endian bitfield modification
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wschmidt at gcc dot gnu.org
CC: dje at gcc dot gnu.org, segher at gcc dot gnu.org
Target Milestone: ---
Target: powerpc64le-unknown-linux-gnu
The following code compiled with -O2 with GCC 5.3 produces incorrect code.
Correct code is generated for current trunk.
typedef unsigned long long CoreUInt64;
typedef unsigned int CoreUInt32;
CoreUInt64 shift4BtUp(CoreUInt64 a)
{
struct Int32S
{
CoreUInt32 highTop;
CoreUInt32 lowTop;
};
union
{
struct Int32S _32store;
CoreUInt64 _64store;
} x;
x._64store = a;
x._32store.lowTop = x._32store.highTop;
x._32store.highTop = 0;
return x._64store;
}
The correct code is a 32-bit left shift on little endian, and indeed trunk
produces sldi 3,3,32 as expected. But on 5.3 we get rldicr 3,3,0,31.
After expand:
;; x._64store = a_2(D);
(insn 6 5 0 (set (reg/v:DI 125 [ x ])
(reg/v:DI 127 [ a ])) sap.c:19 -1
(nil))
;; x._32store.lowTop = _4;
(insn 7 6 0 (set (zero_extract:DI (reg/v:DI 125 [ x ])
(const_int 32 [0x20])
(const_int 0 [0]))
(reg/v:DI 125 [ x ])) sap.c:21 -1
(nil))
;; x._32store.highTop = 0;
(insn 8 7 9 (set (reg:DI 128)
(const_int 0 [0])) sap.c:22 -1
(nil))
(insn 9 8 0 (set (zero_extract:DI (reg/v:DI 125 [ x ])
(const_int 32 [0x20])
(const_int 32 [0x20]))
(reg:DI 128)) sap.c:22 -1
(nil))
;; _7 = x._64store;
(insn 10 9 0 (set (reg:DI 124 [ D.2241 ])
(reg/v:DI 125 [ x ])) sap.c:24 -1
(nil))
This is correct. But then, following the first jump optimization pass, insn 7
is incorrectly removed.
I bisected the fix on trunk to r226005, in which Segher did a complete rewrite
of much of the rotate code. Unfortunately this is a relatively large patch, so
it isn't immediately obvious where the original problem was. There must have
been a hidden endianness assumption in there somewhere.
If it's acceptable, it would be nice to backport the whole patch, but I am not
sure whether there were follow-on patches to deal with any fallout. Certainly
this has had a lot of burn-in time by now.
Segher, can you please advise? Do you recall seeing a bug like this when you
were working on this last year?
[Bug c++/70648] [6 Regression] adplug-xmms fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70648 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Jason Merrill --- Fixed.
[Bug c++/70622] [6 Regression] auto specifier don't deduce value type and its pointer type within single declaration.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70622 --- Comment #3 from Jason Merrill --- Author: jason Date: Thu Apr 14 20:14:49 2016 New Revision: 234991 URL: https://gcc.gnu.org/viewcvs?rev=234991&root=gcc&view=rev Log: PR c++/70622 * parser.c (cp_parser_init_declarator): Add auto_result parm. (cp_parser_simple_declaration): Pass it. (strip_declarator_types): New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/auto47.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c
[Bug c++/70543] [6 Regression] wrong non-const error for enable_if and constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70543 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jason Merrill --- Fixed.
[Bug c++/70648] [6 Regression] adplug-xmms fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70648 --- Comment #1 from Jason Merrill --- Author: jason Date: Thu Apr 14 20:14:38 2016 New Revision: 234989 URL: https://gcc.gnu.org/viewcvs?rev=234989&root=gcc&view=rev Log: PR c++/70648 * constexpr.c (cxx_eval_store_expression): Also copy CONSTRUCTOR_NO_IMPLICIT_ZERO. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-initlist10.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c
[Bug c++/70543] [6 Regression] wrong non-const error for enable_if and constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70543 --- Comment #5 from Jason Merrill --- Author: jason Date: Thu Apr 14 20:14:44 2016 New Revision: 234990 URL: https://gcc.gnu.org/viewcvs?rev=234990&root=gcc&view=rev Log: PR c++/70543 * pt.c (value_dependent_expression_p) [VAR_DECL]: A type-dependent initializer also makes the variable value-dependent. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-template9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/70622] [6 Regression] auto specifier don't deduce value type and its pointer type within single declaration.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70622 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #2 from Jason Merrill --- Fixed.
[Bug c++/70543] [6 Regression] wrong non-const error for enable_if and constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70543 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jason Merrill --- Author: jason Date: Thu Apr 14 20:14:44 2016 New Revision: 234990 URL: https://gcc.gnu.org/viewcvs?rev=234990&root=gcc&view=rev Log: PR c++/70543 * pt.c (value_dependent_expression_p) [VAR_DECL]: A type-dependent initializer also makes the variable value-dependent. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-template9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c --- Comment #6 from Jason Merrill --- Fixed.
[Bug target/70640] IEEE 128-bit floating point negative/abs has two thinkos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70640 Michael Meissner changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Michael Meissner --- After I applied the fix for PR 70640, one the regression testers reported the test as an error. This system is a power7 system that does not have an asembler that understands the power8/power9 instructions. This means that -mcpu=power8 will only generate power7 code. The difference for this test is that on power7, it generates a vspltisw instruciton to create a register with all 1's set, while on power8 it generates xxlorc instead (vspltisw is restricted to the Altivec registers, while xxlorc can target all VSX registers, so it is preferred for power8 code). Test case updated in subversion id 234988.
[Bug target/70640] IEEE 128-bit floating point negative/abs has two thinkos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70640 --- Comment #4 from Michael Meissner --- Author: meissner Date: Thu Apr 14 20:05:58 2016 New Revision: 234988 URL: https://gcc.gnu.org/viewcvs?rev=234988&root=gcc&view=rev Log: 2016-04-14 Michael Meissner PR target/70640 * gcc.target/powerpc/pr70640.c: Fix test so it correctly works on a power7 system that does not have an assembler that supports power8. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/powerpc/pr70640.c
[Bug c++/70594] [6 Regression] -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #50 from Jakub Jelinek --- Should be fixed now. If there are further -fcompare-debug issues, please open a new PR.
[Bug bootstrap/70652] [6 Regression] r234966 causes bootstrap to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70652 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Martin Sebor --- Commit r234981 reverts the change and restores the Java bootstrap (verified on x86_64-linux).
[Bug c++/70594] [6 Regression] -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #49 from Jakub Jelinek --- Author: jakub Date: Thu Apr 14 19:21:31 2016 New Revision: 234987 URL: https://gcc.gnu.org/viewcvs?rev=234987&root=gcc&view=rev Log: PR c++/70594 * ipa-utils.h (polymorphic_ctor_dtor_p): New prototype. * ipa-polymorphic-call.c (polymorphic_ctor_dtor_p): New function. (inlined_polymorphic_ctor_dtor_block_p): Use it. * tree-ssa-live.c (remove_unused_scope_block_p): When in_ctor_dtor_block, avoid discarding not just BLOCKs with BLOCK_ABSTRACT_ORIGIN being FUNCTION_DECL, but even when block_ultimate_origin is FUNCTION_DECL. (remove_unused_locals): If current_function_decl is polymorphic_ctor_dtor_p, pass initial true to remove_unused_scope_block_p' is_ctor_dtor_block. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-polymorphic-call.c trunk/gcc/ipa-utils.h trunk/gcc/tree-ssa-live.c
[Bug c/70671] New: Wrong column number shown for "error: cannot take address of bit-field"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70671
Bug ID: 70671
Summary: Wrong column number shown for "error: cannot take
address of bit-field"
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
When compiling this program:
int main()
{
struct { int x:2; } s;
12345; &s.x;
}
I get the following error message:
$ gcc example.c
example.c: In function ‘main’:
example.c:4:3: error: cannot take address of bit-field ‘x’
12345; &s.x;
^
The column number is wrong.
[Bug ipa/70646] [4.9/5/6 Regression] Corrupt truncated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646 --- Comment #13 from Josh Poimboeuf --- So if I understand correctly, some reachable code is incorrectly getting marked unreachable and then getting discarded. Interestingly, the function's epilogue (frame pointer restore) and return instruction are also getting discarded. Can you tell if that will always be the case when this bug triggers? If so, that should make it possible for objtool to reliably detect the bug.
[Bug target/70670] Duplicate code in rs6000_secondary_reload_direct_move in rs6000.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70670 Michael Meissner changed: What|Removed |Added Target||powerpc64le-unknown-linux-g ||nu Priority|P3 |P4 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-04-14 CC||dje at gcc dot gnu.org, ||wschmidt at gcc dot gnu.org Host||powerpc64le-unknown-linux-g ||nu Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot gnu.org Ever confirmed|0 |1 Build||powerpc64le-unknown-linux-g ||nu --- Comment #1 from Michael Meissner --- While this is harmless, it probably should be fixed some day.
[Bug target/70670] New: Duplicate code in rs6000_secondary_reload_direct_move in rs6000.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70670
Bug ID: 70670
Summary: Duplicate code in rs6000_secondary_reload_direct_move
in rs6000.c
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: meissner at gcc dot gnu.org
Target Milestone: ---
In tracking down the bug in 70669, I noticed that
rs6000_secondary_reload_direct_move has duplicated code.
The code looks like:
if (TARGET_POWERPC64)
{
if (size == 16)
{
// ...
}
else if (mode == SFmode)
{
// ...
}
}
if (TARGET_POWERPC64 && size == 16)
{
// ...
}
Where the code in the second if is identical to the code in the first if if the
size is 16 bytes.
[Bug target/70669] PowerPC __float128 does not support direct move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70669 Michael Meissner changed: What|Removed |Added Target||powerpc64le-unknown-linux-g ||nu Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-04-14 CC||dje at gcc dot gnu.org, ||wschmidt at gcc dot gnu.org Host||powerpc64le-unknown-linux-g ||nu Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot gnu.org Ever confirmed|0 |1 Build||powerpc64le-unknown-linux-g ||nu
[Bug target/70669] New: PowerPC __float128 does not support direct move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70669 Bug ID: 70669 Summary: PowerPC __float128 does not support direct move Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: meissner at gcc dot gnu.org Target Milestone: --- KFmode (i.e. __float128) does not have reload handlers to allow the compiler to do a direct move operation to move the values between GPRs and vector registers in a few instructions. Instead it needs to do a store and load to copy the values. The function rs6000_init_hard_regno_mode_ok should set reg_addr[KFmode].reload_gpr_vsx and reg_addr[KFmode].reload_vsx_gpr to the reload handlers.
[Bug c++/70653] bubble sorting algorithm fail to run on the compiler giving a bug in it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70653 --- Comment #2 from waleed --- can you recommend me which tool we should use for bug tracking > From: gcc-bugzi...@gcc.gnu.org > To: waleed-ri...@hotmail.com > Subject: [Bug c++/70653] bubble sorting algorithm fail to run on the compiler > giving a bug in it > Date: Thu, 14 Apr 2016 08:33:25 + > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70653 > > Richard Biener changed: > >What|Removed |Added > > Status|UNCONFIRMED |RESOLVED > Resolution|--- |INVALID > > --- Comment #1 from Richard Biener --- > we're not a tool to find bugs in your code > > -- > You are receiving this mail because: > You reported the bug. =
[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650 --- Comment #60 from Roger Orr --- Thanks; I can now confirm that a full build of our application with distcc works without problems.
[Bug c/70668] nds32-elf toolchain fails to compile on OSX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70668 Stefan Reinauer changed: What|Removed |Added Summary|nds32-elf toolchain fails |nds32-elf toolchain fails |to compile on OSX" |to compile on OSX --- Comment #3 from Stefan Reinauer --- Also, I have found out that passing -fno-jump-tables to the compiler call fixes the issue. Interestingly enough, I have built cross toolchains on OS X for i386-elf, x86_64-elf, arm-eabi, aarch64-elf, powerpc64-linux-gnu, mipsel-elf (and riscv with a local patch) and only nds32le-elf is crashing. So, while the same script does not crash on Ubuntu 15.10 compiling a nds32le-elf cross toolchain, it seems it's rather a problem that happens to be exposed on OS X than a problem with OS X.
[Bug c/70668] nds32-elf toolchain fails to compile on OSX"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70668 Stefan Reinauer changed: What|Removed |Added Target||nds32le-elf Host||Darwin 15.4.0 --- Comment #2 from Stefan Reinauer --- The environment is Mac OS X El Capitan (Darwin 15.4.0) cross compiler build for nds32le-elf fails when building libgcc. So far, I tracked the issue down to cc1 crashing when compiling divfs3.c (or even the attached minimized example of it) - 8< -- 8< --- ./build-nds32le-elf-GCC/gcc/cc1 divsf3.c __divsf3 Analyzing compilation unit Performing interprocedural optimizations <*free_lang_data> Assembling functions: __divsf3Abort trap: 6 - 8< -- 8< --- Debugger output: - 8< -- 8< --- lldb ./build-nds32le-elf-GCC/gcc/cc1 (lldb) target create "./build-nds32le-elf-GCC/gcc/cc1" Current executable set to './build-nds32le-elf-GCC/gcc/cc1' (x86_64). (lldb) run divsf3.c Process 45989 launched: './build-nds32le-elf-GCC/gcc/cc1' (x86_64) __divsf3 Analyzing compilation unit Performing interprocedural optimizations <*free_lang_data> Assembling functions: __divsf3Process 45989 stopped * thread #1: tid = 0x5c6719, 0x7fff9ee20f06 libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT frame #0: 0x7fff9ee20f06 libsystem_kernel.dylib`__pthread_kill + 10 libsystem_kernel.dylib`__pthread_kill: -> 0x7fff9ee20f06 <+10>: jae0x7fff9ee20f10; <+20> 0x7fff9ee20f08 <+12>: movq %rax, %rdi 0x7fff9ee20f0b <+15>: jmp0x7fff9ee1b7cd; cerror_nocancel 0x7fff9ee20f10 <+20>: retq (lldb) bt * thread #1: tid = 0x5c6719, 0x7fff9ee20f06 libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT * frame #0: 0x7fff9ee20f06 libsystem_kernel.dylib`__pthread_kill + 10 frame #1: 0x7fff9bf0f4ec libsystem_pthread.dylib`pthread_kill + 90 frame #2: 0x7fff98512787 libsystem_c.dylib`__abort + 145 frame #3: 0x7fff98513066 libsystem_c.dylib`__stack_chk_fail + 200 frame #4: 0x0001001198d8 cc1`gen_casesi(rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*) + 392 frame #5: 0x0001006a69bc cc1`insn_gen_fn::operator()(rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*) const + 76 frame #6: 0x000100697b09 cc1`maybe_gen_insn(insn_code, unsigned int, expand_operand*) + 473 frame #7: 0x0001006a4001 cc1`maybe_expand_jump_insn(insn_code, unsigned int, expand_operand*) + 33 frame #8: 0x000100699481 cc1`expand_jump_insn(insn_code, unsigned int, expand_operand*) + 33 frame #9: 0x000100353f20 cc1`try_casesi(tree_node*, tree_node*, tree_node*, tree_node*, rtx_def*, rtx_def*, rtx_def*, int) + 864 frame #10: 0x0001007c0ee9 cc1`emit_case_dispatch_table(tree_node*, tree_node*, case_node*, rtx_def*, tree_node*, tree_node*, tree_node*, basic_block_def*) + 313 frame #11: 0x0001007c07aa cc1`expand_case(gswitch*) + 1290 frame #12: 0x0001001c04b2 cc1`expand_gimple_stmt_1(gimple_statement_base*) + 386 frame #13: 0x0001001beba3 cc1`expand_gimple_stmt(gimple_statement_base*) + 131 frame #14: 0x0001001b989b cc1`expand_gimple_basic_block(basic_block_def*, bool) + 3803 frame #15: 0x0001001b6bef cc1`(anonymous namespace)::pass_expand::execute(function*) + 3199 frame #16: 0x0001006c67b1 cc1`execute_one_pass(opt_pass*) + 721 frame #17: 0x0001006c709e cc1`execute_pass_list_1(opt_pass*) + 78 frame #18: 0x0001006b9732 cc1`execute_pass_list(function*, opt_pass*) + 34 frame #19: 0x0001002008dd cc1`cgraph_node::expand() + 365 frame #20: 0x000100203f45 cc1`output_in_order(bool) + 917 frame #21: 0x0001002035d2 cc1`symbol_table::compile() + 642 frame #22: 0x000100204363 cc1`symbol_table::finalize_compilation_unit() + 179 frame #23: 0x00010001c67a cc1`c_write_global_declarations() + 474 frame #24: 0x0001007d9c47 cc1`compile_file() + 167 frame #25: 0x0001007d8438 cc1`do_compile() + 328 frame #26: 0x0001007d7e83 cc1`toplev::main(int, char**) + 371 frame #27: 0x000100b3dbeb cc1`main + 59 frame #28: 0x7fff90a6b5ad libdyld.dylib`start + 1 frame #29: 0x7fff90a6b5ad libdyld.dylib`start + 1 (lldb) - 8< -- 8< ---
[Bug c/70668] nds32-elf toolchain fails to compile on OSX"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70668 --- Comment #1 from Stefan Reinauer --- Created attachment 38273 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38273&action=edit minimal example
[Bug bootstrap/70652] [6 Regression] r234966 causes bootstrap to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70652 --- Comment #5 from Martin Sebor --- Author: msebor Date: Thu Apr 14 17:35:23 2016 New Revision: 234981 URL: https://gcc.gnu.org/viewcvs?rev=234981&root=gcc&view=rev Log: PR c++/70652 - [6 Regression] r234966 causes bootstrap to fail Revert patch for c++/69517, c++/70019, and c++/70588. Removed: trunk/gcc/testsuite/g++.dg/cpp1y/vla12.C trunk/gcc/testsuite/g++.dg/cpp1y/vla13.C trunk/gcc/testsuite/g++.dg/cpp1y/vla14.C trunk/gcc/testsuite/g++.dg/cpp1y/vla3.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/init.c trunk/gcc/cp/typeck2.c trunk/gcc/doc/extend.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/ubsan/vla-1.c trunk/gcc/testsuite/g++.dg/init/array24.C trunk/gcc/testsuite/g++.dg/ubsan/vla-1.C
[Bug c/70668] New: nds32-elf toolchain fails to compile on OSX"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70668 Bug ID: 70668 Summary: nds32-elf toolchain fails to compile on OSX" Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: stefan.reinauer at coreboot dot org Target Milestone: ---
[Bug bootstrap/70650] [6 regression] bootstrap failure: ICE in emit_move_insn, at expr.c:3546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70650 --- Comment #17 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #8 from Jason Merrill --- [...] > This fixes the reduced testcase for me on sparc, does it fix bootstrap on the > various targets? Just for the record, with your patch a sparc-sun-solaris2.12 bootstrap is well into stage2, so the immediate failure is gone. Will be a couple more hours before I have testsuite results. Rainer
[Bug bootstrap/70652] [6 Regression] r234966 causes bootstrap to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70652 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Known to fail||6.0 --- Comment #4 from Martin Sebor --- The change (r234966) resolves a regression (bug 69517) in how C++ VLAs initialized with excess elements are handled: by throwing an exception in GCC 4.9, and by allowing the program to crash in 5 and 6. Jakub and Jason agreed in an IRC discussion that due to the reported problem and the proximity of GCC 6 release date the change should be backed out and resubmitted in stage 1 for GCC 7. I'll take care of it.
[Bug c++/70543] [6 Regression] wrong non-const error for enable_if and constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70543 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/70648] [6 Regression] adplug-xmms fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70648 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-04-14 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/70029] [7 Regression] ICE with C++11 and -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70029 Marek Polacek changed: What|Removed |Added Target Milestone|6.0 |7.0 Summary|[6 Regression] ICE with |[7 Regression] ICE with |C++11 and -flto |C++11 and -flto --- Comment #10 from Marek Polacek --- Resolved for GCC 6 by disabling the check; leaving this open for a proper solution in GCC 7.
[Bug c++/70029] [6 Regression] ICE with C++11 and -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70029 --- Comment #9 from Marek Polacek --- Author: mpolacek Date: Thu Apr 14 16:51:16 2016 New Revision: 234979 URL: https://gcc.gnu.org/viewcvs?rev=234979&root=gcc&view=rev Log: PR c++/70029 * tree.c (verify_type): Disable the canonical type of main variant check. * g++.dg/torture/pr70029.C: New test. Added: trunk/gcc/testsuite/g++.dg/torture/pr70029.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c
[Bug c++/70667] New: SFINAE error disambiguating using alignas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70667
Bug ID: 70667
Summary: SFINAE error disambiguating using alignas
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The following program tries to use SFINAE to determine whether a non-type
template argument N is a valid alignment. It depends on overload resolution to
choose between two overloads of function template f, only one of which is valid
for the given value of N. Since the first overload isn't viable (3 is not a
valid alignment because it isn't a non-negative power of 2), the second
overload is expected to be selected. But instead, GCC fails with an error.
$ cat u.c && g++ -S -Wall -Wextra -Wpedantic -xc++ u.c
template struct A { alignas (N) int a; };
template struct B { char c; };
template int f (int (*)[sizeof (A)]) { return 0; }
template int f (int (*)[sizeof (B)]) { return 1; }
int i = f<3>();
u.c: In instantiation of ‘struct A<3>’:
u.c:4:40: required by substitution of ‘template int f(int (*)[sizeof
(A)]) [with int N = 3]’
u.c:7:14: required from here
u.c:1:45: error: requested alignment is not a positive power of 2
template struct A { alignas (N) int a; };
^
u.c:7:14: error: no matching function for call to ‘f()’
int i = f<3>();
^
u.c:4:22: note: candidate: template int f(int (*)[sizeof (A)])
template int f (int (*)[sizeof (A)]) { return 0; }
^
u.c:4:22: note: substitution of deduced template arguments resulted in errors
seen above
u.c:5:22: note: candidate: template int f(int (*)[sizeof (B)])
template int f (int (*)[sizeof (B)]) { return 1; }
^
u.c:5:22: note: template argument deduction/substitution failed:
u.c:7:14: note: candidate expects 1 argument, 0 provided
int i = f<3>();
^
[Bug c++/70649] [6 Regression] Incorrect C++ warning on zero-sized array passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70649 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Jason Merrill --- Fixed by reverting the ABI change.
[Bug bootstrap/70650] [6 regression] bootstrap failure: ICE in emit_move_insn, at expr.c:3546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70650 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Jason Merrill --- Fixed by reverting the abi change.
[Bug c++/70649] [6 Regression] Incorrect C++ warning on zero-sized array passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70649 --- Comment #1 from Jason Merrill --- Created attachment 38272 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38272&action=edit fix
[Bug bootstrap/70650] [6 regression] bootstrap failure: ICE in emit_move_insn, at expr.c:3546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70650 --- Comment #15 from Jason Merrill --- (In reply to Jack Howarth from comment #14) > (In reply to Jason Merrill from comment #13) > Is darwin the only target using TREE_TYPE rather than DECL_ARG_TYPE? No, that should be the same for all targets; I don't know why this would affect darwin and not linux.
[Bug c/70651] [6 Regression] ICE on valid code on x86_64-linux-gnu in build_va_arg, at c-family/c-common.c:5728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70651 --- Comment #5 from Jakub Jelinek --- Yeah, the assertions are clearly bogus. Though perhaps it would be better to just error out at those spots instead of ignoring it and hoping we'll error out later.
[Bug c++/70594] [6 Regression] -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #48 from Jakub Jelinek --- Created attachment 38271 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38271&action=edit gcc6-pr70594.patch Untested fix. So the other issue is that noncall_stmt_may_be_vtbl_ptr_store looks for BLOCKs with block_ultimate_origin of FUNCTION_DECL (which is correct), and tree-ssa-live.c was doing that too for finding the cdtor BLOCKs (through inlined_polymorphic_ctor_dtor_block_p), but only looked if BLOCK_ABSTRACT_ORIGIN is FUNCTION_DECL inside of those blocks, which is wrong, that is just subset of what block_ultimate_origin returns. As for the changes I've mentioned in the previous comment already and that are included in this patch too, the thing is that while the pruning code works (except for the above mentioned thing) right when we have a cdtor inlined and some other function inlined into it, we can actually lose the needed BLOCKs already earlier, when pruning unused BLOCKs inside of the cdtor itself before it is inlined - then we also have to avoid pruning the BLOCKs with FUNCTION_DECL ultimate origins (except we of course can prune such blocks inside of BLOCKs with FUNCTION_DECL ultimate origins), thus we need to start with the right value of the is_ctor_dtor_block flag - DECL_INITIAL (current_function_block) usually doesn't have block_ultimate_origin a FUNCTION_DECL and even if it does, it is not current_function_decl - only BLOCK_SUPERCONTEXT (DECL_INITIAL (current_function_decl)) is current_function_decl. This patch fixes the -fcompare-debug issue on the Tobias' testcase.
[Bug bootstrap/70650] [6 regression] bootstrap failure: ICE in emit_move_insn, at expr.c:3546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70650 --- Comment #14 from Jack Howarth --- (In reply to Jason Merrill from comment #13) Is darwin the only target using TREE_TYPE rather than DECL_ARG_TYPE?
[Bug bootstrap/70650] [6 regression] bootstrap failure: ICE in emit_move_insn, at expr.c:3546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70650 --- Comment #13 from Jason Merrill --- The darwin problem is with an ipa-icf thunk trying to pass the parameter on directly, which breaks because it's using the parameter's TREE_TYPE rather than DECL_ARG_TYPE. expand_call handles this transparently for integral promotions by way of promote_function_mode, but doesn't know how to do the equivalent here. This is a significant problem with trying to handle this transition in the front end rather than the back end (as H.J.'s patch did).
[Bug c++/70594] [6 Regression] -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594
--- Comment #47 from Jakub Jelinek ---
Ok, found one bug in the unused block pruning:
--- gcc/ipa-polymorphic-call.c.jj 2016-03-30 16:00:17.0 +0200
+++ gcc/ipa-polymorphic-call.c 2016-04-14 16:45:45.407754387 +0200
@@ -479,16 +479,12 @@ contains_type_p (tree outer_type, HOST_W
}
-/* Return a FUNCTION_DECL if BLOCK represents a constructor or destructor.
+/* Return a FUNCTION_DECL if FN represent a constructor or destructor.
If CHECK_CLONES is true, also check for clones of ctor/dtors. */
tree
-inlined_polymorphic_ctor_dtor_block_p (tree block, bool check_clones)
+polymorphic_ctor_dtor_p (tree fn, bool check_clones)
{
- tree fn = block_ultimate_origin (block);
- if (fn == NULL || TREE_CODE (fn) != FUNCTION_DECL)
-return NULL_TREE;
-
if (TREE_CODE (TREE_TYPE (fn)) != METHOD_TYPE
|| (!DECL_CXX_CONSTRUCTOR_P (fn) && !DECL_CXX_DESTRUCTOR_P (fn)))
{
@@ -510,6 +506,19 @@ inlined_polymorphic_ctor_dtor_block_p (t
return fn;
}
+/* Return a FUNCTION_DECL if BLOCK represents a constructor or destructor.
+ If CHECK_CLONES is true, also check for clones of ctor/dtors. */
+
+tree
+inlined_polymorphic_ctor_dtor_block_p (tree block, bool check_clones)
+{
+ tree fn = block_ultimate_origin (block);
+ if (fn == NULL || TREE_CODE (fn) != FUNCTION_DECL)
+return NULL_TREE;
+
+ return polymorphic_ctor_dtor_p (fn, check_clones);
+}
+
/* We know that the instance is stored in variable or parameter
(not dynamically allocated) and we want to disprove the fact
--- gcc/ipa-utils.h.jj 2016-01-04 14:55:51.0 +0100
+++ gcc/ipa-utils.h 2016-04-14 16:46:08.828444152 +0200
@@ -70,6 +70,7 @@ void dump_possible_polymorphic_call_targ
bool possible_polymorphic_call_target_p (tree, HOST_WIDE_INT,
const ipa_polymorphic_call_context &,
struct cgraph_node *);
+tree polymorphic_ctor_dtor_p (tree, bool);
tree inlined_polymorphic_ctor_dtor_block_p (tree, bool);
bool decl_maybe_in_construction_p (tree, tree, gimple *, tree);
tree vtable_pointer_value_to_binfo (const_tree);
--- gcc/tree-ssa-live.c.jj 2016-01-04 14:55:51.0 +0100
+++ gcc/tree-ssa-live.c 2016-04-14 16:47:33.343324654 +0200
@@ -855,7 +855,9 @@ remove_unused_locals (void)
cfun->local_decls->truncate (dstidx);
}
- remove_unused_scope_block_p (DECL_INITIAL (current_function_decl), false);
+ remove_unused_scope_block_p (DECL_INITIAL (current_function_decl),
+ polymorphic_ctor_dtor_p (current_function_decl,
+ true) != NULL_TREE);
clear_unused_block_pointer ();
BITMAP_FREE (usedvars);
but sadly this still doesn't fix it (though, fixes at least the first case
where we nuke the needed BLOCK).
[Bug tree-optimization/70130] [6 Regression] h264ref fails with verification error starting with r231674 (r224221 is the true start of the problem)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130 --- Comment #29 from Pat Haugen --- Verified the patch also fixes the problem with h264ref benchmark.
[Bug bootstrap/70650] [6 regression] bootstrap failure: ICE in emit_move_insn, at expr.c:3546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70650
--- Comment #12 from Jack Howarth ---
(In reply to Jakub Jelinek from comment #6)
> Shorter testcase:
> struct A {};
>
> void
> foo (struct A a, int b)
> {
> }
> compiles with sparc-solaris C, but doesn't with C++.
This test case doesn't trigger an ICE in the compiler on x86_64 darwin with or
without the proposed patch for the sparc bootstrap failure.
[Bug bootstrap/70650] [6 regression] bootstrap failure: ICE in emit_move_insn, at expr.c:3546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70650 --- Comment #11 from Jack Howarth --- In case it helps, with the proposed patch, the backtrace from fancy_abort in the failing string-inst.cc compilation on darwin appears as... (lldb) bt * thread #1: tid = 0x54d252, 0x0001018798f3 cc1plus`fancy_abort(file="../../gcc-6-20160414/gcc/expr.c", line=3546, function="emit_move_insn") + 19 at diagnostic.c:1329, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 * frame #0: 0x0001018798f3 cc1plus`fancy_abort(file="../../gcc-6-20160414/gcc/expr.c", line=3546, function="emit_move_insn") + 19 at diagnostic.c:1329 frame #1: 0x000100da030b cc1plus`emit_move_insn(x=0x00010534cea0, y=0x00010534ce58) + 123 at expr.c:3545 frame #2: 0x000100dca4b0 cc1plus`emit_single_push_insn_1(mode=QImode, x=0x00010534ce58, type=0x0001026b1dc8) + 656 at expr.c:4033 frame #3: 0x000100dab5e9 cc1plus`emit_single_push_insn(mode=QImode, x=0x00010534ce58, type=0x0001026b1dc8) + 57 at expr.c:4045 frame #4: 0x000100dab1a7 cc1plus`emit_push_insn(x=0x00010534ce58, mode=QImode, type=0x0001026b1dc8, size=0x, align=64, partial=0, reg=0x, extra=0, args_addr=0x, args_so_far=0x000144808480, reg_parm_stack_space=0, alignment_pad=0x000144808480, sibcall_p=true) + 3815 at expr.c:4384 frame #5: 0x000100bc315c cc1plus`store_one_arg(arg=0x7fff5fbfd750, argblock=0x, flags=0, variable_size=0, reg_parm_stack_space=0) + 3036 at calls.c:4883 frame #6: 0x000100bbbf16 cc1plus`expand_call(exp=0x000105297b40, target=0x, ignore=1) + 10550 at calls.c:3191 frame #7: 0x000100dbcb8f cc1plus`expand_expr_real_1(exp=0x000105297b40, target=0x, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x, inner_reference_p=false) + 25647 at expr.c:10601 frame #8: 0x000100db4297 cc1plus`expand_expr_real(exp=0x000105297b40, target=0x000144808480, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x, inner_reference_p=false) + 215 at expr.c:7961 frame #9: 0x000100bf44d1 cc1plus`expand_expr(exp=0x000105297b40, target=0x000144808480, mode=VOIDmode, modifier=EXPAND_NORMAL) + 49 at expr.h:256 frame #10: 0x000100bf3a2e cc1plus`expand_call_stmt(stmt=0x000104d79c78) + 2158 at cfgexpand.c:2661 frame #11: 0x000100bf051e cc1plus`expand_gimple_stmt_1(stmt=0x000104d79c78) + 430 at cfgexpand.c:3549 frame #12: 0x000100bee523 cc1plus`expand_gimple_stmt(stmt=0x000104d79c78) + 131 at cfgexpand.c:3715 frame #13: 0x000100bef993 cc1plus`expand_gimple_tailcall(bb=0x000104fb7a28, stmt=0x000104d79c78, can_fallthru=0x7fff5fbff07f) + 35 at cfgexpand.c:3762 frame #14: 0x000100be7ff8 cc1plus`expand_gimple_basic_block(bb=0x000104fb7a28, disable_tail_calls=false) + 4072 at cfgexpand.c:5698 frame #15: 0x000100be4e9a cc1plus`(anonymous namespace)::pass_expand::execute(this=0x000143914260, fun=0x000104d79738) + 4074 at cfgexpand.c:6345 frame #16: 0x0001011eb28a cc1plus`execute_one_pass(pass=0x000143914260) + 762 at passes.c:2336 frame #17: 0x0001011ebdf7 cc1plus`execute_pass_list_1(pass=0x000143914260) + 103 at passes.c:2420 frame #18: 0x0001011dcf6d cc1plus`execute_pass_list(fn=0x000104d79738, pass=0x000143910de0) + 77 at passes.c:2431 frame #19: 0x000100c3c50c cc1plus`cgraph_node::expand(this=0x000104989b80) + 540 at cgraphunit.c:1982 frame #20: 0x000100c4130a cc1plus`expand_all_functions() + 522 at cgraphunit.c:2118 frame #21: 0x000100c4022e cc1plus`symbol_table::compile(this=0x0001448050a8) + 990 at cgraphunit.c:2474 frame #22: 0x000100c414f9 cc1plus`symbol_table::finalize_compilation_unit(this=0x0001448050a8) + 297 at cgraphunit.c:2564 frame #23: 0x000101338cd0 cc1plus`compile_file() + 224 at toplev.c:490 frame #24: 0x000101337318 cc1plus`do_compile() + 328 at toplev.c:1988 frame #25: 0x000101336d48 cc1plus`toplev::main(this=0x7fff5fbff8a8, argc=30, argv=0x7fff5fbff8e8) + 376 at toplev.c:2096 frame #26: 0x00010185fe20 cc1plus`main(argc=30, argv=0x7fff5fbff8e8) + 64 at main.c:39 frame #27: 0x7fff862545ad libdyld.dylib`start + 1 frame #28: 0x7fff862545ad libdyld.dylib`start + 1 (lldb)
[Bug tree-optimization/70666] New: SLP vectorization opportunity to use load element + splat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70666 Bug ID: 70666 Summary: SLP vectorization opportunity to use load element + splat Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: wschmidt at gcc dot gnu.org CC: dje at gcc dot gnu.org, rguenth at gcc dot gnu.org Target Milestone: --- Target: powerpc*-unknown-linux-gnu As discussed in PR70130, there is an opportunity to produce better code during SLP vectorization for a vector load with a permutation vector where all elements of the permutation are identical. A load of the desired element and a splat would be better than current generated code, which makes use of unaligned loads. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130#c23 for details, and see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130#c11 for a test case that can be used to reproduce the pattern.
[Bug ipa/70646] [4.9/5/6 Regression] Corrupt truncated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug bootstrap/70650] [6 regression] bootstrap failure: ICE in emit_move_insn, at expr.c:3546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70650 --- Comment #10 from Jack Howarth --- (In reply to Jason Merrill from comment #8) > Created attachment 38269 [details] > patch > > This fixes the reduced testcase for me on sparc, does it fix bootstrap on > the various targets? The proposed patch doesn't solve the bootstrap failure on darwin.
[Bug c++/70594] [6 Regression] -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #46 from Jakub Jelinek --- So, it seems the ctor BLOCKs are preserved, but others are removed. So, with -g we get: (gdb) p debug_generic_stmt (block_ultimate_origin ($29)) BLOCK #0 SUPERCONTEXT: assign (gdb) p debug_generic_stmt (block_ultimate_origin ($29->block.supercontext)) assign (gdb) p debug_generic_stmt (block_ultimate_origin ($29->block.supercontext->block.supercontext)) _M_set_length (gdb) p debug_generic_stmt (block_ultimate_origin ($29->block.supercontext->block.supercontext->block.supercontext)) BLOCK #0 SUPERCONTEXT: basic_string (gdb) p debug_generic_stmt (block_ultimate_origin ($29->block.supercontext->block.supercontext->block.supercontext->block.supercontext)) basic_string and assign and _M_set_length are FUNCTION_DECLs which aren't cdtors. while with -g0 we get for the same stmt: (gdb) p debug_generic_stmt (block_ultimate_origin ($33)) BLOCK #0 SUPERCONTEXT: assign (gdb) p debug_generic_stmt (block_ultimate_origin ($33->block.supercontext)) BLOCK #0 SUPERCONTEXT: basic_string (gdb) p debug_generic_stmt (block_ultimate_origin ($33->block.supercontext->block.supercontext)) basic_string $29 and $33 above are gimple_block (stmt). This means for -g we have more rich BLOCK tree, with extra 2 BLOCKs in between, which have sadly FUNCTION_DECL block_ultimate_origin.
[Bug c++/70594] [6 Regression] -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 Nathan Sidwell changed: What|Removed |Added Assignee|nathan at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #45 from Nathan Sidwell --- I am no longer working on this, Richard appears to have the ball. A patch to stop GC cause the constexpr machinery perturbing DECL_UID is attached to https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00607.html, but currently deemed unnecessary.
[Bug middle-end/70643] broken openacc reduction inside a fortran module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70643 cesar at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from cesar at gcc dot gnu.org --- Fixed in r234973.
[Bug target/70044] [5 Regression] -flto turns on -fomit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70044 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #9 from ktkachov at gcc dot gnu.org --- Fixed.
[Bug bootstrap/70650] [6 regression] bootstrap failure: ICE in emit_move_insn, at expr.c:3546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70650 --- Comment #9 from Jack Howarth --- Created attachment 38270 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38270&action=edit bzip2 compressed preprocessed source for libstdc++-v3/src/c++11/string-inst.cc on x86_64-apple-darwin15
[Bug target/70044] [5 Regression] -flto turns on -fomit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70044 --- Comment #8 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Thu Apr 14 13:45:34 2016 New Revision: 234974 URL: https://gcc.gnu.org/viewcvs?rev=234974&root=gcc&view=rev Log: [AArch64] Backport of PR target/70044 fix to GCC 5 2016-04-14 Nick Clifton Kyrylo Tkachov PR target/70044 * config/aarch64/aarch64.c (aarch64_override_options_after_change): When forcing flag_omit_frame_pointer to be true, use a special value that can be detected if this function is called again, thus preventing flag_omit_leaf_frame_pointer from being forced to be false. * gcc.target/aarch64/pr70044.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/gcc.target/aarch64/pr70044.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/aarch64/aarch64.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug middle-end/70643] broken openacc reduction inside a fortran module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70643 --- Comment #1 from cesar at gcc dot gnu.org --- Author: cesar Date: Thu Apr 14 13:44:17 2016 New Revision: 234973 URL: https://gcc.gnu.org/viewcvs?rev=234973&root=gcc&view=rev Log: PR middle-end/70643 gcc/ * omp-low.c (lower_oacc_reductions): Check for TREE_CONSTANT when building a mem ref for the incoming reduction variable. libgomp/ * testsuite/libgomp.oacc-fortran/pr70643.f90: New test. Added: trunk/libgomp/testsuite/libgomp.oacc-fortran/pr70643.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c trunk/libgomp/ChangeLog
[Bug bootstrap/70650] [6 regression] bootstrap failure: ICE in emit_move_insn, at expr.c:3546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70650 --- Comment #8 from Jason Merrill --- Created attachment 38269 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38269&action=edit patch This fixes the reduced testcase for me on sparc, does it fix bootstrap on the various targets?
[Bug c++/70594] [6 Regression] -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594
--- Comment #44 from Richard Biener ---
Index: gcc/ipa-polymorphic-call.c
===
--- gcc/ipa-polymorphic-call.c (revision 234971)
+++ gcc/ipa-polymorphic-call.c (working copy)
@@ -485,6 +485,9 @@ contains_type_p (tree outer_type, HOST_W
tree
inlined_polymorphic_ctor_dtor_block_p (tree block, bool check_clones)
{
+ if (! inlined_function_outer_scope_p (block))
+return NULL_TREE;
+
tree fn = block_ultimate_origin (block);
if (fn == NULL || TREE_CODE (fn) != FUNCTION_DECL)
return NULL_TREE;
[Bug ada/70645] strange -fguess-branch-probability issue with debug info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70645 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot gnu.org Resolution|--- |WORKSFORME Summary|[4.9/5/6 Regression]|strange |-fguess-branch-probability |-fguess-branch-probability |breaks debug-information, |issue with debug info |only in Ada | --- Comment #1 from Eric Botcazou --- I cannot reproduce on Linux. Besides there is no guarantee that debug info be fully correct, except for -O0 and -Og. Try to break on "Hello" instead or to fiddle with the various -gdwarf options since this is Darwin.
[Bug c/70665] Seemingly incorrect warning for being const correct with function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70665 --- Comment #2 from Phillipi Susi --- Yes, so why is there an implicit conversion that does not cause a warning when called directly, but not when called via pointer?
[Bug c++/70594] [6 Regression] -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #43 from Richard Biener --- Same walking of BLOCKs in noncall_stmt_may_be_vtbl_ptr_store.
[Bug c/70665] Seemingly incorrect warning for being const correct with function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70665 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- Because const char * and char * are not compatible types. That is they have an implicit conversion between the two but are still not compatible types.
[Bug c++/70594] [6 Regression] -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594
--- Comment #42 from Jakub Jelinek ---
I see a difference when tree-ssa-pre.c calls
context.get_dynamic_type (instance, OBJ_TYPE_REF_OBJECT (fn), otr_type, stmt);
in get_dynamic_type, right after the first walk_aliased_vdefs in there, in one
invocation I get:
$16 = {offset = 0, instance = , vtbl_ptr_ref =
,
otr_type = , known_current_type = , known_current_offset = 0, speculative = 14,
type_maybe_changed = false, multiple_types_encountered = false,
seen_unanalyzed_store = true}
and in the other
$15 = {offset = 0, instance = , vtbl_ptr_ref =
,
otr_type = , known_current_type = , known_current_offset = 0, speculative = 13,
type_maybe_changed = false, multiple_types_encountered = false,
seen_unanalyzed_store = false}
[Bug tree-optimization/70130] [6 Regression] h264ref fails with verification error starting with r231674 (r224221 is the true start of the problem)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130 --- Comment #28 from Alan Modra --- Bootstrapped and regression testing now completed on both powerpc64le-linux and -m64/-m32 on a power7 powerpc64-linux host, all langs. No regressions found, and it seems this also fixes gcc.dg/vect/slp-perm-12.c on power7 powerpc64-linux. Thanks!
[Bug tree-optimization/70614] [4.9/5/6 Regression] GCC gets stuck with -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70614 --- Comment #6 from Richard Biener --- Author: rguenth Date: Thu Apr 14 13:21:40 2016 New Revision: 234972 URL: https://gcc.gnu.org/viewcvs?rev=234972&root=gcc&view=rev Log: 2016-04-14 Richard Biener PR tree-optimization/70614 * tree-scalar-evolution.c (analyze_evolution_in_loop): Terminate loop if the evolution dropped to chrec_dont_know. (interpret_condition_phi): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-scalar-evolution.c
[Bug tree-optimization/70614] [4.9/5 Regression] GCC gets stuck with -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70614 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Known to work||6.0 Summary|[4.9/5/6 Regression] GCC|[4.9/5 Regression] GCC gets |gets stuck with -O |stuck with -O Known to fail|6.0 | --- Comment #7 from Richard Biener --- Fixed on trunk sofar.
[Bug c/70665] New: Seemingly incorrect warning for being const correct with function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70665
Bug ID: 70665
Summary: Seemingly incorrect warning for being const correct
with function pointers
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: psusi at ubuntu dot com
Target Milestone: ---
void foo( const char *p );
void bar( char *p ) { foo( p ); }
This is perfectly acceptable and const correct since foo does not want write
access, but being given write access anyway is fine. I have run into a
seemingly incorrect warning though when calling such functions via pointer:
void foo( const char *p );
void bar( void (*fn)(char *p) );
bar( foo );
^^ generates warning about pointers not being compatible.
Apparently gcc thinks that when called via a pointer, it is not correct to pass
a writable pointer where only a read only one is needed.
