[Bug libstdc++/59768] [DR 2219] std::thread constructor not handling reference_wrapper correctly

[cctsai57 at gmail dot com]

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

cctsai57  changed:

   What|Removed |Added

 CC||cctsai57 at gmail dot com

--- Comment #6 from cctsai57  ---
Hi,

Use 'configure CXXFLAGS=-O0' and make gcc successfully, but the generated
libstdc++.so has the following problem:

~ BEGIN ~
$ cat test.cc
int main() { return 0; }

$ g++ test.cc
/work2/gcc-x86_64/local/lib/gcc/x86_64-pc-linux-gnu/6.0.0/../../../../lib64/libstdc++.so:
undefined reference to `std::_Unwrap,
std::decay >::type>::type
std::__invfwd
>(std::remove_reference >::type&)'
collect2: error: ld returned 1 exit status

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/work2/gcc-x86_64/local/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /work2/gcc-x86_64/gcc-src/configure --enable-languages=c,c++
--prefix=/work2/gcc-x86_64/local --disable-bootstrap CXXFLAGS=-O0
Thread model: posix
gcc version 6.0.0 20151222 (experimental) (GCC) 

$ ld -v
GNU ld version 2.25-9.fc22
~END~

I guess that '-O0' causes the '__invfwd' not inlined, and the libstdc++.so
building option '-fno-implicit-templates' causes the '__invfwd' template not
instantiated.  I add 'inline' to '__invfwd' to solve this problem, but I'm
not sure if it's right or not:

diff --git a/libstdc++-v3/include/std/functional
b/libstdc++-v3/include/std/functional
index b994df4..9b853e8 100644
--- a/libstdc++-v3/include/std/functional
+++ b/libstdc++-v3/include/std/functional
@@ -207,7 +207,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   // Used by __invoke_impl instead of std::forward<_Tp> so that a
   // reference_wrapper is converted to an lvalue-reference.
   template
-typename _Unwrap<_Tp>::type
+inline typename _Unwrap<_Tp>::type
 __invfwd(typename remove_reference<_Tp>::type& __t) noexcept
 { return _Unwrap<_Tp>::_S_fwd(__t); }

[Bug debug/68860] [6 regression] FAIL: gcc.dg/guality/pr36728-1.c -O3 -g line 16 arg1 == 1

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
(In reply to Jakub Jelinek from comment #4)
> Created attachment 37097 [details]
> gcc6-pr68860-lto.patch
> 
> I've noticed that the new tests still fail with LTO.
> It seems the reason is that LTO ignores DECL_HAS_DEBUG_ARGS_P etc., so this
> stuff is just lost.
> I've added some changes so that this is streamed, but it seems that is not
> enough, DECL_ORIGIN of the decls is wrong, so it isn't used anyway.
> BTW, Honza, why is:
>   if (code == VAR_DECL
>   && DECL_HAS_DEBUG_EXPR_P (t))
> visit (DECL_DEBUG_EXPR (t));
> used in hash_tree?  Depends on what the function is used for, if it is for
> code generation or something like that, better it should not depend on the
> debug info stuff...

So, the reason why nothing is emitted on the callee side with this patch is
that LTO does never stream DECL_ABSTRACT_ORIGIN, and this is used to double
check the data before actually trying to emit anything.  Perhaps this could be
bypassed by some lto condition, but in any case we'd need a way how to find out
the correspondence between those decl_debug_args decls and the original
arguments that were optimized away.
The reason why nothing is emitted on the caller sides is that for some reason
when streaming in the decl_debug_args, all the DEBUG_EXPR_DECLs turn out to be
D#1, while they really should be D#1, D#2 etc. and the DEBUG_EXPR_DECLs emitted
in the callers before those calls should match them, while they are assigned
independently.

[Bug target/69007] [6 regression] test cases gcc.dg/vect/vect-reduc-dot-s8a.c fails starting with r231815

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |6.0

[Bug c++/69005] [5/6 Regression] infinite(?) recursion in template instantiations

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-22
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |5.4
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r224331 aka PR66289 fix.

[Bug c++/69009] New: ICE in instantiate_decl, at cp/pt.c:21511

[webrown.cpp at gmail dot com]

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

Bug ID: 69009
   Summary: ICE in instantiate_decl, at cp/pt.c:21511
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: webrown.cpp at gmail dot com
  Target Milestone: ---

Created attachment 37101
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37101&action=edit
Preprocessed source

Using g++-mp-6 (MacPorts gcc6 6-20151220_0) 6.0.0 20151220 (experimental)

compiling via
  g++-mp-6 -x c++ -std=c++1z -O3  (plus lots of -W flags)

Preprocessed source attached.

The problem manifested after revising my implementation of tuple_size and
tuple_size_v as outlined below:

template< class T >
constexpr auto
  tuple_size_v = 0;

...
// several tuple_size_v specializations later:

template< class T >
using
  tuple_size = integral_constant>;

[Bug debug/60756] var-tracking selects wrong registers

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  ---
Author: ebotcazou
Date: Tue Dec 22 09:51:02 2015
New Revision: 231897

URL: https://gcc.gnu.org/viewcvs?rev=231897&root=gcc&view=rev
Log:
PR debug/60756
* var-tracking.c (tracked_record_parameter_p): New predicate.
(track_expr_p): Invoke it.
(add_stores): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/var-tracking.c

[Bug debug/60756] var-tracking selects wrong registers

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #5 from Eric Botcazou  ---
The test should pass now.

[Bug target/69008] gcc emits unneeded memory access when passing trivial structs by value (ARM)

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-22
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.8.5, 4.9.4, 5.3.1, 6.0

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed on all versions that I have access to.
The expander emits:
(insn 2 5 3 2 (set (reg:SI 113)
(plus:SI (reg/f:SI 105 virtual-stack-vars)
(const_int -8 [0xfff8]))) missed.c:7 -1
 (nil))
(insn 3 2 4 2 (parallel [
(set (mem/c:SI (reg:SI 113) [1 t+0 S4 A32])
(reg:SI 0 r0))
(set (mem/c:SI (plus:SI (reg:SI 113)
(const_int 4 [0x4])) [1 t+4 S4 A32])
(reg:SI 1 r1))
]) missed.c:7 -1
 (nil))
(note 4 3 7 2 NOTE_INSN_FUNCTION_BEG)
(insn 7 4 8 2 (set (reg:SI 115)
(mem/c:SI (plus:SI (reg/f:SI 105 virtual-stack-vars)
(const_int -8 [0xfff8])) [2 t.i1+0 S4 A32]))
missed.c:8 -1
 (nil))
(insn 8 7 9 2 (set (reg:SI 116)
(mem/c:SI (plus:SI (reg/f:SI 105 virtual-stack-vars)
(const_int -4 [0xfffc])) [2 t.i2+0 S4 A32]))
missed.c:8 -1
 (nil))
(insn 9 8 10 2 (set (reg:SI 114)
(plus:SI (reg:SI 115)
(reg:SI 116))) missed.c:8 -1
 (nil))

[Bug tree-optimization/68756] [6 Regression] ICE w/ -O1 -floop-nest-optimize and isl 0.15: isl-0.15/isl_id.c:213: unable to find id

[asolokha at gmx dot com]

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

--- Comment #3 from Arseny Solokha  ---
The following observations were made w/ gcc-6.0.0-alpha20151220 snapshot.

isl fails w/

> isl-0.15/isl_ctx.c:227: Assertion "ctx->ref > 0" failed

when compiling the following snippet w/ the same options as above:

int s9;
int id[2];

void
aj(void)
{
  int l6, p0, dg, it, gs = 0;
  for (it = 0; it < 2; ++it) {
--gs;
for (s9 = 0; s9 < 2; ++s9) {
  if (gs != 0)
break;
  for (dg = 0; dg < 2; ++dg)
for (p0 = 0; p0 < 2; ++p0)
  for (l6 = 0; l6 < 2; ++l6)
id[l6] = 0;
}
  }
}

After moving s9 declarations into aj() cc1 starts to segfault w/ a new
backtrace:

--- qtcykola.c  2015-12-22 17:00:04.827862358 +0700
+++ eu1fk1op.c  2015-12-22 17:00:39.119531288 +0700
@@ -1,9 +1,9 @@
-int s9;
 int id[2];

 void
 aj(void)
 {
+  int s9;
   int l6, p0, dg, it, gs = 0;
   for (it = 0; it < 2; ++it) {
 --gs;

#0  0x03fff7eefeca in isl_map_dim () from /usr/lib64/libisl.so.15
#1  0x011c3a0a in
translate_isl_ast_to_gimple::get_max_schedule_dimensions(scop*) ()
#2  0x011c3ad9 in
translate_isl_ast_to_gimple::generate_isl_schedule(scop*) ()
#3  0x011c5924 in translate_isl_ast_to_gimple::scop_to_isl_ast(scop*,
std::map,
std::allocator > >&) ()
#4  0x011c9012 in graphite_regenerate_ast_isl(scop*) ()
#5  0x011c0366 in graphite_transform_loops() ()
[trimmed]

Further minimization of these two new testcases yield the same failure as in
#c0.

Another question is, why segfaults in libisl.so aren't propagated to cc1 and,
eventually, to a driver?

[Bug middle-end/68999] [6 Regression]: FAIL: gfortran.fortran-torture/execute/save_1.f90 execution

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
The patch also causes bootstrap failure on alpha-linux-gnu native bootstrap.
Reverting the patch allows bootstrap to finish.

[Bug c++/69009] ICE in instantiate_decl, at cp/pt.c:21511

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-22
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||5.3.0, 6.0

--- Comment #1 from Markus Trippelsdorf  ---
markus@x4 tmp % cat tuple_size.pass.cc
using _uchar = char;
using _size_t = decltype(sizeof(_uchar));
using size_t = _size_t;
template  struct integral_constant;
template  using bool_constant = integral_constant;
template  constexpr auto tuple_size_v = 0;
template  auto const tuple_size_v = tuple_size_v;
template 
using tuple_size = integral_constant>;
template 
using is_base_of = bool_constant<__is_base_of(Base, Deriv)>;
template  void test() {
  is_base_of, tuple_size> value(
  is_base_of, tuple_size>);
}
void foo() { test; }

markus@x4 tmp % g++ -std=c++14 -c tuple_size.pass.cc
tuple_size.pass.cc: In instantiation of ‘void test() [with T = int; long
unsigned int N = 0ul]’:
tuple_size.pass.cc:16:26:   required from here
tuple_size.pass.cc:13:59: internal compiler error: in instantiate_decl, at
cp/pt.c:21511

Both gcc-5 and gcc-6 ICE. gcc-4.9 rejects the testcase.

markus@x4 tmp % clang++ -w -std=c++14 -c tuple_size.pass.cc
markus@x4 tmp %

[Bug c++/69009] ICE in instantiate_decl, at cp/pt.c:21511

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
Dropping "volatile" here "solves" the issue:
 template  auto const tuple_size_v =
tuple_size_v;

[Bug libstdc++/59768] [DR 2219] std::thread constructor not handling reference_wrapper correctly

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Yes it should be inline, I'll fix it, thanks.

[Bug tree-optimization/68707] [6 Regression] testcase gcc.dg/vect/O3-pr36098.c vectorized using VEC_PERM_EXPR rather than VEC_LOAD_LANES

[alalaw01 at gcc dot gnu.org]

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

--- Comment #23 from alalaw01 at gcc dot gnu.org ---
Yes, difficult. I'm conscious that this is stage 3, and worried about adding
too much complexity, especially if we're writing code that we'd eventually drop
in favour of a more complete framework later (i.e. in gcc7).

I'm inclined against

> (I wondered
> if load-lanes would require more unrolling we should prefer SLP anyway?).

As we've seen cases where load-lanes requires more unrolling but the code is
still much better. Likewise your argument against

> to query whether _all_ loads need to be permuted with SLP
...
> thus if there is a load node which is not permuted then retain the SLP.

seems convincing. I think the heuristic in comment 16 handles permutation well
enough, and beyond that, sharing (rather than the permutation) then appears to
be the critical factor. Unfortunately as you say SLP doesn't really handle
sharing yet...so

> I fear that to get a better heuristic
> than what is proposed we need to push this for example to
> vect_make_slp_decision where all instances are built

Might be reasonable, but I fear it'd be of dubious benefit without:

> and we'd need to gather some sharing data therein.

I guess if that were a useful step towards

> But then there is only a small step to the point where we could actually
> compare SLP vs. non-SLP costs.

then there is some justification, but the former feels like too much complexity
at this stage - especially to do it well; how much do we really want to gather
data on the sharing that exists at present, rather than looking at removing
that sharing entirely? I'm thinking of e.g. SLP nodes that are performing the
same computations but with different permutations too - shouldn't we be aiming
at making permutations into first class citizens/operations, and making SLP
trees into DAGs? Longer-term goals, sure...

So my instinct is to go with the comment 16 patch, and accept that we take the
hit in that last testcase (i.e. the one with the sharing).

[Bug target/69010] New: Boolean vector constant with a scalar mode is expanded incorrectly

[ienkovich at gcc dot gnu.org]

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

Bug ID: 69010
   Summary: Boolean vector constant with a scalar mode is expanded
incorrectly
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ienkovich at gcc dot gnu.org
  Target Milestone: ---

Created attachment 37102
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37102&action=edit
Reproducer

Attached testcase fails when is vectorized for AVX-512:

>gcc test.c -O2 -ftree-vectorize -march=skylake-avx512
>sde -- ./a.out
libc: Fatal signal 6 (SIGABRT), code -6 in tid 13272
Aborted (core dumped)

Looking into expand dump we can see vector constant is translated incorrectly:

;; vect__14.9_99 = MASK_LOAD (b_12(D), 4B, { -1, 0, 0, -1, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0 });

(insn 45 44 46 (set (reg:HI 139)
(const_int 255 [0xff])) test.c:10 -1
 (nil))

(insn 46 45 0 (set (reg:V16SI 120 [ vect__14.9 ])
(vec_merge:V16SI (mem:V16SI (reg/v/f:DI 125 [ b ]) [1 MEM[(int
*)b_12(D)]+0 S64 A8])
(reg:V16SI 120 [ vect__14.9 ])
(reg:HI 139))) test.c:10 -1
 (nil))

[Bug libstdc++/59768] [DR 2219] std::thread constructor not handling reference_wrapper correctly

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Author: redi
Date: Tue Dec 22 11:37:07 2015
New Revision: 231900

URL: https://gcc.gnu.org/viewcvs?rev=231900&root=gcc&view=rev
Log:
Add inline to std::__invfwd

PR libstdc++/59768
* include/std/functional (__invfwd): Add inline specifier.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/functional

[Bug fortran/69011] New: [OOP] ICE in gfc_advance_chain for ALLOCATE with SOURCE

[tkoenig at gcc dot gnu.org]

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

Bug ID: 69011
   Summary: [OOP] ICE in gfc_advance_chain for ALLOCATE with
SOURCE
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

This is a cut-down version of an ICE in FOODIE
( https://github.com/Fortran-FOSS-Programmers/FOODiE ).

Might be related to PR 51864, but the error message is different.

ig25@linux-fd1f:~/Advance> cat testcase.f90
module foodie_adt_integrand
implicit none
private
public :: integrand

type, abstract :: integrand
  contains
endtype integrand

abstract interface
endinterface

endmodule foodie_adt_integrand

module foodie_integrator_adams_moulton
use foodie_adt_integrand, only : integrand
implicit none
integer, parameter :: R_P = 4, I_P = 4

private
public :: adams_moulton_integrator

type :: adams_moulton_integrator
  private
  integer(I_P) :: steps=-1 !< Number of time steps.
  real(R_P), allocatable :: b(:) !< \(b\) coefficients.
  contains
procedure, pass(self), public :: integrate !< Integrate integrand field.
endtype adams_moulton_integrator
contains

  subroutine integrate(self, previous)
  class(integrand), intent(INOUT) :: previous(1:) !< Previous time steps
solutions of integrand field.
  class(adams_moulton_integrator), intent(IN) :: self !< Actual AB integrator.
  class(integrand), allocatable :: delta !< Delta RHS for fixex point
iterations.
  allocate(delta, source=previous(self%steps))
  return
  endsubroutine integrate
endmodule foodie_integrator_adams_moulton
ig25@linux-fd1f:~/Advance> gfortran -c testcase.f90
testcase.f90:36:0:

   allocate(delta, source=previous(self%steps))


internal compiler error: in gfc_advance_chain, bei fortran/trans.c:58
0x6e67fb gfc_advance_chain(tree_node*, int)
../../trunk/gcc/fortran/trans.c:58
0x719faf gfc_class_vptr_get(tree_node*)
../../trunk/gcc/fortran/trans-expr.c:149
0x71e795 class_vtab_field_get
../../trunk/gcc/fortran/trans-expr.c:199
0x71e795 gfc_class_vtab_copy_get(tree_node*)
../../trunk/gcc/fortran/trans-expr.c:221
0x71e795 gfc_copy_class_to_class(tree_node*, tree_node*, tree_node*, bool)
../../trunk/gcc/fortran/trans-expr.c:1092
0x76c1e2 gfc_trans_allocate(gfc_code*)
../../trunk/gcc/fortran/trans-stmt.c:5979
0x6e6df7 trans_code
../../trunk/gcc/fortran/trans.c:1836
0x7158c8 gfc_generate_function_code(gfc_namespace*)
../../trunk/gcc/fortran/trans-decl.c:6083
0x6eb4b1 gfc_generate_module_code(gfc_namespace*)
../../trunk/gcc/fortran/trans.c:2054
0x6a1f3d translate_all_program_units
../../trunk/gcc/fortran/parse.c:5599
0x6a1f3d gfc_parse_file()
../../trunk/gcc/fortran/parse.c:5818
0x6e3b62 gfc_be_parse_file
../../trunk/gcc/fortran/f95-lang.c:201
Bitte senden Sie einen vollständigen Fehlerbericht auf Englisch ein;
inclusive vorverarbeitetem Quellcode, wenn es dienlich ist.
Please include the complete backtrace with any bug report.
Siehe  für nähere Anweisungen.

The failed assertion is

#1  0x006e67fc in gfc_advance_chain (t=, n=, n@entry=1) at ../../trunk/gcc/fortran/trans.c:58
58gcc_assert (t != NULL_TREE);

[Bug c++/67376] [5/6 regression] Comparison with pointer to past-the-end of array fails inside constant expression

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
Created attachment 37103
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37103&action=edit
gcc6-pr67376.patch

Untested fix.  The problem is that while fold_binary_loc attempts to
canonicalize the order of arguments, in this case neither argument is a
constant that would be forced into the second argument, so we need to check
both variants, because EQ_EXPR/NE_EXPR is commutative.

Another possibility is to move this folding to match.pd instead, but dunno if
that would be still appropriate for stage3.

There are still other cases that aren't folded:
static_assert (a.e + 1 > a.e, "");
static_assert (a.e < a.e + 1, "");
static_assert (a.e + 2 > a.e, "");
static_assert (a.e < a.e + 2, "");

static_assert (a.e != 0, "");
static_assert (a.e + 1 != 0, "");
static_assert (a.e + 2 != 0, "");

(only the a.e != 0 case is folded).

[Bug target/69012] New: gcc-6.0.0 internal compiler error building libgfortran for mips64el target

[paul.hua.gm at gmail dot com]

--with-multilib-list=32,n32,64 --enable-gnu-indirect-function
--with-long-double-128 --build=mips64el-redhat-linux --with-pkgversion=gcc
20151222 commit: gcc-trunk-231896

[Bug target/69012] gcc-6.0.0 internal compiler error building libgfortran for mips64el target

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
   Severity|critical|normal

[Bug fortran/69013] New: gfortran-5.3.0 ICE in prune_uninit_phi_opnds_in_unrealizable_paths, at tree-ssa-uninit.c:1121

[gnwiii at gmail dot com]

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

Bug ID: 69013
   Summary: gfortran-5.3.0 ICE in
prune_uninit_phi_opnds_in_unrealizable_paths, at
tree-ssa-uninit.c:1121
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gnwiii at gmail dot com
  Target Milestone: ---

Created attachment 37104
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37104&action=edit
source file from ncarg 6.3.0 

Using gcc-5.3.0 from Macports on OS X Mavericks, the command:

/opt/local/bin/gfortran-mp-5 -fPIC -fno-range-check -m64 -Wall  -O2 -c -o
vtcudr.o vtcudr.f

internal compiler error: in prune_uninit_phi_opnds_in_unrealizable_paths, at
tree-ssa-uninit.c:1121

vtcudr.f:1:0: internal compiler error: Abort trap: 6
gfortran-mp-5: internal compiler error: Abort trap: 6 (program f951)
Please submit a full bug report,

This is a regression from macports' gcc-5.2.0.

[Bug fortran/69013] gfortran-5.3.0 ICE in prune_uninit_phi_opnds_in_unrealizable_paths, at tree-ssa-uninit.c:1121

[gnwiii at gmail dot com]

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

--- Comment #1 from George N. White III  ---
Created attachment 37105
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37105&action=edit
log file for test compile

Compile command:

/opt/local/bin/gfortran-mp-5 -v --save-temps -fPIC -fno-range-check -m64 -Wall 
-Os-c -o vtcudr.o vtcudr.f > vtcudr.log 2>&1

[Bug c++/69009] ICE in instantiate_decl, at cp/pt.c:21511

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf  ---
(gdb) l
21505 if (tmpl != gen_tmpl)
21506   /* We should already have the extra args.  */
21507   gcc_assert (TMPL_PARMS_DEPTH (DECL_TEMPLATE_PARMS (gen_tmpl))
21508   == TMPL_ARGS_DEPTH (gen_args));
21509 /* And what's in the hash table should match D.  */
21510 gcc_assert ((spec = retrieve_specialization (gen_tmpl, gen_args, 0))
== d
21511 || spec == NULL_TREE);
21512
21513 /* This needs to happen before any tsubsting.  */
21514 if (! push_tinst_level (d))

(gdb) p debug_tree(d)
 
used static tree_3 external decl_5 decl_6 VOID file tuple_size.pass.cc line
7 col 31
align 8 context 
not-really-extern template-info 0x7720a720>
$10 = void

(gdb) p debug_tree(retrieve_specialization (gen_tmpl, gen_args, 0)) 
 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x771ef9d8 precision
32 min  max >
readonly constant used static tree_1 tree_2 tree_3 decl_1 decl_5 decl_6 SI
file tuple_size.pass.cc line 6 col 33 size  unit
size 
align 32 context  initial

template-info 0x7720a4a0>
$11 = void

[Bug c++/67376] [5/6 regression] Comparison with pointer to past-the-end of array fails inside constant expression

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #37103|0   |1
is obsolete||

--- Comment #9 from Jakub Jelinek  ---
Created attachment 37106
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37106&action=edit
gcc6-pr67376.patch

Better patch, this time it handles also the non-equality comparisons.

[Bug c++/69009] [5/6 Regression] ICE in instantiate_decl, at cp/pt.c:21511

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
Summary|ICE in instantiate_decl, at |[5/6 Regression] ICE in
   |cp/pt.c:21511   |instantiate_decl, at
   ||cp/pt.c:21511

--- Comment #4 from Jakub Jelinek  ---
The ICE started with r226642, before that it has been accepted (r226657 has
been gcc 5 backport thereof).

[Bug c++/69009] [5/6 Regression] ICE in instantiate_decl, at cp/pt.c:21511

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
   Target Milestone|--- |5.4

[Bug target/69007] [6 regression] test cases gcc.dg/vect/vect-reduc-dot-s8a.c fails starting with r231815

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-22
 CC||dje at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug target/68973] [6 regression] Internal compiler error on power for gcc/testsuite/g++.dg/pr67211.C

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-22
 CC||dje at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug middle-end/69013] [5 Regression] gfortran-5.3.0 ICE in prune_uninit_phi_opnds_in_unrealizable_paths, at tree-ssa-uninit.c:1121

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.9.3, 6.0
   Keywords||error-recovery,
   ||ice-on-valid-code
   Last reconfirmed||2015-12-22
  Component|fortran |middle-end
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|gfortran-5.3.0 ICE in   |[5 Regression]
   |prune_uninit_phi_opnds_in_u |gfortran-5.3.0 ICE in
   |nrealizable_paths, at   |prune_uninit_phi_opnds_in_u
   |tree-ssa-uninit.c:1121  |nrealizable_paths, at
   ||tree-ssa-uninit.c:1121
  Known to fail||5.3.0

--- Comment #2 from Dominique d'Humieres  ---
Confirmed with gcc-5.3.0 and gcc-5.3.1. This has been fixed/hidden on trunk
(6.0) between revisions r226476 (2015-08-02, ICE) and r227016 (2015-08-19,
compiles). The minimal set of options on x86_64-apple-darwin14 is '-O -Wall'
(-fPIC -m64 being the default). AFAICT this does not seems a gfortran problem.

[Bug fortran/69011] [6 Regression] [OOP] ICE in gfc_advance_chain for ALLOCATE with SOURCE

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-22
  Known to work||5.3.0
Summary|[OOP] ICE in|[6 Regression] [OOP] ICE in
   |gfc_advance_chain for   |gfc_advance_chain for
   |ALLOCATE with SOURCE|ALLOCATE with SOURCE
 Ever confirmed|0   |1
  Known to fail||6.0

--- Comment #1 from Dominique d'Humieres  ---
The test compiles with trunk (6.0) at revision r229620 (plus two patches) and
gives the ICE at r229621 (plus two patches) or with a clean r229631.

[Bug c/69002] C front end should warn about undefined access to atomic structure or union

[mpolacek at gcc dot gnu.org]

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

--- Comment #9 from Marek Polacek  ---
Author: mpolacek
Date: Tue Dec 22 15:23:21 2015
New Revision: 231902

URL: https://gcc.gnu.org/viewcvs?rev=231902&root=gcc&view=rev
Log:
PR c/69002
* c-typeck.c (build_component_ref): Warn when acessing elements of
atomic structures or unions.

* gcc.dg/c11-atomic-1.c: Add dg-warnings.
* gcc.dg/c11-atomic-4.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/c11-atomic-4.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/c11-atomic-1.c

[Bug c/69002] C front end should warn about undefined access to atomic structure or union

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug target/68937] i686: -fno-plt produces wrong code (maybe only with tailcall)

[uros at gcc dot gnu.org]

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

--- Comment #12 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Dec 22 15:38:25 2015
New Revision: 231903

URL: https://gcc.gnu.org/viewcvs?rev=231903&root=gcc&view=rev
Log:
[PATCH] Use call-clobbered register for sibcall via GOT

From: H.J. Lu  

Since sibcall never returns, we can only use call-clobbered register as
GOT base.  Otherwise, callee-saved register used as GOT base won't be
properly restored.  sibcall_memory_operand is changed to allow 32-bit
GOT slot only with pseudo register as GOT base for RTL expansion.  2
new patterns, *sibcall_GOT_32 and *sibcall_value_GOT_32, are added to
expose GOT base register to register allocator so that call-clobbered
register will be used for GOT base.

gcc/

PR target/68937
* config/i386/i386.c (ix86_function_ok_for_sibcall): Count
call to global function via GOT slot as indirect call.
* config/i386/i386.md (*sibcall_GOT_32): New pattern.
(*sibcall_value_GOT_32): Likewise.
* config/i386/predicates.md (sibcall_memory_operand): Rewrite.
Allow 32-bit GOT slot only with pseudo register as GOT base.
(GOT32_symbol_operand): New predicate.

gcc/testsuite/

PR target/68937
* gcc.target/i386/pr68937-1.c: New test.
* gcc.target/i386/pr68937-2.c: Likewise.
* gcc.target/i386/pr68937-3.c: Likewise.
* gcc.target/i386/pr68937-4.c: Likewise.
* gcc.target/i386/pr68937-5.c: Likewise.
* gcc.target/i386/pr68937-6.c: Likewise.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr68937-1.c
trunk/gcc/testsuite/gcc.target/i386/pr68937-2.c
trunk/gcc/testsuite/gcc.target/i386/pr68937-3.c
trunk/gcc/testsuite/gcc.target/i386/pr68937-4.c
trunk/gcc/testsuite/gcc.target/i386/pr68937-5.c
trunk/gcc/testsuite/gcc.target/i386/pr68937-6.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.md
trunk/gcc/config/i386/predicates.md
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/68964] [6 regression] Internal compiler error for test case gcc.dg/tm/20100610.c since r231674

[rth at gcc dot gnu.org]

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

--- Comment #3 from Richard Henderson  ---
The path on which this test goes off the rails is supposed to only
be used for structure assignments, where memmove must be used, and
thus taking the address of both sides of the assignment will work.

However, support for vector types on ppc and aarch64 appears to be
lacking.  You'll note that this test case does not fail on x86_64,
where we instead produce a call to _ITM_WM128 to perform the store.

Digging into why this function isn't called for aarch64...

[Bug middle-end/69013] [5 Regression] gfortran-5.3.0 ICE in prune_uninit_phi_opnds_in_unrealizable_paths, at tree-ssa-uninit.c:1121

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |5.4

--- Comment #3 from Jakub Jelinek  ---
Stopped being reproduceable with r226901, so most likely just went latent.
Started with r219739 aka PR64614, which has been a tree-ssa-uninit.c change.

[Bug tree-optimization/68964] [6 regression] Internal compiler error for test case gcc.dg/tm/20100610.c since r231674

[rth at gcc dot gnu.org]

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

--- Comment #4 from Richard Henderson  ---
Oh, yes, duh.

These vector types are (at least partially) target-specific, and so the
function definitions are left for the target to fill in at startup time.

See config/i386/i386.c bdesc_tm for MMX/SSE/AVX wonkiness.

I expect it's possible to find a target-independent default for these
function definitions, if the target hook has failed to fill them in.
Perhaps check for target support of N-bit wide vector of SImode, then
N-bit wide vector of SFmode, before failing?

[Bug target/69014] New: [4.9/5/6 Regression] gcc.c-torture/execute/991023-1.c FAILs with -Os -fmodulo-sched -fno-tree-vrp

[zsojka at seznam dot cz]

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

Bug ID: 69014
   Summary: [4.9/5/6 Regression] gcc.c-torture/execute/991023-1.c
FAILs with -Os -fmodulo-sched -fno-tree-vrp
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: armv7a-*-linux-gnueabi

Created attachment 37107
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37107&action=edit
testcase (gcc.c-torture/execute/991023-1.c)

Output:
$ armv7a-hardfloat-linux-gnueabi-gcc -Os -fmodulo-sched -fno-tree-vrp
testcase.c
$ qemu-arm ./a.out 
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted


$ armv7a-hardfloat-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-trunk-231884-checking-yes-rtl-df-nographite-armv7a-hardfloat/bin/armv7a-hardfloat-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-231884-checking-yes-rtl-df-nographite-armv7a-hardfloat/bin/../libexec/gcc/armv7a-hardfloat-linux-gnueabi/6.0.0/lto-wrapper
Target: armv7a-hardfloat-linux-gnueabi
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-checking=yes,rtl,df --without-cloog --without-ppl --without-isl
--with-float=hard --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=armv7a-hardfloat-linux-gnueabi
--with-ld=/usr/bin/armv7a-hardfloat-linux-gnueabi-ld
--with-as=/usr/bin/armv7a-hardfloat-linux-gnueabi-as
--with-sysroot=/usr/armv7a-hardfloat-linux-gnueabi --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-231884-checking-yes-rtl-df-nographite-armv7a-hardfloat
Thread model: posix
gcc version 6.0.0 20151221 (experimental) (GCC) 


Other targets (powerpc[64], aarch64, i686, x86_64, x32) do not have this
problem.

Tested revisions:
r231884 - FAIL
5-branch r231870 - FAIL
4_9-branch r231865 - FAIL
4_8-branch r224828 - OK

[Bug middle-end/68999] [6 Regression]: FAIL: gfortran.fortran-torture/execute/save_1.f90 execution

[ubizjak at gmail dot com]

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

--- Comment #5 from Uroš Bizjak  ---
Created attachment 37108
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37108&action=edit
Proposed patch

There is a logic error in Honza's patch. The part in memrefs_conflict_p should
be changed to:

-  /* If decls are different or we know by offsets that there is no
overlap,
-we win.  */
-  if (!cmp || !offset_overlap_p (c, xsize, ysize))
+  /* If decls are different and we know by offsets that
+there is no overlap, we win.  */
+  if (!cmp && !offset_overlap_p (c, xsize, ysize))
return 0;
-  /* Decls may or may not be different and offsets overlap*/
+  /* Decls are different and offsets overlap*/

Even if decls are different, their offsets shouldn't overlap! Addresses with
AND alignment operands depend on increased xsize and ysize, so no wonder gcc
fails to bootstrap on alpha.

In addition to this, the check for SYMBOL_REFs in base_alias_check should be
moved after checks for AND addresses.

The patch also adds some simplification. If symtab_address::equal_address_to
returns -1 for "unknown" (as is otherwise customary throughout the sources), we
can simplify compare_base_decls a bit.

The patch was bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Currently, the bootstrap on alpha-linux-gnu is running (this target is a
massive user of AND-aligned addresses, and bootstrap already went well beyond
the point of reported bootstrap failure).

[Bug middle-end/68999] [6 Regression]: FAIL: gfortran.fortran-torture/execute/save_1.f90 execution

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #6 from Uroš Bizjak  ---
Let's put this PR on Jeff's radar due to proposed patch.

[Bug fortran/69011] [6 Regression] [OOP] ICE in gfc_advance_chain for ALLOCATE with SOURCE

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tom at codesourcery dot com

--- Comment #2 from Thomas Koenig  ---
Tom,

r229621 was yours.  Any idea what could have brought this about?

[Bug target/69014] [4.9/5/6 Regression] gcc.c-torture/execute/991023-1.c FAILs with -Os -fmodulo-sched -fno-tree-vrp

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-22
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug target/69015] New: ICE: RTL check: expected code 'code_label', have 'return' in find_cond_trap, at ifcvt.c:3715 with -fno-if-conversion and __builtin_trap()

[zsojka at seznam dot cz]

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

Bug ID: 69015
   Summary: ICE: RTL check: expected code 'code_label', have
'return' in find_cond_trap, at ifcvt.c:3715 with
-fno-if-conversion and __builtin_trap()
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: powerpc-unknown-linux-gnu

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

Compiler output:
$ powerpc-unknown-linux-gnu-gcc -O -fno-if-conversion testcase.c 
testcase.c: In function 'foo':
testcase.c:6:1: internal compiler error: RTL check: expected code 'code_label',
have 'return' in find_cond_trap, at ifcvt.c:4576
 }
 ^

0xab3ac7 rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int,
char const*)
/repo/gcc-trunk/gcc/rtl.c:811
0x11bc76b find_cond_trap
/repo/gcc-trunk/gcc/ifcvt.c:4576
0x11bc76b find_if_header
/repo/gcc-trunk/gcc/ifcvt.c:4165
0x11bc76b if_convert
/repo/gcc-trunk/gcc/ifcvt.c:5302
0x11bcb4d execute
/repo/gcc-trunk/gcc/ifcvt.c:5492
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


$ powerpc-unknown-linux-gnu-gcc -v   
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-powerpc/bin/powerpc-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-231884-checking-yes-rtl-df-nographite-powerpc/bin/../libexec/gcc/powerpc-unknown-linux-gnu/6.0.0/lto-wrapper
Target: powerpc-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-checking=yes,rtl,df --without-cloog --without-ppl --without-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=powerpc-unknown-linux-gnu
--with-ld=/usr/bin/powerpc-unknown-linux-gnu-ld
--with-as=/usr/bin/powerpc-unknown-linux-gnu-as
--with-sysroot=/usr/powerpc-unknown-linux-gnu --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-231884-checking-yes-rtl-df-nographite-powerpc
Thread model: posix
gcc version 6.0.0 20151221 (experimental) (GCC) 


Only powerpc[64] target has problems with this testcase.


Tested revisions:
r231884 - FAIL
5-branch r231870 - FAIL
4_9-branch r231865 - FAIL
4_8-branch r224828 - FAIL

[Bug c++/69016] New: In C++14 standard, function with auto as return and arguments returns result with the datatype of first argument only

[emailstorbala at gmail dot com]

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

Bug ID: 69016
   Summary: In C++14 standard, function with auto as return and
arguments returns result with the datatype of first
argument only
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: emailstorbala at gmail dot com
  Target Milestone: ---

Hi Team,

I am using gcc/g++ 4.9.2 version in Debian 8.2. I tried to compile the below
code using the compiler option:

g++ -std=c++14 -s -O3 test.cpp -o test



#include 

using namespace std;

auto GetSum(auto a, auto b)
{
return (a + b);
}


int main()
{
auto temp = GetSum(10, 20.5);
cout << "The sum is " << temp << endl;

return 0;
}



Result:
The sum is 30

If the code is changed to 



#include 

using namespace std;

auto GetSum(auto a, auto b)
{
return (a + b);
}


int main()
{
auto temp = GetSum(10.5, 20);
cout << "The sum is " << temp << endl;

return 0;
}



Result:
The sum is 30.5

Issue: The function GetSum() returns value of the first data type only rather
than the final value's datatype. (Even if I set - auto GetSum(auto a, auto b)
-> double)

Please let me know if I am doing anything wrong.

[Bug c++/67376] [5/6 regression] Comparison with pointer to past-the-end of array fails inside constant expression

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
As for the non-NULL checks,
struct A { int e[2]; };
constexpr A a { { 0, 1 } };
static_assert (a.e != 0, "");
static_assert (&a.e[1] != 0, "");
static_assert (&a.e[2] != 0, "");
static_assert (a.e + 1 != 0, "");
static_assert (a.e + 2 != 0, "");
static_assert (&a.e[-1] != 0, "");
static_assert (&a.e[3] != 0, "");
the first 3 static_asserts are handled by match.pd:
 (simplify
  (cmp (convert? addr@0) integer_zerop)
  (if (tree_single_nonzero_warnv_p (@0, NULL))
   { constant_boolean_node (cmp == NE_EXPR, type); })))
case.  The last two as well, but those are invalid and we really should be
diagnosing that in the C++ FE somewhere.
The a.e + 1 != 0 and a.e + 2 != 0 cases we used to fold them because
try_move_mult_to_index would fold them into ADDR_EXPR of some field, which
intentionally no longer happens.  So, I guess we want instead some
simplification of POINTER_PLUS_EXPR, INTEGER_CST> that
would say use get_inner_reference on something, add (in offset_int?)  the
constant offset to it and determine if it is always non-zero.

The question is what rule should we use.  Any positive constant offset from a
known non-zero base address?  Something different (like only positive constant
offset from 0 up to and including the size of the var)?  Perhaps if the
constant offset modulo alignment of the var is known to be non-zero always, no
matter if the base var has known non-zero base address or not?  Or just
whenever the constant offset is > 0 (or optionally also smaller than size of
the var)?  I mean, for &a.e + 1, even if &a is NULL, &a.e + 1 still would be
non-NULL, unless the a var is partly at the end of the address space and partly
at the beginning.

[Bug c++/69016] In C++14 standard, function with auto as return and arguments returns result with the datatype of first argument only

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-22
  Known to work||6.0
 Ever confirmed|0   |1
  Known to fail||4.9.3, 5.3.0

--- Comment #1 from Jonathan Wakely  ---
This is already fixed on trunk, but not gcc-5

Same issue as Bug 67910 (and at least one other that I can't find now).

[Bug c++/69016] In C++14 standard, function with auto as return and arguments returns result with the datatype of first argument only

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
N.B. this is not actually valid according to the C++ standard. C++14 only
supports auto for the return type, not the parameters. Using placeholder types
for the parameters as well is defined by the Concepts TS, which is only
supported on GCC trunk (which will be GCC 6).

So you are using a non-standard experimental feature in GCC 4.9, which
unfortunately is incomplete and doesn't work for multiple parameters. It might
be fixable, but you might have to wait for GCC 6 to use the Concetps support.

[Bug target/68872] -mcpu=powerpc64le does not pass -mpower8 to gas

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2015-12/msg02054.ht
   ||ml
   Last reconfirmed||2015-12-22
   Assignee|unassigned at gcc dot gnu.org  |bergner at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Peter Bergner  ---
Patch summitted:

  https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02054.html

[Bug c++/69017] New: [cilkplus] ICE with valid cilk_spawn

[ryan.burn at gmail dot com]

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

Bug ID: 69017
   Summary: [cilkplus] ICE with valid cilk_spawn
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryan.burn at gmail dot com
  Target Milestone: ---

The below valid code causes this ICE:

t1.cpp: In function ‘void g()’:
t1.cpp:18:22: internal compiler error: gimplification failed
   b = _Cilk_spawn f2();
  ^

0xd6388a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../src-fix/gcc/gimplify.c:11047
0xd493c6 gimplify_addr_expr
../../src-fix/gcc/gimplify.c:5075
0xd60829 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../src-fix/gcc/gimplify.c:10162
0xd4b2fd gimplify_stmt(tree_node**, gimple**)
../../src-fix/gcc/gimplify.c:5616
0xd48e5e gimplify_compound_expr
../../src-fix/gcc/gimplify.c:4943
0xd48de0 gimplify_compound_expr
../../src-fix/gcc/gimplify.c:4930
0xd6049b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../src-fix/gcc/gimplify.c:10105
0xd4b2fd gimplify_stmt(tree_node**, gimple**)
../../src-fix/gcc/gimplify.c:5616
0xd4a9e5 gimplify_cleanup_point_expr
../../src-fix/gcc/gimplify.c:5392
0xd61c92 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../src-fix/gcc/gimplify.c:10481
0xd4b2fd gimplify_stmt(tree_node**, gimple**)
../../src-fix/gcc/gimplify.c:5616
0xd3c296 gimplify_statement_list
../../src-fix/gcc/gimplify.c:1526
0xd62039 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../src-fix/gcc/gimplify.c:10533
0xd4b2fd gimplify_stmt(tree_node**, gimple**)
../../src-fix/gcc/gimplify.c:5616
0xd38d23 gimplify_and_add(tree_node*, gimple**)
../../src-fix/gcc/gimplify.c:425
0xd619a9 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../src-fix/gcc/gimplify.c:10455
0xd4b2fd gimplify_stmt(tree_node**, gimple**)
../../src-fix/gcc/gimplify.c:5616
0xd3c296 gimplify_statement_list
../../src-fix/gcc/gimplify.c:1526
0xd62039 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../src-fix/gcc/gimplify.c:10533
0xd4b2fd gimplify_stmt(tree_node**, gimple**)
../../src-fix/gcc/gimplify.c:5616
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

///
struct A {  
  A() = default;
  A(const A&) {}
};  

struct B {  
  B() = default;

  B& operator=(A a) {   
  } 
};  

B f() { return {}; }

void g() {  
  B b;  
  b = _Cilk_spawn f();  
}   

int main() {
  g();  
  return 0; 
}  
///

[Bug libitm/69018] New: libitm/testsuite/libitm.c++/c++.exp: libstdc++ include paths don't work if tests set options

[torvald at gcc dot gnu.org]

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

Bug ID: 69018
   Summary: libitm/testsuite/libitm.c++/c++.exp: libstdc++ include
paths don't work if tests set options
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libitm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: torvald at gcc dot gnu.org
  Target Milestone: ---

If a tests sets an option (eg, // { dg-options "-fgnu-tm" }), then the include
paths for C++ std headers set by c++.exp don't work anymore.  Switching the
last two arguments to the "dg-runtest" command close to the end of c++.exp
makes it work, but I don't know whether that's a fix or a workaround.

[Bug target/69015] ICE: RTL check: expected code 'code_label', have 'return' in find_cond_trap, at ifcvt.c:3715 with -fno-if-conversion and __builtin_trap()

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 37110
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37110&action=edit
gcc6-pr69015.patch

Untested fix.

[Bug libitm/69018] libitm/testsuite/libitm.c++/c++.exp: libstdc++ include paths don't work if tests set options

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
You could also just use dg-additional-options instead of dg-options.
But yeah, this sounds to be the issue whether the include flags are added to
flags unconditionally or go just to default flags.

[Bug c++/69017] [cilkplus] ICE with valid cilk_spawn

[ryan.burn at gmail dot com]

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

--- Comment #1 from ryan.burn at gmail dot com ---
Better example:
struct B {  
};  

B f() { return {}; }

void g() {  
  B b;  
  b = _Cilk_spawn f();  
}   

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

[Bug target/68772] Many -gstabs tests FAIL with Xcode 7 as

[bergner at gcc dot gnu.org]

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

--- Comment #2 from Peter Bergner  ---
Author: bergner
Date: Tue Dec 22 19:27:14 2015
New Revision: 231905

URL: https://gcc.gnu.org/viewcvs?rev=231905&root=gcc&view=rev
Log:
gcc/
PR target/68772
* config/rs6000/rs6000.h (ASM_CPU_SPEC): For -mcpu=powerpc64le,
pass %(asm_cpu_power8)/-mpwr8.
* config/rs6000/aix53.h: Likewise.
* config/rs6000/aix61.h: Likewise.
* config/rs6000/aix71.h: Likewise.

gcc/testsuite/
PR target/68772
* gcc.target/powerpc/pr68872.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr68872.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.h
trunk/gcc/testsuite/ChangeLog

[Bug target/69019] New: [5 regression] Failure of test case gcc.target/powerpc/ti_math1.c

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 69019
   Summary: [5 regression] Failure of test case
gcc.target/powerpc/ti_math1.c
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

PASS: gcc.target/powerpc/ti_math1.c (test for excess errors)
PASS: gcc.target/powerpc/ti_math1.c scan-assembler-times addc 1
FAIL: gcc.target/powerpc/ti_math1.c scan-assembler-times adde 1
PASS: gcc.target/powerpc/ti_math1.c scan-assembler-times subfc 1
PASS: gcc.target/powerpc/ti_math1.c scan-assembler-times subfe 1
PASS: gcc.target/powerpc/ti_math1.c scan-assembler-not subf

Seen with gcc-5-branch revision 231903.  I don't know when this started failing

This test works with gcc 4.9 and gcc 6 and works with gcc 5 on big endian.

The problem can be seen here when comparing the assembler from gcc 6 with that
from 5:

seurer@genoa:~/tests/gcc$ diff ti_math1.s.gcc5 ti_math1.s.gcc6
13,14c13
<   addze 5,5
<   add 4,5,10
---
>   adde 4,5,10

It also only occurs with -O2

With -O2:
addze 5,5
add 4,5,10

With -O1:
adde 4,5,10

[Bug target/68872] -mcpu=powerpc64le does not pass -mpower8 to gas

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #3 from Peter Bergner  ---
(In reply to Peter Bergner from comment #2)
> Patch summitted:
> 
>   https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02054.html

Patch committed, but without the aix*.h file hunks.

[Bug ipa/67811] [TM] ICE with try-block in transaction

[rth at gcc dot gnu.org]

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

--- Comment #3 from Richard Henderson  ---
Author: rth
Date: Tue Dec 22 19:42:24 2015
New Revision: 231907

URL: https://gcc.gnu.org/viewcvs?rev=231907&root=gcc&view=rev
Log:
PR ipa/67811

* gimple.h (struct gtransaction): Add label_norm, label_uninst;
replace label with label_over.
(gimple_build_transaction): Remove label parameter.
(gimple_transaction_label_norm): New.
(gimple_transaction_label_uninst): New.
(gimple_transaction_label_over): Rename from gimple_transaction_label.
(gimple_transaction_label_norm_ptr): New.
(gimple_transaction_label_uninst_ptr): New.
(gimple_transaction_label_over_ptr): Rename from
gimple_transaction_label_ptr.
(gimple_transaction_set_label_norm): New.
(gimple_transaction_set_label_uninst): New.
(gimple_transaction_set_label_over): Rename from
gimple_transaction_set_label.
* gimple-pretty-print.c (dump_gimple_transaction): Update.
* gimple-streamer-in.c (input_gimple_stmt) [GIMPLE_TRANSACTION]: Same.
* gimple-streamer-out.c (output_gimple_stmt) [GIMPLE_TRANSACTION]:
Same.
* gimple-walk.c (walk_gimple_op) [GIMPLE_TRANSACTION]: Same.
* tree-cfg.c (make_edges_bb) [GIMPLE_TRANSACTION]: Same.
(cleanup_dead_labels) [GIMPLE_TRANSACTION]: Same.
(verify_gimple_transaction): Same.
(gimple_redirect_edge_and_branch) [GIMPLE_TRANSACTION]: Same.
* tree-inline.c (remap_gimple_stmt) [GIMPLE_TRANSACTION]: Same.
* gimple.c (gimple_build_transaction): Remove label parameter;
initialize all three label memebers.
* gimplify.c (gimplify_transaction): Update call
to gimple_build_transaction.
* trans-mem.c (make_tm_uninst): New.
(lower_transaction): Create uninstrumented code path here...
(ipa_tm_scan_calls_transaction): ... not here.
(ipa_uninstrument_transaction): Remove.

testsuite/
* g++.dg/tm/noexcept-1.C: Update expected must_not_throw count.
* g++.dg/tm/noexcept-4.C: Likewise.
* g++.dg/tm/noexcept-5.C: Likewise.
* g++.dg/tm/pr67811.C: New.

Added:
trunk/gcc/testsuite/g++.dg/tm/pr67811.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-pretty-print.c
trunk/gcc/gimple-streamer-in.c
trunk/gcc/gimple-streamer-out.c
trunk/gcc/gimple-walk.c
trunk/gcc/gimple.c
trunk/gcc/gimple.h
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/tm/noexcept-1.C
trunk/gcc/testsuite/g++.dg/tm/noexcept-4.C
trunk/gcc/testsuite/g++.dg/tm/noexcept-5.C
trunk/gcc/trans-mem.c
trunk/gcc/tree-cfg.c
trunk/gcc/tree-inline.c

[Bug target/68617] arm ice output_operand: invalid %-code for -march=armv6k + thumb

[andreast at gcc dot gnu.org]

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

Andreas Tobler  changed:

   What|Removed |Added

 CC||andreast at gcc dot gnu.org

--- Comment #5 from Andreas Tobler  ---
This commit broke bootstrap on armv6*-*-freebsd*.
Here the proposed fix:

https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02060.html

[Bug c++/67376] [5/6 regression] Comparison with pointer to past-the-end of array fails inside constant expression

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Author: jakub
Date: Tue Dec 22 20:47:58 2015
New Revision: 231909

URL: https://gcc.gnu.org/viewcvs?rev=231909&root=gcc&view=rev
Log:
PR c++/67376
* fold-const.c (size_low_cst): Removed.
(fold_comparison): For POINTER_PLUS_EXPR where base is ADDR_EXPR
call get_inner_reference and handle INDIRECT_REF base of it.  Use
offset_int for computation of the bitpos.
(fold_binary_loc) : Formatting
fixes for X +- Y CMP X and C - X CMP X folding.  Add X CMP X +- Y
and X CMP C - X folding.

* g++.dg/cpp0x/constexpr-67376.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-67376.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/67376] [5/6 regression] Comparison with pointer to past-the-end of array fails inside constant expression

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
The first issue should be fixed for GCC 6+ already, the other one needs further
fixes.  As for backporting this to GCC 5 branch, I think it should be done only
after a few weeks on the trunk.

[Bug target/68772] Many -gstabs tests FAIL with Xcode 7 as

[bergner at gcc dot gnu.org]

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

--- Comment #3 from Peter Bergner  ---
Author: bergner
Date: Tue Dec 22 20:51:12 2015
New Revision: 231910

URL: https://gcc.gnu.org/viewcvs?rev=231910&root=gcc&view=rev
Log:
gcc/
Backport from mainline
PR target/68772
* config/rs6000/rs6000.h (ASM_CPU_SPEC): For -mcpu=powerpc64le,
pass %(asm_cpu_power8).

gcc/testsuite/
Backport from mainline
PR target/68772
* gcc.target/powerpc/pr68872.c: New test.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/powerpc/pr68872.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/rs6000/rs6000.h
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug target/68772] Many -gstabs tests FAIL with Xcode 7 as

[bergner at gcc dot gnu.org]

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

--- Comment #4 from Peter Bergner  ---
Author: bergner
Date: Tue Dec 22 20:52:40 2015
New Revision: 231911

URL: https://gcc.gnu.org/viewcvs?rev=231911&root=gcc&view=rev
Log:
gcc/
Backport from mainline
PR target/68772
* config/rs6000/rs6000.h (ASM_CPU_SPEC): For -mcpu=powerpc64le,
pass %(asm_cpu_power8).

gcc/testsuite/
Backport from mainline
PR target/68772
* gcc.target/powerpc/pr68872.c: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/pr68872.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/rs6000/rs6000.h
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/68872] -mcpu=powerpc64le does not pass -mpower8 to gas

[bergner at gcc dot gnu.org]

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

--- Comment #4 from Peter Bergner  ---
Fix backported to gcc-5-branch and gcc-4_0-branch too.

[Bug target/68872] -mcpu=powerpc64le does not pass -mpower8 to gas

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #5 from Peter Bergner  ---
Closing as fixed.

[Bug c++/69020] New: wrong ADL for attribute cleanup functions

[msebor at gcc dot gnu.org]

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

Bug ID: 69020
   Summary: wrong ADL for attribute cleanup functions
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

While working an a fix for bug 58109 I noticed that the comment in
is_late_template_attribute() suggests that attribute cleanup may not be handled
as one would expect for type-dependent functions:

  /* If the first attribute argument is an identifier, only consider
 second and following arguments.  Attributes like mode, format,
 cleanup and several target specific attributes aren't late
 just because they have an IDENTIFIER_NODE as first argument.  */

The test case below shows that the cleanup attribute ends up resolving the
type-dependent reference to foo to the synonymous member of the dependent class
as opposed to the one at namespace scope as a call to foo does.  All versions
of GCC as far back as 4.5 have this bug.

$ cat b.cpp && /build/gcc-trunk-svn/gcc/xg++ -B /build/gcc-trunk-svn/gcc -Wall
-Wextra -Wpedantic -L
/build/gcc-trunk-svn/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs b.cpp &&
./a.out
extern "C" int printf (const char*, ...);

template  struct A {
static void foo (T*) { printf ("%s\n", __PRETTY_FUNCTION__); }
};

void foo (int*) { printf ("%s\n", __PRETTY_FUNCTION__); }

template  struct B: A {
void bar () {
T a __attribute__ ((cleanup (foo)));   // should invoke ::foo(int*)
printf ("%s calling ", __PRETTY_FUNCTION__);
foo (&a);
printf ("cleanup calling ");
}
};

int main ()
{
B().bar ();
}
void B::bar() [with T = int] calling void foo(int*)
cleanup calling static void A::foo(T*) [with T = int]

[Bug c++/69020] wrong ADL for attribute cleanup functions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
People really shouldn't be using the cleanup attribute in C++, they have
destructors in the language...

[Bug c++/69021] New: [cilkplus] valid cilk_spawn won't compile when invoking non-trivial assignment operator

[ryan.burn at gmail dot com]

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

Bug ID: 69021
   Summary: [cilkplus] valid cilk_spawn won't compile when
invoking non-trivial assignment operator
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryan.burn at gmail dot com
  Target Milestone: ---

The below code gives this error but should compile:

prog.cc: In function 'void g()':
prog.cc:12:21: error: invalid use of '_Cilk_spawn'
   a = _Cilk_spawn f();

//
struct A {  
  A() = default;
  A& operator=(const A&) { 
  return *this;
  } 
};  

A f() { return {}; }

void g() {  
  A a;  
  a = _Cilk_spawn f();  
}
//

[Bug c++/69020] wrong ADL for attribute cleanup functions

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
I agree, but as long as the feature is exposed to users it seems that it should
work in unsurprising ways (i.e., follow the C++ lookup rules).  Otherwise, if
we don't want C++ programmers to use it, a possible simple fix is to reject the
attribute in C++.  Alternatively, we could reject it when the referenced
function is dependent to keep it working in the cases we know work correctly
and prevent unexpected results in the others.  Or we can fix it and issue a
warning suggesting to use a destructor.  I'm fine with any of these solutions
and I'm happy to work up a patch (in fact, I already started working on it
hoping for a simple fix).

[Bug c++/67339] [5/6 Regression] Segfault when parsing a typename involving a template-alias

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Tue Dec 22 21:46:38 2015
New Revision: 231912

URL: https://gcc.gnu.org/viewcvs?rev=231912&root=gcc&view=rev
Log:
PR c++/67339
* parser.c (cp_parser_elaborated_type_specifier): Use CLASS_TYPE_P
rather than check for RECORD_TYPE.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-pmf1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c

[Bug c++/67257] [5/6 regression] Internal compiler error in retrieve_specialization

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Tue Dec 22 21:46:44 2015
New Revision: 231913

URL: https://gcc.gnu.org/viewcvs?rev=231913&root=gcc&view=rev
Log:
PR c++/67257
* parser.c (cp_parser_single_declaration): Reject a class template
that also declares a variable.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/auto-fn28.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/g++.dg/cpp0x/pr51226.C

[Bug c++/66921] [4.9/5/6 Regression] failure to determine size of static constexpr array that is nested within a templated class

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Tue Dec 22 21:46:50 2015
New Revision: 231914

URL: https://gcc.gnu.org/viewcvs?rev=231914&root=gcc&view=rev
Log:
PR c++/66921
* decl.c (cp_complete_array_type): Allow an initializer that
already has array type.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-array14.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c

[Bug c++/67339] [5/6 Regression] Segfault when parsing a typename involving a template-alias

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Tue Dec 22 21:49:18 2015
New Revision: 231916

URL: https://gcc.gnu.org/viewcvs?rev=231916&root=gcc&view=rev
Log:
PR c++/67339
* parser.c (cp_parser_elaborated_type_specifier): Use CLASS_TYPE_P
rather than check for RECORD_TYPE.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/alias-decl-pmf1.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/parser.c

[Bug c++/66921] [4.9/5/6 Regression] failure to determine size of static constexpr array that is nested within a templated class

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Tue Dec 22 21:49:25 2015
New Revision: 231917

URL: https://gcc.gnu.org/viewcvs?rev=231917&root=gcc&view=rev
Log:
PR c++/66921
* decl.c (cp_complete_array_type): Allow an initializer that
already has array type.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-array14.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/decl.c

[Bug c/68473] [6 Regression] ICE: in contains_point, at diagnostic-show-locus.c:340 after error

[dmalcolm at gcc dot gnu.org]

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

--- Comment #11 from David Malcolm  ---
Author: dmalcolm
Date: Tue Dec 22 22:27:45 2015
New Revision: 231919

URL: https://gcc.gnu.org/viewcvs?rev=231919&root=gcc&view=rev
Log:
PR c/68473: sanitize source range-printing within certain macro expansions

gcc/ChangeLog:
PR c/68473
* diagnostic-show-locus.c (layout::layout): Make loc_range const.
Sanitize the layout_range against ranges that finish before they
start.

gcc/testsuite/ChangeLog:
PR c/68473
* gcc.dg/plugin/diagnostic-test-expressions-1.c (fminl): New decl.
(TEST_EQ): New macro.
(test_macro): New function.
* gcc.target/i386/pr68473-1.c: New test case.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr68473-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/diagnostic-show-locus.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/plugin/diagnostic-test-expressions-1.c

[Bug c/68473] [6 Regression] ICE: in contains_point, at diagnostic-show-locus.c:340 after error

[dmalcolm at gcc dot gnu.org]

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

--- Comment #12 from David Malcolm  ---
(In reply to David Malcolm from comment #11)
> Author: dmalcolm
> Date: Tue Dec 22 22:27:45 2015
> New Revision: 231919
> 
> URL: https://gcc.gnu.org/viewcvs?rev=231919&root=gcc&view=rev
> Log:
> PR c/68473: sanitize source range-printing within certain macro expansions

This commit corresponds to the patch from comment #5, rather than the one from
comment #9.  Keeping this open in the hope of doing a more thorough fix for
this, but this may need to wait for gcc 7.

[Bug testsuite/68917] test suite failure for builtin-bitops-1.c

[gang.chen.5i5j at gmail dot com]

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

--- Comment #4 from Chen Gang  ---
(In reply to Bernd Edlinger from comment #3)
> by the way, did you have also trouble to build the
> libgcc multilib configuration or did you --disable-multilib?
> this seems completely broken too...

Yes, I did.

../gcc/configure --target=tilegx-gchen-linux --disable-nls --enable-threads
--enable-shared --enable-libssp --prefix=/upstream/release-tile
--with-headers=/upstream/release-tile/include
--with-sysroot=/upstream/release-tile --disable-multilib --disable-libquadmath
--disable-libgomp --disable-libatomic target_alias=tilegx-gchen-linux
--enable-languages=c,c++,lto

Thanks.

[Bug tree-optimization/68541] [6 Regression] Path splitting causes if-conversion miss

[law at redhat dot com]

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

--- Comment #3 from Jeffrey A. Law  ---
So a couple updates.

First the path splitting code has been moved to -O3 and above so anyone trying
to reproduce would need to use -O2 -fsplit-paths.

The unnecessary duplication pointed out by Richi has been fixed.

I'm not sure what Richi is talking about in c#1 with regard to the conditional.
 The duplicated block is:

;;   basic block 7, loop depth 1
;;pred:   5
;;6
  # s_1 = PHI 
  ivtmp.6_2 = ivtmp.6_3 + 1;
  if (ivtmp.6_2 != _21)
goto ;
  else
goto ;
;;succ:   10
;;8

Essentially consider block #7 duplicated into its predecessors, blocks #5 and
#6 respectively.

As I've been sitting here starting at the dumps, one heuristic is starting to
come to mind.  The idea behind path splitting is to enable CSE. For there to be
any CSE, some statement in the duplicated block must be fed by a statement in a
predecessor block.  That implies there's actually an intervening PHI.  We can
potentially key things off the existence of those PHIs.

That heuristic would seem to prevent path splitting in this case.  None of the
statements in the duplicated block have operands which are fed from a
predecessor block (through a PHI).

[Bug c++/69022] New: attribute vector_size ignored with dependent bytes

[msebor at gcc dot gnu.org]

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

Bug ID: 69022
   Summary: attribute vector_size ignored with dependent bytes
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

While working on a fix for bug 58109 (and bug 69020) I came across another
instance of attribute vector_size not being handled correctly (in addition to
bug 35758 and bug 38260).  In the following test case, the attribute is
accepted on all declarations except that of c.  As in bug 58109, the problem in
this case also seems to be in the is_late_template_attribute() function which
fails to treat the argument as dependent.

$ cat x.cpp && /build/gcc-trunk-svn/gcc/xg++ -B /build/gcc-trunk-svn/gcc -S
-Wall -Wextra -Wpedantic -o/dev/null x.cpp 
template 
struct A { static const int X = N; };

#define ASSERT(e) static_assert (e, #e)

template 
struct B: A
{
using A::X;

static void foo ()
{
char a __attribute__ ((vector_size (N)));
ASSERT (sizeof a == N);

T b __attribute__ ((vector_size (N)));
ASSERT (sizeof b == N);
}

static void bar ()
{
char c __attribute__ ((vector_size (X)));
ASSERT (sizeof c == X);

T d __attribute__ ((vector_size (X)));
ASSERT (sizeof d == X);
}
};

void bar ()
{
B::foo ();
B::bar ();
}

x.cpp: In static member function ‘static void B::bar()’:
x.cpp:22:48: warning: ‘vector_size’ attribute ignored [-Wattributes]
 char c __attribute__ ((vector_size (X)));
^

x.cpp: In instantiation of ‘static void B::bar() [with T = int; int N =
16]’:
x.cpp:33:17:   required from here
x.cpp:4:19: error: static assertion failed: sizeof c == X
 #define ASSERT(e) static_assert (e, #e)
   ^

x.cpp:23:9: note: in expansion of macro ‘ASSERT’
 ASSERT (sizeof c == X);
 ^~

[Bug c++/69022] attribute vector_size ignored with dependent bytes

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
I'll try to fix this in the same patch as bug 58109.

[Bug c++/35758] vector_size attribute lost in function arguments for templates

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||msebor at gcc dot gnu.org

--- Comment #23 from Martin Sebor  ---
The test case compiles successfully with 6.0 (albeit with warnings).  Since the
originally reported problem was fixed in r134639 and since there are other bugs
tracking problems with dependent arguments to attributes (bug 58109 and bug
69022), should this bug be RESOLVED as FIXED?

If there is an outstanding problem that isn't tracked anywhere else, can we
distill it into a small test case and open a separate bug for it?  (I'd be
happy to do it but I'm not sure what the outstanding problem is that this bug
still tracks.)

Setting Status to WAITING until a decision is made.

[Bug c++/69023] New: bitset whose name is used in constant-expression rejected

[msebor at gcc dot gnu.org]

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

Bug ID: 69023
   Summary: bitset whose name is used in constant-expression
rejected
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The declaration of b1 in the test case below is rejected for what seems to be
an invalid reason.  The bit-field x doesn't exist yet at the point the sizeof x
expression is seen in the constant expression.  The error also seems confused:
it points that the local variable x and says its meaning is being changed but
doesn't say by what (i.e., it never points at the declaration of the
bit-field).

I'm sure this is a corner case but I think it's a bug in GCC because in the
subsequent declaration of b2, the sizeof y expression is rejected with an error
implying that GCC doesn't treat the bit-field declaration as complete at that
point.

Clang accepts the declarations of b0 and b1 and rejects the declaration of b2
with a similar error as GCC.

$ cat x.cpp && /home/msebor/build/gcc-trunk-svn/gcc/xgcc
-B/home/msebor/build/gcc-trunk-svn/gcc -S -Wall -Wextra -Wpedantic -o/dev/null
x.cpp
void foo () {
int x;
{
struct { int  : sizeof x; } b0; (void)&b0;
struct { int x: sizeof x; } b1; (void)&b1;
struct { int y: sizeof y; } b2; (void)&b2;
}
}

x.cpp: In function ‘void foo()’:
x.cpp:5:32: error: declaration of ‘int foo()x’
[-fpermissive]
 struct { int x: sizeof x; } b1; (void)&b1;
^

x.cpp:2:9: error: changes meaning of ‘x’ from ‘int x’ [-fpermissive]
 int x;
 ^

x.cpp:6:32: error: ‘y’ was not declared in this scope
 struct { int y: sizeof y; } b2; (void)&b2;
^

[Bug c++/69024] New: [cilkpus] cilk_spawn is broken for initializations with implicit conversion operators defined

[ryan.burn at gmail dot com]

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

Bug ID: 69024
   Summary: [cilkpus] cilk_spawn is broken for initializations
with implicit conversion operators defined
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryan.burn at gmail dot com
  Target Milestone: ---

The following code should compile but gives this error:

implicit_cast.cpp: In function ‘void g()’:
implicit_cast.cpp:12:28: error: invalid use of ‘_Cilk_spawn’
   double x = _Cilk_spawn f();

/
struct A {
  operator double() {
return 33.0;
  }
};

A f() {
  return {};
}

void g() {
  double x = _Cilk_spawn f();
}

int main() {
  g();
  return 0;
}
/

[Bug c++/69023] bitset whose name is used in constant-expression rejected

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #1 from Andrew Pinski  ---
I think GCC is correct with its error message for b1 even if it does not do it
also for b2.  The meaning of x does change after the struct is finalized.

Note this kind of diagnostic is not required to happen.  That is the standard
says the code is invalid but no diagnostic is required.  This is one case where
the two compilers can disagree but both be correct even though the one of them
rejects the code.

[Bug c++/69023] bitset whose name is used in constant-expression rejected

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
I'm not sure.  I did read the relevant text in the C++ and C standards and I
can't say I see a clear answer.  But then it rarely seems to be in these corner
cases.

GCC (in C mode) accepts the code.  All other C and C++ compilers I have access
to (about half a dozen) do as well.  The one interesting thing I noticed that
the EDG front end issues the following warnings in C89 and C++ modes but not in
C99 and later.

"b.c", line 4: warning: reference to local variable of enclosing function is
  not allowed
  struct { int  : sizeof x; } b0; (void)&b0;
 ^

"b.c", line 5: warning: reference to local variable of enclosing function is
  not allowed
  struct { int x: sizeof x; } b1; (void)&b1;
 ^

[Bug middle-end/69025] New: df-scan.c:2536 warning: array su bscript is above array bounds

[gary at intrepid dot com]

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

Bug ID: 69025
   Summary: df-scan.c:2536 warning: array su bscript is above
array bounds
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gary at intrepid dot com
  Target Milestone: ---

This showed up as bootstrap failure when building with CFLAGS='-O3', because
when the stage2 compiler is compiled at -O3 using prev-gcc -Werror is asserted
in the warning flags.  Here's the error/warning.

/eng/upc/dev/gary/gupc-gcc-trunk/build/obj/./prev-gcc/xg++ -B/eng/upc/dev/gary/
gupc-gcc-trunk/build/obj/./prev-gcc/ -B/eng/upc/dev/gary/gupc-gcc-trunk/install
/x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/eng/upc/dev/gary/gupc-gcc-trunk/build/
obj/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/eng/upc/dev/gary/gupc-gc
c-trunk/build/obj/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs  -I/eng
/upc/dev/gary/gupc-gcc-trunk/build/obj/prev-x86_64-pc-linux-gnu/libstdc++-v3/in
clude/x86_64-pc-linux-gnu  -I/eng/upc/dev/gary/gupc-gcc-trunk/build/obj/prev-x8
6_64-pc-linux-gnu/libstdc++-v3/include  -I/eng/upc/dev/gary/gupc-gcc-trunk/src/
libstdc++-v3/libsupc++ -L/eng/upc/dev/gary/gupc-gcc-trunk/build/obj/prev-x86_64
-pc-linux-gnu/libstdc++-v3/src/.libs -L/eng/upc/dev/gary/gupc-gcc-trunk/build/o
bj/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c   -O3 -g -
gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W
-Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-a
ttribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wn
o-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -I. -I. -I/eng/upc/de
v/gary/gupc-gcc-trunk/src/gcc -I/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/. -I/e
ng/upc/dev/gary/gupc-gcc-trunk/src/gcc/../include -I/eng/upc/dev/gary/gupc-gcc-
trunk/src/gcc/../libcpp/include  -I/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/../
libdecnumber -I/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/../libdecnumber/bid -I.
./libdecnumber -I/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/../libbacktrace   -o
df-scan.o -MT df-scan.o -MMD -MP -MF ./.deps/df-scan.TPo /eng/upc/dev/gary/gupc
-gcc-trunk/src/gcc/df-scan.c

In file included from /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/target.h:53:0,
 from /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/df-scan.c:28:
 1,1   Top
 from /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/df-scan.c:28:
/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/df-scan.c: In function ‘void df_ref_re
cord(df_ref_class, df_collection_rec*, rtx, rtx_def**, basic_block, df_insn_inf
o*, df_ref_type, int)’:
/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/hard-reg-set.h:156:44: error: array su
bscript is above array bounds [-Werror=array-bounds]
   (!!((SET)[(BIT) / UHOST_BITS_PER_WIDE_INT] \
   ~^

/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/df-scan.c:2536:18: note: in expansion
of macro ‘TEST_HARD_REG_BIT’
   else if (!(TEST_HARD_REG_BIT (elim_reg_set, regno)
  ^

[Bug target/69012] gcc-6.0.0 internal compiler error building libgfortran for mips64el target

[paul.hua.gm at gmail dot com]

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

--- Comment #1 from Paul Hua  ---
The cross compile also crashed ...

/home/xuchenghua/GCC/mips/gcc-trunk-231896-o32_obj/./gcc/xgcc
-B/home/xuchenghua/GCC/mips/gcc-trunk-231896-o32_obj/./gcc/
-B/home/xuchenghua/toolchain/cross-tool
s/gcc-o32/usr/mipsel-redhat-linux/bin/
-B/home/xuchenghua/toolchain/cross-tools/gcc-o32/usr/mipsel-redhat-linux/lib/
-isystem /home/xuchenghua/toolchain/cross-tools/gcc-o32/usr/mipsel-redhat-linux
/include -isystem
/home/xuchenghua/toolchain/cross-tools/gcc-o32/usr/mipsel-redhat-linux/sys-include
-DHAVE_CONFIG_H -I. -I../../../../gcc_git_trunk/libgfortran
-iquote../../../../gcc_git_trunk/li
bgfortran/io -I../../../../gcc_git_trunk/libgfortran/../gcc
-I../../../../gcc_git_trunk/libgfortran/../gcc/config -I../.././gcc
-I../../../../gcc_git_trunk/libgfortran/../libgcc -I../libgcc -I../.
./../../gcc_git_trunk/libgfortran/../libbacktrace -I../libbacktrace
-I../libbacktrace -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings -Werr
or=implicit-function-declaration -Werror=vla -fcx-fortran-rules
-ffunction-sections -fdata-sections -std=gnu11 -g -O2 -minterlink-mips16
-Wunknown-pragmas -MT maxval_r4.lo -MD -MP -MF .deps/maxval
_r4.Tpo -c ../../../../gcc_git_trunk/libgfortran/generated/maxval_r4.c -o
maxval_r4.o
../../../../gcc_git_trunk/libgfortran/generated/maxval_r4.c: In function
'maxval_r4':
../../../../gcc_git_trunk/libgfortran/generated/maxval_r4.c:200:1: error:
unrecognizable insn:
 }
 ^

(insn 688 687 690 2 (parallel [
(set (mem/c:SI (plus:SI (reg/f:SI 29 $sp)
(const_int 16 [0x10])) [11  S4 A32])
(unspec:SI [
(const_int 16 [0x10])
(reg:SI 28 $28)
] UNSPEC_POTENTIAL_CPRESTORE))
(clobber (scratch:SI))
]) ../../../../gcc_git_trunk/libgfortran/generated/maxval_r4.c:42 -1
 (expr_list:REG_DEAD (reg:SI 28 $28)
(nil)))
../../../../gcc_git_trunk/libgfortran/generated/maxval_r4.c:200:1: internal
compiler error: in get_attr_got, at config/mips/mips.md:694

Host：x86_64-redhat-linux
Target：mipsel-redhat-linux

The cross compile configured with:
  $ ../../gcc_git_trunk/configure
--prefix=/home/xuchenghua/toolchain/cross-tools/gcc-o32/usr
--with-sysroot=/home/xuchenghua/toolchain/cross-tools/gcc-o32/usr/mipsel-redhat-linux/sysroot
--target=mipsel-redhat-linux --with-arch=mips64r2 --with-abi=32
--with-gmp=/home/xuchenghua/toolchain/cross-tools/gcc-o32/usr/
--with-mpfr=/home/xuchenghua/toolchain/cross-tools/gcc-o32/usr/
--with-mpc=/home/xuchenghua/toolchain/cross-tools/gcc-o32/usr/
--enable-threads=posix --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --disable-dssi --disable-multilib
--enable-languages=c,c++,objc,obj-c++,fortran,go,lto --enable-shared
--with-build-time-tools=/home/xuchenghua/toolchain/cross-tools/gcc-o32/usr/mipsel-redhat-linux/bin
--with-pkgversion=gcc 20151222 commit: gcc-trunk-231896 

This may be help to reproduced。

[Bug middle-end/69026] New: dwarf2out.c:4295 warning: ‘finder[...]addr_table_entry_struct_union::label’ may be used uninitialized

[gary at intrepid dot com]

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

Bug ID: 69026
   Summary: dwarf2out.c:4295 warning:
‘finder[...]addr_table_entry_struct_union::label’ may
be used uninitialized
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gary at intrepid dot com
  Target Milestone: ---

This showed up as a bootstrap failure when CFLAGS='-O3' because when the final
stage compiler is compiled with prev-gcc -Werror is asserted.

/eng/upc/dev/gary/gupc-gcc-trunk/build/obj/./prev-gcc/xg++ -B/eng/upc/dev/gary/
gupc-gcc-trunk/build/obj/./prev-gcc/ -B/eng/upc/dev/gary/gupc-gcc-trunk/install
/x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/eng/upc/dev/gary/gupc-gcc-trunk/build/
obj/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/eng/upc/dev/gary/gupc-gc
c-trunk/build/obj/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs  -I/eng
/upc/dev/gary/gupc-gcc-trunk/build/obj/prev-x86_64-pc-linux-gnu/libstdc++-v3/in
clude/x86_64-pc-linux-gnu  -I/eng/upc/dev/gary/gupc-gcc-trunk/build/obj/prev-x8
6_64-pc-linux-gnu/libstdc++-v3/include  -I/eng/upc/dev/gary/gupc-gcc-trunk/src/
libstdc++-v3/libsupc++ -L/eng/upc/dev/gary/gupc-gcc-trunk/build/obj/prev-x86_64
-pc-linux-gnu/libstdc++-v3/src/.libs -L/eng/upc/dev/gary/gupc-gcc-trunk/build/o
bj/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c   -O3 -g -
gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W
-Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-a
ttribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wn
o-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -I. -I. -I/eng/upc/de
v/gary/gupc-gcc-trunk/src/gcc -I/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/. -I/e
ng/upc/dev/gary/gupc-gcc-trunk/src/gcc/../include -I/eng/upc/dev/gary/gupc-gcc-
trunk/src/gcc/../libcpp/include  -I/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/../
libdecnumber -I/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/../libdecnumber/bid -I.
./libdecnumber -I/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/../libbacktrace   -o
dwarf2out.o -MT dwarf2out.o -MMD -MP -MF ./.deps/dwarf2out.TPo /eng/upc/dev/gar
y/gupc-gcc-trunk/src/gcc/dwarf2out.c

/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/dwarf2out.c: In function ‘addr_table_e
ntry* add_addr_table_entry(void*, ate_kind)’:
eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/dwarf2out.c: In function ‘addr_table_e
ntry* add_addr_table_entry(void*, ate_kind)’:
/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/dwarf2out.c:4295:41: error: ‘finder.ad
dr_table_entry::addr.addr_table_entry::addr_table_entry_struct_union::label’ ma
y be used uninitialized in this function [-Werror=maybe-uninitialized]
   inchash::add_rtx (a->addr.rtl, hstate);
 ^

/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/dwarf2out.c:4345:20: note: ‘finder.add
r_table_entry::addr.addr_table_entry::addr_table_entry_struct_union::label’ was
 declared here
   addr_table_entry finder;
^~

[Bug target/69015] ICE: RTL check: expected code 'code_label', have 'return' in find_cond_trap, at ifcvt.c:3715 with -fno-if-conversion and __builtin_trap()

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Target|powerpc-unknown-linux-gnu   |powerpc*-*-linux-gnu
 CC||msebor at gcc dot gnu.org
   Host|x86_64-pc-linux-gnu |

--- Comment #2 from Martin Sebor  ---
I reproduced the ICE on powerpc64{le,}-redhat-linux-gnu and verified the patch
fixes it on both.  A full bootstrap of all languages and a make check with the
patch on powerpc64le-redhat-linux-gnu shows no regressions.

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

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

--- Comment #7 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02074.html

[Bug c/68966] atomic_fetch_* on atomic_bool not diagnosed

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02075.html

[Bug c++/69022] attribute vector_size ignored with dependent bytes

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02074.html

[Bug tree-optimization/52272] [4.9/5/6 regression] Performance regression of 410.bwaves on x86.

[wuxiang at iscas dot ac.cn]

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

wuxiang at iscas dot ac.cn changed:

   What|Removed |Added

 CC||wuxiang at iscas dot ac.cn

--- Comment #30 from wuxiang at iscas dot ac.cn ---
(In reply to amker from comment #29)
> I think this is fixed.

Hi, I saw your patch, and patched it on gcc-4.8.4，but no improvement of
410.bwaves on x86_64 with gcc-4.8.4. 
> The patch improves 410.bwaves by 3-4% on x86_64.
Does this just test with gcc trunk before and afer the patch?

[Bug target/69027] New: SPARC: Missing optimization for fall through functions

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

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

Bug ID: 69027
   Summary: SPARC: Missing optimization for fall through functions
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastian.hu...@embedded-brains.de
  Target Milestone: ---

Consider the following test case:

int i(void);

int f(void)
{
return i();
}

int g(int (*j)(void))
{
return (*j)();
}

GCC generates on SPARC something like this:

sparc-rtems4.12-gcc -O2 -S fallthrough.c && cat fallthrough.s
.file   "fallthrough.c"
.section".text"
.align 4
.global f
.type   f, #function
.proc   04
f:
or  %o7, %g0, %g1
calli, 0
 or %g1, %g0, %o7
.size   f, .-f
.align 4
.global g
.type   g, #function
.proc   04
g:
save%sp, -96, %sp
call%i0, 0
 nop
jmp %i7+8
 restore %g0, %o0, %o0
.size   g, .-g
.ident  "GCC: (GNU) 6.0.0 20151221 (experimental)

For g() an superfluous stack frame is generated.

On PowerPC for example this is optimized to:
.file   "fallthrough.c"
.machine ppc
.section".text"
.align 2
.globl f
.type   f, @function
f:
b i
.size   f, .-f
.align 2
.globl g
.type   g, @function
g:
mtctr 3
bctr
.size   g, .-g
.ident  "GCC: (GNU) 6.0.0 20151126 (experimental)