[Bug c++/68689] flexible array members in unions accepted in C++

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-12-04
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Working on a patch.

[Bug c++/68689] New: flexible array members in unions accepted in C++

[msebor at gcc dot gnu.org]

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

Bug ID: 68689
   Summary: flexible array members in unions accepted in C++
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC (in C mode) rejects flexible array members in unions.  G++ (i.e., in C++
mode) accepts them.  Since flexible array members are a G++ extension provided
for compatibility with C, and specifically GCC, G++ should accept and reject
the same constructs as GCC does.

$ cat z.cpp && /build/gcc-trunk-svn/gcc/xg++ -B /build/gcc-trunk-svn/gcc -S
-Wall -Wextra -Wpedantic -o/dev/null z.cpp
union U {
int n;
int a[];
} u;
z.cpp:3:11: warning: ISO C++ forbids zero-size array ‘a’ [-Wpedantic]
 int a[];
   ^

[Bug target/68690] New: PowerPC64: TOC save in PHP core loop results in load hit store

[anton at samba dot org]

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

Bug ID: 68690
   Summary: PowerPC64: TOC save in PHP core loop results in load
hit store
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anton at samba dot org
  Target Milestone: ---

We see a load hit store issue in the core loop of the PHP interpreter. A simple
test case:

$ cat test.c

void (*fn)(void);

void do_nothing(void) { }

int main(void)
{
unsigned long i;

fn = do_nothing;
for (i = 0; i < 10; i++)
fn();

return 0;
}

$ gcc -O2 -o test test.c

We continually save the TOC on each call:

13f0:   00 00 3e e9 ld  r9,0(r30)
13f4:   a6 03 29 7d mtctr   r9
13f8:   78 4b 2c 7d mr  r12,r9
13fc:   18 00 41 f8 std r2,24(r1) <-- save it again!
1400:   21 04 80 4e bctrl
1404:   18 00 41 e8 ld  r2,24(r1)
1408:   01 00 3f 2c cmpdi   r31,1
140c:   ff ff ff 3b addir31,r31,-1
1410:   e0 ff 82 40 bne 13f0 

This should be moved out of the loop. One way to force that is via the
-msave-toc-indirect option:

gcc -msave-toc-indirect -O2 -o test test.c

Which is over 2x faster on this (admittedly worst case) test. For something
more real world, we also see a 20% speedup on PHP7 on various microbenchmarks.

[Bug tree-optimization/68692] New: [graphite] ice: Segmentation fault

[Joost.VandeVondele at mat dot ethz.ch]

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

Bug ID: 68692
   Summary: [graphite] ice: Segmentation fault
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Joost.VandeVondele at mat dot ethz.ch
  Target Milestone: ---

> cat bug.f90
MODULE spme
  INTEGER, PARAMETER :: dp=8
  PRIVATE
  PUBLIC :: get_patch
CONTAINS
  SUBROUTINE get_patch ( part, box, green, npts, p, rhos, is_core, is_shell,&
 unit_charge, charges, coeff, n )
INTEGER, POINTER :: box
REAL(KIND=dp), &
  DIMENSION(-(n-1):n-1, 0:n-1), &
  INTENT(IN) :: coeff
INTEGER, DIMENSION(3), INTENT(IN):: npts
REAL(KIND=dp), DIMENSION(:, :, :), &
  INTENT(OUT):: rhos
REAL(KIND=dp):: q
REAL(KIND=dp), DIMENSION(3)  :: delta, r
CALL get_delta ( box, r, npts, delta, nbox )
CALL spme_get_patch ( rhos, nbox, delta, q, coeff )
  END SUBROUTINE get_patch
  SUBROUTINE spme_get_patch ( rhos, n, delta, q, coeff )
REAL(KIND=dp), DIMENSION(:, :, :), &
  INTENT(OUT):: rhos
REAL(KIND=dp), DIMENSION(3), INTENT(IN)  :: delta
REAL(KIND=dp), INTENT(IN):: q
REAL(KIND=dp), &
  DIMENSION(-(n-1):n-1, 0:n-1), &
  INTENT(IN) :: coeff
INTEGER, PARAMETER   :: nmax = 12
REAL(KIND=dp), DIMENSION(3, -nmax:nmax)  :: w_assign
REAL(KIND=dp), DIMENSION(3, 0:nmax-1):: deltal
REAL(KIND=dp), DIMENSION(3, 1:nmax)  :: f_assign
DO l = 1, n-1
   deltal ( 3, l ) = deltal ( 3, l-1 ) * delta ( 3 )
END DO
DO j = -(n-1), n-1, 2
   DO l = 0, n-1
  w_assign ( 1, j ) =  w_assign ( 1, j ) + &
 coeff ( j, l ) * deltal ( 1, l )
   END DO
   f_assign (3, i ) = w_assign ( 3, j )
   DO i2 = 1, n
  DO i1 = 1, n
 rhos ( i1, i2, i3 ) = r2 * f_assign ( 1, i1 )
  END DO
   END DO
END DO
  END SUBROUTINE spme_get_patch
  SUBROUTINE get_delta ( box, r, npts, delta, n )
INTEGER, POINTER :: box
REAL(KIND=dp), DIMENSION(3), INTENT(IN)  :: r
INTEGER, DIMENSION(3), INTENT(IN):: npts
REAL(KIND=dp), DIMENSION(3), INTENT(OUT) :: delta
INTEGER, DIMENSION(3):: center
REAL(KIND=dp), DIMENSION(3)  :: ca, grid_i, s
CALL real_to_scaled(s,r,box)
s = s - REAL ( NINT ( s ),KIND=dp)
IF ( MOD ( n, 2 ) == 0 ) THEN
   ca ( : ) = REAL ( center ( : ) )
END IF
delta ( : ) = grid_i ( : ) - ca ( : )
  END SUBROUTINE get_delta
END MODULE spme


> gfortran  -c -O3  -floop-nest-optimize  bug.f90
bug.f90:6:0:

   SUBROUTINE get_patch ( part, box, green, npts, p, rhos, is_core, is_shell,&


internal compiler error: Segmentation fault
0xb676cf crash_signal
../../gcc/gcc/toplev.c:334
0xbba647 ssa_default_def(function*, tree_node*)
../../gcc/gcc/tree-dfa.c:305
0xbbd088 get_or_create_ssa_default_def(function*, tree_node*)
../../gcc/gcc/tree-dfa.c:357
0xbf3e83 get_reaching_def
../../gcc/gcc/tree-into-ssa.c:1168
0xbf3e83 get_reaching_def
../../gcc/gcc/tree-into-ssa.c:1155
0xbf5dbe maybe_replace_use
../../gcc/gcc/tree-into-ssa.c:1753
0xbf5dbe rewrite_update_stmt
../../gcc/gcc/tree-into-ssa.c:1948
0xbf5dbe rewrite_update_dom_walker::before_dom_children(basic_block_def*)
../../gcc/gcc/tree-into-ssa.c:2128
0xbf5dbe rewrite_update_dom_walker::before_dom_children(basic_block_def*)
../../gcc/gcc/tree-into-ssa.c:2068
0x125a71a dom_walker::walk(basic_block_def*)
../../gcc/gcc/domwalk.c:176
0xbf28b5 rewrite_blocks
../../gcc/gcc/tree-into-ssa.c:2190
0xbf9a68 update_ssa(unsigned int)
../../gcc/gcc/tree-into-ssa.c:3351
0x128530a graphite_regenerate_ast_isl(scop*)
../../gcc/gcc/graphite-isl-ast-to-gimple.c:3271
0x127cea3 graphite_transform_loops()
../../gcc/gcc/graphite.c:336
0x127d370 graphite_transforms
../../gcc/gcc/graphite.c:363
0x127d370 execute
../../gcc/gcc/graphite.c:440
Please submit a full bug report,

> gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/data/vjoost/gnu/gcc_trunk/install/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/data/vjoost/gnu/gcc_trunk/install
--enable-languages=c,c++,fortran --disable-multilib --enable-plugins
--enable-lto --disable-bootstrap
Thread model: posix
gcc version 6.0.0 20151204 (experimental) [trunk revision 231243] (GCC)

[Bug tree-optimization/68529] scev failed for while(i--)

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from amker at gcc dot gnu.org ---
Fixed.

[Bug rtl-optimization/68691] New: ICE at -O3 with -g enabled on x86_64-linux-gnu in alter_subregs, at lra-spills.c:610 (in 32-bit mode)

[su at cs dot ucdavis.edu]

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

Bug ID: 68691
   Summary: ICE at -O3 with -g enabled on x86_64-linux-gnu in
alter_subregs, at lra-spills.c:610 (in 32-bit mode)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk at
-O3 with -g enabled on x86_64-linux-gnu in the 32-bit mode (but not in 64-bit
mode). 

It is a regression from 5.2.x.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20151203 (experimental) [trunk revision 231219] (GCC) 
$ 
$ gcc-trunk -m32 -O2 -g -c small.c
$ gcc-trunk -m64 -O3 -g -c small.c
$ gcc-5.2 -m32 -O3 -g -c small.c
$ 
$ gcc-trunk -m32 -O3 -g -c small.c
small.c: In function ‘fn1’:
small.c:39:1: internal compiler error: in alter_subregs, at lra-spills.c:610
 }
 ^

0x9a4ccd alter_subregs
../../gcc-trunk/gcc/lra-spills.c:610
0x9a5f32 lra_final_code_change()
../../gcc-trunk/gcc/lra-spills.c:745
0x9868dc lra(_IO_FILE*)
../../gcc-trunk/gcc/lra.c:2383
0x93c449 do_reload
../../gcc-trunk/gcc/ira.c:5383
0x93c449 execute
../../gcc-trunk/gcc/ira.c:5554
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 


--


char a, b, i, j;
int c, d, e, f, g, h, n;

char
fn1 ()
{
  char k, l, m;
  int p;
  e = g > f;
  for (b = 0; b < 2; b++)
{
  for (p = 0; p < 3; p++)
{
  for (; h < 1; h++)
{
  for (; m;)
goto lbl;
  e = g;
}
  l = a < 0 || a < d;
}
  d++;
  for (;;)
{
  k = g;
  n = -k;
  j = n;
  c = j;
  e = 2;
  if (l)
break;
  return 2;
}
}
  for (;;)
;
lbl:
  return i;
}

[Bug c++/68478] flexible array members have complete type

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-12-04
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00511.html

[Bug c++/68613] initializer-string for array of chars is too long error on flexible array member

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00511.html

[Bug lto/68662] [6 regression] FAIL: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o link, -O2 -flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-04
 CC||amodra at gmail dot com
 Ever confirmed|0   |1

--- Comment #2 from Alan Modra  ---
Confirmed.  Also the -O0 variant of this test.  I had a look at assembly output
and see lines like
 addis 30,30,-.L7@ha

This comes from rs6000_emit_load_toc_table use of toc_label_name which appears
to be all-zero.  toc_label_name is supposed to be set in
rs6000_option_override_internal, but apparently isn't because when
rs6000_option_override_internal runs, TARGET_TOC is not true.  Making the
initialisation unconditional isn't enough to cure the problem as that leads to
linker errors about an undefined reference to ".LCTOC1".  That is because code
to set .LCTOC1 isn't being emitted from rs6000_elf_output_toc_section_asm_op.
I haven't verified this, but I'd guess that is because rs6000_file_start
doesn't see flag_pic == 2, and therefore doesn't call switch_to_section
(toc_section).

Notice that c_lto_20090210_0.o does *not* have -fPIC, while c_lto_20090210_1.o
does.

[Bug libstdc++/68688] segmentation fault on regex matching long strings

[timshen at gcc dot gnu.org]

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

Tim Shen  changed:

   What|Removed |Added

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

--- Comment #1 from Tim Shen  ---
This is a known issue, that is the regex engine uses stack frame (through deep
recursion, rather than heap storage) to store data. I plan to fix it after a
series of refactoring, which are waiting for review.

In the mean time, the simplest workaround is to make your stack larger. Sorry
for the inconvenience!

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

[Bug c/53548] allow flexible array members in unions like zero-length arrays

[vapier at gentoo dot org]

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

--- Comment #4 from Mike Frysinger  ---
(In reply to Martin Sebor from comment #3)

that's fine.  thanks !

[Bug tree-optimization/68550] [6 Regression] ICE: verify_gimple failed Error: missing PHI def

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

 CC||sch...@linux-m68k.org

--- Comment #6 from Sebastian Pop  ---
*** Bug 68659 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/68659] [6 regression] FAIL: gcc.dg/graphite/id-pr45230-1.c (internal compiler error)

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #8 from Sebastian Pop  ---
Most likely fixed in r231206.

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

[Bug c/53548] allow flexible array members in unions like zero-length arrays

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-12-04
 Ever confirmed|0   |1

--- Comment #3 from Martin Sebor  ---
Since the C standard requires the test case to be diagnosed and there is an
existing extension that makes the requested functionality possible I'd like to
close this as WONTFIX.  Mike, please let me know if you disagree.

[Bug tree-optimization/68693] New: [6 Regression] ice: in harmful_stmt_in_region, at graphite-scop-detection.c:1052

[Joost.VandeVondele at mat dot ethz.ch]

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

Bug ID: 68693
   Summary: [6 Regression] ice: in harmful_stmt_in_region, at
graphite-scop-detection.c:1052
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Joost.VandeVondele at mat dot ethz.ch
  Target Milestone: ---

> cat bug.f90 
MODULE dbcsr_index_operations
  INTERFACE dbcsr_build_row_index
  END INTERFACE
CONTAINS
  SUBROUTINE merge_index_arrays (new_row_i, new_col_i, new_blk_p, new_size,&
   old_row_i, old_col_i, old_blk_p, old_size,&
   add_ip, add_size, new_blk_d, old_blk_d,&
   added_size_offset, added_sizes, added_size, added_nblks, error)
INTEGER, DIMENSION(new_size), &
  INTENT(OUT):: new_blk_p, new_col_i, &
new_row_i
INTEGER, INTENT(IN)  :: old_size
INTEGER, DIMENSION(old_size), INTENT(IN) :: old_blk_p, old_col_i, &
old_row_i
INTEGER, DIMENSION(new_size), &
  INTENT(OUT), OPTIONAL  :: new_blk_d
INTEGER, DIMENSION(old_size), &
  INTENT(IN), OPTIONAL   :: old_blk_d
INTEGER, DIMENSION(:), INTENT(IN), &
  OPTIONAL   :: added_sizes
INTEGER, INTENT(OUT), OPTIONAL   :: added_size, added_nblks
LOGICAL  :: multidata
IF (add_size .GT. 0) THEN
   IF (old_size .EQ. 0) THEN
  IF (PRESENT (added_size)) added_size = SUM (added_sizes)
   ENDIF
ELSE
   new_row_i(1:old_size) = old_row_i(1:old_size)
   new_col_i(1:old_size) = old_col_i(1:old_size)
   new_blk_p(1:old_size) = old_blk_p(1:old_size)
   IF (multidata) new_blk_d(1:old_size) = old_blk_d(1:old_size)
ENDIF
  END SUBROUTINE merge_index_arrays
END MODULE dbcsr_index_operations


s> gfortran -c -floop-nest-optimize -O2 bug.f90 
bug.f90:5:0:

   SUBROUTINE merge_index_arrays (new_row_i, new_col_i, new_blk_p, new_size,&


internal compiler error: in harmful_stmt_in_region, at
graphite-scop-detection.c:1052
0x128b761 harmful_stmt_in_region
../../gcc/gcc/graphite-scop-detection.c:1052
0x128b761 merge_sese
../../gcc/gcc/graphite-scop-detection.c:857
0x128bd5c build_scop_breadth
../../gcc/gcc/graphite-scop-detection.c:910
0x128bd5c build_scop_depth
../../gcc/gcc/graphite-scop-detection.c:888
0x128bd21 build_scop_breadth
../../gcc/gcc/graphite-scop-detection.c:902
0x128bd21 build_scop_depth
../../gcc/gcc/graphite-scop-detection.c:888
0x128bb1f build_scop_depth
../../gcc/gcc/graphite-scop-detection.c:886
0x128ba75 build_scop_depth
../../gcc/gcc/graphite-scop-detection.c:874
0x128e3da build_scops(vec*)
../../gcc/gcc/graphite-scop-detection.c:1922
0x127cd31 graphite_transform_loops()
../../gcc/gcc/graphite.c:314
0x127d370 graphite_transforms
../../gcc/gcc/graphite.c:363
0x127d370 execute
../../gcc/gcc/graphite.c:440
Please submit a full bug report,


> gfortran  -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/data/vjoost/gnu/gcc_trunk/install/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/data/vjoost/gnu/gcc_trunk/install
--enable-languages=c,c++,fortran --disable-multilib --enable-plugins
--enable-lto --disable-bootstrap
Thread model: posix
gcc version 6.0.0 20151204 (experimental) [trunk revision 231243] (GCC)

[Bug tree-optimization/68693] [6 Regression] ice: in harmful_stmt_in_region, at graphite-scop-detection.c:1052

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

   Last reconfirmed||2015-12-4
 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch, spop at gcc dot gnu.org
   Target Milestone|--- |6.0
  Known to fail||6.0

--- Comment #1 from Joost VandeVondele  
---
another graphite ice

[Bug c++/68689] flexible array members in unions accepted in C++

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00511.html

[Bug tree-optimization/68692] [6 Regression] ice: Segmentation fault

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

   Last reconfirmed||2015-12-4
 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch, spop at gcc dot gnu.org
   Target Milestone|--- |6.0
Summary|[graphite] ice: |[6 Regression] ice:
   |Segmentation fault  |Segmentation fault
  Known to fail||6.0

--- Comment #1 from Joost VandeVondele  
---
trying to get the nightly tester to run, another graphite ice

[Bug tree-optimization/63586] x+x+x+x -> 4*x in gimple

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
(In reply to kugan from comment #2)
> ;; Function f4 (f4, funcdef_no=3, decl_uid=4162, cgraph_uid=3,
> symbol_order=3)
> 
> ;; 1 loops found
> ;;
> ;; Loop 0
> ;;  header 0, latch 1
> ;;  depth 0, outer -1
> ;;  nodes: 0 1 2
> ;; 2 succs { 1 }
> f4 (unsigned int x, unsigned int z, unsigned int k)
> {
>   unsigned int y;
>   unsigned int reassocmul_12;
>   unsigned int reassocmul_13;
>   unsigned int _14;
>   unsigned int _15;
> 
>   :
>   reassocmul_12 = x_2(D) * 3;
>   reassocmul_13 = z_6(D) * 3;
>   _14 = x_2(D) + reassocmul_13;
>   _15 = _14 + reassocmul_12;
>   y_10 = _15 + k_1(D);
>   return y_10;
> 
> }

So the patch fails in this case? It misses the 4th x.


(In reply to kugan from comment #3)
> I think the intention is to have multiplication by power-of-2?

At gimple level, multiplication by any constant would be a good
canonicalization (it can be expanded back to sums later if that's what the
target prefers).

[Bug libstdc++/61582] C++11 regex memory corruption

[timshen at gcc dot gnu.org]

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

Tim Shen  changed:

   What|Removed |Added

 CC||kerukuro at gmail dot com

--- Comment #17 from Tim Shen  ---
*** Bug 68688 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/68550] [6 Regression] ICE: verify_gimple failed Error: missing PHI def

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #7 from Joost VandeVondele  
---
(In reply to Sebastian Pop from comment #5)
> fixed

BTW, with this fixed, I can compile our CP2K code with -floop-nest-optimize at
various -Ox and all seems correct. Thanks!

I'll try to integrate '-floop-nest-optimize' in our nightly testers.

[Bug middle-end/68291] [6 regression] ICE in emit_move_insn, at expr.c:3540

[aoliva at gcc dot gnu.org]

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

--- Comment #7 from Alexandre Oliva  ---
Eric, apologies for the slow response, I'm in the middle of an all-week trip
with little Internet access.

I think the best course of action is to adjust gimple_can_coalesce_p so that it
returns false for RESULT_DECLs for which promote_ssa_mode returns BLKmode, and
then adjust the block you quoted to assign a group rtx to the result decl, like
the original code (still present a few lines below) used to do when
hard_function_value returned a non-REG.  I don't think we can allow coalescing
in this case, because IIRC expanders can't deal with these parallels in
general.

I can look into this next week, when I'll be back home, if you prefer.  Just
let me know.

[Bug c/57180] Structures with a flexible arrray member have wrong size

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||msebor at gcc dot gnu.org
  Known to work||4.9.3, 5.1.0, 6.0
 Resolution|--- |FIXED

--- Comment #5 from Martin Sebor  ---
The test case passes with GCC 4.9.3 and is rejected with GCC 5.1.0 and 6.0 so
it looks like it's resolved as Marek says.  Closing as FIXED.

[Bug sanitizer/68650] Firefox compilation fails with Address Sanitizer (error: undefined reference to 'dlerror')

[gk at torproject dot org]

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

--- Comment #4 from Georg Koppen  ---
It is using -lasan it seems:

Executing: c++ -o firefox -Wall -Wempty-body -Woverloaded-virtual
-Wsign-compare -Wwrite-strings -Wno-invalid-offsetof -Wcast-align -v
-fsanitize=address -Dxmalloc=myxmalloc -fno-exceptions -fno-strict-aliasing
-fno-rtti -fno-exceptions -fno-math-errno -std=gnu++0x -pthread -pipe -DNDEBUG
-DTRIMMED -g -freorder-blocks -Os -fno-omit-frame-pointer
/home/thomas/Arbeit/Tor/mozilla-central/obj-x86_64-unknown-linux-gnu/browser/app/tmpjOe32q.list
-lpthread -fsanitize=address -Wl,-z,noexecstack -Wl,-z,text -Wl,--build-id -B
../../build/unix/gold -Wl,-Bsymbolic -rdynamic
-Wl,-rpath-link,/home/thomas/Arbeit/Tor/mozilla-central/obj-x86_64-unknown-linux-gnu/dist/bin
-Wl,-rpath-link,NONE/lib ../../xpcom/glue/standalone/libxpcomglue.a
/home/thomas/Arbeit/Tor/mozilla-central/obj-x86_64-unknown-linux-gnu/browser/app/tmpjOe32q.list:
INPUT("nsBrowserApp.o")
INPUT("../../mozglue/build/AsanOptions.o")
INPUT("../../mozglue/build/SSE.o")
INPUT("../../mozglue/build/dummy.o")
INPUT("../../memory/mozalloc/Unified_cpp_memory_mozalloc0.o")
INPUT("../../mozglue/misc/StackWalk.o")
INPUT("../../mozglue/misc/TimeStamp.o")
INPUT("../../mozglue/misc/TimeStamp_posix.o")
INPUT("../../mfbt/Compression.o")
INPUT("../../mfbt/Decimal.o")
INPUT("../../mfbt/Unified_cpp_mfbt0.o")
INPUT("../../memory/fallible/fallible.o")

Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 5.2.1-23'
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 5.2.1 20151028 (Debian 5.2.1-23) 
COMPILER_PATH=../../build/unix/gold/:/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=../../build/unix/gold/:/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/5/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-o' 'firefox' '-Wall' '-Wempty-body'
'-Woverloaded-virtual' '-Wsign-compare' '-Wwrite-strings'
'-Wno-invalid-offsetof' '-Wcast-align' '-v' '-fsanitize=address' '-D'
'xmalloc=myxmalloc' '-fno-strict-aliasing' '-fno-rtti' '-fno-exceptions'
'-fno-math-errno' '-std=gnu++11' '-pthread' '-pipe' '-D' 'NDEBUG' '-D'
'TRIMMED' '-g' '-freorder-blocks' '-Os' '-fno-omit-frame-pointer'
'-fsanitize=address' '-B' '../../build/unix/gold' '-rdynamic' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/5/collect2 -plugin
/usr/lib/gcc/x86_64-linux-gnu/5/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccNcaQre.res -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lpthread
-plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc --sysroot=/ --build-id --eh-frame-hdr -m
elf_x86_64 --hash-style=gnu -export-dynamic -dynamic-linker
/lib64/ld-linux-x86-64.so.2 -o firefox
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crt1.o
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/5/crtbegin.o -L../../build/unix/gold
-L/usr/lib/gcc/x86_64-linux-gnu/5
-L/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu
-L/usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib -L/lib/x86_64-linux-gnu
-L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib
-L/usr/lib/gcc/x86_64-linux-gnu/5/../../..
/usr/lib/gcc/x86_64-linux-gnu/5/libasan_preinit.o -lasan

[Bug c/68513] [5/6 Regression] ICE in gimplify_expr, at gimplify.c:8832, c_maybe_const_expr in IL

[mpolacek at gcc dot gnu.org]

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

--- Comment #12 from Marek Polacek  ---
No, this isn't something we'd want to backport I think,  For GCC 5, we'll need
another (but trivial) fix.

[Bug sanitizer/68650] Firefox compilation fails with Address Sanitizer (error: undefined reference to 'dlerror')

[gk at torproject dot org]

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

Georg Koppen  changed:

   What|Removed |Added

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

--- Comment #7 from Georg Koppen  ---
Resolving this as invalid then.

[Bug ipa/68672] [4.9/5/6 Regression] g++.dg/torture/pr68470.C: ICE: cannot update SSA form: statement uses released SSA name

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-03
 CC||hubicka at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
  Component|middle-end  |ipa
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  Looks similar to PR68470, IPA split messes up.

[Bug fortran/68676] New: ICE in gfc_match_formal_arglist when compiling gfortran.dg/submodule_10.f08

[ubizjak at gmail dot com]

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

Bug ID: 68676
   Summary: ICE in gfc_match_formal_arglist when compiling
gfortran.dg/submodule_10.f08
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---
Target: alphaev68-linux-gnu

Recent regression on alphaev68-linux-gnu, fails several submodule_??.f08 tests
[1]. The ICE can be triggered with a crosscompiler to alpha-linux-gnu:

~/gcc-build-alpha/gcc/f951 -O submodule_10.f08

f951: internal compiler error: Segmentation fault
0xb19d7f crash_signal
../../gcc-svn/trunk/gcc/toplev.c:334
0x5498e5 gfc_match_formal_arglist(gfc_symbol*, int, int)
../../gcc-svn/trunk/gcc/fortran/decl.c:4829
0x54c88b gfc_match_subroutine()
../../gcc-svn/trunk/gcc/fortran/decl.c:6016
0x5a52f5 decode_statement
../../gcc-svn/trunk/gcc/fortran/parse.c:378

gdb session:

Starting program: /home/uros/gcc-build-alpha/gcc/f951 -O submodule_10.f08

Program received signal SIGSEGV, Segmentation fault.
0x005498e5 in gfc_match_formal_arglist (progname=0x175b330, st_flag=0,
null_flag=1) at ../../gcc-svn/trunk/gcc/fortran/decl.c:4829
4829  if (!sym->abr_modproc_decl && formal && !head)
(gdb) p sym
$1 = (gfc_symbol *) 0x0
(gdb) list
4824  if (!formal && head)
4825arg_count_mismatch = true;
4826
4827  /* Abbreviated module procedure declaration is not meant to have
any
4828 formal arguments!  */
4829  if (!sym->abr_modproc_decl && formal && !head)
4830arg_count_mismatch = true;
4831
4832  for (p = formal, q = head; p && q; p = p->next, q = q->next)
4833{
(gdb) bt
#0  0x005498e5 in gfc_match_formal_arglist (progname=0x175b330,
st_flag=0, null_flag=1) at ../../gcc-svn/trunk/gcc/fortran/decl.c:4829
#1  0x0054c88c in gfc_match_subroutine () at
../../gcc-svn/trunk/gcc/fortran/decl.c:6016
#2  0x005a52f6 in decode_statement () at
../../gcc-svn/trunk/gcc/fortran/parse.c:378
#3  0x005a6a58 in next_free () at
../../gcc-svn/trunk/gcc/fortran/parse.c:1076
#4  0x005a6de9 in next_statement () at
../../gcc-svn/trunk/gcc/fortran/parse.c:1310
#5  0x005a95af in parse_contained (module=1) at
../../gcc-svn/trunk/gcc/fortran/parse.c:5038
#6  0x005a99ad in parse_module () at
../../gcc-svn/trunk/gcc/fortran/parse.c:5431

sym is dereferenced when NULL.

[1] https://gcc.gnu.org/ml/gcc-testresults/2015-12/msg00267.html

[Bug lto/68556] [6 Regression] -r -flto test failures

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #3 from H.J. Lu  ---
Fixed as of r231223.

[Bug testsuite/68545] gcc.dg/guality/guality.exp hides compiler error

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

[Bug tree-optimization/68671] New: [5/6 Regression] gcc.dg/torture/pr66952.c FAILs with -fno-tree-dce

[zsojka at seznam dot cz]

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

Bug ID: 68671
   Summary: [5/6 Regression] gcc.dg/torture/pr66952.c FAILs with
-fno-tree-dce
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---

Created attachment 36895
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36895=edit
reduced testcase withouth UB

For armv7a, aarch64, powerpc, powerpc64 targets (tested in QEMU) (x86_64 is
OK), the testcase fails:
$ $CC -O2 -fno-tree-dce
$ ./a.out
Aborted

$ armv7a-hardfloat-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-armv7a-hardfloat/bin/armv7a-hardfloat-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-231194-checking-yes-rtl-df-nographite-armv7a-hardfloat/bin/../libexec/gcc/armv7a-hardfloat-linux-gnueabi/6.0.0/lto-wrapper
Target: armv7a-hardfloat-linux-gnueabi
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-checking=yes,rtl,df --without-cloog --without-ppl --without-isl
--with-float=hard --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=armv7a-hardfloat-linux-gnueabi
--with-ld=/usr/bin/armv7a-hardfloat-linux-gnueabi-ld
--with-as=/usr/bin/armv7a-hardfloat-linux-gnueabi-as
--with-sysroot=/usr/armv7a-hardfloat-linux-gnueabi --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-231194-checking-yes-rtl-df-nographite-armv7a-hardfloat
Thread model: posix
gcc version 6.0.0 20151202 (experimental) (GCC)

[Bug tree-optimization/68673] New: Handle __builtin_GOMP_task optimally in ipa-pta

[vries at gcc dot gnu.org]

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

Bug ID: 68673
   Summary: Handle __builtin_GOMP_task optimally in ipa-pta
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

https://gcc.gnu.org/ml/gcc-patches/2015-11/msg03477.html :
...
__builtin_GOMP_task supposedly can be treated similarly
if the third argument is NULL (if 3rd arg is non-NULL, then
the caller passes a different structure from what the callee receives,
but perhaps it could be emulated as pretending that cpyfn is called first
with address of a temporary var and the data argument and then fn
is called with the address of the temporary var).
...

[Bug target/68674] ARM attribute target neon warning: incompatible implicit declaration of built-in function

[chrbr at gcc dot gnu.org]

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

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 Blocks||65837
   Assignee|unassigned at gcc dot gnu.org  |chrbr at gcc dot gnu.org

--- Comment #1 from chrbr at gcc dot gnu.org ---
Found this when fixing target/65837:

builtins should have a global scope. but this unmask a few other failures,
mostly with the hooks TARGET_VECTORIZE_PREFERRED_SIMD_MODE that return wrongs
values for global variables.

The problem is that TARGET_NEON is false for global scopes decls, although the
types were known.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
[Bug 65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[Bug target/68655] SSE2 cannot vec_perm of low and high part

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  ---
On Thu, 3 Dec 2015, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68655
> 
> --- Comment #5 from Jakub Jelinek  ---
> Created attachment 36897
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36897=edit
> gcc6-pr68655.patch
> 
> Initial untested patch.  Unfortunately, it doesn't seem to be always a win,
> when looking at the differences between old and new compiler.
> I'm looking at
> cd /usr/src/gcc/gcc/testsuite/gcc.dg/torture; for i in vshuf-v*[hqs]i.c; do 
> for
> j in -msse2 -msse4 -mavx -mavx2 -mavx512f -mavx512bw; do
> /usr/src/gcc/obj/gcc/cc1.v246 -quiet -O2 $j $i -DEXPENSIVE -o /tmp/1.s;
> /usr/src/gcc/obj/gcc/cc1 -quiet -O2 $j $i -DEXPENSIVE -o /tmp/2.s; echo ===$i
> $j===; diff -up /tmp/1.s /tmp/2.s; done; done
> output now (where cc1.v246 is vanilla cc1, cc1 is one with this patch 
> applied).
> In some cases the patch helps, but I've seen so far some cases where for
> AVX512* it resulted in more instructions.

So maybe that's a too generic handling (doing it up-front?) and maybe
it should be done in the shufp[ds] handler only to catch my case?

Otherwise the x86 ISA makes this quite awkward without building some
pattern recognition scheme with a generator.

[Bug target/68655] SSE2 cannot vec_perm of low and high part

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
I guess it needs analysis.
Some examples of changes:
vshuf-v16qi.c -msse2 test_2, scalar code vs. punpcklqdq, clear win
vshuf-v16qi.c -msse4 test_2, pshufb -> punpcklqdq (is this a win or not?)
(similarly for -mavx, -mavx2, -mavx512f, -mavx512bw)
vshuf-v16si.c -mavx512{f,bw} test_2:
-   vpermi2d%zmm1, %zmm1, %zmm0
+   vmovdqa64   .LC2(%rip), %zmm0
+   vpermi2q%zmm1, %zmm1, %zmm0
looks like pessimization.
vshuf-v32hi.c -mavx512bw test_2, similar pessimization.
vshuf-v32hi.c -mavx512bw test_2, similarly:
-   vpermi2w%zmm1, %zmm1, %zmm0
+   vmovdqa64   .LC2(%rip), %zmm0
+   vpermi2q%zmm1, %zmm1, %zmm0
vshuf-v4si.c -msse2 test_183, another pessimization:
-   pshufd  $78, %xmm0, %xmm1
+   movdqa  %xmm0, %xmm1
movdb(%rip), %xmm4
pshufd  $255, %xmm0, %xmm2
+   shufpd  $1, %xmm0, %xmm1
vshuf-v4si.c -msse4 test_183, another pessimization:
-   pshufd  $78, %xmm1, %xmm0
+   movdqa  %xmm1, %xmm0
+   palignr $8, %xmm0, %xmm0
vshuf-v4si.c -mavx test_183:
-   vpshufd $78, %xmm1, %xmm0
+   vpalignr$8, %xmm1, %xmm1, %xmm0
vshuf-v64qi.c -mavx512bw, desirable change:
-   vpermi2w%zmm1, %zmm1, %zmm0
-   vpshufb .LC3(%rip), %zmm0, %zmm1
-   vpshufb .LC4(%rip), %zmm0, %zmm0
-   vporq   %zmm0, %zmm1, %zmm0
+   vpermi2q%zmm1, %zmm1, %zmm0
vshuf-v8hi.c -msse2 test_1 another scalar to punpcklqdq, win
vshuf-v8hi.c -msse4 test_2 (supposedly a win):
-   pshufb  .LC3(%rip), %xmm0
+   punpcklqdq  %xmm0, %xmm0
vshuf-v8hi.c -mavx test_2, similarly:
-   vpshufb .LC3(%rip), %xmm0, %xmm0
+   vpunpcklqdq %xmm0, %xmm0, %xmm0
vshuf-v8si.c -mavx2 test_2, another win:
-   vmovdqa a(%rip), %ymm0
-   vperm2i128  $0, %ymm0, %ymm0, %ymm0
+   vpermq  $68, a(%rip), %ymm0
vshuf-v8si.c -mavx2 test_5, another win:
-   vmovdqa .LC6(%rip), %ymm0
-   vmovdqa .LC7(%rip), %ymm1
-   vmovdqa %ymm0, -48(%rbp)
vmovdqa a(%rip), %ymm0
-   vpermd  %ymm0, %ymm1, %ymm1
-   vpshufb .LC8(%rip), %ymm0, %ymm3
-   vpshufb .LC10(%rip), %ymm0, %ymm0
-   vmovdqa %ymm1, c(%rip)
-   vmovdqa b(%rip), %ymm1
-   vpermq  $78, %ymm3, %ymm3
-   vpshufb .LC9(%rip), %ymm1, %ymm2
-   vpshufb .LC11(%rip), %ymm1, %ymm1
-   vpor%ymm3, %ymm0, %ymm0
-   vpermq  $78, %ymm2, %ymm2
-   vpor%ymm2, %ymm1, %ymm1
-   vpor%ymm1, %ymm0, %ymm0
+   vmovdqa .LC7(%rip), %ymm2
+   vmovdqa .LC6(%rip), %ymm1
+   vpermd  %ymm0, %ymm2, %ymm2
+   vpermd  b(%rip), %ymm1, %ymm3
+   vmovdqa %ymm1, -48(%rbp)
+   vmovdqa %ymm2, c(%rip)
+   vpermd  %ymm0, %ymm1, %ymm0
+   vmovdqa .LC8(%rip), %ymm2
+   vpand   %ymm2, %ymm1, %ymm1
+   vpcmpeqd%ymm2, %ymm1, %ymm1
+   vpblendvb   %ymm1, %ymm3, %ymm0, %ymm0
vshuf-v8si.c -mavx512f test_2, another win?
-   vmovdqa a(%rip), %ymm0
-   vperm2i128  $0, %ymm0, %ymm0, %ymm0
+   vpermq  $68, a(%rip), %ymm0

The above does not list all changes, I've been often ignoring further changes
in the file if say one change adds or removes a .LC*, then everything else is
renumbered (and doesn't sometimes list cases where the same or similar change
appears with multiple ISAs). So the results are clearly mixed.

Perhaps I should just try doing this at the end of expand_vec_perm_1 (i.e. if
we (most likely) couldn't get a single insn normally, see if we would get it
otherwise), and at the end of ix86_expand_vec_perm_const_1 (as the fallback
after all sequences).  It won't catch some beneficial one insn to one insn
changes (e.g. where in the original case the insn needs a constant operand in
memory) though.

[Bug rtl-optimization/68670] [4.9/5/6 Regression] gcc.c-torture/execute/pr68376-2.c FAILs with -ftracer

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.4

[Bug rtl-optimization/68670] New: [4.9/5/6 Regression] gcc.c-torture/execute/pr68376-2.c FAILs with -ftracer

[zsojka at seznam dot cz]

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

Bug ID: 68670
   Summary: [4.9/5/6 Regression] gcc.c-torture/execute/pr68376-2.c
FAILs with -ftracer
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---

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

As mentioned in PR68376#c8, the testcase is failing with -ftracer.

On the 5-branch, -O2 -ftracer is needed; -O -tracer is enough on other
branches.

armv7, aarch64, powerpc, x86_64 is affected; powerpc64 doesn't seem to fail.

Dumps up to .optimized look fine, it still seems to be an RTL optimizer bug.

Output:
$ $CC -O2 -ftracer testcase.c
$ ./a.out
Aborted


$ gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-231194-checking-yes-rtl-df-nographite/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-checking=yes,rtl,df --without-cloog --without-ppl --without-isl
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-231194-checking-yes-rtl-df-nographite
Thread model: posix
gcc version 6.0.0 20151202 (experimental) (GCC)

[Bug middle-end/68672] New: [4.9/5/6 Regression] g++.dg/torture/pr68470.C: ICE: cannot update SSA form: statement uses released SSA name

[zsojka at seznam dot cz]

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

Bug ID: 68672
   Summary: [4.9/5/6 Regression] g++.dg/torture/pr68470.C: ICE:
cannot update SSA form: statement uses released SSA
name
   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 36896
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36896=edit
preprocessed g++.dg/torture/pr68470.C

Compiler output:
$ x86_64-pc-linux-gnu-gcc -v -O -finline-small-functions -fpartial-inlining
--param=partial-inlining-entry-probability=100 pr68470.ii
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-231194-checking-yes-rtl-df-nographite/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-checking=yes,rtl,df --without-cloog --without-ppl --without-isl
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-231194-checking-yes-rtl-df-nographite
Thread model: posix
gcc version 6.0.0 20151202 (experimental) (GCC) 
/repo/gcc-trunk/gcc/testsuite/g++.dg/torture/pr68470.C: In member function
'virtual void I::m_fn3()':
/repo/gcc-trunk/gcc/testsuite/g++.dg/torture/pr68470.C:35:1: error: statement
uses released SSA name:
 }
 ^

# .MEM_20 = VDEF <.MEM>
MEM[(struct  &)_12] ={v} {CLOBBER};
The use of _12 should have been replaced
/repo/gcc-trunk/gcc/testsuite/g++.dg/torture/pr68470.C:35:1: internal compiler
error: cannot update SSA form
0xdfa08c update_ssa(unsigned int)
/repo/gcc-trunk/gcc/tree-into-ssa.c:3190
0xc5f257 execute_function_todo
/repo/gcc-trunk/gcc/passes.c:1926
0xc5fc9b execute_todo
/repo/gcc-trunk/gcc/passes.c:2010
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Tested revisions:
trunk r231194 - ICE
5-branch r231055 - ICE
4_9-branch 231054 - ICE
4_8-branch r224828 - OK

[Bug target/68674] New: ARM attribute target neon warning: incompatible implicit declaration of built-in function

[chrbr at gcc dot gnu.org]

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

Bug ID: 68674
   Summary: ARM attribute target neon warning: incompatible
implicit declaration of built-in function
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chrbr at gcc dot gnu.org
  Target Milestone: ---

this test compiled with

cc1   -O2 test.c  -mcpu=cortex-a9 -mfloat-abi=hard -quiet -mfpu=neon

#include "arm_neon.h"

int8x8_t a, b;
int16x8_t e;

void
__attribute__ ((target("fpu=neon")))
foo(void)
{
  e = (int16x8_t)__builtin_neon_vaddlsv8qi (a, b);
}

ICEs with 

test.c:10:18: warning: incompatible implicit declaration of built-in function
'__builtin_neon_vaddlsv8qi'
   e = (int16x8_t)__builtin_neon_vaddlsv8qi (a, b);
  ^

test.c:10:7: internal compiler error: in copy_to_mode_reg, at explow.c:595
   e = (int16x8_t)__builtin_neon_vaddlsv8qi (a, b);
   ^~~

[Bug sanitizer/68650] Firefox compilation fails with Address Sanitizer (error: undefined reference to 'dlerror')

[gk at torproject dot org]

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

--- Comment #6 from Georg Koppen  ---
Alright, thanks. So, what happens with r215527 is that checking for dlopen()
working properly in the configure script is not enough anymore to decide
whether one needs -ldl needs to get added explicitly if address sanitizer is
enabled. If it is not enabled the dlopen() check is still sufficient.

If one uses dlsym() for instance instead the check for needing -ldl is working
as before.

I still don't understand exactly why this is needed but I guess this is a thing
which needs to get fixed on the Mozilla side. Sorry for the noise.

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[rguenth at gcc dot gnu.org]

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

Bug 66051 Summary: can't vectorize reductions inside an SLP group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66051

   What|Removed |Added

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

[Bug tree-optimization/66051] can't vectorize reductions inside an SLP group

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Thu Dec  3 11:26:56 2015
New Revision: 231225

URL: https://gcc.gnu.org/viewcvs?rev=231225=gcc=rev
Log:
2015-12-03  Richard Biener  

PR tree-optimization/66051
* tree-vect-slp.c (vect_build_slp_tree_1): Remove restriction
on load group size.  Do not pass in vectorization_factor.
(vect_transform_slp_perm_load): Do not require any permute support.
(vect_build_slp_tree): Do not pass in vectorization factor.
(vect_analyze_slp_instance): Do not compute vectorization
factor estimate.  Use vector size instead of vectorization factor
estimate to split store groups for BB vectorization.

* gcc.dg/vect/slp-42.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/vect/slp-42.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-slp.c

[Bug tree-optimization/66051] can't vectorize reductions inside an SLP group

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/68655] SSE2 cannot vec_perm of low and high part

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 36897
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36897=edit
gcc6-pr68655.patch

Initial untested patch.  Unfortunately, it doesn't seem to be always a win,
when looking at the differences between old and new compiler.
I'm looking at
cd /usr/src/gcc/gcc/testsuite/gcc.dg/torture; for i in vshuf-v*[hqs]i.c; do for
j in -msse2 -msse4 -mavx -mavx2 -mavx512f -mavx512bw; do
/usr/src/gcc/obj/gcc/cc1.v246 -quiet -O2 $j $i -DEXPENSIVE -o /tmp/1.s;
/usr/src/gcc/obj/gcc/cc1 -quiet -O2 $j $i -DEXPENSIVE -o /tmp/2.s; echo ===$i
$j===; diff -up /tmp/1.s /tmp/2.s; done; done
output now (where cc1.v246 is vanilla cc1, cc1 is one with this patch applied).
In some cases the patch helps, but I've seen so far some cases where for
AVX512* it resulted in more instructions.

[Bug tree-optimization/68675] New: Handle GOMP_target_ext optimally in ipa-pta

[vries at gcc dot gnu.org]

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

Bug ID: 68675
   Summary: Handle GOMP_target_ext optimally in ipa-pta
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01336.html :
...
What we can and should improve is teach IPA aliasing/points to analysis
about the way we lower the host vs. offloading region boundary, so that
if alias analysis on the caller of GOMP_target_ext/GOACC_parallel_keyed
determines something it can be used on the offloaded function side and vice
versa.
...

GOACC_parallel_keyed has been implemented, todo: GOMP_target_ext

[Bug c++/68669] [5 regression] -Wunused-variable is not correctly supressed by #pragmas

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|WAITING |NEW
Version|5.1.0   |5.2.1
Summary|-Wunused-variable is not|[5 regression]
   |correctly supressed by  |-Wunused-variable is not
   |#pragmas|correctly supressed by
   ||#pragmas

--- Comment #3 from Markus Trippelsdorf  ---
markus@x4 tmp % cat run_tests.ii
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-variable"
class A {
public:
  static A _fn1();
};
namespace {
A  = A::m_fn1();
}
#pragma GCC diagnostic pop

markus@x4 tmp % g++ -Wall -std=c++14 -O2 -c run_tests.ii
run_tests.ii:8:4: warning: ‘{anonymous}::a’ defined but not used
[-Wunused-variable]
 A  = A::m_fn1();
^

gcc-6 doesn't warn at all (even without the "diagnostic ignored" pragma).

[Bug middle-end/68672] [4.9/5/6 Regression] g++.dg/torture/pr68470.C: ICE: cannot update SSA form: statement uses released SSA name

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.4

[Bug tree-optimization/68671] [5/6 Regression] gcc.dg/torture/pr66952.c FAILs with -fno-tree-dce

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.4

[Bug rtl-optimization/68670] [4.9/5/6 Regression] gcc.c-torture/execute/pr68376-2.c FAILs with -ftracer

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/68655] SSE2 cannot vec_perm of low and high part

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  ---
On Thu, 3 Dec 2015, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68655
> 
> --- Comment #7 from Jakub Jelinek  ---
> I guess it needs analysis.
> Some examples of changes:
> vshuf-v16qi.c -msse2 test_2, scalar code vs. punpcklqdq, clear win
> vshuf-v16qi.c -msse4 test_2, pshufb -> punpcklqdq (is this a win or not?)
> (similarly for -mavx, -mavx2, -mavx512f, -mavx512bw)
> vshuf-v16si.c -mavx512{f,bw} test_2:
> -   vpermi2d%zmm1, %zmm1, %zmm0
> +   vmovdqa64   .LC2(%rip), %zmm0
> +   vpermi2q%zmm1, %zmm1, %zmm0
> looks like pessimization.
> vshuf-v32hi.c -mavx512bw test_2, similar pessimization.
> vshuf-v32hi.c -mavx512bw test_2, similarly:
> -   vpermi2w%zmm1, %zmm1, %zmm0
> +   vmovdqa64   .LC2(%rip), %zmm0
> +   vpermi2q%zmm1, %zmm1, %zmm0
> vshuf-v4si.c -msse2 test_183, another pessimization:
> -   pshufd  $78, %xmm0, %xmm1
> +   movdqa  %xmm0, %xmm1
> movdb(%rip), %xmm4
> pshufd  $255, %xmm0, %xmm2
> +   shufpd  $1, %xmm0, %xmm1
> vshuf-v4si.c -msse4 test_183, another pessimization:
> -   pshufd  $78, %xmm1, %xmm0
> +   movdqa  %xmm1, %xmm0
> +   palignr $8, %xmm0, %xmm0
> vshuf-v4si.c -mavx test_183:
> -   vpshufd $78, %xmm1, %xmm0
> +   vpalignr$8, %xmm1, %xmm1, %xmm0
> vshuf-v64qi.c -mavx512bw, desirable change:
> -   vpermi2w%zmm1, %zmm1, %zmm0
> -   vpshufb .LC3(%rip), %zmm0, %zmm1
> -   vpshufb .LC4(%rip), %zmm0, %zmm0
> -   vporq   %zmm0, %zmm1, %zmm0
> +   vpermi2q%zmm1, %zmm1, %zmm0
> vshuf-v8hi.c -msse2 test_1 another scalar to punpcklqdq, win
> vshuf-v8hi.c -msse4 test_2 (supposedly a win):
> -   pshufb  .LC3(%rip), %xmm0
> +   punpcklqdq  %xmm0, %xmm0
> vshuf-v8hi.c -mavx test_2, similarly:
> -   vpshufb .LC3(%rip), %xmm0, %xmm0
> +   vpunpcklqdq %xmm0, %xmm0, %xmm0
> vshuf-v8si.c -mavx2 test_2, another win:
> -   vmovdqa a(%rip), %ymm0
> -   vperm2i128  $0, %ymm0, %ymm0, %ymm0
> +   vpermq  $68, a(%rip), %ymm0
> vshuf-v8si.c -mavx2 test_5, another win:
> -   vmovdqa .LC6(%rip), %ymm0
> -   vmovdqa .LC7(%rip), %ymm1
> -   vmovdqa %ymm0, -48(%rbp)
> vmovdqa a(%rip), %ymm0
> -   vpermd  %ymm0, %ymm1, %ymm1
> -   vpshufb .LC8(%rip), %ymm0, %ymm3
> -   vpshufb .LC10(%rip), %ymm0, %ymm0
> -   vmovdqa %ymm1, c(%rip)
> -   vmovdqa b(%rip), %ymm1
> -   vpermq  $78, %ymm3, %ymm3
> -   vpshufb .LC9(%rip), %ymm1, %ymm2
> -   vpshufb .LC11(%rip), %ymm1, %ymm1
> -   vpor%ymm3, %ymm0, %ymm0
> -   vpermq  $78, %ymm2, %ymm2
> -   vpor%ymm2, %ymm1, %ymm1
> -   vpor%ymm1, %ymm0, %ymm0
> +   vmovdqa .LC7(%rip), %ymm2
> +   vmovdqa .LC6(%rip), %ymm1
> +   vpermd  %ymm0, %ymm2, %ymm2
> +   vpermd  b(%rip), %ymm1, %ymm3
> +   vmovdqa %ymm1, -48(%rbp)
> +   vmovdqa %ymm2, c(%rip)
> +   vpermd  %ymm0, %ymm1, %ymm0
> +   vmovdqa .LC8(%rip), %ymm2
> +   vpand   %ymm2, %ymm1, %ymm1
> +   vpcmpeqd%ymm2, %ymm1, %ymm1
> +   vpblendvb   %ymm1, %ymm3, %ymm0, %ymm0
> vshuf-v8si.c -mavx512f test_2, another win?
> -   vmovdqa a(%rip), %ymm0
> -   vperm2i128  $0, %ymm0, %ymm0, %ymm0
> +   vpermq  $68, a(%rip), %ymm0
> 
> The above does not list all changes, I've been often ignoring further changes
> in the file if say one change adds or removes a .LC*, then everything else is
> renumbered (and doesn't sometimes list cases where the same or similar change
> appears with multiple ISAs). So the results are clearly mixed.
> 
> Perhaps I should just try doing this at the end of expand_vec_perm_1 (i.e. if
> we (most likely) couldn't get a single insn normally, see if we would get it
> otherwise), and at the end of ix86_expand_vec_perm_const_1 (as the fallback
> after all sequences).

Yeah, I would have done it only if we fail to permute, not generally.
I think you need to stop at 16 byte boundaries (TImode) only for AVX256
and 32byte (OImode) for AVX512.  Not sure if there are cases where
a "effective" DImode permute works with SImode but not DImode,
say { 4, 5, 6, 7, 0, 1, 2, 3 } HImode can be done with both an
SImode { 2, 3, 0, 1 } or a DImode { 1, 0 } permute.

> It won't catch some beneficial one insn to one insn
> changes (e.g. where in the original case the insn needs a constant operand in
> memory) though.

True.  I fear that at some point we want a generator covering all
possible permutes using permute patterns (input would be the .md
file and a list of insns to consider - or maybe even autodetect those).

The code handling permutation is already quite unwieldly (and it tries
generating RTL ...) :/

[Bug c++/68669] -Wunused-variable is not correctly supressed by #pragmas

[pavel.celba at ricardo dot com]

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

--- Comment #2 from Pavel Celba  ---
Created attachment 36893
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36893=edit
Preprocessed run_tests.cpp

Added the pre-processed run_tests.cpp

[Bug c/68668] New: [6 Regression] bogus error: invalid use of array with unspecified bounds

[trippels at gcc dot gnu.org]

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

Bug ID: 68668
   Summary: [6 Regression] bogus error: invalid use of array with
unspecified bounds
   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: ---

% cat vp8_dx_iface.i
typedef const int vp8_tree[];
int fn1(vp8_tree p1) { return p1[0]; }

 % gcc -c vp8_dx_iface.i
vp8_dx_iface.i: In function ‘fn1’:
vp8_dx_iface.i:2:1: error: invalid use of array with unspecified bounds
 int fn1(vp8_tree p1) { return p1[0]; }
 ^~~

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[rguenth at gcc dot gnu.org]

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

Bug 67800 Summary: [6 Regression] Missed vectorization opportunity on x86 
(DOT_PROD_EXPR in non-reduction)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67800

   What|Removed |Added

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

[Bug tree-optimization/67800] [6 Regression] Missed vectorization opportunity on x86 (DOT_PROD_EXPR in non-reduction)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/68659] [6 regression] FAIL: gcc.dg/graphite/id-pr45230-1.c (internal compiler error)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

--- Comment #3 from Richard Biener  ---
Sounds similar to the fixed PR68550.  But confirmed, I also saw the ICE (with
ISL 0.12 and 0.14).

[Bug preprocessor/57580] Repeated _Pragma message directives in macro causes problems

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Fixed for 6+.

[Bug sanitizer/68650] Firefox compilation fails with Address Sanitizer (error: undefined reference to 'dlerror')

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
/home/thomas/Arbeit/Tor/mozilla-central/xpcom/glue/standalone/nsXPCOMGlue.cpp:167:
 
error: undefined reference to 'dlerror' 

That does look like it is actually one of the firefox' objects that needs
dlerror, not *asan*.  And -fsanitize=address never emits calls to these
functions itself, when they aren't present in the source code already.
So perhaps firefox has some code guarded with the sanitizer preprocessor macros
or something similar?
Look for dlerror in nsXPCOMGlue.cpp ?

[Bug tree-optimization/68639] [6 Regression] ICE: Floating point exception

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/68639] [6 Regression] ICE: Floating point exception

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Thu Dec  3 08:38:10 2015
New Revision: 231220

URL: https://gcc.gnu.org/viewcvs?rev=231220=gcc=rev
Log:
2015-12-03  Richard Biener  

PR tree-optimization/68639
* tree-vect-data-refs.c (dr_group_sort_cmp): Split groups
belonging to different loops.
(vect_analyze_data_ref_accesses): Likewise.

* gfortran.fortran-torture/compile/pr68639.f90: New testcase.

Added:
trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr68639.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-data-refs.c

[Bug testsuite/68232] gcc.dg/ifcvt-4.c fails on some arm configurations

[andre.simoesdiasvieira at arm dot com]

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

Andre Vieira  changed:

   What|Removed |Added

 CC||andre.simoesdiasvieira@arm.
   ||com

--- Comment #3 from Andre Vieira  ---
Fails also on any ARM M-profile arch/cpu combination I've tried (all with
-mthumb):
-march={armv6-m,armv7-m}
or -mcpu=cortex-m{0,0plus,3,4,7}

It does pass for armv7-r and cortex-r4 with and without -mthumb.

This all with target 'arm-none-eabi'.

[Bug target/68620] ICE on gcc.target/arm/attr-neon-fp16.c

[clyon at gcc dot gnu.org]

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

--- Comment #4 from Christophe Lyon  ---
Maybe, that's what I'm trying to figure out.

Given the comment in arm.h before the definition of CANNOT_CHANGE_MODE_CLASS,
maybe we need to define more patterns, for all the sizes where
CANNOT_CHANGE_MODE_CLASS is true on big-endian?

[Bug ipa/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire

[rguenther at suse dot de]

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

--- Comment #13 from rguenther at suse dot de  ---
On Thu, 3 Dec 2015, hubicka at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64812
> 
> Jan Hubicka  changed:
> 
>What|Removed |Added
> 
>  CC||rguenther at suse dot de
> 
> --- Comment #12 from Jan Hubicka  ---
> Markus,
> the devirtualization seems valid to me.  You are supposed to link with the
> implementaiton of the class.  It is possible to overwrite this by manually
> setting the visibility.
> 
> We however end up with funny code in optimized dump:
> 
>   :
>   _3 = this_2(D)->D.2399.D.2325._vptr.B;
>   _4 = *_3;
>   PROF_6 = [obj_type_ref] OBJ_TYPE_REF(_4;(struct
> WindowListenerMultiplexer)this_2(D)->0);
>   if (PROF_6 == acquire)
> goto ;
>   else
> goto ;
> 
>   :
>   PROF_10 = [obj_type_ref] OBJ_TYPE_REF(_4;(struct
> WindowListenerMultiplexer)this_2(D)->0);
>   if (PROF_10 == acquire)
> goto ;
>   else
> goto ;
> 
>   :
>   PROF_14 = [obj_type_ref] OBJ_TYPE_REF(_4;(struct
> WindowListenerMultiplexer)this_2(D)->0);
>   if (PROF_14 == acquire)
> goto ;
>   else
> goto ;
> 
>   :
>   PROF_18 = [obj_type_ref] OBJ_TYPE_REF(_4;(struct
> WindowListenerMultiplexer)this_2(D)->0);
>   if (PROF_18 == acquire)
> goto ;
>   else
> goto ;
> 
>   :
>   PROF_22 = [obj_type_ref] OBJ_TYPE_REF(_4;(struct
> WindowListenerMultiplexer)this_2(D)->0);
>   if (PROF_22 == acquire)
> goto ;
>   else
> goto ;
> 
>   :
>   PROF_26 = [obj_type_ref] OBJ_TYPE_REF(_4;(struct
> WindowListenerMultiplexer)this_2(D)->0);
>   if (PROF_26 == acquire)
> goto ;
>   else
> goto ;
>   :
>   PROF_30 = [obj_type_ref] OBJ_TYPE_REF(_4;(struct
> WindowListenerMultiplexer)this_2(D)->0);
>   if (PROF_30 == acquire)
> goto ;
>   else
> goto ;
> 
>   :
>   PROF_34 = [obj_type_ref] OBJ_TYPE_REF(_4;(struct
> WindowListenerMultiplexer)this_2(D)->0);
>   if (PROF_34 == acquire)
> goto ;
>   else
> goto ;
> 
>   :
>   OBJ_TYPE_REF(_4;(struct WindowListenerMultiplexer)this_2(D)->0) (this_2(D));
> [tail call]
>   goto ;
> 
>   :
>   OBJ_TYPE_REF(_4;(struct WindowListenerMultiplexer)this_2(D)->0) (this_2(D));
> [tail call]
>   goto ;
> 
>   :
>   OBJ_TYPE_REF(_4;(struct WindowListenerMultiplexer)this_2(D)->0) (this_2(D));
> [tail call]
>   goto ;
> 
>   :
>   OBJ_TYPE_REF(_4;(struct WindowListenerMultiplexer)this_2(D)->0) (this_2(D));
> [tail call]
>   goto ;
> 
>   :
>   OBJ_TYPE_REF(_4;(struct WindowListenerMultiplexer)this_2(D)->0) (this_2(D));
> [tail call]
>   goto ;
> 
>   :
>   OBJ_TYPE_REF(_4;(struct WindowListenerMultiplexer)this_2(D)->0) (this_2(D));
> [tail call]
>   goto ;
> 
>   :
>   OBJ_TYPE_REF(_4;(struct WindowListenerMultiplexer)this_2(D)->0) (this_2(D));
> [tail call]
>   goto ;
> 
>   :
>   OBJ_TYPE_REF(_4;(struct WindowListenerMultiplexer)this_2(D)->0) (this_2(D));
> [tail call]
>   goto ;
> 
>   :
>   OBJ_TYPE_REF(_4;(struct WindowListenerMultiplexer)this_2(D)->0) (this_2(D));
> [tail call]
> 
>   :
>   return;
> 
> }
> 
> this is result of recursive inlining over the devirtualized call that sort of
> seem legit even though it is bit of overkill.
> 
> RTL optimizers simplify this to:
> 
> _ZN25WindowListenerMultiplexer7acquireEv:
> .LFB1:
> .cfi_startproc
> movq(%rdi), %rax
> jmp *(%rax)
> .cfi_endproc
> .LFE1:
> 
> RIchi, I think PRE is supposed to optimize this?

Ah, for some reason OBJ_TYPE_REF is a GENERIC tree (single RHS) and
SCCVN doesn't handle it at all.  I have a patch which will produce

  :
  _3 = this_2(D)->D.2399.D.2325._vptr.B;
  _4 = *_3;
  PROF_6 = [obj_type_ref] OBJ_TYPE_REF(_4;(struct 
WindowListenerMultiplexer)this_2(D)->0);
  if (PROF_6 == acquire)
goto ;
  else
goto ;

  :
  OBJ_TYPE_REF(_4;(struct WindowListenerMultiplexer)this_2(D)->0) 
(this_2(D)); [tail call]
  goto ;

  :
  OBJ_TYPE_REF(_4;(struct WindowListenerMultiplexer)this_2(D)->0) 
(this_2(D)); [tail call]

thus it also misses to "propagate" acquire into the tailcall.  That
could be fixed as well but only in two steps, first replacing
the OBJ_TYPE_REF in the call with PROF_6 ("CSE" it) and later
DOM might propagate the equivalence.

[Bug c/68513] [5/6 Regression] ICE in gimplify_expr, at gimplify.c:8832, c_maybe_const_expr in IL

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  ---
Supposedly r231178 and r231110.

[Bug rtl-optimization/68651] [5/6 Regression][AArch64] Missing combination of shift-by-one with other arithmetic patterns with -mcpu=cortex-a53

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-12-03
  Component|target  |rtl-optimization
   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from ktkachov at gcc dot gnu.org ---
I think this can/should be fixed in a target-independent way.
I have an idea I'm trying out

[Bug c/68668] [6 Regression] bogus error: invalid use of array with unspecified bounds

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug target/68655] SSE2 cannot vec_perm of low and high part

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On Thu, 3 Dec 2015, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68655
> 
> Jakub Jelinek  changed:
> 
>What|Removed |Added
> 
>  Status|UNCONFIRMED |NEW
>Last reconfirmed||2015-12-03
>  Ever confirmed|0   |1
> 
> --- Comment #3 from Jakub Jelinek  ---
> Well, doing something like that at the optabs.c level wouldn't be really
> helpful, as i?86 has tons of different permutation instructions and for many
> permutations different sequence lengths.
> 
> So, the question is, does any supported CPU have some extra reinterpretation
> costs if we use a different integral vector mode (I believe there is some cost
> for some CPU when reinterpreting an integral vector as float vector and back,
> vice versa, or perhaps even float vector as double vector and vice versa)?
> If not, then the easiest fix is IMHO to change either
> ix86_expand_vec_perm_const_1
> or both
> ix86_expand_vec_perm_const and ix86_vectorize_vec_perm_const_ok
> to detect the case when V*{QI,HI,SI} permutation is doable in a wider unit 
> mode
> same whole vector size mode and just transform it to that case 
> unconditionally.
> If there is some cost, then we'd perhaps should do that at the end of
> expand_vec_perm_1 (if everything else failed for single instruction), but then
> the question is what to do with the 2-5 long sequences, we'd need to repeat
> that at all the other spots.

Older AMD CPUs had "reformatting" costs but only when you apply operations
to vectors that may destroy properties such as whether the value is
a NaN - and the formatting penalty applied only when you then perform
an operation in FP representation on that vector that would care about
this.

So generally I think changing from vector integer modes to
vector integer or float modes of different size and then back
for the purpose of permutation is fine.

Doing this for vector float modes might have an issue depending
on the HW thus using vshufpd on a fload vector.  Practially
the FP state doesn't change unless you shuffle sub-parts of the
float but of course the HW might not be so clever to detect this.

So I think using larger modes or even smaller modes (we already
try chars in optans.c unconditionally (even for float modes?))
for integer vector mode shuffles is ok.  For float vector modes
I would avoid this unless we do more research.

[Bug target/68620] ICE on gcc.target/arm/attr-neon-fp16.c

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Does that mean we need to define a movv4hf pattern?

[Bug c++/68669] New: -Wunused-variable is not correctly supressed by #pragmas

[pavel.celba at ricardo dot com]

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

Bug ID: 68669
   Summary: -Wunused-variable is not correctly supressed by
#pragmas
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pavel.celba at ricardo dot com
  Target Milestone: ---

The GCC version info:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/rs-sync/compilers/gcc/5.1.0/sle11/libexec/gcc/x86_64-unknown-linux-gnu/5.1.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/rs-sync/compilers/gcc/5.1.0/sle11
--libdir=/rs-sync/compilers/gcc/5.1.0/sle11/lib64 --enable-lto
--enable-gold=yes --enable-ld=yes
--with-gmp-include=/rs-sync/compilers/gcc/5.1.0/sle11/include
--with-gmp-lib=/rs-sync/compilers/gcc/5.1.0/sle11/lib64
--with-mpfr-include=/rs-sync/compilers/gcc/5.1.0/sle11/include
--with-mpfr-lib=/rs-sync/compilers/gcc/5.1.0/sle11/lib64
--with-mpc-include=/rs-sync/compilers/gcc/5.1.0/sle11/include
--with-mpc-lib=/rs-sync/compilers/gcc/5.1.0/sle11/lib64
--with-ppl-include=/rs-sync/compilers/gcc/5.1.0/sle11/include
--with-ppl-lib=/rs-sync/compilers/gcc/5.1.0/sle11/lib64
Thread model: posix
gcc version 5.1.0 (GCC)

Including following file from the boost unit test framework - boost version
1.58.0: 
#include 

and trying to supress unused-variable warnings still produce unused variable
warnings:

#ifdef __GNUC__
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-variable"
#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
#pragma GCC diagnostic ignored "-Wsign-compare"
#endif

#include 

#ifdef __GNUC__
#pragma GCC diagnostic pop
#endif

E.g. from our company unit test code compilation:

In file included from
/store/prtc-rsfile/pc1/pc1PlasticLinux/boost/1.58.0/boost/test/unit_test_log.hpp:28:0,
 from
/store/prtc-rsfile/pc1/pc1PlasticLinux/boost/1.58.0/boost/test/test_tools.hpp:20,
 from
/store/prtc-rsfile/pc1/pc1PlasticLinux/boost/1.58.0/boost/test/unit_test.hpp:19,
 from
/store/prtc-rsfile/pc1/pc1PlasticLinux/cpputils/code/unitTest/../include/cuBoostUnitTestHeaderInclude.h:20,
 from
/store/prtc-rsfile/pc1/pc1PlasticLinux/cpputils/code/unitTest/src/run_tests.cpp:2:
/store/prtc-rsfile/pc1/pc1PlasticLinux/boost/1.58.0/boost/test/unit_test_log.hpp:134:28:
warning: âboost::unit_test::{anonymous}::unit_test_logâ defined but not used
[-Wunused-variable]
 BOOST_TEST_SINGLETON_INST( unit_test_log )
^
/store/prtc-rsfile/pc1/pc1PlasticLinux/boost/1.58.0/boost/test/utils/trivial_singleton.hpp:64:36:
note: in definition of macro âBOOST_TEST_SINGLETON_INSTâ
 namespace { BOOST_JOIN( inst, _t)& inst = BOOST_JOIN( inst, _t)::instance(); }

FYI - run_tests.cpp is exactly this:
#define BOOST_TEST_MODULE cpputils_tests test
#include "cuBoostUnitTestHeaderInclude.h"

[Bug tree-optimization/67800] [6 Regression] Missed vectorization opportunity on x86 (DOT_PROD_EXPR in non-reduction)

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Thu Dec  3 08:43:22 2015
New Revision: 231221

URL: https://gcc.gnu.org/viewcvs?rev=231221=gcc=rev
Log:
2015-12-03  Richard Biener  

PR tree-optimization/67800
PR tree-optimization/68333
* tree-vect-patterns.c (vect_recog_dot_prod_pattern): Restore
restriction to reduction contexts but allow SLP reductions as well.
(vect_recog_sad_pattern): Likewise.
(vect_recog_widen_sum_pattern): Likewise.

* gcc.target/i386/vect-pr67800.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.target/i386/vect-pr67800.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-patterns.c

[Bug tree-optimization/68333] [6 Regression] FAIL: gcc.dg/vect/slp-multitypes-4.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Thu Dec  3 08:43:22 2015
New Revision: 231221

URL: https://gcc.gnu.org/viewcvs?rev=231221=gcc=rev
Log:
2015-12-03  Richard Biener  

PR tree-optimization/67800
PR tree-optimization/68333
* tree-vect-patterns.c (vect_recog_dot_prod_pattern): Restore
restriction to reduction contexts but allow SLP reductions as well.
(vect_recog_sad_pattern): Likewise.
(vect_recog_widen_sum_pattern): Likewise.

* gcc.target/i386/vect-pr67800.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.target/i386/vect-pr67800.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-patterns.c

[Bug c/68513] [5/6 Regression] ICE in gimplify_expr, at gimplify.c:8832, c_maybe_const_expr in IL

[jan.sm...@alcatel-lucent.com]

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

--- Comment #11 from Jan Smets  ---
Thanks. Can this also be backported to 5.x? Thanks

[Bug c/68668] [6 Regression] bogus error: invalid use of array with unspecified bounds

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-03
 CC||jsm28 at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug tree-optimization/68333] [6 Regression] FAIL: gcc.dg/vect/slp-multitypes-4.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Should be fixed now.

[Bug target/68655] SSE2 cannot vec_perm of low and high part

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Well, doing something like that at the optabs.c level wouldn't be really
helpful, as i?86 has tons of different permutation instructions and for many
permutations different sequence lengths.

So, the question is, does any supported CPU have some extra reinterpretation
costs if we use a different integral vector mode (I believe there is some cost
for some CPU when reinterpreting an integral vector as float vector and back,
vice versa, or perhaps even float vector as double vector and vice versa)?
If not, then the easiest fix is IMHO to change either
ix86_expand_vec_perm_const_1
or both
ix86_expand_vec_perm_const and ix86_vectorize_vec_perm_const_ok
to detect the case when V*{QI,HI,SI} permutation is doable in a wider unit mode
same whole vector size mode and just transform it to that case unconditionally.
If there is some cost, then we'd perhaps should do that at the end of
expand_vec_perm_1 (if everything else failed for single instruction), but then
the question is what to do with the 2-5 long sequences, we'd need to repeat
that at all the other spots.

[Bug tree-optimization/68659] [6 regression] FAIL: gcc.dg/graphite/id-pr45230-1.c (internal compiler error)

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Target|powerpc-*-* |powerpc-*-*, arm*-*-*
   Last reconfirmed|2015-12-02 00:00:00 |2015-12-3
 CC||ktkachov at gcc dot gnu.org

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Seeing this on arm-none-eabi too.

[Bug tree-optimization/68659] [6 regression] FAIL: gcc.dg/graphite/id-pr45230-1.c (internal compiler error)

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed|2015-12-03 00:00:00 |2015-12-02 0:00

--- Comment #5 from amker at gcc dot gnu.org ---
(In reply to Richard Biener from comment #3)
> Sounds similar to the fixed PR68550.  But confirmed, I also saw the ICE
> (with ISL 0.12 and 0.14).

Yes, seems with the change, more scop is recognized and then the error happens.
 I will double check that the loop niter analysis is correct.

[Bug target/68620] ICE on gcc.target/arm/attr-neon-fp16.c

[chrbr at gcc dot gnu.org]

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

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2015-12-3
 CC||chrbr at gcc dot gnu.org

--- Comment #2 from chrbr at gcc dot gnu.org ---
confirmed. the following ICE with default configure options

arm-none-eabi-gcc  -mfp16-format=ieee -mbig-endian -mfpu=neon-fp16
-mfloat-abi=hard ~/neon-fp16-fail.c

#include "arm_neon.h"

float16x4_t 
foo (float32x4_t arg)
{
return vcvt_f16_f32 (arg);
}

[Bug bootstrap/68667] [6 Regression] GCC trunk build fails compiling graphite-isl-ast-to-gimple.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||build
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-03
   Target Milestone|--- |6.0
Summary|GCC trunk build fails   |[6 Regression] GCC trunk
   |compiling   |build fails compiling
   |graphite-isl-ast-to-gimple. |graphite-isl-ast-to-gimple.
   |c   |c
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Confirmed.  We need a configure check for that OP.

[Bug c++/68669] -Wunused-variable is not correctly supressed by #pragmas

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-12-03
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Please attache the (compressed) preprocessed file run_tests.ii.

[Bug middle-end/26724] __builtin_constant_p fails to recognise function with constant return

[anton at samba dot org]

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

--- Comment #2 from Anton Blanchard  ---
This issue is still present. The workaround Andrew suggests is good:

static inline int baz(void)
{
return 0;
}

void bad()
{
int i = baz();
if (!__builtin_constant_p(i))
FAIL();
}

[Bug lto/65745] [5/6 Regression] lto ICE (Segmentation fault) on powerpc64le-linux-gnu

[doko at gcc dot gnu.org]

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

Matthias Klose  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #6 from Matthias Klose  ---
now builds, no ICE anymore

[Bug rtl-optimization/68624] [6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (in 64-bit mode)

[ktkachov at gcc dot gnu.org]

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

--- Comment #6 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Thu Dec  3 13:28:55 2015
New Revision: 231226

URL: https://gcc.gnu.org/viewcvs?rev=231226=gcc=rev
Log:
[RTL-ifcvt] PR rtl-optimization/68624: Clean up logic that checks for
clobbering conflicts across basic blocks

PR rtl-optimization/68624
* ifcvt.c (noce_try_cmove_arith): Check clobbers of temp regs in both
blocks if they exist and simplify the logic choosing the order to emit
them in.

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

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr68624.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ifcvt.c
trunk/gcc/testsuite/ChangeLog

[Bug c/68668] [6 Regression] bogus error: invalid use of array with unspecified bounds

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
I'll have a go at this.

[Bug rtl-optimization/68636] unnecessary unaligned load on mips o32

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #7 from Richard Biener  ---
Fix:

Index: gcc/builtins.c
===
--- gcc/builtins.c  (revision 231058)
+++ gcc/builtins.c  (working copy)
@@ -497,6 +497,10 @@ get_pointer_alignment_1 (tree exp, unsig
{
  *bitposp = ptr_misalign * BITS_PER_UNIT;
  *alignp = ptr_align * BITS_PER_UNIT;
+ /* Make sure to return a sensible alignment when the multiplication
+by BITS_PER_UNIT overflowed.  */
+ if (*alignp == 0)
+   *alignp = 1u << (HOST_BITS_PER_INT - 1);
  /* We cannot really tell whether this result is an approximation.  */
  return true;
}

[Bug target/68471] ICE: in df_refs_verify, at df-scan.c:4022 with -mmitigate-rop and long double

[bernds at gcc dot gnu.org]

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

--- Comment #2 from Bernd Schmidt  ---
Author: bernds
Date: Thu Dec  3 14:17:35 2015
New Revision: 231228

URL: https://gcc.gnu.org/viewcvs?rev=231228=gcc=rev
Log:
Fix some issues with the ROP patch (PR 68471, 68472)

PR target/68471
PR target/68472
* config/i386/i386.c (ix86_mitigate_rop): Don't call
compute_bb_for_insn again.  Call df_insn_rescan_all.
* config/i386/i386.md (set_got_rex64): Override modrm_class.

* regrename.c (build_def_use): Ignore stack regs if regstack_completed.

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

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.md
trunk/gcc/regrename.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/68560] [6 Regression] The test gfortran.dg/shape_8.f90 now fails when compiled with -flto

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
> I think the problem is that it's actually working.  The optional arguments are
> removed... When they are not present, the procedure declaration also loses 
> them.

Well, it is not how I read

  static integer(kind=4) C.3452 = 4;
...
  D.3451 = 
  D.3453 = 
  _gfortran_shape_4 (, D.3451, D.3453);

There is a third argument D.3453 and its value is 4 (if it's not the KIND, what
is it?).

[Bug fortran/68649] [6 Regression] note: code may be misoptimized unless -fno-strict-aliasing is used

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
Further reduced test

 REAL*8 :: a8(16),b8(4,4), c8(16), d8(4,4)
 c8=RESHAPE(b8,(/16/))
 d8=RESHAPE(a8,(/4,4/))
END

> Notice the difference in size of the records.

How do they relate to the array sizes?

From https://gcc.gnu.org/onlinedocs/gfortran/RESHAPE.html#RESHAPE

Description:
Reshapes SOURCE to correspond to SHAPE. If necessary, the new array may be
padded with elements from PAD or permuted as defined by ORDER. 

> In libgfortran there is 
> void
> reshape_r8 (gfc_array_r8 * const restrict ret, 
> gfc_array_r8 * const restrict source, 
> shape_type * const restrict shape,
> gfc_array_r8 * const restrict pad, 
> shape_type * const restrict order)
>
> ideally the fortran-fe produced declaration of reshape_r8 should be just one 
> per
> unit and interoperable with the declaration above that is pointer to:
> #define GFC_ARRAY_DESCRIPTOR(r, type) \
> struct {\
>   type *base_addr;\
>   size_t offset;\
>   index_type dtype;\
>   descriptor_dimension dim[r];\
> }

Are you meaning that fortran-fe should produce one reshape_r8xx per shape of
source?

[Bug c++/68669] [5 regression] -Wunused-variable in anonymous namespace is not correctly supressed by #pragmas

[manu at gcc dot gnu.org]

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

--- Comment #8 from Manuel López-Ibáñez  ---
(In reply to Markus Trippelsdorf from comment #7)
> (In reply to Manuel López-Ibáñez from comment #6)
> > Perhaps you need to try with -Wunused-const-variable ? There may be some
> > problem with TREE_READONLY (decl).
> 
> There is no -Wunused-const-variable in gcc-5.

I mean to trigger the bug (or check the correct behavior) with gcc 6.

[Bug c++/68669] [5 regression] -Wunused-variable in anonymous namespace is not correctly supressed by #pragmas

[trippels at gcc dot gnu.org]

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

--- Comment #9 from Markus Trippelsdorf  ---
Well, why don't you answer these questions yourself?

[Bug target/68655] SSE2 cannot vec_perm of low and high part

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #36897|0   |1
is obsolete||

--- Comment #9 from Jakub Jelinek  ---
Created attachment 36898
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36898=edit
gcc6-pr68655.patch

Second attempt, this one tries it only for a single insn if we couldn't get a
single insn otherwise, and then as a final fallback if nothing else worked.
Running the same command, I see only beneficial changes this time:
vshuf-v16qi.c -msse2 test_2, scalar to punpcklqdq
vshuf-v64qi.c -mavx512bw test_2
-   vpermi2w%zmm1, %zmm1, %zmm0
-   vpshufb .LC3(%rip), %zmm0, %zmm1
-   vpshufb .LC4(%rip), %zmm0, %zmm0
-   vporq   %zmm0, %zmm1, %zmm0
+   vpermi2q%zmm1, %zmm1, %zmm0
vshuf-v8hi.c -msse2 test_2, scalar to punpcklqdq
and that is it.
Also on:
typedef unsigned short v8hi __attribute__((vector_size(16)));
typedef int v4si __attribute__((vector_size(16)));
typedef long long v2di __attribute__((vector_size(16)));

v2di
f1 (v2di a, v2di b)
{
  return __builtin_shuffle (a, b, (v2di) { 0, 2 });
}

v8hi
f2 (v8hi a, v8hi b)
{
  return __builtin_shuffle (a, b, (v8hi) { 0, 1, 2, 3, 8, 9, 10, 11 });
}

v4si
f3 (v4si a, v4si b)
{
  return __builtin_shuffle (a, b, (v4si) { 0, 1, 4, 5 });
}

v8hi
f4 (v8hi a, v8hi b)
{
  return __builtin_shuffle (a, b, (v8hi) { 0, 1, 2, 3, 12, 13, 14, 15 });
}

with -O2 -msse2 (or -msse3) the diff in f2 is scalar code to punpcklqdq,
with -O2 -mssse3 the diff is f2:
- punpcklwd %xmm1, %xmm0
- pshufb .LC0(%rip), %xmm0
+ punpcklqdq %xmm1, %xmm0
f4:
- palignr $8, %xmm1, %xmm0
- palignr $8, %xmm0, %xmm0
+ shufpd $2, %xmm1, %xmm0
for -O2 -msse4 just the f2 change, for each of -O2 -mavx{,2,512f,512vl} f2:
- vpunpcklwd %xmm1, %xmm0, %xmm1
- vpshufb .LC0(%rip), %xmm1, %xmm0
+ vpunpcklqdq %xmm1, %xmm0, %xmm0

[Bug c++/68669] [5 regression] -Wunused-variable in anonymous namespace is not correctly supressed by #pragmas

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC|manu at gcc dot gnu.org|

--- Comment #10 from Manuel López-Ibáñez  ---
(In reply to Markus Trippelsdorf from comment #9)
> Well, why don't you answer these questions yourself?

Because I don't have latest trunk build and ready. If you don't want to answer
them, that is ok. Maybe somebody else will, maybe they are not important after
all. I'm just pointing out things that may help to identify and fix the bug.
That was all.

[Bug fortran/68676] ICE in gfc_match_formal_arglist when compiling gfortran.dg/submodule_10.f08

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Target|alphaev68-linux-gnu |alphaev68-linux-gnu
   ||i386-*-freebsd
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-03
 CC||kargl at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
See the thread starting at
https://gcc.gnu.org/ml/fortran/2015-12/msg00030.html.

Note that I don't see these failures on x86_64-apple-darwin14 (no valgrind
error).

[Bug rtl-optimization/68636] unnecessary unaligned load on mips o32

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||mips-wrs-vxworks
   Host||x86_64-linux

--- Comment #4 from Richard Biener  ---
With the cross configuration as specified on IRC I cannot reproduce on trunk or
the GCC 5 branch head.

[Bug fortran/68009] [6 Regression] prototype for gfortran_runtime_error with inline matmul

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #3 from Dominique d'Humieres  ---
So let me move it to NEW.

[Bug c++/68669] [5 regression] -Wunused-variable in anonymous namespace is not correctly supressed by #pragmas

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #5 from Manuel López-Ibáñez  ---
(In reply to Markus Trippelsdorf from comment #3)
> gcc-6 doesn't warn at all (even without the "diagnostic ignored" pragma).

Even with an explicit -Wunused-variable?

Does the warning call in the gcc-5 branch contain %q+D? Does it work correctly
if you change it to %qD?

[Bug target/68655] SSE2 cannot vec_perm of low and high part

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
And no, precomputing the permutations isn't going to work, there are just too
many of them, and the amount of permutation instructions on i?86 is huge too.

[Bug c++/68669] [5 regression] -Wunused-variable is not correctly supressed by #pragmas

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||hubicka at ucw dot cz

--- Comment #4 from Markus Trippelsdorf  ---
Started with r210522.

[Bug target/68620] ICE on gcc.target/arm/attr-neon-fp16.c

[clyon at gcc dot gnu.org]

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

--- Comment #5 from Christophe Lyon  ---
(In reply to ktkachov from comment #3)
> Does that mean we need to define a movv4hf pattern?

Isn't *neon_mov providing this (with the VDX iterator)

I think what's not matching here is (set (subreg:SI (reg:V4HF) XXX) (subreg:SI
(reg:V4HF) XXX)) because we cannot generate (subreg:SI (reg:V4HF) XXX)

[Bug c/68533] bogus location for "warning: ‘struct s3’ declared inside parameter list will not be visible outside of this definition or declaration"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Fixed for 6+.

[Bug middle-end/68677] New: Sibcall doesn't work on function with no return

[hjl.tools at gmail dot com]

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

Bug ID: 68677
   Summary: Sibcall doesn't work on function with no return
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

[hjl@gnu-6 tmp]$ cat x.c
extern void bar (void) __attribute__ ((noreturn));

void
foo (void)
{
  bar ();
}
[hjl@gnu-6 tmp]$ gcc -S x.c -O3
[hjl@gnu-6 tmp]$ cat x.s
.file   "x.c"
.section.text.unlikely,"ax",@progbits
.LCOLDB0:
.text
.LHOTB0:
.p2align 4,,15
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
callbar
.cfi_endproc
.LFE0:
.size   foo, .-foo
.section.text.unlikely
.LCOLDE0:
.text
.LHOTE0:
.ident  "GCC: (GNU) 5.2.1 20151104 (Red Hat 5.2.1-4)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 tmp]$