[Bug fortran/71087] scipy amos crash

2016-05-15 Thread nickpapior at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71087

--- Comment #11 from Nick  ---
Created attachment 38492
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38492&action=edit
make check output

I recompiled gcc on the Opteron6136 machine.
I ran the test-suite:
  make -k check > test.out
Doing:
  grep -e FAIL -e ERROR test.out
only returns two lines. Those lines only appear due to "WERROR=" lines.

I also tried:
  gcc -O2 -march=opteron -c zunhj.f
to no avail.

All-in-all, the bug persists. :(
I have attached the gz of the make check.

[Bug c/71120] New: Aliasing "struct sockaddr_storage" produces invalid code

2016-05-15 Thread bernat at luffy dot cx 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71120

Bug ID: 71120
   Summary: Aliasing "struct sockaddr_storage" produces invalid
code
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernat at luffy dot cx
  Target Milestone: ---

Hello,

Starting with gcc-6, the following code (PoC found by Cyril Bonté) will produce
an unexpected result:

#include 
#include 
#include 
#include 
#include 

struct dbg_listener {
struct sockaddr_storage addr;
};

int main(int argc, char **argv)
{
struct dbg_listener *l;
struct sockaddr_storage ss, *ss2, ss3;

memset(&ss3, 0, sizeof(ss3));
ss3.ss_family = AF_INET;
((struct sockaddr_in *)&ss3)->sin_addr.s_addr = inet_addr("127.0.0.1");

ss2 = &ss3;

ss = *ss2;

l = calloc(1, sizeof(*l));
l->addr = ss;

printf("%x\n", ntohl(((struct sockaddr_in
*)(&l->addr))->sin_addr.s_addr));
exit(0);
}

This is a common pattern when handling socket addresses in a generic way. Even
when the code is compiled with -fno-strict-aliasing, the output is 0 while it
should be 7f01.

$ gcc-6 -O2 -Wall -fno-strict-aliasing debug.c -o debug && ./debug
0

Using -O0 fixes the problem. Fixing the aliasing violation with an union fixes
the problem too. Using -fno-tree-sra fixes the problem too. Compiling with
gcc-5.3.1 fixes the problem too.

Here is a good starting point for the context of this bug (in HAProxy):
http://article.gmane.org/gmane.comp.web.haproxy/27924

[Bug rtl-optimization/67609] [5 Regression] Generates wrong code for SSE2 _mm_load_pd

2016-05-15 Thread ebotcazou at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67609

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #46 from Eric Botcazou  ---
What's the status of this on the 6 branch and mainline?  IIUC the doc change
for CANNOT_CHANGE_MODE_CLASS is still there and the aarch64 port implements it,
but not the x86-64 port?  Should the doc change be reverted too, as well as the
aarch64 change as suggested by Richard S. in comment 43?

[Bug c++/71121] New: Spurious warning: "the address of [...] will never be NULL [-Waddress]"

2016-05-15 Thread ogoffart at kde dot org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71121

Bug ID: 71121
   Summary: Spurious warning: "the address of [...] will never be
NULL [-Waddress]"
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ogoffart at kde dot org
  Target Milestone: ---

Regression in GCC 6:
The following code display a spurious warning about 
the addess of CC::mbr never being NULL despite it is not 
compared to null.

--

struct CC { void mbr(); };

constexpr auto getFunc() {
return &CC::mbr;
}

constexpr bool xxx(void (CC::*_a)())
{
constexpr auto f = getFunc();
return (f == _a);
}

---

shows a warning:

warning: the address of ‘void CC::mbr()’ will never be NULL [-Waddress]
 return (f == _a);
 ~~^

Live: http://melpon.org/wandbox/permlink/rPO9BmmGL8RxNsTI

[Bug other/71122] New: 'make distclean' should not try to remove libiberty/testsuite dir

2016-05-15 Thread sourceforge.brock at dse dot nl 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71122

Bug ID: 71122
   Summary: 'make distclean' should not try to remove
libiberty/testsuite dir
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sourceforge.brock at dse dot nl
  Target Milestone: ---

When doing make distclean the Makefile tries to rmdir libiberty/testsuite.
However this directory and its contents are under source control. Someone tried
to suppress the error that this dir cannot be removed by redirecting stderr to
/dev/null and by prepending the rmdir command with a dash (-rmdir). But why so
difficult? And it still generates:

rmdir testsuite 2>/dev/null
Makefile:458: recipe for target 'distclean' failed
make[3]: [distclean] Error 1 (ignored)

Would it not be better to just remove the rmdir line from the Makefile? Putting
its contents under source control seems to indicate you wish to keep it.

Kind regards,
Maarten Brock
SDCC developer

[Bug fortran/71087] scipy amos crash

2016-05-15 Thread nickpapior at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71087

Nick  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #12 from Nick  ---
Sorry, never mind.

The previous check was made against the wrong compiler installation.

It now works. :(

I had always used the same installation procedure, but I guess never gcc
versions allow more advanced optimizations per-default.

Sorry for the blurp. :(

[Bug fortran/70959] [6/7 Regression] Invalid type determination due to expression in a type declaration statement

2016-05-15 Thread jvdelisle at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70959

--- Comment #3 from Jerry DeLisle  ---
I have tried changing the matching order so that integer constants are matched
before real or complex.  It fixes the reported problem but results in numerous
test suite failures.

I wonder. If we just change the warning message to "possible change of value in
conversion ...  " would this be sufficient?  It is only a warning.  Otherwise
we will have to work on some fairly intricate code.  The revision mentioned in
comment #2 only added the warning feature, it did not change the matching
codes.

[Bug fortran/69603] [5/6/7 Regression] ICE: segfault with -fimplicit-none and proc_ptr_comp_24.f90

2016-05-15 Thread kargl at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69603

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sun May 15 18:34:57 2016
New Revision: 236253

URL: https://gcc.gnu.org/viewcvs?rev=236253&root=gcc&view=rev
Log:
2016-05-15  Harald Anlauf  

PR fortran/69603
* interface.c (compare_parameter): Check for non-NULL pointer.

2016-05-15  Harald Anlauf  

PR fortran/69603
* gfortran.dg/pr69603.f90: New testcase.

Added:
trunk/gcc/testsuite/gfortran.dg/pr69603.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/testsuite/ChangeLog

[Bug libfortran/71123] New: Namelist read failure on Windows

2016-05-15 Thread jvdelisle at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71123

Bug ID: 71123
   Summary: Namelist read failure on Windows
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jvdelisle at gcc dot gnu.org
  Target Milestone: ---

Posted on the gfortran list.

The following program works fine under Linux but fails under Windows.

  IMPLICIT REAL*8(A-H,O-Z)
  DIMENSION SENID(30)
  NAMELIST /FITH/ SENID
  DO I=1,30
 SENID(I) = I
  ENDDO
  OPEN(UNIT=7,FILE='TEST.OUT',FORM='FORMATTED',
 * STATUS='NEW',ACTION='READWRITE')
  WRITE(7,NML=FITH)
  REWIND(7)
  READ(7,NML=FITH)
  END

[Bug fortran/69603] [5/6/7 Regression] ICE: segfault with -fimplicit-none and proc_ptr_comp_24.f90

2016-05-15 Thread kargl at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69603

--- Comment #6 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sun May 15 18:48:40 2016
New Revision: 236254

URL: https://gcc.gnu.org/viewcvs?rev=236254&root=gcc&view=rev
Log:
2016-05-15  Harald Anlauf  

PR fortran/69603
* interface.c (compare_parameter): Check for non-NULL pointer.

2016-05-15  Harald Anlauf  

PR fortran/69603
* gfortran.dg/pr69603.f90: New testcase.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr69603.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/interface.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug libfortran/71123] Namelist read failure on Windows

2016-05-15 Thread jvdelisle at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71123

Jerry DeLisle  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org

--- Comment #1 from Jerry DeLisle  ---
I will investigate.

[Bug rtl-optimization/71118] [5,6,7 Regression] ftois instruction not emitted for float -> int bitcast

2016-05-15 Thread ubizjak at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71118

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-15
 CC||segher at gcc dot gnu.org,
   ||ubizjak at gmail dot com
  Component|target  |rtl-optimization
Summary|[5 Regression] ftois|[5,6,7 Regression] ftois
   |instruction not emitted for |instruction not emitted for
   |float -> int bitcast|float -> int bitcast
 Ever confirmed|0   |1

--- Comment #2 from Uroš Bizjak  ---
Looks like a regression in the combine pass.

When compiling f2i, 4.9 is able to combine:

(insn 2 4 3 2 (set (reg/v:SF 72 [ f ])
(reg:SF 48 $f16 [ f ])) ftois.c:11 220 {*movsf}
 (expr_list:REG_DEAD (reg:SF 48 $f16 [ f ])
(nil)))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(insn 6 3 11 2 (set (reg:DI 74 [ f ])
(sign_extend:DI (subreg:SI (reg/v:SF 72 [ f ]) 0))) ftois.c:13 2
{*extendsidi2_1}
 (expr_list:REG_DEAD (reg/v:SF 72 [ f ])
(nil)))

to:

Trying 2 -> 6:
Successfully matched this instruction:
(set (reg:DI 74 [ f ])
(sign_extend:DI (subreg:SI (reg:SF 48 $f16 [ f ]) 0)))

...

(insn 6 3 11 2 (set (reg:DI 74 [ f ])
(sign_extend:DI (subreg:SI (reg:SF 48 $f16 [ f ]) 0))) ftois.c:13 2
{*extendsidi2_1}
 (expr_list:REG_DEAD (reg:SF 48 $f16 [ f ])
(nil)))


However, gcc version 5+ chickens out for some reason:

Trying 2 -> 6:
starting the processing of deferred insns
ending the processing of deferred insns

...

(insn 2 4 3 2 (set (reg/v:SF 71 [ f ])
(reg:SF 48 $f16 [ f ])) ftois.c:11 220 {*movsf}
 (expr_list:REG_DEAD (reg:SF 48 $f16 [ f ])
(nil)))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(insn 6 3 11 2 (set (reg:DI 73 [ f ])
(sign_extend:DI (subreg:SI (reg/v:SF 71 [ f ]) 0))) ftois.c:13 2
{*extendsidi2_1}
 (expr_list:REG_DEAD (reg/v:SF 71 [ f ])
(nil)))

Confirmed as a rtl-optimization problem, combine expert CC'd.

[Bug rtl-optimization/71118] [5,6,7 Regression] ftois instruction not emitted for float -> int bitcast

2016-05-15 Thread ubizjak at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71118

Uroš Bizjak  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug rtl-optimization/71119] [4.9,5,6,7 Regression] ftoit instruction not emitted for double -> long bitcast

2016-05-15 Thread ubizjak at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71119

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-15
  Component|target  |rtl-optimization
 Depends on||71118
   Target Milestone|--- |7.0
Summary|[4.9 Regression] ftoit  |[4.9,5,6,7 Regression]
   |instruction not emitted for |ftoit instruction not
   |double -> long bitcast  |emitted for double -> long
   ||bitcast
 Ever confirmed|0   |1

--- Comment #1 from Uroš Bizjak  ---
Probably the same root cause as in PR 71118, for some reason combine pass is
unable to propagate (insn 2) into (insn 10).

(insn 2 4 3 2 (set (reg/v:DF 71 [ f ])
(reg:DF 48 $f16 [ f ])) ftoit.c:16 221 {*movdf}
 (expr_list:REG_DEAD (reg:DF 48 $f16 [ f ])
(nil)))
(note 3 2 10 2 NOTE_INSN_FUNCTION_BEG)
(insn 10 3 11 2 (set (reg/i:DI 0 $0)
(subreg:DI (reg/v:DF 71 [ f ]) 0)) ftoit.c:19 226 {*movdi}
 (expr_list:REG_DEAD (reg/v:DF 71 [ f ])
(nil)))


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71118
[Bug 71118] [5,6,7 Regression] ftois instruction not emitted for float -> int
bitcast

[Bug rtl-optimization/71118] [5,6,7 Regression] ftois instruction not emitted for float -> int bitcast

2016-05-15 Thread segher at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71118

--- Comment #3 from Segher Boessenkool  ---
Okay, looking...

[Bug target/21530] libstdc++ not supported on h8

2016-05-15 Thread yselkowi at redhat dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21530

Yaakov Selkowitz  changed:

   What|Removed |Added

 CC||yselkowi at redhat dot com

--- Comment #9 from Yaakov Selkowitz  ---
This is also an issue with h8300-elf in GCC 6 (but not in later 4.x or 5) due
to r232454.

[Bug c++/70862] [concepts] adding a concept-constrained version of a variable template causes multiple definition assembler error

2016-05-15 Thread tom at honermann dot net 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70862

Tom Honermann  changed:

   What|Removed |Added

 CC||tom at honermann dot net

--- Comment #2 from Tom Honermann  ---
This looks to be a duplicate of bug 70095.

[Bug c++/70037] [concepts] comdat group error and an ICE with a conceptified tuple implementation

2016-05-15 Thread tom at honermann dot net 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70037

Tom Honermann  changed:

   What|Removed |Added

 CC||tom at honermann dot net

--- Comment #2 from Tom Honermann  ---
This error was also reported in bug 69515 comment 2.

[Bug c++/69515] partial specialization of variable templates is broken

2016-05-15 Thread tom at honermann dot net 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69515

--- Comment #3 from Tom Honermann  ---
The error in comment 2 was also reported in bug 69364.

[Bug target/71124] New: Compiler enters infinite loop on Microblaze with -O1/-O2/-O3

2016-05-15 Thread thomas.petazz...@free-electrons.com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71124

Bug ID: 71124
   Summary: Compiler enters infinite loop on Microblaze with
-O1/-O2/-O3
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomas.petazz...@free-electrons.com
  Target Milestone: ---

Created attachment 38493
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38493&action=edit
Test case

The attached preprocessed C++ file (generated from the assimp project) causes
g++ 4.9.3 to enter an infinite loop if an optimization level of -O1, -O2 or -O3
is used. With no optimization flags, or with the -Os flag, the compiler works
fine.

I.e:

microblazeel-linux-g++ -O1 -c test.cpp
microblazeel-linux-g++ -O2 -c test.cpp
microblazeel-linux-g++ -O3 -c test.cpp

never terminate.

While:

microblazeel-linux-g++ -c test.cpp
microblazeel-linux-g++ -Os -c test.cpp

terminate properly.

[Bug c++/70862] [concepts] adding a concept-constrained version of a variable template causes multiple definition assembler error

2016-05-15 Thread ryan.burn at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70862

--- Comment #3 from ryan.burn at gmail dot com ---
It's a different bug. The test case from 70095 compiles fine with the trunk
from 20160428, but the above example won't.

[Bug c++/71125] New: [concepts] Spurious 'invalid reference to function concept error' issued when overloads are not all declared with the concept specifier

2016-05-15 Thread tom at honermann dot net 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71125

Bug ID: 71125
   Summary: [concepts] Spurious 'invalid reference to function
concept error' issued when overloads are not all
declared with the concept specifier
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
  Target Milestone: ---

I believe the following code is well-formed.

$ cat t.cpp
// This test case demonstrates a spurious reference to function concept error.
// The error is emitted when:
// 1: a constexpr function is declared without the concept specifier, and
// 2: an overload declared with the concept specifier follows, and
// 3: overload resolution of a function invocation in a requires clause of a
//following constrained function declaration selects the first declaration.

template
constexpr bool C1() { return true; }
template
concept bool C1() { return true; }
template
  requires C1() // spurious error: invalid reference to function concept
‘template constexpr bool C1()’
void f1() {}

// Removing the unused overload avoids the error:
template
constexpr bool C2() { return true; }
template
  requires C2() // Ok.
void f2() {}

// Swapping the order of the declarations avoids the error:
template
concept bool C3() { return true; }
template
constexpr bool C3() { return true; }
template
  requires C3() // Ok.
void f3() {}

// Swapping the overload that is resolved avoids the error:
template
constexpr bool C4() { return true; }
template
concept bool C4() { return true; }
template
  requires C4() // Ok.
void f4() {}

// Swapping which overload is declared with the concept specifier avoids the
error:
template
concept bool C5() { return true; }
template
constexpr bool C5() { return true; }
template
  requires C5() // Ok.
void f5() {}


$ svn info   # From my local svn gcc repo.
Path: .
Working Copy Root Path: /home/tom/src/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 236239
Node Kind: directory
Schedule: normal
Last Changed Author: uros
Last Changed Rev: 236238
Last Changed Date: 2016-05-14 05:07:13 -0400 (Sat, 14 May 2016)


$ g++ --version
g++ (GCC) 7.0.0 20160514 (experimental)
...

$ g++ -c -fconcepts -std=c++1z t.cpp
t.cpp:13:12: error: invalid reference to function concept ‘template constexpr bool C1()’
   requires C1() // spurious error: invalid reference to function concept
‘template constexpr bool C1()’
^

[Bug fortran/69603] [5/6/7 Regression] ICE: segfault with -fimplicit-none and proc_ptr_comp_24.f90

2016-05-15 Thread kargl at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69603

--- Comment #7 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sun May 15 21:01:50 2016
New Revision: 236256

URL: https://gcc.gnu.org/viewcvs?rev=236256&root=gcc&view=rev
Log:
2016-05-15  Harald Anlauf  

PR fortran/69603
* interface.c (compare_parameter): Check for non-NULL pointer.

2016-05-15  Harald Anlauf  

PR fortran/69603
* gfortran.dg/pr69603.f90: New testcase.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr69603.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/interface.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/69603] [5/6/7 Regression] ICE: segfault with -fimplicit-none and proc_ptr_comp_24.f90

2016-05-15 Thread kargl at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69603

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from kargl at gcc dot gnu.org ---
Fixed on 5-branch, 6-branch, and trunk.  Thanks for patch.

[Bug c++/71126] New: [concepts] ICE on ill-formed code declaring a variable with a non-type concept

2016-05-15 Thread tom at honermann dot net 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71126

Bug ID: 71126
   Summary: [concepts] ICE on ill-formed code declaring a variable
with a non-type concept
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
  Target Milestone: ---

The following ill-formed code triggers an ICE in gcc r236239.

$ cat t.cpp
template
concept bool C = N==1;
C c = 1;

$ svn info
Path: .
Working Copy Root Path: /home/tom/src/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 236239
Node Kind: directory
Schedule: normal
Last Changed Author: uros
Last Changed Rev: 236238
Last Changed Date: 2016-05-14 05:07:13 -0400 (Sat, 14 May 2016)

$ g++ --version
g++ (GCC) 7.0.0 20160514 (experimental)
...

$ g++ -c -std=c++1z -fconcepts t.cpp
t.cpp:3:7: internal compiler error: tree check: expected tree_vec, have
error_mark in tsubst, at cp/pt.c:12954
 C c = 1;
   ^
0xff7e0c tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc-trunk/gcc/tree.c:9753
0x6bd076 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc-trunk/gcc/tree.h:3025
0x6bd076 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-trunk/gcc/cp/pt.c:12954
0x6b1a78 tsubst_copy
../../gcc-trunk/gcc/cp/pt.c:14077
0x6b787a tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-trunk/gcc/cp/pt.c:17161
0x6b720b tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-trunk/gcc/cp/pt.c:16176
0x6abfee tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-trunk/gcc/cp/pt.c:15800
0x889617 satisfy_predicate_constraint
../../gcc-trunk/gcc/cp/constraint.cc:1768
0x889617 satisfy_constraint_1
../../gcc-trunk/gcc/cp/constraint.cc:1975
0x88a416 satisfy_constraint
../../gcc-trunk/gcc/cp/constraint.cc:2026
0x6deb08 lookup_and_finish_template_variable
../../gcc-trunk/gcc/cp/pt.c:8715
0x6b87c2 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-trunk/gcc/cp/pt.c:15991
0x6abfee tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-trunk/gcc/cp/pt.c:15800
0x889617 satisfy_predicate_constraint
../../gcc-trunk/gcc/cp/constraint.cc:1768
0x889617 satisfy_constraint_1
../../gcc-trunk/gcc/cp/constraint.cc:1975
0x88a416 satisfy_constraint
../../gcc-trunk/gcc/cp/constraint.cc:2026
0x88b694 constraints_satisfied_p(tree_node*, tree_node*)
../../gcc-trunk/gcc/cp/constraint.cc:2146
0x6eaf3a do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context)
../../gcc-trunk/gcc/cp/pt.c:24065
0x67a9bb cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc-trunk/gcc/cp/decl.c:6606
0x77e62f cp_parser_init_declarator
../../gcc-trunk/gcc/cp/parser.c:18694
...

[Bug c++/71127] New: [concepts] ICE on ill-formed code declaring a variable with a template concept

2016-05-15 Thread tom at honermann dot net 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71127

Bug ID: 71127
   Summary: [concepts] ICE on ill-formed code declaring a variable
with a template concept
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
  Target Milestone: ---

The following ill-formed code triggers an ICE in gcc r236239.

$ cat t.cpp
template class T>
concept bool C = T::value;
C c = 1;

$ svn info
Path: .
Working Copy Root Path: /home/tom/src/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 236239
Node Kind: directory
Schedule: normal
Last Changed Author: uros
Last Changed Rev: 236238
Last Changed Date: 2016-05-14 05:07:13 -0400 (Sat, 14 May 2016)

$ g++ --version
g++ (GCC) 7.0.0 20160514 (experimental)
...

$ g++ -c -std=c++1z -fconcepts t.cpp 
t.cpp:3:7: internal compiler error: tree check: expected tree_vec, have
error_mark in tsubst, at cp/pt.c:12954
 C c = 1;
   ^
0xff7e0c tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc-trunk/gcc/tree.c:9753
0x6bd076 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc-trunk/gcc/tree.h:3025
0x6bd076 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-trunk/gcc/cp/pt.c:12954
0x6b50aa tsubst_qualified_id
../../gcc-trunk/gcc/cp/pt.c:13728
0x6b70a3 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-trunk/gcc/cp/pt.c:16204
0x6abfee tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-trunk/gcc/cp/pt.c:15800
0x889617 satisfy_predicate_constraint
../../gcc-trunk/gcc/cp/constraint.cc:1768
0x889617 satisfy_constraint_1
../../gcc-trunk/gcc/cp/constraint.cc:1975
0x88a416 satisfy_constraint
../../gcc-trunk/gcc/cp/constraint.cc:2026
0x6deb08 lookup_and_finish_template_variable
../../gcc-trunk/gcc/cp/pt.c:8715
0x6b87c2 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-trunk/gcc/cp/pt.c:15991
0x6abfee tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-trunk/gcc/cp/pt.c:15800
0x889617 satisfy_predicate_constraint
../../gcc-trunk/gcc/cp/constraint.cc:1768
0x889617 satisfy_constraint_1
../../gcc-trunk/gcc/cp/constraint.cc:1975
0x88a416 satisfy_constraint
../../gcc-trunk/gcc/cp/constraint.cc:2026
0x88b694 constraints_satisfied_p(tree_node*, tree_node*)
../../gcc-trunk/gcc/cp/constraint.cc:2146
0x6eaf3a do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context)
../../gcc-trunk/gcc/cp/pt.c:24065
0x67a9bb cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc-trunk/gcc/cp/decl.c:6606
0x77e62f cp_parser_init_declarator
../../gcc-trunk/gcc/cp/parser.c:18694
0x77ed29 cp_parser_simple_declaration
../../gcc-trunk/gcc/cp/parser.c:12378
...

[Bug target/71124] Compiler enters infinite loop on Microblaze with -O1/-O2/-O3

2016-05-15 Thread thomas.petazz...@free-electrons.com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71124

Thomas Petazzoni  changed:

   What|Removed |Added

Version|4.9.3   |6.1.0

--- Comment #1 from Thomas Petazzoni  ---
This bug still exists with gcc 6.1.0, in the same condition (same test case,
same architecture, same optimization levels that work / don't work).

[Bug c++/71128] New: [concepts] ICE on ill-formed explicit instantiation of a function concept

2016-05-15 Thread tom at honermann dot net 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71128

Bug ID: 71128
   Summary: [concepts] ICE on ill-formed explicit instantiation of
a function concept
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
  Target Milestone: ---

The following ill-formed code triggers an ICE in gcc r236239.

$ cat t.cpp
template
concept bool C() { return true; }
template bool C(); // expected error: attempt to explicitly instantiate
// a function concept.

$ svn info
Path: .
Working Copy Root Path: /home/tom/src/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 236239
Node Kind: directory
Schedule: normal
Last Changed Author: uros
Last Changed Rev: 236238
Last Changed Date: 2016-05-14 05:07:13 -0400 (Sat, 14 May 2016)

$ g++ --version
g++ (GCC) 7.0.0 20160514 (experimental)
...

$ g++ -c -std=c++1z -fconcepts t.cpp
t.cpp:3:22: internal compiler error: in instantiate_decl, at cp/pt.c:21666
 template bool C();
  ^
0x6a8c51 instantiate_decl(tree_node*, int, bool)
../../gcc-trunk/gcc/cp/pt.c:21666
0x77751d cp_parser_explicit_instantiation
../../gcc-trunk/gcc/cp/parser.c:15648
0x788c79 cp_parser_declaration
../../gcc-trunk/gcc/cp/parser.c:12095
0x7874b6 cp_parser_declaration_seq_opt
../../gcc-trunk/gcc/cp/parser.c:12022
0x7877c4 cp_parser_translation_unit
../../gcc-trunk/gcc/cp/parser.c:4324
0x7877c4 c_parse_file()
../../gcc-trunk/gcc/cp/parser.c:37475
0x8e7e42 c_common_parse_file()
../../gcc-trunk/gcc/c-family/c-opts.c:1064
...

[Bug c++/71129] New: [concepts] ICE on ill-formed explicit instantiation of a variable concept

2016-05-15 Thread tom at honermann dot net 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71129

Bug ID: 71129
   Summary: [concepts] ICE on ill-formed explicit instantiation of
a variable concept
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
  Target Milestone: ---

The following ill-formed code triggers an ICE in gcc r236239.

$ cat t.cpp
template
concept bool C = true;
template bool C;

$ svn info
Path: .
Working Copy Root Path: /home/tom/src/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 236239
Node Kind: directory
Schedule: normal
Last Changed Author: uros
Last Changed Rev: 236238
Last Changed Date: 2016-05-14 05:07:13 -0400 (Sat, 14 May 2016)

$ g++ --version
g++ (GCC) 7.0.0 20160514 (experimental)
...

$ g++ -c -std=c++1z -fconcepts t.cpp
t.cpp:3:15: internal compiler error: in instantiate_decl, at cp/pt.c:21666
 template bool C;
   ^~
0x6a8c51 instantiate_decl(tree_node*, int, bool)
../../gcc-trunk/gcc/cp/pt.c:21666
0x77751d cp_parser_explicit_instantiation
../../gcc-trunk/gcc/cp/parser.c:15648
0x788c79 cp_parser_declaration
../../gcc-trunk/gcc/cp/parser.c:12095
0x7874b6 cp_parser_declaration_seq_opt
../../gcc-trunk/gcc/cp/parser.c:12022
0x7877c4 cp_parser_translation_unit
../../gcc-trunk/gcc/cp/parser.c:4324
0x7877c4 c_parse_file()
../../gcc-trunk/gcc/cp/parser.c:37475
0x8e7e42 c_common_parse_file()
../../gcc-trunk/gcc/c-family/c-opts.c:1064
...

[Bug target/64400] iq2000-elf: ICE in dwarf2out_var_location, at dwarf2out.c:21266

2016-05-15 Thread yselkowi at redhat dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64400

Yaakov Selkowitz  changed:

   What|Removed |Added

Version|5.2.0   |6.1.0

--- Comment #2 from Yaakov Selkowitz  ---
Issue remains in 6.1.0, now at dwarf2out.c:24439.

[Bug c++/71130] New: [concepts] Ill-formed code declaring a variable with a non-type concept not rejected

2016-05-15 Thread tom at honermann dot net 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71130

Bug ID: 71130
   Summary: [concepts] Ill-formed code declaring a variable with a
non-type concept not rejected
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
  Target Milestone: ---

The following ill-formed code is not rejected as it should be in gcc r236239.

This test case is similar to the one that triggers an ICE in bug 71126.

$ cat t.cpp
template
concept bool C = true;
C c = 1;

$ svn info
Path: .
Working Copy Root Path: /home/tom/src/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 236239
Node Kind: directory
Schedule: normal
Last Changed Author: uros
Last Changed Rev: 236238
Last Changed Date: 2016-05-14 05:07:13 -0400 (Sat, 14 May 2016)

$ g++ --version
g++ (GCC) 7.0.0 20160514 (experimental)
...

$ g++ -c -std=c++1z -fconcepts t.cpp; echo $?
0

[Bug c++/71131] New: [concepts] Ill-formed code declaring a variable with a template concept not rejected

2016-05-15 Thread tom at honermann dot net 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71131

Bug ID: 71131
   Summary: [concepts] Ill-formed code declaring a variable with a
template concept not rejected
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
  Target Milestone: ---

The following ill-formed code is not rejected as it should be in gcc r236239.

This test case is similar to the one that triggers an ICE in bug 71127.

$ cat t.cpp
template class T>
concept bool C = true;
C c = 1;

$ svn info
Path: .
Working Copy Root Path: /home/tom/src/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 236239
Node Kind: directory
Schedule: normal
Last Changed Author: uros
Last Changed Rev: 236238
Last Changed Date: 2016-05-14 05:07:13 -0400 (Sat, 14 May 2016)

$ g++ --version
g++ (GCC) 7.0.0 20160514 (experimental)
...

$ g++ -c -std=c++1z -fconcepts t.cpp; echo $?
0

[Bug target/64375] m32c ICE building newlib in calls.cL3638

2016-05-15 Thread yselkowi at redhat dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64375

--- Comment #2 from Yaakov Selkowitz  ---
Still not working with 6.1.0 m32c-elf at calls.c:3679.

[Bug tree-optimization/71132] New: gcc ICE at -O3 on valid code on x86_64-linux-gnu with “seg fault”

2016-05-15 Thread helloqirun at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71132

Bug ID: 71132
   Summary: gcc ICE at -O3 on valid code on x86_64-linux-gnu with
“seg fault”
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helloqirun at gmail dot com
  Target Milestone: ---

The following valid code causes an ICE when compiled with the current gcc trunk
at only -O3 on x86_64-linux-gnu in both 32-bit and 64-bit modes.

It appears to be a 7 regression.

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 7.0.0 20160515 (experimental) [trunk revision 236250] (GCC) 



$ gcc-trunk -O3 abc.c
abc.c: In function ‘main’:
abc.c:6:5: internal compiler error: Segmentation fault
 int main() {
 ^~~~
0xbaa52f crash_signal
../../gcc/gcc/toplev.c:333
0xbe18e0 bb_seq_addr
../../gcc/gcc/gimple.h:1654
0xbe18e0 gsi_last_bb
../../gcc/gcc/gimple-iterator.h:163
0xbe18e0 last_stmt(basic_block_def*)
../../gcc/gcc/tree-cfg.c:2640
0xc38900 create_edge_for_control_dependence
../../gcc/gcc/tree-loop-distribution.c:282
0xc39bb6 create_rdg_cd_edges
../../gcc/gcc/tree-loop-distribution.c:327
0xc39bb6 build_rdg
../../gcc/gcc/tree-loop-distribution.c:458
0xc39f0b distribute_loop
../../gcc/gcc/tree-loop-distribution.c:1418
0xc3cdc7 execute
../../gcc/gcc/tree-loop-distribution.c:1791
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

$ cat abc.c
typedef unsigned size_t;
struct {
  unsigned char buf[sizeof(long)];
} a;
size_t b;
int main() {
  size_t c, i;
  unsigned char *d;
  for (; c < sizeof(long);) {
d = a.buf;
b = 0;
for (; b < i; b++)
  *d++ = '\0';
for (; c < b; c++)
  *d++ = 'a';
c = 0;
for (; i < sizeof(long); i++)
  ;
  }
}

[Bug libstdc++/71133] New: msp430-elf -mlarge FTBFS in libstdc++-v3

2016-05-15 Thread yselkowi at redhat dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71133

Bug ID: 71133
   Summary: msp430-elf -mlarge FTBFS in libstdc++-v3
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yselkowi at redhat dot com
  Target Milestone: ---

Building gcc 6.1.0 with newlib 2.4.0 for target msp430-elf fails during
configure-target-libstdc++-v3 in the 'large' multilib:

checking how size_t is mangled... x
configure: error: Unknown underlying type for size_t

Where the relevant information that GLIBCXX_CHECK_SIZE_T_MANGLING doesn't know
how to handle appears to be:

#define __SIZE_TYPE__ __int20 unsigned

[Bug rtl-optimization/71118] [5,6,7 Regression] ftois instruction not emitted for float -> int bitcast

2016-05-15 Thread segher at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71118

--- Comment #4 from Segher Boessenkool  ---
This is caused by https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01445.html .

After the change, the hard (argument) register is no longer propagated
into the (set (int reg) (subreg of fp reg)), and then IRA puts the fp
reg in memory.

We should find a way to express the conversion in a way that we can
match it to its own instruction (it matches the generic integer pattern
now, nothing looks inside the subreg), or if it has to go through memory,
do that at expand time already.

[Bug c++/68807] operator->* returning a temporary T will in some cases be treated as returning an lvalue

2016-05-15 Thread adrianbibbywalther at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68807

Adrian Bibby Walther  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Adrian Bibby Walther  
---
The attached code case seems to compile successfully in 6.1.0

[Bug c++/71092] [6/7 Regression] ICE: in cxx_eval_call_expression, at cp/constexpr.c:1449; only with -Os

2016-05-15 Thread schoko.teddy at web dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71092

schoko.teddy at web dot de changed:

   What|Removed |Added

 CC||schoko.teddy at web dot de

--- Comment #3 from schoko.teddy at web dot de ---
Created attachment 38494
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38494&action=edit
Preprocessed source

This Error occurs while compiling this motioncontrollayer.cpp file from a Qt
project. Gzipped because of largeness.

[Bug c++/71092] [6/7 Regression] ICE: in cxx_eval_call_expression, at cp/constexpr.c:1449; only with -Os

2016-05-15 Thread schoko.teddy at web dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71092

--- Comment #4 from schoko.teddy at web dot de ---
(In reply to schoko.teddy from comment #3)
> Created attachment 38494 [details]
> Preprocessed source
> 
> This Error occurs while compiling this motioncontrollayer.cpp file from a Qt
> project. Gzipped because of largeness.

Oh, and the console output (I tried different -O values, all crashing):

g++ -c -pipe -O2 -march=x86-64 -mtune=generic -O2 -pipe
-fstack-protector-strong -flto -std=gnu++0x -Wall -W -D_REENTRANT -fPIC
-DQT_USE_QSTRINGBUILDER -DQT_STRICT_ITERATORS -DPACKAGE_VERSION=3.1.0
-DPACKAGE_NAME=turag-console -DSIM -DSIMULATION -DTURAG_DEBUG_ENABLE_BINARY
-DQWT_DLL -DQT_NO_DEBUG -DQT_PRINTSUPPORT_LIB -DQT_MULTIMEDIAWIDGETS_LIB
-DQT_SVG_LIB -DQT_WIDGETS_LIB -DQT_MULTIMEDIA_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB
-DQT_SERIALPORT_LIB -DQT_XML_LIB -DQT_CORE_LIB -I../Console -I.
-Itina-platform/public -I../Console -I../../../libs
-I../../../libs/libsimeurobot/plugin -I../../Debug-Server -I../../Debug-Server
-I../../../src/common -I../../../tina -I../../../tina/platform/desktop/public
-isystem /usr/include/qwt -isystem /usr/include/qt -isystem
/usr/include/qt/QtPrintSupport -isystem /usr/include/qt/QtMultimediaWidgets
-isystem /usr/include/qt/QtSvg -isystem /usr/include/qt/QtWidgets -isystem
/usr/include/qt/QtMultimedia -isystem /usr/include/qt/QtGui -isystem
/usr/include/qt/QtNetwork -isystem /usr/include/qt/QtSerialPort -isystem
/usr/include/qt/QtXml -isystem /usr/include/qt/QtCore -I.
-I/usr/lib/qt/mkspecs/linux-g++ -o motioncontrollayer.o
../../../libs/libsimeurobot/vis/motioncontrollayer.cpp

In file included from ../../../libs/libsimeurobot/vis/motioncontrollayer.h:7:0,
 from ../../../libs/libsimeurobot/vis/motioncontrollayer.cpp:1:
../../../libs/libsimeurobot/vis/debugobjects.h: In constructor
'TURAG::SimEurobot::Debug::DriveSplineV1::DriveSplineV1()':
../../../libs/libsimeurobot/vis/debugobjects.h:108:8:   in constexpr expansion
of 'TURAG::Pose()'
../../../tina/tina++/geometry/geometry.h:167:20:   in constexpr expansion of
'((TURAG::Pose*)this)->TURAG::Pose::x.TURAG::Units::Quantity::Quantity(0)'
../../../tina/tina++/geometry/units/unit.h:185:42:   in constexpr expansion of
'TURAG::Units::detail::toValue(val)'
../../../libs/libsimeurobot/vis/debugobjects.h:108:8: internal compiler error:
in cxx_eval_call_expression, at cp/constexpr.c:1449
 struct DriveSplineV1 {
^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Makefile:3342: recipe for target 'motioncontrollayer.o' failed
make: *** [motioncontrollayer.o] Error 1


So here we have our ICE in cxx_eval_call_expression etc.

[Bug bootstrap/71134] New: GCC fails to build with in-tree dependencies:

2016-05-15 Thread dcollinsn at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71134

Bug ID: 71134
   Summary: GCC fails to build with in-tree dependencies:
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcollinsn at gmail dot com
  Target Milestone: ---

The folder ~/toolchain/gcc-6.1.0 is the unzipped GCC source distribution. I
have extracted into that folder the contents of binutils-2.26.tar.gz,
gmp-6.1.0.tar.xz, mpc-1.0.3.tar.gz, mpfr-3.1.4.tar.gz, and isl-0.16.1.tar.bz2.
All were extracted to their own folders (gcc-6.1.0/gmp/, etc) with the
exception of binutils, which was extracted directly into the source directory.
The folder ~/toolchain/gcc-build is a separate, empty build directory. 

The platform is Debian Stretch, otherwise up to date, running inside VMware.

I have configured using the following instructions. --enable-shared and
--enable-host-shared are to attempt to fix a separate bug. I accept the default
languages. I have also deleted all instances of --disable-shared in Makefile.in
because I was getting similar issues as in Bug 67137, despite the "jit"
language not being selected.

dcollins@nightshade64:~/toolchain/gcc-build$ ../gcc-6.1.0/configure
--program-suffix=-6.1 --enable-shared --enable-host-shared

dcollins@nightshade64:~/toolchain/gcc-build$ make 

Configuring stage 2 in ./libiberty
configure: loading cache ./config.cache
checking whether to enable maintainer-specific portions of Makefiles... no
checking for makeinfo... makeinfo --split-size=500 --split-size=500
checking for perl... perl
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for x86_64-pc-linux-gnu-ar... ar
checking for x86_64-pc-linux-gnu-ranlib... ranlib
checking whether to install libiberty headers and static library... no
configure: target_header_dir =
checking for x86_64-pc-linux-gnu-gcc... 
/home/dcollins/toolchain/gcc-build/./prev-gcc/xgcc
-B/home/dcollins/toolchain/gcc-build/./prev-gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/bin/
-B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem
/usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include
-L/home/dcollins/toolchain/gcc-build/./ld
checking for suffix of object files... configure: error: in
`/home/dcollins/toolchain/gcc-build/libiberty':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
Makefile:16209: recipe for target 'configure-stage2-libiberty' failed
make[2]: *** [configure-stage2-libiberty] Error 1
make[2]: Leaving directory '/home/dcollins/toolchain/gcc-build'
Makefile:29946: recipe for target 'stage2-bubble' failed
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory '/home/dcollins/toolchain/gcc-build'
Makefile:916: recipe for target 'all' failed
make: *** [all] Error 2


dcollins@nightshade64:~/toolchain/gcc-build$ cat libiberty/config.log

## --- ##
## Core tests. ##
## --- ##

configure:2334: loading cache ./config.cache
configure:2493: checking whether to enable maintainer-specific portions of
Makefiles
configure:2503: result: no
configure:2518: checking for makeinfo
configure:2545: result: makeinfo --split-size=500 --split-size=500
configure:2585: checking for perl
configure:2601: found /usr/bin/perl
configure:2612: result: perl
configure:2631: checking build system type
configure:2645: result: x86_64-pc-linux-gnu
configure:2665: checking host system type
configure:2678: result: x86_64-pc-linux-gnu
configure:2703: checking for x86_64-pc-linux-gnu-ar
configure:2730: result: ar
configure:2795: checking for x86_64-pc-linux-gnu-ranlib
configure:2822: result: ranlib
configure:2907: checking whether to install libiberty headers and static
library
configure:2930: result: no
configure:2932: target_header_dir =
configure:2944: checking for x86_64-pc-linux-gnu-gcc
configure:2971: result:  /home/dcollins/toolchain/gcc-build/./prev-gcc/xgcc
-B/home/dcollins/toolchain/gcc-build/./prev-gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/b
in/ -B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem
/usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include
-L/home/dcollins/toolchain/gcc-build/./ld
configure:3240: checking for C compiler version
configure:3249:  /home/dcollins/toolchain/gcc-build/./prev-gcc/xgcc
-B/home/dcollins/toolchain/gcc-build/./prev-gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/bin/
-B/u
sr/local/x86_64-pc-linux-gnu/lib/ -isystem
/usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include
-L/home/dcollins/toolchain/gcc-build/./ld--version >&5
xgcc (GCC) 6.1.0
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for

[Bug libstdc++/71135] New: rl78-elf libstdc++ FTBFS with some multilibs

2016-05-15 Thread yselkowi at redhat dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71135

Bug ID: 71135
   Summary: rl78-elf libstdc++ FTBFS with some multilibs
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yselkowi at redhat dot com
  Target Milestone: ---
  Host: x86_64-cygwin
Target: rl78-elf
 Build: x86_64-cygwin

rl78-elf FTBFS in GCC 6.1 libstdc++-v3 (but not in recent 4.x or 5) due to
r232454:

src/c++11/cow-stdexcept.cc: In function ‘void* txnal_read_ptr(void* const*)’:
src/c++11/cow-stdexcept.cc:274:3: error: static assertion failed: Pointers must
be 32 bits or 64 bits wide
   static_assert(sizeof(uint64_t) == sizeof(void*)
   ^

rl78 has 16-bit pointers.

[Bug c++/71136] New: [concepts] Spurious 'converting overloaded function is ambiguous' error.

2016-05-15 Thread tom at honermann dot net 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71136

Bug ID: 71136
   Summary: [concepts] Spurious 'converting overloaded function is
ambiguous' error.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
  Target Milestone: ---

I believe the following test case is well-formed, but it is rejected by gcc
r236238.

$ cat t.cpp
template
struct is_same {};
template
struct is_same { using type = T; };

// Concept imposes a same-type-as-int constraint.
template
concept bool C = requires { typename is_same::type; };

template
constexpr int f() { return 0; } // #1, unconstrained overload.
template
constexpr int f() { return 1; } // #2, constrained overload.

// Obtaining a function pointer to #1 is ok:
constexpr auto x0 = f;// Ok, overload selects #1
static_assert(x0() == 0);   // Ok.

// Invoking #2 is ok:
constexpr auto x1 = f();   // Ok, overload selects #2
static_assert(x1 == 1); // Ok.

// Obtaining a function pointer to #2 fails:
constexpr auto x2 = f; // spurious error: 'converting overloaded
// function is ambiguous'; should select #2.
static_assert(x2() == 1);

$ svn info
Path: .
Working Copy Root Path: /home/tom/src/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 236239
Node Kind: directory
Schedule: normal
Last Changed Author: uros
Last Changed Rev: 236238
Last Changed Date: 2016-05-14 05:07:13 -0400 (Sat, 14 May 2016)

$ g++ --version
g++ (GCC) 7.0.0 20160514 (experimental)
...

$ g++ -c -std=c++1z -fconcepts t.cpp
t.cpp:24:21: error: converting overloaded function ‘f’ to type ‘int (*
const)()’ is ambiguous
 constexpr auto x2 = f; // spurious error: 'converting overloaded
 ^~
t.cpp:11:15: note: candidates are: constexpr int f() [with U = int]
 constexpr int f() { return 0; } // #1, unconstrained overload.
   ^
t.cpp:13:15: note: constexpr int f() [with U = int]
 constexpr int f() { return 1; } // #2, constrained overload.
   ^
t.cpp:26:1: error: non-constant condition for static assertion
 static_assert(x2() == 1);
 ^

[Bug c++/71137] New: [concepts] Spurious 'symbol is already defined' error issued when declaring a constrained non-template function overload.

2016-05-15 Thread tom at honermann dot net 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71137

Bug ID: 71137
   Summary: [concepts] Spurious 'symbol is already defined' error
issued when declaring a constrained non-template
function overload.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
  Target Milestone: ---

I believe the following test case is well-formed; the Concepts TS has similar
examples (§ 13.4p4).  However, compiling this code results in a duplicate
definition error in gcc r236238.

$ cat t.cpp
void f() {}
void f() requires true {}

$ svn info
Path: .
Working Copy Root Path: /home/tom/src/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 236239
Node Kind: directory
Schedule: normal
Last Changed Author: uros
Last Changed Rev: 236238
Last Changed Date: 2016-05-14 05:07:13 -0400 (Sat, 14 May 2016)

$ g++ --version
g++ (GCC) 7.0.0 20160514 (experimental)
...

$ g++ -c -std=c++1z -fconcepts t.cpp 
/tmp/ccONCRCJ.s: Assembler messages:
/tmp/ccONCRCJ.s:22: Error: symbol `_Z1fv' is already defined

[Bug c++/71138] New: [concepts] ill-formed non-constant expression use in nested requirement produces duplicated diagnostics with poor source locations

2016-05-15 Thread tom at honermann dot net 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71138

Bug ID: 71138
   Summary: [concepts] ill-formed non-constant expression use in
nested requirement produces duplicated diagnostics
with poor source locations
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
  Target Milestone: ---

The following test case is ill-formed and gcc r236238 correctly rejects it. 
However, duplicate diagnostic are issued and the diagnostics fail to identify
the problematic source code.

The test case contains two instances of constraint satisfaction failures
labeled #1 and #2.  The first occurs in a static_assert and produces a single
error message.  The second occurs in overload resolution and produces three
duplicate error messages.

None of the diagnostics produce identify the problematic source code annotated
in the test case.

$ cat t.cpp
template
constexpr bool p(T) { return true; }
template
concept bool C = requires(T t) {
requires p(t); // An error should be reported here.
};

static_assert(C); // #1: error: ‘t’ is not a constant expression

template
int f(T) { return 1; }
auto x = f(1); // #2: (3x) error: ‘t’ is not a constant expression


$ svn info
Path: .
Working Copy Root Path: /home/tom/src/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 236239
Node Kind: directory
Schedule: normal
Last Changed Author: uros
Last Changed Rev: 236238
Last Changed Date: 2016-05-14 05:07:13 -0400 (Sat, 14 May 2016)

$ g++ --version
g++ (GCC) 7.0.0 20160514 (experimental)
...

$ g++ -c -std=c++1z -fconcepts t.cpp
t.cpp:8:15: error: ‘t’ is not a constant expression
 static_assert(C); // #1: error: ‘t’ is not a constant expression
   ^~
t.cpp:12:13: error: ‘t’ is not a constant expression
 auto x = f(1); // #2: (3x) error: ‘t’ is not a constant expression
 ^
t.cpp:12:13: error: ‘t’ is not a constant expression
t.cpp:12:13: error: cannot call function ‘int f(T) [with T = int]’
t.cpp:11:5: note:   constraints not satisfied
 int f(T) { return 1; }
 ^
t.cpp:12:13: error: ‘t’ is not a constant expression
 auto x = f(1); // #2: (3x) error: ‘t’ is not a constant expression
 ^
t.cpp:11:5: note:   concept ‘C’ was not satisfied
 int f(T) { return 1; }
 ^

[Bug c++/71139] New: [concepts] ill-formed compound-requirement lacking a semicolon not rejected

2016-05-15 Thread tom at honermann dot net 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71139

Bug ID: 71139
   Summary: [concepts] ill-formed compound-requirement lacking a
semicolon not rejected
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
  Target Milestone: ---

The following ill-formed code is not rejected by gcc r236238.  According to the
Concepts TS § 5.1.4.3, the compound-requirement must include a terminating
semicolon.

$ cat a.cpp 
template
concept bool C = requires(T t) {
{ +t }
};  // expected error: expected ‘;’ before ‘}’ token
static_assert(C);

$ svn info
Path: .
Working Copy Root Path: /home/tom/src/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 236239
Node Kind: directory
Schedule: normal
Last Changed Author: uros
Last Changed Rev: 236238
Last Changed Date: 2016-05-14 05:07:13 -0400 (Sat, 14 May 2016)

$ g++ --version
g++ (GCC) 7.0.0 20160514 (experimental)
...

$ g++ -c -std=c++1z -fconcepts a.cpp; echo $?
0

[Bug c++/71140] New: [concepts] ill-formed nested-requirement lacking a semicolon not rejected

2016-05-15 Thread tom at honermann dot net 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71140

Bug ID: 71140
   Summary: [concepts] ill-formed nested-requirement lacking a
semicolon not rejected
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
  Target Milestone: ---

The following ill-formed code is not rejected by gcc r236238.  According to the
Concepts TS § 5.1.4.4, the nested-requirement must include a terminating
semicolon.

$ cat a.cpp
template
concept bool C = requires(T t) {
requires true
};  // expected error: expected ‘;’ before ‘}’ token
static_assert(C);

$ svn info
Path: .
Working Copy Root Path: /home/tom/src/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 236239
Node Kind: directory
Schedule: normal
Last Changed Author: uros
Last Changed Rev: 236238
Last Changed Date: 2016-05-14 05:07:13 -0400 (Sat, 14 May 2016)

$ g++ --version
g++ (GCC) 7.0.0 20160514 (experimental)
...

$ g++ -c -std=c++1z -fconcepts a.cpp; echo $?
0

[Bug c++/71141] New: [concepts] Example variadic concept code in the Concepts TS 14.1p9.4 rejected

2016-05-15 Thread tom at honermann dot net 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71141

Bug ID: 71141
   Summary: [concepts] Example variadic concept code in the
Concepts TS 14.1p9.4 rejected
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
  Target Milestone: ---

The following test case is taken from example code in the Concepts TS § 14.1
p9.4.  gcc r236238 rejects this code.  I presume the code is intended to be
well-formed; if not, then the Concepts TS should be updated.

$ cat t1.cpp
template concept bool C4 = true;
template void f5(); 

$ g++ -c -std=c++1z -fconcepts t1.cpp
t1.cpp:2:14: error: variadic constraint introduced without ‘...’ before ‘>’
token
 template void f5();
  ^

The example is accepted if the constrained function is re-written with a
requires clause:

$ cat t2.cpp
template concept bool C4 = true;
template requires C4 void f5(); 

$ g++ -c -std=c++1z -fconcepts t2.cpp; echo $?
0

An error is similarly produced when using a variadic non-type concept:

$ cat t3.cpp
template concept bool C5 = true;
template void f7();

$ g++ -c -std=c++1z -fconcepts t3.cpp
t3.cpp:2:14: error: variadic constraint introduced without ‘...’ before ‘>’
token
 template void f7();
  ^

[Bug c++/71141] [concepts] Example variadic concept code in the Concepts TS 14.1p9.4 rejected

2016-05-15 Thread tom at honermann dot net 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71141

--- Comment #1 from Tom Honermann  ---
If it is decided that this code is well-formed, then I think the declaration of
f7() in t3.cpp should be added to the example in the Concepts TS.

[Bug c++/69515] partial specialization of variable templates is broken

2016-05-15 Thread tom at honermann dot net 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69515

--- Comment #4 from Tom Honermann  ---
(In reply to Tom Honermann from comment #3)
> The error in comment 2 was also reported in bug 69364.

I don't know where I got that bug number from.  That should have been:
The error in comment 2 was also reported in bug 70037.

[Bug target/70947] regrename Go breakage on powerpc64

2016-05-15 Thread amodra at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70947

--- Comment #2 from Alan Modra  ---
Author: amodra
Date: Mon May 16 04:51:21 2016
New Revision: 236264

URL: https://gcc.gnu.org/viewcvs?rev=236264&root=gcc&view=rev
Log:
[RS6000] Stop regrename twiddling with split-stack prologue

PR target/70947
* config/rs6000/rs6000.c (rs6000_expand_split_stack_prologue): Stop
regrename modifying insns saving lr before __morestack call.
* config/rs6000/rs6000.md (split_stack_return): Similarly for
insns restoring lr after __morestack call.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/rs6000.c
branches/gcc-6-branch/gcc/config/rs6000/rs6000.md

[Bug c++/70862] [concepts] adding a concept-constrained version of a variable template causes multiple definition assembler error

2016-05-15 Thread tom at honermann dot net 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70862

--- Comment #4 from Tom Honermann  ---
(In reply to ryan.burn from comment #3)
> It's a different bug. The test case from 70095 compiles fine with the trunk
> from 20160428, but the above example won't.

The example in bug 70095 comment 2 still fails the same way.  That example is
known to be a regression caused by the change noted in bug 70095 comment 1 that
intended to fix the example in bug 70095 comment 0.  That change also affected
the behavior of the example in bug 69515 (but didn't fix it).  I don't know how
related these issues are.

[Bug tree-optimization/70964] [7 Regression] internal compiler error: in single_succ_edge, at basic-block.h:351

2016-05-15 Thread asolokha at gmx dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70964

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #6 from Arseny Solokha  ---
Fixed in r236158.

[Bug target/70947] regrename Go breakage on powerpc64

2016-05-15 Thread amodra at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70947

Alan Modra  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
Version|7.0 |6.2.0
 Resolution|--- |FIXED

--- Comment #3 from Alan Modra  ---
Fixed everywhere split-stack supported

[Bug c++/71092] [6/7 Regression] ICE: in cxx_eval_call_expression, at cp/constexpr.c:1449; only with -Os

2016-05-15 Thread trippels at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71092

--- Comment #5 from Markus Trippelsdorf  ---
(In reply to schoko.teddy from comment #3)
> Created attachment 38494 [details]
> Preprocessed source
> 
> This Error occurs while compiling this motioncontrollayer.cpp file from a Qt
> project. Gzipped because of largeness.

Looks like a ICE on invalid and is probably unrelated to the original issue:

markus@x4 tmp % cat motioncontrollayer.ii
namespace std {
template  struct A { static constexpr _Tp value = 0; };
typedef A false_type;
struct B : false_type {};
template  struct is_floating_point : B {};
template  struct enable_if { typedef int type; };
}
typedef int Value;
namespace detail {
template ::value,
 bool>::type = false>
constexpr Value toValue(T) {}
}
struct Quantity {
  template  constexpr Quantity(T) : value(detail::toValue(0)) {}
  Value value;
};
struct Pose {
  int x;
  int y;
  Quantity phi;
  constexpr Pose() : x(), y(), phi(0) {}
};
struct C {
  Pose pose;
};
struct D {
  Pose route[1];
};
void fn1() { C obj; }
void fn2() { D obj; }

markus@x4 tmp % clang++ -std=c++14 -ferror-limit=1 -c motioncontrollayer.ii
motioncontrollayer.ii:12:17: error: no return statement in constexpr function
constexpr Value toValue(T) {}
^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
2 errors generated.

markus@x4 tmp % icpc -std=c++14 -c motioncontrollayer.ii
motioncontrollayer.ii(12): error: missing return statement at end of non-void
function "detail::toValue(T)"
  constexpr Value toValue(T) {}
  ^
  detected during instantiation of "Quantity::Quantity(T) [with T=int]"
at line 22

compilation aborted for motioncontrollayer.ii (code 2)

markus@x4 tmp % g++ -c motioncontrollayer.ii
motioncontrollayer.ii: In constructor ‘constexpr D::D()’:
motioncontrollayer.ii:27:8:   in constexpr expansion of ‘Pose()’
motioncontrollayer.ii:22:37:   in constexpr expansion of
‘((Pose*)this)->Pose::phi.Quantity::Quantity(0)’
motioncontrollayer.ii:15:70:   in constexpr expansion of ‘detail::toValue(0)’
motioncontrollayer.ii:27:8: internal compiler error: in
cxx_eval_call_expression, at cp/constexpr.c:1449