[Bug c++/64626] New: C++14 single quote should not always be a digit separator

[b.r.longbons at gmail dot com]

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

Bug ID: 64626
   Summary: C++14 single quote should not always be a digit
separator
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: b.r.longbons at gmail dot com

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

During preprocessing, single quote (') should only be considered a digit
separator if it is followed by a digit or nondigit.

If it is followed by any other character, it should be considered as the start
of a new character-literal, not part of the current pp-number.

I am aware of exactly 2 other cases where a preprocessing-token needs to
consume 2 characters or none at all (. -> ... and %: -> %:%:), and gcc seems to
handle them correctly. (There is also the <:: case which looks ahead two
characters to *not* consume a character).


Unimplemented: gcc 4.8
Bad: Debian gcc 4.9.1-19
Bad: gcc 5.0.0 snapshot from 20141228
Good: Debian clang 3.4, 3.5, and svn snapshot of 3.6

[Bug c++/64626] C++14 single quote should not always be a digit separator

[b.r.longbons at gmail dot com]

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

--- Comment #1 from Ben Longbons  ---
Demostration that gcc correctly preprocesses the other tokens:

#define JOIN(a, b) a##b
JOIN(.., .)
// error about pasting . and .

#define JOIN3(a, b, c) a##b##c
JOIN3(%:%, :, %:)
// successfully results in %: %:%:
// (though note that the order of evaluation of ## is unspecified so if b##c
were evaluated first a compliant implementation could fail to paste :%:)

[Bug ipa/64218] [5 Regression] ICE: Segmentation fault (symtab_node::get_alias_target()) running Boost testsuite

[trippels at gcc dot gnu.org]

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

--- Comment #11 from Markus Trippelsdorf  ---
(In reply to Jan Hubicka from comment #10)
> Wonder if this one is fixed, too...

No. It still crashes.

[Bug libgomp/64625] ___OFFLOAD_TABLE__ symbol not produced on x86_64 darwin

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-16
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed.

[Bug tree-optimization/61743] [5 Regression] Complete unroll is not happened for loops with short upper bound

[rguenther at suse dot de]

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

--- Comment #16 from rguenther at suse dot de  ---
On Thu, 15 Jan 2015, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61743
> 
> Jakub Jelinek  changed:
> 
>What|Removed |Added
> 
>  CC||jakub at gcc dot gnu.org
> 
> --- Comment #15 from Jakub Jelinek  ---
> The testcases fail on x86_64 with -m32:
> grep 'loop with . iterations completely unrolled' pr61743-1.c.128t.cunroll 
> pr61743-1.c:25:5: note: loop with 8 iterations completely unrolled
> pr61743-1.c:16:5: note: loop with 8 iterations completely unrolled
> pr61743-1.c:16:5: note: loop with 3 iterations completely unrolled
> pr61743-1.c:29:5: note: loop with 2 iterations completely unrolled
> pr61743-1.c:24:3: note: loop with 4 iterations completely unrolled
> grep 'loop with . iterations completely unrolled' pr61743-2.c.128t.cunroll 
> pr61743-2.c:25:5: note: loop with 8 iterations completely unrolled
> pr61743-2.c:16:5: note: loop with 8 iterations completely unrolled
> pr61743-2.c:16:5: note: loop with 3 iterations completely unrolled
> pr61743-2.c:29:5: note: loop with 2 iterations completely unrolled
> pr61743-2.c:24:3: note: loop with 4 iterations completely unrolled
> (latest trunk).  With -m64 they work fine.

Huh, it passed for me ontop of r219648.  Let me re-check.

[Bug tree-optimization/61743] [5 Regression] Complete unroll is not happened for loops with short upper bound

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #17 from Richard Biener  ---
Works for me and also for HJ it seems.  (fixed)

[Bug middle-end/64568] [5 Regression] error: invalid reference prefix

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #6 from Markus Trippelsdorf  ---
I still happens running the Boost testsuite on ppc64:


trippels@gcc2-power8 status % g++ -c -O3 -std=c++11 test22.ii
In file included from ../libs/numeric/ublas/test/test2.hpp:22:0,
 from ../libs/numeric/ublas/test/test22.cpp:13:
../boost/numeric/ublas/blas.hpp: In function ‘M&
boost::numeric::ublas::blas_2::hr2(M&, const T&, const V1&, const V2&) [with M
= boost::numeric::ublas::matrix >; T =
std::complex; V1 = boost::numeric::ublas::vector
>; V2 = boost::numeric::ublas::vector >]’:
../boost/numeric/ublas/blas.hpp:330:13: error: invalid reference prefix
 M & hr2 (M &m, const T &t, const V1 &v1, const V2 &v2)
 ^
MEM[base: _216, index: ivtmp.1531_157, offset: 0]
cc1plus: note: in statement
# VUSE <.MEM_156>
_158 = IMAGPART_EXPR ;
../boost/numeric/ublas/blas.hpp:330:13: error: invalid reference prefix
MEM[base: _216, index: ivtmp.1531_157, offset: 0]
cc1plus: note: in statement
# VUSE <.MEM_156>
_91 = REALPART_EXPR ;
../boost/numeric/ublas/blas.hpp:330:13: internal compiler error: verify_gimple
failed
0x10a48a6f verify_gimple_in_cfg(function*, bool)
../../gcc/gcc/tree-cfg.c:5069
0x10903e53 execute_function_todo
../../gcc/gcc/passes.c:1955
0x10904a93 do_per_function
../../gcc/gcc/passes.c:1647
0x10904d67 execute_todo
../../gcc/gcc/passes.c:2012
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


Reducing...

[Bug tree-optimization/64622] convoluted loop codegen for __strcspn_c1

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
That's indeed more clever "loop header copying".

[Bug tree-optimization/64622] convoluted loop codegen for __strcspn_c1

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
without loop header copyign we generate

__strcspn_c1:
.LFB0:
.cfi_startproc
xorl%eax, %eax
jmp .L2
.p2align 4,,10
.p2align 3
.L8:
cmpl%esi, %edx
je  .L6
addq$1, %rax
.L2:
movsbl  (%rdi,%rax), %edx
testb   %dl, %dl
jne .L8
.L6:
rep ret

so it would be interesting to investigate how they do this (if it's a special
hack or some systematic fix).  The loop header contains just the IV increment
here.

[Bug c++/51747] [DR 1467] [C++11] cannot call defaulted copy constructor using list-initialization

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||ville.voutilainen at gmail dot 
com
 Resolution|FIXED   |---

--- Comment #8 from Ville Voutilainen  ---
This case fails:

struct base {
};

struct derived : base {
derived(const base &state)
: base{state} // Gcc, Clang, and EDG reject.
{}
};

void f(base b) {
derived d{b};

}

Should this be a separate bug? The call of the implicitly-defaulted
copy constructor fails using list-initialization, so this seems like
it should be part of the same PR.

[Bug middle-end/64621] MIssed tail call oppurtunity

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Well, this really really asks for the function signatures to be updated to the
call ABI at the GIMPLE level...

OTOH, (int) strtol (...) possibly truncates the value so it's not a noop
(it's a noop on i?86 only).

[Bug rtl-optimization/11222] arm/thumb __Unwind_SjLj_Register prologue optimization causes crash on interrupts

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ramana at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #11 from Ramana Radhakrishnan  ---
This is almost gone now. I can't reproduce it with trunk probably because
arm-elf is now dead and long gone, as everything is now EABI centric.

[Bug tree-optimization/64601] Missed PRE on std::vector move assignment

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
(In reply to Marc Glisse from comment #3)
> Actually there is no need for inlining.
> 
> struct A { int i; };
> void f(struct A *a){ *&a->i=0; }
> void g(struct A *a){ int*p=&a->i;*p=0; }
> 
> The main difference seems to be that the first one gets through fold-const.c
> while the second is handled by tree-ssa-forwprop.c.

&a->i is merely an address calculation, not an access to type A at a.  Thus
it's valid to write

 struct B { int i; int j; };
 struct B b;
 int *p = &((struct A *)&b)->i;
 *p = 0;

and it's only required that the actual access (here a int * dereference)
honors TBAA rules.

So generally you can't "reconstruct" access paths when forwarding address
calculations into dereferences.  We've had very elaborate code "guessing"
access paths in oder releases which broke down very easily for moderately
complex testcases.

We still have some of that code in forwprop (I still believe it's not
100% correct...) which handles

struct A { int i[4]; };
void g(struct A *a, int j) { int *p = &a->i[j]; *p = 0;}

generating

  MEM[(int *)a_1(D)].i[j_2(D)] = 0;
  return;

but the case comes after forwarding invariant addresses.  If we'd swap them
(really believing in its correctness) then we also handle your case.
But as I said - that "If ... and the value type is the same as that of the
pointed-to type of the address" is really bogus - the type of the address
doesn't have any meaning in GIMPLE (all pointer type conversions are
useless).

[Bug tree-optimization/64601] Missed PRE on std::vector move assignment

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Created attachment 34460
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34460&action=edit
patch

This is what I am talking about (I think it's wrong and instead we have
to remove the case completely)

[Bug target/59710] Nios2: Missing gprel optimization

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

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

Sebastian Huber  changed:

   What|Removed |Added

  Known to work||5.0

--- Comment #3 from Sebastian Huber  ---
Thanks, this fixes the problem in case the new -mgpot=global option is used. Do
you plan to back port this to GCC 4.9? If not, then can you please adjust the
target milestone and close the PR.

nios2-elf-gcc -O2 -mgpopt=global -fno-common -S gprel-ok.c && cat gprel-ok.s
.file   "gprel-ok.c"
.section.text
.align  2
.global gprel_ok
.type   gprel_ok, @function
gprel_ok:
movir2, 123
stw r2, %gprel(iii)(gp)
movir2, 789
stw r2, %gprel(jjj)(gp)
ret
.size   gprel_ok, .-gprel_ok
.global jjj
.section.sdata,"aws",@progbits
.align  2
.type   jjj, @object
.size   jjj, 4
jjj:
.long   456
.global iii
.section.sbss,"aws",@nobits
.align  2
.type   iii, @object
.size   iii, 4
iii:
.zero   4
.ident  "GCC: (GNU) 5.0.0 20150116 (experimental)"
nios2-elf-gcc -O2 -mgpopt=global -fno-common -S gprel-not-ok.c && cat
gprel-not-ok.s
.file   "gprel-not-ok.c"
.section.text
.align  2
.global gprel_not_ok
.type   gprel_not_ok, @function
gprel_not_ok:
movir2, 123
stw r2, %gprel(iii)(gp)
movir2, 789
stw r2, %gprel(jjj)(gp)
ret
.size   gprel_not_ok, .-gprel_not_ok
.ident  "GCC: (GNU) 5.0.0 20150116 (experimental)"

[Bug ipa/62016] [4.8/4.9 Regression] very slow compilation at -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||5.0
Summary|[4.8/4.9/5 Regression] very |[4.8/4.9 Regression] very
   |slow compilation at -O3 on  |slow compilation at -O3 on
   |x86_64-linux-gnu|x86_64-linux-gnu
  Known to fail||4.8.3, 4.9.2

--- Comment #10 from Richard Biener  ---
Yep.

> /usr/bin/time gcc-4.7 t.c -O3
0.10user 0.02system 0:00.62elapsed 21%CPU (0avgtext+0avgdata 15704maxresident)k
26080inputs+48outputs (113major+9177minor)pagefaults 0swaps
> /usr/bin/time gcc-4.8 t.c -O3
^C
0.00user 0.00system 6:11.40elapsed 0%CPU (0avgtext+0avgdata 1136maxresident)k
1440inputs+0outputs (7major+331minor)pagefaults 0swaps
> /usr/bin/time gcc-4.9 t.c -O3
3.13user 0.18system 0:03.84elapsed 86%CPU (0avgtext+0avgdata
404088maxresident)k
28400inputs+48outputs (128major+137978minor)pagefaults 0swaps
> /usr/bin/time /space/rguenther/install/gcc-5.0/bin/gcc t.c -O3
0.04user 0.01system 0:00.28elapsed 20%CPU (0avgtext+0avgdata 13364maxresident)k
6376inputs+48outputs (17major+8570minor)pagefaults 0swaps

[Bug c++/58614] [c++11] ICE with undeclared variable in initializer list

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Fri Jan 16 09:38:59 2015
New Revision: 219716

URL: https://gcc.gnu.org/viewcvs?rev=219716&root=gcc&view=rev
Log:
/cp
2015-01-16  Paolo Carlini  

PR c++/58614
* pt.c (unify): When BRACE_ENCLOSED_INITIALIZER_P (arg), handle
TREE_TYPE (elt) == error_mark_node.

/testsuite
2015-01-16  Paolo Carlini  

PR c++/58614
* g++.dg/cpp0x/auto44.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/auto44.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/64601] Missed PRE on std::vector move assignment

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Note that we do it correctly even - forcing a TBAA type of just 'int' and thus
disabling path-based disambiguation.

So doing this won't help you, it just will generate larger trees:

void f(V&, V&) (struct V & v, struct V & w)
{
  int * _3;
  int * _6;
  int * _7;
  int * _8;

  :
  _3 = MEM[(int * &)w_2(D)].D.14881._M_impl._M_start;
  MEM[(int * &)w_2(D)].D.14881._M_impl._M_start = 0B;
  _6 = MEM[(int * &)w_2(D)].D.14881._M_impl._M_finish;
  MEM[(int * &)w_2(D)].D.14881._M_impl._M_finish = 0B;
  _7 = MEM[(int * &)w_2(D)].D.14881._M_impl._M_end_of_storage;
  MEM[(int * &)w_2(D)].D.14881._M_impl._M_end_of_storage = 0B;
  _8 = MEM[(int * &)v_4(D)].D.14881._M_impl._M_start;
  MEM[(int * &)v_4(D)].D.14881._M_impl._M_start = _3;
  MEM[(int * &)v_4(D)].D.14881._M_impl._M_finish = _6;
  MEM[(int * &)v_4(D)].D.14881._M_impl._M_end_of_storage = _7;
...

void g(V&, V&) (struct V & v, struct V & w)
{
  int * __tmp.0_5;
  int * _6;
  int * __tmp.0_7;
  int * _8;
  int * __tmp.0_9;
  int * _10;

  :
  __tmp.0_5 = MEM[(int * &)v_4(D)].D.14881._M_impl._M_start;
  MEM[(int * &)v_4(D)].D.14881._M_impl._M_start = 0B;
  MEM[(int * &)v_4(D)].D.14881._M_impl._M_finish = 0B;
  MEM[(int * &)v_4(D)].D.14881._M_impl._M_end_of_storage = 0B;
  _6 = MEM[(int * &)w_2(D)].D.14881._M_impl._M_start;
  MEM[(int * &)v_4(D)].D.14881._M_impl._M_start = _6;
  MEM[(int * &)w_2(D)].D.14881._M_impl._M_start = 0B;
  __tmp.0_7 = MEM[(int * &)v_4(D)].D.14881._M_impl._M_finish;
  _8 = MEM[(int * &)w_2(D)].D.14881._M_impl._M_finish;
  MEM[(int * &)v_4(D)].D.14881._M_impl._M_finish = _8;
  MEM[(int * &)w_2(D)].D.14881._M_impl._M_finish = __tmp.0_7;
  __tmp.0_9 = MEM[(int * &)v_4(D)].D.14881._M_impl._M_end_of_storage;
  _10 = MEM[(int * &)w_2(D)].D.14881._M_impl._M_end_of_storage;
  MEM[(int * &)v_4(D)].D.14881._M_impl._M_end_of_storage = _10;
  MEM[(int * &)w_2(D)].D.14881._M_impl._M_end_of_storage = __tmp.0_9;

they are still all plain int * accesses.

[Bug c++/58614] [c++11] ICE with undeclared variable in initializer list

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org

--- Comment #3 from Paolo Carlini  ---
Fixed for 5.0.

[Bug tree-optimization/64601] Missed PRE on std::vector move assignment

[glisse at gcc dot gnu.org]

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

--- Comment #7 from Marc Glisse  ---
I am testing the following hack, I hope there will be at least 1 failure in the
testsuite that will help me understand why it is wrong. It bootstraps and gives
accesses like MEM[(struct _Vector_impl *)v_4(D)]._M_start.

> struct B { int i; int j; };
> struct B b;
> int *p = &((struct A *)&b)->i;
> *p = 0;

Hmmm, yeah, that's ugly... I wish it weren't legal... I'll have to play with it
to see exactly how bad it is... Thanks for the example.

--- tree-ssa-forwprop.c(revision 219694)
+++ tree-ssa-forwprop.c(working copy)
@@ -777,20 +777,41 @@ forward_propagate_addr_expr_1 (tree name
 new_def_rhs);
   else if (is_gimple_min_invariant (new_def_rhs))
 gimple_assign_set_rhs_with_ops (use_stmt_gsi, NOP_EXPR, new_def_rhs);
   else
 return false;
   gcc_assert (gsi_stmt (*use_stmt_gsi) == use_stmt);
   update_stmt (use_stmt);
   return true;
 }

+  /* *&X -> X.  */
+  if (TREE_CODE (lhs) == MEM_REF
+  && TREE_OPERAND (lhs, 0) == name
+  && integer_zerop (TREE_OPERAND (lhs, 1))
+  && useless_type_conversion_p (TREE_TYPE (lhs),
+TREE_TYPE (TREE_OPERAND (def_rhs, 0
+{
+  gimple_assign_set_lhs (use_stmt, unshare_expr (TREE_OPERAND (def_rhs,
0)));
+  tidy_after_forward_propagate_addr (use_stmt);
+  return true;
+}
+  else if (TREE_CODE (rhs) == MEM_REF
+  && TREE_OPERAND (rhs, 0) == name
+  && integer_zerop (TREE_OPERAND (rhs, 1))
+  && useless_type_conversion_p (TREE_TYPE (rhs),
+TREE_TYPE (TREE_OPERAND (def_rhs, 0
+{
+  gimple_assign_set_rhs1 (use_stmt, unshare_expr (TREE_OPERAND (def_rhs,
0)));
+  tidy_after_forward_propagate_addr (use_stmt);
+  return true;
+}
   /* Now strip away any outer COMPONENT_REF/ARRAY_REF nodes from the LHS.
  ADDR_EXPR will not appear on the LHS.  */
   tree *lhsp = gimple_assign_lhs_ptr (use_stmt);
   while (handled_component_p (*lhsp))
 lhsp = &TREE_OPERAND (*lhsp, 0);
   lhs = *lhsp;

   /* Now see if the LHS node is a MEM_REF using NAME.  If so,
  propagate the ADDR_EXPR into the use of NAME and fold the result.  */
   if (TREE_CODE (lhs) == MEM_REF

[Bug ipa/61548] [5 Regression] FAIL: gcc.dg/tls/alias-1.c (internal compiler error)

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED

--- Comment #11 from ktkachov at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #10)
> I believe this is also fixed by the ipa-inline alias handling fix.

I still see the ICE on ARM at least as of r219714:

$TOP/gcc/gcc/testsuite/gcc.dg/tls/alias-1.c:24:3: internal compiler error:
Segmentation fault
0xa61df5 crash_signal
$TOP/gcc/gcc/toplev.c:381
0x6a05d8 symtab_node::get_alias_target()
$TOP/gcc/gcc/cgraph.h:2271
0x6a05d8 symtab_node::verify_base()
$TOP/gcc/gcc/symtab.c:1130
0x6a0983 symtab_node::verify()
$TOP/gcc/gcc/symtab.c:1163
0x6a19af symtab_node::verify_symtab_nodes()
$TOP/gcc/gcc/symtab.c:1181
0x8dabd6 symbol_table::remove_unreachable_nodes(_IO_FILE*)
$TOP/gcc/gcc/ipa.c:662
0x6b1fa4 ipa_passes
$TOP/gcc/gcc/cgraphunit.c:2087
0x6b1fa4 symbol_table::compile()
$TOP/gcc/gcc/cgraphunit.c:2221
0x6b3c71 symbol_table::finalize_compilation_unit()
$TOP/gcc/gcc/cgraphunit.c:2370
0x54d083 c_write_global_declarations()
$TOP/gcc/gcc/c/c-decl.c:10787
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

[Bug target/64011] Fail to compile pr48335-2.c on big-endian where bit insert instruction supported

[jiwang at gcc dot gnu.org]

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

--- Comment #3 from Jiong Wang  ---
Author: jiwang
Date: Fri Jan 16 10:14:51 2015
New Revision: 219717

URL: https://gcc.gnu.org/viewcvs?rev=219717&root=gcc&view=rev
Log:
[Patch] Warn and truncate bitsize when partial overflow happen

  PR rtl-optimization/64011
  gcc/
* expmed.c (store_bit_field_using_insv): Warn and truncate bitsize when
there is partial overflow.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/expmed.c

[Bug libffi/64607] [5 Regression] Multilib test stops working in libffi

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
As expected from comment 0, the following patch restores the previous behavior.

--- ../_clean/libffi/Makefile.in2015-01-12 17:31:37.0 +0100
+++ libffi/Makefile.in2015-01-15 23:02:11.0 +0100
@@ -336,39 +336,39 @@ MAINTAINERCLEANFILES = $(srcdir)/doc/lib
 # values defined in terms of make variables, as is the case for CC and
 # friends when we are called from the top level Makefile.
 AM_MAKEFLAGS = \
-'AR_FLAGS=$(AR_FLAGS)' \
-'CC_FOR_BUILD=$(CC_FOR_BUILD)' \
-'CFLAGS=$(CFLAGS)' \
-'CXXFLAGS=$(CXXFLAGS)' \
-'CFLAGS_FOR_BUILD=$(CFLAGS_FOR_BUILD)' \
-'CFLAGS_FOR_TARGET=$(CFLAGS_FOR_TARGET)' \
-'INSTALL=$(INSTALL)' \
-'INSTALL_DATA=$(INSTALL_DATA)' \
-'INSTALL_PROGRAM=$(INSTALL_PROGRAM)' \
-'INSTALL_SCRIPT=$(INSTALL_SCRIPT)' \
-'JC1FLAGS=$(JC1FLAGS)' \
-'LDFLAGS=$(LDFLAGS)' \
-'LIBCFLAGS=$(LIBCFLAGS)' \
-'LIBCFLAGS_FOR_TARGET=$(LIBCFLAGS_FOR_TARGET)' \
-'MAKE=$(MAKE)' \
-'MAKEINFO=$(MAKEINFO) $(MAKEINFOFLAGS)' \
-'PICFLAG=$(PICFLAG)' \
-'PICFLAG_FOR_TARGET=$(PICFLAG_FOR_TARGET)' \
-'RUNTESTFLAGS=$(RUNTESTFLAGS)' \
-'SHELL=$(SHELL)' \
-'exec_prefix=$(exec_prefix)' \
-'infodir=$(infodir)' \
-'libdir=$(libdir)' \
-'mandir=$(mandir)' \
-'prefix=$(prefix)' \
-'AR=$(AR)' \
-'AS=$(AS)' \
-'CC=$(CC)' \
-'CXX=$(CXX)' \
-'LD=$(LD)' \
-'NM=$(NM)' \
-'RANLIB=$(RANLIB)' \
-'DESTDIR=$(DESTDIR)'
+"AR_FLAGS=$(AR_FLAGS)" \
+"CC_FOR_BUILD=$(CC_FOR_BUILD)" \
+"CFLAGS=$(CFLAGS)" \
+"CXXFLAGS=$(CXXFLAGS)" \
+"CFLAGS_FOR_BUILD=$(CFLAGS_FOR_BUILD)" \
+"CFLAGS_FOR_TARGET=$(CFLAGS_FOR_TARGET)" \
+"INSTALL=$(INSTALL)" \
+"INSTALL_DATA=$(INSTALL_DATA)" \
+"INSTALL_PROGRAM=$(INSTALL_PROGRAM)" \
+"INSTALL_SCRIPT=$(INSTALL_SCRIPT)" \
+"JC1FLAGS=$(JC1FLAGS)" \
+"LDFLAGS=$(LDFLAGS)" \
+"LIBCFLAGS=$(LIBCFLAGS)" \
+"LIBCFLAGS_FOR_TARGET=$(LIBCFLAGS_FOR_TARGET)" \
+"MAKE=$(MAKE)" \
+"MAKEINFO=$(MAKEINFO) $(MAKEINFOFLAGS)" \
+"PICFLAG=$(PICFLAG)" \
+"PICFLAG_FOR_TARGET=$(PICFLAG_FOR_TARGET)" \
+"RUNTESTFLAGS=$(RUNTESTFLAGS)" \
+"SHELL=$(SHELL)" \
+"exec_prefix=$(exec_prefix)" \
+"infodir=$(infodir)" \
+"libdir=$(libdir)" \
+"mandir=$(mandir)" \
+"prefix=$(prefix)" \
+"AR=$(AR)" \
+"AS=$(AS)" \
+"CC=$(CC)" \
+"CXX=$(CXX)" \
+"LD=$(LD)" \
+"NM=$(NM)" \
+"RANLIB=$(RANLIB)" \
+"DESTDIR=$(DESTDIR)"


 # Subdir rules rely on $(FLAGS_TO_PASS)


=== libffi tests ===


Running target unix/-m32

=== libffi Summary for unix/-m32 ===

# of expected passes1904
# of unsupported tests30

Running target unix/-m64

=== libffi Summary for unix/-m64 ===

# of expected passes1904
# of unsupported tests30

=== libffi Summary ===

# of expected passes3808
# of unsupported tests60

[Bug target/64011] Fail to compile pr48335-2.c on big-endian where bit insert instruction supported

[jiwang at gcc dot gnu.org]

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

Jiong Wang  changed:

   What|Removed |Added

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

--- Comment #4 from Jiong Wang  ---
mark as fixed

[Bug target/64624] ppc64 build failure, ISA_2_7_MASKS_SERVER not declared

[anton at samba dot org]

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

Anton Blanchard  changed:

   What|Removed |Added

 Target||powerpc64le-
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Anton Blanchard  ---
Network issues during submit, ended up with two identical bugs.

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

[Bug target/64623] New: ppc64 build failure, ISA_2_7_MASKS_SERVER not declared

[anton at samba dot org]

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

Bug ID: 64623
   Summary: ppc64 build failure, ISA_2_7_MASKS_SERVER not declared
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anton at samba dot org

I'm seeing this build error as of:

* config/rs6000/default64.h (TARGET_DEFAULT) [LITTLE_ENDIAN]: Use
ISA 2.7 (POWER8).

g++ -c   -g -O2 -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common 
-DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/.
-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include 
-I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd
-I../libdecnumber -I../../gcc/gcc/../libbacktrace   -o options.o -MT options.o
-MMD -MP -MF ./.deps/options.TPo options.c
In file included from tm.h:30:0,
 from options.c:7:
../../gcc/gcc/config/rs6000/default64.h:23:25: error: ‘ISA_2_7_MASKS_SERVER’
was not declared in this scope
 #define TARGET_DEFAULT (ISA_2_7_MASKS_SERVER | MASK_POWERPC64 | MASK_64BIT |
MASK_LITTLE_ENDIAN)
 ^
options.c:828:3: note: in expansion of macro ‘TARGET_DEFAULT’
   TARGET_DEFAULT, /* rs6000_isa_flags */
   ^

--- Comment #1 from Anton Blanchard  ---
*** Bug 64624 has been marked as a duplicate of this bug. ***

gcc-bugs@gcc.gnu.org

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Created attachment 34461
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34461&action=edit
preliminary patch

I think the uninit pass doesn't even try to handle switch case input conditions
(convert_control_dep_chain_into_preds).  Nor does predicate handling deal with
bar & 3 predicates.

Preliminary patch attached - still needs to handle the default case - but
it seems we don't warn about the return value with the patch.

With the patch:

[CHECK] Found def edge 1 in tmp_1 = PHI 
[BEFORE SIMPLICATION -- [USE]:
MEM[(char *)tmp_1 + 11B] = 15;
is guarded by :

bar_4(D) == 2

[BEFORE SIMPLICATION -- [DEF]:
tmp_1 = PHI 
is guarded by :

_5 != 0

[AFTER NORMALIZATION -- [DEF]:
tmp_1 = PHI 
is guarded by :

bar_4(D) & 3

[Bug middle-end/64568] [5 Regression] error: invalid reference prefix

[trippels at gcc dot gnu.org]

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

--- Comment #7 from Markus Trippelsdorf  ---
trippels@gcc2-power8 status % cat test22.ii
namespace std
{
typedef long unsigned size_t;
}
class H;
namespace std
{
template  struct complex;
template 
complex<_Tp> operator+(complex<_Tp> &__x, complex<_Tp> __y)
{
  complex<_Tp> a = __x;
  a += __y;
  return a;
}
template <> struct complex
{
  int
  imag ()
  {
return __imag__ _M_value;
  }
  void operator+=(complex __z) { _M_value += _M_value; _M_value  += __z.imag
(); }
  _Complex double _M_value;
};
}
struct A
{
  typedef std::complex &const_reference;
};
class B
{
public:
  B (int);
  std::complex &operator[](int i) { return data_[i]; }
  std::complex *data_;
};
struct C
{
  static std::complex
  apply (A::const_reference t1, std::complex t2)
  {
return t1 + t2;
  }
  typedef std::complex result_type;
};
template  struct D
{
  static void
  apply (T1 t1, std::complex t2)
  {
t1 = t2;
  }
};
class ublas_expression
{
public:
  ~ublas_expression ();
};
template  class F
{
};
template  class matrix_expression : ublas_expression
{
public:
  E &operator()() {}
};
class I : public F
{
public:
  typedef int value_type;
  I (int);
};
template  matrix_expression outer_prod (F, F);
template  class J : public matrix_expression >
{
public:
  typedef typename F::result_type value_type;
  value_type operator()(int i, int)
  {
return F::apply (e1_ (i, 0), e2_ (0, 0));
  }
  E1 e1_;
  E1 e2_;
};
template 
J operator+(matrix_expression, matrix_expression);
template  class F, class M, class E>
void
indexing_matrix_assign (M m, matrix_expression e, int)
{
  for (int i; i; ++i)
F::apply (m (0, 0),
 e ()(i, 0));
}
template  class F, class, class M, class E, class C>
void
matrix_assign (M m, matrix_expression e, int, C)
{
  indexing_matrix_assign (m, e, 0);
}
template  class F, class M, class E>
void
matrix_assign (M m, matrix_expression e)
{
  matrix_assign (m, e, 0, typename M::orientation_category ());
}
class H : matrix_expression
{
public:
  typedef std::complex &reference;
  typedef int orientation_category;
  H (int, int) : data_ (0) {}
  template  H (matrix_expression ae) : data_ (0)
  {
matrix_assign (*this, ae);
  }
  B &
  data ()
  {
  }
  std::complex &operator()(int i, int) { return data ()[i]; }
  void operator+=(matrix_expression ae) { H (*this + ae); }
  B data_;
};
template 
void
sr2 (M m, T, V1 v1, V2 v2)
{
  m += outer_prod (v2, v1);
}
template  struct G
{
  void test ();
};
template struct G;
template 
void
G::test ()
{
  V b (0), c (0);
  M m (0, 0);
  sr2 (m, typename V::value_type (), b, c);
}

trippels@gcc2-power8 status % g++ -c -O2 -std=c++11 test22.ii
test22.ii: In member function ‘void G< ,
,  >::test() [with 
= I;  = H; long unsigned int  = 3ul]’:
test22.ii:139:1: error: invalid reference prefix
 G::test ()
 ^
MEM[base: _44, offset: 0]
cc1plus: note: in statement
# VUSE <.MEM_59>
_26 = IMAGPART_EXPR ;
test22.ii:139:1: error: invalid reference prefix
MEM[base: _44, offset: 0]
cc1plus: note: in statement
# VUSE <.MEM_59>
_51 = REALPART_EXPR ;
test22.ii:139:1: internal compiler error: verify_gimple failed

[Bug libgomp/64625] ___OFFLOAD_TABLE__ symbol not produced on x86_64 darwin

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||openacc, openmp
   Priority|P3  |P1
 CC||andrey.turetskiy at gmail dot 
com,
   ||bernds at gcc dot gnu.org,
   ||iverbin at gmail dot com,
   ||kyukhin at gcc dot gnu.org
   Target Milestone|--- |5.0

--- Comment #3 from Thomas Schwinge  ---
In fact, the __OFFLOAD_TABLE__ symbol (formerly known as __OPENMP_TARGET__)
should be completely removed, as it's unused.  We settled on a different scheme
for passing this data.

We can't remove it from the libgomp OpenMP target interfaces (so, just pass
NULL for those, and remove its documentation in source code comments), because
that'd be an ABI change requiring a new symbol version, but we can remove it
from the libgomp OpenACC interfaces (ABI change still possible now, before the
5.0 release, thus setting P1).

[Bug bootstrap/64612] [5 Regression] profiledbootstrap failures

[trippels at gcc dot gnu.org]

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

--- Comment #9 from Markus Trippelsdorf  ---
Author: trippels
Date: Fri Jan 16 11:12:52 2015
New Revision: 219721

URL: https://gcc.gnu.org/viewcvs?rev=219721&root=gcc&view=rev
Log:
g++.dg/ipa/pr64612.C: New test.

2015-01-16  Markus Trippelsdorf  

PR ipa/64163
PR ipa/64612
* g++.dg/ipa/pr64612.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ipa/pr64612.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug ipa/64163] [5 Regression] r218024 causes qt5 build failure

[trippels at gcc dot gnu.org]

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

--- Comment #10 from Markus Trippelsdorf  ---
Author: trippels
Date: Fri Jan 16 11:12:52 2015
New Revision: 219721

URL: https://gcc.gnu.org/viewcvs?rev=219721&root=gcc&view=rev
Log:
g++.dg/ipa/pr64612.C: New test.

2015-01-16  Markus Trippelsdorf  

PR ipa/64163
PR ipa/64612
* g++.dg/ipa/pr64612.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ipa/pr64612.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug ipa/64163] [5 Regression] r218024 causes qt5 build failure

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #11 from Markus Trippelsdorf  ---


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

[Bug bootstrap/64612] [5 Regression] profiledbootstrap failures

[trippels at gcc dot gnu.org]

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

--- Comment #10 from Markus Trippelsdorf  ---
*** Bug 64163 has been marked as a duplicate of this bug. ***

[Bug libstdc++/64438] Removing string-conversion requirement causes libstdc++-v3 fails on AArch64.

[belagod at gcc dot gnu.org]

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

Tejas Belagod  changed:

   What|Removed |Added

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

--- Comment #6 from Tejas Belagod  ---
Fixed.Thanks.

[Bug c++/64611] Using a << operator inside an overloaded << operator gives compile error

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
   Last reconfirmed||2015-01-16
 Resolution|DUPLICATE   |---
 Ever confirmed|0   |1

--- Comment #5 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #4)
> This is a bug and a dup of bug 11814.
> 
> *** This bug has been marked as a duplicate of bug 11814 ***

I don't think so

[Bug testsuite/64605] [5 Regression] ERROR: (DejaGnu) proc "libatomic_target_compile lto1738.c lto1738.o object additional_flags=-flto" does not exist.

[iverbin at gcc dot gnu.org]

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

--- Comment #2 from iverbin at gcc dot gnu.org ---
Author: iverbin
Date: Fri Jan 16 11:29:54 2015
New Revision: 219722

URL: https://gcc.gnu.org/viewcvs?rev=219722&root=gcc&view=rev
Log:
PR testsuite/64605

libatomic/
* testsuite/lib/libatomic.exp: Do not load gcc-dg.exp.
* testsuite/libatomic.c/c.exp: Load gcc-dg.exp.

Modified:
trunk/libatomic/ChangeLog
trunk/libatomic/testsuite/lib/libatomic.exp
trunk/libatomic/testsuite/libatomic.c/c.exp

[Bug c++/64627] New: Internal compiler error: Segmentation fault

[physik3 at gmx dot net]

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

Bug ID: 64627
   Summary: Internal compiler error: Segmentation fault
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: physik3 at gmx dot net

Created attachment 34462
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34462&action=edit
source file from openVDB library

Hi everyone.

When I try to build openVDB (http://www.openvdb.org/download/) and compile the
file openvdb.cc, GCC crashes with a segmentation fault. As the message asks me
to submit a bug report, I am doing so now.

Error message (I am building on a German system; "Speicherzugriffsfehler" means
segmentation fault):

=
In file included from ../openvdb/tree/Tree.h:53:0,
 from Grid.h:43,
 from openvdb.h:39,
 from openvdb.cc:31:
../openvdb/tree/TreeIterator.h: In instantiation of ‘class
openvdb::v3_0_0::tree::IterListItem, 3u>, 4u>, 5u> > >,
openvdb::v3_0_0::tree::RootNode, 3u>, 4u>, 5u>
>::ChildIter, 3u>, 4u>, 5u> >, std::_Rb_tree_iterator, 3u>, 4u>, 5u> >::NodeStruct> >,
openvdb::v3_0_0::tree::RootNode, 3u>, 4u>, 5u> >::ChildOnPred,
openvdb::v3_0_0::tree::InternalNode, 3u>, 4u>, 5u> > >::PrevItem,
boost::mpl::v_item, 3u>, 4u>, 5u> >,
boost::mpl::v_item, 3u>, 4u>, 5u>,
boost::mpl::vector2, 3u>,
openvdb::v3_0_0::tree::InternalNode, 3u>, 4u> >, 0>, 0>, 4ul, 0u>’:
../openvdb/tree/TreeIterator.h:1296:76:   required from ‘class
openvdb::v3_0_0::tree::LeafIteratorBase, 3u>, 4u>, 5u> > >,
openvdb::v3_0_0::tree::RootNode, 3u>, 4u>, 5u>
>::ChildIter, 3u>, 4u>, 5u> >, std::_Rb_tree_iterator, 3u>, 4u>, 5u> >::NodeStruct> >,
openvdb::v3_0_0::tree::RootNode, 3u>, 4u>, 5u> >::ChildOnPred,
openvdb::v3_0_0::tree::InternalNode, 3u>, 4u>, 5u> > >’
../openvdb/tree/Tree.h:1681:19:   required from ‘void
openvdb::v3_0_0::tree::Tree<_RootNodeType>::clipUnallocatedNodes() [with
_RootNodeType =
openvdb::v3_0_0::tree::RootNode, 3u>, 4u>, 5u> >]’
openvdb.cc:168:1:   required from here
../openvdb/tree/TreeIterator.h:441:40: internal compiler error:
Speicherzugriffsfehler
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
=

Greetings

[Bug rtl-optimization/64616] Redundant ldr when accessing var inside and outside a loop

[thopre01 at gcc dot gnu.org]

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

thopre01 at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-01-16
   Assignee|unassigned at gcc dot gnu.org  |thopre01 at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug target/64015] [5.0 Regression] AArch64 ICE due to conditional compare

[jiwang at gcc dot gnu.org]

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

--- Comment #16 from Jiong Wang  ---
Author: jiwang
Date: Fri Jan 16 11:48:00 2015
New Revision: 219723

URL: https://gcc.gnu.org/viewcvs?rev=219723&root=gcc&view=rev
Log:
[AArch64] Enable CCMP support for AArch64, PR64015 resolved

gcc/
2015-01-16  Zhenqiang Chen  

PR target/64015
* ccmp.c (expand_ccmp_next): New function.
(expand_ccmp_expr_1, expand_ccmp_expr): Handle operand insn sequence
and compare insn sequence.
* config/aarch64/aarch64.c (aarch64_code_to_ccmode,
aarch64_gen_ccmp_first, aarch64_gen_ccmp_next): New functions.
(TARGET_GEN_CCMP_FIRST, TARGET_GEN_CCMP_NEXT): New MICRO.
* config/aarch64/aarch64.md (*ccmp_and): Changed to ccmp_and.
(*ccmp_ior): Changed to ccmp_ior.
(cmp): New pattern.
* doc/tm.texi (TARGET_GEN_CCMP_FIRST, TARGET_GEN_CCMP_NEXT): Update
parameters.
* target.def (gen_ccmp_first, gen_ccmp_next): Update parameters.

gcc/testsuite/
2015-01-16  Zhenqiang Chen 

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


Added:
trunk/gcc/testsuite/gcc.dg/pr64015.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ccmp.c
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/config/aarch64/aarch64.md
trunk/gcc/doc/tm.texi
trunk/gcc/target.def
trunk/gcc/testsuite/ChangeLog

[Bug target/64015] [5.0 Regression] AArch64 ICE due to conditional compare

[jiwang at gcc dot gnu.org]

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

Jiong Wang  changed:

   What|Removed |Added

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

--- Comment #17 from Jiong Wang  ---
mark as fixed.

[Bug rtl-optimization/64286] [4.9 Regression] Redundant extend removal ignores vector element type

[clyon at gcc dot gnu.org]

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

clyon at gcc dot gnu.org changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org,
   ||mshawcroft at gcc dot gnu.org,
   ||ramana at gcc dot gnu.org

--- Comment #11 from clyon at gcc dot gnu.org ---
For some reason, I am seeing regressions on aarch64 in the 4.9 branch, and not
on trunk.

The top-level report is here:
http://abe.tcwglab.linaro.org/logs/validations/cross-validation/gcc/gcc-4_9-branch/219614/report-build-info.html

you can click on the "REGRESSED" red boxes to see more details.

[Bug target/64628] New: testsuite/c-c++-common/goacc/acc_on_device-2.c:19:10: internal compiler error: Segmentation fault on ppc64

[trippels at gcc dot gnu.org]

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

Bug ID: 64628
   Summary: testsuite/c-c++-common/goacc/acc_on_device-2.c:19:10:
internal compiler error: Segmentation fault on ppc64
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Host: powerpc64-unknown-linux-gnu
Target: powerpc64-unknown-linux-gnu
 Build: powerpc64-unknown-linux-gnu

on ppc64:

trippels@gcc2-power8 testsuite % gcc -fopenacc -O
c-c++-common/goacc/acc_on_device-2.c
c-c++-common/goacc/acc_on_device-2.c: In function ‘f’:
c-c++-common/goacc/acc_on_device-2.c:19:10: internal compiler error:
Segmentation fault
   return acc_on_device (dev);
  ^
0x1080e7ab crash_signal
../../gcc/gcc/toplev.c:381
0x102cf97c expand_builtin_acc_on_device
../../gcc/gcc/builtins.c:5933
0x102f2c43 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
../../gcc/gcc/builtins.c:7087
0x10450873 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/gcc/expr.c:10488
0x10462703 expand_expr
../../gcc/gcc/expr.h:254
0x10462703 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc/gcc/expr.c:8248
0x1044f8f3 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/gcc/expr.c:10779
0x1045ef03 expand_expr
../../gcc/gcc/expr.h:254
0x1045ef03 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, tree_node*)
../../gcc/gcc/expr.c:5290
0x1046726f expand_assignment(tree_node*, tree_node*, bool)
../../gcc/gcc/expr.c:5154
0x10316ea7 expand_call_stmt
../../gcc/gcc/cfgexpand.c:2381
0x10316ea7 expand_gimple_stmt_1
../../gcc/gcc/cfgexpand.c:3327
0x10316ea7 expand_gimple_stmt
../../gcc/gcc/cfgexpand.c:3481
0x1031db17 expand_gimple_basic_block
../../gcc/gcc/cfgexpand.c:5394
0x1031ffa7 execute
../../gcc/gcc/cfgexpand.c:6003
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/61743] [5 Regression] Complete unroll is not happened for loops with short upper bound

[rguenth at gcc dot gnu.org]

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

--- Comment #18 from Richard Biener  ---
Author: rguenth
Date: Fri Jan 16 12:06:07 2015
New Revision: 219725

URL: https://gcc.gnu.org/viewcvs?rev=219725&root=gcc&view=rev
Log:
2015-01-16  Richard Biener  

PR tree-optimization/61743
* gcc.dg/tree-ssa/pr61743-1.c: Add -fno-tree-vectorize.
* gcc.dg/tree-ssa/pr61743-2.c: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr61743-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr61743-2.c

[Bug boehm-gc/64042] FAIL: boehm-gc.c/gctest.c -O2 execution test

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 CC||aph at redhat dot com,
   ||pinskia at gmail dot com

--- Comment #9 from vries at gcc dot gnu.org ---
CC-ing libobjc, java maintainer

[Bug c++/64629] New: [5 Regression] -Wformat-security warns with const char *const vars

[jakub at gcc dot gnu.org]

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

Bug ID: 64629
   Summary: [5 Regression] -Wformat-security warns with const char
*const vars
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
CC: jason at gcc dot gnu.org

extern void bar (int, const char *, ...) __attribute__((format (printf, 2,
3)));
void
foo (void)
{
  const char *const msg = "abc";
  bar (1, msg);
}

started warning with -Wformat -Wformat-security with r217814.  Was that an
intentional change for this case?
Seen on libcpp/, where the first hunk no longer works around the warning
while it used to work with gcc 4.9 and earlier.

[Bug c++/64629] [5 Regression] -Wformat-security warns with const char *const vars

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |5.0

[Bug c++/64627] Internal compiler error: Segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-01-16
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Please attach preprocessed source instead which you obtain when adding
-save-temps
to the failing compiler command-line (it will be named openvdb.ii).

Note that GCC 4.7 is no longer supported so in the event it compiles with
GCC 4.8 or newer this bug will be closed as fixed.

[Bug fortran/45290] [F08] pointer initialization

[janus at gcc dot gnu.org]

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

--- Comment #18 from janus at gcc dot gnu.org ---
Author: janus
Date: Fri Jan 16 12:49:46 2015
New Revision: 219731

URL: https://gcc.gnu.org/viewcvs?rev=219731&root=gcc&view=rev
Log:
2015-01-16  Janus Weil  

PR fortran/45290
* decl.c (match_pointer_init): Error out if resolution of init expr
failed.

2015-01-16  Janus Weil  

PR fortran/45290
* gfortran.dg/pointer_init_6.f90: Extended.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/pointer_init_6.f90

[Bug fortran/45290] [F08] pointer initialization

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #19 from janus at gcc dot gnu.org ---
The patch in comment 16 has been committed as r219731, which fixes the second
leftover problem in comment 13.

Since the first one is covered by PR 55207, I'm closing this PR.

[Bug fortran/39627] [meta-bug] Fortran 2008 support

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39627
Bug 39627 depends on bug 45290, which changed state.

Bug 45290 Summary: [F08] pointer initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45290

   What|Removed |Added

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

[Bug fortran/51076] [F2008][tracking] Pointer initialization in init expression

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51076
Bug 51076 depends on bug 45290, which changed state.

Bug 45290 Summary: [F08] pointer initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45290

   What|Removed |Added

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

[Bug target/64363] Unresolved labels with -fcheck-pointer-bounds and -mmpx

[ienkovich at gcc dot gnu.org]

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

--- Comment #2 from ienkovich at gcc dot gnu.org ---
Author: ienkovich
Date: Fri Jan 16 13:08:24 2015
New Revision: 219733

URL: https://gcc.gnu.org/viewcvs?rev=219733&root=gcc&view=rev
Log:
gcc/

PR target/64363
* ipa-chkp.h (chkp_instrumentable_p): New.
* ipa-chkp.c: Include tree-inline.h.
(chkp_instrumentable_p): New.
(chkp_maybe_create_clone): Use chkp_instrumentable_p.
Fix processing of not instrumentable functions.
(chkp_versioning): Use chkp_instrumentable_p. Warn about
not instrumentable functions.
* tree-chkp.c (chkp_add_bounds_to_call_stmt): Use
chkp_instrumentable_p.
* tree-inline.h (copy_forbidden): New.
* tree-inline.c (copy_forbidden): Not static anymore.

gcc/testsuite/

PR target/64363
* gcc.target/i386/chkp-label-address.c: New.


Added:
trunk/gcc/testsuite/gcc.target/i386/chkp-label-address.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-chkp.c
trunk/gcc/ipa-chkp.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-chkp.c
trunk/gcc/tree-inline.c
trunk/gcc/tree-inline.h

gcc-bugs@gcc.gnu.org

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||2.95.2, 3.4.6, 4.1.2

--- Comment #6 from Richard Biener  ---
Fails for all versions I tested btw, so nowhere near a regression.

[Bug target/64149] -mno-lra bitrots, suggest to remove for GCC 5

[jiwang at gcc dot gnu.org]

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

--- Comment #5 from Jiong Wang  ---
Author: jiwang
Date: Fri Jan 16 13:11:53 2015
New Revision: 219734

URL: https://gcc.gnu.org/viewcvs?rev=219734&root=gcc&view=rev
Log:
[AArch64] Remove -mlra/-mno-lra option for Aarch64

2015-01-16  Matthew Wahab  

gcc/
PR target/64149
* config/aarch64/aarch64.opt: Remove lra option and aarch64_lra_flag
variable.
* config/aarch64/aarch64.c (TARGET_LRA_P): Set to hook_bool_void_true.
(aarch64_lra_p): Remove.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/config/aarch64/aarch64.opt

[Bug target/64149] -mno-lra bitrots, suggest to remove for GCC 5

[jiwang at gcc dot gnu.org]

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

Jiong Wang  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||jiwang at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #6 from Jiong Wang  ---
mark as fixed.

[Bug target/64600] [5.0 regression] arm-rtems ICE on valid code (-mcpu=xscale)

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Target Milestone|--- |5.0
  Known to fail||5.0

[Bug target/64606] multiple warnings in arm target code

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-16
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug target/64628] testsuite/c-c++-common/goacc/acc_on_device-2.c:19:10: internal compiler error: Segmentation fault on ppc64

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
Fixed by r219735?

[Bug middle-end/64568] [5 Regression] error: invalid reference prefix

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Fri Jan 16 13:21:11 2015
New Revision: 219736

URL: https://gcc.gnu.org/viewcvs?rev=219736&root=gcc&view=rev
Log:
2015-01-16  Richard Biener  

PR tree-optimization/64568
* tree-ssa-forwprop.c (pass_forwprop::execute): Guard
complex load rewriting for TARGET_MEM_REFs.

* g++.dg/torture/pr64568-2.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr64568-2.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-forwprop.c

[Bug middle-end/64568] [5 Regression] error: invalid reference prefix

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Richard Biener  ---
Fixed.

gcc-bugs@gcc.gnu.org

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Fri Jan 16 13:26:10 2015
New Revision: 219739

URL: https://gcc.gnu.org/viewcvs?rev=219739&root=gcc&view=rev
Log:
2015-01-16  Richard Biener  

PR middle-end/64614
* tree-ssa-uninit.c: Include tree-cfg.h.
(MAX_SWITCH_CASES): New define.
(convert_control_dep_chain_into_preds): Handle switch statements.
(is_pred_expr_subset_of): Handle x == CST vs. (x & CST) != 0.
(normalize_one_pred_1): Do not split bit-manipulations.
Record (x & CST).

* gcc.dg/uninit-18.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/uninit-18.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-uninit.c

[Bug ipa/63576] [5 Regression] ICE : in ipa_merge_profiles, at ipa-utils.c:540 during Firefox LTO/PGO build

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-16
 Ever confirmed|0   |1

--- Comment #4 from Markus Trippelsdorf  ---
Happend again today. Honza can you please take a look at Ilya's patch?

https://gcc.gnu.org/ml/gcc-patches/2014-10/msg03089.html

[Bug target/64628] testsuite/c-c++-common/goacc/acc_on_device-2.c:19:10: internal compiler error: Segmentation fault on ppc64

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #2 from Markus Trippelsdorf  ---
(In reply to Uroš Bizjak from comment #1)
> Fixed by r219735?

Yes. Thanks.

[Bug target/64453] Live high register not saved in function prolog on ARM with -Os

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ramana at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |5.0

--- Comment #2 from Ramana Radhakrishnan  ---
Fixed presumably.

[Bug libgomp/64625] ___OFFLOAD_TABLE__ symbol not produced on x86_64 darwin

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
Any hope to have this fixed rapidly? Thousands of failures make testing a
nightmare.

[Bug c++/64629] [5 Regression] -Wformat-security warns with const char *const vars

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-01-16
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug tree-optimization/64434] [5 Regression] Performance regression after operand canonicalization (r216728).

[ienkovich at gcc dot gnu.org]

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

--- Comment #17 from ienkovich at gcc dot gnu.org ---
Author: ienkovich
Date: Fri Jan 16 14:22:57 2015
New Revision: 219741

URL: https://gcc.gnu.org/viewcvs?rev=219741&root=gcc&view=rev
Log:
gcc/testsuite/

PR tree-optimization/64434
* gcc.dg/torture/pr64434.c: Move to...
* gcc.dg/pr64434.c: ... here.


Added:
trunk/gcc/testsuite/gcc.dg/pr64434.c
  - copied unchanged from r219740,
trunk/gcc/testsuite/gcc.dg/torture/pr64434.c
Removed:
trunk/gcc/testsuite/gcc.dg/torture/pr64434.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug target/64516] arm: wrong unaligned load generated

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-16
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.9.0, 4.9.1, 4.9.2, 5.0

--- Comment #1 from Ramana Radhakrishnan  ---

Hmmm, I'm not sure if such type punning pushes the attributes through. We seem
to think that the alignment will be 16 bits and not 8 bits at expand time.

(insn 6 3 7 2 (set (reg:SI 115)
(zero_extend:SI (mem:HI (reg/v/f:SI 112 [ p ]) [1 MEM[(const struct TU2
*)p_2(D)]+0 S2 A16]))) /tmp/al.c:17 -1
 (nil))

[Bug target/64458] [ARM] Redundant ldr when accessing var inside and outside a loop

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-01-16
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Ramana Radhakrishnan  ---
Huh, what arch options ? 

.arm
.syntax divided
.file"ldr.c"
.text
.align2
.globalg
.typeg, %function
g:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldrr2, .L5
ldrr3, [r2]
.L2:
cmpr3, #0
bne.L2
movr3, #1
strr3, [r2]
bxlr
.L6:
.align2
.L5:
.wordglob
.sizeg, .-g
.commglob,4,4

[Bug libstdc++/55997] build of libstd3++ segfaults armv5tel.

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ramana at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #3 from Ramana Radhakrishnan  ---
There is very little here to help reproduce this issue especially as I see
others building 4.8.x based compilers on gcc-testresults even today.

I think I'm going to mark this as WONTFIX until we know more and let's reopen
this if the problem still exists.

[Bug rtl-optimization/64616] Redundant ldr when accessing var inside and outside a loop

[thopre01 at gcc dot gnu.org]

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

thopre01 at gcc dot gnu.org changed:

   What|Removed |Added

 Target||arm-none-eabi

--- Comment #1 from thopre01 at gcc dot gnu.org ---
At least with -mcpu=cortex-m3 and -mthumb. I haven't tried other combinations
yet.

[Bug target/64617] [5 Regression] ICE: Max. number of generated reload insns per insn is achieved (90) with -ftree-vectorize -mavx512bw -march=slm

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-16
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |5.0
Summary|ICE: Max. number of |[5 Regression] ICE: Max.
   |generated reload insns per  |number of generated reload
   |insn is achieved (90) with  |insns per insn is achieved
   |-ftree-vectorize -mavx512bw |(90) with -ftree-vectorize
   |-march=slm  |-mavx512bw -march=slm
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with my r218565.

[Bug target/64263] [5.0 Regression] ICE where adddi3_aarch64 does not satisfy its constraints after r217546

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Fixed with r219745.

[Bug target/64263] [5.0 Regression] ICE where adddi3_aarch64 does not satisfy its constraints after r217546

[ktkachov at gcc dot gnu.org]

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Fri Jan 16 14:50:39 2015
New Revision: 219745

URL: https://gcc.gnu.org/viewcvs?rev=219745&root=gcc&view=rev
Log:
[AArch64] Fix PR 64263: Do not try to split constants when destination is SIMD
reg

PR target/64263
* config/aarch64/aarch64.md (*movsi_aarch64): Don't split if the
destination is not a GP reg.
(*movdi_aarch64): Likewise.

* gcc.target/aarch64/pr64263_1.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/aarch64/pr64263_1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.md
trunk/gcc/testsuite/ChangeLog

[Bug target/64623] ppc64 build failure, ISA_2_7_MASKS_SERVER not declared

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-16
 Ever confirmed|0   |1

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

[Bug target/64623] ppc64 build failure, ISA_2_7_MASKS_SERVER not declared

[dje at gcc dot gnu.org]

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

--- Comment #3 from David Edelsohn  ---
I temporarily reverted the patch.  I need to explicitly include rs6000-cpus.def
in default64.h.

[Bug testsuite/64605] [5 Regression] ERROR: (DejaGnu) proc "libatomic_target_compile lto1738.c lto1738.o object additional_flags=-flto" does not exist.

[iverbin at gcc dot gnu.org]

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

iverbin at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mikestump at comcast dot net
 Resolution|--- |FIXED

--- Comment #3 from iverbin at gcc dot gnu.org ---
Fixed by r219722

[Bug fortran/61933] Inquire on internal units

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle  ---
You might notice that we redefined existence to be whether or not it is
connected.  Units get connected when opened so your sample code needs only ask:

IF ((.NOT.is_open).AND.(istat == 0)) RETURN

Whether this is what we really want to do of course is open to discussion.

The other definition for existence is .true. for all units except -1 which is
moot because -1 will give an error and the test for existence is always .true.
and not needed.  Also unit existence is processor dependent.

In your opinion, should we change it to the other definition?  Unit existence
is sort of a nebulous situation.  Will your code be more portable without the
test for existence?

[Bug c++/64630] New: error: invalid reference prefix

[dcb314 at hotmail dot com]

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

Bug ID: 64630
   Summary: error: invalid reference prefix
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com

Created attachment 34463
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34463&action=edit
gzipped C++ source code

I just tried to compile the attached C++ code with the latest trunk
dated 20150111 on a Fedora Linux x86_64 box.

The compiler said

/home/dcb/rpmbuild/BUILD/eigen-eigen-b23437e61a07/Eigen/src/Core/SolveTriangular.h:147:15:
error: invalid reference prefix
   static void run(const Lhs& lhs, Rhs& other)
   ^
MEM[base: _630, offset: 0]
cc1plus: note: in statement
# VUSE <.MEM_409>
pretmp_624 = IMAGPART_EXPR ;

Flag -O2 required.

[Bug c++/64631] New: error: ‘lgammal_r’ was not declared in this scope

[mathieu.malaterre at gmail dot com]

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

Bug ID: 64631
   Summary: error: ‘lgammal_r’ was not declared in this scope
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mathieu.malaterre at gmail dot com

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

I cannot compile the following pseudo code (see attachment) it fails with:

$ g++ -ffast-math foo.cxx
In file included from /usr/include/math.h:432:0,
 from foo.cxx:3:
/usr/include/x86_64-linux-gnu/bits/math-finite.h: In function ‘double
lgamma(double)’:
/usr/include/x86_64-linux-gnu/bits/math-finite.h:260:41: error:
‘lgamma_r’ was not declared in this scope
   return lgamma_r (__d, &__local_signgam);
 ^
/usr/include/x86_64-linux-gnu/bits/math-finite.h: In function ‘float
lgammaf(float)’:
/usr/include/x86_64-linux-gnu/bits/math-finite.h:269:42: error:
‘lgammaf_r’ was not declared in this scope
   return lgammaf_r (__d, &__local_signgam);
  ^
/usr/include/x86_64-linux-gnu/bits/math-finite.h: In function ‘long
double lgammal(long double)’:
/usr/include/x86_64-linux-gnu/bits/math-finite.h:279:42: error:
‘lgammal_r’ was not declared in this scope
   return lgammal_r (__d, &__local_signgam);
  ^
/usr/include/x86_64-linux-gnu/bits/math-finite.h: In function ‘double
gamma(double)’:
/usr/include/x86_64-linux-gnu/bits/math-finite.h:293:41: error:
‘lgamma_r’ was not declared in this scope
   return lgamma_r (__d, &__local_signgam);
 ^
/usr/include/x86_64-linux-gnu/bits/math-finite.h: In function ‘float
gammaf(float)’:
/usr/include/x86_64-linux-gnu/bits/math-finite.h:302:42: error:
‘lgammaf_r’ was not declared in this scope
   return lgammaf_r (__d, &__local_signgam);
  ^
/usr/include/x86_64-linux-gnu/bits/math-finite.h: In function ‘long
double gammal(long double)’:
/usr/include/x86_64-linux-gnu/bits/math-finite.h:312:42: error:
‘lgammal_r’ was not declared in this scope
   return lgammal_r (__d, &__local_signgam);

[Bug c++/64631] error: ‘lgammal_r’ was not declared in this scope

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
#undef __USE_MISC

This causes undefined behaviour, that macro is for the C library to define, not
for you to mess with.

[Bug tree-optimization/33651] Request warning on null pointer chk optimized after ptr deref

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-16
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug fortran/61933] Inquire on internal units

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #9 from Joost VandeVondele  
---
(In reply to Jerry DeLisle from comment #8)
> You might notice that we redefined existence to be whether or not it is
> connected.  Units get connected when opened so your sample code needs only
> ask:
> 
> IF ((.NOT.is_open).AND.(istat == 0)) RETURN
> 
> Whether this is what we really want to do of course is open to discussion.
> 
> The other definition for existence is .true. for all units except -1 which
> is moot because -1 will give an error and the test for existence is always
> .true. and not needed.  Also unit existence is processor dependent.
> 
> In your opinion, should we change it to the other definition?  Unit
> existence is sort of a nebulous situation.  Will your code be more portable
> without the test for existence?

The code in comment #7 worked on all compilers we had access to (and is part of
our released code since ages), so this change of behaviour would be a problem.

I think unless gfortran has a maximum for the allowed unit numbers, any postive
unit number should exist (i.e. can possibly be used in an open statement). 

Since:
> cat test.f90
open(UNIT=HUGE(1_16))
END
yields:
> ./a.out
At line 1 of file test.f90
Fortran runtime error: Unit number in I/O statement too large
that would be a unit that doesn't exist.

[Bug bootstrap/63771] internal compiler error: in lra_create_copy, at lra.c:1532

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ramana at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #4 from Ramana Radhakrishnan  ---
Marking as duplicate in the absence of any other information.

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

[Bug bootstrap/63740] [4.9 Regression] GCC 4.9.2 bootstrap fails on ARM, haifa-sched.c:6507:1: internal compiler error: in lra_create

[ramana at gcc dot gnu.org]

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

--- Comment #11 from Ramana Radhakrishnan  ---
*** Bug 63771 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/64601] Missed PRE on std::vector move assignment

[glisse at gcc dot gnu.org]

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

--- Comment #8 from Marc Glisse  ---
With the modified hack below, the testsuite passes, except:

gcc.dg/tree-ssa/scev-[34].c those go from xfail to pass, that sounds good
g++.dg/tree-ssa/pr31146.C seems that the scan-tree-dump is too strict
c-c++-common/ubsan/object-size-9.c for some reason it prints  instead of a bunch of 0s but I can't reproduce outside the dg
framework, doesn't seem very important.

I had to add a couple checks compared to the first version. Giving up on
volatile operands, sure, there is probably a better way but whatever. Forwprop
tends to feed artificial &MEM_REF[(void*)...] to this function in many cases
(POINTER_PLUS_EXPR in particular), which causes a number of issues (including,
surprisingly, assuming too strong alignment). Testing for ptr_type_node is a
hack, but the necessity for it is just an artifact of placing the
transformation there, it shouldn't be necessary if I put it elsewhere.

The transformation is triggered by dereferences, and compares the types of
objects, not pointers, so it isn't obvious that the issues you were describing
apply to it.

--- tree-ssa-forwprop.c(revision 219694)
+++ tree-ssa-forwprop.c(working copy)
@@ -777,20 +777,49 @@ forward_propagate_addr_expr_1 (tree name
 new_def_rhs);
   else if (is_gimple_min_invariant (new_def_rhs))
 gimple_assign_set_rhs_with_ops (use_stmt_gsi, NOP_EXPR, new_def_rhs);
   else
 return false;
   gcc_assert (gsi_stmt (*use_stmt_gsi) == use_stmt);
   update_stmt (use_stmt);
   return true;
 }

+  /* *&X -> X.  */
+  if (TREE_CODE (lhs) == MEM_REF
+  && !gimple_has_volatile_ops (use_stmt)
+  && TREE_OPERAND (lhs, 0) == name
+  && integer_zerop (TREE_OPERAND (lhs, 1))
+  && (TREE_CODE (TREE_OPERAND (def_rhs, 0)) != MEM_REF
+  || TREE_TYPE (TREE_OPERAND (TREE_OPERAND (def_rhs, 0), 1))
+ != ptr_type_node)
+  && useless_type_conversion_p (TREE_TYPE (lhs),
+TREE_TYPE (TREE_OPERAND (def_rhs, 0
+{
+  gimple_assign_set_lhs (use_stmt, unshare_expr (TREE_OPERAND (def_rhs,
0)));
+  tidy_after_forward_propagate_addr (use_stmt);
+  return true;
+}
+  else if (TREE_CODE (rhs) == MEM_REF
+  && !gimple_has_volatile_ops (use_stmt)
+  && TREE_OPERAND (rhs, 0) == name
+  && integer_zerop (TREE_OPERAND (rhs, 1))
+  && (TREE_CODE (TREE_OPERAND (def_rhs, 0)) != MEM_REF
+  || TREE_TYPE (TREE_OPERAND (TREE_OPERAND (def_rhs, 0), 1))
+ != ptr_type_node)
+  && useless_type_conversion_p (TREE_TYPE (rhs),
+TREE_TYPE (TREE_OPERAND (def_rhs, 0
+{
+  gimple_assign_set_rhs1 (use_stmt, unshare_expr (TREE_OPERAND (def_rhs,
0)));
+  tidy_after_forward_propagate_addr (use_stmt);
+  return true;
+}
   /* Now strip away any outer COMPONENT_REF/ARRAY_REF nodes from the LHS.
  ADDR_EXPR will not appear on the LHS.  */
   tree *lhsp = gimple_assign_lhs_ptr (use_stmt);
   while (handled_component_p (*lhsp))
 lhsp = &TREE_OPERAND (*lhsp, 0);
   lhs = *lhsp;

   /* Now see if the LHS node is a MEM_REF using NAME.  If so,
  propagate the ADDR_EXPR into the use of NAME and fold the result.  */
   if (TREE_CODE (lhs) == MEM_REF

[Bug libgomp/64625] ___OFFLOAD_TABLE__ symbol not produced on x86_64 darwin

[howarth at bromo dot med.uc.edu]

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

--- Comment #5 from howarth at bromo dot med.uc.edu ---
Does this imply that significant chunks of dead code exists in this merge?

[Bug middle-end/64353] [5 Regression] ICE: in execute_todo, at passes.c:1986

[ienkovich at gcc dot gnu.org]

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

--- Comment #8 from ienkovich at gcc dot gnu.org ---
Author: ienkovich
Date: Fri Jan 16 15:38:21 2015
New Revision: 219748

URL: https://gcc.gnu.org/viewcvs?rev=219748&root=gcc&view=rev
Log:
gcc/

PR middle-end/64353
* tree-cfg.c (pass_data_fixup_cfg): Update SSA for
virtuals on start.

gcc/testsuite/

PR middle-end/64353
* g++.dg/pr64353.C: New.


Added:
trunk/gcc/testsuite/g++.dg/pr64353.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-cfg.c

[Bug fortran/61933] Inquire on internal units

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #10 from Jerry DeLisle  ---
It occurs to me another possible interpretation of what a unit existence might
be.

Behind the scenes when opening a unit with no filename we create a file named
for example fort.10.  That file name is processor dependent and the user should
not know what that filename is. (we know by convention of course)

I wonder now whether we should define unit existence to be whether or not the
corresponding file (or device, or whatever it is) exists on the system. 
This starts to make some sense when you think about it and could assist a user
from inadvertently overwriting some existing data.

I am going to reopen this for further discussion.  I do agree with your issue.

[Bug rtl-optimization/60162] [4.9/5 Regression][lra] mlra appears to be using the FP registers for integer values and then moving on to GPR registers.

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

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

--- Comment #9 from Ramana Radhakrishnan  ---
Not sure what's going on here, as I'm unable to reproduce this now.

[Bug middle-end/57748] [4.8 Regression] ICE when expanding assignment to unaligned zero-sized array

[ramana at gcc dot gnu.org]

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

--- Comment #57 from Ramana Radhakrishnan  ---
(In reply to Jakub Jelinek from comment #56)
> GCC 4.8.4 has been released.

If it's too late to backport this to 4.8 we might as well close this off
targeting it for 4.9.

Ramana

[Bug c++/64630] error: invalid reference prefix

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Markus Trippelsdorf  ---
This issue was fixed today. Dup.

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

[Bug middle-end/64568] [5 Regression] error: invalid reference prefix

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #10 from Markus Trippelsdorf  ---
*** Bug 64630 has been marked as a duplicate of this bug. ***

[Bug lto/63607] run fail with -flto -mfloat-abi=softfp for armeb-linux-gnueabi-gcc

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #3 from Ramana Radhakrishnan  ---
(In reply to Fei Yang from comment #2)
> (In reply to Richard Biener from comment #1)
> > Is -mfloat-abi=softfp properly used at LTO stage?
> 
> It seems that -mfloat-abi=softfp is here for lto1:
> 
>  /home/lxr/install/bin/../lib/gcc/../../libexec/gcc/armeb-linux-gnueabi/4.7.
> 1/lto1 -quiet -dumpdir ./ -dumpbase 1.wpa -mfloat-abi=softfp -march=armv7-a
> -mtls-dialect=gnu -mfloat-abi=softfp -march=armv7-a -mtls-dialect=gnu
> -auxbase cc9cih7t -O2 -version -fltrans-output-list=/tmp/ccZqlDqA.ltrans.out
> -fwpa -fresolution=/tmp/ccUnDlh3.res @/tmp/ccSi9hcz

Can you check if it occurs with 4.8 , 4.9 or trunk today ? I don't really have
a big endian environment setup to reproduce this easily enough.

[Bug fortran/61933] Inquire on internal units

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #11 from Joost VandeVondele  
---
(In reply to Jerry DeLisle from comment #10)
> It occurs to me another possible interpretation of what a unit existence
> might be.
> 
> Behind the scenes when opening a unit with no filename we create a file
> named for example fort.10.  That file name is processor dependent and the
> user should not know what that filename is. (we know by convention of course)
>
> I wonder now whether we should define unit existence to be whether or not
> the corresponding file (or device, or whatever it is) exists on the
> system.  This starts to make some sense when you think about it and could
> assist a user from inadvertently overwriting some existing data.

I don't think this is the intended behavior. I really think the meaning rather
is, can we in principle open a file on that unit number (like from the good old
days, is a tape drive mechanically connected to it). 

I'm reading the F2008 standard, and the guidance given in 9.5.3 is not much...
However, external files and external units seem to be conceptually quite
different (see also note 9.16)

> 
> I am going to reopen this for further discussion.  I do agree with your
> issue.

thanks also for your efforts in fixing these things!

[Bug target/63250] Complex fp16 arithmetic uses nonexistent libgcc functions

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-16
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Ramana Radhakrishnan  ---
(In reply to Joseph S. Myers from comment #1)
> Author: jsm28
> Date: Tue Sep 23 00:48:46 2014
> New Revision: 215491
> 
> URL: https://gcc.gnu.org/viewcvs?rev=215491&root=gcc&view=rev
> Log:
> Remove LIBGCC2_LONG_DOUBLE_TYPE_SIZE target macro.
> 
> This patch removes the target macro LIBGCC2_LONG_DOUBLE_TYPE_SIZE.

Joseph, how does this patch go towards "fixing" this issue as it doesn't even
touch the ARM backend ?


Confirming the bug though as I do see the calls to __mulhc3 as expected even
today on trunk.

[Bug web/62211] ./configure --with-float= and ARM

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Keywords||documentation
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-16
 CC||ramana at gcc dot gnu.org
   Target Milestone|--- |5.0
 Ever confirmed|0   |1

[Bug libgomp/64625] ___OFFLOAD_TABLE__ symbol not produced on x86_64 darwin

[howarth at bromo dot med.uc.edu]

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

--- Comment #6 from howarth at bromo dot med.uc.edu ---
The code producing this problematic symbol appears to be...

/* Holds a decl for __OFFLOAD_TABLE__.  */
static GTY(()) tree offload_symbol_decl;

/* Get the __OFFLOAD_TABLE__ symbol. */
static tree
get_offload_symbol_decl (void)
{
  if (!offload_symbol_decl)
{
  tree decl = build_decl (UNKNOWN_LOCATION, VAR_DECL,
  get_identifier ("__OFFLOAD_TABLE__"),
  ptr_type_node);
  TREE_ADDRESSABLE (decl) = 1;
  TREE_PUBLIC (decl) = 1;
  DECL_EXTERNAL (decl) = 1;
  DECL_WEAK (decl) = 1;
  DECL_ATTRIBUTES (decl)
= tree_cons (get_identifier ("weak"),
 NULL_TREE, DECL_ATTRIBUTES (decl));
  offload_symbol_decl = decl;
}
  return offload_symbol_decl;
}

in mop-low.c but get_offload_symbol_decl() is used to assign offload_table in
expand_omp_target().

[Bug middle-end/57748] [4.8 Regression] ICE when expanding assignment to unaligned zero-sized array

[bernd.edlinger at hotmail dot de]

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

--- Comment #58 from Bernd Edlinger  ---
IIRC it was first fixed in 4.9.0.
The known to fail above includes 4.9.0 but that is wrong.

Do you think this is still worth to be fixed in 4.8.5 ?

[Bug libstdc++/64632] New: runtime error: member call on address 0x0000004318a8 which does not point to an object of type 'ios_base'

[trippels at gcc dot gnu.org]

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

Bug ID: 64632
   Summary: runtime error: member call on address 0x004318a8
which does not point to an object of type 'ios_base'
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org

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

markus@x4 ~ % g++ -fsanitize=undefined -O2 bench.cpp
markus@x4 ~ % ./a.out
sizearray   vector_pointvector_itersdeque  
listset multiset
/usr/lib/gcc/x86_64-pc-linux-gnu/5.0.0/include/g++-v5/bits/ios_base.h:1037:16:
runtime error: member call on address 0x004318a8 which does not point to an
object of type 'ios_base'
0x004318a0: note: object is base class subobject at offset 8 within object
of type 'std::ostream'
 00 00 00 00  a8 17 ce 25 ca 7f 00 00  d0 17 ce 25 ca 7f 00 00  06 00 00 00 00
00 00 00  00 00 00 00
  ^~~~
   vptr for '' base class of
'std::ostream'
/usr/lib/gcc/x86_64-pc-linux-gnu/5.0.0/include/g++-v5/iomanip:210:7: runtime
error: member call on address 0x004318a8 which does not point to an object
of type 'ios_base'
0x004318a0: note: object is base class subobject at offset 8 within object
of type 'std::ostream'
 00 00 00 00  a8 17 ce 25 ca 7f 00 00  d0 17 ce 25 ca 7f 00 00  06 00 00 00 00
00 00 00  00 00 00 00
  ^~~~
   vptr for '' base class of
'std::ostream'
10  0.230.230.410.77   
1.570.971.44
^C


markus@x4 ~ % clang++ -fsanitize=undefined -O2 bench.cpp
markus@x4 ~ % ./a.out
sizearray   vector_pointvector_itersdeque  
listset multiset
/usr/lib64/gcc/x86_64-pc-linux-gnu/5.0.0/include/g++-v5/bits/ios_base.h:102:24:
runtime error: load of value 4294967035, which is not a valid value for type
'std::_Ios_Fmtflags'
/usr/lib64/gcc/x86_64-pc-linux-gnu/5.0.0/include/g++-v5/bits/ios_base.h:82:67:
runtime error: load of value 4294967035, which is not a valid value for type
'std::_Ios_Fmtflags'
10  0.260.280.512.13   
3.811.262.04
^C