[Bug c++/67411] [5/6 Regression] internal compiler error: in tsubst_copy, at cp/pt.c:13473

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67411

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

--- Comment #7 from Jason Merrill  ---
Fixed.

[Bug c++/67411] [5/6 Regression] internal compiler error: in tsubst_copy, at cp/pt.c:13473

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67411

--- Comment #9 from Jason Merrill  ---
Author: jason
Date: Mon Dec 21 03:04:18 2015
New Revision: 231870

URL: https://gcc.gnu.org/viewcvs?rev=231870=gcc=rev
Log:
PR c++/67411
* decl2.c (decl_maybe_constant_var_p): Use DECL_HAS_VALUE_EXPR_P.

Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/decl2.c

[Bug c++/67411] [5/6 Regression] internal compiler error: in tsubst_copy, at cp/pt.c:13473

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67411

--- Comment #8 from Jason Merrill  ---
Author: jason
Date: Mon Dec 21 03:04:08 2015
New Revision: 231869

URL: https://gcc.gnu.org/viewcvs?rev=231869=gcc=rev
Log:
PR c++/67411
* decl2.c (decl_maybe_constant_var_p): Use DECL_HAS_VALUE_EXPR_P.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c

[Bug java/58117] Java not compiling on ia64-hp-hpux11.31 due to socklen_t

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58117

Martin Sebor  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from Martin Sebor  ---
Closing based on reporter's feedback.

[Bug libstdc++/66338] std::forward_as_tuple() issue with single argument

[ville.voutilainen at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66338

--- Comment #6 from Ville Voutilainen  ---
Should be a simple matter of doing the _NonNestedTuple checks before other
checks. Patch coming in a couple of days.

[Bug libstdc++/68995] Including both and can cause ADL problems in std::function SFINAE

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68995

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-12-21
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #1)
> I think TR1 is considered as non-supported now.

Pretty much.

This is easy to fix, so I'll fix it, but people trying to mix C++11 and TR1 are
weird and should be shunned.

[Bug c++/58109] alignas() fails to compile with constant expression

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58109

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2013-08-09 00:00:00 |2015-12-20
 CC||msebor at gcc dot gnu.org
  Known to fail||4.9.3, 5.1.0, 6.0

--- Comment #6 from Martin Sebor  ---
Still fails with the current trunk, and also 5.1.0 in addition to 4.9.3.

The patch fixes the test case but I'm not yet sure it's the right or complete
fix.  My tests are still running but the comment makes me wonder if the
function handles the other attributes correctly.

Index: gcc/cp/decl2.c
===
--- gcc/cp/decl2.c  (revision 231870)
+++ gcc/cp/decl2.c  (working copy)
@@ -1193,7 +1193,7 @@
 second and following arguments.  Attributes like mode, format,
 cleanup and several target specific attributes aren't late
 just because they have an IDENTIFIER_NODE as first argument.  */
-  if (arg == args && identifier_p (t))
+  if (!is_attribute_p ("aligned", name) && arg == args && identifier_p
(t))
continue;

   if (value_dependent_expression_p (t)

[Bug tree-optimization/68659] [6 regression] FAIL: gcc.dg/graphite/id-pr45230-1.c (internal compiler error)

[danglin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68659

John David Anglin  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #11 from John David Anglin  ---
Seeing this on hppa with -mschedule=7100LC.  This is with r231795.

There is null pointer exception here:

Program received signal SIGSEGV, Segmentation fault.
translate_isl_ast_to_gimple::collect_all_ssa_names (
this=this@entry=0xfd703908, new_expr=0x0, vec_ssa=vec_ssa@entry=0xfd7044c8)
at ../../gcc/gcc/graphite-isl-ast-to-gimple.c:1603
1603  if (TREE_CODE (new_expr) == SSA_NAME)
(gdb) p new_expr
$1 = (tree) 0x0

[Bug c++/68996] New: Decltype-specifier in declarator-id should not be accepted

[zeratul976 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68996

Bug ID: 68996
   Summary: Decltype-specifier in declarator-id should not be
accepted
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeratul976 at hotmail dot com
  Target Milestone: ---

GCC accepts the following code:

  struct{
  void test();
  } a;

  void decltype(a)::test(){}

I believe this is invalid, due to the following sentence in [dcl.meaning] p1:

  The nested-name-specifier of a qualified declarator-id shall
  not begin with a decltype-specifier.

Is this an oversight, or deliberately supported as an extension?

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[raj.khem at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68302

Khem Raj  changed:

   What|Removed |Added

 CC||raj.khem at gmail dot com

--- Comment #16 from Khem Raj  ---
I see this issue as well with OpenEmbedded cross compilers ( gcc 5.2 ) -g -O2
-march=mips32r2 is the combination that fails.

[Bug libstdc++/66338] std::forward_as_tuple() issue with single argument

[ville.voutilainen at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66338

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-12-20
 CC||ville.voutilainen at gmail dot 
com
   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com
 Ever confirmed|0   |1

--- Comment #5 from Ville Voutilainen  ---
Mine.

[Bug libstdc++/68995] Including both and can cause ADL problems in std::function SFINAE

[rs2740 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68995

--- Comment #3 from TC  ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > I think TR1 is considered as non-supported now.
> 
> Pretty much.

The documentation may need updating if that's the case.

> people trying to mix C++11 and TR1 are weird and should be shunned.

I don't disagree :)

[Bug boehm-gc/66848] boehm-gc fails test suite on x86_64-apple-darwin15

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66848

--- Comment #25 from Jack Howarth  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #24)
> > --- Comment #23 from Dominique d'Humieres  ---
> >> Yes. If you apply the ugly hack from comment 11, you will find that it 
> >> fixes
> >> both the boehm-gc test suite regressions as well as those in the libjava 
> >> test
> >> suite (which are due to the breakage in boehm-gc used by libjava).
> >
> > Yes it does. This should probably also be done for the 5 branch (I see the 
> > same
> > failures).
> 
> For me (on Mac OS X 10.11.1), the hack fixes the boehm-gc failures, but
> the libjava ones remain.
> 
>   Rainer

Did you remember to install the patched build before attempting to run the
libjava test suite? System Integrity Protection on 10.11 will make any usage of
DYLD_LIBRARY_PATH by the test suite non-functional so any previously installed
libraries will be used instead of those in the current build directory.

Native configuration is x86_64-apple-darwin15.3.0

=== libjava tests ===


Running target unix/-m32
FAIL: PR16923.c compilation

=== libjava Summary for unix/-m32 ===

# of expected passes2580
# of unexpected failures1
# of expected failures  4

Running target unix/-m64
FAIL: Throw_2 execution - source compiled test
FAIL: Throw_2 -findirect-dispatch execution - source compiled test
FAIL: Throw_2 -O3 execution - source compiled test
FAIL: Throw_2 -O3 -findirect-dispatch execution - source compiled test

=== libjava Summary for unix/-m64 ===

# of expected passes2574
# of unexpected failures4
# of expected failures  4
# of untested testcases 4

=== libjava Summary ===

# of expected passes5154
# of unexpected failures5
# of expected failures  8
# of untested testcases 4

Compiler version: gcc libjava 
Platform: x86_64-apple-darwin15.3.0
configure flags: --prefix=/sw --prefix=/sw/lib/gcc6 --mandir=/sw/share/man
--infodir=/sw/lib/gcc6/info
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-isl=/sw --with-mpc=/sw --with-system-zlib
--program-suffix=-fsf-6 --with-build-config=bootstrap-debug

[Bug c++/68997] New: [cilkplus] cilk_spawn is broken for functions that return a type with a custom copy or move constructor

[ryan.burn at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68997

Bug ID: 68997
   Summary: [cilkplus] cilk_spawn is broken for functions that
return a type with a custom copy or move constructor
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryan.burn at gmail dot com
  Target Milestone: ---

The below code should be valid but gives this error:

main.cpp: In function ‘void compute_cilk()’:
main.cpp:15:26: error: invalid use of ‘_Cilk_spawn’
   auto v1 = cilk_spawn f();
  ^


#include   
#include   

struct A {  
  A() = default;

  A(const A&) {} // uncomment and it works  

  // A(A &&) {} // broken for move constructors also
};  

A f() { 
  return A{};   
}   

void compute_cilk() {   
  auto v1 = cilk_spawn f(); 
  auto v2 = f();
  cilk_sync;
}   

int main() {
  compute_cilk();   
  return 0; 
} 

[Bug c++/67411] [5/6 Regression] internal compiler error: in tsubst_copy, at cp/pt.c:13473

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67411

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Mon Dec 21 01:52:00 2015
New Revision: 231868

URL: https://gcc.gnu.org/viewcvs?rev=231868=gcc=rev
Log:
PR c++/67411

* decl2.c (decl_maybe_constant_var_p): A proxy isn't constant.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp1y/lambda-generic-const1.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/decl2.c

[Bug tree-optimization/64910] tree reassociation results in poor code

[law at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64910

--- Comment #2 from Jeffrey A. Law  ---
Author: law
Date: Mon Dec 21 04:49:02 2015
New Revision: 231871

URL: https://gcc.gnu.org/viewcvs?rev=231871=gcc=rev
Log:
PR tree-optimization/64910
* config/i386/i386.md (testqi_ext_3): Allow HImode.

PR tree-optimization/64910
* gcc.target/i386/bittest.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/bittest.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/68995] Including both and can cause ADL problems in std::function SFINAE

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68995

--- Comment #1 from Andrew Pinski  ---
I think TR1 is considered as non-supported now.

[Bug target/36925] "3.5 malloc(), vec_malloc(), and new" part of the Alivec PIM is not implemented

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36925

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug boehm-gc/66848] boehm-gc fails test suite on x86_64-apple-darwin15

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66848

--- Comment #23 from Dominique d'Humieres  ---
> Yes. If you apply the ugly hack from comment 11, you will find that it fixes
> both the boehm-gc test suite regressions as well as those in the libjava test
> suite (which are due to the breakage in boehm-gc used by libjava).

Yes it does. This should probably also be done for the 5 branch (I see the same
failures).

[Bug c++/67411] [5/6 Regression] internal compiler error: in tsubst_copy, at cp/pt.c:13473

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67411

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Sun Dec 20 18:38:37 2015
New Revision: 231863

URL: https://gcc.gnu.org/viewcvs?rev=231863=gcc=rev
Log:
PR c++/67411

* lambda.c (generic_lambda_fn_p): Split out from...
(maybe_add_lambda_conv_op): ...here.
* semantics.c (process_outer_var_ref): Don't defer maybe-constant
variables in a generic lambda.
* pt.c (instantiate_non_dependent_or_null): New.
* init.c (constant_value_1): Use it.
* cp-tree.h: Declare it and generic_lambda_fn_p.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-const2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/init.c
trunk/gcc/cp/lambda.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/semantics.c

[Bug c++/67411] [5/6 Regression] internal compiler error: in tsubst_copy, at cp/pt.c:13473

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67411

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Sun Dec 20 18:38:30 2015
New Revision: 231862

URL: https://gcc.gnu.org/viewcvs?rev=231862=gcc=rev
Log:
PR c++/67411

* decl2.c (decl_maybe_constant_var_p): A proxy isn't constant.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-const1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c

[Bug fortran/68993] MERGE does not evaluate its arguments

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68993

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-12-20
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
> I believe that this PR should be closed with INVALID.

I agree.

IIRC there have been similar discussion about

WRITE(6,*) foo()+foo()

but I am too lazy to dig the archives!

[Bug boehm-gc/66848] boehm-gc fails test suite on x86_64-apple-darwin15

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66848

--- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #23 from Dominique d'Humieres  ---
>> Yes. If you apply the ugly hack from comment 11, you will find that it fixes
>> both the boehm-gc test suite regressions as well as those in the libjava test
>> suite (which are due to the breakage in boehm-gc used by libjava).
>
> Yes it does. This should probably also be done for the 5 branch (I see the 
> same
> failures).

For me (on Mac OS X 10.11.1), the hack fixes the boehm-gc failures, but
the libjava ones remain.

Rainer

[Bug rtl-optimization/68910] [5/6 regression] huge stack frame and poor code with instruction scheduling at -O2

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68910

--- Comment #15 from Eric Botcazou  ---
> The stack frame is still larger than necessary at least on the -mcpu=cypress
> and -mcpu=leon3 targets. However, the range is similar to GCC 4.3.2, so this
> looks like an old problem.

Yes, it's the init-regs.c thing, see PR rtl-optimization/68641.

[Bug fortran/68993] MERGE does not evaluate its arguments

[Joost.VandeVondele at mat dot ethz.ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68993

Joost VandeVondele  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch
 Resolution|--- |INVALID

--- Comment #3 from Joost VandeVondele  
---
I believe there was some confusion about the second testcase. The real question
is if this is valid in all cases:

MERGE(C_NULL_PTR, C_LOC(pc), .NOT.PRESENT(pc)))

and I believe it is not, because all arguments might be evaluated. However, it
is also OK not to evaluate all arguments for the reasons quoted.

[Bug rtl-optimization/68910] [5/6 regression] huge stack frame and poor code with instruction scheduling at -O2

[sebastian.hu...@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68910

--- Comment #14 from Sebastian Huber  ---
(In reply to Eric Botcazou from comment #13)
> Thanks for reporting the problem.

Thanks for the quick fix.

The stack frame is still larger than necessary at least on the -mcpu=cypress
and -mcpu=leon3 targets. However, the range is similar to GCC 4.3.2, so this
looks like an old problem.

sparc-rtems4.12-gcc -S -O2 sha512c.i -mcpu=leon3

.file   "sha512c.i"
.section".text"
.align 4
.global SHA512_Transform
.type   SHA512_Transform, #function
.proc   020
SHA512_Transform:
save%sp, -2760, %sp
mov 128, %o2
mov %i1, %o1
add %fp, -640, %o0
callmemcpy, 0
 st %i0, [%fp+68]
add %fp, -640, %g4
add %fp, -128, %o4
ld  [%g4+116], %i1
.LL8:
[...]
bne .LL7
 add%fp, -704, %o3
jmp %i7+8
 restore
.size   SHA512_Transform, .-SHA512_Transform
.ident  "GCC: (GNU) 6.0.0 20151221 (experimental)

Your reduced test case gcc.target/sparc/20151219-1.c doesn't show this large
stack frame.

[Bug target/64402] mep-elf ICE in pre_and_rev_post_order_compute, at cfganal.c:1022

[bernd.edlinger at hotmail dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64402

Bernd Edlinger  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #2 from Bernd Edlinger  ---
can you try this?


Index: mep.c
===
--- mep.c   (Revision 231696)
+++ mep.c   (Arbeitskopie)
@@ -3004,11 +3004,9 @@
 emit_insn (gen_mep_enable_int ());

   if (mep_prevent_lp_restore)
-{
-  emit_jump_insn (gen_eh_return_internal ());
-  emit_barrier ();
-}
-  else if (interrupt_handler)
+return;
+
+  if (interrupt_handler)
 emit_jump_insn (gen_mep_reti ());
   else
 emit_jump_insn (gen_return_internal (gen_rtx_REG (SImode, lp_temp)));
@@ -3025,6 +3023,8 @@
 }

   emit_insn (gen_eh_epilogue (operands[0]));
+  emit_jump_insn (gen_eh_return_internal ());
+  emit_barrier ();
 }

 void

[Bug bootstrap/67598] [6 Regression] Target powerpc-e500v2-linux-gnuspe failed to bootstrap

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67598

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #5 from Jakub Jelinek  ---
.