[Bug tree-optimization/70388] New: [openacc] host_data use_device triggers error mentioning use_device_ptr

[vries at gcc dot gnu.org]

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

Bug ID: 70388
   Summary: [openacc] host_data use_device triggers error
mentioning use_device_ptr
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider test.c:
...
void
foo (void)
{
  int i = 0;

#pragma acc host_data use_device(i)
  {
  }
}
...

Compiling for openacc gives an error message that mentions the use_device_ptr:
...
$ gcc test.c -fopenacc
test.c: In function ‘foo’:
test.c:9:33: error: ‘use_device_ptr’ variable is neither a pointer nor an array
 #pragma acc host_data use_device(i)
 ^
...

The fortran version version of this testcase
(src/gcc/testsuite/gfortran.dg/goacc/host_data-tree.f95) compiles without
errors.

[Bug tree-optimization/70372] [6 Regression] ICE: in wide_int_to_tree, at tree.c:1488 with -fno-tree-fre and v2ti vectors

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Thu Mar 24 08:17:43 2016
New Revision: 234449

URL: https://gcc.gnu.org/viewcvs?rev=234449&root=gcc&view=rev
Log:
2016-03-24  Richard Biener  

PR tree-optimization/70372
* tree-ssa-reassoc.c (eliminate_plus_minus_pair): Use
build_all_ones_cst to also handle vector types correctly.

* gcc.dg/tree-ssa/pr70372.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr70372.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-reassoc.c

[Bug tree-optimization/70372] [6 Regression] ICE: in wide_int_to_tree, at tree.c:1488 with -fno-tree-fre and v2ti vectors

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c/70389] New: uint_16t left shift with -Wconversion produces incorrect warning

[bobgmeyers at muchomail dot com]

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

Bug ID: 70389
   Summary: uint_16t left shift with -Wconversion produces
incorrect warning
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bobgmeyers at muchomail dot com
  Target Milestone: ---

This code:

int
main(void){
  uint16_t x;

  x=5;
  do{
x<<=1U;
x++;
  }while(1);
}

The code obviously outputs nothing, but this is just an example of this bug
which happens in every case as described below.

with -Wconversion it produces:

warning: conversion to ‘uint16_t’ from ‘int’ may alter its value [-Wconversion]
 x<<=1U;

How on earth could x<<1U end up being an int? x isn't signed and 1U isn't
signed (and according to the spec, the type of 1U is not relevant to the type
of x<<1U). I tried uint32_t and the error went away, so it looks like a problem
with uint16_t. Right shift is also OK.

Might relate to:

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

[Bug middle-end/70370] ICE in execute_todo, at passes.c:2003 when using __real__ or __imag__ as lvalue in asm

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-checking, wrong-code

--- Comment #8 from Richard Biener  ---
Interestingly enough for

struct X { int i; };

struct X boo (struct X x)
{
  __asm__ ("" : "=r" (x.i));
  return x;
}

struct X boof (struct X x)
{
  __asm__ ("" : "+r" (x.i));
  return x;
}

we "ignore" the !allows_mem and end up generating virtual operands anyway,
leaving RTL expansion to fix up things (or ICE).  When omitting the .i
the proposed patch would reject this (we can't fix up on GIMPLE if not
for using a different type based on the mode).  If making X not have
a mode suitable for a register we get

t.c: In function ‘boo’:
t.c:5:3: error: impossible constraint in ‘asm’
   __asm__ ("" : "=r" (x));
   ^

this hints the ICE being an operand scanner issue after all (in some weird
way...).  Still having !allows_mem but not a register might be odd.

Ok, so I think the real issue with __real/__imag is that it doesn't get
a VOP because the param is_gimple_reg() as it has DECL_GIMPLE_REG_P set.
That happens because we do in gimplify_function_tree:

11521 for (parm = DECL_ARGUMENTS (fndecl); parm ; parm = DECL_CHAIN (parm))
11522   {
11523 /* Preliminarily mark non-addressed complex variables as eligible
11524for promotion to gimple registers.  We'll transform their uses
11525as we find them.  */
(gdb) 
11526 if ((TREE_CODE (TREE_TYPE (parm)) == COMPLEX_TYPE
11527  || TREE_CODE (TREE_TYPE (parm)) == VECTOR_TYPE)
11528 && !TREE_THIS_VOLATILE (parm)
11529 && !needs_to_live_in_memory (parm))
11530   DECL_GIMPLE_REG_P (parm) = 1;
11531   }

but this means we have to transform _all_ uses during gimplification.
I don't think we can roll-back setting of DECL_GIMPLE_REG_P.  Or the FEs
would need to mark even !allows_mem asm operands as addressable.

So fixing this up in gimplification is required but I'm trying to leave
the other cases (!is_gimple_reg base) alone for the expander to complain about.

[Bug fortran/70350] [5 Regression] ICE with -fcheck=all and array initialization

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #2 from Dominique d'Humieres  ---
It is caused by revision r234093.

[Bug c++/70387] -fnon-call-exceptions has no effect

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-03-24
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
We need a complete testcase ("implementation details omitted" doesn't help).

The EH info is present as far as I can see

[Bug c++/70386] [6 Regression] ICE with -Wall on valid code on x86_64-linux-gnu in verify_ctor_sanity, at cp/constexpr.c:2232

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
  Known to work||5.3.0
   Keywords||diagnostic,
   ||ice-on-valid-code
   Last reconfirmed||2016-03-24
 Ever confirmed|0   |1
Summary|ICE with -Wall on valid |[6 Regression] ICE with
   |code on x86_64-linux-gnu in |-Wall on valid code on
   |verify_ctor_sanity, at  |x86_64-linux-gnu in
   |cp/constexpr.c:2232 |verify_ctor_sanity, at
   ||cp/constexpr.c:2232
   Target Milestone|--- |6.0

--- Comment #1 from Richard Biener  ---
Confirmed.  -Wall required.

[Bug tree-optimization/69042] [6 regression] Missed optimization in ivopts

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #14 from Richard Biener  ---
Regression is fixed.

[Bug tree-optimization/70390] New: [6 Regression] internal compiler error: in copy_loop_close_phi_args, at graphite-isl-ast-to-gimple.c:2114

[ktkachov at gcc dot gnu.org]

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

Bug ID: 70390
   Summary: [6 Regression] internal compiler error: in
copy_loop_close_phi_args, at
graphite-isl-ast-to-gimple.c:2114
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

The testcase:

int a, c;
int *b;
short d, f;
static int e;
long g;
void
fn1 ()
{
  a = 4;
  for (; a >= 0; a--)
;
  for (; c;)
for (; f <= 4; f++)
  {
g &= a;
d = 0;
for (; d <= 4; d++)
  e |= b[d];
  }
}

ICEs for me on aarch64 with -O3 -floop-interchange (-O2 doesn't crash)

mycrash.c: In function 'fn1':
mycrash.c:7:1: internal compiler error: in copy_loop_close_phi_args, at
graphite-isl-ast-to-gimple.c:2114
 fn1 ()
 ^~~
0x108da77
translate_isl_ast_to_gimple::copy_loop_close_phi_args(basic_block_def*,
basic_block_def*, bool)
$SRC/gcc/graphite-isl-ast-to-gimple.c:2114
0x108def3
translate_isl_ast_to_gimple::copy_loop_close_phi_nodes(basic_block_def*,
basic_block_def*)
$SRC/gcc/graphite-isl-ast-to-gimple.c:2183
0x108ead5
translate_isl_ast_to_gimple::copy_bb_and_scalar_dependences(basic_block_def*,
edge_def*, vec)
$SRC/gcc/graphite-isl-ast-to-gimple.c:2715
0x108f608
translate_isl_ast_to_gimple::translate_isl_ast_node_user(isl_ast_node*,
edge_def*, std::map,
std::allocator > >&)
$SRC/gcc/graphite-isl-ast-to-gimple.c:935
0x108f78f translate_isl_ast_to_gimple::translate_isl_ast(loop*, isl_ast_node*,
edge_def*, std::map,
std::allocator > >&)
$SRC/gcc/graphite-isl-ast-to-gimple.c:1039
0x108fce0 translate_isl_ast_to_gimple::translate_isl_ast_node_block(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
$SRC/gcc/graphite-isl-ast-to-gimple.c:964
0x108f7a5 translate_isl_ast_to_gimple::translate_isl_ast(loop*, isl_ast_node*,
edge_def*, std::map,
std::allocator > >&)
$SRC/gcc/graphite-isl-ast-to-gimple.c:1043
0x10902cc graphite_regenerate_ast_isl(scop*)
$SRC/gcc/graphite-isl-ast-to-gimple.c:3185
0x1086f15 graphite_transform_loops()
$SRC/gcc/graphite.c:329
0x10870ac graphite_transforms
$SRC/gcc/graphite.c:356
0x10870ac execute
$SRC/gcc/graphite.c:433
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/70390] [6 Regression] internal compiler error: in copy_loop_close_phi_args, at graphite-isl-ast-to-gimple.c:2114

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target|aarch64 |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-24
 CC||spop at gcc dot gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed on x86_64-linux.

[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format

[dominiq at lps dot ens.fr]

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

--- Comment #11 from Dominique d'Humieres  ---
> Created attachment 38075 [details]
> A patch for testing

With the patch and using the test attached to comment 5 with y = 1.0 and d=8, I
get the following output

-8pf18.8 y=0.000.
-7pf18.8 y=0.00.0
-6pf18.8 y=0.0.00
-5pf18.8 y=0..000
-4pf18.8 y=0.000.
-3pf18.8 y=0.00.0
-2pf18.8 y=0.0.00
-1pf18.8 y=0.1000
0pf18.8 y=1.
1pf18.8 y=   10.
2pf18.8 y=  100.
3pf18.8 y= 1000.
4pf18.8 y=1.
5pf18.8 y=   10.
6pf18.8 y=  100.
7pf18.8 y= 1000.

which is wrong for P<=-2.

[Bug hsa/70391] New: HSA back-end produces wrong alignment load/store instructions

[marxin at gcc dot gnu.org]

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

Bug ID: 70391
   Summary: HSA back-end produces wrong alignment load/store
instructions
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: hsa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jamborm at gcc dot gnu.org
  Target Milestone: ---

Hello.

As reported here:
https://github.com/HSAFoundation/gccbrig/issues/6#issuecomment-197986345

current HSA back-end produces wrong alignment load/stores, for instance in
following example:

prog function &foo(align(4) arg_u8 %res[12])(align(4) arg_u8 %c[12]) <--- 'c'
has alignment just 4 
{
align(4) private_u8 %__private_0[12];
align(4) private_u8 %__hsa_anonymous_2357[12];
ld_arg_align(8)_u64 $d0, [%c]; < alignment == 8


Martin

[Bug tree-optimization/70390] [6 Regression] internal compiler error: in copy_loop_close_phi_args, at graphite-isl-ast-to-gimple.c:2114

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
graphite uses a strange "premature optimization" with scev_analyzable_p
which seems to be confused about a degenerate IV we have in the loop.

  
  _1 = PHI <_2, _3>
  _3 = _1;

   if ()  goto exit

   goto bbN;

  exit:
   _5 = PHI <_3>

interestingly the copyprop pass before graphite doesn't fix this up.

Ah, before copyprop we have

  _57 = -1;

...

  # prephitmp_59 = PHI 
  _16 = _57 & prephitmp_59;

which SCCP introduces (during it's constant "non-"propagation, not during
final value replacement).

Note that copyprop doesn't visit "uninteresting" stmts (like _16 = _57 &
prephitmp_59), it merely folds them at the end of propagation which
figures out _57 is -1.

Not sure if the GRAPHITE assert is necessary or merely a hint that some
optimization didn't apply - that is, do we actually generate wrong-code
if it triggers?

Index: gcc/graphite-isl-ast-to-gimple.c
===
--- gcc/graphite-isl-ast-to-gimple.c(revision 234449)
+++ gcc/graphite-isl-ast-to-gimple.c(working copy)
@@ -2112,7 +2112,7 @@ copy_loop_close_phi_args (basic_block ol

   if (is_gimple_reg (res) && scev_analyzable_p (res, region->region))
/* Loop close phi nodes should not be scev_analyzable_p.  */
-   gcc_unreachable ();
+   /*gcc_unreachable ()*/;

   gphi *new_close_phi = create_phi_node (SSA_NAME_VAR (res), new_bb);
   tree new_res = create_new_def_for (res, new_close_phi,
@@ -2497,7 +2497,7 @@ copy_cond_phi_nodes (basic_block bb, bas
continue;
   if (is_gimple_reg (res) && scev_analyzable_p (res, region->region))
/* Cond phi nodes should not be scev_analyzable_p.  */
-   gcc_unreachable ();
+   /*gcc_unreachable ()*/;

   gphi *new_phi = create_phi_node (SSA_NAME_VAR (res), new_bb);
   tree new_res = create_new_def_for (res, new_phi,

"fixes" the ICE.

Sebastian?

[Bug tree-optimization/70392] New: [openacc] inconsistent line numbers in uninitialised warnings for if clause

[vries at gcc dot gnu.org]

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

Bug ID: 70392
   Summary: [openacc] inconsistent line numbers in uninitialised
warnings for if clause
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

I. uninitialized warning, regular

1. In fortran, the line number for the uninitialized warning is the one for the
use:
...
$ cat -n uninit.f95 
 1  subroutine foo
 2  
 3integer :: i
 4  
 5i = i + 1
 6  
 7  end subroutine foo
$ gfortran -Wuninitialized uninit.f95 -S
uninit.f95:5:0:

   i = i + 1

Warning: ‘i’ is used uninitialized in this function [-Wuninitialized]


2. In C, that's the same:
...
$ cat -n uninit.c
 1  void
 2  foo (void)
 3  {
 4int i;
 5  
 6i++;
 7  }
$ gcc -Wuninitialized uninit.c -S
uninit.c: In function ‘foo’:
uninit.c:6:4: warning: ‘i’ is used uninitialized in this function
[-Wuninitialized]
   i++;
   ~^~
...

3. And in C++, still the same:
...
$ g++ -Wuninitialized uninit.c -S
uninit.c: In function ‘void foo()’:
uninit.c:6:6: warning: ‘i’ is used uninitialized in this function
[-Wuninitialized]
   i++;
  ^
...


II. uninitialized warning, openacc if-clause

1. Again, in Fortran, the line number for the uninitialized warning is the one
for the use:
...
$ cat -n uninit-if.f95
 1  
 2  program test
 3implicit none
 4logical :: b, b2, b3, b4
 5integer :: data, data2
 6  
 7!$acc parallel if(b)
 8!$acc end parallel
 9  
10!$acc kernels if(b2)
11!$acc end kernels
12  
13!$acc data if(b3)
14!$acc end data
15  
16!$acc update if(b4) self(data2)
17  
18  end program test
$ gfortran -Wuninitialized uninit-if.f95 -S -fopenacc
uninit-if.f95:7:0:

   !$acc parallel if(b)

Warning: ‘b’ is used uninitialized in this function [-Wuninitialized]
uninit-if.f95:10:0:

   !$acc kernels if(b2)

Warning: ‘b2’ is used uninitialized in this function [-Wuninitialized]
uninit-if.f95:13:0:

   !$acc data if(b3)

Warning: ‘b3’ is used uninitialized in this function [-Wuninitialized]
uninit-if.f95:16:0:

   !$acc update if(b4) self(data2)

Warning: ‘b4’ is used uninitialized in this function [-Wuninitialized]
...

2. In C, that's the same:
...
$ cat -n uninit-if.c
 1  #include 
 2  
 3  int
 4  main (void)
 5  {
 6int i, i2, i3, i4;
 7bool b, b2, b3, b4;
 8int data, data2;
 9  
10#pragma acc parallel if(i)
11;
12  
13#pragma acc parallel if(b)
14;
15  
16#pragma acc kernels if(i2)
17;
18  
19#pragma acc kernels if(b2)
20;
21  
22#pragma acc data if(i3)
23;
24  
25#pragma acc data if(b3)
26;
27  
28#pragma acc update if(i4) self(data)
29;
30  
31#pragma acc update if(b4) self(data2)
32;
33  
34  }
$ ./lean/install/bin/gcc -Wuninitialized uninit-if.c -S -fopenacc
uninit-if.c: In function ‘main’:
uninit-if.c:10:27: warning: ‘i’ is used uninitialized in this function
[-Wuninitialized]
   #pragma acc parallel if(i)
   ^
uninit-if.c:13:27: warning: ‘b’ is used uninitialized in this function
[-Wuninitialized]
   #pragma acc parallel if(b)
   ^
uninit-if.c:16:26: warning: ‘i2’ is used uninitialized in this function
[-Wuninitialized]
   #pragma acc kernels if(i2)
  ^~
uninit-if.c:19:26: warning: ‘b2’ is used uninitialized in this function
[-Wuninitialized]
   #pragma acc kernels if(b2)
  ^~
uninit-if.c:22:23: warning: ‘i3’ is used uninitialized in this function
[-Wuninitialized]
   #pragma acc data if(i3)
   ^~
uninit-if.c:25:23: warning: ‘b3’ is used uninitialized in this function
[-Wuninitialized]
   #pragma acc data if(b3)
   ^~
uninit-if.c:28:25: warning: ‘i4’ is used uninitialized in this function
[-Wuninitialized]
   #pragma acc update if(i4) self(data)
 ^~
uninit-if.c:31:25: warning: ‘b4’ is used uninitialized in this function
[-Wuninitialized]
   #pragma acc update if(b4) self(data2)
 ^~
...

3. For C++ however, for the bool variables, we get the line number of the
declaration:
...
$ ./lean/install/bin/g++ -Wuninitialized uninit-if.c -S -fopenacc
uninit-if.c: In function ‘int main()’:
uninit-if.c:10:29: warning: ‘i’ is used uninitialized in this function
[-Wuninitialized]
   #pragma acc parallel if(i)
 ^
uninit-if.c:7:8: warning: ‘b’ is used uninitialized in this function
[-Wuninitialized]
   bool b, b2, b3, b4;
^
uninit-if.c

[Bug c++/70387] -fnon-call-exceptions has no effect

[jwjagersma at gmail dot com]

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

--- Comment #2 from jwjagersma at gmail dot com ---
Created attachment 38077
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38077&action=edit
Test case

I reduced my code to the bare minimum required to reproduce this issue.

Compile with djgpp:
"g++ -std=gnu++14 -fnon-call-exceptions -fasynchronous-unwind-tables -o
traptest.exe traptest.cpp"

[Bug tree-optimization/70390] [6 Regression] internal compiler error: in copy_loop_close_phi_args, at graphite-isl-ast-to-gimple.c:2114

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug c/70389] uint_16t left shift with -Wconversion produces incorrect warning

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
For unsigned short x <<= 1U is after integral promotions
x = (((int) x) << 1U);
and -Wconversion warns about the conversion of the int value to unsigned short.
Consider e.g. x being 0x8000, x << 1U then is 0x1 and the implicit
conversion alters the value.
If x is unsigned int, there is no promotion, so if x is e.g. 0x8000U, then
x << 1U is 0 and nothing is altered.

[Bug c++/70393] New: Miscompilation: missing constructor call for static object

[js at alien8 dot de]

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

Bug ID: 70393
   Summary: Miscompilation: missing constructor call for static
object
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: js at alien8 dot de
  Target Milestone: ---

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

For the attached testcase, g++ on Linux miscompiles and there is no constructor
called for the static object. That results in the vtable being 0 and the
program segfaulting. clang compiles this without problem.

% g++ --version
g++ (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

To reproduce do the following:

% g++ -std=c++11 -o testcase testcase.cpp
% ./testcase 
set_element() on B @ 0x602070
call_element() on B @ 0x602070
zsh: segmentation fault (core dumped)  ./testcase

Expected output is this:
% clang++ -std=c++11 -o testcase testcase.cpp 
% ./testcase 
set_element() on B @ 0x602068
call_element() on B @ 0x602068
vfunc() on AB @ 0x602068

[Bug c++/70305] 5.3.0 solaris: ld: fatal: relocation error: R_SPARC_DISP32: file ../src/c++11/.libs/libc++11convenience.a

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-03-24
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Botcazou  ---
> Example showing where the `-z relax=comdat` flag needed to be applied in the
> generated configure files to get a working build. Ultimately this flag
> should not be necessary and the compiler should be emitting correct
> relocations.

This looks like the Solaris linker putting itself in a corner: if it cannot
deal with relocations to discarded sections, then it should not discard the
sections in the first place!  Please report this to Oracle first.

[Bug other/70346] [libvtv] 6.0-20160313 build succeeds, install fails: cannot stat '.libs/libvtv.a': No such file or directory

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-03-24
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Botcazou  ---
> Build succeeds and seems to build libvtv.la and libvtv.so*, but the install
> step fails because it can't find libvtv.a. It seems like there are missing
> targets/dependencies or some kind of make race:

Which version of GNU make do you use?

[Bug target/70290] -mavx512vl breaks parsing of C++ vector condition

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar 24 11:26:44 2016
New Revision: 234450

URL: https://gcc.gnu.org/viewcvs?rev=234450&root=gcc&view=rev
Log:
PR target/70290
* g++.dg/ext/pr70290.C: Add -Wno-psabi -w to dg-options.  Formatting.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ext/pr70290.C

[Bug hsa/70394] New: HSA: kernel dispatch packet mechanism uses uninitialized memory

[marxin at gcc dot gnu.org]

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

Bug ID: 70394
   Summary: HSA: kernel dispatch packet mechanism uses
uninitialized memory
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: hsa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jamborm at gcc dot gnu.org
  Target Milestone: ---

As seen in PHSA runtime:

==7960== Thread 2:
==7960== Conditional jump or move depends on uninitialised value(s)
==7960==at 0xCEA5714: __phsa_launch_wg_function (in
/home/visit0r/src/phsa-finalizer/build/rt/libphsa-rt.so)
==7960==by 0xBA89C35: main__omp_fn_0 (in
/home/visit0r/temp/test_cases/phsa-temp/program-0.so)
==7960==by 0x5EF1B32: CpuAgent::DoWork() (cpu_agent.cpp:155)
==7960==by 0x5EF15ED: CpuKernelExecutorThread(CpuAgent*) (cpu_agent.cpp:68)
==7960==by 0x5EFAE8A: void boost::_bi::list1
>::operator()(boost::_bi::type,
void (*&)(CpuAgent*), boost::_bi::list0&, int) (bind.hpp:253)
==7960==by 0x5EFAB24: boost::_bi::bind_t > >::operator()()
(bind_template.hpp:20)
==7960==by 0x5EFA771: boost::detail::thread_data > >
>::run() (thread.hpp:117)
==7960==by 0x6B11A49: ??? (in
/usr/lib/x86_64-linux-gnu/libboost_thread.so.1.54.0)
==7960==by 0x506D181: start_thread (pthread_create.c:312)
==7960==by 0x537D47C: clone (clone.S:111)

Our current code does not properly set packet->header field.

Martin

[Bug c++/70395] New: [C++11] Error when initializing array of non-copyable non-trivial type in constructor initializer list

[mosra at centrum dot cz]

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

Bug ID: 70395
   Summary: [C++11] Error when initializing array of non-copyable
non-trivial type in constructor initializer list
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mosra at centrum dot cz
  Target Milestone: ---

I am getting an error when trying to compile the following snippet:

struct NonCopyable {
NonCopyable(const NonCopyable&) = delete;
NonCopyable(NonCopyable&&) = delete;
NonCopyable& operator=(const NonCopyable&) = delete;
NonCopyable& operator=(NonCopyable&&) = delete;

NonCopyable() {}

~NonCopyable() {} // to make it non-trivial
};

union A {
A(): _a{} {}
~A() {}

NonCopyable _a[5];
} a;

int main() {}

GCC 5.3 complains that `error: use of deleted function
‘NonCopyable::NonCopyable(NonCopyable&&)’`, both Clang 3.7 and MSVC 2015
compile fine. I really don't see why it should use a move constructor for
initializing the elements. The behavior differs when I make the following
changes:

- If I make the `_a` member a non-array, it compiles fine.
- If I remove the `NonCopyable` destructor, the struct is trivial again and
everything compiles fine
- If I use placement new instead of `_a{}`, everything compiles fine (but
that's verbose)

The behavior is the same for struct and union, I used union to emphasize that I
need to do the initialization explicitly.

This probably affects also older versions, didn't have a chance to test.

[Bug rtl-optimization/70396] New: ICE on valid code at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (in immed_wide_int_const, at emit-rtl.c:606)

[chengniansun at gmail dot com]

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

Bug ID: 70396
   Summary: ICE on valid code at -O3 in 32-bit and 64-bit modes on
x86_64-linux-gnu (in immed_wide_int_const, at
emit-rtl.c:606)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

The following code crashes the trunk at -O3 in 32-bit and 64-bit modes on
x86_64-linux-gnu.



$: gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 6.0.0 20160324 (experimental) [trunk revision 234448] (GCC) 
$: 
$: gcc-trunk -O3 small.c
small.c:4:5: warning: array ‘a’ assumed to have one element
 int a[];
 ^
small.c: In function ‘fn1’:
small.c:11:14: warning: iteration 2147483645 invokes undefined behavior
[-Waggressive-loop-optimizations]
   for (; c; c++) {
 ~^~
small.c:11:3: note: within this loop
   for (; c; c++) {
   ^~~
small.c:7:6: internal compiler error: in immed_wide_int_const, at
emit-rtl.c:606
 void fn1() {
  ^~~
0x806f7d immed_wide_int_const(generic_wide_int >
const&, machine_mode)
../../gcc-source-trunk/gcc/emit-rtl.c:606
0x82b5ce const_vector_from_tree
../../gcc-source-trunk/gcc/expr.c:11531
0x82b5ce expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc-source-trunk/gcc/expr.c:9748
0xa65c6a expand_expr
../../gcc-source-trunk/gcc/expr.h:256
0xa65c6a vector_compare_rtx
../../gcc-source-trunk/gcc/optabs.c:5299
0xa7025d expand_vec_cond_expr(tree_node*, tree_node*, tree_node*, tree_node*,
rtx_def*)
../../gcc-source-trunk/gcc/optabs.c:5629
0x840c35 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc-source-trunk/gcc/expr.c:9358
0x7274a1 expand_gimple_stmt_1
../../gcc-source-trunk/gcc/cfgexpand.c:3654
0x7274a1 expand_gimple_stmt
../../gcc-source-trunk/gcc/cfgexpand.c:3714
0x7296ea expand_gimple_basic_block
../../gcc-source-trunk/gcc/cfgexpand.c:5720
0x72eafe execute
../../gcc-source-trunk/gcc/cfgexpand.c:6335
Please submit a full bug report,
with preprocessed source if appropriate.
gcc version 6.0.0 20160324 (experimental) [trunk revision 234448] (GCC)
$:
$: gcc-trunk -O3 small.c
small.c:4:5: warning: array ‘a’ assumed to have one element
 int a[];
 ^
small.c: In function ‘fn1’:
small.c:11:14: warning: iteration 2147483645 invokes undefined behavior
[-Waggressive-loop-optimizations]  
   for (; c; c++) {
 ~^~
small.c:11:3: note: within this loop
   for (; c; c++) {
   ^~~
small.c:7:6: internal compiler error: in immed_wide_int_const, at
emit-rtl.c:606
 void fn1() {
  ^~~
0x806f7d immed_wide_int_const(generic_wide_int >
const&, machine_mode)
../../gcc-source-trunk/gcc/emit-rtl.c:606
0x82b5ce const_vector_from_tree
../../gcc-source-trunk/gcc/expr.c:11531
0x82b5ce expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc-source-trunk/gcc/expr.c:9748
0xa65c6a expand_expr
../../gcc-source-trunk/gcc/expr.h:256
0xa65c6a vector_compare_rtx
../../gcc-source-trunk/gcc/optabs.c:5299
0xa7025d expand_vec_cond_expr(tree_node*, tree_node*, tree_node*, tree_node*,
rtx_def*)
../../gcc-source-trunk/gcc/optabs.c:5629
0x840c35 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc-source-trunk/gcc/expr.c:9358
0x7274a1 expand_gimple_stmt_1
../../gcc-source-trunk/gcc/cfgexpand.c:3654
0x7274a1 expand_gimple_stmt
../../gcc-source-trunk/gcc/cfgexpand.c:3714
0x7296ea expand_gimple_basic_block
../../gcc-source-trunk/gcc/cfgexpand.c:5720
0x72eafe execute
../../gcc-source-trunk/gcc/cfgexpand.c:6335
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$:
$: cat small.c
struct S2 {
  signed f1 : 3;
};
int a[];
int b, c;
char d;
void fn1() {
  struct S2 e;
  b / e.f1;
  c = 2;
  for (; c; c++) {
d = 0;
a[c] = ~e.f1 != d;
  }
}
$:

[Bug fortran/70397] New: ice while allocating ultimate polymorphic

[valeryweber at hotmail dot com]

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

Bug ID: 70397
   Summary: ice while allocating ultimate polymorphic
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: valeryweber at hotmail dot com
  Target Milestone: ---

Dear All
The following code is ICEing.
v

cat gcc-ice-polym.f90
module mod

  TYPE, PUBLIC :: base_type
  END TYPE base_type

  TYPE, PUBLIC :: dict_entry_type
 PRIVATE
 CLASS( * ), ALLOCATABLE :: key
 CLASS( * ), ALLOCATABLE :: val
  END TYPE dict_entry_type


contains

  SUBROUTINE dict_put ( this, key, val )
CLASS(dict_entry_type), INTENT(INOUT) :: this
CLASS(base_type), INTENT(IN) :: key, val
INTEGER  :: istat
ALLOCATE( this%key, SOURCE=key, STAT=istat )
  end SUBROUTINE dict_put
end module mod

gfortran-5.3.0  -c gcc-ice-polym.f90
gcc-ice-polym.f90:19:0:

 ALLOCATE( this%key, SOURCE=key, STAT=istat )
 1
internal compiler error: Segmentation fault
0xa3420f crash_signal
../../gcc-5.3.0/gcc/toplev.c:383
0x69c8b8 gfc_class_len_get(tree_node*)
../../gcc-5.3.0/gcc/fortran/trans-expr.c:170
0x69fcb7 gfc_copy_class_to_class(tree_node*, tree_node*, tree_node*, bool)
../../gcc-5.3.0/gcc/fortran/trans-expr.c:1052
0x6d6fec gfc_trans_allocate(gfc_code*)
../../gcc-5.3.0/gcc/fortran/trans-stmt.c:5630
0x678bd7 trans_code
../../gcc-5.3.0/gcc/fortran/trans.c:1820
0x6995c4 gfc_generate_function_code(gfc_namespace*)
../../gcc-5.3.0/gcc/fortran/trans-decl.c:5851
0x67a1b9 gfc_generate_module_code(gfc_namespace*)
../../gcc-5.3.0/gcc/fortran/trans.c:2036
0x635118 translate_all_program_units
../../gcc-5.3.0/gcc/fortran/parse.c:5330
0x635118 gfc_parse_file()
../../gcc-5.3.0/gcc/fortran/parse.c:5540
0x674dd5 gfc_be_parse_file
../../gcc-5.3.0/gcc/fortran/f95-lang.c:229
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/70370] ICE in execute_todo, at passes.c:2003 when using __real__ or __imag__ as lvalue in asm

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #9 from Richard Biener  ---
Fixed for GCC 6.

[Bug middle-end/70370] ICE in execute_todo, at passes.c:2003 when using __real__ or __imag__ as lvalue in asm

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Author: rguenth
Date: Thu Mar 24 12:19:56 2016
New Revision: 234453

URL: https://gcc.gnu.org/viewcvs?rev=234453&root=gcc&view=rev
Log:
2016-03-24  Richard Biener  

PR middle-end/70370
* gimplify.c (gimplify_asm_expr): Handle !allows_mem outputs
with register bases.

* gcc.dg/torture/pr70370.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr70370.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/70395] [C++11] Error when initializing array of non-copyable non-trivial type in constructor initializer list

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Probably a dup of PR 63707

[Bug c++/70393] [5/6 Regression] Miscompilation: missing constructor call for static object

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-24
  Known to work||4.9.3
Summary|Miscompilation: missing |[5/6 Regression]
   |constructor call for static |Miscompilation: missing
   |object  |constructor call for static
   ||object
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
ubsan prints lots of errors confirming that the vptr is not setup up correctly.

[Bug tree-optimization/70396] ICE on valid code at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (in immed_wide_int_const, at emit-rtl.c:606)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-24
  Component|rtl-optimization|tree-optimization
 Ever confirmed|0   |1

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

604   /* Allow truncation but not extension since we do not know if the
605  number is signed or unsigned.  */
606   gcc_assert (prec <= v.get_precision ());
607
608   if (len < 2 || prec <= HOST_BITS_PER_WIDE_INT)
609 return gen_int_mode (v.elt (0), mode);
610
(gdb) p prec
$1 = 8
(gdb) p mode
$2 = QImode
(gdb) p v.get_precision ()
$3 = 3

we indeed have

  constant 8>
unit size  constant 1>
align 8 symtab 0 alias set 2 canonical type 0x7698b2a0 precision 3 min
 max >
$7 = void

constants in the VECTOR_CST we expand and it has a vector type with
bit-precision element type.

[Bug tree-optimization/70396] ICE on valid code at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (in immed_wide_int_const, at emit-rtl.c:606)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
  /* Invariant comparison.  */
  if (!vectype)
{
  vectype = build_vector_type (TREE_TYPE (rhs1), nunits);
  if (tree_to_shwi (TYPE_SIZE_UNIT (vectype)) != current_vector_size)
return false;

it should _always_ use get_vectype_for_scalar_type

[Bug rtl-optimization/70398] New: [6 Regression] gcc.dg/vect/slp-multitypes-9.c FAILs with -fno-tree-loop-optimize -fno-tree-ter

[zsojka at seznam dot cz]

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

Bug ID: 70398
   Summary: [6 Regression] gcc.dg/vect/slp-multitypes-9.c FAILs
with -fno-tree-loop-optimize -fno-tree-ter
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
Target: aarch64-unknown-linux-gnu

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

Output (qemu userspace emulation):
$ aarch64-unknown-linux-gnu gcc -O -fno-tree-loop-optimize -fno-tree-ter
-static testcase.c
$ ./a.out 
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault

Crash is at:
Dump of assembler code for function main:
   0x00400ac8 <+0>: mov w2, #0x0// #0
   0x00400acc <+4>: adrpx4, 0x49
   0x00400ad0 <+8>: add x4, x4, #0x10
   0x00400ad4 <+12>:adrpx3, 0x493000 
   0x00400ad8 <+16>:add x3, x3, #0x530
   0x00400adc <+20>:lsl w0, w2, #1
=> 0x00400ae0 <+24>:ldrbw1, [x4,x5]
   0x00400ae4 <+28>:add w1, w1, #0x1
   0x00400ae8 <+32>:strbw1, [x3,w0,sxtw]

x5 is never initialised.

.ira has:
(insn 8 7 11 3 (set (reg:SI 74 [ _5 ])
(ashift:SI (reg/v:SI 82 [ i ])
(const_int 1 [0x1]))) testcase.c:13 636
{*aarch64_ashl_sisd_or_int_si3}
 (nil))
(note 11 8 12 3 NOTE_INSN_DELETED)
(insn 12 11 13 3 (set (reg:SI 75 [ _6 ])
(mem:SI (plus:DI (sign_extract:DI (mult:DI (subreg:DI (reg:SI 74 [ _5
]) 0)
(const_int 4 [0x4]))
(const_int 34 [0x22])
(const_int 0 [0]))
(reg/f:DI 102)) [1 in S4 A64])) testcase.c:13 49
{*movsi_aarch64}
 (expr_list:REG_EQUIV (mem:SI (plus:DI (sign_extract:DI (mult:DI (subreg:DI
(reg:SI 74 [ _5 ]) 0)
(const_int 4 [0x4]))
(const_int 34 [0x22])
(const_int 0 [0]))
(reg/f:DI 102)) [1 in S4 A64])
(nil)))
(insn 13 12 14 3 (set (reg:SI 76 [ _7 ])
(zero_extend:SI (subreg:QI (reg:SI 75 [ _6 ]) 0))) testcase.c:13 90
{*zero_extendqisi2_aarch64}
 (expr_list:REG_DEAD (reg:SI 75 [ _6 ])
(nil)))

but .reload has:
(insn 8 7 11 3 (set (reg:SI 0 x0 [orig:74 _5 ] [74])
(ashift:SI (reg/v:SI 2 x2 [orig:82 i ] [82])
(const_int 1 [0x1]))) testcase.c:13 636
{*aarch64_ashl_sisd_or_int_si3}
 (nil))
(note 11 8 12 3 NOTE_INSN_DELETED)
(note 12 11 13 3 NOTE_INSN_DELETED)
(insn 13 12 14 3 (set (reg:SI 1 x1 [orig:76 _7 ] [76])
(zero_extend:SI (mem:QI (plus:DI (reg/f:DI 4 x4 [102])
(reg:DI 5 x5 [139])) [1 in S1 A64]))) testcase.c:13 90
{*zero_extendqisi2_aarch64}
 (nil))


.ira might be correct, but .reload is wrong. Insn 12 is deleted without any
replacement (and it turns out, the same happens with insn 25)


@@ -23,12 +23,14 @@
 .L2:
.loc 1 13 0 is_stmt 0 discriminator 3
lsl w0, w2, 1
-   ldrbw1, [x4, x5]
+   lsl w5, w0, 2
+   ldrbw1, [x4, w5, sxtw]
add w1, w1, 1
strbw1, [x3, w0, sxtw]
.loc 1 14 0 is_stmt 1 discriminator 3
add w0, w0, 1
-   ldrbw1, [x4, x6]
+   lsl w6, w0, 2
+   ldrbw1, [x4, w6, sxtw]
add w1, w1, 2
strbw1, [x3, w0, sxtw]
.loc 1 11 0 discriminator 3


fixes the asm.


Tested revisions:
trunk r234405 - FAIL
5-branch r234375 - OK

[Bug c++/70395] [C++11] Error when initializing array of non-copyable non-trivial type in constructor initializer list

[mosra at centrum dot cz]

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

--- Comment #2 from Vladimír Vondruš  ---
Forgot to add that if I default the move constructor/assignment, it also
compiles fine (as the error message suggests).

[Bug c++/70393] [5/6 Regression] Miscompilation: missing constructor call for static object

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Started with r217664.

[Bug hsa/70394] HSA: kernel dispatch packet mechanism uses uninitialized memory

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Fixed.

[Bug rtl-optimization/70398] [6 Regression] gcc.dg/vect/slp-multitypes-9.c FAILs with -fno-tree-loop-optimize -fno-tree-ter

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ra
   Target Milestone|--- |6.0

[Bug c++/70353] [5/6 regression] ICE on __PRETTY_FUNCTION__ in a constexpr function

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #10 from Patrick Palka  ---
It's a hack, but we could pull the STRING_CST out from the artificial VAR_DECL
during constexpr evaluation to avoid referring to __func__'s symbol.

--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -3354,6 +3354,11 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx,
tree t,

 case VAR_DECL:
 case CONST_DECL:
+  if (VAR_P (t)
+ && DECL_ARTIFICIAL (t)
+ && TREE_STATIC (t)
+ && TREE_CODE (DECL_INITIAL (t)) == STRING_CST)
+   return DECL_INITIAL (t);
   /* We used to not check lval for CONST_DECL, but darwin.c uses
 CONST_DECL for aggregate constants.  */
   if (lval)

[Bug rtl-optimization/70398] [6 Regression] gcc.dg/vect/slp-multitypes-9.c FAILs with -fno-tree-loop-optimize -fno-tree-ter

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-24
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug c/70297] [5/6 Regression] GCC Segfaults when using -g3

[mpolacek at gcc dot gnu.org]

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

--- Comment #9 from Marek Polacek  ---
Patch posted .

[Bug tree-optimization/70396] ICE on valid code at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (in immed_wide_int_const, at emit-rtl.c:606)

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Thu Mar 24 14:07:42 2016
New Revision: 234455

URL: https://gcc.gnu.org/viewcvs?rev=234455&root=gcc&view=rev
Log:
2016-03-24  Richard Biener  

PR tree-optimization/70396
* tree-vect-stmts.c (vectorizable_comparison): Use
get_vectype_for_scalar_type.

* gcc.dg/torture/pr70396.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr70396.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-stmts.c

[Bug tree-optimization/70396] ICE on valid code at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (in immed_wide_int_const, at emit-rtl.c:606)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format

[jvdelisle at gcc dot gnu.org]

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

--- Comment #12 from Jerry DeLisle  ---
(In reply to Dominique d'Humieres from comment #11)
> > Created attachment 38075 [details]
> > A patch for testing
> 
> With the patch and using the test attached to comment 5 with y = 1.0 and
> d=8, I get the following output
> 
> -8pf18.8 y=0.000.
> -7pf18.8 y=0.00.0
... snip ...
> which is wrong for P<=-2.

OK great, this is related to the conditions for the shift, thanks.  I will keep
at it.

[Bug hsa/70399] HSA: Wrong emission of st_align(4)_u8 HSAIL insn

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Created attachment 38080
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38080&action=edit
test case

[Bug hsa/70399] New: HSA: Wrong emission of st_align(4)_u8 HSAIL insn

[marxin at gcc dot gnu.org]

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

Bug ID: 70399
   Summary: HSA:  Wrong emission of st_align(4)_u8 HSAIL insn
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: hsa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jamborm at gcc dot gnu.org
  Target Milestone: ---

Hello.

Attached source file is miscompiled with HSA back-end:

$ HSAILasm -disassemble phsa-temp/program-0.brig 
$ HSAILasm phsa-temp/program-0.hsail

>   st_align(4)_u8  9, 0, 0, 0, [$d0+8];
>  ^
input(10,20): Invalid operand 1, expected: an address

Martin

[Bug c/70400] New: GCC compiles a return statement with an expression in a void function (illegal under C90 6.6.6.4) with -std=c90 -pedantic

[ryao at gentoo dot org]

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

Bug ID: 70400
   Summary: GCC compiles a return statement with an expression in
a void function (illegal under C90 6.6.6.4) with
-std=c90 -pedantic
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryao at gentoo dot org
  Target Milestone: ---

Created attachment 38081
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38081&action=edit
Test case where GCC allows a void function to return an expression

ISO C90 6.6.6.4 says that "A return statement with an expression shall not
appear in a function whose return type is void."

Both Sun Studio and the TenDRA make this a build failure as the specification
requires while Clang does what GCC does. The sudo project had a bug filed
agaisnt it because of Sun Studio:

https://bugzilla.sudo.ws/show_bug.cgi?id=727

GCC will only emit a warning when -pendantic is specified and adding -std=c90
does not change the behavior to a warning. The documentation for -pedantic
clearly states that things disallowed by the specification emit errors:

https://gcc.gnu.org/onlinedocs/gcc-4.9.3/gcc/Warning-Options.html

This probably should be a warning even without `-pendantic`.

[Bug ipa/70366] [6 Regression] chromium fails to build with LTO due to segfault in ipa-inline-transform.c:inline_call

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #5 from prathamesh3492 at gcc dot gnu.org ---
(In reply to prathamesh3492 from comment #4)
> Created attachment 38076 [details]
> patch
> 
> Hi,
> The attached patch suggested by Richard fixes the chromium build.
> It passes bootstrap+test on x86_64-unknown-linux-gnu
> and cross-tested on arm*-*-* and aarch64*-*-*.
> The patch however regresses libstdc++ for arm-none-eabi:
> http://people.linaro.org/~christophe.lyon/cross-validation/gcc-test-patches/
> 234391-70366/arm-none-eabi/diff-libstdc++-rh60-arm-none-eabi-arm-cortex-a9-
> default.txt
> Looking at the logs there isn't much information:
> compiler exited with status 1
> FAIL: 25_algorithms/partial_sort/moveable.cc (test for excess errors)
> Excess errors:
> exit status is 1
> WARNING: 25_algorithms/partial_sort/moveable.cc compilation failed to
> produce executable
> The complete log is at:
> http://people.linaro.org/~christophe.lyon/cross-validation/gcc-test-patches/
> 234391-70366/arm-none-eabi/libstdc++-rh60-arm-none-eabi-arm-cortex-a9-
> default.log.xz
Hi,
The failure was probably due to validation issues and not the patch.
Re-running the validation didn't show up any regressions on arm*-*-*
and aarch64*-*-*.
I posted the patch upstream:
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg01376.html

Thanks,
Prathamesh
> 
> I don't have much ideas on how to proceed.
> I am trying to reduce the test-case, and reproduce the above regression
> locally and will get back if I find more information.
> 
> Thanks,
> Prathamesh

[Bug c/70400] GCC compiles a return statement with an expression in a void function (illegal under C90 6.6.6.4) with -std=c90 -pedantic

[sch...@linux-m68k.org]

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

--- Comment #1 from Andreas Schwab  ---
Use -pedantic-errors to turn pedantic diagnostics into errors.

[Bug c/70400] GCC compiles a return statement with an expression in a void function (illegal under C90 6.6.6.4) with -std=c90 -pedantic

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Richard Yao from comment #0)
> GCC will only emit a warning when -pendantic is specified and adding
> -std=c90 does not change the behavior to a warning. The documentation for
> -pedantic clearly states that things disallowed by the specification emit
> errors:
> 
> https://gcc.gnu.org/onlinedocs/gcc-4.9.3/gcc/Warning-Options.html

No, it clearly states that it produces warnings (I count six mentions of
warnings and none of errors). And it clearly says -pedantic-errors means you
get errors not warnings.

[Bug c++/70393] [5/6 Regression] Miscompilation: missing constructor call for static object

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Yeah, that was with -std=c++0x.  With -std=c++1y it started one revision
earlier (r217663).

[Bug c++/70393] [5/6 Regression] Miscompilation: missing constructor call for static object

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #3 from Patrick Palka  ---
(In reply to Jakub Jelinek from comment #2)
> Started with r217664.

I assume that's with -std=c++11?  I wonder which commit introduced the
regression when the test case is compiled with -std=c++14.

[Bug c++/70401] New: [c++1z on mingw]compile variadic template failed

[xiangli_zhao at hotmail dot com]

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

Bug ID: 70401
   Summary: [c++1z on mingw]compile variadic template failed
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xiangli_zhao at hotmail dot com
  Target Milestone: ---

Created attachment 38082
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38082&action=edit
a variadic template class fizzbuzz in attached.

mingw version gcc download from 
http://120.52.73.49/tenet.dl.sourceforge.net/project/mingw-w64/Toolchains%20targetting%20Win64/Personal%20Builds/dongsheng-daily/6.x/gcc-6-win64_6.0.0-20160318.7z

when I compile variadic template aa.cpp （see attached), 
g++ -std=c++1z aa.cpp -o aa.exe
I got an error said

Internal compiler error: Error reporting routines re-entered.
libbacktrace could not find executable to open

Thanks a lot

[Bug c/70400] GCC compiles a return statement with an expression in a void function (illegal under C90 6.6.6.4) with -std=c90 -pedantic

[ryao at gentoo dot org]

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

--- Comment #4 from Richard Yao  ---
How would GCC "reject all programs" without emitting an error? If there is some
other way, it is not being done as GCC emits assembly that assembles and links
without a problem. Rejecting the program should not allow things to go so far.
If `-pedantic` does not cause programs to be rejected under any circumstance,
then the documentation is wrong.

[Bug target/70216] [SH] Implement __builtin_trap

[olegendo at gcc dot gnu.org]

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

--- Comment #6 from Oleg Endo  ---
Created attachment 38083
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38083&action=edit
Proposed patch

This patch adds two new target options:
  -msh4-trapa-sleep-bug
  -mbuiltin-trap=

and two configure options:
  --with-builtin-trap
  --enable-sh4-trapa-sleep-bug / --disable-sh4-trapa-sleep-bug

On sh*-linux it should configure itself to use -mbuiltin-trap=trapa,imm=84 by
default.

I'm not sure if the -msh4-trapa-sleep-bug should be enabled by default on
sh*-linux to always emit the workaround insn sequence (trap + 5x or r0,r0).  If
--enable-sh4-trapa-sleep-bug is not specified, it will only be enabled when
compiling code for SH4.

[Bug c/70400] GCC compiles a return statement with an expression in a void function (illegal under C90 6.6.6.4) with -std=c90 -pedantic

[ryao at gentoo dot org]

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

Richard Yao  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Yao  ---
It says "reject all programs that use forbidden extensions, and some other
programs that do not follow ISO C and ISO C++." This is C++ extension as far as
ISO C is concerned:

"A return statement with an operand of type void shall be used only in a
function whose return type is cv void."

http://eel.is/c++draft/stmt.return

[Bug target/70359] [6 Regression] Code size increase for ARM compared to gcc-5.3.0

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||kugan at gcc dot gnu.org,
   ||segher at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
I see multiple points of the increases:
r224048 added 4 bytes.
r224995 added 8 bytes.
r228318 added 4 bytes.

Perhaps the middle one could change from
(if (single_use (@2)
 || (TREE_CODE (@1) == INTEGER_CST && TREE_CODE (@3) == INTEGER_CST))
to
(if (single_use (@2)
 || (!optimize_size && TREE_CODE (@1) == INTEGER_CST && TREE_CODE (@3) ==
INTEGER_CST))
(or some optimize*for_speed*)?
CCing authors of the other commits.  That said, complaining about size
regressions generally should be only if it (significantly) increases sizes of
some larger codebases (CSiBE, size of some large app, ...), when looking at a
single function only, there will be always improvements and degradations, the
compiler is changing.

[Bug c++/70029] [6 Regression] ICE with C++11 and -flto

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
The problem is that decl_attributes uses build_type_attribute_qual_variant,
which uses build_qualified_type, which doesn't understand C++ type variants and
blithely returns an attribute-qualified type which isn't ref-qualified like the
original type.  One way to address this would be to add a langhook for
check_qualified_type.  Otherwise the front end would need to stop representing
exception specifications and ref-qualifiers as type variants.

[Bug c++/62212] [4.9/5/6 Regression] ICE compiling template function with array reference parameter whose size depends on a template parameter

[ppalka at gcc dot gnu.org]

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

--- Comment #5 from Patrick Palka  ---
Author: ppalka
Date: Thu Mar 24 15:59:53 2016
New Revision: 234457

URL: https://gcc.gnu.org/viewcvs?rev=234457&root=gcc&view=rev
Log:
Fix PR c++/62212 (ICE during mangling of array type)

gcc/cp/ChangeLog:

PR c++/62212
* tree.c (build_cplus_array_type): Determine type-dependentess
with uses_template_parms instead of with dependent_type_p.

gcc/testsuite/ChangeLog:

PR c++/62212
* g++.dg/template/mangle2.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/template/mangle2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/62212] [4.9/5 Regression] ICE compiling template function with array reference parameter whose size depends on a template parameter

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

Summary|[4.9/5/6 Regression] ICE|[4.9/5 Regression] ICE
   |compiling template function |compiling template function
   |with array reference|with array reference
   |parameter whose size|parameter whose size
   |depends on a template   |depends on a template
   |parameter   |parameter

--- Comment #6 from Patrick Palka  ---
Fixed for GCC 6 at least.

[Bug rtl-optimization/70164] [6 Regression] Code/performance regression due to poor register allocation on Cortex-M0

[law at redhat dot com]

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

--- Comment #14 from Jeffrey A. Law  ---
Some further notes.

I was looking at what the impact would be if we just stopped recording the
problematical equivalences in CSE, both to see if the equivalences are useful
at all, and if they are, to get a sense of when (which might perhaps lead to
some useful conditions for recording them).  I was quite surprised at how much
of a difference in the resulting code generation these equivalences make.

One of the things that is emerging is that these equivalences are useful when
the copy propagation they enable allows one operand to die at the comparison
when it didn't die before.  That in turn may allow creation of REG_EQUIV note
on the insn that initializes the dying register.  Which then allows
substitution of the equivalent memory for the register in the comparison.

We still have the same number of memory references, but we use one less
register in that case and have one less instruction.

We obviously don't have that level of insight during CSE.  But given uses/sets
DF info, we can get a lot of the way there.

Anyway, just wanted to record some of my findings.  I'm putting this down for
now as it's not likely to be a gcc-6 kind of change.

[Bug hsa/70402] New: HSA: SBR instruction can be undefined

[marxin at gcc dot gnu.org]

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

Bug ID: 70402
   Summary: HSA: SBR instruction can be undefined
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: hsa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jamborm at gcc dot gnu.org
  Target Milestone: ---

As reported here:
https://github.com/HSAFoundation/gccbrig/issues/3

current HSA back-end can produce a SBR isntruction with smaller or equal number
of labels than an index value.

Martin

[Bug c++/70323] [6 regression] missing error on integer overflow in constexpr function result converted to bool

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug middle-end/70307] [6 Regression] ICE: in gimplify_expr, at gimplify.c:10915 on valid code

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
I think we need to teach c_fully_fold how to fold VEC_COND_EXPR.  Until r229128
this wasn't necessary as the C FE never saw any VEC_COND_EXPRs.  But since that
revision we create a VEC_COND_EXPR when building a vector comparison.

[Bug target/70359] [6 Regression] Code size increase for ARM compared to gcc-5.3.0

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug libstdc++/69332] [6 Regression] FAIL: libstdc++-prettyprinters/libfundts.cc print ab

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||law at redhat dot com

[Bug target/64971] [5/6 Regression] gcc.c-torture/compile/pr37433.c ICEs with -mabi=ilp32

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/70403] New: A null pointer check removed with -O2 even with -fno-delete-null-pointers-checks

[thadula at ciena dot com]

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

Bug ID: 70403
   Summary: A null pointer check removed with -O2 even with
-fno-delete-null-pointers-checks
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thadula at ciena dot com
  Target Milestone: ---

g++, powerpc-e500-linux-gnuspe-g++, version 4.9.2
compiled with -O2 and -fno-delete-null-pointers-checks

Code (look for ==> to mark the point in the code):


static const char* fnName = "NewLs::CpSelect - ";
tbr_t  tbrStart, tbrEnd, timediff;

tbrStart = tbrGet();

McId newCpId((McIdHandle)cpId);
McId newSelId((McIdHandle)selId);
McCpId*  pCpId= static_cast(&newCpId);
ComplexXCon* pXCon= NULL;
CtpCpBase*   pNewSel  = NULL;
ComplexXCon* pNewXCon = NULL;
UniCp*   pCp  = NULL;

rFailureReason = LS_SUCCESS;

if (!pCpId)
{
MEMORY_LOG_MCHECK (getSwitchCoreMemoryLog(), pCpId, NULL,
   "!!!ERROR!!!: " << fnName << "null CP id");
return false;
}

// Find the CP object
pCp = FindCpFromHashList(*pCpId);
if (!pCp)
{
LOGIC_SWITCH_ERRLOG_PRINTF (getSwitchCoreMemoryLog(),
"%sCannot find CP 0x%llX", fnName, cpId);
rFailureReason = END_POINT_NOT_FOUND;
return false;
}

McCpProtectionApp protApp = pCp->GetProtApp();

if (rxProtApp != protApp)
{
.
.
.
return false;
}

pXCon = pCp->GetXCon();
if (!pXCon)
{
char mcBuf[ 64 ];

pCpId->toString (mcBuf, sizeof (mcBuf));
LOGIC_SWITCH_ERRLOG_PRINTF (getSwitchCoreMemoryLog(),
"%sCannot find XCon for CP: %s", fnName, mcBuf);
rFailureReason = CROSS_CONNECT_NOT_FOUND;
return false;
}

if (!squelch)
{
if (newSelId == McId::InvalidId)
{
rFailureReason = BAD_END_POINT_ID;
return false;
}

//
// Find the CTP or CP (if it exists) and verify that it belongs to
pXCon
//
if (newSelId.IsCtpId())
{
McCtpId ctpId(newSelId);
pNewSel = FindCtpFromHashList(ctpId);
}
else if (newSelId.IsCpId())
{
McCpId newCpId((McCpIdHandle) newSelId.GetId());
pNewSel = FindCpFromHashList(newCpId);
}
==> if (pNewSel)
pNewXCon = pNewSel->GetXCon();
}
else
{
char mcBuf[ 64 ];

pCpId->toString (mcBuf, sizeof (mcBuf));
getSwitchCoreMemoryLog()->PrintRamLog ("%sSetting %s to be squelched.",
fnName, mcBuf);
}

if (squelch || (pNewSel && pNewXCon == pXCon))
{
if (pCp->GetSelectedCtpCp() == pNewSel
|| (isDefaultFromCac && pCp->GetDefaultSelector() == pNewSel))
{
.
.
.
return false;   // already selected
}

// Update current selector on CP.
pCp->SetSelectedCtpCp(pNewSel);
.
.
.
}


Segmentation fault:

Program terminated with signal 11, Segmentation fault.
#0  CtpCpBase::GetXCon (this=this@entry=0x0) at
src/software/centaur/apps/core/txn/Switching/NewLS/CtpCpBase.cpp:79
79  if( mpXCon && mpXCon->IsRemoteTAP() && !mpXCon->IsRemoteTAPParent()
)
(gdb) bt
#0  CtpCpBase::GetXCon (this=this@entry=0x0) at
src/software/centaur/apps/core/txn/Switching/NewLS/CtpCpBase.cpp:79
#1  0x1149b610 in NewLogicalSwitch::CpSelect (this=0x671d0038, cpId=, selId=, 
rFailureReason=@0x7019e6f0: LS_SUCCESS,
rxProtApp=rxProtApp@entry=MC_CP_PROTECTION_APP_UPSR_SNCP, squelch=true, 
isDefaultFromCac=isDefaultFromCac@entry=false) at
src/software/centaur/apps/core/txn/Switching/NewLS/NewLogicalSwitch.cpp:8221
#2  0x1149bfb4 in NewLogicalSwitch::CpSelectTest (this=,
cpId=cpId@entry=2, newSelId=)
at
src/software/centaur/apps/core/txn/Switching/NewLS/NewLogicalSwitch.cpp:5869
#3  0x114c704c in NewLsDcraft::ImplementMsg (this=0x6df9b338, pObj=0x836ea7e8)
at src/software/centaur/apps/core/txn/Switching/NewLS/NewLsDcraft.cpp:711
#4  0x11cafe6c in Actor::Run (this=0x6df9b338) at
src/generic/component/Actor/Actor.cpp:929
#5  0x11bdff9c in RunnableTask::TaskFunction (this=0x6df9c970) at
src/generic/component/UtilProg/RunnableTask.cpp:35
#6  0x11593080 in LnTask::TaskEntry (pThis=0x6df9c970) at
src/generic/component/Osencap/linux/LnTask.cpp:627
#7  0x0f1ecc04 in ?? ()
#8  0x09e4a5b4 in ?? ()
(gdb) up
#1  0x1149b610 in NewLogicalSwitch::CpSelect (this=0x671d0038, cpId=, selId=, 
rFailureReason=@0x7019e6f0: LS_SUCCESS,
rxProtApp=rxProtApp@entry=MC_CP_PROTECTION_APP_UPSR_SNCP, squelch=true, 
isDefaultFromCac=isDefaultFromCac@entry=false) at
src/software/centaur/apps/core/txn/Swi

[Bug middle-end/69845] [4.9/5/6 Regression] Expression getting incorrectly optimized after being rewritten by compiler

[law at gcc dot gnu.org]

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

--- Comment #8 from Jeffrey A. Law  ---
Author: law
Date: Thu Mar 24 17:52:11 2016
New Revision: 234462

URL: https://gcc.gnu.org/viewcvs?rev=234462&root=gcc&view=rev
Log:
2016-03-24  Richard Henderson  

PR middle-end/69845
* fold-const.c (extract_muldiv_1): Correct test for multiplication
overflow.

PR middle-end/69845
* gcc.dg/tree-ssa/pr69845-1.c: New test.
* gcc.dg/tree-ssa/pr69845-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr69845-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr69845-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/70403] A null pointer check removed with -O2 even with -fno-delete-null-pointers-checks

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-03-24
 Ever confirmed|0   |1
   Severity|major   |normal

--- Comment #1 from Jonathan Wakely  ---
Please provide a complete testcase, and/or preprocessed source.

https://gcc.gnu.org/bugs/

[Bug c++/70323] [6 regression] missing error on integer overflow in constexpr function result converted to bool

[jason at gcc dot gnu.org]

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

--- Comment #10 from Jason Merrill  ---
Author: jason
Date: Thu Mar 24 17:59:58 2016
New Revision: 234463

URL: https://gcc.gnu.org/viewcvs?rev=234463&root=gcc&view=rev
Log:
PR c++/70323

* constexpr.c (cxx_eval_call_expression): Don't cache result if
*overflow_p.

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

[Bug c++/70323] [6 regression] missing error on integer overflow in constexpr function result converted to bool

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #11 from Jason Merrill  ---
Fixed.

[Bug c++/55004] [meta-bug] constexpr issues

[jason at gcc dot gnu.org]

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

Bug 70323 Summary: [6 regression] missing error on integer overflow in 
constexpr function result converted to bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70323

   What|Removed |Added

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

[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format

[dominiq at lps dot ens.fr]

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

--- Comment #13 from Dominique d'Humieres  ---
Created attachment 38084
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38084&action=edit
A new patch for testing

With y = 1.0 and d=8 I now get

-8pf18.8 y=0.0001
-7pf18.8 y=0.0010
-6pf18.8 y=0.0100
-5pf18.8 y=0.1000
-4pf18.8 y=0.0001
-3pf18.8 y=0.0010
-2pf18.8 y=0.0100
-1pf18.8 y=0.1000
0pf18.8 y=1.
1pf18.8 y=   10.
2pf18.8 y=  100.
3pf18.8 y= 1000.
4pf18.8 y=1.
5pf18.8 y=   10.
6pf18.8 y=  100.
7pf18.8 y= 1000.

Note that without the addition

@@ -70,6 +70,10 @@ determine_precision (st_parameter_dt * d
   switch (f->format)
 {
 case FMT_F:
+  precision += dtp->u.p.scale_factor;
+  if (precision < f->u.real.d)
+   precision = f->u.real.d;
+  break;
 case FMT_G:
   precision += dtp->u.p.scale_factor;
   break;

I get

-8pf18.8 y=0.
-7pf18.8 y=0.
-6pf18.8 y=0.
-5pf18.8 y=0.
-4pf18.8 y=0.0001
-3pf18.8 y=0.0010
-2pf18.8 y=0.0100
-1pf18.8 y=0.1000
0pf18.8 y=1.
1pf18.8 y=   10.
2pf18.8 y=  100.
3pf18.8 y= 1000.
4pf18.8 y=1.
5pf18.8 y=   10.
6pf18.8 y=  100.
7pf18.8 y= 1000.

[Bug rtl-optimization/68695] [6 Regression] Performance regression related to ssa patch / ifcvt

[vmakarov at gcc dot gnu.org]

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

--- Comment #23 from Vladimir Makarov  ---
(In reply to Jakub Jelinek from comment #22)
> Going back to variants of the original testcase:
> int
> foo (int x, int y, int a)
> {
>   int i = x;
>   int j = y;
> #ifdef EX1
>   if (__builtin_expect (x > y, 1))
> #elif defined EX0
>   if (__builtin_expect (x > y, 0))
> #else
>   if (x > y)
> #endif
> {
>   i = a;
>   j = i;
> }
>   return i * j;
> }
> 
> at least for the -DEX1 case I'd think it is reasonable to assign one of i or
> j to the register holding argument a (%r4), because that will for the common
> case need one fewer register move.  But, there is one further constraint. 
> The multiplication wants the result to live in %r2, because then it can
> avoid a move, and the multiplication is commutative two operand one, so one
> of the operands needs to match the output.  Thus, from this the reasonable
> disposition choices are either i in %r2 and j in %r3 (this is especially
> desirable if the if is unlikely, i.e. -DEX0 case), or perhaps i in %r2 and j
> in %r4 (while this will need if/then/else rather than if/then only, it would
> use one fewer move in the expected likely block).
> The problem is that IRA chooses i in %r4 and j in %r3, so there are 2 moves
> even in the fast path (the i = a assignment is a nop, but j = i is needed,
> and then later on extra reload move is added, because pseudo 67 disposition
> (result of mulsi3) is properly in %r2 and if one argument is %r4 and another
> one %r3, it needs to copy one to %r2.
> 
> Vlad, can you please have a look?

I investigated it.  I don't think that the desired results can be achieved
without changing existing heuristics.  Changing the existing heuristics is a
big job.  Besides rewriting code, it requires a lot of benchmarking.

Also part of problem can be solved if we use conflicts built using value
numbering instead of live-range analysis.  I don't know a RA whose conflict
graph is based on value numbering.

What I don't like is that p67 originally got r4 and then it was changed to r2
in improve_allocation.  Fixing that will improve the code but not for all
possible combinations (EX1, EX0 etc).  In any case I'll continue my work on the
PR.

[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
Summary|[5/6 Regression] 16%|[5 Regression] 16%
   |tramp3d-v4.cpp compile time |tramp3d-v4.cpp compile time
   |regression  |regression

--- Comment #64 from Jeffrey A. Law  ---
Removing gcc-6 regression tag per c#63.  Keeping gcc-5 regression tag.

[Bug libstdc++/69945] Provide an equivalent of __libc_freeres to release emergency EH pool memory

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Thu Mar 24 18:13:40 2016
New Revision: 234465

URL: https://gcc.gnu.org/viewcvs?rev=234465&root=gcc&view=rev
Log:
libstdc++/69945 Add __gnu_cxx::__freeres hook

PR libstdc++/69945
* config/abi/pre/gnu.ver: Add new symbol.
* libsupc++/eh_alloc.cc (__gnu_cxx::__freeres): Define.
* testsuite/18_support/free_eh_pool.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/18_support/free_eh_pool.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config/abi/pre/gnu.ver
trunk/libstdc++-v3/libsupc++/eh_alloc.cc

[Bug c++/70386] [6 Regression] ICE with -Wall on valid code on x86_64-linux-gnu in verify_ctor_sanity, at cp/constexpr.c:2232

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/70403] A null pointer check removed with -O2 even with -fno-delete-null-pointers-checks

[thadula at ciena dot com]

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

--- Comment #2 from Hadula, Tomasz  ---
The whole thing is huge (compiles for almost 2 hours).
The problem is that when I attempt to make it smaller in form of a simple,
standalone app, the problem doesn't happen anymore.

I've been searching for something that dereferences pNewSel or some sort of
memcpy or memmove, but I can't find it.

Those are 2 methods used to obtain pNewSel. Hashlist is based on RogueWave
hashset:

UniCtp*
NewLogicalSwitch::FindCtpFromHashList (McCtpId ctpId)
{
UniCtp* pDummyCtp = mUniCtpPool.Get();

if (!pDummyCtp)
{
getSwitchCoreMemoryLog()->PrintRamLog (
"NewLogicalSwitch::FindCtpFromHashList: no more room in the CTP
pool");
return NULL;
}

pDummyCtp->CtpCpBase::Init(ctpId);   // call base class method; need
CtpCpBase:: qualifier because UniCtp redefines Init(), hiding the base class
version
UniCtp* pCtp = mCtpHashList.find(pDummyCtp);
pDummyCtp->Destroy();  // return to mempool

return pCtp;
}

UniCp*
NewLogicalSwitch::FindCpFromHashList (McCpId cpId)
{
// Note - The prot app is not used in the find process.
//Find just compares the ids of the two CPs.
//The prot app is not part of the id.
//We just needed to pass in a dummy prot app
//along with the real id to create the dummyCp.
//
TcmInfo dummyTcmInfo;
UniCp* pDummyCp, *pUniCp;

pDummyCp = mUniCpPool.Get();
if (!pDummyCp)
{
getSwitchCoreMemoryLog()->PrintRamLog (
   "NewLogicalSwitch::FindCpFromHashList: no more room in the CP
pool");
return NULL;
}

pDummyCp->Init(cpId, MC_CP_PROTECTION_APP_NONE,
MC_CP_PU_TYPE_NONE,
0, dummyTcmInfo, true, true, true, true, McId::InvalidId);


pUniCp = mCpHashList.find (pDummyCp);

// Return CP to MemPool
pDummyCp->Destroy();
return pUniCp;
}


Just a command line used to compile that particular source goes like this:

/usr/local/ciena/powerpc-e500-linux-gnuspe-20160316/bin/powerpc-e500-linux-gnuspe-g++
-Wp,-MD,/simdisk/thadula/oneos/branches/centaur/dev/main/build/centaur-cn5430/libNewLS.a/chassis/powerpc-e500/32/.NewLogicalSwitch.o.d,-MP
-g -pipe -O2 -fno-delete-null-pointer-checks -std=gnu++03 -Wall -Wextra
-Wno-unused-parameter -Wno-deprecated -Wno-unused-but-set-parameter
-Wno-unused-function -Wno-unused-parameter -fPIC
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/software/centaur/apps/core/txn/Switching/NewLS
-DCIENA_CTM -DCIENA_CENTAUR -DOSI_STACK_ENABLED -DCENTAUR_5430
-DCENTAUR_SPECIFIC -DWARM_RESTART
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/hardware/uio_ciena_hdpsm/lib/
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/hardware/uio_ciena_hdpsm/ko/
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/hardware/uio_ciena_hdsm/lib/
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/hardware/uio_ciena_hdsm/ko/
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/hardware/uio_ciena_sm/lib/
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/hardware/uio_ciena_sm/ko/
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/elf-utils
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/include
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/linxipc
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/log
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/onesies
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/subsys-elf
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/cad
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/compiler
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/ni/apps/apis
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/ni/apps/include
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/ni/apps/infrastructure
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/ni/apps/notifications
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/ni/apps/utilities
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/ntp
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/ni/nonbranched
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/ni/system/map
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/ni/system/shared
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/ni/system/shared/hal
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/ni/system/branding
-D_REENTRANT -DRW_MULTI_THREAD -DRW_POSIX_THREADS -DRWDEBUG
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/event_mgr
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/generic/osrp/osrputil
-iquote/simdisk/thadula/oneos/branches/centaur/dev/main/src/hardwa

[Bug c++/70393] [5/6 Regression] Miscompilation: missing constructor call for static object

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #5 from Nathan Sidwell  ---
We're turning 'ab's initializer into a static one (so the lack of a dynamic
initializer is a red herring).  But we're flubbing the form of that initializer
because the placement of AB's bases is not their declaration order.  B is
chosen as the primary base, so AB is laid out as:
AB size 24 align 8
  A @ 16
  B @ 0

The  emitted initializer is:
_ZL2ab:
.zero   16
.long   1  <-- A::a
.quad   _ZTV2AB+16
.quad   2  <-- B::element

(I modified the testcase so the NSDMIs are distinct non-zero values).  The 16
zero bytes appear to be skipping over the B sub-object to place A's
initializer.

We should be emitting something more like:

_ZL2ab:
.quad   _ZTV2AB+16
.quad   2  <--B::element
.long   1  <-- A::a
.zero   4  <-- tail padding

[Bug target/63890] [4.9/5/6 regression] Compiling trivial program with -O -p leads to misaligned stack

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #29 from Jeffrey A. Law  ---
I've been able to confirm this on an older mac here. I've got a baseline
bootstrap & test running and will test the patch from c#9 once the baseline is
complete.

[Bug target/70359] [6 Regression] Code size increase for ARM compared to gcc-5.3.0

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

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

--- Comment #6 from Fredrik Hederstierna 
 ---
Thanks for your analysis on this. One comment on this 'complaint', it's not
only about size - in my example the compiler uses 2 more regs push and pop, and
several more instructions, so I think causing performance regressions aswell? I
can file the 'complaints' as performance degradations next time if this is
better.

Actually this was derived from a larger code base analysis (CSiBE)

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

Where CSiBE problems was analysed, but this issue unfortunately got too fuzzy
where its hard to define an issue on almost 1000 files, the conclusion was then
to create separate smaller examples to work on, because the CSiBE overall
benchmark was hard to overview.

I understand its much focus on performance speed on GCC development, but I do
think that size really is important aswell since GCC is used very widely also
for typically ARM based embedded systems.

I will continue to try track size on CSiBE on
http://gcc.hederstierna.com/csibe, but please comment if you think size
regressions are non-wanted, I can try to focus more on issues that have both
performance speed and size components combined (I guess they often go hand in
hand.).

Thanks, BR, Fredrik

[Bug c++/70393] [5/6 Regression] Miscompilation: missing constructor call for static object

[nathan at gcc dot gnu.org]

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

--- Comment #6 from Nathan Sidwell  ---
Indeed, manually editing the assembly to such an initializer results in  a
working program.

The CONSTRUCTOR created for ab's  DECL_INITIAL has the correct things in it,
but in declaration  order.  I.e. it looks like:
IDX=field-for-A-base VAL=CONSTRUCTOR (...)
IDX=field-for-B-base VAL=CONSTRUCTOR (...)

I think CONSTRUCTOR_ELTs are expected to be in ascending placement order?

[Bug c++/70403] A null pointer check removed with -O2 even with -fno-delete-null-pointers-checks

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Hadula, Tomasz from comment #2)
> The whole thing is huge (compiles for almost 2 hours).
> The problem is that when I attempt to make it smaller in form of a simple,
> standalone app, the problem doesn't happen anymore.

So provide preprocessed source of just the one file, which will only take a few
seconds. That way someone can compile that file and inspect the generated code.
It doesn't need to produce a running program. Without it this report is not
useful.

[Bug c++/70403] A null pointer check removed with -O2 even with -fno-delete-null-pointers-checks

[thadula at ciena dot com]

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

--- Comment #4 from Hadula, Tomasz  ---
Created attachment 38085
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38085&action=edit
output from -fdump-tree-optimized

I attached dump from -fdump-tree-optimized for the affected source
(NewLogicalSwitch.cpp). Please look for ::CpSelect in it

[Bug c++/70386] [6 Regression] ICE with -Wall on valid code on x86_64-linux-gnu in verify_ctor_sanity, at cp/constexpr.c:2232

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Thu Mar 24 19:21:38 2016
New Revision: 234469

URL: https://gcc.gnu.org/viewcvs?rev=234469&root=gcc&view=rev
Log:
PR c++/70386

* constexpr.c (cxx_eval_bare_aggregate): Handle PMFs.

Added:
trunk/gcc/testsuite/g++.dg/expr/pmf-2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c

[Bug target/70404] New: pr71074.c fails on s390x

[vogt at linux dot vnet.ibm.com]

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

Bug ID: 70404
   Summary: pr71074.c fails on s390x
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vogt at linux dot vnet.ibm.com
CC: krebbel at gcc dot gnu.org
  Target Milestone: ---
  Host: s390x
Target: s390x

The new test case from #70174 triggers an ICE on s390x (svn rev 234414):

.../build/gcc/xgcc -B...//gcc/ .../gcc/testsuite/gcc.dg/pr70174.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -S -m64 -o pr70174.s
.../gcc/testsuite/gcc.dg/pr70174.c: In function 'foo':
.../gcc/testsuite/gcc.dg/pr70174.c:10:7: warning: assignment makes integer from
pointer without a cast [-Wint-conversion]
/home/vogt/src/git/gcc/gcc/testsuite/gcc.dg/pr70174.c:11:1: error:
unrecognizab\
le insn:
(insn 9 8 10 2 (set (zero_extract:DI (subreg:DI (reg:QI 66) 0)
(const_int 4 [0x4])
(const_int 56 [0x38]))
(symbol_ref:DI ("foo") [flags 0x3] )
.../gcc/testsuite/gcc.dg/pr70174.c:10 -1
 (nil))
.../gcc/testsuite/gcc.dg/pr70174.c:11:1: internal compiler error: in
extract_insn, at recog.c:2287
0x805b40dd _fatal_insn(char const*, rtx_def const*, char const*, int, char
cons\
t*)
.../gcc/rtl-error.c:108
0x805b411d _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
.../gcc/rtl-error.c:116
0x80582a2d extract_insn(rtx_insn*)
.../gcc/recog.c:2287
0x803b6af3 instantiate_virtual_regs_in_insn
.../gcc/function.c:1582
0x803b6af3 instantiate_virtual_regs
.../gcc/function.c:1950
0x803b6af3 execute
.../gcc/function.c:1999

[Bug rtl-optimization/70174] [6 Regression] ICE at -O1 and above on x86_64-linux-gnu in gen_lowpart_general, at rtlhooks.c:63

[vogt at linux dot vnet.ibm.com]

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

Dominik Vogt  changed:

   What|Removed |Added

 CC||vogt at linux dot vnet.ibm.com

--- Comment #12 from Dominik Vogt  ---
The new test case triggers an ICE on s390x.  See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70404

[Bug c++/70403] A null pointer check removed with -O2 even with -fno-delete-null-pointers-checks

[thadula at ciena dot com]

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

--- Comment #5 from Hadula, Tomasz  ---
Created attachment 38086
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38086&action=edit
Original and preprocessed source

generated with -E

[Bug target/70359] [6 Regression] Code size increase for ARM compared to gcc-5.3.0

[law at redhat dot com]

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

--- Comment #7 from Jeffrey A. Law  ---
I would suggest that you definitely keep reporting these things and extracting
examples from csibe or other benchmarks to show the codesize increases.

While some folks will prioritize performance, it doesn't mean that codesize is
ignored.  Similarly for significant changes in compile-time, stack usage, etc.

[Bug rtl-optimization/70405] New: -fcompare-debug failure with -mavx512f

[zsojka at seznam dot cz]

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

Bug ID: 70405
   Summary: -fcompare-debug failure with -mavx512f
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
Target: x86_64-pc-linux-gnu, i686-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -mavx512f -fcompare-debug testcase.c
x86_64-pc-linux-gnu-gcc: error: testcase.c: -fcompare-debug failure (length)

The generated assembly differs significantly.

Tested revisions:
trunk r234391 - FAIL
5-branch r234412 - OK

[Bug target/70406] New: ICE: in extract_insn, at recog.c:2287 (unrecognizable insn) with -mtune=pentium2 -mavx512f

[zsojka at seznam dot cz]

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

Bug ID: 70406
   Summary: ICE: in extract_insn, at recog.c:2287 (unrecognizable
insn) with -mtune=pentium2 -mavx512f
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
Target: i686-pc-linux-gnu

Compiler output:
$ i686-pc-linux-gnu-gcc -O -mtune=pentium2 -mavx512f testcase.c 
testcase.c: In function 'foo':
testcase.c:9:1: error: unrecognizable insn:
 }
 ^
(insn 39 33 40 2 (set (reg/v:QI 1 dx [orig:89 i ] [89])
(not:HI (reg/v:QI 1 dx [orig:89 i ] [89]))) testcase.c:6 -1
 (nil))
testcase.c:9:1: internal compiler error: in extract_insn, at recog.c:2287
0xb37078 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.c:108
0xb37108 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-trunk/gcc/rtl-error.c:116
0xaec618 extract_insn(rtx_insn*)
/repo/gcc-trunk/gcc/recog.c:2287
0xaec6c7 extract_insn_cached(rtx_insn*)
/repo/gcc-trunk/gcc/recog.c:2178
0x85140d cleanup_subreg_operands(rtx_insn*)
/repo/gcc-trunk/gcc/final.c:3104
0xae7ffa split_insn
/repo/gcc-trunk/gcc/recog.c:2901
0xaf03e7 split_all_insns()
/repo/gcc-trunk/gcc/recog.c:2955
0xaf04d8 rest_of_handle_split_after_reload
/repo/gcc-trunk/gcc/recog.c:3891
0xaf04d8 execute
/repo/gcc-trunk/gcc/recog.c:3920
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Tested revisions:
trunk r234391 - FAIL
5-branch r234412 - FAIL
4_9-branch r234243 - FAIL

[Bug target/70406] ICE: in extract_insn, at recog.c:2287 (unrecognizable insn) with -mtune=pentium2 -mavx512f

[zsojka at seznam dot cz]

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

--- Comment #1 from Zdenek Sojka  ---
Created attachment 38088
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38088&action=edit
reduced testcase

[Bug target/70359] [6 Regression] Code size increase for ARM compared to gcc-5.3.0

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
All I wanted to say is that it is to be expected that on some code a newer GCC
version ends up needing one or two more instructions, even at -Os, and what
matters is not the size of a single function, but larger codebases.  If the
testcase here has been extracted from CSiBE and/or represents something that
happens often, then it is of course desirable to fix that.
So e.g. it would be interesting to find out what impact these above mentioned
commits have on larger codebases.  If they are in the end neutral or shrink
code size, then one testcase going in the other direction is fine, if they have
overal negative -Os code size effects, then it is something to work on.

[Bug target/70216] [SH] Implement __builtin_trap

[bugdal at aerifal dot cx]

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

--- Comment #7 from Rich Felker  ---
Is there a reason we don't use an undefined instruction that will trap? 0xfffd
is mentioned as permanently undefined here on page 85:

http://documentation.renesas.com/doc/products/mpumcu/rej09b0003_sh4a.pdf

I actually had trouble getting Linux to trap this; it's one thing I need to
investigate on the kernel side, which is why I didn't reply earlier. I'll
report my findings later.

One other thing I'm wondering about is the contract for clobbers on the
function call version. Is __builtin_trap supposed to be able to return? I was
under the impression that it's noreturn, in which case there would be no
requirements on what it can clobber, but there may be calling-convention issues
still: Is it callable via PLT? On FDPIC targets, does the function receive a
valid GOT pointer in r12 so that it can make further calls/data access? Also,
if the expectation is that the trap will not return, does the trapa need the
bug workaround? Does the bug (requiring the 5x or) take place at the time the
trapa is executed, or at the time of return to the instruction after it? This
is not well-documented and I remember looking into it before but I don't
remember the answer.

[Bug c++/70386] [6 Regression] ICE with -Wall on valid code on x86_64-linux-gnu in verify_ctor_sanity, at cp/constexpr.c:2232

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
Fixed.

[Bug fortran/34640] ICE when assigning item of a derived-component to a pointer

[chester.gingrich at gmail dot com]

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

--- Comment #27 from chester.gingrich at gmail dot com ---
Created attachment 38089
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38089&action=edit
workaround (of sorts)

This is how I get around this issue.

Note that I don't usually have to explicitly provide the dimensions
in my application.  The workaround is shown applied to the demo case.

I simply wrote a "do nothing" function, "remap" that does the pointer
assignment.

I hope someone can make use of this workaround to figure out a real solution!

[Bug target/69770] [ARM] -mlong-calls does not affect calls to __gnu_mcount_nc generated by -pg

[cbaylis at gcc dot gnu.org]

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

cbaylis at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |7.0

--- Comment #3 from cbaylis at gcc dot gnu.org ---
new patch posted to mailing list

https://gcc.gnu.org/ml/gcc-patches/2016-03/msg01403.html

[Bug c++/70353] [5/6 regression] ICE on __PRETTY_FUNCTION__ in a constexpr function

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||jason at gcc dot gnu.org,
   ||mliska at suse dot cz
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

--- Comment #11 from Jason Merrill  ---
Core issue 1962 talks about changing __func__ et al to be const char * rather
than array; Martin was investigating that change but it fell off my radar. 
I'll look at finishing up his patch.

[Bug fortran/70071] ICE on wrong usage of a subscript triplet

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #3 from Harald Anlauf  ---
(In reply to Gerhard Steinmetz from comment #0)
> $ cat z1.f90
> program p
>integer, allocatable :: z(:)[:,:]
>allocate (z(2)[1::2,*])
> end
> 
> $ gfortran-6 -fcoarray=single z1.f90
> f951: internal compiler error: gfc_ref_dimen_size(): Bad dimension

Potential fix (not regtested):

Index: gcc/fortran/array.c
===
--- gcc/fortran/array.c (revision 234170)
+++ gcc/fortran/array.c (working copy)
@@ -2173,9 +2184,15 @@ gfc_ref_dimen_size (gfc_array_ref *ar, int dimen,
   mpz_t diff;
   bool t;

-  if (dimen < 0 || ar == NULL || dimen > ar->dimen - 1)
+  if (dimen < 0 || ar == NULL)
 gfc_internal_error ("gfc_ref_dimen_size(): Bad dimension");

+  if (dimen > ar->dimen - 1)
+{
+  gfc_error ("Bad array dimension at %L", &ar->c_where[dimen]);
+  return false;
+}
+
   switch (ar->dimen_type[dimen])
 {
 case DIMEN_ELEMENT:


Which gives:

pr70071-z1.f90:3:18:

allocate (z(2)[1::2,*])
  1
Error: Bad array dimension at (1)

[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format

[jvdelisle at gcc dot gnu.org]

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

--- Comment #14 from Jerry DeLisle  ---
Created attachment 38090
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38090&action=edit
Updated patch correcting problem found by Dominique

This is what I came up with independent of Dominiques patch.  This patch is
much simpler.  Lets continue testing.