[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 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=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

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

[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 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 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 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 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 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 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=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 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 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=gcc=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 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 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 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=gcc=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 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 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=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++/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 ()() = a.mf; // error
}

[Bug fortran/65751] Bogus 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=gcc=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/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 #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 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 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/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 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 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 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 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 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 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 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=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

[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=edit
main.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 #1 from acsawdey at gcc dot gnu.org ---
Created attachment 36735
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36735=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=edit
php_cli.i

[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(  );   // 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 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 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=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 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=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: 

[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=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 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();
   ^

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(); 
}   

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 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

[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 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=gcc=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=gcc=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 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=gcc=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=gcc=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 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 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 other/46218] TARGET_PREFERRED_OUTPUT_RELOAD_CLASS is not documented

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from sandra at gcc dot gnu.org ---
I see this in tm.texi on mainline head:


@deftypefn {Target Hook} reg_class_t TARGET_PREFERRED_OUTPUT_RELOAD_CLASS (rtx
@
var{x}, reg_class_t @var{rclass})
Like @code{TARGET_PREFERRED_RELOAD_CLASS}, but for output reloads instead of
input reloads.

The default version of this hook always returns value of @code{rclass}
argument.

You can also use @code{TARGET_PREFERRED_OUTPUT_RELOAD_CLASS} to discourage
reload from using some alternatives, like @code{TARGET_PREFERRED_RELOAD_CLASS}.
@end deftypefn


I think there is nothing to do here any more.

[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

--- Comment #3 from Anton Blanchard  ---
No problems Richard! Thanks for the quick fix, it works for me.

[Bug other/42270] manual's sections are ordered counter intuitively

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #1 from sandra at gcc dot gnu.org ---
The specific problem with the ordering of the attributes sections has been
fixed on trunk, but there are still other organizational problems with the
chapter (now numbered chapter 6) on "Extensions to the C Language Family".  I
think introducing another level of sections to group existing sections by topic
would make it easier to find things.

[Bug tree-optimization/66949] [6 Regression] ICE at -O2 and -O3 on x86_64-linux-gnu in tree_ssa_phiopt_worker, at tree-ssa-phiopt.c:335

[anton at samba dot org]

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

Anton Blanchard  changed:

   What|Removed |Added

 CC||anton at samba dot org

--- Comment #3 from Anton Blanchard  ---
I'm seeing this on powerpc64le with the following testcase:

char a;
int b, c, d;

short fn1(short p1, short p2)
{
return p2 == 0 ? p1 : p1 / p2;
}

int main(void)
{
char e = 1;
int f = 7;
c = a >> f;
b = fn1(c, 0 < d <= e && fn2());

return 0;
}

# gcc -O3 -c crash1.i
crash1.i: In function ‘main’:
crash1.i:14:27: warning: implicit declaration of function ‘fn2’
[-Wimplicit-function-declaration]
  b = fn1(c, 0 < d <= e && fn2());
   ^~~

crash1.i:9:5: internal compiler error: in tree_ssa_phiopt_worker, at
tree-ssa-phiopt.c:322
 int main(void)
 ^~~~

0x10a46a23 tree_ssa_phiopt_worker
../../gcc/gcc/tree-ssa-phiopt.c:322

[Bug libgcc/59412] __fixunsdfDI triggers wrong inexact exceptions

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
It's a bug in libgcc2.c for the subset of targets for which this code gets 
used (note 64-bit targets will generally be using it for TImode not 
DImode) *and* which have hardware exceptions.  It's part of the general 
large group of bugs relating to code generation / transformations not 
consistently accounting for exceptions / rounding modes.

[Bug libgcc/59412] __fixunsdfDI triggers wrong inexact exceptions

[pangbw at gmail dot com]

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

--- Comment #2 from baoshan  ---
Why this has been unconfirmed for so long time? Can someone tell us if this is
a bug in libgcc2.c or not? Thanks.

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

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-11-17
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Created attachment 36747
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36747=edit
Suggested patch

Sorry for the breakage.  Please could you try the attached patch?

(FWIW I did try testing on powerpc64el-linux-gnu before posting
the series, but the build died during stage 2 for unrelated
reasons.)

[Bug libgcc/59412] __fixunsdfDI triggers wrong inexact exceptions

[pangbw at gmail dot com]

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

--- Comment #4 from baoshan  ---
(In reply to jos...@codesourcery.com from comment #3)
> It's a bug in libgcc2.c for the subset of targets for which this code gets 
> used (note 64-bit targets will generally be using it for TImode not 
> DImode) *and* which have hardware exceptions.  It's part of the general 
> large group of bugs relating to code generation / transformations not 
> consistently accounting for exceptions / rounding modes.

Hi Joseph,

Thanks for the quick response.
Do you know if there is fix for this issue? 

Thanks,
Baoshan

[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 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 

[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=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 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

[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 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=gcc=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 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 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=gcc=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 libgcc/59412] __fixunsdfDI triggers wrong inexact exceptions

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com  ---
I'm not aware of anyone working on these exceptions / rounding modes 
issues.

[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 #36 from Gary Funck  ---
(In reply to rguent...@suse.de from comment #35)
> 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
> [... patch ..]
> help?  (without the comment #29 patch)
> 
> Does the patch in comment #25 help?

It is getting a bit confusing.  Can you post a single patch to a given trunk
reviiosn?

[Bug c++/68399] New: c++11 default initialization of a large array: slow compile

[kcc at gcc dot gnu.org]

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

Bug ID: 68399
   Summary: c++11 default initialization of a large array: slow
compile
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kcc at gcc dot gnu.org
  Target Milestone: ---

Reproducible with 4.8.2 and fresh trunk (r230509). 

% gcc -O1 z.cpp -std=c++11 -c


#ifndef SZ
# define SZ 16
#endif
struct Range {
  short B, E;
  Range() : B(0), E(0) {}
};
struct ArrayOfRanges {
  Range LabelRanges[1 << SZ] = {};
};
ArrayOfRanges *AOR = new ArrayOfRanges();


This code will take ~10 minutes to compile at -O1
The larger the SZ is the longer it takes.

[Bug target/68400] New: ICE in change_address_1, at emit-rtl.c:2125

[nbd at nbd dot name]

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

Bug ID: 68400
   Summary: ICE in change_address_1, at emit-rtl.c:2125
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nbd at nbd dot name
  Target Milestone: ---

Created attachment 36748
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36748=edit
Proposed fix

When MIPS16 is enabled, I get the following ICE when compiling libpcap:

./pcap-common.c: In function 'swap_linux_usb_header.isra.0':
./pcap-common.c:1296:1: internal compiler error: in change_address_1, at
emit-rtl.c:2125
 }

I've analyzed this, and found that it generates a single-byte load from the
stack, which is not valid in MIPS16 - only size 4 or 8 is valid for access with
offset from the stack pointer, as explained by the comment in
mips_regno_mode_ok_for_base_p().

I've attached a patch which fixes the issue.

[Bug c++/68396] bug with parameter pack expansion

[ryan.burn at gmail dot com]

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

--- Comment #1 from ryan.burn at gmail dot com ---
It looks like this was caused with the commit "Handle auto parameter packs."
(https://github.com/gcc-mirror/gcc/commit/018c146eec4143116f7f422239d56eb4047be3a4#diff-8570312acacadf34317aa24621800c00)

The addition of these lines to the function find_parameter_packs_r in pt.c

+  if (ppd->type_pack_expansion_p && is_auto_or_concept (t))
+   TEMPLATE_TYPE_PARAMETER_PACK (t) = true;

are interfering with non-pack autos. If I remove them, the code compiles fine.

[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 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 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 fortran/65751] Bogus 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 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

[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 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/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 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?