[Bug lto/65130] [5 Regression] ICE with LTO on valid code on x86_64-linux-gnu

[hubicka at ucw dot cz]

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

--- Comment #11 from Jan Hubicka  ---
Hi,
the bug is caused by code inlining functions called once.  Here is a dead
self recursive function that is called once (from itself) and the inliner
manages
to not punt on the rcurisve call and produce cycle.

The following patch ought to fix it.
Index: ipa-inline-analysis.c
===
--- ipa-inline-analysis.c(revision 221096)
+++ ipa-inline-analysis.c(working copy)
@@ -1291,7 +1291,8 @@ inline_summary_t::duplicate (cgraph_node
   set_hint_predicate (&info->array_index, p);
 }
 }
-  inline_update_overall_summary (dst);
+  if (!dst->global.inlined_to)
+inline_update_overall_summary (dst);
 }


@@ -3924,10 +3925,11 @@ do_estimate_growth_1 (struct cgraph_node
   continue;
 }

-  if (e->caller == d->node
-  || (e->caller->global.inlined_to
-  && e->caller->global.inlined_to == d->node))
-d->self_recursive = true;
+  if (e->recursive_p ())
+{
+  d->self_recursive = true;
+  continue;
+}
   d->growth += estimate_edge_growth (e);
 }
   return false;
Index: ipa-inline.c
===
--- ipa-inline.c(revision 221096)
+++ ipa-inline.c(working copy)
@@ -952,6 +952,8 @@ check_callers (struct cgraph_node *node,
  return true;
if (!can_inline_edge_p (e, true))
  return true;
+   if (e->recursive_p ())
+ return true;
if (!(*(bool *)has_hot_call) && e->maybe_hot_p ())
  *(bool *)has_hot_call = true;
  }
@@ -2094,6 +2096,15 @@ inline_to_all_callers (struct cgraph_nod
 {
   struct cgraph_node *caller = node->callers->caller;

+  if (!can_inline_edge_p (node->callers, true)
+  || node->callers->recursive_p ())
+{
+  if (dump_file)
+fprintf (dump_file, "Uninlinable call found; giving up.\n");
+  *num_calls = 0;
+  return false;
+}
+
   if (dump_file)
 {
   fprintf (dump_file,

[Bug target/65263] [5 Regression] ICE (error: unrecognizable insn / in insn_min_length, at config/rs6000/rs6000.md) on powerpc64le-linux-gnu

[amodra at gmail dot com]

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

--- Comment #6 from Alan Modra  ---
rev 221098 plus the patch segfaults on the testcase in
cgraph_node::function_symbol.  node->callees is NULL.

[Bug ipa/65245] [5 Regression] internal compiler error: in address_matters_p, at symtab.c:1908

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug lto/65243] [5 Regression] lto1 ICE (segfault) on powerpc64le-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-03-02
   Target Milestone|--- |5.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Can you please at least get a backtrace for us?  A somewhat reduced testcase
would also be helpful.

[Bug target/65248] [5 Regression] Copy relocation in PIE against protected symbol

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
   Priority|P3  |P1

[Bug target/65242] [5 Regression] ICE (in gen_add2_insn, at optabs.c:4761) on powerpc64le-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |5.0

[Bug tree-optimization/65241] [5 Regression] ICE (in remove_local_expressions_from_table, at tree-ssa-dom.c:1081) on powerpc64le-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
  Component|middle-end  |tree-optimization
   Target Milestone|--- |5.0

[Bug target/65240] [5 Regression] ICE (insn does not satisfy its constraints) on powerpc64le-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |5.0

[Bug ipa/65236] [5 Regression]: IPA ICF causes miscompilation in Chromium built with -Os

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.0

[Bug ipa/65237] [5 Regression] r221040 caused many regressions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |5.0

[Bug middle-end/65256] [5 regression] Undefined symbols linking f951

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||build
   Priority|P3  |P1
   Target Milestone|--- |5.0

[Bug lto/65252] Link time optimization breaks use of filenames in linker scripts

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
LTO doesn't know about linker scripts and their effects (see other related
bugreports).  For your case LTO partitioning might simply tear boot.o and
early.o
apart and put parts in differen LTRANS units.

I don't see any way to fix this but to teach WPA to parse linker scripts and
guide partitioning.

That means basically a WONTFIX with the known workaround to compile boot.o and
early.o without -flto.

Another workaround that might work is to use -flto-partition=1to1 (but the
filenames will still get wrong I think).

[Bug rtl-optimization/65247] [missed optimisation] Reading a callee-saved register writes to the stack

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization, ra
 Target||x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-02
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Well, if you want to read %rbx as it is at the point of the asm (you don't
initialize "rbx") then simply read from it without any input or input
constraint.
Or do not use an asm at tall but just 'return rbx;'?

As of why we still push/pop %rbx, no idea.  That is, confirmed with

#include 

uint64_t read_rbx(void) {
  register uint64_t rbx asm ("rbx");
  return rbx;
}

[Bug ipa/65270] [5 regression] ICF needs to match TYPE attributes on memory accesses

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-03-02
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |5.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Mine.

[Bug target/65263] [5 Regression] ICE (error: unrecognizable insn / in insn_min_length, at config/rs6000/rs6000.md) on powerpc64le-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |5.0

[Bug driver/65264] compare debug failure when using stdin

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||powerpc64*-*-*
Version|unknown |5.0

--- Comment #1 from Richard Biener  ---
Only on ppc?

[Bug target/55295] [SH] Add support for fipr instruction

[olegendo at gcc dot gnu.org]

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

--- Comment #13 from Oleg Endo  ---
(In reply to Manu Evans from comment #12)
> Hey, I'm still following this with great interest.
> 
> Is it possible to make an intrinsic for this instruction so it can be issued
> at will?

Yes, that's what I wanted to do.  Automatic detection of the fipr insn would be
restricted to relaxed FP math (e.g. -ffast-math), because it has reduced FP
precision.  So it makes sense to add a __builtin_sh_fipr.


> What I'm still more interested in at this point, would be some support for
> passing vectors in registers, making it possible to eliminate so much of
> that fmov noise.

See also PR 56592, PR 13423, PR 64305.

Unfortunately those are not so trivial to solve and I have little time at the
moment.

[Bug lto/65262] Link time optimization breaks use __attribute__((section("..."))) in templates

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
You are using a linker script for this?  That doesn't work.  LTO happily
privatizes template instantiations.

See other bug.

[Bug target/65261] [5 Regression] bootstrap-ubsan ppc64le: gcc/libcpp/lex.c:552:30: runtime error: load of misaligned address 0x01002172dfc6 for type 'const uchar', which requires 16 byte alignment

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.0

[Bug driver/65264] compare debug failure when using stdin

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Target|powerpc64*-*-*  |

--- Comment #2 from Markus Trippelsdorf  ---
(In reply to Richard Biener from comment #1)
> Only on ppc?

No, it is a general issue. Not sure how to fix it;
other than saving stdin to a tmp file in case of -fcompare-debug.

[Bug tree-optimization/65258] Wrong array bounds warning

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic,
   ||missed-optimization
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-03-02
  Component|c   |tree-optimization
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1
  Known to fail||4.8.3, 4.9.2, 5.0

--- Comment #1 from Richard Biener  ---
Early unrolling peels the a[i] = 0 loop 10 times.  VRP where we perform the
array bound warning still isn't able to prove that the last iterations are
not executed.  So we end up with

  :
  # j_12 = PHI 
  i_9 = j_12 >> 3;
  i_25 = i_9 + 4294967295;
  a[i_25] = 0;
  i_29 = i_9 + 4294967294;
  a[i_29] = 0;
  i_33 = i_9 + 4294967293;
  if (i_29 != 0)
goto ;
  else
goto ;

  :
  a[i_33] = 0;
  i_37 = i_9 + 4294967292;
  if (i_33 != 0)
goto ;
  else
goto ;

  :
  a[i_37] = 0;
  i_41 = i_9 + 4294967291;
  a[i_41] = 0;
  i_45 = i_9 + 4294967290;
  a[i_45] = 0;
...

I believe that's also partly because we have propagated the increments
to be based on the initial value and thus we don't get any additional
asserts registered after the preceeding checks for != 0.

Let me see if I can do anything about this.

[Bug tree-optimization/49234] [4.8/4.9 Regression] -Wstrict-overflow gives obviously unwarranted warning

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
  Known to work||5.0
 Resolution|FIXED   |---
Summary|[4.8/4.9/5 Regression]  |[4.8/4.9 Regression]
   |-Wstrict-overflow gives |-Wstrict-overflow gives
   |obviously unwarranted   |obviously unwarranted
   |warning |warning

--- Comment #27 from Richard Biener  ---
Only for trunk.

[Bug lto/65274] New: Internal compiler error: should die in combat

[linux at carewolf dot com]

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

Bug ID: 65274
   Summary: Internal compiler error: should die in combat
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: linux at carewolf dot com

When trying to build QtWebkit with LTO I get the internal error:
lto1: internal compiler error: in should_move_die_to_comdat, at
dwarf2out.c:6846

Note. I do not actually expect an LTO debug build of QtWebKit to succede, since
a normal debug linking step consumes 5-10Gbyte a of memory and an optimizing
link would likely consume a lot more, but I expect it to run normally and get
killed in action by the OOM killer.

Not sure I can post any meaningful intermediates here, the whole thing is
rather insane in scope. If there is anything more useful I can post please tell
me.

[Bug tree-optimization/65241] [5 Regression] ICE (in remove_local_expressions_from_table, at tree-ssa-dom.c:1081)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Target|powerpc64le-linux-gnu   |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-02
 CC||mpolacek at gcc dot gnu.org
Summary|[5 Regression] ICE (in  |[5 Regression] ICE (in
   |remove_local_expressions_fr |remove_local_expressions_fr
   |om_table, at|om_table, at
   |tree-ssa-dom.c:1081) on |tree-ssa-dom.c:1081)
   |powerpc64le-linux-gnu   |
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Doesn't seem to be target dependent, reproduced even on x86_64-linux.  Started
with r217827.

[Bug lto/65262] Link time optimization breaks use __attribute__((section("..."))) in templates

[goswin-v-b at web dot de]

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

--- Comment #2 from Goswin von Brederlow  ---
The linker script is only there because the default script combines all .text.*
into one hiding the effect. One could use different section names that the
default script does not combine and work without a custom linker script.

LTO is free to privatizes template instantiations. But if it doesn't inline the
template then it should preserve the section attribute on it like it does for
normal functions. All optimized clones of a normal functions are still in the
same section the original function was in.

I could understand if a template would end up in the section of the function
causing the instantiation (although what if functions from different sections
use the same instance?). But templates simply end up in the .text section no
matter what they where originally or where they get instantiated. I don't know
the internals but it looks to me like something should copy the section
attribute from the template to the privatized function in LTO mode.

You can't set a section on the template, you can't use a file scope in the
linker, you can't even use __attribute__((always_inline)) and the behaviour
differs from without -flto. How is that a WONTFIX?

[Bug tree-optimization/65241] [5 Regression] ICE (in remove_local_expressions_from_table, at tree-ssa-dom.c:1081)

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Better test case:

enum E { A, B, C, D };
void fn4 (void);

int
fn1 (enum E p1)
{
  static int w[D];
  if (w[p1])
switch (p1)
  case C:
  w[p1] = 0;
}

void
fn2 (p1)
{
  fn1 (p1);
}

void
fn3 (enum E p1)
{
  fn2 (p1);
  fn4 ();
  fn2 (p1);
}

[Bug target/61578] [4.9/5 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[fredrik.hederstie...@securitas-direct.com]

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

--- Comment #14 from Fredrik Hederstierna 
 ---
Created attachment 34916
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34916&action=edit
CSiBE benchmark with gnu89, updates with newer trunk as reference.

I added attachment with new CSiBE measurement from newer trunk,
and now using -std=gnu89 for correctness.

It looks alot better on current trunk, the code size is now smaller than 4.8.x,
so in this case this issue seems at least partly resolved.

Though, still the proposed patch with "-mip-fixed" on trunk,
still gets approx  -0.2%  reduced code size in average,
which might seem significant. See attached docs.

The CSiBE test also it indicates that LRA might improved specific areas,
where the code size gets worse with IP fixed, which could be investigated
further. Example file are libmspack/test/cabd_md5.c.

So, I'm just wondering if you that are or have been involved with this issue,
thinks the proposed patch is a good idea and worth putting time to make it
proper for commit? I just do not want to put time and effort in this patch if
its not likely to get in, or you think its a bad idea.

Please comment :)  Thanks and Kind Regards Fredrik

[Bug ipa/61916] Internal compiler error in symtab_nonoverwritable_alias with -O2

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

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

--- Comment #8 from Kai Tietz  ---
Already fixed. A dup of 64212

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

[Bug target/64212] [4.9/5 Regression] ICE [in noninterposable_alias, at symtab.c:1706]

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 CC||timothygu99 at gmail dot com

--- Comment #11 from Kai Tietz  ---
*** Bug 61916 has been marked as a duplicate of this bug. ***

[Bug target/65183] ICE: verify_ssa failed: virtual use of statement not up-to-date with -fcheck-pointer-bounds -fchkp-use-nochk-string-functions -mmpx

[ienkovich at gcc dot gnu.org]

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

--- Comment #1 from ienkovich at gcc dot gnu.org ---
Author: ienkovich
Date: Mon Mar  2 10:41:09 2015
New Revision: 221105

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

PR target/65183
* tree-chkp.c (chkp_check_lower): Don't check against
zero bounds for already instrumented functions.
(chkp_check_upper): Likewise.
(chkp_fini): Clean pass local data to avoid wrong reusage.

gcc/testsuite/

PR target/65183
* gcc.target/i386/pr65183.c: New.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr65183.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-chkp.c

[Bug target/65184] ICE: in expand_expr_addr_expr_1, at expr.c:7760 with -mabi=ms -fcheck-pointer-bounds -mmpx

[ienkovich at gcc dot gnu.org]

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

--- Comment #1 from ienkovich at gcc dot gnu.org ---
Author: ienkovich
Date: Mon Mar  2 10:47:54 2015
New Revision: 221106

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

PR target/65184
* gcc/config/i386/i386.c (ix86_pass_by_reference) Bounds
are never passed by reference.

gcc/testsuite/

PR target/65184
* gcc.target/i386/pr65184.c: New.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr65184.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/65235] Simplifying vec_select of vec_concat miscompiles when first element of vec_concat is const_int

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 Target|aarch64 |aarch64*-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-02
 CC||jgreenhalgh at gcc dot gnu.org
   Host||*-*-*
 Ever confirmed|0   |1

--- Comment #7 from James Greenhalgh  ---
The tescase from comment 5 fails for me at -O3 on an aarch64-none-elf cross
compiler (r221086), this also fails for native aarch64-none-linux-gnu.

As with Kyrill, I see:

(insn 16 15 17 2 (set (reg:V2DI 80 [ D.2809 ])
(vec_concat:V2DI (reg:DI 95 [ D.2812 ])
(reg:DI 77 [ D.2806 ]))) reduced.c:19 1386
{aarch64_combine_internaldi}
 (expr_list:REG_DEAD (reg:DI 95 [ D.2812 ])
(expr_list:REG_DEAD (reg:DI 77 [ D.2806 ])
(expr_list:REG_EQUAL (vec_concat:V2DI (reg:DI 95 [ D.2812 ])
(const_int 4503599627370498 [0x12]))
(nil)

(insn 17 16 18 2 (set (reg:DI 96 [ D.2806 ])
(vec_select:DI (reg:V2DI 80 [ D.2809 ])
(parallel [
(const_int 0 [0])
]))) reduced.c:14 1372 {aarch64_get_lanev2di}
 (expr_list:REG_DEAD (reg:V2DI 80 [ D.2809 ])
(nil)))

Combine:

Trying 16 -> 17:
Successfully matched this instruction:
(set (reg:DI 96 [ D.2806 ])
(reg:DI 77 [ D.2806 ]))
---

Which is bogus, the correct rewrite would be to:

(set (reg:DI 96 [ D.2806 ])
(reg:DI 95 [ D.2812 ]))

[Bug lto/65130] [5 Regression] ICE with LTO on valid code on x86_64-linux-gnu

[ktietz at gcc dot gnu.org]

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

--- Comment #12 from Kai Tietz  ---
I confirm that bug is fixed with that patch.  Only for the case that trying to
link with objects created with prior revision will still fail.  Later might be
acceptable.

[Bug lto/63546] ICE: Segmentation fault in lto_get_decl_name_mapping on ppc64

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #10 from Markus Trippelsdorf  ---
Seems to be fixed. Closing.

[Bug c/65275] New: Disappearing -Wsequence-point warning

[chronokitsune3233 at gmail dot com]

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

Bug ID: 65275
   Summary: Disappearing -Wsequence-point warning
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chronokitsune3233 at gmail dot com

An unusual declaration of an array with variable size does not always elicit a
warning diagnostic on Windows 7 64-bit with a mingw-w64 target
(x86_64-w64-mingw32).  My own gcc 4.9.1 and TDM-GCC 4.8.2 both exhibit the
problem.

> type foo.i
# 1 "foo.c"
# 1 ""
# 1 ""
# 1 "foo.c"
int printf (const char *, ...);
int main (void) {
  int n = 2;
  int a[(++n, 7)];
  printf ("%d %d\n", n, (int) (sizeof a / sizeof a[0]));
}

> gcc -std=c99 -Wall foo.c
foo.c: In function 'main':
foo.c:4:10: warning: operation on 'n' may be undefined [-Wsequence-point]
   int a[(++n, 7)];

Curiously, it's not the 'sizeof' division or 'n' by themselves.  A slightly
altered copy of the file has the following in the body of 'main', and there are
no warnings with the same command line:

  int n = 2;
  int a[(++n, 7)];
  printf("%d ", n);
  printf("%d\n", (int) (sizeof a / sizeof a[0]));

And I can assign the result of the 'sizeof' division to a variable as well to
make the warning disappear:

  int n = 2;
  int a[(++n, 7)];
  int len = (int) (sizeof a / sizeof a[0]);
  printf ("%d %d\n", n, len);

I've reduced the file to avoid using #include , but I received the
exact same results even when using the system header instead of the 'printf'
prototype shown on the first line, so I've ruled out that possibility.

I'm not certain whether this is undefined behavior or not, but even if it is,
why does the warning disappear, depending on the code used?

[Bug target/65240] [5 Regression] ICE (insn does not satisfy its constraints) on powerpc64le-linux-gnu

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
I can't reproduce.

[Bug c++/65271] Declarator after class-specifier cannot declare rvalue reference

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-02
 Ever confirmed|0   |1

[Bug target/65240] [5 Regression] ICE (insn does not satisfy its constraints) on powerpc64le-linux-gnu

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #2 from Markus Trippelsdorf  ---
(In reply to Marek Polacek from comment #1)
> I can't reproduce.

Neither can I.

[Bug ipa/65270] [5 regression] ICF needs to match TYPE attributes on memory accesses

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
In theory comparing the object alignment with sth like

  unsigned int align1, align2;
  unsigned HOST_WIDE_INT tem;
  get_object_alignment_1 (t1, &align1, &tem);
  get_object_alignment_1 (t2, &align2, &tem);
  if (align1 != align2)
return return_false_with_msg ("different access alignment");

should work, but in this case with variable offset we don't represent
"unknown misalign offset" and thus fail to see the difference here.
Thus we have to compare alignment of the base object here (but then
not that from ao_ref_base because that's too aggressive in stripping
MEM_REFs).

I have a patch.

[Bug lto/65243] [5 Regression] lto1 ICE (segfault) on powerpc64le-linux-gnu

[doko at gcc dot gnu.org]

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

Matthias Klose  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

--- Comment #2 from Matthias Klose  ---
export COLLECT_GCC=/usr/bin/powerpc64le-linux-gnu-g++
export COLLECT_GCC_OPTIONS="'-c' '-fexceptions' '-fmath-errno' '-fsigned-zeros'
'-ftrapping-math' '-fno-trapv' '-fno-openmp' '-fno-openacc' '-msecure-plt'
'-mtune=power8' '-mcpu=power7' '-O3' '-O2' '-O3' '-v' '-save-temps' '-g' '-O3'
'-fstack-protector-strong' '-Werror=format-security' '-D' '_FORTIFY_SOURCE=2'
'-fPIE' '-pie' '-shared-libgcc' '-mtune=power8' '-mcpu=power7' '-dumpdir' './'
'-dumpbase' 'apt-cacher-ng.ltrans17' '-fltrans' '-o'
'apt-cacher-ng.ltrans17.ltrans.o' '-shared-libgcc'"
gdb --args  /usr/lib/gcc/powerpc64le-linux-gnu/5/lto1 -quiet -dumpdir ./
-dumpbase apt-cacher-ng.ltrans17 -msecure-plt -mtune=power8 -mcpu=power7
-mtune=power8 -mcpu=power7 -auxbase-strip apt-cacher-ng.ltrans17.ltrans.o -g
-O3 -O2 -O3 -O3 -Werror=format-security -version -fexceptions -fmath-errno
-fsigned-zeros -ftrapping-math -fno-trapv -fno-openmp -fno-openacc
-fstack-protector-strong -fPIE -fltrans apt-cacher-ng.ltrans17.o -o
apt-cacher-ng.ltrans17.s

Program received signal SIGSEGV, Segmentation fault.
0x10c53690 in htab_hash_string ()
(gdb) bt
#0  0x10c53690 in htab_hash_string ()
#1  0x1026a1d8 in lookup_external_ref(hash_table*, die_struct*) ()
#2  0x1026a2d8 in optimize_external_refs_1(die_struct*,
hash_table*) ()
#3  0x1026a894 in optimize_external_refs(die_struct*) ()
#4  0x1026abf4 in output_comp_unit(die_struct*, int) ()
#5  0x1028d5cc in dwarf2out_finish(char const*) ()
#6  0x105ca938 in compile_file() ()
#7  0x10141374 in toplev::main(int, char**) ()
#8  0x10141d78 in main ()

[Bug lto/65243] [5 Regression] lto1 ICE (segfault) on powerpc64le-linux-gnu

[doko at gcc dot gnu.org]

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

--- Comment #3 from Matthias Klose  ---
Created attachment 34917
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34917&action=edit
object file

[Bug c/65275] Disappearing -Wsequence-point warning

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

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

--- Comment #1 from Marc Glisse  ---
Something to do with save_expr I guess (it also explains why the warning is on
the wrong line).

[Bug target/65240] [5 Regression] ICE (insn does not satisfy its constraints) on powerpc64le-linux-gnu

[doko at gcc dot gnu.org]

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

Matthias Klose  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|WORKSFORME  |---

--- Comment #3 from Matthias Klose  ---
another occurrence:

$ gcc -std=gnu99 -c -g -O3 -ffast-math filters.i 
filters.c: In function 'flam3_create_spatial_filter':
filters.c:270:1: error: insn does not satisfy its constraints:
 }
 ^
(insn 388 2863 2731 10 (set (reg:DF 104 27 [1124])
(mem/u/c:DF (lo_sum:DI (reg:DI 24 24)
(unspec:DI [
(symbol_ref/u:DI ("*.LC23") [flags 0x82])
(reg:DI 2 2)
] UNSPEC_TOCREL)) [1  S8 A64])) filters.c:251 499
{*movdf_hardfloat64}
 (expr_list:REG_EQUIV (const_double:DF -1.0e+0 [-0x0.8p+1])
(nil)))
filters.c:270:1: internal compiler error: in extract_constrain_insn, at
recog.c:2246
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug target/65240] [5 Regression] ICE (insn does not satisfy its constraints) on powerpc64le-linux-gnu

[doko at gcc dot gnu.org]

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

--- Comment #4 from Matthias Klose  ---
Created attachment 34918
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34918&action=edit
preprocessed source

[Bug target/65240] [5 Regression] ICE (insn does not satisfy its constraints) on powerpc64le-linux-gnu

[doko at gcc dot gnu.org]

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

--- Comment #5 from Matthias Klose  ---
reduced test case for filters.i:

double a, b, d, e;
c, f, g;
double fn1() {
  double t;
  if (t < 0.0)
t = -t;
  if (t < 1.0)
return 1.0 - t;
  t = -t;
  if (t < .5)
return t * t;
}

double fn2(double p1) {
  if (p1 < 1)
b = p1 * p1 / 3.0;
  if (p1)
return 6.0 * p1 * p1;
}

double fn3(double p1) {
  if (c == 0)
fn4();
  else if (c == 2)
return fn1();
  else if (c == 5)
return fn2(p1);
  else if (c == 3) {
d = p1 * p1;
return d;
  }
}

fn5() {
  double h, j;
  int k = f, i;
  h = a;
  i = 0;
  for (; i < k; i++) {
g = 0;
for (; g < k;) {
  e = ((i + 1.0) / k - 1.0) * h;
  j = (2.0 * g - 1.0) * fn3(e) * fn3(j);
}
  }
}

[Bug target/65240] [5 Regression] ICE (insn does not satisfy its constraints) on powerpc64le-linux-gnu

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #6 from Markus Trippelsdorf  ---
Attached unreduced testcase ICEs for me. Reduced testcase from comment 5
doesn't.

trippels@gcc2-power8 ~ % cat filters.i
int b, d, e;
double c;
double *f;
int
fn1(double p1) {
  if (p1 && p1 <= 1)
return 1;
  return 0;
}
double fn2(double p1) {
  if (p1 < 0)
p1 = -p1;
  if (p1 < 1)
return -p1 - 1;
  if (p1 < .5)
return .75 - p1 * p1;
}
double fn3(double p1) {
  int a;
  if (p1 < 0)
return a * p1 + 3.0;
  if (p1 < 2)
return 1 / 6.0 * p1 * p1 * p1;
}
double fn4(double p1) {
  if (b == 0)
fn5(p1);
  else if (b == 1)
return fn1(p1);
  else if (b == 3)
return fn2(p1);
  else if (b == 5)
return fn3(p1);
}
void
fn6() {
  double g, h;
  int j = e, i;
  g = e;
  for (; j; i++) {
d = 0;
for (; d < 1; d++) {
  c = (i + 1.0) / 0.1 - 1;
  h = ((2.0 * d + 1) / j - 1) * g;
  *f = fn4(c) * fn4(h);
}
  }
}

trippels@gcc2-power8 ~ % ~/gcc_test/usr/local/bin/gcc -w -std=gnu99 -c -O3
-ffast-math filters.i
filters.i: In function ‘fn6’:
filters.i:48:1: error: insn does not satisfy its constraints:
 }
 ^
(insn 86 598 599 3 (set (reg:DF 98 21 [345])
(mem/u/c:DF (lo_sum:DI (reg:DI 8 8)
(unspec:DI [
(symbol_ref/u:DI ("*.LC8") [flags 0x82])
(reg:DI 2 2)
] UNSPEC_TOCREL)) [2  S8 A64])) filters.i:44 499
{*movdf_hardfloat64}
 (expr_list:REG_EQUIV (const_double:DF -1.0e+0 [-0x0.8p+1])
(nil)))
filters.i:48:1: internal compiler error: in extract_constrain_insn, at
recog.c:2246
0x1075f653 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:110
0x1075f6b7 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:121
0x107264fb extract_constrain_insn(rtx_insn*)
../../gcc/gcc/recog.c:2246
0x106ff137 reload_cse_simplify_operands
../../gcc/gcc/postreload.c:430
0x10700723 reload_cse_simplify
../../gcc/gcc/postreload.c:207
0x10700723 reload_cse_regs_1
../../gcc/gcc/postreload.c:246
0x107009e7 reload_cse_regs
../../gcc/gcc/postreload.c:94
0x107009e7 execute
../../gcc/gcc/postreload.c:2367
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug lto/65276] New: [5 Regression] LTO: ICE add_type_duplicate, at ipa-devirt.c:1462

[burnus at gcc dot gnu.org]

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

Bug ID: 65276
   Summary: [5 Regression] LTO: ICE add_type_duplicate, at
ipa-devirt.c:1462
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org

Created attachment 34919
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34919&action=edit
File "one.ii" - compile with -O0 (g++ -w -c -flto -O0 -std=c++11 one.ii)

Seems to be introduced in the last few days (max. 2 weeks) as it compiled
before.

The attached program fails with:
lto1: internal compiler error: in add_type_duplicate, at ipa-devirt.c:1462

Compile with:
  g++ -w -c -flto -O0 -std=c++11 one.ii
  g++ -w -c -flto -O2 -std=c++11 two.ii
  gcc -r -nostdlib -O0 -Wodr -flto-odr-type-merging one.o two.o

[Bug tree-optimization/65258] Wrong array bounds warning

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
There are of course two issues here - one VRP not optimizing away the dead code
and unrolling creating the dead code in the first place (thus number of
iteration
analysis being not very precise).

Number of iteration analysis has a hard time exercising SCEV here as that
cannot
handle division (generally such IVs are not affine, in this case the evolution
of j/8 is not affine in the j loop).

Now for the VRP issue it is forwprop that replaces the sequence of i-- with
i = j/8 - 1, i = j/8 - 2, ... thereby making VRPs life hard with

  :
  i_9 = j_3 / 8;
  i_26 = i_9 + 4294967295;
  if (i_9 != 0)
goto ;
  else
goto ;

  :
  a[i_26] = 0;
  i_30 = i_9 + 4294967294;
  if (i_26 != 0)
goto ;
  else
goto ;

  :
  a[i_30] = 0;
  i_34 = i_9 + 4294967293;
  if (i_30 != 0)
goto ;
  else
goto ;

where the assertion on i_26 != 0 doesn't help it improving the range
for i_34 (which is based on i_9 again).

Disabling forwprop2 fixes the warning and makes VRP1 do its job.  It is
match.pd:491 that does the transform.

Of course I can write the problematic code in plain C as well so VRP should
better deal with it somehow.

We can "easily" do

  i_38 = i_53 + 4294967292;
  if (i_34 != 0)
goto ;
  else
goto ;

  :
  i_56 = ASSERT_EXPR ;
  a[i_38] = 0;
  i_42 = i_56 + 4294967291;
  if (i_38 != 0)
goto ;
  else 
goto ;

  : 
  i_57 = ASSERT_EXPR ;
  a[i_42] = 0;

but then we'd still need an assert for i_42 as well which is quite backward.

In fact the way VRP works makes this quite hard to do.  For a "real"
sophisticated VRP we'd walk the full dominator tree dominating each
predicate to compute value-ranges for SSA names dominated by those predicates
(but that's quadratic).

That said - with the above we are down to a single warning (but the code is
not removed).  We are not able to simplify the last branch to false and
the branch after gets UNDEFINED into the comparison so we can fold either
way (we could put builtin_unreachable before that branch...).

So - not sure if improving to

t.c: In function 'main':
t.c:8:3: warning: array subscript is above array bounds [-Warray-bounds]
  a[i] = 0;
   ^

is worth it.

[Bug lto/65276] [5 Regression] LTO: ICE add_type_duplicate, at ipa-devirt.c:1462

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  ---
Created attachment 34920
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34920&action=edit
File "two.ii" - compile with -O2 (g++ -w -c -flto -O2 -std=c++11 two.ii)

[Bug tree-optimization/65258] Wrong array bounds warning

[rguenth at gcc dot gnu.org]

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

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

Patch to add additional asserts and to better handle UNDEFINED in propagation.

[Bug target/65263] [5 Regression] ICE (error: unrecognizable insn / in insn_min_length, at config/rs6000/rs6000.md) on powerpc64le-linux-gnu

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #7 from Martin Liška  ---
Created attachment 34922
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34922&action=edit
Suggested patch

There's fixed version of the patch:

1) If I see correctly, there was error in: struct cgraph_edge *nexte =
e->next_callee
2) We should not remove alias if there's a thunk that wasn't redirected
3) gcc_assert must be changed for these cases

Patch can run the testcase and survives FF with -O3 and -flto. Regression tests
have been running.

Martin

[Bug ipa/65006] [5 Regression] 252.eon in SPEC CPU 2000 miscompiled with LTO

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #14 from H.J. Lu  ---
Fixed as of r221077.

[Bug lto/65276] [5 Regression] LTO: ICE add_type_duplicate, at ipa-devirt.c:1462

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |5.0

[Bug c++/65277] New: ice in get_untransformed_body with -O2

[dcb314 at hotmail dot com]

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

Bug ID: 65277
   Summary: ice in get_untransformed_body with -O2
   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

The gcc/testsuite case g++.dg/inherit/covariant18.C,
when compiled by trunk dated 20150301 with -O2, does this:

bug188.cc:41:1: internal compiler error: in get_untransformed_body, at
cgraph.c:
3113
 }
 ^
0x8faead cgraph_node::get_untransformed_body()
../../src/trunk/gcc/cgraph.c:3113
0x90560f cgraph_node::expand()
../../src/trunk/gcc/cgraphunit.c:1850
0x906e58 expand_all_functions
../../src/trunk/gcc/cgraphunit.c:2014
0x906e58 symbol_table::compile()
../../src/trunk/gcc/cgraphunit.c:2367
0x908977 symbol_table::finalize_compilation_unit()
../../src/trunk/gcc/cgraphunit.c:2444
0x6d901c cp_write_global_declarations()
../../src/trunk/gcc/cp/decl2.c:4754

[Bug c++/65277] [5 Regression] ice in get_untransformed_body with -O2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |5.0
Summary|ice in  |[5 Regression] ice in
   |get_untransformed_body with |get_untransformed_body with
   |-O2 |-O2

[Bug testsuite/63175] [4.9/5 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2" basic block vectorized using SLP" 1

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener  ---
Btw, first of all unaligned stores are not supported according to the targets
vectorization hook, thus you'd need to peel the loop to make the store aligned
which for some reason doesn't happen.  But when peeled you certainly will see
byte/short/word stores at least.

[Bug ipa/65270] [5 regression] ICF needs to match TYPE attributes on memory accesses

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Mon Mar  2 14:31:46 2015
New Revision: 221117

URL: https://gcc.gnu.org/viewcvs?rev=221117&root=gcc&view=rev
Log:
2015-03-02  Richard Biener  

PR ipa/65270
* ipa-icf-gimple.c: Include builtins.h.
(func_checker::compare_memory_operand): Compare base alignment.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-icf-gimple.c

[Bug debug/53927] wrong value for DW_AT_static_link

[derodat at adacore dot com]

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

--- Comment #15 from Pierre-Marie de Rodat  ---
(In reply to Pierre-Marie de Rodat from comment #13)
> [1] This patch teaches GDB how to use DW_AT_static_link in order to find the
> frame corresponding to the lexically enclosing scope. I think I will try to
> submit it to GDB soon.

For the record, here it is:
.

[Bug testsuite/63175] [4.9/5 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2" basic block vectorized using SLP" 1

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Biener  ---
(In reply to Richard Biener from comment #15)
> Btw, first of all unaligned stores are not supported according to the targets
> vectorization hook, thus you'd need to peel the loop to make the store
> aligned
> which for some reason doesn't happen.

Quite obvious - the loop iterates 8 times but the vectorization factor is 8
as well, so if we peel off a iteration to align the destination the vectorized
loop will never enter.

Why is the loop bound to i != 16 / sizeof *s?

>  But when peeled you certainly will see
> byte/short/word stores at least.

Like when I increase the iteration count I get for copy_short_0_1:

.L.copy_Type_0_1:
addis 6,2,.LANCHOR0@toc@ha
addis 7,2,.LANCHOR1@toc@ha
addi 6,6,.LANCHOR0@toc@l
addi 7,7,.LANCHOR1@toc@l
li 8,7
addi 9,6,2
mr 10,7
mtctr 8
.p2align 4,,15
.L2:
addi 10,10,2
lhz 8,-2(10)
addi 9,9,2
sth 8,-2(9)
bdnz .L2
addi 8,7,14
addi 7,7,29
neg 5,8
lvx 1,0,8
lvx 0,0,7
li 7,16
lvsr 13,0,5
addi 8,10,14
addi 9,9,14
addi 10,10,16
vperm 0,1,0,13
stvx 0,6,7
.p2align 4,,15
.L3:
lhzu 7,2(8)
cmpld 7,10,8
sthu 7,2(9)
bne+ 7,.L3
blr

the cost model should probably reject this, but it does not:

t.c:36:1: note: Cost model analysis:
  Vector inside of loop cost: 3
  Vector prologue cost: 17
  Vector epilogue cost: 2
  Scalar iteration cost: 2
  Scalar outside cost: 0
  Vector outside cost: 19
  prologue iterations: 7
  epilogue iterations: 1
  Calculated minimum iters for profitability: 10

[Bug c++/65277] [5 Regression] ice in get_untransformed_body with -O2

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-02
 CC||ktietz at gcc dot gnu.org,
   ||maxim at trivialbugs dot com
 Ever confirmed|0   |1

--- Comment #1 from Kai Tietz  ---
Issue seems to be happend in expand_all_functions.  In prior versions we called
expand_function, but now we are calling directly expand ().  Expand () itself
makes use of function get_untransformed_body, which checks for in-LTO-mode,
which of course fails.
Anyway the most funny thing here is that this change is not mentioned in any
ChangeLog.  It is caused by r214422

[Bug ipa/65270] [5 regression] ICF needs to match TYPE attributes on memory accesses

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug debug/53927] wrong value for DW_AT_static_link

[tromey at gcc dot gnu.org]

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

--- Comment #16 from Tom Tromey  ---
(In reply to Pierre-Marie de Rodat from comment #15)
> (In reply to Pierre-Marie de Rodat from comment #13)
> > [1] This patch teaches GDB how to use DW_AT_static_link in order to find the
> > frame corresponding to the lexically enclosing scope. I think I will try to
> > submit it to GDB soon.
> 
> For the record, here it is:
> .

I'm curious if you tried it on the test case in this PR.


In the patch you wrote:

> Since I'm not sure of how this issue should be solved, I'm nevertheless 
> posting this patch here so this matter can be discussed. In the context of 
> this feature, I think we need a backlink from all symbols to the 
> corresponding embedding block but on the other hand only a few blocks have 
> static link: maybe we could turn this static_link field into a objfile-based 
> hashtable lookup. Thoughts? 


Yeah, growing these is to be avoided.
My patch for this added a method to symbol_computed_ops instead.

Unfortunately gitorious is acting weird so you can't see the patch
online :-(.  But you can fetch from https://gitorious.org/binutils-gdb/gdb.git
and look at the branch static-link-fix if you like.

[Bug c++/65277] [5 Regression] ice in get_untransformed_body with -O2

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
221040(In reply to Kai Tietz from comment #1)
> It is caused by r214422

No, I think this started with r221040.

[Bug target/65278] New: [5 Regression] ICE (in output_718, at config/rs6000/rs6000.md:11592) on powerpc-linux-gnu

[doko at gcc dot gnu.org]

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

Bug ID: 65278
   Summary: [5 Regression] ICE (in output_718, at
config/rs6000/rs6000.md:11592) on powerpc-linux-gnu
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org

r221115 on powerpc-linux-gnu

$ g++ -c -g -O2 -fPIC DistanceEstimation.ii 
DistanceEstimation.ii: In member function 'virtual double
B::_ZTv0_n12_NK1B5m_fn1ERKiS1_(const int&, const int&) const':
DistanceEstimation.ii:14:42: internal compiler error: in output_718, at
config/rs6000/rs6000.md:11592
 TwoTreeLikelihood::~TwoTreeLikelihood() {}
  ^
Please submit a full bug report,
with preprocessed source if appropriate.

$ cat DistanceEstimation.ii 
class A {
  virtual double m_fn1(const int &, const int &) const;
  int d2f_variable1;
  int d2f_variable2;
  virtual double m_fn2() { m_fn1(d2f_variable1, d2f_variable2); }
};
class B : virtual A {
  double m_fn1(const int &, const int &) const { return 0; }
};
class TwoTreeLikelihood : A {
  ~TwoTreeLikelihood();
  double m_fn1(const int &, const int &) const { return 0; }
};
TwoTreeLikelihood::~TwoTreeLikelihood() {}

[Bug target/65278] [5 Regression] ICE (in output_718, at config/rs6000/rs6000.md:11592) on powerpc-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.0

[Bug libstdc++/65279] New: [4.8/4.9/5 Regression] std::scoped_allocator_adaptor is not assignable

[redi at gcc dot gnu.org]

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

Bug ID: 65279
   Summary: [4.8/4.9/5 Regression] std::scoped_allocator_adaptor
is not assignable
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org

#include 
#include 
#include 

int main()
{
  std::vector>> v, w;
  w = std::move(v);
}

This compiles OK (using -std=c++11) with 4.7 but not 4.8 or later:

In file included from
/home/jwakely/gcc/4.8.0/include/c++/4.8.0/ext/alloc_traits.h:36:0,
 from
/home/jwakely/gcc/4.8.0/include/c++/4.8.0/bits/stl_construct.h:61,
 from /home/jwakely/gcc/4.8.0/include/c++/4.8.0/memory:64,
 from saa.cc:1:
/home/jwakely/gcc/4.8.0/include/c++/4.8.0/bits/alloc_traits.h: In instantiation
of ‘void std::__do_alloc_on_move(_Alloc&, _Alloc&, std::true_type) [with _Alloc
= std::scoped_allocator_adaptor >; std::true_type =
std::integral_constant]’:
/home/jwakely/gcc/4.8.0/include/c++/4.8.0/bits/alloc_traits.h:490:49:  
required from ‘void std::__alloc_on_move(_Alloc&, _Alloc&) [with _Alloc =
std::scoped_allocator_adaptor >]’
/home/jwakely/gcc/4.8.0/include/c++/4.8.0/bits/stl_vector.h:1364:36:   required
from ‘void std::vector<_Tp, _Alloc>::_M_move_assign(std::vector<_Tp, _Alloc>&&,
std::true_type) [with _Tp = int; _Alloc =
std::scoped_allocator_adaptor >; std::true_type =
std::integral_constant]’
/home/jwakely/gcc/4.8.0/include/c++/4.8.0/bits/stl_vector.h:445:65:   required
from ‘std::vector<_Tp, _Alloc>& std::vector<_Tp,
_Alloc>::operator=(std::vector<_Tp, _Alloc>&&) [with _Tp = int; _Alloc =
std::scoped_allocator_adaptor >]’
saa.cc:8:5:   required from here
/home/jwakely/gcc/4.8.0/include/c++/4.8.0/bits/alloc_traits.h:479:13: error:
use of deleted function ‘std::scoped_allocator_adaptor >&
std::scoped_allocator_adaptor >::operator=(const
std::scoped_allocator_adaptor >&)’
 { __one = std::move(__two); }
 ^
In file included from saa.cc:2:0:
/home/jwakely/gcc/4.8.0/include/c++/4.8.0/scoped_allocator:176:11: note:
‘std::scoped_allocator_adaptor >&
std::scoped_allocator_adaptor >::operator=(const
std::scoped_allocator_adaptor >&)’ is implicitly declared
as deleted because ‘std::scoped_allocator_adaptor >’
declares a move constructor or move assignment operator
 class scoped_allocator_adaptor
   ^

[Bug libstdc++/65279] [4.8/4.9/5 Regression] std::scoped_allocator_adaptor is not assignable

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-03-02
  Known to work||4.7.4
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |4.8.5
 Ever confirmed|0   |1
  Known to fail||4.8.3, 4.9.1, 5.0

[Bug c++/65277] [5 Regression] ice in get_untransformed_body with -O2

[ktietz at gcc dot gnu.org]

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

--- Comment #3 from Kai Tietz  ---
(In reply to Marek Polacek from comment #2)
> 221040(In reply to Kai Tietz from comment #1)
> > It is caused by r214422
> 
> No, I think this started with r221040.

Yes, it got shown with r221040.  Nevertheless code-change mentioned before
happend in r214256 (svn blame lied).  So I am testing right now:

Index: cgraphunit.c
===
--- cgraphunit.c(Revision 221103)
+++ cgraphunit.c(Arbeitskopie)
@@ -1847,7 +1847,8 @@ cgraph_node::expand (void)
   announce_function (decl);
   process = 0;
   gcc_assert (lowered);
-  get_untransformed_body ();
+  if (in_lto_p)
+get_untransformed_body ();

   /* Generate RTL for the body of DECL.  */

[Bug ipa/65087] [5 Regression] r220742 causes: ICE: in ipcp_verify_propagated_values, at ipa-cp.c:1057

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
So the problem is caused by ICF which makes a symbol to have no direct calls
(and no references). As a result IPA CP triggers verification failure. I hope
the right solution is to append TODO_remove_function for ICF IPA pass.

I've been testing following patch:

diff --git a/gcc/ipa-icf.c b/gcc/ipa-icf.c
index 31fcbec..56f59a9 100644
--- a/gcc/ipa-icf.c
+++ b/gcc/ipa-icf.c
@@ -3049,7 +3049,7 @@ const pass_data pass_data_ipa_icf =
   0,/* properties_provided */
   0,/* properties_destroyed */
   0,/* todo_flags_start */
-  0,/* todo_flags_finish */
+  TODO_remove_functions,/* todo_flags_finish */
 };

 class pass_ipa_icf : public ipa_opt_pass_d

Martin

[Bug target/65138] [5 Regression] testsuite ICEs on powerpc64le

[meissner at gcc dot gnu.org]

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

--- Comment #6 from Michael Meissner  ---
Created attachment 34923
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34923&action=edit
Proposed patch to fix the problem

I'm going to run full tests on this patch, but this patch appears to fix the
problem.

[Bug sanitizer/65280] New: -fsanitize=bounds does not detect out-of-bounds access

[mpolacek at gcc dot gnu.org]

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

Bug ID: 65280
   Summary: -fsanitize=bounds does not detect out-of-bounds access
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

void
foo (int n, int (*b)[n])
{
  (*b)[n] = 1;
}

int
main ()
{
  int a[20];
  foo (3, (int (*)[3]) &a);
}

We issue no runtime error here, while clang says:
u.c:5:2: runtime error: index 3 out of bounds for type 'int [n]'

[Bug target/65278] [5 Regression] ICE (in output_718, at config/rs6000/rs6000.md:11592) on powerpc-linux-gnu

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org

--- Comment #1 from Aldy Hernandez  ---
Cannot reproduce.  Is this 32-bit ppc?  I can't reproduce on a cross build,
running cc1plus.  Are there any special options being passed to cc1plus (check
by passing -v to g++)?

[Bug sanitizer/65280] -fsanitize=bounds does not detect out-of-bounds access

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Patch here .

[Bug lto/65276] [5 Regression] LTO: ICE add_type_duplicate, at ipa-devirt.c:1462

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-02
 CC||aldyh at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |aldyh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Aldy Hernandez  ---
Confirmed.  I'll take a look.

[Bug testsuite/63175] [4.9/5 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2" basic block vectorized using SLP" 1

[msebor at gcc dot gnu.org]

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

--- Comment #17 from Martin Sebor  ---
Following up on my comment #14, and as requested on gcc-patches, the test case
below is vectorized with GCC 4.8.2 for T being either 32 bits wide (e.g., int)
or 64-bits wide (e.g., long or long long) but not with the fix referenced in
comment #13.  The difference between the test in costmodel-bb-slp-9a.c and the
code here is that unlike the source, the destination of the copy isn't aligned
on an even element boundary.

const T a [] = { 1, 2, 3, 4, 5 };
extern T b[sizeof a / sizeof *a];

void g (void)
{
const T *p = a;
T *q = b + 1;

*q++ = *p++;
*q++ = *p++;
*q++ = *p++;
*q++ = *p++;
}

In addition to this failure (mentioned on the list) the latest trunk also fails
to vectorize the following code which is successfully vectorized by 4.8.2.  The
difference is that the arrays are only declared here while in
costmodel-bb-slp-9a.c they are defined.  I only noticed this now, and so it's
not being exercised in the proposed enhanced test submitted to gcc-patches last
Friday,

extern const T a [];
extern T b[];

void g (void)
{
const T *p = a + 1;
T *q = b;

*q++ = *p++;
*q++ = *p++;
*q++ = *p++;
*q++ = *p++;
}

[Bug target/65278] [5 Regression] ICE (in output_718, at config/rs6000/rs6000.md:11592) on powerpc-linux-gnu

[doko at gcc dot gnu.org]

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

--- Comment #2 from Matthias Klose  ---
yes, 32bit powerpc,

/usr/lib/gcc/powerpc-linux-gnu/5/cc1plus -fpreprocessed DistanceEstimation.ii
-msecure-plt -quiet -dumpbase DistanceEstimation.ii -auxbase DistanceEstimation
-g -O2 -version -fPIC -fstack-protector-strong -Wformat -Wformat-security -o
/tmp/ccYUSH7u.s

[Bug target/65261] [5 Regression] bootstrap-ubsan ppc64le: gcc/libcpp/lex.c:552:30: runtime error: load of misaligned address 0x01002172dfc6 for type 'const uchar', which requires 16 byte alignment

[wschmidt at gcc dot gnu.org]

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

--- Comment #2 from Bill Schmidt  ---
Markus, yes, if adding that attribute clears up the messages for you, then I
would agree with that solution.  The code is working as designed, as use of
unaligned vector loads and stores on POWER8 is preferable to the
forced-alignment solution.  Could you please verify and submit a patch?

Thanks,
Bill

[Bug target/65278] [5 Regression] ICE (in output_718, at config/rs6000/rs6000.md:11592) on powerpc-linux-gnu

[doko at gcc dot gnu.org]

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

--- Comment #3 from Matthias Klose  ---
Created attachment 34924
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34924&action=edit
preprocessed source

this is the unreduced source

[Bug testsuite/63175] [4.9/5 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2" basic block vectorized using SLP" 1

[rguenther at suse dot de]

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

--- Comment #18 from rguenther at suse dot de  ---
On Mon, 2 Mar 2015, msebor at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63175
> 
> --- Comment #17 from Martin Sebor  ---
> Following up on my comment #14, and as requested on gcc-patches, the test case
> below is vectorized with GCC 4.8.2 for T being either 32 bits wide (e.g., int)
> or 64-bits wide (e.g., long or long long) but not with the fix referenced in
> comment #13.  The difference between the test in costmodel-bb-slp-9a.c and the
> code here is that unlike the source, the destination of the copy isn't aligned
> on an even element boundary.
> 
> const T a [] = { 1, 2, 3, 4, 5 };
> extern T b[sizeof a / sizeof *a];
> 
> void g (void)
> {
> const T *p = a;
> T *q = b + 1;
> 
> *q++ = *p++;
> *q++ = *p++;
> *q++ = *p++;
> *q++ = *p++;
> }
> 
> In addition to this failure (mentioned on the list) the latest trunk also 
> fails
> to vectorize the following code which is successfully vectorized by 4.8.2.  
> The
> difference is that the arrays are only declared here while in
> costmodel-bb-slp-9a.c they are defined.  I only noticed this now, and so it's
> not being exercised in the proposed enhanced test submitted to gcc-patches 
> last
> Friday,
> 
> extern const T a [];
> extern T b[];
> 
> void g (void)
> {
> const T *p = a + 1;
> T *q = b;
> 
> *q++ = *p++;
> *q++ = *p++;
> *q++ = *p++;
> *q++ = *p++;
> }

Both is because powerpc simply cannot handle unaligned stores and
in neither testcase we can force its alignemnt (it's "extern", and
for the first case aligning the first element won't align the
vector store)

[Bug libstdc++/64367] [5 Regression] g++-v5/stdexcept:52:28: error: invalid use of non-static data member '_M_p'

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Author: redi
Date: Mon Mar  2 16:50:24 2015
New Revision: 221118

URL: https://gcc.gnu.org/viewcvs?rev=221118&root=gcc&view=rev
Log:
PR libstdc++/64367
* include/std/stdexcept (__sso_string): Don't use non-static member
in sizeof.

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

[Bug libstdc++/64367] [5 Regression] g++-v5/stdexcept:52:28: error: invalid use of non-static data member '_M_p'

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |5.0

--- Comment #9 from Jonathan Wakely  ---
Should really be fixed this time.

[Bug testsuite/63175] [4.9/5 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2" basic block vectorized using SLP" 1

[rguenther at suse dot de]

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

--- Comment #19 from rguenther at suse dot de  ---
On Mon, 2 Mar 2015, rguenther at suse dot de wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63175
> 
> --- Comment #18 from rguenther at suse dot de  ---
> On Mon, 2 Mar 2015, msebor at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63175
> > 
> > --- Comment #17 from Martin Sebor  ---
> > Following up on my comment #14, and as requested on gcc-patches, the test 
> > case
> > below is vectorized with GCC 4.8.2 for T being either 32 bits wide (e.g., 
> > int)
> > or 64-bits wide (e.g., long or long long) but not with the fix referenced in
> > comment #13.  The difference between the test in costmodel-bb-slp-9a.c and 
> > the
> > code here is that unlike the source, the destination of the copy isn't 
> > aligned
> > on an even element boundary.
> > 
> > const T a [] = { 1, 2, 3, 4, 5 };
> > extern T b[sizeof a / sizeof *a];
> > 
> > void g (void)
> > {
> > const T *p = a;
> > T *q = b + 1;
> > 
> > *q++ = *p++;
> > *q++ = *p++;
> > *q++ = *p++;
> > *q++ = *p++;
> > }
> > 
> > In addition to this failure (mentioned on the list) the latest trunk also 
> > fails
> > to vectorize the following code which is successfully vectorized by 4.8.2.  
> > The
> > difference is that the arrays are only declared here while in
> > costmodel-bb-slp-9a.c they are defined.  I only noticed this now, and so 
> > it's
> > not being exercised in the proposed enhanced test submitted to gcc-patches 
> > last
> > Friday,
> > 
> > extern const T a [];
> > extern T b[];
> > 
> > void g (void)
> > {
> > const T *p = a + 1;
> > T *q = b;
> > 
> > *q++ = *p++;
> > *q++ = *p++;
> > *q++ = *p++;
> > *q++ = *p++;
> > }
> 
> Both is because powerpc simply cannot handle unaligned stores and
> in neither testcase we can force its alignemnt (it's "extern", and
> for the first case aligning the first element won't align the
> vector store)

How does GCC 4.8 generated vectorized code look like?

[Bug testsuite/63175] [4.9/5 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2" basic block vectorized using SLP" 1

[msebor at gcc dot gnu.org]

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

--- Comment #20 from Martin Sebor  ---
(In reply to rguent...@suse.de from comment #19)

Please remove the extern from the first test and try again (it's a vestige of
the second test).  Here's the assembly emitted by 4.8.3 for the first test
(without the extern):

$ cat u.c && gcc -DT="int" -O2 -ftree-vectorize -maltivec -S u.c && cat u.s
const T a [] = { 1, 2, 3, 4, 5 };
T b[sizeof a / sizeof *a];

void g (void)
{
const T *p = a;
T *q = b + 1;

*q++ = *p++;
*q++ = *p++;
*q++ = *p++;
*q++ = *p++;
}
.file"u.c"
.section".toc","aw"
.section".text"
.section".toc","aw"
.LC0:
.quadb
.section".text"
.align 2
.p2align 4,,15
.globl g
.section".opd","aw"
.align 3
g:
.quad.L.g,.TOC.@tocbase
.previous
.typeg, @function
.L.g:
addis 9,2,.LC1@toc@ha
addis 10,2,.LC0@toc@ha
addi 9,9,.LC1@toc@l
lxvw4x 32,0,9
ld 9,.LC0@toc@l(10)
li 10,4
stxvw4x 32,9,10
blr
.long 0
.byte 0,0,0,0,0,0,0,0
.sizeg,.-.L.g
.commb,20,4
.globl a
.section.rodata
.align 4
.typea, @object
.sizea, 20
a:
.long1
.long2
.long3
.long4
.long5
.section.rodata.cst16,"aM",@progbits,16
.align 4
.LC1:
.4byte1
.4byte2
.4byte3
.4byte4
.ident"GCC: (GNU) 4.8.3 20140911 (Red Hat 4.8.3-9)"
.section.note.GNU-stack,"",@progbits

[Bug ipa/65237] [5 Regression] r221040 caused many regressions

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #16 from Jan Hubicka  ---
We mixed several issues in this PR, but I believe all are now fixed.

[Bug ipa/65237] [5 Regression] r221040 caused many regressions

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #17 from H.J. Lu  ---
(In reply to Jan Hubicka from comment #16)
> We mixed several issues in this PR, but I believe all are now fixed.

As of r221117,  I still see

FAIL: gcc.dg/guality/sra-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 32 a[0] == 4
FAIL: gcc.dg/guality/sra-1.c   -O2  line 21 a.i == 4
FAIL: gcc.dg/guality/sra-1.c   -O3 -fomit-frame-pointer  line 21 a.i == 4
FAIL: gcc.dg/guality/sra-1.c   -O3 -g  line 21 a.i == 4
FAIL: gcc.dg/guality/sra-1.c   -Os  line 21 a.i == 4

on Linux/x86-32.

[Bug lto/65276] [5 Regression] LTO: ICE add_type_duplicate, at ipa-devirt.c:1462

[hubicka at gcc dot gnu.org]

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

--- Comment #3 from Jan Hubicka  ---
I guess it is the case where one type come from -O0 unit and have no
TYPE_BINFO, because it is not optimized. I think just removing the check may
work these days - I changed the way leading candidate is chosen and it should
be one with BINFO after all.

[Bug target/65138] [5 Regression] testsuite ICEs on powerpc64le

[dje at gcc dot gnu.org]

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

--- Comment #7 from David Edelsohn  ---
Allowing users to specify -mcpu=powerpc64le is all well and good, but if
TARGET_DEFAULT is set, it should not be gratuitously overridden in
rs6000_option_override.  The logic is not correct and defaults should not be
inherited from the processor name.

[Bug lto/65276] [5 Regression] LTO: ICE add_type_duplicate, at ipa-devirt.c:1462

[aldyh at gcc dot gnu.org]

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

--- Comment #4 from Aldy Hernandez  ---
(In reply to Jan Hubicka from comment #3)
> I guess it is the case where one type come from -O0 unit and have no
> TYPE_BINFO, because it is not optimized. I think just removing the check may
> work these days - I changed the way leading candidate is chosen and it
> should be one with BINFO after all.

Correct, TYPE_BINFO(type2) is NULL.

Started with:

commit 87a9c1b6624ae11321799e7c9aba4a7b47567d5d
Author: hubicka 
Date:   Mon Feb 9 20:34:18 2015 +

* ipa-devirt.c (odr_types_equivalent_p): Fix formating.
(add_type_duplicate): Fix comparison of BINFOs.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@220546
138bc75d-0d04-0410-96
1f-82ee72b054a4

I can post a patch.

[Bug testsuite/63175] [4.9/5 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2" basic block vectorized using SLP" 1

[rguenther at suse dot de]

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

--- Comment #21 from rguenther at suse dot de  ---
On March 2, 2015 5:58:28 PM CET, "msebor at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63175
>
>--- Comment #20 from Martin Sebor  ---
>(In reply to rguent...@suse.de from comment #19)
>
>Please remove the extern from the first test and try again (it's a
>vestige of
>the second test).  Here's the assembly emitted by 4.8.3 for the first
>test
>(without the extern):
>
>$ cat u.c && gcc -DT="int" -O2 -ftree-vectorize -maltivec -S u.c && cat
>u.s
>const T a [] = { 1, 2, 3, 4, 5 };
>T b[sizeof a / sizeof *a];
>
>void g (void)
>{
>const T *p = a;
>T *q = b + 1;
>
>*q++ = *p++;
>*q++ = *p++;
>*q++ = *p++;
>*q++ = *p++;
>}
>.file"u.c"
>.section".toc","aw"
>.section".text"
>.section".toc","aw"
>.LC0:
>.quadb
>.section".text"
>.align 2
>.p2align 4,,15
>.globl g
>.section".opd","aw"
>.align 3
>g:
>.quad.L.g,.TOC.@tocbase
>.previous
>.typeg, @function
>.L.g:
>addis 9,2,.LC1@toc@ha
>addis 10,2,.LC0@toc@ha
>addi 9,9,.LC1@toc@l
>lxvw4x 32,0,9
>ld 9,.LC0@toc@l(10)
>li 10,4
>stxvw4x 32,9,10

But isn't this simply wrong-code?!

>blr
>.long 0
>.byte 0,0,0,0,0,0,0,0
>.sizeg,.-.L.g
>.commb,20,4
>.globl a
>.section.rodata
>.align 4
>.typea, @object
>.sizea, 20
>a:
>.long1
>.long2
>.long3
>.long4
>.long5
>.section.rodata.cst16,"aM",@progbits,16
>.align 4
>.LC1:
>.4byte1
>.4byte2
>.4byte3
>.4byte4
>.ident"GCC: (GNU) 4.8.3 20140911 (Red Hat 4.8.3-9)"
>.section.note.GNU-stack,"",@progbits

[Bug debug/63572] [5 Regression] ICF breaks user debugging experience

[hubicka at gcc dot gnu.org]

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

--- Comment #11 from Jan Hubicka  ---
Reported by HJ:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65237

As of r221117,  I still see

FAIL: gcc.dg/guality/sra-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 32 a[0] == 4
FAIL: gcc.dg/guality/sra-1.c   -O2  line 21 a.i == 4
FAIL: gcc.dg/guality/sra-1.c   -O3 -fomit-frame-pointer  line 21 a.i == 4
FAIL: gcc.dg/guality/sra-1.c   -O3 -g  line 21 a.i == 4
FAIL: gcc.dg/guality/sra-1.c   -Os  line 21 a.i == 4

on Linux/x86-32.

[Bug ipa/65237] [5 Regression] r221040 caused many regressions

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #18 from Jan Hubicka  ---
We have https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572 about debugging
issues. I added the note there and closing this one.

[Bug libstdc++/65279] [4.8/4.9/5 Regression] std::scoped_allocator_adaptor is not assignable

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Mon Mar  2 17:50:55 2015
New Revision: 221119

URL: https://gcc.gnu.org/viewcvs?rev=221119&root=gcc&view=rev
Log:
PR libstdc++/65279
* include/std/scoped_allocator (__inner_type_impl,
scoped_allocator_adaptor): Add defaulted copy assignment and move
assignment operators.
* testsuite/20_util/scoped_allocator/65279.cc: New.

Added:
trunk/libstdc++-v3/testsuite/20_util/scoped_allocator/65279.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/scoped_allocator

[Bug lto/65276] [5 Regression] LTO: ICE add_type_duplicate, at ipa-devirt.c:1462

[hubicka at ucw dot cz]

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

--- Comment #5 from Jan Hubicka  ---
> Correct, TYPE_BINFO(type2) is NULL.
> 
> Started with:
> 
> commit 87a9c1b6624ae11321799e7c9aba4a7b47567d5d
> Author: hubicka 
> Date:   Mon Feb 9 20:34:18 2015 +
> 
> * ipa-devirt.c (odr_types_equivalent_p): Fix formating.
> (add_type_duplicate): Fix comparison of BINFOs.

Yep, previously we would have false positive about base mismatch.
> 
> 
> git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@220546
> 138bc75d-0d04-0410-96
> 1f-82ee72b054a4
> 
> I can post a patch.

That would be nice, patch is preaproved (with the testcase) if it passes
testing.

Honza

[Bug libstdc++/65279] [4.8/4.9 Regression] std::scoped_allocator_adaptor is not assignable

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||5.0
Summary|[4.8/4.9/5 Regression]  |[4.8/4.9 Regression]
   |std::scoped_allocator_adapt |std::scoped_allocator_adapt
   |or is not assignable|or is not assignable
  Known to fail|5.0 |

--- Comment #2 from Jonathan Wakely  ---
Fixed on trunk so far.

[Bug ipa/60871] [4.9 Regression] internal compiler error: in possible_polymorphic_call_targets, at ipa-devirt.c:1510

[jussilehtola at fedoraproject dot org]

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

Susi Lehtola  changed:

   What|Removed |Added

 CC||jussilehtola@fedoraproject.
   ||org

--- Comment #17 from Susi Lehtola  ---
Any progress on the backport?

[Bug libgcc/64885] libstdc++ all_attributes failure

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
Author: redi
Date: Mon Mar  2 18:02:18 2015
New Revision: 221120

URL: https://gcc.gnu.org/viewcvs?rev=221120&root=gcc&view=rev
Log:
PR libgcc/64885
* gthr-single.h: Use __unused__ attribute instead of unused.
* config/gthr-vxworks.h: Likewise.
* config/i386/gthr-win32.h: Likewise.

Modified:
trunk/libgcc/ChangeLog
trunk/libgcc/config/gthr-vxworks.h
trunk/libgcc/config/i386/gthr-win32.h
trunk/libgcc/gthr-single.h

[Bug libgcc/65281] New: Lots of macros using non-reserved names in gthr headers

[redi at gcc dot gnu.org]

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

Bug ID: 65281
   Summary: Lots of macros using non-reserved names in gthr
headers
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org

See Bug 64885 comment 6 (referring to libgcc/gthr-single.h and others):

Note the UNUSED macro (whether function-like or not) certainly doesn't belong
to headers included from STL headers either.
It should have been __gthr_unused or something similar.

and Bug 64885 comment 7:

Ditto the header guards like
GCC_GTHR_POSIX_H
GCC_GTHR_SINGLE_H
GCC_GTHR_H
and macros like
GTHREAD_USE_WEAK
HIDE_EXPORTS



This breaks valid programs such as:

#define UNUSED 1
#include 
int main() { }

[Bug libgcc/64885] libstdc++ all_attributes failure

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #10 from Jonathan Wakely  ---
The FAIL should be fixed, I've created Bug 65281 for the other problems with
non-reserved macros in the gthr headers.

[Bug testsuite/63175] [4.9/5 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2" basic block vectorized using SLP" 1

[msebor at gcc dot gnu.org]

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

--- Comment #22 from Martin Sebor  ---
(In reply to rguent...@suse.de from comment #21)
> >g:
> >.quad.L.g,.TOC.@tocbase
> >.previous
> >.typeg, @function
> >.L.g:
> >addis 9,2,.LC1@toc@ha
> >addis 10,2,.LC0@toc@ha
> >addi 9,9,.LC1@toc@l
> >lxvw4x 32,0,9
> >ld 9,.LC0@toc@l(10)
> >li 10,4
> >stxvw4x 32,9,10
> 
> But isn't this simply wrong-code?!

I don't see anything wrong with it.  The load seems straightforward enough and,
AFAICS, the store code matches the stxvw4x example in the PowerISA 2.07
reference (in Storing an Unaligned Quadword to Big-Endian Storage on page 360).
 r9 is the address of B and r10 is the byte offset of B[1] from B.

[Bug libgcc/65281] Lots of macros using non-reserved names in gthr headers

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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