[Bug fortran/67063] segfault in opening a formatted file at second time with status="replace"

[textdirected at gmail dot com]

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

--- Comment #4 from HEMMI, Shigeru  ---
I look into mingw web site and found that the same error has been reported by
Yogesh Yadav.

Please take a look at http://sourceforge.net/p/mingw-w64/support-requests/103/

Thanks for taking the time for this issue.

HEMMI, Shigeru

[Bug tree-optimization/66828] [5/6 Regression] gcc/tree-ssa-math-opts.c:2182:38: runtime error: left shift of 72057594037927936 by 8 places cannot be represented in type 'long int'

[thopre01 at gcc dot gnu.org]

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

--- Comment #11 from Thomas Preud'homme  ---
Sure. Starting bootstrap and testing.

[Bug target/67110] New: gcc.target/i386/iamcu/test_struct_returning.c execution test FAILs with -fpic

[ubizjak at gmail dot com]

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

Bug ID: 67110
   Summary: gcc.target/i386/iamcu/test_struct_returning.c
execution test FAILs with -fpic
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

As seen in [1], gcc.target/i386/iamcu/test_struct_returning.c execution test
FAILs with -fpic

/ssd/uros/gcc-build/gcc/xgcc -B/ssd/uros/gcc-build/gcc/
/home/uros/gcc-svn/trunk/gcc/testsuite/gcc.target/i386/iamcu/test_struct_returning.c
/home/uros/gcc-svn/trunk/gcc/testsuite/gcc.target/i386/iamcu/asm-support.S 
-m32  -O2 -fpic  -miamcu

Program received signal SIGSEGV, Segmentation fault.
0x08048385 in main () at
/home/uros/gcc-svn/trunk/gcc/testsuite/gcc.target/i386/iamcu/test_struct_returning.c:336
336   D(1) D(2) D(3) D(4) D(5) D(6) D(7)
(gdb) list
331 }
332
333 int
334 main (void)
335 {
336   D(1) D(2) D(3) D(4) D(5) D(6) D(7)
337
338   D(30)
339
340   D(50) D(51) D(52) D(53) D(54) D(55) D(56) D(57) D(58) D(59)

(gdb) disass
Dump of assembler code for function main:
   0x08048300 <+0>: push   %ebp
   0x08048301 <+1>: push   %edi
   0x08048302 <+2>: mov$0x18,%ecx
   0x08048307 <+7>: push   %esi
   0x08048308 <+8>: push   %ebx
   0x08048309 <+9>: xor%edx,%edx
   0x0804830b <+11>:call   0x80499c0 <__x86.get_pc_thunk.bx>
   0x08048310 <+16>:add$0x4cf0,%ebx
   0x08048316 <+22>:sub$0x108,%esp
   0x0804831c <+28>:lea0x2f0(%ebx),%edi
   0x08048322 <+34>:lea0x2ce(%ebx),%eax
   0x08048328 <+40>:lea0x2ec(%ebx),%ebp
   0x0804832e <+46>:lea0x304(%ebx),%esi
   0x08048334 <+52>:mov%eax,(%edi)
   0x08048336 <+54>:lea0x2fc(%ebx),%eax
   0x0804833c <+60>:movl   $0x1,0x0(%ebp)
   0x08048343 <+67>:movl   $0x0,(%esi)
   0x08048349 <+73>:mov%eax,(%esp)
   0x0804834c <+76>:movl   $0x0,(%eax)
   0x08048352 <+82>:lea0x2f8(%ebx),%eax
   0x08048358 <+88>:mov%eax,0x4(%esp)
   0x0804835c <+92>:movl   $0x0,(%eax)
   0x08048362 <+98>:lea0x2d4(%ebx),%eax
   0x08048368 <+104>:   mov%eax,0x8(%esp)
   0x0804836c <+108>:   call   0x804ac30 
   0x08048371 <+113>:   xor%edx,%ebx
   0x08048373 <+115>:   xor%ecx,%ecx
   0x08048375 <+117>:   lea0x2f4(%ebx),%edx
   0x0804837b <+123>:   lea-0x3550(%ebx),%eax
   0x08048381 <+129>:   mov%edx,0xc(%esp)
=> 0x08048385 <+133>:   mov%eax,(%edx)
   0x08048387 <+135>:   call   0x804ab00 
   0x0804838c <+140>:   mov%al,0x2ce(%ebx)
   0x08048392 <+146>:   lea0xf8(%ebx),%eax
   0x08048398 <+152>:   mov$0x1,%edx
   0x0804839d <+157>:   mov(%eax),%eax
   0x0804839f <+159>:   call   0x804a950 

(gdb) i r edx
edx0x5c81480

[1] https://gcc.gnu.org/ml/gcc-testresults/2015-08/msg00271.html

[Bug tree-optimization/67109] New: ICE at -O3 on x86_64-linux-gnu in vect_analyze_slp_instance, at tree-vect-slp.c:1793

[su at cs dot ucdavis.edu]

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

Bug ID: 67109
   Summary: ICE at -O3 on x86_64-linux-gnu in
vect_analyze_slp_instance, at tree-vect-slp.c:1793
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk at
-O3 on x86_64-linux-gnu in the 64-bit mode (but not in the 32-bit mode). 

It is a regression from 5.1.x (I didn't check 5.2.x). 

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20150803 (experimental) [trunk revision 226526] (GCC) 
$ 
$ gcc-trunk -m64 -O2 -c small.c
small.c: In function ‘fn1’:
small.c:12:9: warning: iteration 1u invokes undefined behavior
[-Waggressive-loop-optimizations]
b[a] ^= 1;
 ^
small.c:10:7: note: containing loop
   for (; c < 5; c++)
   ^
$ gcc-trunk -m32 -O3 -c small.c
small.c: In function ‘fn1’:
small.c:12:9: warning: iteration 1u invokes undefined behavior
[-Waggressive-loop-optimizations]
b[a] ^= 1;
 ^
small.c:10:7: note: containing loop
   for (; c < 5; c++)
   ^
$ 
$ gcc-5.1 -m64 -O3 -c small.c
small.c: In function ‘fn1’:
small.c:12:9: warning: iteration 1u invokes undefined behavior
[-Waggressive-loop-optimizations]
b[a] ^= 1;
 ^
small.c:10:7: note: containing loop
   for (; c < 5; c++)
   ^
$ 
$ gcc-trunk -m64 -O3 -c small.c
small.c: In function ‘fn1’:
small.c:12:9: warning: iteration 1u invokes undefined behavior
[-Waggressive-loop-optimizations]
b[a] ^= 1;
 ^
small.c:10:7: note: containing loop
   for (; c < 5; c++)
   ^
small.c:5:1: internal compiler error: in vect_analyze_slp_instance, at
tree-vect-slp.c:1793
 fn1 ()
 ^
0xcf91c5 vect_analyze_slp_instance
../../gcc-trunk/gcc/tree-vect-slp.c:1793
0xcf9ab7 vect_analyze_slp(_loop_vec_info*, _bb_vec_info*, unsigned int)
../../gcc-trunk/gcc/tree-vect-slp.c:1879
0xcf9eee vect_slp_analyze_bb_1
../../gcc-trunk/gcc/tree-vect-slp.c:2426
0xcf9eee vect_slp_analyze_bb(basic_block_def*)
../../gcc-trunk/gcc/tree-vect-slp.c:2552
0xcfce22 execute
../../gcc-trunk/gcc/tree-vectorizer.c:702
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.
$ 


---


unsigned int a;
int b[1], c, d;

void
fn1 ()
{
  for (; d;)
{
  a = c = 0;
  for (; c < 5; c++)
{
  b[a] ^= 1;
  a--;
}
}
}

[Bug debug/67043] [6 Regression] -fcompare-debug failure with -O3

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Markus Trippelsdorf  ---
Fixed. Thanks.

[Bug tree-optimization/66828] [5/6 Regression] gcc/tree-ssa-math-opts.c:2182:38: runtime error: left shift of 72057594037927936 by 8 places cannot be represented in type 'long int'

[trippels at gcc dot gnu.org]

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

--- Comment #10 from Markus Trippelsdorf  ---
Thomas, could you backport your fix to the gcc-5 branch, so that we can close
this issue?

[Bug c++/67084] [c++-concepts] Matching of variable template declarations ignores constraints

[jason at gcc dot gnu.org]

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

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 #1 from Jason Merrill  ---
Fixed.

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Tue Aug  4 05:07:10 2015
New Revision: 226546

URL: https://gcc.gnu.org/viewcvs?rev=226546&root=gcc&view=rev
Log:
PR c++/67084
* pt.c (spec_hasher::equal): Compare constraints.
(check_explicit_specialization): Don't register partial specs.
(process_partial_specialization): Register them here.
(lookup_template_class_1): Clear elt.spec.

Added:
branches/c++-concepts/gcc/testsuite/g++.dg/concepts/partial-spec2.C
Modified:
branches/c++-concepts/ChangeLog.concepts
branches/c++-concepts/gcc/cp/pt.c

[Bug c++/67084] [c++-concepts] Matching of variable template declarations ignores constraints

[jason at gcc dot gnu.org]

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

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 #1 from Jason Merrill  ---
Fixed.

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Tue Aug  4 05:07:10 2015
New Revision: 226546

URL: https://gcc.gnu.org/viewcvs?rev=226546&root=gcc&view=rev
Log:
PR c++/67084
* pt.c (spec_hasher::equal): Compare constraints.
(check_explicit_specialization): Don't register partial specs.
(process_partial_specialization): Register them here.
(lookup_template_class_1): Clear elt.spec.

Added:
branches/c++-concepts/gcc/testsuite/g++.dg/concepts/partial-spec2.C
Modified:
branches/c++-concepts/ChangeLog.concepts
branches/c++-concepts/gcc/cp/pt.c

[Bug go/67101] mprof.goc:408:5: error: calling ‘__builtin_frame_address’ with a nonzero argument is unsafe [-Werror=frame-address]

[ian at airs dot com]

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

--- Comment #5 from Ian Lance Taylor  ---
That is a different problem.  I just committed a patch that should fix it.

[Bug debug/67043] [6 Regression] -fcompare-debug failure with -O3

[thopre01 at gcc dot gnu.org]

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

--- Comment #6 from Thomas Preud'homme  ---
Author: thopre01
Date: Tue Aug  4 02:11:58 2015
New Revision: 226540

URL: https://gcc.gnu.org/viewcvs?rev=226540&root=gcc&view=rev
Log:
2015-08-04  Thomas Preud'homme  

gcc/
PR tree-optimization/67043
* loop-invariant.c (move_invariant_reg): Recompute luids in loop
preheader after hoisting invariant in it.
(find_defs): Force recomputation of all luids.

gcc/testsuite/
PR tree-optimization/67043
* gcc.dg/pr67043.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr67043.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/loop-invariant.c
trunk/gcc/testsuite/ChangeLog

[Bug target/67002] [5] [SH]: Bootstrap stage 2/3 comparison failure - gcc/real.o differs

[kkojima at gcc dot gnu.org]

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

--- Comment #14 from Kazumoto Kojima  ---
Created attachment 36117
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36117&action=edit
reduced test case

> Michael Karcher, who previously helped smashing some bugs in gcc for the SH
> target, had a go at this and he discovered that the difference between stage2
> and stage3 is the -gtoggle switch.

I've confirmed it even with cross 5/6 compilers.  The above reduced
C++ test case fails with "-S -O2 -fcompare-debug" on my 5/6 cross
sh4-linux/sh-elf g++.  It means that the generated insns differ
with/without -g.  It looks to me a target independent issue, though
I could be wrong about it.  With a quick look, rtl_pre pass behaves
differently with -g.  I've found PRs for -fcompare-debug like 63315,
65874, 65980, 66688 and 67043.

[Bug fortran/64104] [F2003][IEEE] Allow IEEE functions in specification expressions

[fxcoudert at gcc dot gnu.org]

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

--- Comment #3 from Francois-Xavier Coudert  ---
According to F08/0104 interp/erratum
(http://j3-fortran.org/doc/year/14/14-192.txt):

Allowed in constant expressions:

"(8) a reference to a transformational function from the intrinsic module
IEEE_ARITHMETIC or IEEE_EXCEPTIONS (14), where each argument is a constant
expression,"

which means:
IEEE_SELECTED_REAL_KIND
IEEE_SUPPORT_ROUNDING
IEEE_SUPPORT_FLAG
IEEE_SUPPORT_HALTING


Allowed in specification expressions:

"(nn) a reference to a transformational function from the intrinsic module
IEEE_ARITHMETIC or IEEE_EXCEPTIONS (14) or the intrinsic module ISO_C_BINDING
(15.2), where each argument is a restricted expression,"

which means:
IEEE_SELECTED_REAL_KIND
IEEE_SUPPORT_ROUNDING
IEEE_SUPPORT_FLAG
IEEE_SUPPORT_HALTING

and:

"(9) a specification inquiry, i.e.
  [...]
  (3) an inquiry function from the intrinsic modules IEEE_ARITHMETIC and
IEEE_EXCEPTIONS"

which means:

IEEE SUPPORT DATATYPE
IEEE SUPPORT DENORMAL
IEEE SUPPORT DIVIDE
IEEE SUPPORT INF
IEEE SUPPORT IO
IEEE SUPPORT NAN
IEEE SUPPORT SQRT
IEEE SUPPORT STANDARD
IEEE SUPPORT UNDERFLOW CONTROL

[Bug go/67101] mprof.goc:408:5: error: calling ‘__builtin_frame_address’ with a nonzero argument is unsafe [-Werror=frame-address]

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

 CC||miyuki at gcc dot gnu.org

--- Comment #4 from Mikhail Maltsev  ---
Seems like it's still failing:

/home/jenkins/workspace/build-gcc-trunk/src/libgo/runtime/mprof.goc: In
function ‘runtime_Stack’:
/home/jenkins/workspace/build-gcc-trunk/src/libgo/runtime/mprof.goc:437:19:
error: ‘enablegc’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
   mstats.enablegc = enablegc;
   ^
/home/jenkins/workspace/build-gcc-trunk/src/libgo/runtime/mprof.goc:406:7:
note: ‘enablegc’ was declared here
  bool enablegc;

That is r226526, x86_64-pc-linux-gnu bootstrap, configured like this:
  $ /home/jenkins/workspace/build-gcc-trunk/src/configure
--enable-languages=c,c++,objc,lto,fortran,go --prefix=/opt/gcc-6.0.0
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-isl=/opt/isl-0.14 --enable-shared --with-fpmath=sse --enable-multilib
--enable-bootstrap --enable-checking=yes CC=/opt/gcc-4.9.3-fdo/bin/gcc
CXX=/opt/gcc-4.9.3-fdo/bin/g++

The warning is likely a false positive.

[Bug target/67071] GCC misses an optimization to load vector constants

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  ---
Author: meissner
Date: Mon Aug  3 21:52:10 2015
New Revision: 226534

URL: https://gcc.gnu.org/viewcvs?rev=226534&root=gcc&view=rev
Log:
Patch for PR 67071

Added:
branches/ibm/ieee4/gcc/testsuite/gcc.target/powerpc/pr67071-1.c
branches/ibm/ieee4/gcc/testsuite/gcc.target/powerpc/pr67071-2.c
branches/ibm/ieee4/gcc/testsuite/gcc.target/powerpc/pr67071-3.c
Modified:
branches/ibm/ieee4/gcc/ChangeLog.meissner
branches/ibm/ieee4/gcc/config/rs6000/altivec.md
branches/ibm/ieee4/gcc/config/rs6000/predicates.md
branches/ibm/ieee4/gcc/config/rs6000/rs6000-protos.h
branches/ibm/ieee4/gcc/config/rs6000/rs6000.c
branches/ibm/ieee4/gcc/config/rs6000/rs6000.h
branches/ibm/ieee4/gcc/testsuite/ChangeLog.meissner

[Bug fortran/67063] segfault in opening a formatted file at second time with status="replace"

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||fxcoudert at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #3 from Francois-Xavier Coudert  ---
Unless we know more about this, this looks really like an issue with this
specific build. Can you report it to the minnow-w64 maintainers so they can
look into it?

[Bug fortran/66311] [5/6 Regression] Problems with some integer(16) values

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu.org,
   ||jakub at redhat dot com

--- Comment #6 from Francois-Xavier Coudert  ---
Definitely a middle-end issue. We get it right on the front-end, the variable
initialization gets screwed when translated later. Reduced testcase:

$ cat a.f90
program test
  integer(kind=16) :: z = 18446744073709551614_16
  print *, z
end
$ ./usr/local/bin/gfortran -fdump-parse-tree -fdump-tree-original a.f90 &&
./a.out
 -2


The "parse tree" clearly shows that z has value of 18446744073709551614_16. But
in the a.f90.003t.original, we get the wrong initialization:

  static integer(kind=16) z = -2;


I tracked the issue to the two calls to wi::from_mpz() and wide_int_to_tree()
in gcc/fortran/trans-const.c:gfc_conv_mpz_to_tree(). There the mpz value (which
is correct) in translated into:

  wide_int_storage = {
val = ([0] = -2, [1] = 0, [2] = 56)
len = 1
precision = 128
  }

which appears to be where the -2 comes from. Probably not seen outside Fortran
because people don't use this conversion routine in C (because there is not way
to input literal __int128 values in C).

Can someone familiar with wide-int look into it?

[Bug c++/67108] New: ICE: in cxx_eval_call_expression, at cp/constexpr.c:1345 when dumping

[zsojka at seznam dot cz]

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

Bug ID: 67108
   Summary: ICE: in cxx_eval_call_expression, at
cp/constexpr.c:1345 when dumping
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---

Created attachment 36116
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36116&action=edit
reduced testcase

Compiler output with -fdump-ipa-cgraph:
$ gcc testcase.C -fdump-ipa-cgraph
testcase.C:26:3:   in constexpr expansion of ‘is_same{}.is_same::operator()()’
cc1plus: internal compiler error: in cxx_eval_call_expression, at
cp/constexpr.c:1345
0x7e5a35 cxx_eval_call_expression
/mnt/svn/gcc-trunk/gcc/cp/constexpr.c:1345
0x7e6851 cxx_eval_constant_expression
/mnt/svn/gcc-trunk/gcc/cp/constexpr.c:3079
0x7ebd9b cxx_eval_outermost_constant_expr
/mnt/svn/gcc-trunk/gcc/cp/constexpr.c:3594
0x7eda18 maybe_constant_value(tree_node*, tree_node*)
/mnt/svn/gcc-trunk/gcc/cp/constexpr.c:3707
0x64dda6 convert_nontype_argument
/mnt/svn/gcc-trunk/gcc/cp/pt.c:5956
0x64dda6 convert_template_argument
/mnt/svn/gcc-trunk/gcc/cp/pt.c:6853
0x64f55f coerce_template_parms
/mnt/svn/gcc-trunk/gcc/cp/pt.c:7282
0x651b72 lookup_template_class_1
/mnt/svn/gcc-trunk/gcc/cp/pt.c:7851
0x651b72 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
/mnt/svn/gcc-trunk/gcc/cp/pt.c:8177
0x654bac tsubst_aggr_type
/mnt/svn/gcc-trunk/gcc/cp/pt.c:10587
0x640cf8 tsubst(tree_node*, tree_node*, int, tree_node*)
/mnt/svn/gcc-trunk/gcc/cp/pt.c:12549
0x6bd440 dump_template_bindings
/mnt/svn/gcc-trunk/gcc/cp/error.c:351
0x6bd440 dump_substitution
/mnt/svn/gcc-trunk/gcc/cp/error.c:1438
0x6c9963 decl_as_string(tree_node*, int)
/mnt/svn/gcc-trunk/gcc/cp/error.c:2803
0x778ec9 cxx_printable_name_internal
/mnt/svn/gcc-trunk/gcc/cp/tree.c:2095
0x8e7c1e symtab_node::name() const
/mnt/svn/gcc-trunk/gcc/symtab.c:460
0x8e7c1e symtab_node::dump_base(_IO_FILE*)
/mnt/svn/gcc-trunk/gcc/symtab.c:726
0x8f1192 cgraph_node::dump(_IO_FILE*)
/mnt/svn/gcc-trunk/gcc/cgraph.c:1980
0x8e86ca symtab_node::dump_table(_IO_FILE*)
/mnt/svn/gcc-trunk/gcc/symtab.c:853
0x901dc1 analyze_functions
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1167
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


Compiler output with -fcompare-debug:
$ gcc testcase.C -fcompare-debug


internal compiler error: Error reporting routines re-entered.
0x7e5a35 cxx_eval_call_expression
/mnt/svn/gcc-trunk/gcc/cp/constexpr.c:1345
0x7e6851 cxx_eval_constant_expression
/mnt/svn/gcc-trunk/gcc/cp/constexpr.c:3079
0x7ebd9b cxx_eval_outermost_constant_expr
/mnt/svn/gcc-trunk/gcc/cp/constexpr.c:3594
0x7eda18 maybe_constant_value(tree_node*, tree_node*)
/mnt/svn/gcc-trunk/gcc/cp/constexpr.c:3707
0x64dda6 convert_nontype_argument
/mnt/svn/gcc-trunk/gcc/cp/pt.c:5956
0x64dda6 convert_template_argument
/mnt/svn/gcc-trunk/gcc/cp/pt.c:6853
0x64f55f coerce_template_parms
/mnt/svn/gcc-trunk/gcc/cp/pt.c:7282
0x651b72 lookup_template_class_1
/mnt/svn/gcc-trunk/gcc/cp/pt.c:7851
0x651b72 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
/mnt/svn/gcc-trunk/gcc/cp/pt.c:8177
0x654bac tsubst_aggr_type
/mnt/svn/gcc-trunk/gcc/cp/pt.c:10587
0x640cf8 tsubst(tree_node*, tree_node*, int, tree_node*)
/mnt/svn/gcc-trunk/gcc/cp/pt.c:12549
0x6bd440 dump_template_bindings
/mnt/svn/gcc-trunk/gcc/cp/error.c:351
0x6bd440 dump_substitution
/mnt/svn/gcc-trunk/gcc/cp/error.c:1438
0x6c99fc decl_as_string_translate(tree_node*, int)
/mnt/svn/gcc-trunk/gcc/cp/error.c:2811
0x778ec9 cxx_printable_name_internal
/mnt/svn/gcc-trunk/gcc/cp/tree.c:2095
0x6c6a72 cp_print_error_function
/mnt/svn/gcc-trunk/gcc/cp/error.c:3144
0x6c6a72 cp_diagnostic_starter
/mnt/svn/gcc-trunk/gcc/cp/error.c:3098
0x163e1df diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
/mnt/svn/gcc-trunk/gcc/diagnostic.c:916
0x163f037 internal_error(char const*, ...)
/mnt/svn/gcc-trunk/gcc/diagnostic.c:1272
0x163d6f3 fancy_abort(char const*, int, char const*)
/mnt/svn/gcc-trunk/gcc/diagnostic.c:1340
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


Tested revisions:
r226486 - ICE
gcc-5-branch r225803 - code is not accepted

[Bug driver/66849] Incorrect multilib chosen with -mthumb -mfloat-abi=hard

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

 CC||wilson at gcc dot gnu.org

--- Comment #4 from Jim Wilson  ---
The problem is that we can't have thumb1 hard-float code, so the thumb/hard
multilib is explicitly disabled.  However, we can have thumb2 hard-float code,
and hence this should be enabled for targets that support thumb2, but isn't
yet, as there is no easy and obvious way to do this without breaking support
for older thumb1 targets.

If you don't care whether you have arm or thumb code, then you can just use the
arm hard-float library with an override like you already did.

If you want a proper thumb2 hard multilib, then in the file
gcc/config/arm/t-arm-elf see the line
MULTILIB_EXCEPTIONS+= *mthumb/*mfloat-abi=hard*
Put a # in front of it to disable it, rebuild gcc, and then you will have
thumb2 hard-float libraries.  See also the comments before this section of
code.

The t-aprofile that Ramana mentioned does support thumb/hard multilibs, but
makes this work by requiring armv7 or higher.

[Bug c/67107] New: [6 Regression] ICE: SIGSEGV in tree_class_check with -frounding-math -funsafe-math-optimizations

[zsojka at seznam dot cz]

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

Bug ID: 67107
   Summary: [6 Regression] ICE: SIGSEGV in tree_class_check with
-frounding-math -funsafe-math-optimizations
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---

Created attachment 36115
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36115&action=edit
reduced testcase

Compiler output:
$ gcc -frounding-math -funsafe-math-optimizations testcase.c 
testcase.c: In function 'test':
testcase.c:3:3: internal compiler error: Segmentation fault
   return 5.0 < 5.0 - 0.1;
   ^
0xc19cdf crash_signal
/mnt/svn/gcc-trunk/gcc/toplev.c:352
0x9845d6 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/mnt/svn/gcc-trunk/gcc/tree.h:2980
0x9845d6 generic_simplify_GT_EXPR
   
/home/smatz/build-226486-lto-fortran-checking-yes-rtl-df/gcc/generic-match.c:18582
0x990dfd generic_simplify(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
   
/home/smatz/build-226486-lto-fortran-checking-yes-rtl-df/gcc/generic-match.c:34963
0x85073e fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/mnt/svn/gcc-trunk/gcc/fold-const.c:9108
0x85d67a fold_build2_stat_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/mnt/svn/gcc-trunk/gcc/fold-const.c:12781
0x66d093 c_fully_fold_internal
/mnt/svn/gcc-trunk/gcc/c-family/c-common.c:1361
0x66e1e5 c_fully_fold(tree_node*, bool, bool*)
/mnt/svn/gcc-trunk/gcc/c-family/c-common.c:1144
0x5e762c c_finish_return(unsigned int, tree_node*, tree_node*)
/mnt/svn/gcc-trunk/gcc/c/c-typeck.c:9379
0x62332e c_parser_statement_after_labels
/mnt/svn/gcc-trunk/gcc/c/c-parser.c:5042
0x6248d5 c_parser_compound_statement_nostart
/mnt/svn/gcc-trunk/gcc/c/c-parser.c:4696
0x62511e c_parser_compound_statement
/mnt/svn/gcc-trunk/gcc/c/c-parser.c:4533
0x620f67 c_parser_declaration_or_fndef
/mnt/svn/gcc-trunk/gcc/c/c-parser.c:1966
0x62b297 c_parser_external_declaration
/mnt/svn/gcc-trunk/gcc/c/c-parser.c:1436
0x62bb59 c_parser_translation_unit
/mnt/svn/gcc-trunk/gcc/c/c-parser.c:1323
0x62bb59 c_parse_file()
/mnt/svn/gcc-trunk/gcc/c/c-parser.c:15449
0x6875b2 c_common_parse_file()
/mnt/svn/gcc-trunk/gcc/c-family/c-opts.c:1058
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.


$ gcc -v
Using built-in specs.
COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc
COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-226486-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df
--enable-languages=c,c++,lto,fortran
--prefix=/mnt/svn/gcc-trunk/binary-226486-lto-fortran-checking-yes-rtl-df/
--without-cloog --without-ppl --without-isl
Thread model: posix
gcc version 6.0.0 20150803 (experimental) (GCC) 


Tested revisions:
r226486 - ICE
gcc-5-branch r225803 - OK

[Bug libstdc++/67085] priority queue should not copy comparators when calling push_heap and pop_heap

[konig121 at gmail dot com]

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

--- Comment #3 from Andrew Calcutt  ---
Hi Jonathan,

I can understand your reservation, but it seems to me like there is a case for
making this change if the comparator provided to the priority_queue was
explicitly a reference type. For example:

 std::priority_queue, MyComparator&> queue;

would create an object which contained a reference to an external comparator.
Even in this case, however, the heap operations would use a copy of the
provided comparator. I believe that fixing this would allow for move only
comparators to be used, and would not require as complex a change. Simply
providing the comparator type to the heap calls would be sufficient without
requiring std::ref.

Are there technical reasons this is not desirable or possible beyond what you
have already stated? Is the behavior of the priority queue here also outside of
the intent of the standard?

Thanks,
Andrew

[Bug middle-end/64744] ARM: gcc internal compiler error: in store_field, at expr.c:6659

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #8 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug middle-end/48470] ICE in expand_expr_addr_expr_1 at expr.c:6835

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #5 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug target/43404] ARM: Internal compiler error when using '&foo' in naked function

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #9 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug target/43404] ARM: Internal compiler error when using '&foo' in naked function

[law at gcc dot gnu.org]

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

--- Comment #8 from Jeffrey A. Law  ---
Author: law
Date: Mon Aug  3 19:34:31 2015
New Revision: 226528

URL: https://gcc.gnu.org/viewcvs?rev=226528&root=gcc&view=rev
Log:
PR middle-end/64744
PR middle-end/48470
PR middle-end/43404
* cfgexpand.c (expand_one_var): Add check if stack is going to
be used in naked function.
* expr.c (expand_expr_addr_expr_1): Remove excess checking
whether expression should not reside in MEM.
* function.c (use_register_for_decl): Do not use registers for
non-register things (volatile, float, BLKMode) in naked functions.

PR middle-end/64744
PR middle-end/48470
PR middle-end/43404
* gcc.target/arm/pr43404.c : New testcase.
* gcc.target/arm/pr48470.c : New testcase.
* gcc.target/arm/pr64744-1.c : New testcase.
* gcc.target/arm/pr64744-2.c : New testcase.

Added:
trunk/gcc/testsuite/gcc.target/arm/pr43404.c
trunk/gcc/testsuite/gcc.target/arm/pr48470.c
trunk/gcc/testsuite/gcc.target/arm/pr64744-1.c
trunk/gcc/testsuite/gcc.target/arm/pr64744-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/expr.c
trunk/gcc/function.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/64744] ARM: gcc internal compiler error: in store_field, at expr.c:6659

[law at gcc dot gnu.org]

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

--- Comment #7 from Jeffrey A. Law  ---
Author: law
Date: Mon Aug  3 19:34:31 2015
New Revision: 226528

URL: https://gcc.gnu.org/viewcvs?rev=226528&root=gcc&view=rev
Log:
PR middle-end/64744
PR middle-end/48470
PR middle-end/43404
* cfgexpand.c (expand_one_var): Add check if stack is going to
be used in naked function.
* expr.c (expand_expr_addr_expr_1): Remove excess checking
whether expression should not reside in MEM.
* function.c (use_register_for_decl): Do not use registers for
non-register things (volatile, float, BLKMode) in naked functions.

PR middle-end/64744
PR middle-end/48470
PR middle-end/43404
* gcc.target/arm/pr43404.c : New testcase.
* gcc.target/arm/pr48470.c : New testcase.
* gcc.target/arm/pr64744-1.c : New testcase.
* gcc.target/arm/pr64744-2.c : New testcase.

Added:
trunk/gcc/testsuite/gcc.target/arm/pr43404.c
trunk/gcc/testsuite/gcc.target/arm/pr48470.c
trunk/gcc/testsuite/gcc.target/arm/pr64744-1.c
trunk/gcc/testsuite/gcc.target/arm/pr64744-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/expr.c
trunk/gcc/function.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/48470] ICE in expand_expr_addr_expr_1 at expr.c:6835

[law at gcc dot gnu.org]

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

--- Comment #4 from Jeffrey A. Law  ---
Author: law
Date: Mon Aug  3 19:34:31 2015
New Revision: 226528

URL: https://gcc.gnu.org/viewcvs?rev=226528&root=gcc&view=rev
Log:
PR middle-end/64744
PR middle-end/48470
PR middle-end/43404
* cfgexpand.c (expand_one_var): Add check if stack is going to
be used in naked function.
* expr.c (expand_expr_addr_expr_1): Remove excess checking
whether expression should not reside in MEM.
* function.c (use_register_for_decl): Do not use registers for
non-register things (volatile, float, BLKMode) in naked functions.

PR middle-end/64744
PR middle-end/48470
PR middle-end/43404
* gcc.target/arm/pr43404.c : New testcase.
* gcc.target/arm/pr48470.c : New testcase.
* gcc.target/arm/pr64744-1.c : New testcase.
* gcc.target/arm/pr64744-2.c : New testcase.

Added:
trunk/gcc/testsuite/gcc.target/arm/pr43404.c
trunk/gcc/testsuite/gcc.target/arm/pr48470.c
trunk/gcc/testsuite/gcc.target/arm/pr64744-1.c
trunk/gcc/testsuite/gcc.target/arm/pr64744-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/expr.c
trunk/gcc/function.c
trunk/gcc/testsuite/ChangeLog

[Bug debug/67106] New: [6 Regression] ICE: verify_type failed: type variant differs by TYPE_PACKED. with -g -fpack-struct

[zsojka at seznam dot cz]

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

Bug ID: 67106
   Summary: [6 Regression] ICE: verify_type failed:  type variant
differs by TYPE_PACKED. with -g -fpack-struct
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---

Created attachment 36114
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36114&action=edit
reduced testcase

Compiler output:
$ /mnt/svn/gcc-trunk/binary-latest/bin/gcc -g -fpack-struct testcase.c 
testcase.c:8:3: error: type variant differs by TYPE_PACKED.
   };
   ^
  chain >
  chain >
testcase.c:8:3: internal compiler error: verify_type failed
0xeb4379 verify_type(tree_node const*)
/mnt/svn/gcc-trunk/gcc/tree.c:13570
0x7c3d34 gen_type_die_with_usage
/mnt/svn/gcc-trunk/gcc/dwarf2out.c:20685
0x7c44c5 gen_type_die_with_usage
/mnt/svn/gcc-trunk/gcc/dwarf2out.c:20783
0x7c5516 gen_type_die
/mnt/svn/gcc-trunk/gcc/dwarf2out.c:20879
0x7d354d gen_decl_die
/mnt/svn/gcc-trunk/gcc/dwarf2out.c:21519
0x7c2fcd gen_member_die
/mnt/svn/gcc-trunk/gcc/dwarf2out.c:20356
0x7c2fcd gen_struct_or_union_type_die
/mnt/svn/gcc-trunk/gcc/dwarf2out.c:20461
0x7c2fcd gen_tagged_type_die
/mnt/svn/gcc-trunk/gcc/dwarf2out.c:20662
0x7c483d gen_type_die_with_usage
/mnt/svn/gcc-trunk/gcc/dwarf2out.c:20824
0x7c5516 gen_type_die
/mnt/svn/gcc-trunk/gcc/dwarf2out.c:20879
0x7d3a79 gen_decl_die
/mnt/svn/gcc-trunk/gcc/dwarf2out.c:21465
0x7d4594 dwarf2out_decl
/mnt/svn/gcc-trunk/gcc/dwarf2out.c:21915
0x7d486b dwarf2out_type_decl
/mnt/svn/gcc-trunk/gcc/dwarf2out.c:21625
0xb187ef rest_of_type_compilation(tree_node*, int)
/mnt/svn/gcc-trunk/gcc/passes.c:336
0x5d4cf3 finish_struct(unsigned int, tree_node*, tree_node*, tree_node*,
c_struct_parse_info*)
/mnt/svn/gcc-trunk/gcc/c/c-decl.c:7849
0x611a4e c_parser_struct_or_union_specifier
/mnt/svn/gcc-trunk/gcc/c/c-parser.c:2812
0x611a4e c_parser_declspecs
/mnt/svn/gcc-trunk/gcc/c/c-parser.c:2387
0x60fc2b c_parser_struct_declaration
/mnt/svn/gcc-trunk/gcc/c/c-parser.c:2896
0x6119b7 c_parser_struct_or_union_specifier
/mnt/svn/gcc-trunk/gcc/c/c-parser.c:2786
0x6119b7 c_parser_declspecs
/mnt/svn/gcc-trunk/gcc/c/c-parser.c:2387
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.


$ /mnt/svn/gcc-trunk/binary-latest/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc
COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-226486-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df
--enable-languages=c,c++,lto,fortran
--prefix=/mnt/svn/gcc-trunk/binary-226486-lto-fortran-checking-yes-rtl-df/
--without-cloog --without-ppl --without-isl
Thread model: posix
gcc version 6.0.0 20150803 (experimental) (GCC) 


-freport-bug fails here:

$ /mnt/svn/gcc-trunk/binary-latest/bin/gcc -freport-bug -g -fpack-struct
testcase.c  
testcase.c:8:3: error: type variant differs by TYPE_PACKED.
   };
...
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.
The bug is not reproducible, so it is likely a hardware or OS problem.

Is this behavior expected? It reproduces everytime for me.


Tested revisions:
r226486 - ICE
gcc-5-branch r225803 - OK

[Bug fortran/66079] [6 Regression] memory leak with source allocation in internal subprogram

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #9 from kargl at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #8)
> Created attachment 36113 [details]
> Patch for th 5 branch
> 
> Before closing this PR, I checked and found that the 5 branch now leaks
> memory.
> 
> The attached fixes the memory leak but does not fix the ICEs for which the
> tests have been commented out. There is already too much divergence in
> trans_allocate between 5 and 6 to do any more.
> 
> What do you think about applying this patch, which bootstraps and regtests?
> 

I think that it would be fine to apply the patch (as you already have
done the backport of a patch and tested it).

[Bug c++/67064] Register asm variable broken

[daniel.gutson at tallertechnologies dot com]

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

--- Comment #20 from Daniel Gutson  ---
(In reply to Manuel López-Ibáñez from comment #19)
> (In reply to Daniel Gutson from comment #18)
> > Please assign this to me. Thanks.
> 
> You need to login with your @gcc.gnu.org account to be able to assign bugs
> (and do other Bugzilla operations).

I don't have a @gcc.gnu.org account. Should I simply send the attachment?
Otherwise please assign this to me for me if it is still possible. FWIW, I've
been listed in the MAINTAINER list in the past while working for CodeSourcery
but my name no longer is in that list.

[Bug c++/67064] Register asm variable broken

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #19 from Manuel López-Ibáñez  ---
(In reply to Daniel Gutson from comment #18)
> Please assign this to me. Thanks.

You need to login with your @gcc.gnu.org account to be able to assign bugs (and
do other Bugzilla operations).

[Bug c++/67064] Register asm variable broken

[daniel.gutson at tallertechnologies dot com]

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

--- Comment #18 from Daniel Gutson  ---
I created https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67105

to treat that bug separately.

67064 (this bug) interferes with RTEMS in real life thus has a much higher
priority, so I will address this bug first.
Please assign this to me. Thanks.

[Bug c++/67105] New: use of global register variables should emit a pedwarn

[daniel.gutson at tallertechnologies dot com]

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

Bug ID: 67105
   Summary: use of global register variables should emit a pedwarn
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.gutson at tallertechnologies dot com
  Target Milestone: ---

This is a spinoff of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
specially comment https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064#c16

So basically:

struct s {
  int i;
};
register struct s *reg asm( "si" );

should pedwarn.

[Bug fortran/66079] [6 Regression] memory leak with source allocation in internal subprogram

[pault at gcc dot gnu.org]

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

--- Comment #8 from Paul Thomas  ---
Created attachment 36113
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36113&action=edit
Patch for th 5 branch

Before closing this PR, I checked and found that the 5 branch now leaks memory.

The attached fixes the memory leak but does not fix the ICEs for which the
tests have been commented out. There is already too much divergence in
trans_allocate between 5 and 6 to do any more.

What do you think about applying this patch, which bootstraps and regtests?

Paul

[Bug c++/67104] Constant expression factory function initializes std::array with static storage duration strangely

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-08-03
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Markus Trippelsdorf  ---
markus@x4 tmp % cat te3.ii
namespace std
{
typedef int size_t;
template  struct A
{
  typedef int _Type[_Nm];
  static constexpr _Tp
  _S_ref (const _Type __t, size_t)
  {
return __t[0];
  }
};
template  struct array
{
  typedef int const_reference;
  typedef int size_type;
  typedef A _AT_Type;
  typename _AT_Type::_Type _M_elems;
  constexpr const_reference operator[](size_type) const
  {
return _AT_Type::_S_ref (_M_elems, 0);
  }
};
}

constexpr auto make_array (int val)
{
  std::array result{ val, 0 };
  return result;
}

constexpr auto numbers_static = make_array (1);
int
main ()
{
  static_assert (numbers_static[0], "");
}

markus@x4 tmp % clang++ -std=c++14 te3.ii
markus@x4 tmp % g++ -std=c++14 te3.ii
te3.ii: In function ‘int main()’:
te3.ii:36:3: error: static assertion failed: 
   static_assert (numbers_static[0], "");
   ^

[Bug go/67101] mprof.goc:408:5: error: calling ‘__builtin_frame_address’ with a nonzero argument is unsafe [-Werror=frame-address]

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||ian at airs dot com
 Resolution|--- |FIXED

--- Comment #3 from Ian Lance Taylor  ---
Fixed.  Thanks.

[Bug c++/67104] Constant expression factory function initializes std::array with static storage duration strangely

[moritz at klammler dot eu]

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

--- Comment #3 from Moritz Klammler  ---
Note that the following slightly modified program passes all assertions and
behaves identical when compiled with either GCC or Clang.

#include 
#include 

namespace /* anonymous */
{

  constexpr auto
  make_array(const int val1, const int val2) noexcept
  {
std::array result = { { val1, val2 } };
return result;
  }

  constexpr auto numbers_static = make_array(42, 0);

}

int
main()
{
  const auto numbers_automatic = make_array(42, 0);
  assert(numbers_automatic[0] == 42);  // okay
  assert(numbers_static[0] == 42); // okay
}

[Bug c++/67070] [concepts] Concept with negation and disjunction not checked correctly

[jason at gcc dot gnu.org]

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

--- Comment #9 from Jason Merrill  ---
(In reply to Andrew Sutton from comment #7)
> I don't think this is a good idea, but mostly because I'm not sure what the
> instantiation/satisfaction semantics are. Consider:
> 
> template
> concept bool C() { return T::value; }
> 
> template void f(T); // #1
> template void f(T);// #2
> 
> f(0); // ill-formed or #1?
> 
> If you evaluate constraints as expressions, then how is C() instantiated?
> If it's instantiated like a regular function, then the program should be
> ill-formed since we're in a different instantiation context (in exactly the
> same way this would fail for a function with a deduced return type).
> 
> We might alternatively evaluate concept checks by always evaluating them in
> a SFINAE context, and defining, so that C() returns true iff its
> constraint is satisfied. Here, T::value (for int) yields a substitution
> failure and is not satisfied. So #1 is chosen.

Yes, that's a question.  The implementation currently does the latter.

> But these semantics actually do something a little weird for !. It lets you
> write checks for when substitution fails or a constraint is not satisfied.
> 
> template
>   requires !C()
> void g();
> 
> g() is selected whenever C() is not satisfied, or if substitution into
> C() fails. Those semantics were not considered in the original design. A
> predicate constraint should evaluate a valid predicate. Substitution failure
> is a kind of higher-order property of the system.

It seems to me that we should only substitute into C in the process of
satisfaction: in this case, if the type constraint is not satisfied, we don't
substitute into the rhs of &&.  It strikes me as strange that in some cases we
would substitute into both sides and in other cases only one side.

> I'm also worried that evaluating constraints in this way would force us to
> consider extending the logical system to support negation.

I think evaluating constraints in this way is a way to *avoid* needing to
extend the logical system to support negation, by allowing && shortcuts within
evaluation of a single concept.

[Bug go/67101] mprof.goc:408:5: error: calling ‘__builtin_frame_address’ with a nonzero argument is unsafe [-Werror=frame-address]

[ian at gcc dot gnu.org]

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

--- Comment #2 from ian at gcc dot gnu.org  ---
Author: ian
Date: Mon Aug  3 17:54:50 2015
New Revision: 226525

URL: https://gcc.gnu.org/viewcvs?rev=226525&root=gcc&view=rev
Log:
PR go/67101

runtime: Remove call to __builtin_frame_address.

__builtin_frame_address was only supposed to use nonzero arguments
for debugging purposes.  Calling it with nonzero arguments can have
unpredictable results and uses are now marked unsafe when
-Wframe-address is enabled.

Reviewed-on: https://go-review.googlesource.com/13063

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/libgo/runtime/mprof.goc

[Bug c++/67104] Constant expression factory function initializes std::array with static storage duration strangely

[moritz at klammler dot eu]

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

--- Comment #2 from Moritz Klammler  ---
Created attachment 36112
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36112&action=edit
Compiler standard error output

[Bug c++/67104] Constant expression factory function initializes std::array with static storage duration strangely

[moritz at klammler dot eu]

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

--- Comment #1 from Moritz Klammler  ---
Created attachment 36111
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36111&action=edit
Preprocessed source file

[Bug c++/67104] New: Constant expression factory function initializes std::array with static storage duration strangely

[moritz at klammler dot eu]

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

Bug ID: 67104
   Summary: Constant expression factory function initializes
std::array with static storage duration strangely
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: moritz at klammler dot eu
  Target Milestone: ---

Created attachment 36110
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36110&action=edit
Source code to reproduce the problem

The following program -- that, to my best knowledge, is valid C++14 -- if
compiled with GCC fails at the marked assertion.  If compiled with Clang, both
assertions hold.

#include 
#include 

namespace /* anonymous */
{

  constexpr auto
  make_array(const int val) noexcept
  {
std::array result = { { val, 0 } };
return result;
  }

  // Replacing `constexpr` by `const` doesn't change anything.
  constexpr auto numbers_static = make_array(42);

}

int
main()
{
  const auto numbers_automatic = make_array(42);
  assert(numbers_automatic[0] == 42);  // okay
  assert(numbers_static[0] == 42); // fails
}

Attached are the source code, preprocessor output and standard error output
when compiling with GCC 5.1.0 using this command:

$ g++ -std=c++14 -v -save-temps -Wall -Wextra -Werror -pedantic main.cxx

There are no warnings or errors reported by the compiler.

This issue has already been discussed on Stack Overflow where I have posted a
more complicated example to trigger the behavior.

   
https://stackoverflow.com/questions/31762429/initializing-stdarray-with-static-storage-duration-with-a-parameter-pack-expan

The reduced example included in this report is courtesy of Stack Overflow user
Columbo who has also tried different versions of GCC that reproduced the
behavior.

[Bug target/67060] [6 Regression] FAIL: gcc.dg/pr56228.c (test for excess errors)

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from John David Anglin  ---
Fixed.

[Bug c++/66842] libatomic uses multiple locks for locked atomics

[rth at gcc dot gnu.org]

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

--- Comment #7 from Richard Henderson  ---
(In reply to Bin Fan from comment #6)
> Could you clarify what does aliased pages mean? Do you mean the same object
> is mapped into two or more different processes with different virtual
> addresses? And the locks in libatomic are also shared by the processes? Or
> something else?

The same page mapped into the address space more than once.  Of course
I don't mean different processes, as libatomic is *not* an IPC library.
Such a thing is easily constructable via mmap of a file, however.

> This make sense if the above understand of aliased pages is true. However,
> what if the memory is not mapped at page boundaries?

How do you suppose you'd map a page anywhere other than at a page boundary?
That's nonsensical.  Virtual address spaces don't work that way.

> And this does not explain why a locked object is protected by multiple
> locks. If memory is always mapped at edge boundaries, then the offset of the
> object in the page will always be the same so one lock should work. If
> memory is not mapped at page boundaries, then if an object is mapped into
> two "non-overlapped" address space inside a page, multiple locks would still
> don't work.

...

> Besides aliased pages, does libatomic consider supporting nested locked
> atomic objects? For example, should the following work?
> 
> typedef struct {
>   _Atomic locked1_t obj1;
>   /* other fields */
> } locked2_t;
> 
> _Atomic locked2_t obj2;

Yes.  The end address cannot be inferred from the start address.  Thus we
lock every cacheline the object overlaps.

[Bug rtl-optimization/67103] [6 Regression]: gcc.target/i386/cmov2.c and gcc.target/i386/cmov3.c FAIL on x86

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-08-03
 CC||ktkachov at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org
 Ever confirmed|0   |1
  Known to fail||6.0

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Mine.

[Bug rtl-optimization/67103] [6 Regression]: gcc.target/i386/cmov2.c and gcc.target/i386/cmov3.c FAIL on x86

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Target||x86
   Target Milestone|--- |6.0

[Bug rtl-optimization/67103] New: [6 Regression]: gcc.target/i386/cmov2.c and gcc.target/i386/cmov3.c FAIL on x86

[ubizjak at gmail dot com]

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

Bug ID: 67103
   Summary: [6 Regression]: gcc.target/i386/cmov2.c and
gcc.target/i386/cmov3.c FAIL on x86
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

Revision r226491 :

[RTL-ifcvt] Improve conditional select ops on immediates

* ifcvt.c (noce_try_store_flag_constants): Make logic of the case
when diff == STORE_FLAG_VALUE or diff == -STORE_FLAG_VALUE more
explicit.  Prefer to add the flag whenever possible.
(noce_process_if_block): Try noce_try_store_flag_constants before
noce_try_cmove.

* gcc.target/aarch64/csel_bfx_1.c: New test.
* gcc.target/aarch64/csel_imms_inc_1.c: Likewise.

introduced following testsuite failures on x86:

FAIL: gcc.target/i386/cmov2.c scan-assembler sbb
FAIL: gcc.target/i386/cmov3.c scan-assembler cmov[^3]

The report and a discussion is at [1].

[1] https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00056.html

[Bug target/67060] [6 Regression] FAIL: gcc.dg/pr56228.c (test for excess errors)

[danglin at gcc dot gnu.org]

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

--- Comment #3 from John David Anglin  ---
Author: danglin
Date: Mon Aug  3 17:32:08 2015
New Revision: 226524

URL: https://gcc.gnu.org/viewcvs?rev=226524&root=gcc&view=rev
Log:
PR target/67060
* config/pa/pa.md (call_reg_64bit): Remove reg:DI 1 clobber.
Adjust splits to match new pattern.


Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/pa/pa.md

[Bug target/67060] [6 Regression] FAIL: gcc.dg/pr56228.c (test for excess errors)

[danglin at gcc dot gnu.org]

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

--- Comment #2 from John David Anglin  ---
Author: danglin
Date: Mon Aug  3 17:29:22 2015
New Revision: 226523

URL: https://gcc.gnu.org/viewcvs?rev=226523&root=gcc&view=rev
Log:
PR target/67060
* config/pa/pa.md (call_reg_64bit): Remove reg:DI 1 clobber.
Adjust splits to match new pattern.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/pa/pa.md

[Bug target/67060] [6 Regression] FAIL: gcc.dg/pr56228.c (test for excess errors)

[danglin at gcc dot gnu.org]

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

--- Comment #1 from John David Anglin  ---
Author: danglin
Date: Mon Aug  3 17:26:19 2015
New Revision: 226522

URL: https://gcc.gnu.org/viewcvs?rev=226522&root=gcc&view=rev
Log:
PR target/67060
* config/pa/pa.md (call_reg_64bit): Remove reg:DI 1 clobber.
Adjust splits to match new pattern.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/pa/pa.md

[Bug fortran/66942] trans-expr.c:5701 runtime error: member call on null pointer of type 'struct vec'

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |5.3

--- Comment #12 from kargl at gcc dot gnu.org ---
Fixed on trunk and 5-branch.  Thanks for the bug report.

[Bug fortran/66942] trans-expr.c:5701 runtime error: member call on null pointer of type 'struct vec'

[kargl at gcc dot gnu.org]

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

--- Comment #11 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Aug  3 17:17:51 2015
New Revision: 226521

URL: https://gcc.gnu.org/viewcvs?rev=226521&root=gcc&view=rev
Log:
2015-08-03  Steven G. Kargl  

PR fortran/66942
* trans-expr.c (gfc_conv_procedure_call): Avoid NULL pointer reference

Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/trans-expr.c

[Bug target/66731] vnmul, fnmul patterns incorrect for -frounding-math

[nsz at gcc dot gnu.org]

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

--- Comment #6 from nsz at gcc dot gnu.org ---
Author: nsz
Date: Mon Aug  3 17:04:29 2015
New Revision: 226519

URL: https://gcc.gnu.org/viewcvs?rev=226519&root=gcc&view=rev
Log:
Backport form mainline r226496.

gcc:

Backport form mainline r226496.
2015-08-03  Szabolcs Nagy  

PR target/66731
* config/arm/vfp.md (negmuldf3_vfp): Add new pattern.
(negmulsf3_vfp): Likewise.
(muldf3negdf_vfp): Disable for -frounding-math.
(mulsf3negsf_vfp): Likewise.
* config/arm/arm.c (arm_new_rtx_costs): Fix NEG cost for VNMUL,
fix MULT cost with -frounding-math.

gcc/testsuite:

Backport form mainline r226496.
2015-08-03  Szabolcs Nagy  

PR target/66731
* gcc.target/arm/vnmul-1.c: New.
* gcc.target/arm/vnmul-2.c: New.
* gcc.target/arm/vnmul-3.c: New.
* gcc.target/arm/vnmul-4.c: New.


Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/vnmul-1.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/vnmul-2.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/vnmul-3.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/vnmul-4.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/arm/arm.c
branches/gcc-4_9-branch/gcc/config/arm/vfp.md
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug fortran/66942] trans-expr.c:5701 runtime error: member call on null pointer of type 'struct vec'

[kargl at gcc dot gnu.org]

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

--- Comment #10 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Aug  3 16:56:39 2015
New Revision: 226517

URL: https://gcc.gnu.org/viewcvs?rev=226517&root=gcc&view=rev
Log:
2015-08-03  Steven G. Kargl  

PR fortran/66942
* trans-expr.c (gfc_conv_procedure_call): Avoid NULL pointer reference

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c

[Bug c++/67094] Compiling and linking through compiler driver with '-x c++' fails to link with stream of errors

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #6 from Manuel López-Ibáñez  ---
(In reply to Jeffrey Walton from comment #4)
> Andrew/Everyone(In reply to Andrew Pinski from comment #1)
> If the document is accurate and I am parsing it correctly, then -x only
> applies to:

What it is trying to say is "the effect of -x only applies to the files that
appear in the command line on the right side of it and up to the next -x
option". The description of -x none talks of "subsequent files". I'm not sure
how to best phrase it, but suggestions are welcome in gcc-patches@ (with CC to
the doc maintainers, Sandra is quite good a phrasing things clearly).

[Bug tree-optimization/67077] [6 Regression] Incorrect "array subscript is above array bounds" warning with -O2

[hjl at gcc dot gnu.org]

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

--- Comment #2 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Mon Aug  3 16:58:03 2015
New Revision: 226518

URL: https://gcc.gnu.org/viewcvs?rev=226518&root=gcc&view=rev
Log:
Add a testcase for PR tree-optimization/67077

PR tree-optimization/67077
* gcc.dg/pr67077.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr67077.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/67094] Compiling and linking through compiler driver with '-x c++' fails to link with stream of errors

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
"Specify explicitly the language for the following input files (rather than
letting the compiler choose a default based on the file name suffix). This
option applies to all following input files until the next -x option. Possible
values for language are:"

"Following input files" seems confusing the first time I read it but the second
time I read it, I read it as the input files that are after the -x option
rather than the types listed below.

Hopefully that makes better sense.

[Bug c++/67094] Compiling and linking through compiler driver with '-x c++' fails to link with stream of errors

[noloader at gmail dot com]

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

--- Comment #4 from Jeffrey Walton  ---
Andrew/Everyone(In reply to Andrew Pinski from comment #1)
> -x c++ means the input is c++ source no matter what the extension.

Sorry to revisit this...

According to the GCC docs, GCC should not be changing the input file type of
object files. See "-x language" topic at
https://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html#Overall-Options.

If the document is accurate and I am parsing it correctly, then -x only applies
to:

c  c-header  cpp-output
c++  c++-header  c++-cpp-output
objective-c  objective-c-header  objective-c-cpp-output
objective-c++ objective-c++-header objective-c++-cpp-output
assembler  assembler-with-cpp
ada
f77  f77-cpp-input f95  f95-cpp-input
go
java

In the end, I know you are right. So I guess that explains why I thought -x
applied to source files, and not object files.

[Bug middle-end/66314] [6 Regression] ice in verify_loop_structure

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #13 from Jeffrey A. Law  ---
Fixed on trunk

[Bug gcov-profile/66899] [6 Regression] ICE when compiling pkcs7_trust.c in Linux

[law at gcc dot gnu.org]

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

--- Comment #6 from Jeffrey A. Law  ---
Author: law
Date: Mon Aug  3 16:26:13 2015
New Revision: 226516

URL: https://gcc.gnu.org/viewcvs?rev=226516&root=gcc&view=rev
Log:
PR middle-end/66314
PR gcov-profile/66899
* tree-ssa-threadupdate.c (mark_threaded_blocks): Correctly
iterate over the jump threading paths when an element in the
jump threading paths array is eliminated.

PR middle-end/66314
PR gcov-profile/66899
* gcc.dg/pr66899.c: New test.
* gcc.dg/pr66314.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr66314.c
trunk/gcc/testsuite/gcc.dg/pr66899.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-threadupdate.c

[Bug middle-end/66314] [6 Regression] ice in verify_loop_structure

[law at gcc dot gnu.org]

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

--- Comment #12 from Jeffrey A. Law  ---
Author: law
Date: Mon Aug  3 16:26:13 2015
New Revision: 226516

URL: https://gcc.gnu.org/viewcvs?rev=226516&root=gcc&view=rev
Log:
PR middle-end/66314
PR gcov-profile/66899
* tree-ssa-threadupdate.c (mark_threaded_blocks): Correctly
iterate over the jump threading paths when an element in the
jump threading paths array is eliminated.

PR middle-end/66314
PR gcov-profile/66899
* gcc.dg/pr66899.c: New test.
* gcc.dg/pr66314.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr66314.c
trunk/gcc/testsuite/gcc.dg/pr66899.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-threadupdate.c

[Bug c/67093] incorrect -Wnonnull text for execl family of functions

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
execl is a GCC builtin and GCC issues the -Wformat warning regardless of its
declaration:

$ cat t.c && ~/bin/gcc-5.1.0/bin/gcc -Wall t.c
extern int execl (const char*, const char*, ...);

int main (void) {
return execl ("/bin/echo", (char*)0);
}
t.c: In function ‘main’:
t.c:4:5: warning: not enough variable arguments to fit a sentinel [-Wformat=]
 return execl ("/bin/echo", (char*)0);
 ^

You're right though that the -Wnonnull warning is due to the nonnull attribute.

[Bug middle-end/67034] [6 Regression] FAIL: gcc.c-torture/compile/pr39928-1.c

[aoliva at gcc dot gnu.org]

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

--- Comment #4 from Alexandre Oliva  ---
Ok, it looks like that idea worked, at least on ppc64 and ppc64el; it's
available in the current git branch aoliva/pr64164.  Would you please give it a
try on pa when you have a chance?  Thanks in advance,

[Bug libstdc++/67078] [6 Regression] FAIL: 24_iterators/container_access.cc (test for excess errors) on aarch64-none-elf

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Jonathan Wakely  ---
.

[Bug libstdc++/67078] [6 Regression] FAIL: 24_iterators/container_access.cc (test for excess errors) on aarch64-none-elf

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Mon Aug  3 15:56:17 2015
New Revision: 226515

URL: https://gcc.gnu.org/viewcvs?rev=226515&root=gcc&view=rev
Log:
PR libstdc++/67078
* include/bits/range_access.h (size, empty, data): Fix _N bad name.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/range_access.h

[Bug libstdc++/67078] [6 Regression] FAIL: 24_iterators/container_access.cc (test for excess errors) on aarch64-none-elf

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

--- Comment #2 from Jonathan Wakely  ---
Fixed.

[Bug c/67093] incorrect -Wnonnull text for execl family of functions

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Surely GCC only warns here because glibc adds the attribute to the execl
declaration, so the bug is in glibc.

GCC interprets the nonnull attribute to mean the argument *must* be non-null,
and even optimises based on that assumption. So the attribute should not be
used for recommendations, only requirements.

[Bug c++/67064] Register asm variable broken

[jason at gcc dot gnu.org]

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

--- Comment #17 from Jason Merrill  ---
(In reply to Daniel Gutson from comment #15)
> (In reply to Jason Merrill from comment #14)
> >  '-Wpedantic' does not cause warning messages for use of the
> >  alternate keywords whose names begin and end with '__'.
> 
> Do you refer to the __asm__?

Yes.  I don't think we should warn about __asm__ either by default or with
-pedantic, though perhaps there should be an even-more-pedantic mode that
complains about __keywords__ outside system headers.

For the original bug, I think force_paren_expr needs to ignore
DECL_HARD_REGISTER variables.

(In reply to Jens Maurer from comment #16)
> Agreed, but this:
> 
> struct s {
>   int i;
> };
> register struct s *reg asm( "si" );
> 
> (note: no double underscores) should issue a diagnostic for violating
> 7.1.1p2 when invoking
> 
> > g++ -std=c++14 -Wall -Wextra -Wpedantic -c reg-asm.cc 
> 
> right?  It doesn't.  Total silence.

Yes, that should give a pedwarn.

[Bug target/63679] [5/6 Regression][AArch64] Failure to constant fold.

[alalaw01 at gcc dot gnu.org]

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

--- Comment #37 from alalaw01 at gcc dot gnu.org ---
Hmmm, no it's not the hashing - that pretty much ignores all types. It's the
comparison in hashable_expr_equal_p, which just uses operand_equal_p,
specifically this part (in fold-const.c):

case MEM_REF:
  /* Require equal access sizes, and similar pointer types.
 We can have incomplete types for array references of
 variable-sized arrays from the Fortran frontend
 though.  Also verify the types are compatible.  */
  if (!((TYPE_SIZE (TREE_TYPE (arg0)) == TYPE_SIZE (TREE_TYPE (arg1))
   || (TYPE_SIZE (TREE_TYPE (arg0))
   && TYPE_SIZE (TREE_TYPE (arg1))
   && operand_equal_p (TYPE_SIZE (TREE_TYPE (arg0)),
   TYPE_SIZE (TREE_TYPE (arg1)),
flags)))
  && types_compatible_p (TREE_TYPE (arg0), TREE_TYPE (arg1))
  && ((flags & OEP_ADDRESS_OF)
  || (alias_ptr_types_compatible_p
(TREE_TYPE (TREE_OPERAND (arg0, 1)),
 TREE_TYPE (TREE_OPERAND (arg1, 1)))
  && (MR_DEPENDENCE_CLIQUE (arg0)
  == MR_DEPENDENCE_CLIQUE (arg1))
  && (MR_DEPENDENCE_BASE (arg0)
  == MR_DEPENDENCE_BASE (arg1))
  && (TYPE_ALIGN (TREE_TYPE (arg0))
== TYPE_ALIGN (TREE_TYPE (arg1)))

specifically, a pointer to int, and a pointer to an array of int, are not
alias_ptr_types_compatible_p. (I'm not clear that they should be, either!?)

[Bug libffi/67102] New: Parallel build fails in libffi/configure

[dilyan.palauzov at aegee dot org]

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

Bug ID: 67102
   Summary: Parallel build fails in libffi/configure
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libffi
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dilyan.palauzov at aegee dot org
  Target Milestone: ---

I configure gcc with

/git/gcc/configure --enable-host-shared --enable-threads=posix
--enable-languages=all --enable-targets=all --enable-nls
--with-linker-hash-style=gnu --enable-interpreter --enable-libgcj-multifile
--with-system-zlib --enable-browser-plugin --without-x
--with-mtune=arm1176jzf-s --with-arch=armv6kz
--target=armv6kz-hardfloat-linux-gnueabi --with-fpu=vfp --with-float=hard
--with-sysroot=/raspberryOS/

and then do "make -j4".  It fails in
armv6kz-hardfloat-linux-gnueabi/libffi/configure (/lib/cpp as preprocessor not
found).  My preprocessor is "/usr/local/bin/cpp" on $PATH, not /lib/cpp 

Sequential build does not have this problem.

This is possibly a duplicate of PR65726.

-- armv6kz-hardfloat-linux-gnueabi/libffi/config.log --

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by libffi configure 3.9, which was
generated by GNU Autoconf 2.64.  Invocation command line was

  $ /git/gcc/libffi/configure --srcdir=/git/gcc/libffi
--cache-file=./config.cache --enable-multilib
--with-cross-host=x86_64-pc-linux-gnu --enable-host-shared
--enable-threads=posix --enable-targets=all --enable-nls
--with-linker-hash-style=gnu --enable-interpreter --enable-libgcj-multifile
--with-system-zlib --enable-browser-plugin --without-x
--with-mtune=arm1176jzf-s --with-arch=armv6kz --with-fpu=vfp --with-float=hard
--with-sysroot=/raspberryOS/ --enable-languages=c,c++,fortran,java,lto,objc
--program-transform-name=s&^&armv6kz-hardfloat-linux-gnueabi-&
--disable-option-checking --with-target-subdir=armv6kz-hardfloat-linux-gnueabi
--build=x86_64-pc-linux-gnu --host=armv6kz-hardfloat-linux-gnueabi
--target=armv6kz-hardfloat-linux-gnueabi

## - ##
## Platform. ##
## - ##

hostname = Ric
uname -m = x86_64
uname -r = 3.16.0-4-amd64
uname -s = Linux
uname -v = #1 SMP Debian 3.16.7-ckt11-1+deb8u2 (2015-07-17)

/usr/bin/uname -p = unknown
/bin/uname -X = unknown

/bin/arch  = unknown
/usr/bin/arch -k   = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo  = unknown
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

PATH: /usr/local/bin
PATH: /usr/bin
PATH: /bin
PATH: /usr/local/games
PATH: /usr/games


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

configure:2452: creating cache ./config.cache
configure:2596: checking build system type
configure:2610: result: x86_64-pc-linux-gnu
configure:2630: checking host system type
configure:2643: result: armv6kz-hardfloat-linux-gnueabi
configure:2663: checking target system type
configure:2676: result: armv6kz-hardfloat-linux-gnueabi
configure:2721: checking for a BSD-compatible install
configure:2789: result: /usr/bin/install -c
configure:2800: checking whether build environment is sane
configure:2850: result: yes
configure:2899: checking for armv6kz-hardfloat-linux-gnueabi-strip
configure:2926: result: armv6kz-hardfloat-linux-gnueabi-strip
configure:2991: checking for a thread-safe mkdir -p
configure:3030: result: /bin/mkdir -p
configure:3043: checking for gawk
configure:3070: result: gawk
configure:3081: checking whether make sets $(MAKE)
configure:3103: result: yes
configure:3189: checking for makeinfo
configure:3216: result: makeinfo --split-size=500
configure:3226: checking for modern makeinfo
configure:3241: result: yes
configure:3264: checking generated-files-in-srcdir
configure:3277: result: no
configure:3306: checking for armv6kz-hardfloat-linux-gnueabi-gcc
configure:: result: /home/d/rasbperry/gcc/./gcc/xgcc
-B/home/d/rasbperry/gcc/./gcc/
-B/usr/local/armv6kz-hardfloat-linux-gnueabi/bin/
-B/usr/local/armv6kz-hardfloat-linux-gnueabi/lib/ -isystem
/usr/local/armv6kz-hardfloat-linux-gnueabi/include -isystem
/usr/local/armv6kz-hardfloat-linux-gnueabi/sys-include   
configure:3602: checking for C compiler version
configure:3611: /home/d/rasbperry/gcc/./gcc/xgcc -B/home/d/rasbperry/gcc/./gcc/
-B/usr/local/armv6kz-hardfloat-linux-gnueabi/bin/
-B/usr/local/armv6kz-hardfloat-linux-gnueabi/lib/ -isystem
/usr/local/armv6kz-hardfloat-linux-gnueabi/include -isystem
/usr/local/armv6kz-hardfloat-linux-gnueabi/sys-include    --version >&5
xgcc (GCC) 6.0.0 20150803 (experimental)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:3622: $? = 0
configure:3611: /ho

[Bug libstdc++/67078] [6 Regression] FAIL: 24_iterators/container_access.cc (test for excess errors) on aarch64-none-elf

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
_N is a BADNAME listed in
https://gcc.gnu.org/onlinedocs/libstdc++/manual/source_code_style.html -- fix
coming up ...

[Bug libstdc++/67082] FAIL: tr1/8_c_compatibility/complex/functions.cc (test for excess errors)

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Since nothing relevant has changed in libstdc++ I think this must be a front
end regression, but you might need to bisect to narrow it down to a more
specific range of commits.

[Bug libstdc++/67096] libstdc++ testsuite, codecvt: many UTF-8 tests illegal (testing bytes 5 and 6)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-08-03
 Ever confirmed|0   |1

[Bug c/67093] incorrect -Wnonnull text for execl family of functions

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
The requirements on execl() and main() are specified in sufficient detail to
guarantee that a program that call execl("/some/other/program", (char*)0) is
portable across all conforming implementations so long as /some/other/program
doesn't assume that argv[0] is non-null.

Issuing a warning in this case is useful because programs often do make this
assumption (including some utilities that are part of an implementation --
e.g., /bin/echo on Linux, see below).  That is why applications that assume
that it's safe to pass null as arg0 is safe "cannot be assured to be portable
across conforming implementations."  (I.e., the utilities themselves aren't
strictly conforming C programs.)

What this issue points out is not that the warning is wrong but that its text
isn't strictly speaking correct: passing a non-null arg0 is not required, only
recommended.

$ cat t.c && gcc t.c && ./a.out 
#include 

int main (void) {
return execl ("/bin/echo", (char*)0);
}
A NULL argv[0] was passed through an exec system call.
Aborted (core dumped)

This is a C conformance bug in /bin/echo since there is no requirement that
argv[0] be non-null.

Why do I point this out?  Because the use of the word "required" in the text of
the warning perpetuates the widespread misconception that argv[0] is guaranteed
to be non-null.  The programs that should be fixed are those that make this
assumption.   Calling execl with a non-null arg0 just works around the bug.

[Bug rtl-optimization/67029] [5/6 regression] gcc-5.2.0 unable to find a register to spill with O3 fsched-pressure fschedule-insns

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||rdsandiford at googlemail dot 
com

--- Comment #9 from H.J. Lu  ---
It was caused by r216554.

[Bug go/67101] mprof.goc:408:5: error: calling ‘__builtin_frame_address’ with a nonzero argument is unsafe [-Werror=frame-address]

[cmang at google dot com]

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

Chris Manghane  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-08-03
   Assignee|ian at airs dot com|cmang at google dot com
 Ever confirmed|0   |1

--- Comment #1 from Chris Manghane  ---
Hi, thanks for reporting this. This is being addressed in golang.org/cl/13063.

[Bug go/67101] New: mprof.goc:408:5: error: calling ‘__builtin_frame_address’ with a nonzero argument is unsafe [-Werror=frame-address]

[gary at intrepid dot com]

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

Bug ID: 67101
   Summary: mprof.goc:408:5: error: calling
‘__builtin_frame_address’ with a nonzero argument is
unsafe [-Werror=frame-address]
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: gary at intrepid dot com
CC: cmang at google dot com
  Target Milestone: ---

For a full bootstrap build, we also build Go and Fortran.  In today's merge
with trunk, the bootstrap failed, due to this error.

/eng/upc/dev/gary/gupc-merge/src/gupc/libgo/runtime/mprof.goc: In function
‘runtime_Stack’:
/eng/upc/dev/gary/gupc-merge/src/gupc/libgo/runtime/mprof.goc:408:5: error:
calling ‘__builtin_frame_address’ with a nonzero argument is unsafe
[-Werror=frame-address]
  sp = runtime_getcallersp(&b);
 ^
cc1: all warnings being treated as errors
make[4]: *** [mprof.lo] Error 1
make[4]: Leaving directory
`/eng/upc/dev/gary/gupc-merge/bld/packed-opt/x86_64-pc-linux-gnu/libgo'

This is likely triggered by the addition of -Wframe-address.

2015-08-02  Martin Sebor  

* c-family/c.opt (-Wframe-address): New warning option.
* doc/invoke.texi (Wframe-address): Document it.
* doc/extend.texi (__builtin_frame_address, __builtin_return_address):
Clarify possible effects of calling the functions with non-zero
arguments and mention -Wframe-address.
* builtins.c (expand_builtin_frame_address): Handle -Wframe-address.

[Bug target/66731] vnmul, fnmul patterns incorrect for -frounding-math

[nsz at gcc dot gnu.org]

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

--- Comment #5 from nsz at gcc dot gnu.org ---
Author: nsz
Date: Mon Aug  3 14:27:43 2015
New Revision: 226507

URL: https://gcc.gnu.org/viewcvs?rev=226507&root=gcc&view=rev
Log:
Backport form mainline r226496.

gcc:

Backport form mainline r226496.
2015-08-03  Szabolcs Nagy  

PR target/66731
* config/arm/vfp.md (negmuldf3_vfp): Add new pattern.
(negmulsf3_vfp): Likewise.
(muldf3negdf_vfp): Disable for -frounding-math.
(mulsf3negsf_vfp): Likewise.
* config/arm/arm.c (arm_new_rtx_costs): Fix NEG cost for VNMUL,
fix MULT cost with -frounding-math.

gcc/testsuite:

Backport form mainline r226496.
2015-08-03  Szabolcs Nagy  

PR target/66731
* gcc.target/arm/vnmul-1.c: New.
* gcc.target/arm/vnmul-2.c: New.
* gcc.target/arm/vnmul-3.c: New.
* gcc.target/arm/vnmul-4.c: New.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/vnmul-1.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/vnmul-2.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/vnmul-3.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/vnmul-4.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/arm/arm.c
branches/gcc-5-branch/gcc/config/arm/vfp.md
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug driver/66732] ISL 0.15 released, has breaking changes to gcc

[timo.gurr at gmail dot com]

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

--- Comment #3 from Timo Gurr  ---
Looks like the patches posted on the mailing list were merged/accepted into
trunk:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=226050

[Bug c++/67100] ICE(in type_dependent_expression_p) on macro function + user defined literal

[tower120 at gmail dot com]

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

--- Comment #3 from tower120  ---
Forgot to say - it's ok with gcc 5.1

[Bug c/67088] Incorrect location of error on invalid type used in bit-field declaration

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Author: mpolacek
Date: Mon Aug  3 13:55:28 2015
New Revision: 226506

URL: https://gcc.gnu.org/viewcvs?rev=226506&root=gcc&view=rev
Log:
PR c/67088
* c-decl.c (check_bitfield_type_and_width): Add location parameter.
Use it.
(grokdeclarator): Pass LOC down to check_bitfield_type_and_width.

* gcc.dg/pr67088.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr67088.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/testsuite/ChangeLog

[Bug c/67088] Incorrect location of error on invalid type used in bit-field declaration

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Marek Polacek  ---
Fixed.

[Bug c++/55095] Wshift-overflow

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

 CC||miyuki at gcc dot gnu.org

--- Comment #16 from Mikhail Maltsev  ---
(In reply to Marek Polacek from comment #15)
> Yea, I'm afraid we'll have to do what you suggest.  And warn for the sign
> bit only when -Wshift-overflow=2.

Actually for me it looks like the correct way to handle this case. I mean, in
c-family/c-common.c we have:

/* Warn if signed left shift overflows.  We don't warn
   about left-shifting 1 into the sign bit in C++14; cf.
   
...

And this check is implemented like this:

  /* Handle the left-shifting 1 into the sign bit case.  */
  if (integer_onep (op0)
  && compare_tree_int (op1, prec0 - 1) == 0)

But in fact, even though the defect report explicitly mentions the "1 << x"
case, the resolution is more general. It says:

...if E1 has a signed type and non-negative value, and E1 ⨯ 2^E2 is
representable in the *corresponding unsigned type of the* result type, then
that *value, converted to the result type,* is the resulting value; otherwise,
the behavior is undefined.

I.e., we should not warn for (0x1f << 27) either, at least when compiling C++14
code. But it seems reasonable to use the same logic for earlier dialects of C++
and C when -Wshift-overflow=1, as it is done now.

[Bug c++/67100] ICE(in type_dependent_expression_p) on macro function + user defined literal

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-08-03
 CC||trippels at gcc dot gnu.org
  Known to work||5.2.0, 6.0
 Ever confirmed|0   |1
  Known to fail||4.9.3

--- Comment #2 from Markus Trippelsdorf  ---
markus@x4 tmp % cat te.ii
template  struct A {};
template  using _tstring = A;
template  _tstring operator""_tstr();
template  struct Dispatcher;
template 
struct Dispatcher {
  template  decltype(0) operator()();
};
int main() { Dispatcher(); }

markus@x4 tmp % /usr/x86_64-pc-linux-gnu/gcc-bin/4.9.3/g++ -std=c++14 te.ii
te.ii: In instantiation of ‘struct Dispatcher, void>’:
te.ii:9:61:   required from here
te.ii:6:36: internal compiler error: in type_dependent_expression_p, at
cp/pt.c:21026

[Bug c++/67070] [concepts] Concept with negation and disjunction not checked correctly

[andrew.n.sutton at gmail dot com]

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

--- Comment #8 from Andrew Sutton  ---
And as an afterthought, adding negation makes the subsumption solver more
complex, since determining implications in the presence of negation would mean
decomposition of both the left and right sides of the implication, and
modifying those term lists whenever negation is encountered.

It's certainly doable, but it's going to add a *lot* of overhead: decomposing
conjunctions on the RHS is the same as disjunctions on the LHS. 

That gets us into ways to heuristically simplify constraints by identifying and
removing tautologies or reducing to contradiction where possible. I don't know
what the overhead of those algorithms are.

[Bug c++/55095] Wshift-overflow

[mpolacek at gcc dot gnu.org]

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

--- Comment #15 from Marek Polacek  ---
Yea, I'm afraid we'll have to do what you suggest.  And warn for the sign bit
only when -Wshift-overflow=2.

[Bug c++/67070] [concepts] Concept with negation and disjunction not checked correctly

[andrew.n.sutton at gmail dot com]

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

--- Comment #7 from Andrew Sutton  ---
We haven't evaluated constraints as expressions in a long time (since
post-Rapperswil I think).

I don't think this is a good idea, but mostly because I'm not sure what the
instantiation/satisfaction semantics are. Consider:

template
concept bool C() { return T::value; }

template void f(T); // #1
template void f(T);// #2

f(0); // ill-formed or #1?

If you evaluate constraints as expressions, then how is C() instantiated? If
it's instantiated like a regular function, then the program should be
ill-formed since we're in a different instantiation context (in exactly the
same way this would fail for a function with a deduced return type).

We might alternatively evaluate concept checks by always evaluating them in a
SFINAE context, and defining, so that C() returns true iff its constraint is
satisfied. Here, T::value (for int) yields a substitution failure and is not
satisfied. So #1 is chosen.

But these semantics actually do something a little weird for !. It let's you
write checks for when substitution fails or a constraint is not satisfied.

template
  requires !C()
void g();

g() is selected whenever C() is not satisfied, or if substitution into
C() fails. Those semantics were not considered in the original design. A
predicate constraint should evaluate a valid predicate. Substitution failure is
a kind of higher-order property of the system.

I'm also worried that evaluating constraints in this way would force us to
consider extending the logical system to support negation. And it's not always
obvious what the semantics of things like:

  !requires { typename T::type; }

would mean. Is it that T::type must not exist? Is it that T::type is not
required to exist? There are very good reasons to select both.

[Bug c++/67100] ICE(in type_dependent_expression_p) on macro function + user defined literal

[tower120 at gmail dot com]

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

--- Comment #1 from tower120  ---
if change 

#define dispatch_forward_fn(fn_name, prefix) \
template \
struct Dispatcher{ /* Problem here tstring(go_up)
*/\
template \
inline decltype(auto) operator() (ArgsRef&&... args) {\
return 0; \
} \
};



with:


#define dispatch_forward_fn(fn_name, prefix) \
template \
using H_##fn_name = tstring(fn_name); \
struct Dispatcher{ \
template \
inline decltype(auto) operator() (ArgsRef&&... args) {\
return 0; \
} \
};

ICE does not occurs.

[Bug c++/67100] New: ICE(in type_dependent_expression_p) on macro function + user defined literal

[tower120 at gmail dot com]

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

Bug ID: 67100
   Summary: ICE(in type_dependent_expression_p) on macro function
+ user defined literal
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tower120 at gmail dot com
  Target Milestone: ---

Live errors : #http://goo.gl/UlaJI7

The following code:
//-

#include 
#include 

#define CAT1(A, B) A ## B
#define CAT(A, B) CAT1(A, B)

#define TOKEN_TO_STRING(TOK) # TOK
#define STRINGIZE_TOKEN(TOK) TOKEN_TO_STRING(TOK)


template 
using _tstring = std::integer_sequence;

template 
constexpr _tstring operator""_tstr() { return { }; }

#define tstring(STR) decltype( CAT( TOKEN_TO_STRING(STR), _tstr) )



#define dispatch_forward_fn(fn_name, prefix) \
template \
struct Dispatcher{ \
template \
inline decltype(auto) operator() (ArgsRef&&... args) {\
return 0; \
} \
};

#define dispatch_list_prefix \
template \
struct Dispatcher; \
dispatch_forward_fn(go_up, _d)


dispatch_list_prefix

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


//-

Produces following error at gcc 4.9.2 (any flags):

/tmp/gcc-explorer-compiler11573-68-zk0erd/example.cpp: In instantiation of
'struct Dispatcher,
void>':
40 : required from here
37 : internal compiler error: in type_dependent_expression_p, at cp/pt.c:21020

[Bug c/67088] Incorrect location of error on invalid type used in bit-field declaration

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-08-03
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Should be easy to fix.

[Bug target/66731] vnmul, fnmul patterns incorrect for -frounding-math

[nsz at gcc dot gnu.org]

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

--- Comment #4 from nsz at gcc dot gnu.org ---
Author: nsz
Date: Mon Aug  3 11:12:00 2015
New Revision: 226496

URL: https://gcc.gnu.org/viewcvs?rev=226496&root=gcc&view=rev
Log:
[ARM] PR target/66731 Fix vnmul insn with -frounding-math

gcc:

PR target/66731
* config/arm/vfp.md (negmuldf3_vfp): Add new pattern.
(negmulsf3_vfp): Likewise.
(muldf3negdf_vfp): Disable for -frounding-math.
(mulsf3negsf_vfp): Likewise.
* config/arm/arm.c (arm_new_rtx_costs): Fix NEG cost for VNMUL,
fix MULT cost with -frounding-math.

gcc/testsuite:

PR target/66731
* gcc.target/arm/vnmul-1.c: New.
* gcc.target/arm/vnmul-2.c: New.
* gcc.target/arm/vnmul-3.c: New.
* gcc.target/arm/vnmul-4.c: New.


Added:
trunk/gcc/testsuite/gcc.target/arm/vnmul-1.c
trunk/gcc/testsuite/gcc.target/arm/vnmul-2.c
trunk/gcc/testsuite/gcc.target/arm/vnmul-3.c
trunk/gcc/testsuite/gcc.target/arm/vnmul-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/config/arm/vfp.md
trunk/gcc/testsuite/ChangeLog

[Bug c++/59716] variadic template multiple parameter pack expansion fails

[lts-rudolph at gmx dot de]

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

--- Comment #1 from Klaus Rudolph  ---
Bug is still present 2015-08-03 ( sorry, can't change "last reconfirmed"
entry?!

[Bug tree-optimization/67077] [6 Regression] Incorrect "array subscript is above array bounds" warning with -O2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Richard Biener  ---
I believe this has been fixed with

2015-07-23  Richard Biener  

PR middle-end/66916
* match.pd: Guard widen and sign-change comparison simplification
with single_use.

[Bug other/67092] bootstrap failure in running genpreds, libstdc++ version mismatch

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
I think we can no longer reliably support host libstdc++ as includes are not
picked up from its location and GCC is C++ now.

I suggest to remove that entirely.

[Bug other/67099] Documentation --with-host-libstdcxx is outdated, mentions ppl

[vries at gcc dot gnu.org]

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

--- Comment #1 from vries at gcc dot gnu.org ---
And given PR67098 - Documentation --with-stage1-ldflags does not mention
default -static-libstdc++ -static-libgcc, even better is:
...
--with-host-libstdcxx=linker-args
Sets default value for --with-stage1-libs and --with-boot-libs. Sets default
value for --with-stage1-ldflags and --with-boot-ldflags to empty.
...

[Bug other/67092] bootstrap failure in running genpreds, libstdc++ version mismatch

[vries at gcc dot gnu.org]

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

--- Comment #12 from vries at gcc dot gnu.org ---
(In reply to vries from comment #11)
> (In reply to vries from comment #10)
> > Looking at the description of with-host-libstdcxx:
> > ...
> > --with-host-libstdcxx=linker-args
> > If you are linking with a static copy of PPL, you can use this option to
> > specify how the linker should find the standard C++ library used internally
> > by PPL. Typical values of linker-args might be ‘-lstdc++’ or
> > ‘-Wl,-Bstatic,-lstdc++,-Bdynamic -lm’. If you are linking with a shared copy
> > of PPL, you probably do not need this option; shared library dependencies
> > will cause the linker to search for the standard C++ library automatically. 
> > ...
> > 
> > We no longer support building with PPL (
> > https://gcc.gnu.org/ml/gcc-patches/2012-06/msg01773.html ), so this doc item
> > probably needs to be updated.
> 
> --with-host-libstdcxx=linker-args
> Sets default value for --with-stage1-libs and --with-boot-libs. Sets default
> value for --with-boot-ldflags to empty.

Filed seperate PR67099 - Documentation --with-host-libstdcxx is outdated,
mentions ppl .

[Bug fortran/64921] [4.9/5/6 Regression] FAIL: gfortran.dg/class_allocate_18.f90

[mikael at gcc dot gnu.org]

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

--- Comment #25 from Mikael Morin  ---
Author: mikael
Date: Mon Aug  3 10:03:55 2015
New Revision: 226493

URL: https://gcc.gnu.org/viewcvs?rev=226493&root=gcc&view=rev
Log:
Fix random class_allocate_18.f90 failure

PR fortran/64921
gcc/fortran/
* class.c (generate_finalization_wrapper): Set finalization
procedure symbol's always_explicit attribute.
gcc/testsuite/
* gfortran.dg/class_allocate_20.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/class_allocate_20.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/class.c
trunk/gcc/testsuite/ChangeLog

[Bug other/67099] New: Documentation --with-host-libstdcxx is outdated, mentions ppl

[vries at gcc dot gnu.org]

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

Bug ID: 67099
   Summary: Documentation --with-host-libstdcxx is outdated,
mentions ppl
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

https://gcc.gnu.org/install/configure.html:
...
--with-host-libstdcxx=linker-args
If you are linking with a static copy of PPL, you can use this option to
specify how the linker should find the standard C++ library used internally by
PPL. Typical values of linker-args might be ‘-lstdc++’ or
‘-Wl,-Bstatic,-lstdc++,-Bdynamic -lm’. If you are linking with a shared copy of
PPL, you probably do not need this option; shared library dependencies will
cause the linker to search for the standard C++ library automatically. 
...

PPL is not supported anymore. The only function of with-host-libstdcxx seems to
be to set other configure flags to a default. So a more accurate doc would be:
...
--with-host-libstdcxx=linker-args
Sets default value for --with-stage1-libs and --with-boot-libs. Sets default
value for --with-boot-ldflags to empty.
...

[Bug other/67098] New: Documentation --with-stage1-ldflags does not mention default -static-libstdc++ -static-libgcc

[vries at gcc dot gnu.org]

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

Bug ID: 67098
   Summary: Documentation --with-stage1-ldflags does not mention
default -static-libstdc++ -static-libgcc
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

https://gcc.gnu.org/install/configure.html:
...
--with-stage1-ldflags=flags
This option may be used to set linker flags to be used when linking stage 1
of GCC. These are also used when linking GCC if configured with
--disable-bootstrap. By default no special flags are used. 
...

But in configure we have:
...
# Linker flags to use for stage1 or when not bootstrapping.

# Check whether --with-stage1-ldflags was given.
if test "${with_stage1_ldflags+set}" = set; then :
  withval=$with_stage1_ldflags; if test "$withval" = "no" -o "$withval" =
"yes"; then
   stage1_ldflags=
 else
   stage1_ldflags=$withval
 fi
else
  stage1_ldflags=
 # In stage 1, default to linking libstdc++ and libgcc statically with GCC
 # if supported.  But if the user explicitly specified the libraries to use,
 # trust that they are doing what they want.
 if test "$stage1_libs" = "" -a "$have_static_libs" = yes; then
   stage1_ldflags="-static-libstdc++ -static-libgcc"
 fi
fi
...

So the doc should be something like:
...
--with-stage1-ldflags=flags
This option may be used to set linker flags to be used when linking stage 1
of GCC. These are also used when linking GCC if configured with
--disable-bootstrap.  If neither –with-stage1-libs nor –with-host-libstdcxx is
set to a value, then the default is ‘-static-libstdc++ -static-libgcc’, if
supported.
...

[Bug target/67089] [4.8/4.9/5/6 Regression] Integer overflow checks not optimized on x86/x86_64

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
(In reply to Mike from comment #2)
> (In reply to Uroš Bizjak from comment #1)
> > We shouldn't do this, and it reflected in PR58779.
> But can't we improve the logic to satisfy both pr58779 and pr67089? The
> absolute metric is code quality, and with all due respect, the code can be
> better in this very case.

I don't see a way. pr58779 will generate:

(set (pc)
(if_then_else (gtu (plus:SI (reg:SI 86 [ D.1769 ])
(const_int -1 [0x]))
(reg:SI 86 [ D.1769 ]))
(label_ref 22)
(pc)))

which can be also represented as:

(set (pc)
(if_then_else (gtu (minus:SI (reg:SI 86 [ D.1769 ])
(const_int 1 [0x1]))
(reg:SI 86 [ D.1769 ]))
(label_ref 22)
(pc)))

and before pr58779 was fixed, these two equivalent insns would result in
swapped condition, as evident from the diff:

 case GTU:  /* CF=0 & ZF=0 */
 case LEU:  /* CF=1 | ZF=1 */
-  /* Detect overflow checks.  They need just the carry flag.  */
-  if (GET_CODE (op0) == MINUS
- && rtx_equal_p (op1, XEXP (op0, 0)))
-   return CCCmode;
-  else
-   return CCmode;
+  return CCmode;

and the part where GTU is emitted:

@@ -14103,8 +14103,6 @@
 Those same assemblers have the same but opposite lossage on cmov.  */
   if (mode == CCmode)
suffix = fp ? "nbe" : "a";
-  else if (mode == CCCmode)
-   suffix = "b";
   else
gcc_unreachable ();
   break;

[Bug target/66312] [SH] Regression: Bootstrap failure gcc/d/ctfeexpr.dmd.o differs with gcc-4.8/4.9

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #10 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #9)
> Yes, maybe.  Please attach.

Ok, please give me a few days :).