[Bug go/68072] malformed DWARF TagVariable entry

[vogt at linux dot vnet.ibm.com]

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

--- Comment #7 from Dominik Vogt  ---
All right, I'll try to extract a minimal test case.

[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts

[rguenther at suse dot de]

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

--- Comment #48 from rguenther at suse dot de  ---
On Mon, 16 Nov 2015, ch3root at openwall dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
> 
> --- Comment #47 from Alexander Cherepanov  ---
> On 2015-11-16 14:00, rguenther at suse dot de wrote:
> >> --- Comment #43 from Jeehoon Kang  ---
> >> - Performance degradation due to "casted pointers as escaped" is 
> >> insignificant.
> >
> > I think this is not true.  For example with MatLab (might be sth else,
> > if I don't remember correctly) you are required to pass pointers to
> > arrays in two halves in double(!) values (I believe the only function
> > argument type they support).  GCC happily makes points-to analysis work
> > through those.
> 
> But this is invalid C. First, it breaks strict aliasing rules. Second, 
> the representations of these doubles are free to change at any time 
> given their values are kept intact (e.g. change one NaN to another). 
> That is, unrelated improvements in other optimizations in gcc will break 
> all of this in the future, right?

You misunderstood, they marshall a pointer 'T *p' like

  unsigned int high = ((uintptr_t)p) >> 32;
  unsigned int low = ((uintptr_t)p) & (1 << 32 - 1);
  foo ((double) high, (double) low);

and in foo then do

foo (double hdouble, double ldouble)
{ 
  unsigned int high = (unsigned int) hdouble;
  unsigned int low = (unsigned int) ldouble;
  T *p = (T *)(((uintptr_t)high << 32) | (uintptr_t)low);

the important part here is to recognize that frobbing in points-to
analysis so you still see what 'p' points to in foo.

> > I added the current handling of pointers vs. integers for a
> > missed-optimization bug that said a hand-written memcpy loop
> > didn't properly transfer points-to info (properly as in
> > optimially for optimization).  GCC can now do that ;)
> 
> Nice! Does gcc properly transfer effective type info too, over a 
> hand-written memcpy loop? Just curious.

No, GCC doesn't have any effective type analysis / propagation.  It
only has the traditional type-based disambiguations of accesses
using the access type.

> On 2015-11-16 15:51, rguenther at suse dot de wrote:
>  >> Thank you for giving me the information.  I don't know the GCC 
> internals, so I
>  >> would like to ask how much it would cost to introduce the syntax for 
> pointer
>  >> subtractions.  I hope it is not that huge, but I really don't have 
> any idea.
>  >
>  > It would be quite some (mechanical) work but otherwise not too difficult.
>  > There is the choice whether to embed the division implicitely here or
>  > not.
> 
> If you choose to fix it please fix pr45779 on the way (see pr67999 for a 
> context).

[Bug target/68263] Vector "*mov_internal" fails to handle misaligned load/store from reload

[julia.koval at intel dot com]

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

--- Comment #11 from Yulia Koval  ---
>HJ, can you please test the patch for IAMCU, also with AVX target?
Tests are ok for IAMCU target

[Bug rtl-optimization/68376] [4.9/5/6 Regression] wrong code at -O1 and above on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
-fno-if-conversion fixes it.

[Bug target/68263] Vector "*mov_internal" fails to handle misaligned load/store from reload

[uros at gcc dot gnu.org]

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

--- Comment #12 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Nov 17 09:45:35 2015
New Revision: 230456

URL: https://gcc.gnu.org/viewcvs?rev=230456&root=gcc&view=rev
Log:
PR target/68263
* config/i386/i386.h (BIGGEST_ALIGNMENT): Always define
to 32 for IAMCU.
* config/i386/sse.md (*mov_internal): Always enable
AVX and SSE unaligned moves for IAMCU.


Modified:
trunk/gcc/config/i386/i386.h
trunk/gcc/config/i386/sse.md

[Bug c++/68368] [6 regression] ICE tree check: expected integer_cst, have nop_expr in decompose, at tree.h:5123

[chrbr at gcc dot gnu.org]

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

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 CC||chrbr at gcc dot gnu.org

--- Comment #2 from chrbr at gcc dot gnu.org ---
Created attachment 36731
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36731&action=edit
reduced case

still fails at rev 230435

just call with 
cc1plus testcase-min.ii

internal compiler error: tree check: expected integer_cst, have nop_expr in
decompose, at tree.h:5123
  13))
^

[Bug target/66776] [AArch64] zero-extend version of csel not matching properly

[renlin at gcc dot gnu.org]

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

Renlin Li  changed:

   What|Removed |Added

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

--- Comment #3 from Renlin Li  ---
resolved.

[Bug rtl-optimization/66556] Wrong code-generation for armv7-a big-endian at -Os

[renlin at gcc dot gnu.org]

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

Renlin Li  changed:

   What|Removed |Added

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

--- Comment #5 from Renlin Li  ---
resolved

[Bug middle-end/68375] [6 Regression] ICE in get_loop_body_in_bfs_order when dumping cfg with -fdump-tree-optimized-graph

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
   Target Milestone|--- |6.0

--- Comment #1 from Richard Biener  ---
(In reply to ktkachov from comment #0)
> I was investigating the testcase from PR 68194
> 
> int printf (const char *, ...); 
> 
> int a, c, d, e, g, h;
> short f;
> 
> short
> fn1 () 
> {
>   int j[2];
>   for (; e; e++)
> if (j[0])
>   for (;;)
>   ;
>   if (!g)
> return f;
> }
> 
> int
> main ()
> {
>   for (; a < 1; a++)
> {
>   for (c = 0; c < 2; c++)
>   { 
> d && (f = 0); 
> h = fn1 (); 
>   }
>   printf ("%d\n", (char) f);   
>}
>   
>  return 0;
> }
> 
> and hit an ICe when compiling with -fdump-tree-optimized-graph -O2:
> internal compiler error: in get_loop_body_in_bfs_order, at cfgloop.c:944
>  fn1 ()
>  ^~~
> 
> 0x7114e8 get_loop_body_in_bfs_order(loop const*)
>   ../../gcc/gcc/cfgloop.c:944
> 0x1166ce2 draw_cfg_nodes_for_loop
>   ../../gcc/gcc/graph.c:220
> 0x1166cad draw_cfg_nodes_for_loop
>   ../../gcc/gcc/graph.c:212
> 0x1166e64 draw_cfg_nodes
>   ../../gcc/gcc/graph.c:242
> 0x1166e64 print_graph_cfg(char const*, function*)
>   ../../gcc/gcc/graph.c:288
> 0xa17806 execute_function_dump
>   ../../gcc/gcc/passes.c:1751
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> 
> The assert "gcc_assert (i > vc);" triggers.
> Changing it to "gcc_assert (i >= vc);" fixes it for me but it was explicitly
> changed to i > vc from i >= vc with:
> 
> 2015-06-09  Richard Biener  
> 
> * cfgloop.c (get_loop_body_in_bfs_order): Fix assert.
> 
> so there must be something I'm missing?

if i == vc then blocks[vc++] will read from uninitialized memory as we always
write to blocks[i++].

I think the case that is not handled well here is a a loop with just
a header (no explicit latch).  Then i == 1 and vc == 1 at the end
(but the loop will terminate immediately after the read from blocks[vc++]
which is even outside of the allocation due to the loop header check
i < 1).

Re-structuring the loop like

blocks[0] = loop->header;
bitmap_set_bit (visited, loop->header->index);
vc = 0;
i = 1;
while (i < loop->num_nodes)
 {
   gcc_assert (i > vc);
   bb = blocks[vc++];

  FOR_EACH_EDGE (e, ei, bb->succs)
{
  if (flow_bb_inside_loop_p (loop, e->dest))
{
  if (bitmap_set_bit (visited, e->dest->index))
blocks[i++] = e->dest;
}
}
 }

would fix this I guess.

[Bug tree-optimization/68367] [6 regression] ICE in vectorizable_load, at tree-vect-stmts.c:6711

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>

[rguenth at gcc dot gnu.org]

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

--- Comment #33 from Richard Biener  ---
(In reply to Gary Funck from comment #32)
> (In reply to Gary Funck from comment #17)
> > We're seeing this ICE on x86-64, while building the 32-bit libgfortran.
> > We're building the target libraries with -O3 with GCC compiler checks
> > enabled.
> 
> The recent r230424 commit did *not* fix this regression.  Note that we're
> building with CFLAGS_FOR_TARGET='-O3 -g'.

Can you try the patch attached to comment #29?

[Bug fortran/65751] Bogus &L in error message

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |dominiq at lps dot 
ens.fr

--- Comment #5 from Dominique d'Humieres  ---
Patch submitted at https://gcc.gnu.org/ml/fortran/2015-11/msg00100.html.

[Bug other/68247] Remove pass_first_instance

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from vries at gcc dot gnu.org ---
https://gcc.gnu.org/ml/gcc-cvs/2015-11/msg00790.html :

Author: vries
Date: Mon Nov 16 12:40:50 2015
New Revision: 230420

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

2015-11-16  Tom de Vries  

* passes.c (first_pass_instance): Remove variable.
(execute_todo): Remove setting of first_pass_instance.
* tree-pass.h (first_pass_instance): Remove declaration.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/passes.c
trunk/gcc/tree-pass.h

[Bug c++/68368] [6 regression] ICE tree check: expected integer_cst, have nop_expr in decompose, at tree.h:5123

[chrbr at gcc dot gnu.org]

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

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|RESOLVED|REOPENED
   Last reconfirmed||2015-11-17
 Resolution|DUPLICATE   |---
 Ever confirmed|0   |1

--- Comment #3 from chrbr at gcc dot gnu.org ---
reopened with reduced case.

[Bug target/68263] Vector "*mov_internal" fails to handle misaligned load/store from reload

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #13 from Uroš Bizjak  ---
Fixed.

[Bug target/68263] Vector "*mov_internal" fails to handle misaligned load/store from reload

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug middle-end/68378] Return value optimization does not fire iff in C mode

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-17
  Component|c   |middle-end
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
In GCC, there are two places where this optimization happens.  One in the C++
front-end and once in the middle-end.  Looks like the middle-end one is not
doing it; only the one in the C++ front-end.

[Bug c++/68308] [6 Regression] ICE: tree check: expected integer_cst, have var_decl in decompose, at tree.h:5105

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #1 from Markus Trippelsdorf  ---
Started with r230081.

[Bug tree-optimization/68379] New: [6 Regression] BB vectorization: definition in block 13 follows the use for SSA_NAME

[rguenth at gcc dot gnu.org]

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

Bug ID: 68379
   Summary: [6 Regression] BB vectorization: definition in block
13 follows the use for SSA_NAME
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

! { dg-do compile }
! { dg-additional-options "-Ofast" }
! { dg-additional-options "-mavx" { target x86_64-*-* i?86-*-* } }

  SUBROUTINE PASSB4 (IDO,L1,CC,CH,WA1,WA2,WA3)
  IMPLICIT REAL(4) (A-H, O-Z)
  DIMENSION   CC(IDO,4,L1)   ,CH(IDO,L1,4)   ,&
 WA1(*) ,WA2(*) ,WA3(*)
  102 DO 104 K=1,L1
 DO 103 I=2,IDO,2
TI1 = CC(I,1,K)-CC(I,3,K)
TI2 = CC(I,1,K)+CC(I,3,K)
TI3 = CC(I,2,K)+CC(I,4,K)
TR2 = CC(I-1,1,K)+CC(I-1,3,K)
TI4 = CC(I-1,2,K)-CC(I-1,4,K)
TR3 = CC(I-1,2,K)+CC(I-1,4,K)
CH(I-1,K,1) = TR2+TR3
CH(I,K,1) = TI2+TI3
CI4 = TI1-TI4
CH(I-1,K,4) = CI4
CH(I,K,4) = CI4
  103CONTINUE
  104 CONTINUE
  RETURN
  END

on aarch64-linux ICEs with

vect-9.f90:5:0:

   SUBROUTINE PASSB4 (IDO,L1,CC,CH,WA1,WA2,WA3)


Error: definition in block 11 follows the use
for SSA_NAME: _54 in statement:
vectp.20_198 = &*cc_36(D)[_54];

Breakpoint 2, internal_error (gmsgid=0x1718ff4 "verify_ssa failed")

which is because when we vectorize

vect-9.f90:10:0: note: node
vect-9.f90:10:0: note:  stmt 0 _37 = *cc_36(D)[_35];
vect-9.f90:10:0: note:  stmt 1 _37 = *cc_36(D)[_35];

the interleaving with _55 = *cc_36(D)[_54]; and a permutation of { 1 1 } will
cause us to base the reference off a pointer to a ref that does not
participate in the SLP node and thus is not considered when we look for
the insertion place with vect_find_last_scalar_stmt_in_slp.

[Bug c/68380] New: NetBSD has SSP in libc

[tk at giga dot or.at]

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

Bug ID: 68380
   Summary: NetBSD has SSP in libc
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tk at giga dot or.at
  Target Milestone: ---

Created attachment 36732
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36732&action=edit
Patch fixing the problem.

NetBSD has SSP included in libc:

http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/ssp/?only_with_tag=MAIN

gcc/configure does not know about this. The attached patch (against SVN
checkout from today) fixes this.

[Bug libstdc++/66059] make_integer_sequence should use a log(N) implementation

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
I already have a better make_integer_sequence, but have been trying to write an
intrinsic.

[Bug target/68381] New: [6 Regression] wrong code and quality regression with __builtin_mul_overflow() @ aarch64

[zsojka at seznam dot cz]

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

Bug ID: 68381
   Summary: [6 Regression] wrong code and quality regression with
__builtin_mul_overflow() @ aarch64
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---

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

Output:
$ aarch64-unknown-linux-gnu-gcc -O -fexpensive-optimizations -fno-tree-bit-ccp 
testcase.c
$ ./a.out
Aborted

The function foo() is miscompiled.

5-branch output:
foo:
uxthw0, w0
uxthw1, w1
umull   x0, w0, w1
tbz w0, #31, .L7
stp x29, x30, [sp, -16]!
add x29, sp, 0
bl  abort
.L7:
ret

trunk output:
foo:
tbnzw0, #31, .L10
ret
.L10:
stp x29, x30, [sp, -16]!
add x29, sp, 0
bl  abort


Things seem to break in .combine if -fexpensive-optimisations is enabled.
Before .combine, there is:

(insn 2 5 3 2 (set (reg/v:SI 80 [ xD.2712 ])
(zero_extend:SI (reg:HI 0 x0 [ xD.2712 ]))) testcase.c:3 82
{*zero_extendhisi2_aarch64}
 (expr_list:REG_DEAD (reg:HI 0 x0 [ xD.2712 ])
(nil)))
(insn 3 2 4 2 (set (reg/v:SI 81 [ yD.2713 ])
(zero_extend:SI (reg:HI 1 x1 [ yD.2713 ]))) testcase.c:3 82
{*zero_extendhisi2_aarch64}
 (expr_list:REG_DEAD (reg:HI 1 x1 [ yD.2713 ])
(nil)))
(note 4 3 7 2 NOTE_INSN_FUNCTION_BEG)
(insn 7 4 8 2 (set (reg:SI 76 [ _5+4 ])
(const_int 0 [0])) testcase.c:5 39 {*movsi_aarch64}
 (nil))
(insn 8 7 9 2 (set (reg:DI 82)
(mult:DI (zero_extend:DI (reg/v:SI 80 [ xD.2712 ]))
(zero_extend:DI (reg/v:SI 81 [ yD.2713 ] testcase.c:5 360
{umulsidi3}
 (expr_list:REG_DEAD (reg/v:SI 81 [ yD.2713 ])
(expr_list:REG_DEAD (reg/v:SI 80 [ xD.2712 ])
(nil
(insn 9 8 10 2 (set (reg:DI 83)
(lshiftrt:DI (reg:DI 82)
(const_int 32 [0x20]))) testcase.c:5 614
{*aarch64_lshr_sisd_or_int_di3}
 (nil))
(insn 10 9 39 2 (set (reg:CC 66 cc)
(compare:CC (subreg:SI (reg:DI 83) 0)
(const_int 0 [0]))) testcase.c:5 375 {*cmpsi}
 (expr_list:REG_UNUSED (reg:CC 66 cc)
(nil)))
...
(insn 43 42 44 2 (set (reg:CC 66 cc)
(compare:CC (subreg:SI (reg:DI 82) 0)
(const_int 0 [0]))) testcase.c:5 375 {*cmpsi}
 (nil))


and .combine shows:

Trying 2, 8, 9 -> 10:
Successfully matched this instruction:
(set (reg:DI 83)
(const_int 0 [0]))
(const_int 0 [0])

which seems to miss the parallel set of reg 82.



The performance regression is at -O3:
5-branch output:
foo:
uxthx0, w0  // xD.2664, xD.2664
uxthx1, w1  // yD.2665, yD.2665
mul x0, x0, x1  // tmp84, xD.2664, yD.2665
cmp x0, x0, sxtw// tmp84, tmp84
bne .L9 //,
ret
.L9:
stp x29, x30, [sp, -16]!//,,,
add x29, sp, 0  //,,
bl  abort   //

trunk output:
foo:
uxthw0, w0  // xD.2712, xD.2712
uxthw1, w1  // yD.2713, yD.2713
umull   x0, w0, w1  // tmp81, xD.2712, yD.2713
tbnzw0, #31, .L6// tmp81,
mov w2, 0   // _5,
cbnzw2, .L6 // _5,
ret
.L6:
stp x29, x30, [sp, -16]!//,,,
add x29, sp, 0  //,,
bl  abort   //


The code:
mov w2, 0   // _5,
cbnzw2, .L6 // _5,
seems to be absolutely unneeded.


I don't know if the wrong-code and missed-optimization is related.



$ aarch64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-230409-checking-yes-rtl-df-nographite-aarch64/libexec/gcc/aarch64-unknown-linux-gnu/6.0.0/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df
--enable-languages=c,c++
--prefix=/mnt/svn/gcc-trunk/binary-230409-checking-yes-rtl-df-nographite-aarch64/
--without-cloog --without-ppl --without-isl --host=x86_64-pc-linux-gnu
--target=aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--with-sysroot=/home/aarch64-chroot
--with-as=/usr/libexec/gcc/aarch64-unknown-linux-gnu/as
--with-ld=/usr/libexec/gcc/aarch64-unknown-linux-gnu/ld
Thread model: posix
gcc version 6.0.0 20151116 (experimental) (GCC) 


Tested revisions:
trunk r230409 - FAIL
5-branch r229483 - OK

[Bug fortran/68382] New: Linux Binary Download page broken

[pogos77 at hotmail dot com]

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

Bug ID: 68382
   Summary: Linux Binary Download page broken
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pogos77 at hotmail dot com
  Target Milestone: ---

The download page for GNU/Linux has not been working for some weeks now. Hope
you'll have time to look into this.


Many thanks for all of your effort.


Prince

[Bug c++/68159] Demangler crash (GDB PR 19190)

[fiesh at zefix dot tv]

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

fiesh at zefix dot tv changed:

   What|Removed |Added

 CC||fiesh at zefix dot tv

--- Comment #3 from fiesh at zefix dot tv ---
I ran into a problem that is possibly the same issue.

echo 'void
_ZSt7forwardIRKZN5Write14DataMapGrammarISt20back_insert_iteratorISsEEC4EvEUlRT_E_EOS5_RNSt16remove_referenceIS5_E4typeE()
{} int main() {}' | gcc -xc - -o /tmp/a.out && gdb /tmp/a.out

On gdb 7.9.1, 7.10, and 7.10.50.20151117-cvs, this results in

Reading symbols from /tmp/a.out...cp-support.c:1595: demangler-warning: unable
to demangle
'_ZSt7forwardIRKZN5Write14DataMapGrammarISt20back_insert_iteratorISsEEC4EvEUlRT_E_EOS5_RNSt16remove_referenceIS5_E4typeE'
(demangler failed with signal 11)
Unable to dump core, use `ulimit -c unlimited' before executing GDB next time.
cp-support.c:1608: demangler-warning: unable to demangle
'_ZSt7forwardIRKZN5Write14DataMapGrammarISt20back_insert_iteratorISsEEC4EvEUlRT_E_EOS5_RNSt16remove_referenceIS5_E4typeE'
(demangler failed with signal 11)

The binary was compiled with gcc 4.9.3.  If it's a different problem, I'll open
up a separate ticket.

[Bug tree-optimization/68327] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vect_is_simple_use, at tree-vect-stmts.c:8562

[ienkovich at gcc dot gnu.org]

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

--- Comment #3 from Ilya Enkovich  ---
We compute vectype for phi when it's relevant.  For other statements we compute
it when it's relevant or alive.  For non-relevant but alive boolean statement
we try to examine operand definition which is non-relevant phi and doesn't have
vectype.

Do we need vectype for non-relevant statements?  This patch works for the test:

diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index 80937ec..592372d 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -439,7 +439,8 @@ vect_determine_vectorization_factor (loop_vec_info
loop_vinfo)
 compute a factor.  */
  if (TREE_CODE (scalar_type) == BOOLEAN_TYPE)
{
- mask_producers.safe_push (stmt_info);
+ if (STMT_VINFO_RELEVANT_P (stmt_info))
+   mask_producers.safe_push (stmt_info);
  bool_result = true;

  if (gimple_code (stmt) == GIMPLE_ASSIGN

[Bug c++/68159] Demangler crash (GDB PR 19190)

[trippels at gcc dot gnu.org]

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

--- Comment #4 from Markus Trippelsdorf  ---
(In reply to fiesh from comment #3)
> I ran into a problem that is possibly the same issue.
> 
> echo 'void
> _ZSt7forwardIRKZN5Write14DataMapGrammarISt20back_insert_iteratorISsEEC4EvEUlR
> T_E_EOS5_RNSt16remove_referenceIS5_E4typeE() {} int main() {}' | gcc -xc -
> -o /tmp/a.out && gdb /tmp/a.out
> 
> On gdb 7.9.1, 7.10, and 7.10.50.20151117-cvs, this results in
> 
> Reading symbols from /tmp/a.out...cp-support.c:1595: demangler-warning:
> unable to demangle
> '_ZSt7forwardIRKZN5Write14DataMapGrammarISt20back_insert_iteratorISsEEC4EvEUl
> RT_E_EOS5_RNSt16remove_referenceIS5_E4typeE' (demangler failed with signal
> 11)
> Unable to dump core, use `ulimit -c unlimited' before executing GDB next
> time.
> cp-support.c:1608: demangler-warning: unable to demangle
> '_ZSt7forwardIRKZN5Write14DataMapGrammarISt20back_insert_iteratorISsEEC4EvEUl
> RT_E_EOS5_RNSt16remove_referenceIS5_E4typeE' (demangler failed with signal
> 11)
> 
> The binary was compiled with gcc 4.9.3.  If it's a different problem, I'll
> open up a separate ticket.

Your issue is a dup of PR61321, which is different.

[Bug other/61321] demangler crash on casts in template parameters

[trippels at gcc dot gnu.org]

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

--- Comment #11 from Markus Trippelsdorf  ---
Any update, Pedro?

[Bug c++/68159] Demangler crash (GDB PR 19190)

[fiesh at zefix dot tv]

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

--- Comment #5 from fiesh at zefix dot tv ---
Ah I see, thanks!

[Bug c++/68159] Demangler crash (GDB PR 19190)

[trippels at gcc dot gnu.org]

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

--- Comment #6 from Markus Trippelsdorf  ---
(In reply to fiesh from comment #5)
> Ah I see, thanks!

Looking deeper, it isn't a dup after all. I'll open a new issue later.

[Bug rtl-optimization/68381] [6 Regression] wrong code and quality regression with __builtin_mul_overflow() @ aarch64

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Component|target  |rtl-optimization
   Target Milestone|--- |4.9.4

[Bug rtl-optimization/68381] [6 Regression] wrong code and quality regression with __builtin_mul_overflow() @ aarch64

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|4.9.4   |6.0

[Bug other/61321] demangler crash on casts in template parameters

[trippels at gcc dot gnu.org]

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

--- Comment #12 from Markus Trippelsdorf  ---
_ZSt7forwardIRKZN5Write14DataMapGrammarISt20back_insert_iteratorISsEEC4EvEUlRT_E_EOS5_RNSt16remove_referenceIS5_E4typeE

still recurses endless, even with your patch applied.

[Bug c++/68383] New: Demangler stack overflow

[trippels at gcc dot gnu.org]

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

Bug ID: 68383
   Summary: Demangler stack overflow
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

markus@x4 libiberty % ./a.out
_ZSt7forwardIRKZN5Write14DataMapGrammarISt20back_insert_iteratorISsEEC4EvEUlRT_E_EOS5_RNSt16remove_referenceIS5_E4typeE
ASAN:SIGSEGV
=
==29666==ERROR: AddressSanitizer: stack-overflow on address 0x7ffee66ebf28 (pc
0x7f255c00f094 bp 0x7ffee66ec790 sp 0x7ffee66ebf30 T0)
#0 0x7f255c00f093 in __asan_memcpy
(/usr/lib/gcc/x86_64-pc-linux-gnu/5.2.1/libasan.so.2+0x90093)
#1 0x403b0d in d_growable_string_append_buffer cp-demangle.c:3839
#2 0x403b0d in d_growable_string_callback_adapter cp-demangle.c:3851
#3 0x40463c in d_print_flush cp-demangle.c:4044
#4 0x40463c in d_append_char cp-demangle.c:4055
#5 0x40463c in d_append_buffer cp-demangle.c:4067
#6 0x40463c in d_print_comp_inner cp-demangle.c:4373
#7 0x412f88 in d_print_comp cp-demangle.c:5431
#8 0x40445f in d_print_comp_inner cp-demangle.c:4401
#9 0x412f88 in d_print_comp cp-demangle.c:5431
#10 0x408a71 in d_print_comp_inner cp-demangle.c:4559
#11 0x412f88 in d_print_comp cp-demangle.c:5431
#12 0x407eaf in d_print_comp_inner cp-demangle.c:5013
#13 0x412f88 in d_print_comp cp-demangle.c:5431
#14 0x408b73 in d_print_comp_inner cp-demangle.c:4563
#15 0x412f88 in d_print_comp cp-demangle.c:5431
#16 0x404362 in d_print_comp_inner cp-demangle.c:4387
#17 0x414422 in d_print_comp cp-demangle.c:5431
#18 0x414422 in d_print_mod cp-demangle.c:5649
#19 0x4155a6 in d_print_mod_list cp-demangle.c:5575
#20 0x417137 in d_print_function_type cp-demangle.c:5720
#21 0x404bb6 in d_print_comp_inner cp-demangle.c:4898
#22 0x412f88 in d_print_comp cp-demangle.c:5431
#23 0x40e69b in d_print_comp_inner cp-demangle.c:4504
#24 0x412f88 in d_print_comp cp-demangle.c:5431
#25 0x404362 in d_print_comp_inner cp-demangle.c:4387
#26 0x412f88 in d_print_comp cp-demangle.c:5431
#27 0x406d78 in d_print_comp_inner cp-demangle.c:4832
#28 0x412f88 in d_print_comp cp-demangle.c:5431
#29 0x406d78 in d_print_comp_inner cp-demangle.c:4832
#30 0x412f88 in d_print_comp cp-demangle.c:5431
#31 0x407eaf in d_print_comp_inner cp-demangle.c:5013
#32 0x412f88 in d_print_comp cp-demangle.c:5431
#33 0x40a8c2 in d_print_comp_inner cp-demangle.c:5396
#34 0x412f88 in d_print_comp cp-demangle.c:5431
#35 0x40445f in d_print_comp_inner cp-demangle.c:4401
#36 0x412f88 in d_print_comp cp-demangle.c:5431
#37 0x406d78 in d_print_comp_inner cp-demangle.c:4832
#38 0x412f88 in d_print_comp cp-demangle.c:5431
#39 0x406d78 in d_print_comp_inner cp-demangle.c:4832
#40 0x412f88 in d_print_comp cp-demangle.c:5431
#41 0x407eaf in d_print_comp_inner cp-demangle.c:5013
#42 0x412f88 in d_print_comp cp-demangle.c:5431
#43 0x40a8c2 in d_print_comp_inner cp-demangle.c:5396
...

[Bug target/68143] [5/6 Regression][ARM] Wrong code initialising struct member after zeroing out the whole struct

[ktkachov at gcc dot gnu.org]

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Tue Nov 17 13:20:08 2015
New Revision: 230462

URL: https://gcc.gnu.org/viewcvs?rev=230462&root=gcc&view=rev
Log:
[ARM] PR 68143 Properly update memory offsets when expanding setmem

PR target/68143
* config/arm/arm.c (arm_block_set_unaligned_vect): Keep track of
offset from dstbase and use it appropriately in
adjust_automodify_address.
(arm_block_set_aligned_vect): Likewise.

* gcc.c-torture/execute/pr68143_1.c: New test.


Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr68143_1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/68134] [6 Regression] float64x1_t comparison ICE on aarch64-none-elf

[ienkovich at gcc dot gnu.org]

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

--- Comment #5 from Ilya Enkovich  ---
Author: ienkovich
Date: Tue Nov 17 13:22:40 2015
New Revision: 230463

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

PR middle-end/68134
* targhooks.c (default_get_mask_mode): Filter out
scalar modes returned by mode_for_vector.

gcc/testsuite/

PR middle-end/68134
* gcc.dg/pr68134.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr68134.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/targhooks.c
trunk/gcc/testsuite/ChangeLog

[Bug other/61321] demangler crash on casts in template parameters

[ian at airs dot com]

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

--- Comment #13 from Ian Lance Taylor  ---
Was the symbol from comment #12,
_ZSt7forwardIRKZN5Write14DataMapGrammarISt20back_insert_iteratorISsEEC4EvEUlRT_E_EOS5_RNSt16remove_referenceIS5_E4typeE,
generated by g++ or clang?  That is, is it supposed to demangle?  If so, do you
have the source code?

[Bug other/61321] demangler crash on casts in template parameters

[trippels at gcc dot gnu.org]

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

--- Comment #14 from Markus Trippelsdorf  ---
It was first reported in PR68159. I've opened PR68383 for the issue.
The reporter is CCed in PR68383, so please ask him there directly.

[Bug c++/68383] Demangler stack overflow

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
@fi...@zefix.tv 
Ian asks:
»Was the symbol
_ZSt7forwardIRKZN5Write14DataMapGrammarISt20back_insert_iteratorISsEEC4EvEUlRT_E_EOS5_RNSt16remove_referenceIS5_E4typeE
generated by g++ or clang?  That is, is it supposed to demangle?  If so, do you
have the source code?»

[Bug c++/68383] Demangler stack overflow

[fiesh at zefix dot tv]

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

--- Comment #2 from fiesh at zefix dot tv ---
g++ 4.9.3, I do have the source code and will try to provide a minimal test
case.

[Bug rtl-optimization/68328] [4.9/5/6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[ktkachov at gcc dot gnu.org]

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

--- Comment #8 from ktkachov at gcc dot gnu.org ---
The above testcase should be adjusted a bit for targets that have different
char signedness than x86:
int a, b, c = 1, d = 1, e;

__attribute__((noinline, noclone)) int
foo (void)
{
  asm volatile ("" : : : "memory");
  return 4195552;
}

__attribute__((noinline, noclone)) void
bar (int x, int y)
{
  asm volatile ("" : : "g" (x), "g" (y) : "memory");
  if (y == 0)
__builtin_abort ();
}

int
baz (int x)
{
  char g, h;
  int i, j;

  foo ();
  for (;;)
{
  if (c)
h = d;
  g = h < x ? h : 0;
  i = (signed char) ((unsigned char)(g - 120) ^ 1);
  j = i > 97;
  if (a - j)
bar (0x123456, 0);
  if (!b)
return e;
}
}

int
main ()
{
  baz (2);
  return 0;
}

[Bug lto/68384] New: LTO error for global register variables in PHP 7 compiling on powerpc64le

[acsawdey at gcc dot gnu.org]

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

Bug ID: 68384
   Summary: LTO error for global register variables in PHP 7
compiling on powerpc64le
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acsawdey at gcc dot gnu.org
  Target Milestone: ---

Created attachment 36734
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36734&action=edit
zend.i from reduced test case

If you attempt to build PHP 7 with -flto, you encounter errors for the 2
register global variables it uses:

zend_execute.i:81:32: error: global register variable follows a function
definition
register const zend_op *opline __asm__("r29");
^

zend_execute.i:80:36: error: global register variable follows a function
definition
register zend_execute_data *execute_data __asm__("r28");
^

I've reduced this with multidelta and the preprocessed files are attached.

Reproduce with:

gcc -flto -O3 main.i php_cli.i zend_execute.i zend.i

Of course this test case won't link or do anything useful, but it hits the LTO
issue before getting to the link phase.

I did my testing with trunk 230270, but older gcc 4.8.x also has the same
problem.

[Bug lto/68384] LTO error for global register variables in PHP 7 compiling on powerpc64le

[acsawdey at gcc dot gnu.org]

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

--- Comment #1 from acsawdey at gcc dot gnu.org ---
Created attachment 36735
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36735&action=edit
zend_execute.i

[Bug lto/68384] LTO error for global register variables in PHP 7 compiling on powerpc64le

[acsawdey at gcc dot gnu.org]

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

--- Comment #2 from acsawdey at gcc dot gnu.org ---
Created attachment 36736
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36736&action=edit
php_cli.i

[Bug rtl-optimization/68381] [6 Regression] wrong code and quality regression with __builtin_mul_overflow() @ aarch64

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-17
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed. Started with the combine change @ r230326.

[Bug lto/68384] LTO error for global register variables in PHP 7 compiling on powerpc64le

[acsawdey at gcc dot gnu.org]

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

--- Comment #3 from acsawdey at gcc dot gnu.org ---
Created attachment 36737
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36737&action=edit
main.i

[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>

[gary at intrepid dot com]

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

--- Comment #34 from Gary Funck  ---
(In reply to Richard Biener from comment #33)
> Can you try the patch attached to comment #29?

That seemed to fix the issue in 32/libgfortran, though I haven't tried a build
from scratch yet.

Regarding the patch, in cfgexpand.c, I had to change the call to
redirect_edge_var_map_empty() (was: redirect_edge_var_map_destroy).
Note there is no ggc_collect() call there, it appears in other places
in the patch.

[Bug c/68385] New: ICE building libstdc++ on arm-none-eabi

[alalaw01 at gcc dot gnu.org]

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

Bug ID: 68385
   Summary: ICE building libstdc++ on arm-none-eabi
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alalaw01 at gcc dot gnu.org
  Target Milestone: ---
Target: arm-none-eabi

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

Starting with r230365, building gcc for arm-none-eabi falls over in libstdc++
with:

/work/alalaw01/build-arm-none-eabi/obj/gcc2/./gcc/xgcc -shared-libgcc
-B/work/alalaw01/build-arm-none-eabi/obj/gcc2/./gcc -nostdinc++
-L/work/alalaw01/build-arm-none-eabi/obj/gcc2/arm-none-eabi/libstdc++-v3/src
-L/work/alalaw01/build-arm-none-eabi/obj/gcc2/arm-none-eabi/libstdc++-v3/src/.libs
-L/work/alalaw01/build-arm-none-eabi/obj/gcc2/arm-none-eabi/libstdc++-v3/libsupc++/.libs
-B/work/alalaw01/build-arm-none-eabi/install/arm-none-eabi/bin/
-B/work/alalaw01/build-arm-none-eabi/install/arm-none-eabi/lib/ -isystem
/work/alalaw01/build-arm-none-eabi/install/arm-none-eabi/include -isystem
/work/alalaw01/build-arm-none-eabi/install/arm-none-eabi/sys-include
-I/work/alalaw01/src/gcc/libstdc++-v3/../libgcc
-I/work/alalaw01/build-arm-none-eabi/obj/gcc2/arm-none-eabi/libstdc++-v3/include/arm-none-eabi
-I/work/alalaw01/build-arm-none-eabi/obj/gcc2/arm-none-eabi/libstdc++-v3/include
-I/work/alalaw01/src/gcc/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall
-Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once
-ffunction-sections -fdata-sections -frandom-seed=eh_personality.lo -O2 -g -c
/work/alalaw01/src/gcc/libstdc++-v3/libsupc++/eh_personality.cc -o
eh_personality.o
/work/alalaw01/src/gcc/libstdc++-v3/libsupc++/eh_personality.cc: In function
'_Unwind_Reason_Code __cxxabiv1::__gxx_personality_v0(_Unwind_State,
_Unwind_Control_Block*, _Unwind_Context*)':
/work/alalaw01/src/gcc/libstdc++-v3/libsupc++/eh_personality.cc:394:26:
internal compiler error: tree check: expected integer_cst, have nop_expr in
decompose, at tree.h:5123
  UNWIND_STACK_REG))
  ^

0xf8d589 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/work/alalaw01/src/gcc/gcc/tree.c:9587
0x10df3fd tree_check
/work/alalaw01/src/gcc/gcc/tree.h:3212
0x10df3fd wi::int_traits::decompose(long*, unsigned int,
tree_node const*)
/work/alalaw01/src/gcc/gcc/tree.h:5123
0x10df3fd wide_int_ref_storage
/work/alalaw01/src/gcc/gcc/wide-int.h:936
0x10df3fd generic_wide_int
/work/alalaw01/src/gcc/gcc/wide-int.h:714
0x10df3fd generic_simplify_172
/work/alalaw01/build-arm-none-eabi/obj/gcc2/gcc/generic-match.c:6142
0x1113507 generic_simplify_EQ_EXPR
/work/alalaw01/build-arm-none-eabi/obj/gcc2/gcc/generic-match.c:22841
0x111d719 generic_simplify(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/work/alalaw01/build-arm-none-eabi/obj/gcc2/gcc/generic-match.c:25312
0xa182c8 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/work/alalaw01/src/gcc/gcc/fold-const.c:9138
0xa227b2 fold_build2_stat_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/work/alalaw01/src/gcc/gcc/fold-const.c:12333
0x10e00cd generic_simplify_46
/work/alalaw01/build-arm-none-eabi/obj/gcc2/gcc/generic-match.c:2014
0x1112b27 generic_simplify_EQ_EXPR
/work/alalaw01/build-arm-none-eabi/obj/gcc2/gcc/generic-match.c:22441
0x111d719 generic_simplify(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/work/alalaw01/build-arm-none-eabi/obj/gcc2/gcc/generic-match.c:25312
0xa182c8 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/work/alalaw01/src/gcc/gcc/fold-const.c:9138
0xa3ec75 fold(tree_node*)
/work/alalaw01/src/gcc/gcc/fold-const.c:11973
0x5bdff3 build_new_op_1
/work/alalaw01/src/gcc/gcc/cp/call.c:5730
0x5be299 build_new_op(unsigned int, tree_code, int, tree_node*, tree_node*,
tree_node*, tree_node**, int)
/work/alalaw01/src/gcc/gcc/cp/call.c:5803
0x70f42f build_x_binary_op(unsigned int, tree_code, tree_node*, tree_code,
tree_node*, tree_code, tree_node**, int)
/work/alalaw01/src/gcc/gcc/cp/typeck.c:3828
0x6e3b39 cp_parser_binary_expression
/work/alalaw01/src/gcc/gcc/cp/parser.c:8621
0x6e3cdc cp_parser_assignment_expression
/work/alalaw01/src/gcc/gcc/cp/parser.c:8742
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Reduced testcase attached:

$ arm-none-eabi-gcc -c reduced.cc
reduced.cc: In function 'bool __gxx_personality_v0(_Unwind_State,
_Unwind_Control_Block*, _Unwind_Context*)':
reduced.cc:19:63: internal compiler er

[Bug c++/68386] New: error: invalid initialization of reference of type 'void (&&)()' from expression of type 'void()'

[redi at gcc dot gnu.org]

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

Bug ID: 68386
   Summary: error: invalid initialization of reference of type
'void (&&)()' from expression of type 'void()'
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

template void f(F&&) { }

struct A {
  static void mf() { }
};

int main()
{
  A a;
  f( &a.mf );   // OK
  f( a.mf );// error
}


a.cc: In function 'int main()':
a.cc:11:11: error: invalid initialization of reference of type 'void (&&)()'
from expression of type 'void()'
   f( a.mf );// error
   ^

a.cc:1:27: note: in passing argument 1 of 'void f(F&&) [with F = void()]'
 template void f(F&&) { }
   ^

[Bug middle-end/67438] [6 Regression] ~X op ~Y pattern relocation causes loop performance degradation on 32bit x86

[ysrumyan at gmail dot com]

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

--- Comment #9 from Yuri Rumyantsev  ---
It looks like such transformation is profitable if only def statements have a
single use, i.e. it looks reasonable for 
   if (255 - a) > (255 -b) /* a,b have char type.  */
but it does not look reasonable for attached test-case since after it we missed
min/max recognition, namely,

c = 255 - r; /* c has mulitple uses!  */
m = 255 - g; /* likewise.  */
y = 255 - b; /* likewise.  */
if (c < m) 
  k = MIN (c, y);
else
  k = MIN (m, y);
*write++ = c - k;

[Bug bootstrap/68361] [6 regression] Bootstrap failure with --enable-checking=release

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-17
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
I also see that on x86_64-apple-darwin14. Note that the "suggest parentheses
..." is quite unhelpful.

[Bug c++/68383] Demangler stack overflow

[fiesh at zefix dot tv]

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

--- Comment #3 from fiesh at zefix dot tv ---
Created attachment 36739
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36739&action=edit
Preprocessed c++ file

[Bug c++/68383] Demangler stack overflow

[fiesh at zefix dot tv]

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

--- Comment #4 from fiesh at zefix dot tv ---
I added a preprocessed file that triggers the bug.  It was created using

g++ -I. -std=c++14 -E -o write.ii write.cpp

and can be compiled and linked using

g++ -std=c++14 -o write write.ii

This binary will trigger the bug in GDB.

It's huge, alas I don't have time today / tomorrow any more.  If I need to
produce a smaller test case, I can work on it, but given the heavy use of
boost::spirit, it won't become too small anyway.

[Bug rtl-optimization/68381] [6 Regression] wrong code and quality regression with __builtin_mul_overflow() @ aarch64

[ktkachov at gcc dot gnu.org]

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
(In reply to ktkachov from comment #1)
> Confirmed. Started with the combine change @ r230326.

The wrong-code part, I should say. I didn't look at the code quality regression
yet

[Bug middle-end/68134] [6 Regression] float64x1_t comparison ICE on aarch64-none-elf

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #6 from Ilya Enkovich  ---
Fixed

[Bug tree-optimization/68305] [6 regression] ICE on valid code at -O3 on x86_64-linux-gnu: tree check: expected class ‘expression’, have ‘exceptional’ (ssa_name) in tree_operand_check, at tree.h:3436

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #5 from Ilya Enkovich  ---
Fixed

[Bug target/68293] [6 Regression] ICE: in prepare_cmp_insn, at optabs.c:3813 with vector compare with -O0 @ aarch64

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #8 from Ilya Enkovich  ---
Fixed

[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>

[rguenther at suse dot de]

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

--- Comment #35 from rguenther at suse dot de  ---
On Tue, 17 Nov 2015, gary at intrepid dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117
> 
> --- Comment #34 from Gary Funck  ---
> (In reply to Richard Biener from comment #33)
> > Can you try the patch attached to comment #29?
> 
> That seemed to fix the issue in 32/libgfortran, though I haven't tried a build
> from scratch yet.
> 
> Regarding the patch, in cfgexpand.c, I had to change the call to
> redirect_edge_var_map_empty() (was: redirect_edge_var_map_destroy).
> Note there is no ggc_collect() call there, it appears in other places
> in the patch.

Yes, I thought the cfgexpand.c place is a better one and the only one
that would be related to the place where I removed the old
redirect_edge_var_map_destroy call.

Hmm.  Maybe not for functions removed by cgraph code.

Does

Index: gcc/function.c
===
--- gcc/function.c  (revision 230428)
+++ gcc/function.c  (working copy)
@@ -75,6 +75,7 @@ along with GCC; see the file COPYING3.
 #include "tree-chkp.h"
 #include "rtl-chkp.h"
 #include "tree-dfa.h"
+#include "tree-ssa.h"

 /* So we can assign to cfun in this file.  */
 #undef cfun
@@ -4759,6 +4760,7 @@ set_cfun (struct function *new_cfun)
   if (cfun != new_cfun)
 {
   cfun = new_cfun;
+  redirect_edge_var_map_destroy ();
   invoke_set_current_function_hook (new_cfun ? new_cfun->decl : 
NULL_TREE);
 }
 }

help?  (without the comment #29 patch)

Does the patch in comment #25 help?

[Bug rtl-optimization/68381] [6 Regression] wrong code and quality regression with __builtin_mul_overflow() @ aarch64

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #3 from ktkachov at gcc dot gnu.org ---
I think the subst hunk from r230326 should be:
  if (code == MULT
  && (GET_CODE (XEXP (x, 0)) == ZERO_EXTEND
  || GET_CODE (XEXP (x, 0)) == SIGN_EXTEND)
  && (GET_CODE (XEXP (x, 1)) == ZERO_EXTEND
  || GET_CODE (XEXP (x, 1)) == SIGN_EXTEND)
  && REG_P (XEXP (XEXP (x, 0), 0))
  && REG_P (XEXP (XEXP (x, 1), 0)))
{
  if (from == to)
return x;
}

that is, return x without any simplifications if we're passed a no-op
substitution (or PC) and perform the normal substitutions and simplifications
otherwise. This seems to fix the testcase for me and not regress the testcase
that r230326 was supposed to fix.
I'll be evaluating this approach further

[Bug fortran/68382] Linux Binary Download page broken

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from kargl at gcc dot gnu.org ---
The downloading of pre-built fortran is provided by a third party.
Issues of this nature should be reported on the fortran@gcc 
mailing list not the bugzilla database.

[Bug c++/68383] Demangler stack overflow

[ian at airs dot com]

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

--- Comment #5 from Ian Lance Taylor  ---
Thanks for the test case.  Which version of GCC are you using to compile?  When
I try to compile the test case I get

/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/avx512fintrin.h: In function
‘__m512i _mm512_set1_epi64(long long int)’:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/avx512fintrin.h:3631:25: error:
‘__builtin_ia32_pbroadcastq512_mem_mask’ was not declared in this scope
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/avx512fintrin.h: In function
‘__m512i _mm512_mask_set1_epi64(__m512i, __mmask8, long long int)’:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/avx512fintrin.h:3644:14: error:
‘__builtin_ia32_pbroadcastq512_mem_mask’ was not declared in this scope
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/avx512fintrin.h: In function
‘__m512i _mm512_maskz_set1_epi64(__mmask8, long long int)’:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/avx512fintrin.h:3661:11: error:
‘__builtin_ia32_pbroadcastq512_mem_mask’ was not declared in this scope


The version of avx512fintrin.h on mainline does not seem to call the function
__builtin_ia32_pbroadcastq512_mem_mask.

[Bug middle-end/67438] [6 Regression] ~X op ~Y pattern relocation causes loop performance degradation on 32bit x86

[rguenther at suse dot de]

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

--- Comment #10 from rguenther at suse dot de  ---
On Tue, 17 Nov 2015, ysrumyan at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67438
> 
> --- Comment #9 from Yuri Rumyantsev  ---
> It looks like such transformation is profitable if only def statements have a
> single use, i.e. it looks reasonable for 
>if (255 - a) > (255 -b) /* a,b have char type.  */
> but it does not look reasonable for attached test-case since after it we 
> missed
> min/max recognition, namely,
> 
> c = 255 - r; /* c has mulitple uses!  */
> m = 255 - g; /* likewise.  */
> y = 255 - b; /* likewise.  */
> if (c < m) 
>   k = MIN (c, y);
> else
>   k = MIN (m, y);
> *write++ = c - k;

Looks like we are missing the corresponding pattern for MIN/MAX
instead.

 MIN (~X, ~Y) -> ~MAX (X, Y)
 MAX (~X, ~Y) -> ~MIN (X, Y)

(for minmax (min max)
 maxmin (max min)
 (simplify
  (minmax (bit_not @0) (bit_not @1))
  (bit_not (maxmin @0 @1

maybe that helps.  I notice a missed optimization to combine
the test with the two MINs on the GIMPLE level anyway.

[Bug c++/68308] [6 Regression] ICE: tree check: expected integer_cst, have var_decl in decompose, at tree.h:5105

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

[Bug c/68162] [5/6 Regression] Incompatible pointer type using a typedef

[jsm28 at gcc dot gnu.org]

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

--- Comment #12 from Joseph S. Myers  ---
Could you post your dwarf2out.c patch to gcc-patches for review?

[Bug c++/68383] Demangler stack overflow

[trippels at gcc dot gnu.org]

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

--- Comment #6 from Markus Trippelsdorf  ---
It compiles with 4.9.3. I'm currently reducing the testcase...

[Bug c++/68387] New: [c++1z] gcc hangs forever on this code

[ryan.burn at gmail dot com]

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

Bug ID: 68387
   Summary: [c++1z] gcc hangs forever on this code
   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 36740
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36740&action=edit
preprocessed code

The attached code causes gcc to hang forever.

[Bug lto/68384] LTO error for global register variables in PHP 7 compiling on powerpc64le

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
First off it seems wrong PHP is using global registers.

But anyways the problem looks related to partitioning.

[Bug c++/68386] error: invalid initialization of reference of type 'void (&&)()' from expression of type 'void()'

[schaub.johannes at googlemail dot com]

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

Johannes Schaub  changed:

   What|Removed |Added

 CC||schaub.johannes@googlemail.
   ||com

--- Comment #1 from Johannes Schaub  ---
This can be further reduced to 

struct A { static void mf() { } };

int main() {
   A a;
   void (&rmf)() = a.mf; // error
}

[Bug sanitizer/64820] Libsanitizer fails with ((AddrIsAlignedByGranularity(addr + size))) != (0)" (0x0, 0x0) if ssp is enabled.

[joakim.tjernlund at transmode dot se]

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

joakim.tjernlund at transmode dot se  
changed:

   What|Removed |Added

 CC||joakim.tjernlund@transmode.
   ||se

--- Comment #6 from joakim.tjernlund at transmode dot se  ---
Is this fix in gcc 4.9.3?
If not, will go into 4.9.4?

[Bug fortran/65751] Bogus &L in error message

[dominiq at gcc dot gnu.org]

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

--- Comment #6 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Tue Nov 17 16:29:45 2015
New Revision: 230465

URL: https://gcc.gnu.org/viewcvs?rev=230465&root=gcc&view=rev
Log:
2015-11-17  Dominique d'Humieres 

PR fortran/65751
* expr.c (gfc_check_pointer_assign): Fix error message.

* gfortran.dg/unlimited_polymorphic_2.f03: Update test.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/unlimited_polymorphic_2.f03

[Bug tree-optimization/68317] [6 regression] ice in set_value_range, at tree-vrp.c:380

[jiwang at gcc dot gnu.org]

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

--- Comment #6 from Jiong Wang  ---
Created attachment 36741
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36741&action=edit
prototype-fix

(In reply to Richard Biener from comment #3)
> (gdb) p debug_generic_expr (max)
> 4294443008(OVF)
> +  # ivtmp.8_8 = PHI <4294443008(OVF)(2), ivtmp.8_11(4)>
> +  _5 = (int) ivtmp.8_8;
>fn2 (_5);
> -  i_7 = i_1 + -1;
>  
>:
> +  ivtmp.8_11 = ivtmp.8_8 - 524288;
>goto ;
>  
>  }
> 
> note that the infinite loop contains undefined overflow.
> 
> IVOPTs should simply strip the overflow flag (using drop_tree_overflow).

And my further investigation shows PR68326 is caused by the same issue.

 # ivtmp.8_8 = PHI <4294443008(OVF)(2), ivtmp.8_11(4)>

the new phi node destination is with unsigned int type, the constant
value 4294443008 can fit into it, it's marked as OVF because
it's treated as signed type. For the simple testcase in PR68326,
the overflow number is 4294967286 which is -10, while there happen be
another signed integer with initial value -10. So, looks like the unsigned
4294967286 somehow inherited the signed type from the other value in some
tree pass, then some valid constant is marked with OVF unnecessarily.

Anyway, below is my fix, does it looks the correct approach to you?

drop_tree_overflow is invoked during create_iv, if the constant can actually
fit into the type. I only checked INTEGER_CST, not for others like REAL, as I
though they won't suffer from the unsigned/signed type issue.

x86-64 bootstrap is OK with this patch, will do more testing if the approach is
OK.

diff --git a/gcc/tree-ssa-loop-manip.c b/gcc/tree-ssa-loop-manip.c
index b614412..55a6334 100644
--- a/gcc/tree-ssa-loop-manip.c
+++ b/gcc/tree-ssa-loop-manip.c
@@ -136,6 +136,11 @@ create_iv (tree base, tree step, tree var, struct loop
*loop,
 gsi_insert_seq_on_edge_immediate (pe, stmts);

   phi = create_phi_node (vb, loop->header);
+  if (TREE_OVERFLOW (initial)
+  && TREE_CODE (initial) == INTEGER_CST
+  && int_fits_type_p (initial, TREE_TYPE (vb)))
+initial = drop_tree_overflow (initial);
+
   add_phi_arg (phi, initial, loop_preheader_edge (loop), UNKNOWN_LOCATION);
   add_phi_arg (phi, va, loop_latch_edge (loop), UNKNOWN_LOCATION);
 }

[Bug c++/68388] New: incomplete type bug when using decltype

[ryan.burn at gmail dot com]

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

Bug ID: 68388
   Summary: incomplete type bug when using decltype
   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 compiles fine with clang
(http://melpon.org/wandbox/permlink/Rm6dpbmC0N3eMJJa) and earlier versions of
gcc-6, but was recently broken. Gcc gives this error when compiling:

bug.cpp: In instantiation of ‘auto map_impl(std::index_sequence,
Functor, T1, T2) [with int ...Indexes = {0}; Functor = Less; T1 = Tuple;
T2 = Tuple]’:
bug.cpp:27:11:   required from ‘auto map_impl(Functor, T1, T2) [with Functor =
Less; T1 = Tuple; T2 = Tuple]’
bug.cpp:40:26:   required from here
bug.cpp:22:3: error: invalid use of incomplete type ‘class Tuple(f, t1, t2))...>’
   Tuple(f, t1, t2))...>();
   ^

bug.cpp:8:27: note: declaration of ‘class Tuple(f, t1, t2))...>’
 template  class Tuple {};

///
typedef int size_t; 
template
struct index_sequence {};   
}   


template  class Tuple {}; 

template   
auto get(Tuple) {   
  return TFirst();  
}   

template  
auto apply_impl(Functor f, T1 t1, T2 t2) {  
  return f(get(t1), get(t2)); 
}   

template 
auto map_impl(std::index_sequence, Functor f, T1 t1, T2 t2) {   
  Tuple(f, t1, t2))...>(); 
}   

template 
auto map_impl(Functor f, T1 t1, T2 t2) {
  map_impl(std::index_sequence<0>(), f, t1, t2);
}   

struct Less {   
  template
  auto operator()(Lhs lhs, Rhs rhs) -> decltype(lhs < rhs) {
return lhs < rhs;   
  } 
};  

int main() {
  auto t1 = Tuple();   
  auto t2 = Tuple();   
  map_impl(Less(), t1, t2); 
}
///

[Bug sanitizer/64820] Libsanitizer fails with ((AddrIsAlignedByGranularity(addr + size))) != (0)" (0x0, 0x0) if ssp is enabled.

[chefmax at gcc dot gnu.org]

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

--- Comment #7 from Maxim Ostapenko  ---
(In reply to joakim.tjernl...@transmode.se from comment #6)
> Is this fix in gcc 4.9.3?

No, this didn't go to GCC 4.9, only to GCC 5.

> If not, will go into 4.9.4?

Well, actually we didn't plan backport this on gcc-4.9 branch, the case is
quite specific. But I think it would be pretty easy to backport the fix now. I
can do it if there aren't objections from GCC hackers.

[Bug libstdc++/65329] [C++14] constexpr complex::real(), imag() are non-const

[pipping at exherbo dot org]

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

Elias Pipping  changed:

   What|Removed |Added

 CC||pipping at exherbo dot org

--- Comment #4 from Elias Pipping  ---
For future reference and anyone else trying to understand this bug, a bit more
info:

The fix in r216258 makes something like the following compile in C++14 mode
again:

#include 

int
main()
{
  std::complex const x(1,2);
  int r = x.real();
}

The fact that int is used as the template parameter of std::complex is
important here: float, double, and long double are handled through a
specialisation that had already been adjusted in r198141.

Since the effect of instantiating std::complex where T is anything other
than one of those three floating point types is unspecified, types like
std::complex are probably hardly ever used except by accident; it thus
makes sense that it took two years for someone to come across this (although I
guess instead of int, users will probably typically plug in custom floating
point types).

[Bug sanitizer/64820] Libsanitizer fails with ((AddrIsAlignedByGranularity(addr + size))) != (0)" (0x0, 0x0) if ssp is enabled.

[joakim.tjernlund at transmode dot se]

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

--- Comment #8 from joakim.tjernlund at transmode dot se  ---
As stack protector is default in gcc, I don't think it is specific.
I did bite me on ppc with only -fsanitize=address and
ASAN_OPTIONS=detect_stack_use_after_return=1

[Bug lto/68384] LTO error for global register variables in PHP 7 compiling on powerpc64le

[acsawdey at gcc dot gnu.org]

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

--- Comment #5 from acsawdey at gcc dot gnu.org ---
The partitioning seems to be involved. If you add -flto-partition=max, you can
get past the global register error. However 230270 that I've been using for
testing then hits a recursive inlining error that looks a lot like 59626 when
trying to compile all of PHP 7. However gcc 5.2 is able to compile the whole
thing using -flto-partition=max.

I think I need to update my trunk build and then see if the recursive inlining
error persists.

[Bug other/56036] Wrong indentation in multiple -O options explaination

[sandra at gcc dot gnu.org]

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

--- Comment #4 from sandra at gcc dot gnu.org ---
Author: sandra
Date: Tue Nov 17 18:06:01 2015
New Revision: 230467

URL: https://gcc.gnu.org/viewcvs?rev=230467&root=gcc&view=rev
Log:
2015-11-17  Sandra Loosemore  

PR target/56036
* doc/invoke.texi (Option Summary): Add -mms-bitfields to x86
option list.
(x86 Options): Add -mms-bitfields and -mno-ms-bitfields.  Move
discussion of the Microsoft structure layout details here from
its former home in extend.texi.
* doc/extend.texi (x86 Variable Attributes): Replace detailed
discussion with pointer to its new location.  Add cross-reference
to corresponding type attributes.
(x86 Type Attributes): Add cross-references to command-line options
and variable attributes.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/extend.texi
trunk/gcc/doc/invoke.texi

[Bug c++/68308] [6 Regression] ICE: tree check: expected integer_cst, have var_decl in decompose, at tree.h:5105

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Author: msebor
Date: Tue Nov 17 18:09:36 2015
New Revision: 230468

URL: https://gcc.gnu.org/viewcvs?rev=230468&root=gcc&view=rev
Log:
PR c++/68308 - [6 Regression] ICE: tree check: expected integer_cst,
have var_decl in decompose, at tree.h:5105

gcc/
* cp/init.c (build_new_1): Check for expression constness
the right way.

testsuite/
* g++.dg/init/new46.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/init/new46.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/68308] [6 Regression] ICE: tree check: expected integer_cst, have var_decl in decompose, at tree.h:5105

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
Fixed via r230468.

[Bug bootstrap/68361] [6 regression] Bootstrap failure with --enable-checking=release

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Tue Nov 17 18:16:29 2015
New Revision: 230470

URL: https://gcc.gnu.org/viewcvs?rev=230470&root=gcc&view=rev
Log:
PR bootstrap/68361

* cvt.c (cp_convert_and_check): Use warning_sentinel to suppress
-Wparentheses.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wparentheses-28.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cvt.c

[Bug bootstrap/68346] [6 Regression] Bootstrap failure on i686-linux

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Tue Nov 17 18:16:35 2015
New Revision: 230471

URL: https://gcc.gnu.org/viewcvs?rev=230471&root=gcc&view=rev
Log:
PR bootstrap/68346

* c-common.c (warn_tautological_cmp): Fold before checking for
constants.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wtautological-compare2.C
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c

[Bug target/53587] [manual] Option -mms-bitfields not documented

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from sandra at gcc dot gnu.org ---
Fixed in commit 230467 (sorry, I screwed up the PR # in the commit message so
it didn't get recorded here automatically).

[Bug tree-optimization/68389] New: internal compiler error: in tree_low_cst, at tree.h:4431

[ketan.surender at gmail dot com]

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

Bug ID: 68389
   Summary: internal compiler error: in tree_low_cst, at
tree.h:4431
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ketan.surender at gmail dot com
  Target Milestone: ---

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

For the attached file I am seeing an internal compiler error with -O3 

COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-ansi' '-pedantic'
'-Wno-long-long' '-fwrapv' '-fPIC' '-O3' '-D' 'MODEL=xOutOfOrderWrites_exec'
'-D' 'HAVESTDIO' '-D' 'USE_RTMODEL' '-D' 'UNIX' '-I' 'anotherPath/gccBugs' '-I'
'anotherPath/gccBugs/codegen/dll/xOutOfOrderWrites' '-I' 'aPath/extern/include'
'-I' 'aPath/simulink/include' '-I' 'aPath/rtw/c/src' '-I'
'aPath/rtw/c/src/ext_mode/common' '-I' 'aPath/rtw/c/ert' '-o'
'xOutOfOrderWrites.o' '-mtune=generic' '-march=x86-64'

/anotherAnotherPath/glnxa64/gcc-4.7.2/libexec/gcc/x86_64-unknown-linux-gnu/4.7.2/cc1
-fpreprocessed xOutOfOrderWrites.i -quiet -dumpbase xOutOfOrderWrites.c
-mtune=generic -march=x86-64 -auxbase-strip xOutOfOrderWrites.o -O3 -pedantic
-Wno-long-long -ansi -version -fwrapv -fPIC -o xOutOfOrderWrites.s

xOutOfOrderWrites.c: In function ‘xOutOfOrderWrites’:
xOutOfOrderWrites.c:222:6: internal compiler error: in tree_low_cst, at
tree.h:4431

This can be reproduced with the attached preprocessed file:

gcc -c -O3 xOutOfOrderWrites.i

GCC Version Info:

GNU C (GCC) version 4.7.2 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.2, GMP version 4.3.2, MPFR version 2.4.2,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C (GCC) version 4.7.2 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.2, GMP version 4.3.2, MPFR version 2.4.2,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: aa64e71d3fbf9c408b8b9eecd9fda662

[Bug tree-optimization/68389] internal compiler error: in tree_low_cst, at tree.h:4431

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
4.7.2 isn't supported anymore. Please try a more recent compiler.

[Bug fortran/59910] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:5327

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
I have a patch for this problem.

[Bug target/68390] New: Incorrect code due to indirect tail call of varargs function with hard float ABI

[kugan at gcc dot gnu.org]

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

Bug ID: 68390
   Summary: Incorrect code due to indirect tail call of varargs
function with hard float ABI
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kugan at gcc dot gnu.org
  Target Milestone: ---

__attribute__ ((noinline))
double direct(int x, ...)
{
  return x*x;
}

__attribute__ ((noinline))
double broken(double (*indirect)(int x, ...), int v)
{
  return indirect(v);
}

int main ()
{
  double d1, d2;
  int i = 2;
  d1 = broken (direct, i);
  if (d1 != i*i)
{
  __builtin_abort ();
}
  return 0;
}


Please note that we have a sibcall from "broken" to "indirect".

"direct" is variadic function so it is conforming to AAPCS base standard.

"broken" is a non-variadic function and will return the value in
floating point register for TARGET_HARD_FLOAT. Thus we should not be
doing sibcall here.

[Bug libstdc++/66059] make_integer_sequence should use a log(N) implementation

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Fixed on trunk

[Bug libstdc++/66059] make_integer_sequence should use a log(N) implementation

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Tue Nov 17 19:54:33 2015
New Revision: 230496

URL: https://gcc.gnu.org/viewcvs?rev=230496&root=gcc&view=rev
Log:
PR libstdc++/66059 optimise _Build_index_tuple

PR libstdc++/66059
* include/std/utility (_Build_index_tuple): Optimise.

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

[Bug libstdc++/66059] make_integer_sequence should use a log(N) implementation

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Daniel Frey from comment #3)
> A better O(log N) library-only solution than the linked one is available at
> https://github.com/taocpp/sequences/blob/master/include/tao/seq/
> make_integer_sequence.hpp

The version I came up with is very close to Xeo's at stackoverflow. I tried
something more like yours and it used a LOT more memory.

Here's what I tested:

#include 

namespace std
{
  template struct _Index_tuple { };

#if DUP
  template struct _Itup_dup;

  template
struct _Itup_dup<_Index_tuple<_Ind...>, 0>
{
  static constexpr size_t _Nm = sizeof...(_Ind);
  using __type = _Index_tuple<_Ind..., _Nm + _Ind...>;
};

  template
struct _Itup_dup<_Index_tuple<_Ind...>, 1>
{
  static constexpr size_t _Nm = sizeof...(_Ind);
  using __type = _Index_tuple<_Ind..., _Nm + _Ind..., 2 * _Nm>;
};

  // Builds an _Index_tuple<0, 1, 2, ..., _Num-1>.
  template
struct _Build_index_tuple
{
  using __type = typename _Itup_dup<
typename _Build_index_tuple<_Num / 2>::__type, _Num % 2>::__type;
};
#else
  template struct _Itup_cat;

  template
struct _Itup_cat<_Index_tuple<_Ind1...>, _Index_tuple<_Ind2...>>
{
  using __type = _Index_tuple<_Ind1..., (_Ind2 + sizeof...(_Ind1))...>;
};

  template
struct _Build_index_tuple
: _Itup_cat::__type,
typename _Build_index_tuple<_Num - _Num / 2>::__type>
{ };
#endif

  template<>
struct _Build_index_tuple<1> { typedef _Index_tuple<0> __type; };

  template<>
struct _Build_index_tuple<0> { typedef _Index_tuple<> __type; };

}

template struct is_same { static const bool value =
false; };
template struct is_same { static const bool value = true; };

int main()
{
constexpr auto N = 1024;
using T = std::_Build_index_tuple::__type;
static_assert(sizeof(T), "");
static_assert( is_same::__type,
std::_Index_tuple<0, 1, 2, 3, 4, 5, 6, 7, 8, 9>>::value, "");
static_assert( is_same::__type,
std::_Index_tuple<0, 1, 2, 3, 4, 5, 6, 7, 8>>::value, "");

}



tmp$ g++11 it.cc -ftime-report 

Execution times (seconds)
 phase setup :   0.01 (11%) usr   0.00 ( 0%) sys   0.02 (20%) wall 
  1396 kB (15%) ggc
 phase parsing   :   0.07 (78%) usr   0.01 (100%) sys   0.08 (80%) wall
   7235 kB (80%) ggc
 phase opt and generate  :   0.01 (11%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall 
   421 kB ( 5%) ggc
 |name lookup:   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 (10%) wall 
   111 kB ( 1%) ggc
 |overload resolution:   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 (10%) wall 
66 kB ( 1%) ggc
 garbage collection  :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 (10%) wall 
 0 kB ( 0%) ggc
 template instantiation  :   0.07 (78%) usr   0.01 (100%) sys   0.07 (70%) wall
   6763 kB (75%) ggc
 initialize rtl  :   0.01 (11%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall 
 8 kB ( 0%) ggc
 TOTAL :   0.09 0.01 0.10  
9066 kB
Extra diagnostic checks enabled; compiler may run slowly.
Configure with --enable-checking=release to disable checks.
tmp$ g++11 it.cc -ftime-report -DDUP

Execution times (seconds)
 phase setup :   0.00 ( 0%) usr   0.01 (33%) sys   0.02 ( 2%) wall 
  1396 kB ( 3%) ggc
 phase parsing   :   0.91 (99%) usr   0.02 (67%) sys   0.93 (98%) wall 
 45729 kB (96%) ggc
 phase finalize  :   0.01 ( 1%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall 
 0 kB ( 0%) ggc
 garbage collection  :   0.01 ( 1%) usr   0.00 ( 0%) sys   0.01 ( 1%) wall 
 0 kB ( 0%) ggc
 preprocessing   :   0.01 ( 1%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall 
30 kB ( 0%) ggc
 parser struct body  :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 1%) wall 
22 kB ( 0%) ggc
 template instantiation  :   0.89 (97%) usr   0.02 (67%) sys   0.91 (96%) wall 
 45262 kB (95%) ggc
 TOTAL :   0.92 0.03 0.95 
47577 kB
Extra diagnostic checks enabled; compiler may run slowly.
Configure with --enable-checking=release to disable checks.

As you can see, defining DUP makes it 10 times slower and using 5 times as much
memory. Looking at your implementation I see only one relevant difference, you
pass N/2 as a template argument instead of calculating it with sizeof... i.e.

  template struct _Itup_dup;

  template
struct _Itup_dup<_Index_tuple<_Ind...>, _Nm, 0>
{
  using __type = _Index_tuple<_Ind..., _Nm + _Ind...>;
};

  template
struct _Itup_dup<_Index_tuple<_Ind...>, _Nm, 1>
{
  using __type = _Index_tuple<_Ind..., _Nm + _Ind..., 2 * _Nm>;
};

  // Builds an _Index_tuple<0, 1, 2, ..., _Num-1>.
  template
struct _Build_index_tuple
: typename _Itup_dup<
typename _Build_index_tuple<_Num / 2>::__type, _Num / 2, _Num % 2>
{ };

and indeed this is even faster than what I just committed. I didn't r

[Bug c++/68391] New: -Wsuggest-override does not work on Item 12 of Effective Modern C++

[rhalbersma at gmail dot com]

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

Bug ID: 68391
   Summary: -Wsuggest-override does not work on Item 12 of
Effective Modern C++
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rhalbersma at gmail dot com
  Target Milestone: ---

Item 12 of Effective Modern C++ contains this example:

class Base {
public:
virtual void mf1() const;
virtual void mf2(int x);
virtual void mf3() &;
void mf4() const;
};

class Derived: public Base {
public:
virtual void mf1();
virtual void mf2(unsigned int x);
virtual void mf3() &&;
void mf4() const;
};

int main(){}

gcc -Wsuggest-override does not yield a single warning (-Wall -Wextra -pedantic
don't help either). In contrast, clang -Woverloaded-virtual warns about mf1
through mf3.

[Bug middle-end/68392] New: ICE: SIGSEGV in update_uses (fwprop.c:896) with -fno-checking

[zsojka at seznam dot cz]

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

Bug ID: 68392
   Summary: ICE: SIGSEGV in update_uses (fwprop.c:896) with
-fno-checking
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---

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

Compiler output:
$ aarch64-unknown-linux-gnu-gcc -O -fno-checking testcase.c -wrapper
valgrind,-q,--num-callers=40
==16356== Invalid read of size 8
==16356==at 0x63A: sparseset_bit_p (sparseset.h:143)
==16356==by 0x63A: update_uses (fwprop.c:896)
==16356==by 0x63A: update_df(rtx_insn*, rtx_def*) (fwprop.c:919)
==16356==by 0x11127FC: try_fwprop_subst(df_ref_d*, rtx_def**, rtx_def*,
rtx_insn*, bool) (fwprop.c:1007)
==16356==by 0x1112F2A: forward_propagate_and_simplify (fwprop.c:1321)
==16356==by 0x1112F2A: forward_propagate_into(df_ref_d*) (fwprop.c:1374)
==16356==by 0x1113C24: fwprop (fwprop.c:1457)
==16356==by 0x1113C24: (anonymous
namespace)::pass_rtl_fwprop::execute(function*) (fwprop.c:1490)
==16356==by 0xA29FF7: execute_one_pass(opt_pass*) (passes.c:2325)
==16356==by 0xA2A597: execute_pass_list_1(opt_pass*) (passes.c:2398)
==16356==by 0xA2A5A9: execute_pass_list_1(opt_pass*) (passes.c:2399)
==16356==by 0xA2A5F4: execute_pass_list(function*, opt_pass*)
(passes.c:2409)
==16356==by 0x703593: cgraph_node::expand() (cgraphunit.c:1965)
==16356==by 0x704E95: expand_all_functions (cgraphunit.c:2101)
==16356==by 0x704E95: symbol_table::compile() (cgraphunit.c:2450)
==16356==by 0x706D85: symbol_table::finalize_compilation_unit()
(cgraphunit.c:2540)
==16356==by 0xB2A1D3: compile_file() (toplev.c:489)
==16356==by 0x56C7BD: do_compile (toplev.c:1951)
==16356==by 0x56C7BD: toplev::main(int, char**) (toplev.c:2058)
==16356==by 0x56E576: main (main.c:39)
==16356==  Address 0x18 is not stack'd, malloc'd or (recently) free'd
==16356== 
testcase.c: In function 'foo':
testcase.c:8:1: internal compiler error: Segmentation fault
 }
 ^

Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$ aarch64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-230409-checking-release-nographite-aarch64/libexec/gcc/aarch64-unknown-linux-gnu/6.0.0/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=release
--enable-languages=c,c++
--prefix=/mnt/svn/gcc-trunk/binary-230409-checking-release-nographite-aarch64/
--without-cloog --without-ppl --without-isl --host=x86_64-pc-linux-gnu
--target=aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--with-sysroot=/home/aarch64-chroot
--with-as=/usr/libexec/gcc/aarch64-unknown-linux-gnu/as
--with-ld=/usr/libexec/gcc/aarch64-unknown-linux-gnu/ld
Thread model: posix
gcc version 6.0.0 20151116 (experimental) (GCC) 


I don't have any other recent GCC by hand than this aarch64 crosscompiler,
configured with --enable-checking=yes,rtl,df

Tested revisions:
r230409 - ICE

[Bug middle-end/68392] ICE: SIGSEGV in update_uses (fwprop.c:896) with -fno-checking

[zsojka at seznam dot cz]

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

--- Comment #1 from Zdenek Sojka  ---
$ aarch64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/mnt/svn/gcc-trunk/binary-230409-checking-yes-rtl-df-nographite-aarch64/bin/aarch64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-230409-checking-yes-rtl-df-nographite-aarch64/libexec/gcc/aarch64-unknown-linux-gnu/6.0.0/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df
--enable-languages=c,c++
--prefix=/mnt/svn/gcc-trunk/binary-230409-checking-yes-rtl-df-nographite-aarch64/
--without-cloog --without-ppl --without-isl --host=x86_64-pc-linux-gnu
--target=aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--with-sysroot=/home/aarch64-chroot
--with-as=/usr/libexec/gcc/aarch64-unknown-linux-gnu/as
--with-ld=/usr/libexec/gcc/aarch64-unknown-linux-gnu/ld
Thread model: posix
gcc version 6.0.0 20151116 (experimental) (GCC) 


The version information in comment #0 is wrong; the --enable-checking=release
compiler doesn't have any problems (with either -f{no-,}checking)

[Bug libstdc++/66059] make_integer_sequence should use a log(N) implementation

[d.frey at gmx dot de]

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

--- Comment #8 from Daniel Frey  ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to Daniel Frey from comment #3)
> > A better O(log N) library-only solution than the linked one is available at
> > https://github.com/taocpp/sequences/blob/master/include/tao/seq/
> > make_integer_sequence.hpp
> 
> The version I came up with is very close to Xeo's at stackoverflow. I tried
> something more like yours and it used a LOT more memory.
> 
> Here's what I tested:
> 
> [...snip...]
> 
> As you can see, defining DUP makes it 10 times slower and using 5 times as
> much memory. Looking at your implementation I see only one relevant
> difference, you pass N/2 as a template argument instead of calculating it
> with sizeof... i.e.

Yeah, avoiding sizeof... is crucial. I don't really know why, I just know it
is. And only for GCC, Clang doesn't care if you use sizeof... or pass in the
size explicitly. This behavior from GCC might be worth a look from the compiler
people, as there is no reason why it should use so much more memory.

> and indeed this is even faster than what I just committed. I didn't realise
> sizeof... would have such an impact.
> 
> My one can be optimised to be almost as fast by avoiding sizeof... in
> _Itup_cat.

I guess my version (without the sizeof...) is still better the larger the
numbers get, but it won't make a real difference in practice as it's kind of
unrealistic to generate index sequences with 10 or more elements.

[Bug c/48568] Missing documentation for __attribute__((visibility ("protected"))) on variables.

[sandra at gcc dot gnu.org]

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

--- Comment #1 from sandra at gcc dot gnu.org ---
Author: sandra
Date: Tue Nov 17 21:07:15 2015
New Revision: 230498

URL: https://gcc.gnu.org/viewcvs?rev=230498&root=gcc&view=rev
Log:
2015-11-17  Sandra Loosemore  

PR 48568
* doc/extend.texi (Common Function Attributes) [visibility]:
Add cross-references to matching variable and type attributes.
(Common Variable Attributes) [visibility]: Add missing entry.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/extend.texi

[Bug c/48568] Missing documentation for __attribute__((visibility ("protected"))) on variables.

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from sandra at gcc dot gnu.org ---
Fixed on trunk now.

[Bug middle-end/68393] New: internal compiler error: in convert_move, at expr.c:286

[anton at samba dot org]

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

Bug ID: 68393
   Summary: internal compiler error: in convert_move, at
expr.c:286
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anton at samba dot org
  Target Milestone: ---

I'm seeing an ICE on powerpc64le when building trunk:

x.c:3:9: internal compiler error: in convert_move, at expr.c:286
  return __builtin_clzll(x);
 ^~

0x104a8907 convert_move(rtx_def*, rtx_def*, int)
../../gcc/gcc/expr.c:286
0x105c12ab expand_direct_optab_fn
../../gcc/gcc/internal-fn.c:2114
0x105c1f17 expand_internal_call(internal_fn, gcall*)
../../gcc/gcc/internal-fn.c:2245
0x10348443 expand_call_stmt
../../gcc/gcc/cfgexpand.c:2565
0x10348443 expand_gimple_stmt_1
../../gcc/gcc/cfgexpand.c:3525
0x10348443 expand_gimple_stmt
../../gcc/gcc/cfgexpand.c:3688
0x1034a5df expand_gimple_basic_block
../../gcc/gcc/cfgexpand.c:5694
0x10351c87 execute
../../gcc/gcc/cfgexpand.c:6309

A testcase:

unsigned long foo(x)
{
return __builtin_clzll(x);
}

[Bug target/66785] internal compiler error in record_operand_use

[bernds at gcc dot gnu.org]

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

--- Comment #4 from Bernd Schmidt  ---
Author: bernds
Date: Tue Nov 17 21:20:20 2015
New Revision: 230499

URL: https://gcc.gnu.org/viewcvs?rev=230499&root=gcc&view=rev
Log:
PR target/66785
* regrename.c (record_operand_use): Keep track of failed operands
and stop appending if we see any.
* regrename.h (struct operand_rr_info): Add a failed field and shrink
n_chains to short.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/regrename.c
trunk/gcc/regrename.h

[Bug middle-end/68392] ICE: SIGSEGV in update_uses (fwprop.c:896) with -fno-checking

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

 CC||miyuki at gcc dot gnu.org

--- Comment #2 from Mikhail Maltsev  ---
It's probably related to --enable-checking=df

This version (built from snapshot) does not ICE:
$ /opt/gcc-6-latest/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/opt/gcc-6-latest/bin/gcc
COLLECT_LTO_WRAPPER=/opt/gcc-6-latest/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/home/jenkins/workspace/build-gcc-snapshot/src/gcc-6-20151115/configure
--prefix=/opt/gcc-6-latest --enable-clocale=gnu
--enable-languages=c,c++,lto,objc,fortran,jit --enable-host-shared
--disable-nls --with-isl=/opt/isl-0.14 --with-demangler-in-ld
--with-system-zlib --enable-checking=yes --with-fpmath=sse --enable-shared
Thread model: posix
gcc version 6.0.0 20151115 (experimental) (GCC)

[Bug middle-end/68393] internal compiler error: in convert_move, at expr.c:286

[anton at samba dot org]

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

Anton Blanchard  changed:

   What|Removed |Added

 CC||richard.guenther at gmail dot 
com,
   ||rsandifo at gcc dot gnu.org

--- Comment #1 from Anton Blanchard  ---
Bisected to r230487 "Short-cut generation of simple built-in functions"

[Bug target/66785] internal compiler error in record_operand_use

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #5 from Bernd Schmidt  ---
Ah, sorry Jim, I already had a patch. Ramana pointed out this bug but I didn't
expect anyone else to actually investigate it. The overflow case can only occur
in a failure case if the operand can't be renamed, so I've chosen to just
record that fact.
Someone might want to take a look at the aarch64 backend to see if it needs to
take the new "failed" bit into account.

[Bug middle-end/48254] documentation minor

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||sandra at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #6 from sandra at gcc dot gnu.org ---
The duplicate entries for -funroll-loops, -funroll-all-loops, and -ftracer were
removed in commits 219803 and 219813.  I don't think there's anything left to
do here.