[Bug bootstrap/70650] [6 regression] bootstrap failure: ICE in emit_move_insn, at expr.c:3546

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

[jason at gcc dot gnu.org]

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

[jason at gcc dot gnu.org]

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=gcc=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

[krebbel at gcc dot gnu.org]

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

[krebbel at gcc dot gnu.org]

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=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

[jason at gcc dot gnu.org]

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

[jason at gcc dot gnu.org]

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=gcc=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

[amodra at gmail dot com]

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

[amodra at gmail dot com]

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

[davidgkinniburgh at yahoo dot co.uk]

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

[segher at gcc dot gnu.org]

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

[segher at gcc dot gnu.org]

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

[segher at gcc dot gnu.org]

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

[davidgkinniburgh at yahoo dot co.uk]

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

[davidgkinniburgh at yahoo dot co.uk]

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

[meissner at gcc dot gnu.org]

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

[meissner at gcc dot gnu.org]

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=gcc=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

[meissner at gcc dot gnu.org]

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

[ctice at gcc dot gnu.org]

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

[segher at gcc dot gnu.org]

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

[meissner at gcc dot gnu.org]

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=edit
Proposed patch to fix the problem

[Bug middle-end/61409] [4.9/5/6 regression] -Wmaybe-uninitialized false-positive with -O2

[law at redhat dot com]

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

[matt at godbolt dot org]

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 &) 
: 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

[chris.quenelle at oracle dot com]

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

[lopezibanez at gmail dot com]

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 &)
> : 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

[msebor at gcc dot gnu.org]

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=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

[jason at gcc dot gnu.org]

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

[jakub at gcc dot gnu.org]

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++

[msebor at gcc dot gnu.org]

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

[msebor at gcc dot gnu.org]

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

[msebor at gcc dot gnu.org]

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++

[msebor at gcc dot gnu.org]

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

[msebor at gcc dot gnu.org]

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

[jakub at gcc dot gnu.org]

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

[wschmidt at gcc dot gnu.org]

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

[jason at gcc dot gnu.org]

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.

[jason at gcc dot gnu.org]

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=gcc=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

[jason at gcc dot gnu.org]

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=gcc=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++/70543] [6 Regression] wrong non-const error for enable_if and constexpr function

[jason at gcc dot gnu.org]

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

[jason at gcc dot gnu.org]

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=gcc=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++/70622] [6 Regression] auto specifier don't deduce value type and its pointer type within single declaration.

[jason at gcc dot gnu.org]

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

[jason at gcc dot gnu.org]

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=gcc=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

[meissner at gcc dot gnu.org]

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

[meissner at gcc dot gnu.org]

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=gcc=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

[jakub at gcc dot gnu.org]

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

[msebor at gcc dot gnu.org]

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

[jakub at gcc dot gnu.org]

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=gcc=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"

[ch3root at openwall dot com]

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; 
}

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; 
   ^

The column number is wrong.

[Bug ipa/70646] [4.9/5/6 Regression] Corrupt truncated function

[jpoimboe at redhat dot com]

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

[meissner at gcc dot gnu.org]

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

[meissner at gcc dot gnu.org]

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

[meissner at gcc dot gnu.org]

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

[meissner at gcc dot gnu.org]

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

[waleed-rider at hotmail dot com]

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

[rogero at howzatt dot demon.co.uk]

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

[stefan.reinauer at coreboot dot org]

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"

[stefan.reinauer at coreboot dot org]

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"

[stefan.reinauer at coreboot dot org]

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=edit
minimal example

[Bug bootstrap/70652] [6 Regression] r234966 causes bootstrap to fail

[msebor at gcc dot gnu.org]

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=gcc=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"

[stefan.reinauer at coreboot dot org]

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

[msebor at gcc dot gnu.org]

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

[jason at gcc dot gnu.org]

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

[jason at gcc dot gnu.org]

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

[mpolacek at gcc dot gnu.org]

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

[mpolacek at gcc dot gnu.org]

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=gcc=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

[msebor at gcc dot gnu.org]

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

[jason at gcc dot gnu.org]

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

[jason at gcc dot gnu.org]

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

[jason at gcc dot gnu.org]

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=edit
fix

[Bug bootstrap/70650] [6 regression] bootstrap failure: ICE in emit_move_insn, at expr.c:3546

[jason at gcc dot gnu.org]

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

[jakub at gcc dot gnu.org]

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

[jakub at gcc dot gnu.org]

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=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

[howarth.at.gcc at gmail dot com]

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

[jason at gcc dot gnu.org]

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

[jakub at gcc dot gnu.org]

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)

[pthaugen at gcc dot gnu.org]

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

[howarth.at.gcc at gmail dot com]

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

[howarth.at.gcc at gmail dot com]

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

[wschmidt at gcc dot gnu.org]

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

[rguenth at gcc dot gnu.org]

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

[howarth.at.gcc at gmail dot com]

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

[jakub at gcc dot gnu.org]

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

[nathan at gcc dot gnu.org]

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

[cesar at gcc dot gnu.org]

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

[ktkachov at gcc dot gnu.org]

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

[howarth.at.gcc at gmail dot com]

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=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

[ktkachov at gcc dot gnu.org]

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=gcc=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

[cesar at gcc dot gnu.org]

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=gcc=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

[jason at gcc dot gnu.org]

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=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

[rguenth at gcc dot gnu.org]

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

[ebotcazou at gcc dot gnu.org]

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

[psusi at ubuntu dot com]

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

[rguenth at gcc dot gnu.org]

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

[pinskia at gcc dot gnu.org]

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

[jakub at gcc dot gnu.org]

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)

[amodra at gmail dot com]

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

[rguenth at gcc dot gnu.org]

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=gcc=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

[rguenth at gcc dot gnu.org]

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

[psusi at ubuntu dot com]

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.