[Bug c/67668] erroneous type argument for unary operator one's complement

[ka_bena at yahoo dot fr]

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

--- Comment #4 from BENAÏSSA  ---
  Thank you for your quick and clear reply .
  Note:
   I think that using the same symbol operator for doing two different things
   can be a potential source of blind errors.
   I confirm that this is only a personnal point of view.
  A.Benaïssa



 Le Lundi 21 septembre 2015 15h41, manu at gcc dot gnu.org
 a écrit :


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

Manuel López-Ibáñez  changed:

          What    |Removed                    |Added

            Status|UNCONFIRMED                |RESOLVED
                CC|                            |manu at gcc dot gnu.org
        Resolution|---                        |INVALID

--- Comment #3 from Manuel López-Ibáñez  ---
Marc is right:

The operator ‘~’ performs complex conjugation when used on a value with a
complex type. This is a GNU extension; for values of floating type, you should
use the ISO C99 functions conjf, conj and conjl, declared in  and
also provided as built-in functions by GCC. 

test.c:3:3: warning: ISO C does not support ‘~’ for complex conjugation
[-Wpedantic]
  ~( 1. + 0.i ) ; 
  ^

[Bug c++/67684] [concepts] friend access not working with constrained function

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-22
 Ever confirmed|0   |1

[Bug tree-optimization/59124] [4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds"

[pangbw at gmail dot com]

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

--- Comment #32 from baoshan  ---
(In reply to Manuel López-Ibáñez from comment #30)
> (In reply to baoshan from comment #29)
> > > However, it is clear that _14 = baz[_9] is executed only 5 times (not 5
> > > times + 1). Why is this estimate wrong?
> > 
> > The max value of n is 6, so the max value of i is 5 as "i < n", then the max
> > value of j is 4 as "j = i - 1" which means the max iterate times is 4.
> 
> True! Well, that reinforces my point that something is very wrong in the
> estimation. What is it?

And I think it is not wrong, it's just inaccurate, and it is not making any
wrong result in running time.

Can you point me how to proceed?

[Bug c++/67684] New: [concepts] friend access not working with constrained function

[ryan.burn at gmail dot com]

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

Bug ID: 67684
   Summary: [concepts] friend access not working with constrained
function
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryan.burn at gmail dot com
  Target Milestone: ---

The following code fails to compile with g++ (GCC) 6.0.0 20150915
(experimental)

/
template
class A {
 public:
  template
requires I > 0
  friend int f(const A&);
 private:
  int x = 2;
};

template
  requires I > 0
int f(const A& a) { 
  return a.x;
} 

int main() { 
  A a;
  f<2>(a);
  return 0;
} 
/

I get the error

main.cpp:14:12: error: ‘int A::x’ is private within this context

But I expect it should be valid code (it compiles fine if the constraint is
removed)

[Bug target/67677] New: [6 Regression] r226005 causes "Conditional jump or move depends on uninitialised value(s)"

[trippels at gcc dot gnu.org]

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

Bug ID: 67677
   Summary: [6 Regression] r226005 causes "Conditional jump or
move depends on uninitialised value(s)"
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: segher at gcc dot gnu.org
  Target Milestone: ---
  Host: powerpc64le-unknown-linux-gnu
Target: powerpc64le-unknown-linux-gnu
 Build: powerpc64le-unknown-linux-gnu

Starting with r226005 --checking=valgrind shows on ppc64le:

==148059== Conditional jump or move depends on uninitialised value(s)
==148059==at 0x10935248: rs6000_is_valid_mask(rtx_def*, int*, int*,
machine_mode) (rs6000.c:16516)
==148059==by 0x1093545B: rs6000_is_valid_and_mask(rtx_def*, machine_mode)
(rs6000.c:16565)
==148059==by 0x105281CF: insn_operand_matches (optabs.c:6527)
==148059==by 0x105281CF: maybe_legitimize_operand_same_code(insn_code,
unsigned int, expand_operand*) [clone .isra.18] (optabs.c:6555)
==148059==by 0x1052B8EF: maybe_legitimize_operand (optabs.c:6625)
==148059==by 0x1052B8EF: maybe_legitimize_operands(insn_code, unsigned int,
unsigned int, expand_operand*) (optabs.c:6690)
==148059==by 0x1052BD73: maybe_gen_insn(insn_code, unsigned int,
expand_operand*) (optabs.c:6708)
==148059==by 0x1052C6E7: maybe_expand_insn(insn_code, unsigned int,
expand_operand*) (optabs.c:6751)
==148059==by 0x1052E667: maybe_emit_op(atomic_op_functions const*,
rtx_def*, rtx_def*, rtx_def*, bool, memmodel, bool) (optabs.c:6293)
==148059==by 0x105350DF: expand_atomic_fetch_op_no_fallback(rtx_def*,
rtx_def*, rtx_def*, rtx_code, memmodel, bool) (optabs.c:6347)
==148059==by 0x105352F3: expand_atomic_fetch_op(rtx_def*, rtx_def*,
rtx_def*, rtx_code, memmodel, bool) (optabs.c:6411)
==148059==by 0x1020D28B: expand_builtin_atomic_fetch_op(machine_mode,
tree_node*, rtx_def*, rtx_code, bool, bool, built_in_function)
(builtins.c:5530)
==148059==by 0x1021E35F: expand_builtin(tree_node*, rtx_def*, rtx_def*,
machine_mode, int) (builtins.c:6917)
==148059==by 0x1035AC6F: expand_expr_real_1(tree_node*, rtx_def*,
machine_mode, expand_modifier, rtx_def**, bool) (expr.c:10474)
==148059==
==148059== Conditional jump or move depends on uninitialised value(s)
==148059==at 0x10935264: exact_log2 (hwint.h:223)
==148059==by 0x10935264: rs6000_is_valid_mask(rtx_def*, int*, int*,
machine_mode) (rs6000.c:16519)
==148059==by 0x1093545B: rs6000_is_valid_and_mask(rtx_def*, machine_mode)
(rs6000.c:16565)
==148059==by 0x105281CF: insn_operand_matches (optabs.c:6527)
==148059==by 0x105281CF: maybe_legitimize_operand_same_code(insn_code,
unsigned int, expand_operand*) [clone .isra.18] (optabs.c:6555)
==148059==by 0x1052B8EF: maybe_legitimize_operand (optabs.c:6625)
==148059==by 0x1052B8EF: maybe_legitimize_operands(insn_code, unsigned int,
unsigned int, expand_operand*) (optabs.c:6690)
==148059==by 0x1052BD73: maybe_gen_insn(insn_code, unsigned int,
expand_operand*) (optabs.c:6708)
==148059==by 0x1052C6E7: maybe_expand_insn(insn_code, unsigned int,
expand_operand*) (optabs.c:6751)
==148059==by 0x1052E667: maybe_emit_op(atomic_op_functions const*,
rtx_def*, rtx_def*, rtx_def*, bool, memmodel, bool) (optabs.c:6293)
==148059==by 0x105350DF: expand_atomic_fetch_op_no_fallback(rtx_def*,
rtx_def*, rtx_def*, rtx_code, memmodel, bool) (optabs.c:6347)
==148059==by 0x105352F3: expand_atomic_fetch_op(rtx_def*, rtx_def*,
rtx_def*, rtx_code, memmodel, bool) (optabs.c:6411)
==148059==by 0x1020D28B: expand_builtin_atomic_fetch_op(machine_mode,
tree_node*, rtx_def*, rtx_code, bool, bool, built_in_function)
(builtins.c:5530)
==148059==by 0x1021E35F: expand_builtin(tree_node*, rtx_def*, rtx_def*,
machine_mode, int) (builtins.c:6917)
==148059==by 0x1035AC6F: expand_expr_real_1(tree_node*, rtx_def*,
machine_mode, expand_modifier, rtx_def**, bool) (expr.c:10474)
==148059==
==148059== Conditional jump or move depends on uninitialised value(s)
==148059==at 0x109352E4: exact_log2 (hwint.h:223)
==148059==by 0x109352E4: rs6000_is_valid_mask(rtx_def*, int*, int*,
machine_mode) (rs6000.c:16519)
==148059==by 0x1093545B: rs6000_is_valid_and_mask(rtx_def*, machine_mode)
(rs6000.c:16565)
==148059==by 0x105281CF: insn_operand_matches (optabs.c:6527)
==148059==by 0x105281CF: maybe_legitimize_operand_same_code(insn_code,
unsigned int, expand_operand*) [clone .isra.18] (optabs.c:6555)
==148059==by 0x1052B8EF: maybe_legitimize_operand (optabs.c:6625)
==148059==by 0x1052B8EF: maybe_legitimize_operands(insn_code, unsigned int,
unsigned int, expand_operand*) (optabs.c:6690)
==148059==by 0x1052BD73: maybe_gen_insn(insn_code, unsigned int,
expand_operand*) 

[Bug tree-optimization/67666] single restrict pointer in struct looses restrict

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from vries at gcc dot gnu.org ---
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01622.html

[Bug middle-end/67649] trunk build with valgrind fail in get_def_blocks_for

[trippels at gcc dot gnu.org]

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

--- Comment #10 from Markus Trippelsdorf  ---
A gave your patch a quick spin on gcc112 (compile farm machine).
It fixes the issue.

[Bug bootstrap/67598] [6 Regression] Target powerpc-e500v2-linux-gnuspe failed to bootstrap

[asolokha at gmx dot com]

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

--- Comment #1 from Arseny Solokha  ---
(In reply to Arseny Solokha from comment #0)
> I still have to find out
> when the issue have started showing up, given that I now have half a year
> wide window.

6.0.0-alpha20150802 snapshot bootstraps fine, and 6.0.0_alpha20150906 fails. I
failed to bootstrap 6.0.0_alpha20150830 because of unrelated build failure, but
all in all the issue seems to be introduced sometime in August.

[Bug libgomp/67141] wrong libgomp mutex initialisation order

[cltang at gcc dot gnu.org]

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

--- Comment #6 from Chung-Lin Tang  ---
Author: cltang
Date: Tue Sep 22 06:45:22 2015
New Revision: 227994

URL: https://gcc.gnu.org/viewcvs?rev=227994=gcc=rev
Log:
2015-09-22  Chung-Lin Tang  

PR libgomp/67141
* oacc-int.h (goacc_host_init): Add declaration.
* oacc-host.c (goacc_host_init): Remove static and constructor
attribute.
* oacc-init.c (goacc_runtime_initialize): Call goacc_host_init() at
end.


Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/oacc-host.c
trunk/libgomp/oacc-init.c
trunk/libgomp/oacc-int.h

[Bug c/67680] Seg Fault in gcc 4.9.3 compiling libiberty/floatformat.c when building gcc 5.2.1 on Cygwin 64 on Windows

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-09-22
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Can you provide the preprocessed source?

[Bug tree-optimization/67682] New: Missed vectorization: (another) straight-line memcpy/memset not vectorized when equivalent loop is

[alalaw01 at gcc dot gnu.org]

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

Bug ID: 67682
   Summary: Missed vectorization: (another) straight-line
memcpy/memset not vectorized when equivalent loop is
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alalaw01 at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

This code:

void
test (int*__restrict a, int*__restrict b)
{
a[0] = b[0];
a[1] = b[1];
a[2] = b[2];
a[3] = b[3];
a[4] = 0;
a[5] = 0;
a[6] = 0;
a[7] = 0;
}

is not vectorized; -fdump-tree-slp-details reveals

test.c:4:13: note: Build SLP failed: different operation in stmt MEM[(int
*)a_4(
D) + 28B] = 0;
test.c:4:13: note: original stmt *a_4(D) = _3;
test.c:4:13: note: === vect_slp_analyze_data_ref_dependences ===
test.c:4:13: note: === vect_slp_analyze_operations ===
test.c:4:13: note: not vectorized: bad operation in basic block.
test.c:4:13: note: * Re-trying analysis with vector size 8
...
test.c:4:13: note: Build SLP failed: different operation in stmt MEM[(int
*)a_4(D) + 28B] = 0;
test.c:4:13: note: original stmt *a_4(D) = _3;
test.c:4:13: note: === vect_slp_analyze_data_ref_dependences ===
test.c:4:13: note: === vect_slp_analyze_operations ===
test.c:4:13: note: not vectorized: bad operation in basic block.

(the failure with vector size 8 is expected, but vector size 4 should succeed)

Output is:
test:
ldp w4, w3, [x1]
ldp w2, w1, [x1, 8]
stp w4, w3, [x0]
stp w2, w1, [x0, 8]
stp wzr, wzr, [x0, 16]
stp wzr, wzr, [x0, 24]
ret

Curiously, a similar code but writing elements a[0..3] and a[5..8] (missing out
a[4]) is SLP'd, producing superior:

test:
ldr q0, [x1]
moviv1.4s, 0
str q1, [x0, 20]
str q0, [x0]
ret

And similarly for (equivalent to the first):

void
test (int*__restrict a, int*__restrict b)
{
  for (int i = 0; i < 4; i++)
a[i] = b[i];
  for (int i = 4; i < 8; i++)
a[i] = 0;
}

producing:

test:
moviv0.4s, 0
ldp x2, x3, [x1]
stp x2, x3, [x0]
str q0, [x0, 16]
ret

[Bug fortran/67679] -Wunitialized reports on compiler generated variables

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-22
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (6.0). Even worse with

[Book15] f90/bug% gfca pr67679.f90 -cpp -Wuninitialized -O -c
pr67679.f90:15:0:

   DIMENSION(:, :, :) :: work
^
Warning: 'work.dim[2].stride' may be used uninitialized in this function
[-Wmaybe-uninitialized]
pr67679.f90:15:0: Warning: 'work.dim[1].stride' may be used uninitialized in
this function [-Wmaybe-uninitialized]
pr67679.f90:15:0: Warning: 'work.offset' may be used uninitialized in this
function [-Wmaybe-uninitialized]
pr67679.f90:54:0:

p(lb1:ub1,lb2:ub2,lb3:ub3) = work(lb1:ub1,lb2:ub2,lb3:ub3)
^
Warning: 'ub3' may be used uninitialized in this function
[-Wmaybe-uninitialized]
pr67679.f90:54:0: Warning: 'ub2' may be used uninitialized in this function
[-Wmaybe-uninitialized]
pr67679.f90:54:0: Warning: 'ub1' may be used uninitialized in this function
[-Wmaybe-uninitialized]
pr67679.f90:54:0: Warning: 'lb3' may be used uninitialized in this function
[-Wmaybe-uninitialized]
pr67679.f90:54:0: Warning: 'lb2' may be used uninitialized in this function
[-Wmaybe-uninitialized]
pr67679.f90:54:0: Warning: 'lb1' may be used uninitialized in this function
[-Wmaybe-uninitialized]

[Bug c/67680] New: Seg Fault in gcc 4.9.3 compiling libiberty/floatformat.c when building gcc 5.2.1 on Cygwin 64 on Windows

[bplummer at hotmail dot com]

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

Bug ID: 67680
   Summary: Seg Fault in gcc 4.9.3 compiling
libiberty/floatformat.c when building gcc 5.2.1 on
Cygwin 64 on Windows
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bplummer at hotmail dot com
  Target Milestone: ---

both the configure and the make args were default.  I've tried a wide variety
of args for both configure and make and the error is blindingly consistent.

Here are the details :

Brian@MBPWin7-64 ~/gnu/gcc/gcc-5.2.0/build/libiberty
$ gmake
if [ x"" != x ]; then \
  gcc -c -DHAVE_CONFIG_H -g  -I. -I../../libiberty/../include  -W -Wall
-Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  
../../libiberty/floatformat.c -o pic/floatformat.o; \
else true; fi
if [ x"" != x ]; then \
  gcc -c -DHAVE_CONFIG_H -g  -I. -I../../libiberty/../include  -W -Wall
-Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic   
../../libiberty/floatformat.c -o noasan/floatformat.o; \
else true; fi
gcc -c -DHAVE_CONFIG_H -g  -I. -I../../libiberty/../include  -W -Wall
-Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic 
../../libiberty/floatformat.c -o floatformat.o
../../libiberty/floatformat.c: In function ‘floatformat_to_double’:
../../libiberty/floatformat.c:529:2: internal compiler error: Segmentation
fault
  dto = ldexp (1.0, exponent);
  ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Makefile:773: recipe for target 'floatformat.o' failed
gmake: *** [floatformat.o] Error 1

Brian@MBPWin7-64 ~/gnu/gcc/gcc-5.2.0/build/libiberty
$ uname -a
CYGWIN_NT-6.1 MBPWin7-64 2.2.1(0.289/5/3) 2015-08-20 11:42 x86_64 Cygwin

Brian@MBPWin7-64 ~/gnu/gcc/gcc-5.2.0/build/libiberty
$ gcc --version
gcc (GCC) 4.9.3
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.

[Bug tree-optimization/67681] New: Missed vectorization: induction variable used after loop

[alalaw01 at gcc dot gnu.org]

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

Bug ID: 67681
   Summary: Missed vectorization: induction variable used after
loop
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alalaw01 at gcc dot gnu.org
  Target Milestone: ---

The inner loop here:
void addlog2 (int *data)
{
  int i = 1;
  for (int j=0; j<=30; j++) {
int max = 1 << j;
if (FOO && i>max) break;

for (; i <= max; i++)
  data[i] += j;
  }
}

does not vectorize if the if(FOO...) is present:
$ /work/alalaw01/build-aarch64-none-elf/install/bin/aarch64-none-elf-gcc -S -O2
-ftree-vectorize -fdump-tree-vect-details=stdout loop9b.c -DFOO=1 | grep
vectorized
loop9b.c:1:6: note: not vectorized: inner-loop count not invariant.
loop9b.c:8:5: note: === vect_mark_stmts_to_be_vectorized ===
loop9b.c:8:5: note: not vectorized: value used after loop.
loop9b.c:8:5: note: === vect_mark_stmts_to_be_vectorized ===
loop9b.c:8:5: note: not vectorized: value used after loop.
loop9b.c:1:6: note: vectorized 0 loops in function.


$ aarch64-none-elf-gcc -S -O2 -ftree-vectorize -fdump-tree-vect-details=stdout
loop9b.c -DFOO=0 | grep vectorized
loop9b.c:4:3: note: not vectorized: inner-loop count not invariant.
loop9b.c:8:5: note: === vect_mark_stmts_to_be_vectorized ===
loop9b.c:8:5: note: loop vectorized
loop9b.c:1:6: note: vectorized 1 loops in function.

Same with -O3. Of course clever analysis could figure out that i>max is never
true, but even without that, we should be able to get 'i' back afterwards.

[Bug c/67667] erroneous type argument for unary operator one's complement

[ka_bena at yahoo dot fr]

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

--- Comment #2 from BENAÏSSA  ---
  Thank you for your quick and clear reply .
  Note:
   I think that using the same symbol operato as GNU extension for doing two
different things
   can be a potential source of blind errors .
   I confirm that this is only a personnal point of view.
  A.Benaïssa



 Le Lundi 21 septembre 2015 13h29, redi at gcc dot gnu.org
 a écrit :


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

Jonathan Wakely  changed:

          What    |Removed                    |Added

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

--- Comment #1 from Jonathan Wakely  ---
.

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

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

[vogt at linux dot vnet.ibm.com]

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

Dominik Vogt  changed:

   What|Removed |Added

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

--- Comment #27 from Dominik Vogt  ---
The patch in comment 22 that was applied on 2015-09-01 with the git commit id
0af99ebfea26293fc900fe9050c5dd514005e4e5 breaks the S/390 compiler (and maybe
other platforms too):

tt.c:
-- snip --
  struct t
  {
int i;
void *p;
void *q;
  };
  void foo (t **g)
  {
(*g)->p = &((*g)->p);
  }
-- snip --

This code should set "p" to "", but actually sets "q" to "".  Before the
patch, compiling with "g++ -O2" resulted in this assembly code:

tt.s:
  lg%r1,0(%r2)  # r1 := *g
  la%r2,8(%r1)  # r2 := &((*g)->p)
  stg   %r2,8(%r1)  # *r2 := (*g) + 8  <--- GOOD

with the patch it uses r1 for both, effectively doubling the store target's
offset into the structure:

tt.s:
  lg  %r1,0(%r2) # r1 := *g
  la  %r1,8(%r1) # r1 := &((*g)->p)
  stg %r1,8(%r1) # *(r1 + 8) := (*g) + 8  <--- BAD


RTL details:


tt.c.232r.reload (BAD, with patch):
-- snip --
(insn 6 3 7 2 (set (reg/f:DI 1 %r1 [orig:61 *g_2(D) ] [61])
(mem/f:DI (reg:DI 2 %r2 [ g ]) [1 *g_2(D)+0 S8 A64])) tt.c:9 900
{*movdi_64}
 (nil))
(insn 7 6 13 2 (parallel [
(set (reg/f:DI 1 %r1 [orig:61 *g_2(D) ] [61])
(plus:DI (reg/f:DI 1 %r1 [orig:61 *g_2(D) ] [61])
(const_int 8 [0x8])))
(clobber (reg:CC 33 %cc))
]) tt.c:9 1171 {*adddi3}
 (nil))
(insn 13 7 10 2 (set (mem/f:DI (plus:DI (reg/f:DI 1 %r1 [orig:61 *g_2(D) ]
[61])
(const_int 8 [0x8])) [2 _3->p+0 S8 A64])
(reg/f:DI 1 %r1 [orig:61 *g_2(D) ] [61])) tt.c:9 900 {*movdi_64}
 (nil))
-- snip --


tt.c.232r.reload (GOOD, without patch):
-- snip --
(insn 6 3 12 2 (set (reg/f:DI 1 %r1 [orig:61 *g_2(D) ] [61])
(mem/f:DI (reg:DI 2 %r2 [ g ]) [1 *g_2(D)+0 S8 A64])) tt.c:9 900
{*movdi_64}
 (nil))
(insn 12 6 7 2 (set (reg:DI 2 %r2 [63])
(reg/f:DI 1 %r1 [orig:61 *g_2(D) ] [61])) tt.c:9 900 {*movdi_64}
 (nil))
(insn 7 12 13 2 (parallel [
(set (reg:DI 2 %r2 [63])
(plus:DI (reg:DI 2 %r2 [63])
(const_int 8 [0x8])))
(clobber (reg:CC 33 %cc))
]) tt.c:9 1171 {*adddi3}
 (nil))
(insn 13 7 10 2 (set (mem/f:DI (plus:DI (reg/f:DI 1 %r1 [orig:61 *g_2(D) ]
[61])
(const_int 8 [0x8])) [2 _3->p+0 S8 A64])
(reg:DI 2 %r2 [63])) tt.c:9 900 {*movdi_64}
 (nil))
-- snip --


tt.c.231r.ira (GOOD):
-- snip --
(insn 6 3 7 2 (set (reg/f:DI 61 [ *g_2(D) ])
(mem/f:DI (reg:DI 2 %r2 [ g ]) [1 *g_2(D)+0 S8 A64])) tt.c:9 900
{*movdi_64}
 (expr_list:REG_DEAD (reg:DI 2 %r2 [ g ])
(nil)))
(insn 7 6 10 2 (parallel [
(set (mem/f:DI (plus:DI (reg/f:DI 61 [ *g_2(D) ])
(const_int 8 [0x8])) [2 _3->p+0 S8 A64])
(plus:DI (reg/f:DI 61 [ *g_2(D) ])
(const_int 8 [0x8])))
(clobber (reg:CC 33 %cc))
]) tt.c:9 1171 {*adddi3}
 (expr_list:REG_DEAD (reg/f:DI 61 [ *g_2(D) ])
(expr_list:REG_UNUSED (reg:CC 33 %cc)
(nil
-- snip --

[Bug target/67391] [SH] Convert clrt addc to normal add insn

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 CC||kkojima at gcc dot gnu.org

--- Comment #1 from Oleg Endo  ---
This seems to be (indirectly) caused by the extra checks added to addsi3 as
part of PR 55212, in particular attachment 33707, and r218999, r219341.

Removing those with:

@@ -2129,11 +2129,6 @@
 {
   if (TARGET_SHMEDIA)
 operands[1] = force_reg (SImode, operands[1]);
-  else if (! arith_operand (operands[2], SImode))
-{
-  if (reg_overlap_mentioned_p (operands[0], operands[1]))
-   FAIL;
-}
 })

 (define_insn "addsi3_media"
@@ -2172,10 +2167,7 @@
   [(set (match_operand:SI 0 "arith_reg_dest" "=r,")
(plus:SI (match_operand:SI 1 "arith_operand" "%0,r")
 (match_operand:SI 2 "arith_or_int_operand" "rI08,rn")))]
-  "TARGET_SH1
-   && ((rtx_equal_p (operands[0], operands[1])
-&& arith_operand (operands[2], SImode))
-   || ! reg_overlap_mentioned_p (operands[0], operands[1]))"
+  "TARGET_SH1"
   "@
add %2,%0
#"
@@ -2190,6 +2182,37 @@
 }
   [(set_attr "type" "arith")])

Removes the suspicious clrt-addc sequence.  The added reg overlap
checks/restrictions also trigger some problems with ifcvt, because it tries to
emit insns that go like

(set (reg:SI 162)
(ne:SI (reg:SI 147 t)
(const_int 0 [0])))

(set (reg:SI 162)
 (plus:SI (reg:SI 162) (const_int 2147483647)))

I haven't tested the patch above (with LRA enabled), but on CSiBE it does:
sum:  3347407 -> 3346163-1244 / -0.037163 %

Kaz, do you have any memory of the extra checks?  Isn't it enough to just
accept the addsi3 pattern as "rC = rA + {rB|imm}" and insert the reg-reg copy
after register allocation via split2, as it's already done?  Why are the reg
overlap checks needed during matching of the patterns?

[Bug c++/53856] Default argument allowed on member defined outside of class template

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-09-22
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #2 from Paolo Carlini  ---
Looks like the first testcase is already fixed in 5. I'm looking into the
second one.

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

[vogt at linux dot vnet.ibm.com]

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

--- Comment #28 from Dominik Vogt  ---
Created attachment 36371
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36371=edit
Outpout of the reload pass (BAD)

The full output of the reload pass on S/390, showing the behaviour described in
comment 27.

[Bug c/65405] improve locations of diagnostics in c-pragma.c

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #1 from Manuel López-Ibáñez  ---
This was fixed in r227923

[Bug tree-optimization/67683] New: Missed vectorization: shifts of an induction variable

[alalaw01 at gcc dot gnu.org]

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

Bug ID: 67683
   Summary: Missed vectorization: shifts of an induction variable
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alalaw01 at gcc dot gnu.org
Blocks: 53947
  Target Milestone: ---

This testcase:

void test (unsigned char *data, int max)
{
  unsigned short val = 0xcdef;
  for(int i = 0; i < max; i++) { 
  data[i] = (unsigned char)(val & 0xff);
  val >>= 1; 
  }
}

does not vectorize on AArch64 or x86_64 at -O3. (I haven't yet looked at
whether it's a mid-end deficiency or both back-ends are missing patterns.)


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug c/67688] New: [MinGW/Cygwin] Attributes selectany and section cannot be used together

[thiago at kde dot org]

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

Bug ID: 67688
   Summary: [MinGW/Cygwin] Attributes selectany and section cannot
be used together
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thiago at kde dot org
  Target Milestone: ---

The following program:

__declspec(selectany) __attribute__((section("foo"))) int i = 0;

Fails to compile with:

error: i causes a section type conflict

The same program compiles with clang -target i386-mingw -fms-compatibility and
produces the assembly:

.sectionfoo,"dw",discard,_i
.globl  _i  # @i
.align  4
_i:
.long   0   # 0x0

The similar program:

#pragma data_seg("foo")
__declspec(selectany) __declspec(allocate("foo")) int i = 0;

compiles without error with MSVC and produces assembly:
PUBLIC  i
;   COMDAT i
foo SEGMENT
i   DD  00H
foo ENDS

[Bug target/67391] [SH] Convert clrt addc to normal add insn

[kkojima at gcc dot gnu.org]

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

--- Comment #3 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #1)
> Kaz, do you have any memory of the extra checks?  Isn't it enough to just
> accept the addsi3 pattern as "rC = rA + {rB|imm}" and insert the reg-reg
> copy after register allocation via split2, as it's already done?  Why are
> the reg overlap checks needed during matching of the patterns?

Ugh, those checks look just wrong and I can't remind why I've
added them.  33707 didn't do that and checked overlapping at
the split condition only.  Perhaps I mixed up the final patch
with the one of test codes to collect CSiBE results.  You can
install the above patch as the rather obvious one, though I'm
running "make -k check" on sh4-unknown-linux-gnu.  Sorry for
adding that thinko.

[Bug tree-optimization/67689] New: wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

Bug ID: 67689
   Summary: wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The current gcc trunk miscompiles the following code on x86_64-linux-gnu at
-O1, -O2 and -O3 in both 32-bit and 64-bit modes. 

This is a regression from 5.2.x.


$ 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-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20150922 (experimental) [trunk revision 228013] (GCC) 
$ 
$ gcc-trunk -O0 small.c; ./a.out
$ gcc-5.2 -O1 small.c; ./a.out
$ 
$ gcc-trunk -O1 small.c
$ ./a.out
Aborted
$ 


--


int a, b, c = 1, d, e;

void
fn1 ()
{
  e = c >> b ? c : c << 1;
  for (b = 0; b < 1; b++)
d = a ? 0 : e ^ 1;
  d = 0;
}

int
main ()
{
  fn1 ();

  if (e != 1)
__builtin_abort ();

  return 0;
}

[Bug target/67391] [SH] Convert clrt addc to normal add insn

[olegendo at gcc dot gnu.org]

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

--- Comment #4 from Oleg Endo  ---
(In reply to Kazumoto Kojima from comment #3)
> 
> Ugh, those checks look just wrong and I can't remind why I've
> added them.  33707 didn't do that and checked overlapping at
> the split condition only.  Perhaps I mixed up the final patch
> with the one of test codes to collect CSiBE results.  You can
> install the above patch as the rather obvious one, though I'm
> running "make -k check" on sh4-unknown-linux-gnu.  Sorry for
> adding that thinko.

No problem.  I'd like to wait for your test results though before committing.

I've just checked, the code is also present in GCC 5.  Because of the funny
side effects even with LRA disabled (this PR) I'd like to backport this to the
GCC 5 branch, too.

[Bug target/67391] [SH] Convert clrt addc to normal add insn

[kkojima at gcc dot gnu.org]

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

--- Comment #5 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #4)
> I've just checked, the code is also present in GCC 5.  Because of the funny
> side effects even with LRA disabled (this PR) I'd like to backport this to
> the GCC 5 branch, too.

Yes, this is clearly a 5/6 regression.  My test has passed C and C++ part
with no new failures.  I'll report back when test completed.

[Bug middle-end/67649] trunk build with valgrind fail in get_def_blocks_for

[miyuki at gcc dot gnu.org]

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

--- Comment #11 from Mikhail Maltsev  ---
Author: miyuki
Date: Wed Sep 23 02:31:14 2015
New Revision: 228033

URL: https://gcc.gnu.org/viewcvs?rev=228033=gcc=rev
Log:
Fix use of valgrind API

gcc/
PR middle-end/67649
* memory-block.h (memory_block_pool::allocate): Use valgrind API to
mark the block as accessible.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/memory-block.h

[Bug middle-end/67649] trunk build with valgrind fail in get_def_blocks_for

[miyuki at gcc dot gnu.org]

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

--- Comment #12 from Mikhail Maltsev  ---
(In reply to Markus Trippelsdorf from comment #10)
> A gave your patch a quick spin on gcc112 (compile farm machine).
> It fixes the issue.

Thanks, Markus. I committed the fix.

[Bug target/67391] [SH] Convert clrt addc to normal add insn

[olegendo at gcc dot gnu.org]

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

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

Tested on sh-elf, LRA enabled, with make -k check
RUNTESTFLAGS="--target_board=sh-sim\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"

I don't get any new failures.  Kaz, could you please patch try this in your
setup?

[Bug debug/67192] Backward-goto in loop can get wrong line number

[ppalka at gcc dot gnu.org]

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

--- Comment #12 from Patrick Palka  ---
(In reply to Manuel López-Ibáñez from comment #10)
> (In reply to Manuel López-Ibáñez from comment #8)
> > Does GCC work at all if input_location is saved and restored in
> > c_parser_peek_token? I guess not, it seems too much still relies in
> > input_location being magically right.
> 
> Perhaps you can add c_parser_peek_token_keep_input_location and use that
> where you are peeking the next token.

In the C++ frontend it looks like the entire file is lexed at startup and so
the cp_lexer_peek_token method does not change input_location (since
input_location is updated as a side effect of lexing a new token).  Instead,
the cp_lexer_consume_token method is responsible for updating input_location.

In the C frontend it looks like the reverse happens: tokens are lexed on demand
and so the c_parser_peek_token method does update input_location (as a side
effect of lexing the next token) and c_parser_consume_token does not change
input_location.

Would it be a good idea to make the C frontend behave more like the C++
frontend w.r.t. updating input_location? The behavior of the C++ frontend seems
more sensible to me. And I think such a change would fix this PR.

[Bug libstdc++/55815] switch hash function of libstdc++ hash tables to siphash

[felix-glibc at fefe dot de]

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

--- Comment #5 from felix-glibc at fefe dot de ---
How about you add SipHash and make it selectable at runtime.
Then I can file security bugs against all relevant programs not
selecting it for being vulnerable and glibc has their ass covered
regarding performance.

I mean seriously, you argue performance for a security measure?
Does Google turn off stack cookies in production? ACL checks?
All this password checking is making our code slow?
I sure hope not.

Also: Do you have any actual benchmarks proving siphash would make a
noticeable impact?

[Bug tree-optimization/67690] New: wrong code with -O2 on x86_64/Linux

[eriksnga at gmail dot com]

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

Bug ID: 67690
   Summary: wrong code with -O2 on x86_64/Linux
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eriksnga at gmail dot com
  Target Milestone: ---

Created attachment 36374
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36374=edit
prepocessed source code

gcc-5.2.0 produces wrong code on x86_64-suse-linux (Intel/AMD) at -O2 and
higher.

gcc-4.9.1 on same platforms does not reproduce the problem.

Adding any of

 -fno-inline-small-functions
 -fno-tree-pre
 -fno-tree-tail-merge
 -fno-tree-vrp

restores the correct behaviour at -O2.



$ gcc-5.2.0 -v
Using built-in specs.
COLLECT_GCC=/opt/sandbox/gcc/5.2.0/bin/gcc
COLLECT_LTO_WRAPPER=/opt/sandbox/gcc/5.2.0/lib/gcc/x86_64-suse-linux/5.2.0/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../../gcc-5.2.0/configure --enable-languages=c,c++,fortran
--enable-targets=x86_64-suse-linux,i686-suse-linux
--prefix=/opt/sandbox/gcc/5.2.0 --with-gnu-as
--with-as=/opt/sandbox/gcc/binutils-2.25.1/bin/as --with-gnu-ld
--with-ld=/opt/sandbox/gcc/binutils-2.25.1/bin/ld.gold
--with-gmp=/opt/sandbox/gcc/gmp-5.0.1 --with-mpfr=/opt/sandbox/gcc/mpfr-3.0.0
--with-mpc=/opt/sandbox/gcc/mpc-0.8.2 --enable-threads=posix --enable-shared
--enable-__cxa_atexit --enable-libstdcxx-allocator=pool x86_64-suse-linux
Thread model: posix
gcc version 5.2.0 (GCC) 
$
$
$ gcc-5.2.0 -pedantic-errors -Werror -Wall -Wextra -O2 testcase.c && ./a.out
Aborted
$ 



$ echo ; cat testcase.c ; echo

const int c1 = 1; /* >= 0 */
const int c2 = 2;

int check(int i)
{
  int j;
  if (i >= 0)
j = c2 - i;
  else
j = c2 - i;
  return c2 - c1 + 1 > j; /* c2 - c1 + 1 > c2 - c1 for i == c1 */
}

int invoke(int* pi) __attribute__ ((noinline,noclone));
int invoke(int* pi) { return check(*pi); }

int main() 
{
  int i = c1;
  int ret = invoke();
  if (!ret) __builtin_abort();
  return 0;
}

$

[Bug tree-optimization/67690] wrong code with -O2 on x86_64/Linux

[eriksnga at gmail dot com]

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

--- Comment #1 from Erik Volk  ---
Created attachment 36375
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36375=edit
full output from gcc -v

[Bug tree-optimization/59124] [4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds"

[manu at gcc dot gnu.org]

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

--- Comment #33 from Manuel López-Ibáñez  ---
(In reply to baoshan from comment #32)
> And I think it is not wrong, it's just inaccurate, and it is not making any
> wrong result in running time.
> 
> Can you point me how to proceed?

To be honest, I don't know, since neither loop-unrolling nor VRP are my
speciality. If you can figure out how the estimate can be improved in cunrolli,
that would be great. There are some functions called after that point that seem
to attempt to provide a more accurate estimate. One would need to go through
them carefully in GDB and find out why they fail. 

If itl cannot be fixed here, the info about valid ranges is still inaccurate,
that is, the loop may be unrolled into 6 iterations, but only 4 are ever
executed. There must be a way to teach VRP that this is the case and mark the
blocks as unreachable.

I hope other more knowledgeable devs will chime in, I'm out of ideas.

[Bug c++/67685] New: ICE on invalid requires expression

[colu...@gmx-topmail.de]

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

Bug ID: 67685
   Summary: ICE on invalid requires expression
   Product: gcc
   Version: c++-concepts
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: colu...@gmx-topmail.de
  Target Milestone: ---

void f(auto i) {requires {i;};}

int main() {f(0);}

=>

prog.cc: In instantiation of 'void f(auto:1) [with auto:1 = int]':
prog.cc:3:16:   required from here
prog.cc:1:17: internal compiler error: in tsubst_copy, at cp/pt.c:13689
 void f(auto i) {requires {i;};}
 ^
0x5ebae8 tsubst_copy
/home/heads/gcc/gcc-source/gcc/cp/pt.c:13689
0x5ec1f9 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:16451
0x5e8201 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:15257
0x6dcd39 tsubst_simple_requirement
/home/heads/gcc/gcc-source/gcc/cp/constraint.cc:1506
0x6dcd39 tsubst_requirement
/home/heads/gcc/gcc-source/gcc/cp/constraint.cc:1562
0x6dcd39 tsubst_requirement_body
/home/heads/gcc/gcc-source/gcc/cp/constraint.cc:1585
0x6dcd39 tsubst_requires_expr(tree_node*, tree_node*, int, tree_node*)
/home/heads/gcc/gcc-source/gcc/cp/constraint.cc:1616
0x5ed221 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:16609
0x5e8201 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:15257
0x5e7293 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:14668
0x5e8095 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:14840
0x5e6e31 instantiate_decl(tree_node*, int, bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:21387
0x60233b instantiate_pending_templates(int)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:21502
0x61fa4d c_parse_final_cleanups()
/home/heads/gcc/gcc-source/gcc/cp/decl2.c:4570


This code is ill-formed as per [expr.prim.req]/4, anyway; The
requires-expression is not allowed in an expression-statement.

[Bug c/48885] missed optimization with restrict qualifier?

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org,
   ||vries at gcc dot gnu.org

--- Comment #10 from vries at gcc dot gnu.org ---
The current implementation of restrict is based on clique/base pairs.

For the example
...
void
test (int *a, int *b, int * restrict v)
{
  *a = *v;
  *b = *v;
}
...
we get *v annotated with clique/base 1/1.

I wonder if we can reserve a base in each clique as non-restrict base, and
annotate like this:
- *a : 1/non-restrict
- *b : 1/non-restrict
- *v : 1/1

This way:
- *a and *b would still potentially alias
- *a and *v would be disambiguated, and
- not annotated memory references would not be impacted


This would only work with top-level restrict though. We would have to take care
in an example like this:
...
void
f (int *__restrict__ &__restrict__ p, int *p2)
{
  *p = 1;
  *p2 = 2;
}

void
g (int *__restrict__ gp)
{
  f (gp, gp);
}
...

Currently we annotate this as:
...
void f(int* __restrict__&, int*) (intD.9 * restrict & restrict pD.2252, intD.9
* p2D.2253)
{
  intD.9 * _3;

  # VUSE <.MEM_1(D)>
  # PT = { D.2265 } (nonlocal)
  _3 = MEM[(intD.9 * restrict &)p_2(D) clique 1 base 1];

  # .MEM_4 = VDEF <.MEM_1(D)>
  MEM[(intD.9 *)_3 clique 1 base 2] = 1;

  # .MEM_6 = VDEF <.MEM_4>
  *p2_5(D) = 2;
...

In this case, p2 cannot alias with clique 1/base 1, since it's a toplevel
restrict. But p2 can alias with clique 1/base 2, because it's not a toplevel
restrict.

So, if we f.i. register MR_DEPENDENCE_TOPLEVEL (in addition to
MR_DEPENDENCE_CLIQUE and MR_DEPENDENCE_BASE), we can disambiguate:
- normal bases within the same clique if they're different, and
- a non-restrict base vs a toplevel base.

[Bug libstdc++/55815] switch hash function of libstdc++ hash tables to siphash

[gpike at google dot com]

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

Geoff Pike  changed:

   What|Removed |Added

 CC||gpike at google dot com

--- Comment #4 from Geoff Pike  ---
I'm working on a higher-difficulty-higher-payoff approach to hash-flood
mitigation. It admittedly has a long way to go, but for those interested, an
early draft is https://gcc.gnu.org/ml/gcc-patches/2015-09/txtLiT8K2xyw4.txt

With chaining hashtables (and perhaps others), there continues to be a hash
flooding problem no matter how good the hash function: there's a timing attack
that can force the attackee to do some constant times n^1.5 computational steps
for n steps by the attacker.  Whether this attack matters in real life is
unclear to me, but I believe it is a realistic threat. By using a smarter data
structure one can avoid the n^1.5 worst case, and also use a fast hash function
when, happily, no hash flooding attack is in progress.

Meanwhile, is SipHash useful? Maybe. It is slow, so perhaps a more modern
competitor could be constructed, if one doesn't exist. On machines with fast
multiplication (and/or CRC, pshufb, SIMD, ...), one is likely better off using
those features, and SipHash does not get enough out of those features to be
speedy.

[Bug rtl-optimization/67604] shrink-wrap doesn't allow multiple entries

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #2 from Segher Boessenkool  ---
Fixed with r228022.

[Bug libstdc++/55815] switch hash function of libstdc++ hash tables to siphash

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

 CC||miyuki at gcc dot gnu.org

--- Comment #6 from Mikhail Maltsev  ---
SipHash is not very slow, BTW. I remember doing some benchmarks (there was some
discussion about changing the hash function used for incremental hash in GCC),
https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00179.html

Result for small strings (1-20 bytes) on x86_64, elapsed time (i.e. less is
better):

function  | gcc -O3 | clang -O3
--|-|--
murmur32  |   0.91  |   0.95 
murmur128 |   1.33  |   1.24 
sip24 |   1.88  |   1.45 
sip13 |   1.66  |   1.22 
lookup3   |   1.18  |   0.90 
spooky|   1.24  |   0.90 

I don't remember all the details about the workload used and which
implementation of SipHash I used (but most likely my own one).

(In reply to felix-gcc from comment #0)
> It may even make sense to replace the hash code gcc itself uses, as there
> are now web pages where you can paste code and see which code gcc generates
> for it, turning this problem into a security issue if someone pastes code
> with colliding symbols to exploit this problem.

There is a much more efficient way to attack them: search GCC bugzilla for open
bugs of type "compile time hog" or "memory hog" and simply use the code
provided there.

[Bug c++/67692] New: [concepts] ICE when using requires in non-concept contexts

[ryan.burn at gmail dot com]

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

Bug ID: 67692
   Summary: [concepts] ICE when using requires in non-concept
contexts
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryan.burn at gmail dot com
  Target Milestone: ---

The below code produces an ICE compiling with -std=c++1z:


template
bool f(T x) {
  return requires(T x) {
++x;
  };
}

int main() {
  f(3);
  return 0;
}


Stack trace:
main.cpp: In function ‘bool f(T) [with T = int]’:
main.cpp:5:3: internal compiler error: in gimplify_expr, at gimplify.c:8848
   };
   ^
0xa99c53 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:8848
0xaa6bc0 gimplify_modify_expr
../../gcc/gcc/gimplify.c:4625
0xa979d2 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:8116
0xa9bb96 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gcc/gimplify.c:5526
0xa990d6 gimplify_and_add(tree_node*, gimple_statement_base**)
../../gcc/gcc/gimplify.c:398
0xa990d6 gimplify_return_expr
../../gcc/gcc/gimplify.c:1291
0xa990d6 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:8363
0xa9bb96 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gcc/gimplify.c:5526
0xa9d929 gimplify_body(tree_node*, bool)
../../gcc/gcc/gimplify.c:9250
0xa9df46 gimplify_function_tree(tree_node*)
../../gcc/gcc/gimplify.c:9408
0x92ccd7 cgraph_node::analyze()
../../gcc/gcc/cgraphunit.c:636
0x92fedb analyze_functions
../../gcc/gcc/cgraphunit.c:1028
0x930a68 symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2477
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/67680] Seg Fault in gcc 4.9.3 compiling libiberty/floatformat.c when building gcc 5.2.1 on Cygwin 64 on Windows

[bplummer at hotmail dot com]

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

Brian Plummer  changed:

   What|Removed |Added

 CC||bplummer at hotmail dot com

--- Comment #2 from Brian Plummer  ---
Created attachment 36376
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36376=edit
floatformat.preprocessed.c

As requested.

[Bug c/67680] Seg Fault in gcc 4.9.3 compiling libiberty/floatformat.c when building gcc 5.2.1 on Cygwin 64 on Windows

[bplummer at hotmail dot com]

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

--- Comment #3 from Brian Plummer  ---
As requested.

[Bug target/67691] New: [SH] Omit zero extension of shift amounds for dynamic shifts

[olegendo at gcc dot gnu.org]

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

Bug ID: 67691
   Summary: [SH] Omit zero extension of shift amounds for dynamic
shifts
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olegendo at gcc dot gnu.org
  Target Milestone: ---
Target: sh*-*-*

In CSiBE I've seen code that goes like this ...

left shift:
 mov.b@(...),r0
 extu.b   r0,r1
 ...
 shld r1,r2

right shift:
 mov.b@(...),r0
 extu.b   r0,r1
 neg  r1,r1
 ...
 shld r1,r2

In both cases the zero extension can be omitted.  The shld/shad shift count is
truncated to a 5 bit and as per C/C++ standard shift counts > 31 or negative
shift counts are undefined behavior for int32_t/uint32_t.

If a shift count value is loaded from memory and is not explicitly AND'ed with
31, it can be assumed that the value is in the range 0..31.

For example

value in mem  signed ext.  unsigned ext.
0...310...31   0...31   OK
3333   33   NG
255   255  -1   NG

I can't think of a case where keeping the zero extension would avoid undefined
behavior.

[Bug c/67680] Seg Fault in gcc 4.9.3 compiling libiberty/floatformat.c when building gcc 5.2.1 on Cygwin 64 on Windows

[bplummer at hotmail dot com]

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

--- Comment #4 from Brian Plummer  ---
I had these comments in my message, but they got lost when I added my
attachment.

floatformat.preprocessed.c was created with this command :

Brian@MBPWin7-64 ~/gnu/gcc/gcc-5.2.0/libiberty
$ gcc -E -c -DHAVE_CONFIG_H -g  -I. -I../build/libiberty/ -I../include  -W
-Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  floatformat.c
-o floatformat.preprocessed.c

compiling floatformat.preprocessed.c :

Brian@MBPWin7-64 ~/gnu/gcc/gcc-5.2.0/libiberty
$ gcc -c floatformat.preprocessed.c -o floatformat.o
floatformat.c: In function ‘floatformat_to_double’:
floatformat.c:529:2: internal compiler error: Segmentation fault
  dto = ldexp (1.0, exponent);
  ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Machine and compiler details are in an earlier post.

[Bug target/67321] [ARM] Exploit Wide Add operations when appropriate

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-09-22
 CC||ramana at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |michael.collison at 
linaro dot org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #2 from Ramana Radhakrishnan  ---
Confirmed.

[Bug c/66454] Common -Wmisleading-indentation false-positive triggered in the Linux kernel

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ppalka at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Patrick Palka  ---
Fixed as part of r226479.

[Bug c++/67686] New: [concepts] segfault in finish_call_expr function

[ryan.burn at gmail dot com]

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

Bug ID: 67686
   Summary: [concepts] segfault in finish_call_expr function
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryan.burn at gmail dot com
  Target Milestone: ---

Created attachment 36372
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36372=edit
preprocessed code

The attached code causes a segfault with gcc 6.0 when compiling with
-std=c++1z. Here's the stack trace:


In file included from
/home/rnburn/proj/echo/htl/include/echo/htl/algorithm.h:10:0,
 from /home/rnburn/proj/echo/htl/unittest/algorithm.cpp:1:
/home/rnburn/proj/echo/htl/include/echo/htl/concept.h: In instantiation of
‘constexpr const bool echo::htl::detail_concept::mappable_elements’:
/home/rnburn/proj/echo/htl/include/echo/htl/concept.h:70:22:   required from
‘constexpr const bool echo::htl::detail_concept::mappable_impl’
/home/rnburn/proj/echo/htl/unittest/algorithm.cpp:60:23:   required from here
/home/rnburn/proj/echo/htl/include/echo/htl/concept.h:40:66: internal compiler
error: Segmentation fault
 requires cpt_CopyConstructible**, int)
../../gcc/gcc/cp/call.c:4390
0x7901ba finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/gcc/cp/semantics.c:2408
0x68131f tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:15872
0x661a6c tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:13138
0x67cd12 tsubst_template_args
../../gcc/gcc/cp/pt.c:10839
0x660054 tsubst_aggr_type
../../gcc/gcc/cp/pt.c:11036
0x6621dc tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:12505
0x67e7ea tsubst_qualified_id
../../gcc/gcc/cp/pt.c:13335
0x68081b tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:15452
0x66aad1 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:15044
0x823207 satisfy_predicate_constraint
../../gcc/gcc/cp/constraint.cc:1694
0x823207 satisfy_constraint_1
../../gcc/gcc/cp/constraint.cc:1898
0x8235cd satisfy_parameterized_constraint
../../gcc/gcc/cp/constraint.cc:1841
0x8235cd satisfy_constraint_1
../../gcc/gcc/cp/constraint.cc:1916
0x823f76 satisfy_constraint
../../gcc/gcc/cp/constraint.cc:1949
0x605b94 build_new_function_call(tree_node*, vec**, bool, int)
../../gcc/gcc/cp/call.c:4130
0x78ff5e finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/gcc/cp/semantics.c:2391
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/66755] [ARM] TARGET_ASM_OUTPUT_MI_THUNK should be rewritten to an RTL implementation

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-22
 Ever confirmed|0   |1

--- Comment #1 from Ramana Radhakrishnan  ---
Confirmed.

[Bug c++/67687] New: [c++0x][constexpr] initialize constexpr member with constexpr constructor

[crosetto at lifev dot org]

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

Bug ID: 67687
   Summary: [c++0x][constexpr] initialize constexpr member with
constexpr constructor
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crosetto at lifev dot org
  Target Milestone: ---

the following code doesn't compile with gcc 5.1
error:
internal compiler error: unexpected expression '(const
accessor_base){dimension{0}}' of kind implicit_conv_expr
 static constexpr accessor_base s_args_constexpr{dimension{0}
};

//CODE:
template 
struct dimension{
template
constexpr dimension(T...t){}
};

struct accessor_base{
template
constexpr accessor_base(T...t){}
};

template 
struct accessor_mixed{

private:
static constexpr accessor_base s_args_constexpr{dimension{0}
};
};

[Bug rtl-optimization/67676] Implicit alignment of struct not applied to members

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

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

[Bug tree-optimization/62171] restrict pointer to struct with restrict pointers parm doesn't prevent aliases

[vries at gcc dot gnu.org]

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

--- Comment #8 from vries at gcc dot gnu.org ---
(In reply to Richard Biener from comment #7)
> I was thinking about sth like
> 
> struct X { int i; int * __restrict__ q; };
> 
> int foo (X& __restrict__ x, X *p)
> {
>   *x.q = 1;
>   p->i = 0;
>   return *x.q;
> }
> 
> int main()
> {
>   X x;
>   x.q = 
>   return foo (x, );
> }
> 

I think this example's an invalid use of restrict.

By using restrict in the 'X& __restrict__ x' parameter of foo, we promise that
if the object x points to is modified during foo execution (and it is, by both
assignments) we only access the object using pointers based on x during foo
execution.

p is pointing to the same object, and we access the object via p. But p is not
based on x.

[Bug target/67677] [6 Regression] r226005 causes "Conditional jump or move depends on uninitialised value(s)"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug tree-optimization/66952] [6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Author: rguenth
Date: Tue Sep 22 07:47:21 2015
New Revision: 227995

URL: https://gcc.gnu.org/viewcvs?rev=227995=gcc=rev
Log:
2015-09-22  Richard Biener  

Backport from mainline
2015-07-23  Richard Biener  

PR tree-optimization/66952
* gcc.dg/torture/pr66952.c: Use signed char.

Modified:
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr66952.c

[Bug tree-optimization/67671] restrict pointer reference looses restrict

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
I think the patch is reasonable.

[Bug bootstrap/67672] [6 regression] Ada "Storage_Error stack overflow or erroneous memory access" error breaks sparc-linux bootstrap

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Botcazou  ---
.

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

[Bug bootstrap/67622] [6 regression] Solaris/SPARC bootstrap fails compiling stage2 stdc++.h.gch/O2ggnu++0x.gch

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #6 from Eric Botcazou  ---
*** Bug 67672 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/62171] restrict pointer to struct with restrict pointers parm doesn't prevent aliases

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
I was thinking about sth like

struct X { int i; int * __restrict__ q; };

int foo (X& __restrict__ x, X *p)
{
  *x.q = 1;
  p->i = 0;
  return *x.q;
}

int main()
{
  X x;
  x.q = 
  return foo (x, );
}

but I see we're still conservatively requiring decls in visit_loadstore:

  tree ptr = TREE_OPERAND (base, 0);
  if (TREE_CODE (ptr) == SSA_NAME)
{
  /* ???  We need to make sure 'ptr' doesn't include any of
 the restrict tags in its points-to set.  */
  return false;

Of course this kind of testcase would also break if X were passed by
value (and changed by the frontend to DECL_BY_REFERENCE).  That is,
using the 2nd level restrict sounds bogus iff there can be a testcase
that can be created by the user (thus is not under strict control by
the compiler).


That said, generally the tree-ssa-structalias.c:visit_loadstore needs
some more sophistication as well.

[Bug tree-optimization/67666] single restrict pointer in struct looses restrict

[vries at gcc dot gnu.org]

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

--- Comment #4 from vries at gcc dot gnu.org ---
Author: vries
Date: Tue Sep 22 08:15:32 2015
New Revision: 227996

URL: https://gcc.gnu.org/viewcvs?rev=227996=gcc=rev
Log:
Handle single restrict pointer in struct in create_variable_info_for_1

2015-09-22  Tom de Vries  

PR tree-optimization/67666
* tree-ssa-structalias.c (create_variable_info_for_1): Handle struct
with single field non-conservative.

* g++.dg/pr67666.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/pr67666.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-structalias.c

[Bug tree-optimization/67666] single restrict pointer in struct looses restrict

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from vries at gcc dot gnu.org ---
committed patch with test-case, marking resolved-fixed.

[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE

[bonzini at gnu dot org]

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

--- Comment #29 from Paolo Bonzini  ---
> While getting familiar with DF problems, I noticed that LIVE's ignores
> the order of GENs and KILLs in basic blocks. In other words, the
> transfer function for: GEN(r1); KILL(r1) is currently the same as for
> KILL(r1); GEN(r1) whereas clearly the former leaves r1 unitialized
> whereas the latter leaves it initialized.

GEN and KILL are not the same for LR and MIR.

1) Sets and clobbers are handled differently.  A set or clobber of r1 _kills_
liveness, while for MIR sets _generate_ "initialized-ness" and only clobbers
kill it.

2) A use of r1 _creates_ liveness (which extends up, until it reaches the sets
for all reaching definitions of that use), while uses of r1 are irrelevant for
MIR.

3) For LR, GEN must override KILL if an insn has both a set and a use of r1. 
For MIR, you cannot have a GEN (set) and a KILL (clobber) in the same insn.

BTW, are you sure that

+  if (DF_REF_FLAGS_IS_SET (def,
+  DF_REF_PARTIAL | DF_REF_CONDITIONAL))
+   /* All partial or conditional def
+  seen are included in the gen set. */
+   bitmap_set_bit (gen, regno);

?  I would have thought they don't belong in any set, and on the contrary I
would have thought that may-clobber definitions count as kills.

[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE

[bonzini at gnu dot org]

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

--- Comment #31 from Paolo Bonzini  ---
Ah, I see now.  I think you're right that the DF_REF_MUST_CLOBBER case should
also clear GEN in df_live_bb_local_compute.

However, regarding the "BTW" I am fairly sure now that df_live_bb_local_compute
and the corresponding function for MIR should handle may-clobber and may-sets
differently.  If you think of may-clobber and may-set as a diamond-shaped CFG:

 ..
/ \  / \
   /   \/   \
  clobber   |  set   |
  \/\/
   \  /  \  /
\/\/

Then at the join point you have an "OR" for LIVE (so the clobber's KILL
disappears and the set's GEN remains), and an "AND" for MIR.  For MIR the
clobber's KILL remains and the set's GEN disappears.

[Bug tree-optimization/67476] Add --param parloops-schedule=<static|dynamic|guided|auto|runtime>

[vries at gcc dot gnu.org]

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

--- Comment #8 from vries at gcc dot gnu.org ---
Pinged: https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01623.html

[Bug tree-optimization/50417] regression: memcpy with known alignment

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
*** Bug 67676 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE

[ebotcazou at gcc dot gnu.org]

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

--- Comment #30 from Eric Botcazou  ---
> GEN and KILL are not the same for LR and MIR.
> 
> 1) Sets and clobbers are handled differently.  A set or clobber of r1
> _kills_ liveness, while for MIR sets _generate_ "initialized-ness" and only
> clobbers kill it.
> 
> 2) A use of r1 _creates_ liveness (which extends up, until it reaches the
> sets for all reaching definitions of that use), while uses of r1 are
> irrelevant for MIR.
> 
> 3) For LR, GEN must override KILL if an insn has both a set and a use of r1.
> For MIR, you cannot have a GEN (set) and a KILL (clobber) in the same insn.

The issue is not LR vs MIR, it's the may-initialized part of LIVE vs MIR.

It seem to me that the GEN and KILL of the may-initialized part of LIVE should
be the same as those of MIR, since the difference between the 2 problems is
only at the global level.  Pierre-Marie's patch duplicates them, but ideally
they should be factored and reused.

[Bug c++/67678] New: Nested class can be re-declared after definition

[redi at gcc dot gnu.org]

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

Bug ID: 67678
   Summary: Nested class can be re-declared after definition
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

This should give a diagnostic:

struct A { struct B{}; struct B; };

9.2 [class.mem] p1:

   A member shall not be declared twice in the member-specification,
   except that a nested class or member class template can be declared
   and then later defined, [...]


Clang warns:

x.cc:1:31: warning: class member cannot be redeclared
[-Wredeclared-class-member]
struct A { struct B{}; struct B; };
  ^
x.cc:1:19: note: previous declaration is here
struct A { struct B{}; struct B; };
  ^
1 warning generated.

EDG warns:

"x.cc", line 1: warning: invalid redeclaration of nested class
  struct A { struct B{}; struct B; };
^

[Bug target/65782] Assembly failure (invalid register for .seh_savexmm) with -O3 -mavx512f on mingw-w64

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

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

--- Comment #1 from Kai Tietz  ---
This issue is related to output in gcc for SEH-prologue pseudos.  It tries to
output registers not being supported 8-byte SSE ones.

Generally, AVX512 can't be supported in an 32-byte aligned way on x64 target
anyway.

[Bug target/67480] AVX512 bitwise logic operations pattern is incorrect

[kyukhin at gcc dot gnu.org]

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

--- Comment #4 from Kirill Yukhin  ---
Author: kyukhin
Date: Tue Sep 22 11:14:25 2015
New Revision: 228010

URL: https://gcc.gnu.org/viewcvs?rev=228010=gcc=rev
Log:
PR target/67480

gcc/
* config/i386/sse.md (define_mode_iterator VI48_AVX_AVX512F): New.
(define_mode_iterator VI12_AVX_AVX512F): New.
(define_insn "3"): Change
all iterators to VI48_AVX_AVX512F. Extract remaining modes ...
(define_insn "*3"): ... Into new pattern using
VI12_AVX_AVX512F iterators without masking.

gcc/testsuite/
* gcc.target/i386/pr67480.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr67480.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

[Bug libgomp/67141] wrong libgomp mutex initialisation order

[cltang at gcc dot gnu.org]

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

--- Comment #7 from Chung-Lin Tang  ---
Author: cltang
Date: Tue Sep 22 11:18:23 2015
New Revision: 228011

URL: https://gcc.gnu.org/viewcvs?rev=228011=gcc=rev
Log:
2015-09-22  Chung-Lin Tang  

Backport from mainline:

2015-09-22  Chung-Lin Tang  

PR libgomp/67141
* oacc-int.h (goacc_host_init): Add declaration.
* oacc-host.c (goacc_host_init): Remove static and constructor
attribute.
* oacc-init.c (goacc_runtime_initialize): Call goacc_host_init() at
end.


Modified:
branches/gcc-5-branch/libgomp/ChangeLog
branches/gcc-5-branch/libgomp/oacc-host.c
branches/gcc-5-branch/libgomp/oacc-init.c
branches/gcc-5-branch/libgomp/oacc-int.h

[Bug target/67480] AVX512 bitwise logic operations pattern is incorrect

[afomin.mailbox at gmail dot com]

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

Alexander Fomin  changed:

   What|Removed |Added

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

--- Comment #5 from Alexander Fomin  ---
Please note that my previous comment is misleading: forced instruction mode
implies no masking at all.

[Bug c++/54895] the compiler treats '__cdecl' & '__stdcall' as the same.

[ktietz at gcc dot gnu.org]

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

--- Comment #12 from Kai Tietz  ---
This bug got partially fixed for x86 (32-bit) by PR/44282.  For x64 we have the
issue that there is made no difference between different calling-conventions,
as all variants are treated as standard fastcall-convention under the hood.

[Bug tree-optimization/62171] restrict pointer to struct with restrict pointers parm doesn't prevent aliases

[vries at gcc dot gnu.org]

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

--- Comment #10 from vries at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #9)
> On Tue, 22 Sep 2015, vries at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62171
> > 
> > --- Comment #8 from vries at gcc dot gnu.org ---
> > (In reply to Richard Biener from comment #7)
> > > I was thinking about sth like
> > > 
> > > struct X { int i; int * __restrict__ q; };
> > > 
> > > int foo (X& __restrict__ x, X *p)
> > > {
> > >   *x.q = 1;
> > >   p->i = 0;
> > >   return *x.q;
> > > }
> > > 
> > > int main()
> > > {
> > >   X x;
> > >   x.q = 
> > >   return foo (x, );
> > > }
> > > 
> > 
> > I think this example's an invalid use of restrict.
> > 
> > By using restrict in the 'X& __restrict__ x' parameter of foo, we promise 
> > that
> > if the object x points to is modified during foo execution (and it is, by 
> > both
> > assignments) we only access the object using pointers based on x during foo
> > execution.
> > 
> > p is pointing to the same object, and we access the object via p. But p is 
> > not
> > based on x.
> 
> Sorry, I modified it bogously, just move int i; out of the struct and
> somewhere else.

I don't understand. My reasoning above has nothing to do with 'int i'.

> My concerns boil down to X being passed twice,
> once as reference and once as pointer.

That's exactly the thing I was trying to point out as illegal use of restrict.
Let me try again, with variables renamed for clarity:

struct X { int i; int * __restrict__ q; };

int foo (X& __restrict__ foox, X *foop)
{
   *foox.q = 1;
   foop->i = 0;
   return *foox.q;
}

int main()
{
  X mainx;
  mainx.q = 
  return foo (mainx, );
}

By:
- using restrict for the foox parameter of foo, and
- modifing object mainx during foo execution
we promise that we only access the object mainx using pointers based on foox
during foo execution.

However, we access mainx via foop in foo, and foop is not based on foox.

[Bug middle-end/65965] Straight-line memcpy/memset not vectorized when equivalent loop is

[alalaw01 at gcc dot gnu.org]

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

--- Comment #4 from alalaw01 at gcc dot gnu.org ---
(In reply to Richard Biener from comment #3)
> Fixed for GCC 6.

Indeed. I note that the same testcase does _not_ SLP/vectorize if I use
consecutive indices:

void
test (int*__restrict a, int*__restrict b)
{
a[0] = b[0];
a[1] = b[1];
a[2] = b[2];
a[3] = b[3];
a[4] = 0;
a[5] = 0;
a[6] = 0;
a[7] = 0;
}

loop26a.c:6:13: note: Build SLP failed: different operation in stmt MEM[(int
*)a
_4(D) + 28B] = 0;
loop26a.c:6:13: note: original stmt *a_4(D) = _3;
loop26a.c:6:13: note: === vect_slp_analyze_data_ref_dependences ===
loop26a.c:6:13: note: === vect_slp_analyze_operations ===
loop26a.c:6:13: note: not vectorized: bad operation in basic block.

Worth another bug?

[Bug c++/67544] ICE: SIGSEGV in tree_check3 (tree.h:2896) with -fconcepts

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-22
 Blocks||67491
 Ever confirmed|0   |1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues

[Bug target/54412] Request for 32-byte stack alignment with -mavx on Windows

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |SUSPENDED
   Last reconfirmed||2015-09-22
 Ever confirmed|0   |1

--- Comment #12 from Kai Tietz  ---
It is good to hear that issue is fixed for 32-bit.  But for 64-bit - as I
already explained in comment above - this issue isn't fixable for
stack-variables.

The problem is that for x64 ABI we are tighten bound to SEH-prologue
information, and this can't express alignment-operations.  The x64 ABI
guarantee 16 byte alignment on function entry, therefore sse 128-bit operations
are possible to be placed fully aligned on stack, but higher alignment is
simply not expressible.

Therefore I will need to set this bug to suspended.  If this information gets
in future extended to allow such prologue-information we need for alignment,
then we will be able to fix that.  So long it is suspended.

[Bug tree-optimization/62171] restrict pointer to struct with restrict pointers parm doesn't prevent aliases

[rguenther at suse dot de]

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

--- Comment #9 from rguenther at suse dot de  ---
On Tue, 22 Sep 2015, vries at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62171
> 
> --- Comment #8 from vries at gcc dot gnu.org ---
> (In reply to Richard Biener from comment #7)
> > I was thinking about sth like
> > 
> > struct X { int i; int * __restrict__ q; };
> > 
> > int foo (X& __restrict__ x, X *p)
> > {
> >   *x.q = 1;
> >   p->i = 0;
> >   return *x.q;
> > }
> > 
> > int main()
> > {
> >   X x;
> >   x.q = 
> >   return foo (x, );
> > }
> > 
> 
> I think this example's an invalid use of restrict.
> 
> By using restrict in the 'X& __restrict__ x' parameter of foo, we promise that
> if the object x points to is modified during foo execution (and it is, by both
> assignments) we only access the object using pointers based on x during foo
> execution.
> 
> p is pointing to the same object, and we access the object via p. But p is not
> based on x.

Sorry, I modified it bogously, just move int i; out of the struct and
somewhere else.  My concerns boil down to X being passed twice,
once as reference and once as pointer.  The PTA machinery will
then use restrict for X.q for the reference case but not for
the pointer case.  I believe C doesn't specify what happens for
these "indirect" cases (nor for what happens for global restricts).

To behave "correctly" PTA would need to correlate q from both
parameters.

[Bug middle-end/65965] Straight-line memcpy/memset not vectorized when equivalent loop is

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On Tue, 22 Sep 2015, alalaw01 at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65965
> 
> --- Comment #4 from alalaw01 at gcc dot gnu.org ---
> (In reply to Richard Biener from comment #3)
> > Fixed for GCC 6.
> 
> Indeed. I note that the same testcase does _not_ SLP/vectorize if I use
> consecutive indices:
> 
> void
> test (int*__restrict a, int*__restrict b)
> {
> a[0] = b[0];
> a[1] = b[1];
> a[2] = b[2];
> a[3] = b[3];
> a[4] = 0;
> a[5] = 0;
> a[6] = 0;
> a[7] = 0;
> }
> 
> loop26a.c:6:13: note: Build SLP failed: different operation in stmt MEM[(int
> *)a
> _4(D) + 28B] = 0;
> loop26a.c:6:13: note: original stmt *a_4(D) = _3;
> loop26a.c:6:13: note: === vect_slp_analyze_data_ref_dependences ===
> loop26a.c:6:13: note: === vect_slp_analyze_operations ===
> loop26a.c:6:13: note: not vectorized: bad operation in basic block.
> 
> Worth another bug?

The above looks like if SLP is trying a vector size of v8si.  It
_should_ work for v4si.  For v8si we indeed can't vectorize this
as we don't support "partial" loads.  We could vectorize with
masked loads and IIRC on x86_64 the masked elements can be 
initialized to 0 or -1, so we can OR in the constant pieces.

Not sure if that's worth another bug, please double-check your
vector size first.

[Bug tree-optimization/62171] restrict pointer to struct with restrict pointers parm doesn't prevent aliases

[rguenther at suse dot de]

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

--- Comment #11 from rguenther at suse dot de  ---
On Tue, 22 Sep 2015, vries at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62171
> 
> --- Comment #10 from vries at gcc dot gnu.org ---
> (In reply to rguent...@suse.de from comment #9)
> > On Tue, 22 Sep 2015, vries at gcc dot gnu.org wrote:
> > 
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62171
> > > 
> > > --- Comment #8 from vries at gcc dot gnu.org ---
> > > (In reply to Richard Biener from comment #7)
> > > > I was thinking about sth like
> > > > 
> > > > struct X { int i; int * __restrict__ q; };
> > > > 
> > > > int foo (X& __restrict__ x, X *p)
> > > > {
> > > >   *x.q = 1;
> > > >   p->i = 0;
> > > >   return *x.q;
> > > > }
> > > > 
> > > > int main()
> > > > {
> > > >   X x;
> > > >   x.q = 
> > > >   return foo (x, );
> > > > }
> > > > 
> > > 
> > > I think this example's an invalid use of restrict.
> > > 
> > > By using restrict in the 'X& __restrict__ x' parameter of foo, we promise 
> > > that
> > > if the object x points to is modified during foo execution (and it is, by 
> > > both
> > > assignments) we only access the object using pointers based on x during 
> > > foo
> > > execution.
> > > 
> > > p is pointing to the same object, and we access the object via p. But p 
> > > is not
> > > based on x.
> > 
> > Sorry, I modified it bogously, just move int i; out of the struct and
> > somewhere else.
> 
> I don't understand. My reasoning above has nothing to do with 'int i'.
> 
> > My concerns boil down to X being passed twice,
> > once as reference and once as pointer.
> 
> That's exactly the thing I was trying to point out as illegal use of restrict.
> Let me try again, with variables renamed for clarity:
> 
> struct X { int i; int * __restrict__ q; };
> 
> int foo (X& __restrict__ foox, X *foop)
> {
>*foox.q = 1;
>foop->i = 0;
>return *foox.q;
> }
> 
> int main()
> {
>   X mainx;
>   mainx.q = 
>   return foo (mainx, );
> }
> 
> By:
> - using restrict for the foox parameter of foo, and
> - modifing object mainx during foo execution
> we promise that we only access the object mainx using pointers based on foox
> during foo execution.
> 
> However, we access mainx via foop in foo, and foop is not based on foox.

Hmm, indeed.  I guess we're fine then and could lift the restriction
even more via

Index: gcc/tree-ssa-structalias.c
===
--- gcc/tree-ssa-structalias.c  (revision 228010)
+++ gcc/tree-ssa-structalias.c  (working copy)
@@ -5857,9 +5953,8 @@ intra_create_variable_infos (struct func
   /* For restrict qualified pointers to objects passed by
  reference build a real representative for the pointed-to object.
 Treat restrict qualified references the same.  */
-  if (TYPE_RESTRICT (TREE_TYPE (t))
- && ((DECL_BY_REFERENCE (t) && POINTER_TYPE_P (TREE_TYPE (t)))
- || TREE_CODE (TREE_TYPE (t)) == REFERENCE_TYPE)
+  if (POINTER_TYPE_P (TREE_TYPE (t))
+ && TYPE_RESTRICT (TREE_TYPE (t))
  && !type_contains_placeholder_p (TREE_TYPE (TREE_TYPE (t
{
  struct constraint_expr lhsc, rhsc;

[Bug tree-optimization/67671] restrict pointer reference looses restrict

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from vries at gcc dot gnu.org ---
patch with test-case committed, marking resolved-fixed

[Bug tree-optimization/67671] restrict pointer reference looses restrict

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from vries at gcc dot gnu.org ---
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01636.html

[Bug sanitizer/64906] -fsanitize=integer-divide-by-zero creates false -Wmaybe-uninitialized warning

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
int
testf (int f, int s)
{
  int ret = 0;
  if (f)
ret = s / (f ? (unsigned long) 8 : 0);
  return ret;
}

[Bug sanitizer/64906] -fsanitize=integer-divide-by-zero creates false -Wmaybe-uninitialized warning

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
I'm testing a fix.

[Bug tree-optimization/67671] restrict pointer reference looses restrict

[vries at gcc dot gnu.org]

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

--- Comment #3 from vries at gcc dot gnu.org ---
Author: vries
Date: Tue Sep 22 14:14:56 2015
New Revision: 228015

URL: https://gcc.gnu.org/viewcvs?rev=228015=gcc=rev
Log:
Handle restrict pointer references as restrict in AA

2015-09-22  Tom de Vries  

PR tree-optimization/67671
* tree-ssa-structalias.c (create_variable_info_for_1): Handle restrict
pointer references as restrict.

* g++.dg/pr67671.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/pr67671.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-structalias.c

[Bug fortran/67679] New: -Wunitialized reports on compiler generated variables

[Joost.VandeVondele at mat dot ethz.ch]

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

Bug ID: 67679
   Summary: -Wunitialized reports on compiler generated variables
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Joost.VandeVondele at mat dot ethz.ch
  Target Milestone: ---

With gcc 5.2 I see:

> gfortran -c -g -O2 -Wuninitialized -cpp bug.f90
bug.f90:15:0:

   DIMENSION(:, :, :) :: work
 ^
Warning: ‘work.dim[2].stride’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
bug.f90:15:0: Warning: ‘work.dim[1].stride’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
bug.f90:15:0: Warning: ‘work.offset’ may be used uninitialized in this function
[-Wmaybe-uninitialized]

where the problem is that compiler generated variables appear in the output. 
(.stride happens x178, .ubound x 111 and .lbound x9 in a CP2K compile).

Some strange forms (not in this testcase) include also :

‘MEM[(integer(kind=4)[2] *)_stat][1]’ may be used uninitialized in this
function

should I try to reduce a testcase for the latter ?

testcase:

> cat bug.f90
MODULE memory_utilities
  INTEGER, PARAMETER :: dp=8, dp_size=8
  CHARACTER(len=*), PARAMETER, PRIVATE :: moduleN = 'memory_utilities'
CONTAINS
  SUBROUTINE reallocate_c3(p,lb1_new,ub1_new,lb2_new,ub2_new,lb3_new,ub3_new)
COMPLEX(KIND=dp), DIMENSION(:, :, :), &
  POINTER:: p
INTEGER, INTENT(IN)  :: lb1_new, ub1_new, lb2_new, &
ub2_new, lb3_new, ub3_new
CHARACTER(LEN=*), PARAMETER :: routineN = 'reallocate_c3', &
  routineP = moduleN//':'//routineN
COMPLEX(KIND=dp), PARAMETER  :: zero = (0.0_dp,0.0_dp)
INTEGER, PARAMETER   :: t_size = 2*dp_size
COMPLEX(KIND=dp), ALLOCATABLE, &
  DIMENSION(:, :, :) :: work

INTEGER :: istat, lb1, lb1_old, lb2, lb2_old, lb3, lb3_old, &
  ub1, ub1_old, ub2, ub2_old, ub3, ub3_old

IF (ASSOCIATED(p)) THEN
   lb1_old = LBOUND(p,1)
   ub1_old = UBOUND(p,1)
   lb2_old = LBOUND(p,2)
   ub2_old = UBOUND(p,2)
   lb3_old = LBOUND(p,3)
   ub3_old = UBOUND(p,3)
   lb1 = MAX(lb1_new,lb1_old)
   ub1 = MIN(ub1_new,ub1_old)
   lb2 = MAX(lb2_new,lb2_old)
   ub2 = MIN(ub2_new,ub2_old)
   lb3 = MAX(lb3_new,lb3_old)
   ub3 = MIN(ub3_new,ub3_old)
   ALLOCATE (work(lb1:ub1,lb2:ub2,lb3:ub3),STAT=istat)
   IF (istat /= 0) THEN
  CALL stop_memory(routineN,moduleN,__LINE__,&
   "work",t_size*(ub1-lb1+1)*&
 (ub2-lb2+1)*&
 (ub3-lb3+1))
   END IF
   work(lb1:ub1,lb2:ub2,lb3:ub3) = p(lb1:ub1,lb2:ub2,lb3:ub3)
   DEALLOCATE (p)
END IF

ALLOCATE (p(lb1_new:ub1_new,lb2_new:ub2_new,lb3_new:ub3_new),STAT=istat)
IF (istat /= 0) THEN
   CALL stop_memory(routineN,moduleN,__LINE__,&
"p",t_size*(ub1_new-lb1_new+1)*&
   (ub2_new-lb2_new+1)*&
   (ub3_new-lb3_new+1))
END IF
p(:,:,:) = zero

IF (ASSOCIATED(p).AND.ALLOCATED(work)) THEN
   p(lb1:ub1,lb2:ub2,lb3:ub3) = work(lb1:ub1,lb2:ub2,lb3:ub3)
   DEALLOCATE (work)
END IF
  END SUBROUTINE reallocate_c3
END MODULE memory_utilities

[Bug c++/58074] [C++11][DR 1333] __is_trivial intrinsic fails for deleted members and for non-trivial copy-c'tors

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
Summary|[C++11] __is_trivial|[C++11][DR 1333]
   |intrinsic fails for deleted |__is_trivial intrinsic
   |members and for non-trivial |fails for deleted members
   |copy-c'tors |and for non-trivial
   ||copy-c'tors

--- Comment #5 from Jason Merrill  ---
This comes from DR 1333, which seems to me to be wrongly resolved.  I've raised
the question with the committee and will defer this until after the next
meeting.

[Bug c++/58074] [C++11][DR 1333] __is_trivial intrinsic fails for deleted members and for non-trivial copy-c'tors

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
Created attachment 36370
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36370=edit
patch for GCC 5

And a patch to add a -Wabi warning to GCC 5.

[Bug c++/58074] [C++11][DR 1333] __is_trivial intrinsic fails for deleted members and for non-trivial copy-c'tors

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Created attachment 36369
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36369=edit
patch

But here's the fix if the committee reaffirms the DR.

[Bug other/67627] libatomic parallel build failure

[nsz at gcc dot gnu.org]

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

--- Comment #1 from nsz at gcc dot gnu.org ---
adding

all-multi: $(libatomic_la_LIBADD)

to libatomic/Makefile.in solves the problem for me,
but i'm not sure what's the automake way of doing
this