[Bug c++/57565] variadic template and type inference failure

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57565

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-08
 Ever confirmed|0   |1

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

template struct tuple { };

template
tuple
make_tuple(T&&...) { return {}; }

template
void f()
{
  auto tp = make_tuple(I...);
};

int main()
{
  f<0, 1, 2>();
}


I can't recall anything similar right now.

[Bug c++/57566] New: [C++11][constexpr] static temporaries bound recursively in reference constant expressions don't get initialized

[richard-gccbugzilla at metafoo dot co.uk]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57566

Bug ID: 57566
   Summary: [C++11][constexpr] static temporaries bound
recursively in reference constant expressions don't
get initialized
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richard-gccbugzilla at metafoo dot co.uk

If a temporary is lifetime-extended by being bound to a reference within a
lifetime-extended temporary, and the complete initializer is a constant
expression, the outer temporary does not get initialized and the inner
temporary does not get emitted. Example:

struct S { int &&a; int b; };
S &&s = { 123, 456 };

GCC emits:

.local  _ZGR1s0
.comm   _ZGR1s0,16,16
.globl  s
.bss
.align 8
.type   s, @object
.size   s, 8
s:
.zero   8

GCC emits code to dynamically initialize 's.a' to the address of _ZGR1s0. GCC
does not emit any code to initialize _ZGR1s0 itself, nor to initialize s.b.

Both s and the temporaries should be emitted as constants.

[Bug c++/57565] variadic template and type inference failure

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57565

Paolo Carlini  changed:

   What|Removed |Added

 CC||jwakely.gcc at gmail dot com

--- Comment #1 from Paolo Carlini  ---
Jon, can you help me reducing/triaging this? It's pretty bad, but I think I
have seen something similar already.

[Bug c++/55149] capturing VLA in lambda

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55149

--- Comment #12 from Paolo Carlini  ---
PR57408 seems related.

[Bug target/57564] regmove switched operands?

[ncahill_alt at yahoo dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57564

--- Comment #1 from ncahill_alt at yahoo dot com ---
Also present in 4.8.0, not in 4.7.3.

[Bug c++/57565] New: variadic template and type inference failure

[anass.lasram at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57565

Bug ID: 57565
   Summary: variadic template and type inference failure
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anass.lasram at gmail dot com

Created attachment 30279
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30279&action=edit
sources, compiler details and command line

#include
#include

// #define DISABLE_COMPILE_ERROR

template
void bug()
{
#ifndef DISABLE_COMPILE_ERROR
auto tpl = std::make_tuple(t...); // doesn't compile but it should
#else
std::tuple tpl = std::make_tuple(t...);
#endif
std::cout << std::get<0>(tpl) << " , " << std::get<1>(tpl) << " , " <<
std::get<2>(tpl) << std::endl;
}


int main()
{
bug<10,20,30>();

return 0;
}

[Bug rtl-optimization/57564] New: regmove switched operands?

[ncahill_alt at yahoo dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57564

Bug ID: 57564
   Summary: regmove switched operands?
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ncahill_alt at yahoo dot com

Created attachment 30278
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30278&action=edit
Testcase

With x86 GCC 4.8.1 (32-bit), bzip2 built with -O1 decompresses files more
quickly than with -O2.  I found that -O2 -fno-regmove restores the performance.

Looking at the output, I saw the following.  I have attached a reduced testcase
to generate a similar pattern:

  movl%eax, 40(%esp)
  shrl%cl, 40(%esp)
  andl$7, 40(%esp)
  movl40(%esp), %eax

The command: gcc -S -O2 -pipe -c reduceme.c -o decompress.s

Thanks.
Neil Cahill.

[Bug bootstrap/56714] [4.9 regression] Bootstrap failure libitm/local_atomic:1580:3: error: always_inline function might not be inlinable

[gerald at pfeifer dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56714

Gerald Pfeifer  changed:

   What|Removed |Added

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

--- Comment #8 from Gerald Pfeifer  ---
I committed the following, which fixes this:

PR bootstrap/56714
* local_atomic (__always_inline): Always define our version.
(__calculate_memory_order): Mark inline.
(atomic_thread_fence): Ditto.
(atomic_signal_fence): Ditto.
(atomic_bool::atomic_flag_test_and_set_explicit): Ditto.
(atomic_bool::atomic_flag_clear_explicit): Ditto.
(atomic_bool::atomic_flag_test_and_set): Ditto.
(atomic_bool::atomic_flag_clear): Ditto.

[Bug fortran/57562] [OOP] Internal compiler error due to extended derived type with PARAMETER attribute

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57562

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org
Summary|Internal compiler error due |[OOP] Internal compiler
   |to extended derived type|error due to extended
   |with PARAMETER attribute|derived type with PARAMETER
   ||attribute
 Ever confirmed|0   |1
   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-07

--- Comment #2 from Tobias Burnus  ---
The problem seems to be that expr.c's find_component_ref is not prepared to
find the parent's elements as dt%comp instead of as dt%parent%comp.

[Bug fortran/57535] [OOP] ICE when allocating a CLASS function-result variable

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57535

--- Comment #1 from Tobias Burnus  ---
Patch: http://gcc.gnu.org/ml/fortran/2013-06/msg00053.html

[Bug c++/56544] documentation for __cplusplus is out of date

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56544

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #2 from Paolo Carlini  ---
Mine.

[Bug c++/57387] Passing parameter pack to emplace stl function cause compilation bug

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57387

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Paolo Carlini  ---
Dup.

*** This bug has been marked as a duplicate of bug 57086 ***

[Bug c++/57086] Internal compiler error: Error reporting routines re-entered.

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57086

Paolo Carlini  changed:

   What|Removed |Added

 CC||avraammauridis at gmail dot com

--- Comment #6 from Paolo Carlini  ---
*** Bug 57387 has been marked as a duplicate of this bug. ***

[Bug c++/54440] [c++11] g++ prematurely applying rule that a template parameter pack cannot be followed by a template parameter

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54440

--- Comment #2 from Paolo Carlini  ---
Hi Jason. Noticed your patch here scheduled for 4.9...

[Bug fortran/57562] Internal compiler error due to extended derived type with PARAMETER attribute

[helvio.vairinhos at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57562

helvio  changed:

   What|Removed |Added

Version|4.7.3   |4.8.1

--- Comment #1 from helvio  ---
I just installed gfortran 4.8.1.
I tried to compile the example code, but the ICE still occurs.

[Bug c/57563] New: Lots of Cilk+ failures on i686-linux

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57563

Bug ID: 57563
   Summary: Lots of Cilk+ failures on i686-linux
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
CC: bviyer at gcc dot gnu.org
Target: i686-linux

If you do
make check-gcc RUNTESTFLAGS='--target_board=unix/-m32 cilk-plus.exp'
on x86_64-linux (or just make check-gcc RUNTESTFLAGS=cilk-plus.exp on
i686-linux), I'm seeing tons of FAILs that don't show up in x86_64 64-bit
testing:
FAIL: c-c++-common/cilk-plus/AN/builtin_fn_mutating.c  -O3 -fcilkplus execution
test
FAIL: c-c++-common/cilk-plus/AN/builtin_fn_mutating.c  -g -O3 -fcilkplus
execution test
FAIL: c-c++-common/cilk-plus/AN/builtin_fn_mutating.c  -O3 -ftree-vectorize
-fcilkplus -g execution test
FAIL: c-c++-common/cilk-plus/AN/builtin_fn_custom.c  -fcilkplus -std=c99
execution test
FAIL: c-c++-common/cilk-plus/AN/builtin_fn_mutating.c  -fcilkplus -std=c99
execution test
FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c  -fcilkplus -std=c99
(internal compiler error)
FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c  -fcilkplus -std=c99
(test for excess errors)
FAIL: c-c++-common/cilk-plus/AN/builtin_fn_custom.c  -fcilkplus -O0 -std=c99
execution test
FAIL: c-c++-common/cilk-plus/AN/builtin_fn_mutating.c  -fcilkplus -O0 -std=c99
execution test
FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c  -fcilkplus -O0 -std=c99
(internal compiler error)
FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c  -fcilkplus -O0 -std=c99
(test for excess errors)
FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c  -fcilkplus -O1 -std=c99
(internal compiler error)
FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c  -fcilkplus -O1 -std=c99
(test for excess errors)
FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c  -fcilkplus -O2
-ftree-vectorize -std=c99 (internal compiler error)
FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c  -fcilkplus -O2
-ftree-vectorize -std=c99 (test for excess errors)
FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c  -fcilkplus -O3 -std=c99
(internal compiler error)
FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c  -fcilkplus -O3 -std=c99
(test for excess errors)
FAIL: c-c++-common/cilk-plus/AN/builtin_fn_custom.c  -fcilkplus -g -std=c99
execution test
FAIL: c-c++-common/cilk-plus/AN/builtin_fn_mutating.c  -fcilkplus -g -std=c99
execution test
FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c  -fcilkplus -g -std=c99
(internal compiler error)
FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c  -fcilkplus -g -std=c99
(test for excess errors)
FAIL: c-c++-common/cilk-plus/AN/builtin_fn_custom.c  -fcilkplus -g -O0 -std=c99
execution test
FAIL: c-c++-common/cilk-plus/AN/builtin_fn_mutating.c  -fcilkplus -g -O0
-std=c99 execution test
FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c  -fcilkplus -g -O0
-std=c99 (internal compiler error)
FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c  -fcilkplus -g -O0
-std=c99 (test for excess errors)
FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c  -fcilkplus -g -O1
-std=c99 (internal compiler error)
FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c  -fcilkplus -g -O1
-std=c99 (test for excess errors)
FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c  -fcilkplus -g -O2
-ftree-vectorize -std=c99 (internal compiler error)
FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c  -fcilkplus -g -O2
-ftree-vectorize -std=c99 (test for excess errors)
FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c  -fcilkplus -g -O3
-std=c99 (internal compiler error)
FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c  -fcilkplus -g -O3
-std=c99 (test for excess errors)
FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c  -O3 -ftree-vectorize
-std=c99 -g -fcilkplus (internal compiler error)
FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c  -O3 -ftree-vectorize
-std=c99 -g -fcilkplus (test for excess errors)

[Bug fortran/57562] Internal compiler error due to extended derived type with PARAMETER attribute

[helvio.vairinhos at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57562

helvio  changed:

   What|Removed |Added

   Severity|critical|major

[Bug fortran/57562] New: Internal compiler error due to extended derived type with PARAMETER attribute

[helvio.vairinhos at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57562

Bug ID: 57562
   Summary: Internal compiler error due to extended derived type
with PARAMETER attribute
   Product: gcc
   Version: 4.7.3
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helvio.vairinhos at gmail dot com

Created attachment 30277
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30277&action=edit
ICE example

Hi,

In programs like the example below:



program example

   type :: Parent
  integer :: member1 = 0
   end type Parent

   type, extends(Parent) :: Child
  integer :: member2 = 0
   end type Child

   integer, parameter :: member1 = 23
   integer, parameter :: member2 = 42

   type(Child), parameter :: object = Child(member1, member2)

   print *, object%member1  !<-- No ICE if commented out
   print *, object%member2

end program example



I get the following message (on versions 4.6.4 and 4.7.3):



f951: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.



Best regards,

Helvio

[Bug c++/57548] calling gnu multiversioned function at file scope causes ICE

[tmsriram at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57548

--- Comment #1 from Sriraman Tallam  ---
Patch proposed to fix this problem:

The problem here is that the caller to fum not from a function and 
current_function_decl is NULL when processing the
call.  The simple fix in call.c to check current_function_decl before
calling can_inline_p target hook.

* cp/call.c (build_over_call):  Check if current_function_decl is
NULL.
* testsuite/g++.dg/ext/pr57548.C: New test.


Index: cp/call.c
===
--- cp/call.c(revision 199662)
+++ cp/call.c(working copy)
@@ -7053,7 +7053,8 @@ build_over_call (struct z_candidate *cand, int fla
  otherwise the call should go through the dispatcher.  */

   if (DECL_FUNCTION_VERSIONED (fn)
-  && !targetm.target_option.can_inline_p (current_function_decl, fn))
+  && (current_function_decl == NULL
+  || !targetm.target_option.can_inline_p (current_function_decl, fn)))
 {
   fn = get_function_version_dispatcher (fn);
   if (fn == NULL)
Index: testsuite/g++.dg/ext/pr57548.C
===
--- testsuite/g++.dg/ext/pr57548.C(revision 0)
+++ testsuite/g++.dg/ext/pr57548.C(revision 0)
@@ -0,0 +1,25 @@
+/* { dg-do compile { target i?86-*-* x86_64-*-* } } */
+/* { dg-require-ifunc "" }  */
+
+int fum (); // Extra declaration that is merged with the second one.
+int fum () __attribute__ ((target("default")));
+
+
+int fum () __attribute__((target( "mmx")));
+int fum () __attribute__((target( "popcnt")));
+int fum () __attribute__((target( "sse")));
+int fum () __attribute__((target( "sse2")));
+int fum () __attribute__((target( "sse3")));
+int fum () __attribute__((target( "ssse3")));
+int fum () __attribute__((target( "sse4.1")));
+int fum () __attribute__((target( "sse4.2")));
+int fum () __attribute__((target( "avx")));
+int fum () __attribute__((target( "avx2")));
+
+int fum () __attribute__((target("arch=core2")));
+int fum () __attribute__((target("arch=corei7")));
+int fum () __attribute__((target("arch=atom")));
+
+int (*p)() = &fum;
+
+int j = fum();

[Bug c++/57561] New: gnu function multiversion - resolver doesn't use isa priority according to documentation

[mib.bugzilla at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57561

Bug ID: 57561
   Summary: gnu function multiversion - resolver doesn't use isa
priority according to documentation
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mib.bugzilla at gmail dot com

In this test case, the resolver function doesn't find the correct version,
according to the documentation e.g. mmx should not preceed sse4.2
(Using gcc 4.8.1 on x86 system)
grep movl fu.s | grep arch
movl$_Z3fumv.arch_corei7_avx2, %eax
movl$_Z3fumv.arch_corei7_avx, %eax
movl$_Z3fumv.arch_corei7_popcnt, %eax
movl$_Z3fumv.arch_corei7_mmx, %eax
movl$_Z3fumv.arch_corei7_sse4.2, %eax
movl$_Z3fumv.arch_corei7_sse4.1, %eax
movl$_Z3fumv.arch_corei7_ssse3, %eax
movl$_Z3fumv.arch_corei7_sse, %eax
movl$_Z3fumv.arch_corei7_sse2, %eax
movl$_Z3fumv.arch_corei7_sse3, %eax

cat fu.cpp
 __attribute__ ((target("default"))) int fum () { return 0; }
 __attribute__ ((target("arch=corei7,sse3"))) int fum () { return 0; }
 __attribute__ ((target("arch=corei7,sse2"))) int fum () { return 0; }
 __attribute__ ((target("arch=corei7,sse"))) int fum () { return 0; }
 __attribute__ ((target("arch=corei7,ssse3"))) int fum () { return 0; }
 __attribute__ ((target("arch=corei7,sse4.1"))) int fum () { return 0; }
 __attribute__ ((target("arch=corei7,sse4.2"))) int fum () { return 0; }
 __attribute__ ((target("arch=corei7,popcnt"))) int fum () { return 0; }
 __attribute__ ((target("arch=corei7,avx"))) int fum () { return 0; }
 __attribute__ ((target("arch=corei7,avx2"))) int fum () { return 0; }
 __attribute__ ((target("arch=corei7,mmx"))) int fum () { return 0; }

int (*p)() = &fum;

int foo(void)
{
  int j = fum();
  return j;
}

[Bug c++/57560] Variadic templates, unwarranted warnings

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57560

Paolo Carlini  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Paolo Carlini  ---
I'm wondering if for this kind of annoying warning which would make sense only
for specific instantiations, we shouldn't use again a mechanism like
c_inhibit_evaluation_warnings. Jakub?

[Bug tree-optimization/57539] [4.9 Regression] ice in ipa_edge_duplication_hook

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57539

Martin Jambor  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #2 from Martin Jambor  ---
The main reason why the code does not work is that when
ipa_edge_duplication_hook is invoked, dst->caller does not yet have
its global.inlined_to set (it does not have any callers either) and so
we cannot use it to figure out which copy of rdesc in the list is the
one describing the new tree of inline clones.  This means that this
whole copying/re-mapping should be moved out of the hook into a
specialized function called from clone_inlined_nodes.

Additionally, and this has confused me for hours, we also do not even
create the rdesc we want to map a different edge to in this particular
testcase.  That is because an originally indirect edge is involved and
the call to ipa_free_edge_args_substructures in
ipa_propagate_indirect_call_infos.  That deallocated the vector of
jump functions, so the loop over it in the hook did not do anything.
That call needs to be removed.

[Bug c++/55149] capturing VLA in lambda

[david.abdurachmanov at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55149

--- Comment #11 from David Abdurachmanov  
---
(In reply to Jason Merrill from comment #10)

Hi Jason,

Compiled fine in 4.8.0, fails in 4.9.0 (r199649). That's the smallest I could
get in this time. It produces two errors for the same line.

david

cat <<\EOF > test.cxx

template
 struct SA
 {
   SA (const int & PA);
   int nt;
 };

template
 inline void
 test(TB aa)
 {
   ;
 }

template
 inline
 SA::SA(const int & PA)
 {
   float e[nt];
   test([&e](int i, int j){ return e[i] < e[j]; });
 }

int main()
{
 int d;
 SA<2> iso(d);
 return 0;
}
EOF

### GCC COMMAND ###

c++ -c -DGNU_GCC -D_GNU_SOURCE -O2 -pthread -pipe -Werror=main
-Werror=pointer-arith -Werror=overlength-strings -Wno-vla -Wno-overflow
-Wno-strict-overflow -std=c++0x -msse3 -ftree-vectorize -Wno-strict-overflow
-Werror=array-bounds -Werror=format-contains-nul -Werror=type-limits
-fvisibility-inlines-hidden -fno-math-errno --param
vect-max-version-for-alias-checks=50 -fipa-pta -felide-constructors
-fmessage-length=0 -ftemplate-depth-300 -Wall -Wno-non-template-friend
-Wno-long-long -Wreturn-type -Wunused -Wparentheses -Wno-deprecated
-Werror=return-type -Werror=missing-braces -Werror=unused-value -Werror=address
-Werror=format -Werror=sign-compare -Werror=write-strings
-Werror=delete-non-virtual-dtor -Werror=maybe-uninitialized
-Werror=strict-aliasing -Werror=narrowing -Werror=uninitialized
-Werror=unused-but-set-variable -Werror=reorder -Werror=unused-variable
-Werror=conversion-null -Werror=switch -fdiagnostics-show-option
-Wno-unused-local-typedefs -Wabi -fPIC test.cxx -o test.o

### GCC OUTPUT ###

test.cxx: In instantiation of 'struct SA::SA(const int&) [with unsigned int
TA = 2u]::':
test.cxx:20:50:   required from 'SA::SA(const int&) [with unsigned int TA =
2u]'
test.cxx:26:13:   required from here
test.cxx:20:11: error: size of array is not an integral constant-expression
test([&e](int i, int j){ return e[i] < e[j]; });
   ^
test.cxx: In instantiation of 'SA::SA(const int&) [with unsigned int TA =
2u]':
test.cxx:26:13:   required from here
test.cxx:20:9: error: invalid initialization of reference of type 'float
(&)[1]' from expression of type 'float [((SA<2u>*)this)->SA<2u>::nt]'
test([&e](int i, int j){ return e[i] < e[j]; });
 ^

[Bug c++/57557] can't reference static const int member with optimizations on

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57557

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--- Comment #5 from Jonathan Wakely  ---
Using -Wall would have saved you submitting a bug.

[Bug c++/57560] Variadic templates, unwarranted warnings

[vpozdyayev at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57560

--- Comment #2 from vpozdyayev at gmail dot com ---
Almost. This time it's "parameter" instead of "variable".

[Bug c++/57557] can't reference static const int member with optimizations on

[pavel.v.chupin at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57557

Pavel Chupin  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #4 from Pavel Chupin  ---
Right. Thanks. Missed all that.
On real case I faced undefined reference so thanks for a link.

[Bug c++/57560] Variadic templates, unwarranted warnings

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57560

--- Comment #1 from Jonathan Wakely  ---
is this PR 56958 ?

[Bug c++/57560] New: Variadic templates, unwarranted warnings

[vpozdyayev at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57560

Bug ID: 57560
   Summary: Variadic templates, unwarranted warnings
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vpozdyayev at gmail dot com

Created attachment 30276
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30276&action=edit
test case

Test case: see the attachment. Command line: "g++ test.cpp -Wall -Wextra
-std=c++11". I believe the "parameter set but not used" warning to be
unnecessary here.

[Bug rtl-optimization/57559] New: S/390: ICE with lra

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57559

Bug ID: 57559
   Summary: S/390: ICE with lra
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org

t.c:

typedef int int32_t;
typedef unsigned char uint8_t;
typedef unsigned int uint32_t;
struct _IO_marker
{
};
static const int32_t mfcone = 1;
static const uint8_t *mfctop = (const uint8_t *) &mfcone;
int32_t
decContextTestEndian (uint8_t quiet)
{
  int32_t res = 0;
  uint32_t dle = (uint32_t) 0;
  if (*mfctop != 0)
{
  res = (int32_t) * mfctop - dle;
}
  return res;
}

cc1 -fpreprocessed  -quiet -march=z10 -m64 -mzarch  -O1 t.c -o t.s

t.c: In function ‘decContextTestEndian’:
t.c:19:1: internal compiler error: Max. number of generated reload insns per
insn is achieved (90)

 }
 ^
0x806b1637 lra_constraints(bool)
/home/andreas/clean/gcc-head/gcc/lra-constraints.c:3698
0x80697d8b lra(_IO_FILE*)
/home/andreas/clean/gcc-head/gcc/lra.c:2278
0x80621aeb do_reload
/home/andreas/clean/gcc-head/gcc/ira.c:4641
0x80621dfd rest_of_handle_reload
/home/andreas/clean/gcc-head/gcc/ira.c:4753
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


The testcase works fine with either -mno-lra or -march=z9-109

[Bug fortran/57549] Bogus error with array constructor with derived-type typespec

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57549

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #3 from Tobias Burnus  ---
FIXED on the trunk (4.9).

[Bug fortran/57549] Bogus error with array constructor with derived-type typespec

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57549

--- Comment #2 from Tobias Burnus  ---
Author: burnus
Date: Fri Jun  7 15:05:47 2013
New Revision: 199820

URL: http://gcc.gnu.org/viewcvs?rev=199820&root=gcc&view=rev
Log:
2013-06-07  Tobias Burnus  

PR fortran/57549
* array.c (gfc_match_array_constructor): Call
gfc_match_type_spec instead of gfc_match_decl_type_spec.
* match.c (gfc_match_type_spec): Renamed from match_type_spec.
(gfc_match_type_is, gfc_match_allocate): Update call.
* match.h (gfc_match_type_spec): Add prototype.

2013-06-07  Tobias Burnus  

PR fortran/57549
* gfortran.dg/array_constructor_48.f90: New.
* gfortran.dg/array_constructor_type_14.f03: Correct test case.
* gfortran.dg/array_constructor_type_15.f03: Ditto.


Added:
trunk/gcc/testsuite/gfortran.dg/array_constructor_48.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/array.c
trunk/gcc/fortran/match.c
trunk/gcc/fortran/match.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/array_constructor_type_14.f03
trunk/gcc/testsuite/gfortran.dg/array_constructor_type_15.f03

[Bug c++/57557] can't reference static const int member with optimizations on

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57557

--- Comment #3 from Jonathan Wakely  ---
Doh, sorry, I completely misread the test!

It's still undefined behaviour though, obj is uninitialized and you're missing
a return from A::foo

[Bug c++/57557] can't reference static const int member with optimizations on

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57557

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> It's undefined behaviour, you take a reference ton object that has no

s/ton object/to an object/

[Bug c++/57557] can't reference static const int member with optimizations on

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57557

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Jonathan Wakely  ---
It's undefined behaviour, you take a reference ton object that has no
definition (i.e. no address)

Please read
http://gcc.gnu.org/wiki/VerboseDiagnostics#missing_static_const_definition

[Bug regression/57551] [4.9 Regression]: g++.dg/ext/visibility/anon6.C scan-assembler 1BIiE1cE

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57551

--- Comment #4 from Jan Hubicka  ---
OK, C++ FE properly brings the decl local as part of constrain_visibility,
however later in pt.c it is made public again in 
mark_decl_instantiated as explicit instantiation.

My wild try is the following:
Index: pt.c
===
--- pt.c(revision 199698)
+++ pt.c(working copy)
@@ -17402,6 +17402,13 @@ mark_decl_instantiated (tree result, int
   if (TREE_ASM_WRITTEN (result))
 return;

+  /* For anonymous namespace we don't need to do anything.  */
+  if (decl_anon_ns_mem_p (result))
+{
+  gcc_assert (!TREE_PUBLIC (result));
+  return;
+}
+
   if (TREE_CODE (result) != FUNCTION_DECL)
 /* The TREE_PUBLIC flag for function declarations will have been
set correctly by tsubst.  */

[Bug tree-optimization/57558] New: Issue with number of iterations calculation

[ysrumyan at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57558

Bug ID: 57558
   Summary: Issue with number of iterations calculation
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ysrumyan at gmail dot com

For the following simple test-case extracted from 254.gap (spec2000):

typedef unsigned long ul;
void foo (ul* __restrict x, ul* __restrict y, ul n)
{
  ul i;
  for (i=1; i<=n; i++, x++, y++)
*x ^= *y;
}

gcc cannot determine number of iterations and failed to vectorize loop:

t1.c:5: note: === get_loop_niters ===Analyzing # of iterations of loop 1
  exit condition [2, + , 1] <= n_8(D)
  bounds on difference of bases: -1 ... 4294967293
  result:
under assumptions n_8(D) != 4294967295
# of iterations n_8(D) + 4294967295, bounded by 4294967294

t1.c:5: note: not vectorized: number of iterations cannot be computed.

Note that if we change for-stmt to
  for (i=0; i

[Bug c++/57557] New: can't reference static const int member with optimizations on

[pavel.v.chupin at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57557

Bug ID: 57557
   Summary: can't reference static const int member with
optimizations on
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pavel.v.chupin at gmail dot com

Test case:
#include 
using namespace std;

template bool Compare_GT(const A &a, const B &b) { if (a > b)
return true; else return false; }

struct A {
   bool foo(int a) {
 Compare_GT(VARIABLE, a);
   }
   private:
 static const int VARIABLE;
};

const int A::VARIABLE = 30;

int main() {
   A *obj;
//   cout << "30>20 ? " << obj->foo(20) << "\n";
//   cout << "30>40 ? " << obj->foo(40) << "\n";
   return !obj->foo(20);
}

Compiled with -O1 and higher produce:
$ g++ -O1 t.cpp; ./a.out ; echo $?
1

0040068c :
  40068c:   b8 01 00 00 00  mov$0x1,%eax
  400691:   c3  retq

If compiled with -O0 code is correct and test returns 0:
$ g++ -O0 t.cpp; ./a.out ; echo $?
0

Is it a bug or some sort of undefined behavior by standard?

[Bug target/56564] movdqa on possibly-8-byte-aligned struct with -O3

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56564

--- Comment #13 from Jakub Jelinek  ---
Created attachment 30275
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30275&action=edit
gcc49-pr56564.patch

Untested fix.  Honza, is the array type >= 16 bytes alignment increase the only
ABI mandated one and all the rest is just optimization?

[Bug regression/57551] [4.9 Regression]: g++.dg/ext/visibility/anon6.C scan-assembler 1BIiE1cE

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57551

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
   Assignee|hubicka at gcc dot gnu.org |jason at gcc dot gnu.org
   Target Milestone|--- |4.9.0

--- Comment #3 from Jason Merrill  ---
Sounds right to me.

[Bug c++/55149] capturing VLA in lambda

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55149

--- Comment #10 from Jason Merrill  ---
(In reply to David Abdurachmanov from comment #9)

I addressed example 1 in 55520.  

Please provide a self-contained testcase for example 2.

[Bug fortran/57556] [4.9 Regression] [OOP] ICE with move_alloc on polymorphic component with -fcheck=all

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57556

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #4 from Tobias Burnus  ---
FIXED.

Thanks for the report - and sorry for not properly solving PR57542.

[Bug fortran/57556] [4.9 Regression] [OOP] ICE with move_alloc on polymorphic component with -fcheck=all

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57556

--- Comment #3 from Tobias Burnus  ---
Author: burnus
Date: Fri Jun  7 13:20:29 2013
New Revision: 199812

URL: http://gcc.gnu.org/viewcvs?rev=199812&root=gcc&view=rev
Log:
2013-06-07  Tobias Burnus  

PR fortran/57556
* trans.c (gfc_build_final_call): Init block before use.


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

[Bug fortran/57556] [4.9 Regression] [OOP] ICE with move_alloc on polymorphic component with -fcheck=all

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57556

Tobias Burnus  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

--- Comment #2 from Tobias Burnus  ---
Obvious patch for a stupid mistake of mine:

--- a/gcc/fortran/trans.c
+++ b/gcc/fortran/trans.c
@@ -854,0 +855 @@ gfc_build_final_call (gfc_typespec ts, gfc_expr
+  gfc_start_block (&block);
@@ -939 +939,0 @@ gfc_build_final_call (gfc_typespec ts, gfc_expr
-  gfc_start_block (&block);

[Bug regression/57551] [4.9 Regression]: g++.dg/ext/visibility/anon6.C scan-assembler 1BIiE1cE

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57551

Jan Hubicka  changed:

   What|Removed |Added

 CC||jason at redhat dot com

--- Comment #2 from Jan Hubicka  ---
You are right, I added attribute used to the variable and forgot about it. The
testcase is bogus by expecting unused local static to not be optmized away.

Looking closer, I am however confused. While the attribute fixes the testcase,
i think something wrong is still going on hre.

We get the following symbol out of FE:
_ZN12_GLOBAL__N_11BIiE1cE/1 (const int {anonymous}::B::c) @0x775141a0
  Type: variable definition analyzed
  Visibility: force_output comdat
  Aux: @0x1  References:
  Referring:
  Availability: not-ready
  Varpool flags: initialized read-only const-value-known

i.e. it is COMDAT but not public. It is the force_output flag that keeps
variable alive and that is there because of keying. The variable is output as
static object:
jh@gcc10:~/trunk/build3/gcc$ more anon6.s
.file   "anon6.C"
.section.rodata
.align 4
.type   _ZN12_GLOBAL__N_11BIiE1cE, @object
.size   _ZN12_GLOBAL__N_11BIiE1cE, 4
_ZN12_GLOBAL__N_11BIiE1cE:
.zero   4
.ident  "GCC: (GNU) 4.9.0 20130602 (experimental)"
.section.note.GNU-stack,"",@progbits

i.e. no comdat visibility. This flag stays through the compilation and seems to
be ignored by output routines.  

And now adding the attribute used:

Index: /home/jh/trunk/gcc/testsuite/g++.dg/ext/visibility/anon6.C
===
--- /home/jh/trunk/gcc/testsuite/g++.dg/ext/visibility/anon6.C  (revision
199698)
+++ /home/jh/trunk/gcc/testsuite/g++.dg/ext/visibility/anon6.C  (working copy)
@@ -18,7 +18,7 @@ namespace
   template 
   class B
   {
-static const T c = 0;
+__attribute__ ((__used__)) static const T c = 0;
   };

   template  const T B::c;

changes object to:
_ZN12_GLOBAL__N_11BIiE1cE/1 (const int {anonymous}::B::c) @0x775141a0
  Type: variable definition analyzed
  Visibility: force_output forced_by_abi public weak comdat
comdat_group:_ZN12_GLOBAL__N_11BIiE1cE one_only
  Aux: @0x77402850  References:
  Referring:
  Availability: not-ready
  Varpool flags: initialized read-only const-value-known

which changes assembly to:
jh@gcc10:~/trunk/build/gcc$ ./xgcc -B ./ -O2
/home/jh/trunk/gcc/testsuite/g++.dg/ext/visibility/anon6.C -S -std=c++98
-pedantic-errors -Wno-long-long -S -fdump-ipa-all-details -fdump-ipa-cgraph
jh@gcc10:~/trunk/build/gcc$ more anon6.s 
.file   "anon6.C"
.weak   _ZN12_GLOBAL__N_11BIiE1cE
.section   
.rodata._ZN12_GLOBAL__N_11BIiE1cE,"aG",@progbits,_ZN12_GLOBAL__N_11BIiE1cE,comdat
.align 4
.type   _ZN12_GLOBAL__N_11BIiE1cE, @gnu_unique_object
.size   _ZN12_GLOBAL__N_11BIiE1cE, 4
_ZN12_GLOBAL__N_11BIiE1cE:
.zero   4
.ident  "GCC: (GNU) 4.9.0 20130605 (experimental)"
.section.note.GNU-stack,"",@progbits

Here we now disagree with GCC 4.5 that still outputs this as static.

Jason, why C++ FE behaves this way now?

clang also optimizes out the variable in testcase and adding attribute used
makes the var to be static.

I think the testcase should be fixed by adding the used flag and by checking
that weaks/comdats are not involved in the assembly and C++ FE should be fixed.
or do I miss something?

Honza

[Bug c++/55520] [C++11] ICE when capturing a variable-length stack array in lambda; in expand_expr_real_1, at expr.c:9122

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55520

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.0

--- Comment #5 from Jason Merrill  ---
Fixed for 4.9.

[Bug c++/57555] Warning on negation of constexpr uint8_t being assigned to uint8_t

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57555

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Jonathan Wakely  ---
The standard says that ~foo has type int and value -256, so assigning it to
uint8_t changes the value, so the warning is correct.

The warning is only given when foo is constant because otherwise the value of
~foo is not a compile-time constant.

[Bug fortran/57556] [4.9 Regression] [OOP] ICE with move_alloc on polymorphic component with -fcheck=all

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57556

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-07
 CC||janus at gcc dot gnu.org
Summary|[OOP][Regression]  ICE with |[4.9 Regression] [OOP] ICE
   |move_alloc on polymorphic   |with move_alloc on
   |component   |polymorphic component with
   ||-fcheck=all
 Ever confirmed|0   |1

--- Comment #1 from janus at gcc dot gnu.org ---
Confirmed. Reduced test case:


  type prec_type
  end type

  type container
class(prec_type), allocatable :: item
  end type

  type(container), allocatable :: pool(:), dbp(:)

  allocate(dbp(1))

  call move_alloc(pool(1)%item,dbp(1)%item)

end

[Bug c++/57555] Warning on negation of constexpr uint8_t being assigned to uint8_t

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57555

--- Comment #2 from Paolo Carlini  ---
Not having studied the issue in any detail, most likely the warning is fine:
all the modern compilers (gcc, ICC, clang) I have at hand warn in exactly the
same way.

[Bug fortran/57556] New: [OOP][Regression] ICE with move_alloc on polymorphic component

[sfilippone at uniroma2 dot it]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57556

Bug ID: 57556
   Summary: [OOP][Regression]  ICE with move_alloc on polymorphic
component
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sfilippone at uniroma2 dot it

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

The attached code generates the ICE when compiled with -fcheck=all. Looks very
similar but independent of  PR57542, since the patch for the latter was already
applied. Works with 4.7/4.8.

[sfilippo@jacobi BugDeallocateFinal]$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gnu49/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/usr/local/gnu49
--enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp
--with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc
--with-cloog=/home/travel/GNUBUILD/cloog : (reconfigured) ../gcc/configure
--prefix=/usr/local/gnu49 --enable-languages=c,c++,fortran
--with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr
--with-mpc=/home/travel/GNUBUILD/mpc --with-cloog=/home/travel/GNUBUILD/cloog :
(reconfigured) ../gcc/configure --prefix=/usr/local/gnu49
--enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp
--with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc
--with-cloog=/home/travel/GNUBUILD/cloog : (reconfigured) ../gcc/configure
--prefix=/usr/local/gnu49 --enable-languages=c,c++,fortran
--with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr
--with-mpc=/home/travel/GNUBUILD/mpc --with-cloog=/home/travel/GNUBUILD/cloog
Thread model: posix
gcc version 4.9.0 20130606 (experimental) (GCC) 
[sfilippo@jacobi BugDeallocateFinal]$ gfortran -c testMoveAlloc.f90
[sfilippo@jacobi BugDeallocateFinal]$ gfortran -c -fcheck=all testMoveAlloc.f90
testMoveAlloc.f90: In function 'realloc_pool':
testMoveAlloc.f90:31:0: internal compiler error: tree check: did not expect
class 'type', have 'type' (boolean_type) in append_to_statement_list, at
tree-iterator.c:94
   call move_alloc(pool(i)%item,dbp(i)%item)
 ^
0xb57be9 tree_not_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/gcc/tree.c:9159
0x9d9a0c non_type_check
../../gcc/gcc/tree.h:3869
0x9d9a0c append_to_statement_list(tree_node*, tree_node**)
../../gcc/gcc/tree-iterator.c:94
0x5b6f32 add_expr_to_chain
../../gcc/gcc/fortran/trans.c:1402
0x5b8ec6 gfc_add_block_to_block(stmtblock_t*, stmtblock_t*)
../../gcc/gcc/fortran/trans.c:1448
0x5b909b gfc_build_final_call
../../gcc/gcc/fortran/trans.c:898
0x5b909b gfc_add_finalizer_call(stmtblock_t*, gfc_expr*)
../../gcc/gcc/fortran/trans.c:1016
0x5b9aee gfc_deallocate_scalar_with_status(tree_node*, tree_node*, bool,
gfc_expr*, gfc_typespec)
../../gcc/gcc/fortran/trans.c:1300
0x6038ec conv_intrinsic_move_alloc
../../gcc/gcc/fortran/trans-intrinsic.c:7592
0x6038ec gfc_conv_intrinsic_subroutine(gfc_code*)
../../gcc/gcc/fortran/trans-intrinsic.c:7790
0x5b8bd2 trans_code
../../gcc/gcc/fortran/trans.c:1594
0x619544 gfc_trans_simple_do
../../gcc/gcc/fortran/trans-stmt.c:1425
0x619544 gfc_trans_do(gfc_code*, tree_node*)
../../gcc/gcc/fortran/trans-stmt.c:1588
0x5b8b0a trans_code
../../gcc/gcc/fortran/trans.c:1635
0x5e0cce gfc_generate_function_code(gfc_namespace*)
../../gcc/gcc/fortran/trans-decl.c:5460
0x5b9fd1 gfc_generate_module_code(gfc_namespace*)
../../gcc/gcc/fortran/trans.c:1859
0x578677../../gcc/gcc/fortran/parse.c:4496
0x578677 gfc_parse_file()
../../gcc/gcc/fortran/parse.c:4706
0x5b47f5 gfc_be_parse_file
../../gcc/gcc/fortran/f95-lang.c:189
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
[sfilippo@jacobi BugDeallocateFinal]$  translate_all_program_units

[Bug c++/57555] Warning on negation of constexpr uint8_t being assigned to uint8_t

[megari at mbnet dot fi]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57555

--- Comment #1 from Ari Sundholm  ---
It seems that actually just making the variable const suffices:

uint8_t foo() {
static const uint8_t foo = 0xff;

uint8_t ret = ~foo;

return ret;
}

[Bug c++/57555] New: Warning on negation of constexpr uint8_t being assigned to uint8_t

[megari at mbnet dot fi]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57555

Bug ID: 57555
   Summary: Warning on negation of constexpr uint8_t being
assigned to uint8_t
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: megari at mbnet dot fi

The following code produces a warning when it probably should not:

$ cat constexprbug.cpp
#include 

uint8_t foo() {
static constexpr uint8_t foo = 0xff;

uint8_t ret = ~foo;

return ret;
}

uint8_t bar() {
static constexpr uint8_t foo = 0x00;

uint8_t ret = ~foo;

return ret;
}

int main() {
foo();
bar();
}

$ g++ -std=c++11 -o constexprbug constexprbug.cpp
constexprbug.cpp: In function ‘uint8_t foo()’:
constexprbug.cpp:6:20: warning: large integer implicitly truncated to unsigned
type [-Woverflow]
$ gcc --version
gcc (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2)
Copyright (C) 2012 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.

The curious thing is that only the function foo() produces the warning. Also,
the variable needs to be constexpr for the warning to be emitted.

[Bug c++/13088] templatizing outer class hides specialization of inner template class

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13088

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC|gcc-bugs at gcc dot gnu.org|
  Known to work||4.8.0, 4.9.0
 Resolution|--- |FIXED

--- Comment #27 from Paolo Carlini  ---
It seems to me that lately everything is fine.

[Bug rtl-optimization/57479] [ARM][NEON] internal compiler error: Segmentation fault in add_dependence_list

[mikpe at it dot uu.se]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57479

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpe at it dot uu.se

--- Comment #4 from Mikael Pettersson  ---
I can reproduce the SEGV now, it was masked by my standard build's
--with-tune=cortex-a9 option.

The SEGV doesn't reproduce any more after r188742 + r188743, which changed the
way the ARM backend expands epilogues.  I don't immediately see the connection
between that change and the garbage reg_last->sets value.

[Bug regression/57551] [4.9 Regression]: g++.dg/ext/visibility/anon6.C scan-assembler 1BIiE1cE

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57551

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-06-07
 CC||hubicka at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jan Hubicka  ---
mine.

[Bug lto/57554] [4.9 regression] 176.gcc built with -flto miscompared after r198917 for x86

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57554

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug c++/54047] unused variable warning not for std::string

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54047

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Paolo Carlini  ---
Closing.

[Bug preprocessor/38990] preprocessing different in g++ -E and regular compiling.

[jan.sm...@alcatel-lucent.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38990

--- Comment #4 from Jan Smets  ---
Known to work: GCC 4.6

[Bug c++/53311] [C++0x] argument packs are not handled correctly in decltype

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53311

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||4.7.2, 4.8.0, 4.9.0
 Resolution|--- |FIXED

--- Comment #2 from Paolo Carlini  ---
Everything seems fine at least on 4.7.2, 4.8 and mainline. If you can still see
something wrong, please re-open.

[Bug c++/54366] [meta-bug] decltype issues

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54366

Bug 54366 depends on bug 53311, which changed state.

Bug 53311 Summary: [C++0x] argument packs are not handled correctly in decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53311

   What|Removed |Added

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

[Bug lto/57554] New: [4.9 regression] 176.gcc built with -flto miscompared after r198917 for x86

[izamyatin at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57554

Bug ID: 57554
   Summary: [4.9 regression] 176.gcc built with -flto miscompared
after r198917 for x86
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: izamyatin at gmail dot com
CC: jh at suse dot cz
Target: x86

Note that before r198917 there was compilation fail for this test.

Compile flags: -O3 -funroll-loops -ffast-math -flto

[Bug preprocessor/38990] preprocessing different in g++ -E and regular compiling.

[jan.sm...@alcatel-lucent.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38990

Jan Smets  changed:

   What|Removed |Added

 CC||jan.sm...@alcatel-lucent.co
   ||m

--- Comment #3 from Jan Smets  ---
Confirmed. This issue is easily hit when using distcc.

[Bug c++/57086] Internal compiler error: Error reporting routines re-entered.

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57086

Paolo Carlini  changed:

   What|Removed |Added

 CC||jussi.judin at ericsson dot com

--- Comment #5 from Paolo Carlini  ---
*** Bug 57552 has been marked as a duplicate of this bug. ***

[Bug c++/57552] Internal compiler error with vector::emplace_back() for templated class constructor

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57552

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Paolo Carlini  ---
Dup.

*** This bug has been marked as a duplicate of bug 57086 ***

[Bug c++/53658] internal compiler error -- segmentation fault

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53658

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #5 from Paolo Carlini  ---
Fixed for 4.9.0.

[Bug fortran/57549] Bogus error with array constructor with derived-type typespec

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57549

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||accepts-invalid, diagnostic

--- Comment #1 from Tobias Burnus  ---
There current code is odd: The following is clearly invalid, but it is not
diagnosed - but it compiles:
  print *, [ type(t) :: ]
  end
Reason: "t" is never defined - and the reason for the next item.


Also the following is invalid - and compiles:

  print *, [ type(integer) :: ]
  end

Reason: TYPE(...), i.e. a declaration-type-spec, is not permitted; the standard
only permits an intrinsic-type-spec/derived-type-spec, i.e. "integer" or a
derived-type name like "t" without TYPE().


The Fortran 2008 standard has:

R469  ac-spec  is  type-spec ::
   or  [type-spec ::] ac-value-list

R402  type-spec  is  intrinsic-type-spec
 or  derived-type-spec

R453  derived-type-spec  is  type-name [ ( type-param-spec-list ) ]

[Bug c++/57550] [4.8/4.9 Regression] bogus "error ... is private"

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57550

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
The behavior for the testcase changed with r190664 aka PR51213.

[Bug rtl-optimization/57459] [4.8 Regression] LRA inheritance bug

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57459

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-06-07
   Assignee|unassigned at gcc dot gnu.org  |vmakarov at gcc dot 
gnu.org
Summary|[4.8/4.9 Regression] LRA|[4.8 Regression] LRA
   |inheritance bug |inheritance bug
 Ever confirmed|0   |1

--- Comment #7 from Jakub Jelinek  ---
Author: vmakarov
Date: Thu Jun  6 20:58:46 2013
New Revision: 199762

URL: http://gcc.gnu.org/viewcvs?rev=199762&root=gcc&view=rev
Log:
2013-06-06  Vladimir Makarov  

PR rtl-optimization/57459
* lra-constraints.c (update_ebb_live_info): Fix typo for operand
type when setting live regs.

2013-06-06  Vladimir Makarov  

PR rtl-optimization/57459
* gcc.target/i386/pr57459.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr57459.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/57553] Valid use of STORAGE_SIZE rejected, bad error message for invalid use

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57553

--- Comment #1 from Tobias Burnus  ---
"13.7.160 STORAGE SIZE (A [, KIND])
 Description. Storage size in bits.
 Class. Inquiry function.
 Arguments.
 A shall be a scalar or array of any type. If it is polymorphic it shall
   not be an undefined pointer. If it has any deferred type parameters
   it shall not be an unallocated allocatable variable or a disassociated
   or undefined pointer."

My impression is that the current code assumes that the argument is a variable
and not an expression (including literal constants).

[Bug fortran/57553] New: Valid use of STORAGE_SIZE rejected, bad error message for invalid use

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57553

Bug ID: 57553
   Summary: Valid use of STORAGE_SIZE rejected, bad error message
for invalid use
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: diagnostic, rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org

Found at http://mailman.j3-fortran.org/pipermail/j3/2013-June/006442.html
(please read also follow up email).


* The following looks valid to me and it is rejected with a bogus error
message:
  integer, parameter :: ESize = storage_size('a')
  1
  Error: Invalid character in name at (1)

integer, parameter :: ESize = storage_size('a')
end


* The following is invalid, but the error message location is bad:
integer, parameter :: ESize = ( storage_size(a) + 7 ) / 8
1
  Error: Unclassifiable statement at (1)

subroutine S ( A )
  character(len=*), intent(in) :: A
  integer, parameter :: ESize = ( storage_size(a) + 7 ) / 8
end

[Bug target/57540] stack pointer related loop invariants after reload

[amker.cheng at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57540

bin.cheng  changed:

   What|Removed |Added

  Component|rtl-optimization|target

--- Comment #2 from bin.cheng  ---
This only happens on arm mode.
For below gimple,
  k_8 = parent[k_29];
On ARM mode GCC expands it into,
   81: r180:SI=0xf7f0
   82: zero_extract(r180:SI,0x10,0x10)=0x
   83: r181:SI=r165:SI<<0x2
   84: r182:SI=r105:SI+r181:SI
   85: r183:SI=r182:SI+r180:SI
   86: r165:SI=[r183:SI]
while on Thumb2 GCC expands it into,
   88: r185:SI=r105:SI
   89: r186:SI=r105:SI-0x810
   90: r171:SI=[r171:SI*0x4+r186:SI]
thus resulting in much better assembly code,
.L5:
ldrr3, [sp, r3, lsl #2]
addsr2, r2, #1
cmpr3, #0
bge.L5
uxtbr2, r2

[Bug c++/57552] Internal compiler error with vector::emplace_back() for templated class constructor

[jussi.judin at ericsson dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57552

--- Comment #2 from Jussi Judin  ---
Created attachment 30273
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30273&action=edit
GCC 4.7-20130601 snapshot intermediate precompiled file.

[Bug c++/57552] Internal compiler error with vector::emplace_back() for templated class constructor

[jussi.judin at ericsson dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57552

--- Comment #1 from Jussi Judin  ---
Created attachment 30272
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30272&action=edit
GCC 4.7-20130601 snapshot output

[Bug c++/57552] New: Internal compiler error with vector::emplace_back() for templated class constructor

[jussi.judin at ericsson dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57552

Bug ID: 57552
   Summary: Internal compiler error with vector::emplace_back()
for templated class constructor
   Product: gcc
   Version: 4.7.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jussi.judin at ericsson dot com

Created attachment 30271
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30271&action=edit
Intermediate precompiled file resulting from this compilation

I'm getting an internal compiler error when trying to compile following code
with GCC 4.7.3 and with the 20130601 snapshot of 4.7 compiler series:

#include 

template
class TemplateKlass
{
};

void funktion()
{
std::vector > result;
char segment;
result.emplace_back(segment);
}

Here there is no constructor defined in TemplateKlass, but I get the same crash
if I define proper constructors. GCC 4.7.3 results in following compiler output
with given arguments:

$ /tmp/c-4.7-3/bin/g++ -save-temps --verbose --std=c++11 -o out.o -c code.cc
Using built-in specs.
COLLECT_GCC=/tmp/c-4.7-3/bin/g++
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/tmp/c-4.7-3
Thread model: posix
gcc version 4.7.3 (GCC) 
COLLECT_GCC_OPTIONS='-save-temps' '-v' '-std=c++11' '-o' 'out.o' '-c'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /tmp/c-4.7-3/libexec/gcc/x86_64-unknown-linux-gnu/4.7.3/cc1plus -E -quiet -v
-imultilib . -imultiarch x86_64-linux-gnu -D_GNU_SOURCE code.cc -mtune=generic
-march=x86-64 -std=c++11 -fpch-preprocess -o code.ii
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/tmp/c-4.7-3/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /home/ejusjud/compiles/include
 .

/tmp/c-4.7-3/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/../../../../include/c++/4.7.3

/tmp/c-4.7-3/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/../../../../include/c++/4.7.3/x86_64-unknown-linux-gnu/.

/tmp/c-4.7-3/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/../../../../include/c++/4.7.3/backward
 /tmp/c-4.7-3/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/include
 /usr/local/include
 /tmp/c-4.7-3/include
 /tmp/c-4.7-3/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-save-temps' '-v' '-std=c++11' '-o' 'out.o' '-c'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /tmp/c-4.7-3/libexec/gcc/x86_64-unknown-linux-gnu/4.7.3/cc1plus -fpreprocessed
code.ii -quiet -dumpbase code.cc -mtune=generic -march=x86-64 -auxbase-strip
out.o -std=c++11 -version -o code.s
GNU C++ (GCC) version 4.7.3 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.3, GMP version 5.1.2, MPFR version
3.1.1-p2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.7.3 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.3, GMP version 5.1.2, MPFR version
3.1.1-p2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: ebd72fbdf2a173314a31a8680934f115
‘
Internal compiler error: Error reporting routines re-entered.
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

The 20130601 snapshot will result in similar output. Also attached the
intermediate .ii precompiled file.