[Bug rtl-optimization/80463] [6/7/8 Regression] ICE with -fselective-scheduling2 and -fvar-tracking-assignments

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Seems this doesn't ICE starting with r248863, so it likely just went latent.
Maybe we should just error out on selective scheduling and explicit
-fvar-tracking-assignments or -gstatement-frontiers, this scheduler really
can't handle any debug insns well.

[Bug fortran/29651] Subroutine: Kind convertion of intent(out) value: signal

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

 CC||jb at gcc dot gnu.org

--- Comment #13 from Janne Blomqvist  ---
From https://gcc.gnu.org/wiki/LibgfortranAbiCleanup :

> For many intrinsics there are multiple implementations for different argument 
> kinds. In many cases these should be replaced by a single implementation and 
> having the frontend convert the arguments. E.g. fseek, isatty etc. Of course 
> intrinsics with floating point arguments or that are otherwise performance 
> sensitive must still be kept separate. Also, it should be noted that the 
> current system with foo_i4 and foo_i8 works for F95 where intrinsics require 
> an integer of default kind, in F2003 this restricitons has been lifted and 
> most intrinsics should now accept integers of any kind the compiler supports. 
> Hence doing intrinsics the old way with separate library functions leads to a 
> combinatorial explosion for those intrinsics with multiple integer arguments. 


Now, for the G77 intrinsics, we don't need to follow the standard and can do
whatever we want. Though I think the general approach above is good for G77
intrinsics too, namely have one implementation in the library that uses a
suitable integer type for whatever the intrinsic is doing, then have the
frontend generate temporary variables or whatever if the intrinsic is called
with some other kind. For the particular case of signal, I wonder if it
wouldn't in the end be as easy to just generate a call to libc signal()
directly in the frontend..?

[Bug lto/83804] [meta] LTO memory consumption

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Mon Jan 15 08:57:28 2018
New Revision: 256685

URL: https://gcc.gnu.org/viewcvs?rev=256685&root=gcc&view=rev
Log:
2018-01-15  Richard Biener  

PR lto/83804
* tree.c (free_lang_data_in_type): Always unlink TYPE_DECLs
from TYPE_FIELDS.  Free TYPE_BINFO if not used by devirtualization.
Reset type names to their identifier if their TYPE_DECL doesn't
have linkage (and thus is used for ODR and devirt).
(save_debug_info_for_decl): Remove.
(save_debug_info_for_type): Likewise.
(add_tree_to_fld_list): Adjust.
* tree-pretty-print.c (dump_generic_node): Make dumping of
type names more robust.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-pretty-print.c
trunk/gcc/tree.c

[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jan 15 09:05:59 2018
New Revision: 256686

URL: https://gcc.gnu.org/viewcvs?rev=256686&root=gcc&view=rev
Log:
PR middle-end/82694
* common.opt (fstrict-overflow): No longer an alias.
(fwrapv-pointer): New option.
* tree.h (TYPE_OVERFLOW_WRAPS, TYPE_OVERFLOW_UNDEFINED): Define
also for pointer types based on flag_wrapv_pointer.
* opts.c (common_handle_option) : Set
opts->x_flag_wrap[pv] to !value, clear opts->x_flag_trapv if
opts->x_flag_wrapv got set.
* fold-const.c (fold_comparison, fold_binary_loc): Revert 2017-08-01
changes, just use TYPE_OVERFLOW_UNDEFINED on pointer type instead of
POINTER_TYPE_OVERFLOW_UNDEFINED.
* match.pd: Likewise in address comparison pattern.
* doc/invoke.texi: Document -fwrapv and -fstrict-overflow.

* gcc.dg/no-strict-overflow-7.c: Revert 2017-08-01 changes.
* gcc.dg/tree-ssa/pr81388-1.c: Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/common.opt
trunk/gcc/doc/invoke.texi
trunk/gcc/fold-const.c
trunk/gcc/match.pd
trunk/gcc/opts.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/no-strict-overflow-7.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr81388-1.c
trunk/gcc/tree.h

[Bug lto/83816] [7 Regression] lto1: internal compiler error: compressed stream: data error

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
It's a message from zlib:

  status = inflate (&in_stream, Z_SYNC_FLUSH);
  if (status != Z_OK && status != Z_STREAM_END)
internal_error ("compressed stream: %s", zError (status));

not sure what 'data error' means but I think the stream is corrupt.  Can you
try using valgrind on a reproducer to see if we have a wild memory write/read
somewhere?  And double-check your memory/disk?

[Bug c++/83817] [8 Regression] internal compiler error: tree check: expected call_expr, have aggr_init_expr in tsubst_copy_and_build, at cp/pt.c:17822

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug fortran/83823] [8 Regression] Character length issues with PACK()

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug c++/83824] [6/7/8 Regression] ICE on invalid C++ code with alignas: in chainon, at tree.c:3037

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-checking,
   ||ice-on-invalid-code
   Priority|P3  |P4

[Bug other/83826] Fixinclude creates redefinitions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-01-15
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Can you attcah both fixed and unfixed sys/types.h?

[Bug c/83844] New: [8 Regression] ICE with warn_if_not_aligned attribute

[jakub at gcc dot gnu.org]

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

Bug ID: 83844
   Summary: [8 Regression] ICE with warn_if_not_aligned attribute
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

typedef unsigned long long __u64
__attribute__((aligned(4),warn_if_not_aligned(8)));

void
bar (int n)
{
  struct A
  {
int i1;
int i2;
int i3[n];
__u64 x;
  } __attribute__((aligned (8)));
  struct B
  {
int i1;
int i2;
long long i3[n];
__u64 x;
  } __attribute__((aligned (8)));
  struct A a;
  struct B b;
}

ICEs starting with r251180.  Obviously not in all structs we can use
tree_to_uhwi on DECL_FIELD_OFFSET without checking if it actually
tree_fits_uhwi_p.

[Bug c++/83824] [6/7/8 Regression] ICE on invalid C++ code with alignas: in chainon, at tree.c:3037

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P4  |P2

--- Comment #2 from Jakub Jelinek  ---
This actually isn't error-recovery ICE, we ICE before emitting any error.

[Bug rtl-optimization/83827] vector load/store with struct in registers

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-15
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I think we have a dup for the various ABI related parameter passing vs. access
issue and similar for the return ABI (A is returned in a %xmm0/%xmm1 pair).

[Bug target/83828] FAIL: gcc.target/i386/avx512vpopcntdqvl-vpopcntq-1.c execution test

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||x86_64-*-*, i?86-*-*

--- Comment #2 from Richard Biener  ---
Either wrong-code or testsuite issue.

[Bug target/83831] [6/7/8 Regression][RX] Unused bclr,bnot,bset insns

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |6.5

[Bug libstdc++/83834] [6/7/8 Regression] FAIL: libstdc++-abi/abi_check

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
   Target Milestone|--- |6.5

[Bug middle-end/83837] [8 regression] libgomp.fortran/pointer[12].f90 FAIL

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug bootstrap/83839] [8 Regression] bootstrap fails in gcc/config/i386/i386.c on darwin

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |8.0
Summary|bootstrap fails in  |[8 Regression] bootstrap
   |gcc/config/i386/i386.c on   |fails in
   |darwin  |gcc/config/i386/i386.c on
   ||darwin

[Bug tree-optimization/83836] [8 regression] gcc.dg/vect/pr79920.c FAILs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug tree-optimization/83843] [8 Regression] wrong code at -O2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-15
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
-fno-store-merging fixes it.

test (unsigned char * buf, unsigned char * tab)
{
...
  _6 = _2 ^ _5;
  bswapsrc_18 = (short unsigned int) _6;
  _19 = bswapsrc_18 r>> 8;
  MEM[(unsigned char *)buf_15(D)] = _19;

looks suspicious.

[Bug c/83844] [8 Regression] ICE with warn_if_not_aligned attribute

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug target/83845] New: [8 regression] new failures after r256620

[clyon at gcc dot gnu.org]

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

Bug ID: 83845
   Summary: [8 regression] new failures after r256620
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Hello,

I've noticed that r256620 introduces failures:
* on aarch64-none-elf -mabi=ilp32
gcc.target/aarch64/sve/mask_struct_load_1.c -march=armv8.2-a+sve 
scan-assembler-times \\tld2d\\t.z[0-9] 98 (found 15 times)
gcc.target/aarch64/sve/mask_struct_load_1.c -march=armv8.2-a+sve 
scan-assembler-times \\tld2w\\t.z[0-9] 50 (found 92 times)
gcc.target/aarch64/sve/mask_struct_load_2.c -march=armv8.2-a+sve 
scan-assembler-times \\tld3d\\t.z[0-9] 98 (found 15 times)
gcc.target/aarch64/sve/mask_struct_load_2.c -march=armv8.2-a+sve 
scan-assembler-times \\tld3w\\t.z[0-9] 50 (found 92 times)
gcc.target/aarch64/sve/mask_struct_load_3.c -march=armv8.2-a+sve 
scan-assembler-times \\tld4d\\t.z[0-9] 98 (found 15 times)
gcc.target/aarch64/sve/mask_struct_load_3.c -march=armv8.2-a+sve 
scan-assembler-times \\tld4w\\t.z[0-9] 50 (found 92 times)
gcc.target/aarch64/sve/mask_struct_load_4.c -march=armv8.2-a+sve 
scan-assembler-times \\tld3d\\t.z[0-9] 98 (found 15 times)
gcc.target/aarch64/sve/mask_struct_load_4.c -march=armv8.2-a+sve 
scan-assembler-times \\tld3w\\t.z[0-9] 50 (found 92 times)
gcc.target/aarch64/sve/mask_struct_load_5.c -march=armv8.2-a+sve 
scan-assembler-times \\tld4d\\t.z[0-9] 98 (found 15 times)
gcc.target/aarch64/sve/mask_struct_load_5.c -march=armv8.2-a+sve 
scan-assembler-times \\tld4w\\t.z[0-9] 50 (found 92 times)
gcc.target/aarch64/sve/mask_struct_store_1.c -march=armv8.2-a+sve 
scan-assembler-times \\tst2d\\t.z[0-9] 98 (found 15 times)
gcc.target/aarch64/sve/mask_struct_store_1.c -march=armv8.2-a+sve 
scan-assembler-times \\tst2w\\t.z[0-9] 50 (found 92 times)
gcc.target/aarch64/sve/mask_struct_store_2.c -march=armv8.2-a+sve 
scan-assembler-times \\tst3d\\t.z[0-9] 98 (found 15 times)
gcc.target/aarch64/sve/mask_struct_store_2.c -march=armv8.2-a+sve 
scan-assembler-times \\tst3w\\t.z[0-9] 50 (found 92 times)
gcc.target/aarch64/sve/mask_struct_store_3.c -march=armv8.2-a+sve 
scan-assembler-times \\tst4d\\t.z[0-9] 98 (found 15 times)
gcc.target/aarch64/sve/mask_struct_store_3.c -march=armv8.2-a+sve 
scan-assembler-times \\tst4w\\t.z[0-9] 50 (found 92 times)


* on aarch64_be-none-elf:
gcc.target/aarch64/sve/mask_struct_load_3.c -march=armv8.2-a+sve (internal
compiler error)
gcc.target/aarch64/sve/mask_struct_load_3.c -march=armv8.2-a+sve (test for
excess errors)
gcc.target/aarch64/sve/mask_struct_store_3.c -march=armv8.2-a+sve  1 blank
line(s) in output
gcc.target/aarch64/sve/mask_struct_store_3.c -march=armv8.2-a+sve (internal
compiler error)
gcc.target/aarch64/sve/mask_struct_store_3.c -march=armv8.2-a+sve (test for
excess errors)

[Bug c/83844] [8 Regression] ICE with warn_if_not_aligned attribute

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-01-15
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Created attachment 43126
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43126&action=edit
gcc8-pr83844.patch

Untested fix.

[Bug middle-end/83837] [8 regression] libgomp.fortran/pointer[12].f90 FAIL

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-15
 CC||pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Revision r256607.

[Bug c/65345] ICE with _Generic selection on _Atomic int

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #30 from Marek Polacek  ---
Closing given Comment 29.

[Bug target/83846] New: -mabi=ilp32New test aarch64/sve/while_4.c fails on aarch64

[clyon at gcc dot gnu.org]

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

Bug ID: 83846
   Summary: -mabi=ilp32New test aarch64/sve/while_4.c fails on
aarch64
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Hi,

Since this new test was introduced (r256625), I've noticed it fails on
aarch64-none-elf -mabi=ilp32:
FAIL:gcc.target/aarch64/sve/while_4.c -march=armv8.2-a+sve 
scan-assembler-times \\tuqdec 2 (found 0 times)
FAIL:gcc.target/aarch64/sve/while_4.c -march=armv8.2-a+sve 
scan-assembler-times \\tuqdecb\\tx[0-9]+ 2 (found 0 times)

[Bug c/83729] [8 Regression] AVR ICE on convert_memory_address_addr_space_1 at explow.c:300

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Component|middle-end  |c
 Resolution|--- |DUPLICATE

--- Comment #5 from Georg-Johann Lay  ---
Fixed by 256608.

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

[Bug c++/54011] missed optimization opportunities for bool struct/class members

[plasmahh at gmx dot net]

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

Dennis Lubert  changed:

   What|Removed |Added

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

--- Comment #2 from Dennis Lubert  ---
The duplicate has been closed as resolved, however the compilation of this
example has not changed and is imho still a good opportunity for optimization.

Have a look on the gcc explorer with -O3 and gcc 7.3 :
https://godbolt.org/g/qWvpSg

[Bug c/83801] [8 Regression][avr] String constant in __flash not put into .progmem

[gjl at gcc dot gnu.org]

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

--- Comment #13 from Georg-Johann Lay  ---
*** Bug 83729 has been marked as a duplicate of this bug. ***

[Bug target/83838] Many gcc.target/i386/indirect-thunk*.c tests FAIL

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #3 from H.J. Lu  ---
> There are
>
> /* Only recent versions of Solaris 11 ld properly support hidden .gnu.linkonce
>sections, so don't use them.  */
> #ifndef USE_GLD
> #define USE_HIDDEN_LINKONCE 0
> #endif

If I can figure out when full support for .gnu.linkonce started in
Solaris ld, I can make this dynamic in configure.ac ...

> But GCC generates comdat:
>
> .section   
> .text.__x86_indirect_thunk,"axG",@progbits,__x86_indirec
> t_thunk,comdat
> .globl  __x86_indirect_thunk
> .hidden __x86_indirect_thunk
> .type   __x86_indirect_thunk, @function
>
> Does Solaris ld support comdat?

... like this one: complete Solaris ld support for comdat started
sometime in the Solaris 11 timeframe, cf. configure.ac (comdat_group).
Solaris 10 did not (at least not in a way that could cope with
everything gcc might generate).

Rainer

[Bug c/83729] [8 Regression] AVR ICE on convert_memory_address_addr_space_1 at explow.c:300

[gjl at gcc dot gnu.org]

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

--- Comment #6 from Georg-Johann Lay  ---
Author: gjl
Date: Mon Jan 15 10:04:32 2018
New Revision: 256687

URL: https://gcc.gnu.org/viewcvs?rev=256687&root=gcc&view=rev
Log:
PR c/83801
PR c/83729
* gcc.target/avr/torture/pr83729.c: New test.
* gcc.target/avr/torture/pr83801.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/avr/torture/pr83729.c
trunk/gcc/testsuite/gcc.target/avr/torture/pr83801.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/83847] New: [8 Regression] ICE in vectorizable_load, at tree-vect-stmts.c:7365

[marxin at gcc dot gnu.org]

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

Bug ID: 83847
   Summary: [8 Regression] ICE in vectorizable_load, at
tree-vect-stmts.c:7365
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rsandifo at gcc dot gnu.org
  Target Milestone: ---

Starting from r256643 we ICE on:

$ cat ice.i
typedef struct {
  struct {
int a;
int b;
  } c;
} * d;
typedef struct {
  unsigned e;
  d f[];
} g;
g h;
d *k;
int i(int j) {
  if (j) {
*k = *h.f;
return 1;
  }
  return 0;
}
int l;
int m;
int n;
d o;
void p() {
  for (; i(l); l++) {
n += o->c.a;
m += o->c.b;
  }
}

$ gcc -march=bdver4 -O3 -fgnu89-inline ice.i -c
during GIMPLE pass: vect
ice.i: In function ‘p’:
ice.i:24:6: internal compiler error: in vectorizable_load, at
tree-vect-stmts.c:7365
 void p() {
  ^
0xe3e4f8 vectorizable_load
../../gcc/tree-vect-stmts.c:7365
0xe44154 vect_analyze_stmt(gimple*, bool*, _slp_tree*, _slp_instance*)
../../gcc/tree-vect-stmts.c:9355
0xe63f42 vect_slp_analyze_node_operations
../../gcc/tree-vect-slp.c:2766
0xe63c7d vect_slp_analyze_node_operations
../../gcc/tree-vect-slp.c:2686
0xe6e52e vect_slp_analyze_operations(vec_info*)
../../gcc/tree-vect-slp.c:2794
0xe56b74 vect_analyze_loop_2
../../gcc/tree-vect-loop.c:2247
0xe56b74 vect_analyze_loop(loop*, _loop_vec_info*)
../../gcc/tree-vect-loop.c:2546
0xe73776 vectorize_loops()
../../gcc/tree-vectorizer.c:664

[Bug c/83801] [8 Regression][avr] String constant in __flash not put into .progmem

[gjl at gcc dot gnu.org]

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

--- Comment #14 from Georg-Johann Lay  ---
Author: gjl
Date: Mon Jan 15 10:04:32 2018
New Revision: 256687

URL: https://gcc.gnu.org/viewcvs?rev=256687&root=gcc&view=rev
Log:
PR c/83801
PR c/83729
* gcc.target/avr/torture/pr83729.c: New test.
* gcc.target/avr/torture/pr83801.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/avr/torture/pr83729.c
trunk/gcc/testsuite/gcc.target/avr/torture/pr83801.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug target/83848] New: New failures on aarch64 -mabi=ilp32 after r256628

[clyon at gcc dot gnu.org]

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

Bug ID: 83848
   Summary: New failures on aarch64 -mabi=ilp32 after r256628
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Hi,

I've noticed that several of the new tests introduced by r256628 fail on
aarch64-none-elf -mabi=ilp32:
gcc.target/aarch64/sve/index_offset_1.c -march=armv8.2-a+sve 
scan-assembler-times ld1b\\tz[0-9]+.b, p[0-9]+/z, \\[x[0-9]+, x[0-9]+\\] 16
(found 0 times)
gcc.target/aarch64/sve/index_offset_1.c -march=armv8.2-a+sve 
scan-assembler-times ld1d\\tz[0-9]+.d, p[0-9]+/z, \\[x[0-9]+, x[0-9]+, lsl 3\\]
16 (found 0 times)
gcc.target/aarch64/sve/index_offset_1.c -march=armv8.2-a+sve 
scan-assembler-times ld1h\\tz[0-9]+.h, p[0-9]+/z, \\[x[0-9]+, x[0-9]+, lsl 1\\]
16 (found 0 times)
gcc.target/aarch64/sve/index_offset_1.c -march=armv8.2-a+sve 
scan-assembler-times ld1w\\tz[0-9]+.s, p[0-9]+/z, \\[x[0-9]+, x[0-9]+, lsl 2\\]
16 (found 0 times)
gcc.target/aarch64/sve/index_offset_1.c -march=armv8.2-a+sve 
scan-assembler-times st1b\\tz[0-9]+.b, p[0-9]+, \\[x[0-9]+, x[0-9]+\\] 16
(found 0 times)
gcc.target/aarch64/sve/index_offset_1.c -march=armv8.2-a+sve 
scan-assembler-times st1d\\tz[0-9]+.d, p[0-9]+, \\[x[0-9]+, x[0-9]+, lsl 3\\]
16 (found 0 times)
gcc.target/aarch64/sve/index_offset_1.c -march=armv8.2-a+sve 
scan-assembler-times st1h\\tz[0-9]+.h, p[0-9]+, \\[x[0-9]+, x[0-9]+, lsl 1\\]
16 (found 0 times)
gcc.target/aarch64/sve/index_offset_1.c -march=armv8.2-a+sve 
scan-assembler-times st1w\\tz[0-9]+.s, p[0-9]+, \\[x[0-9]+, x[0-9]+, lsl 2\\]
16 (found 0 times)
gcc.target/aarch64/sve/loop_add_2.c -march=armv8.2-a+sve 
scan-assembler-times \\tld1w\\tz[0-9]+.s, p[0-7]+/z, \\[x[0-9]+, x[0-9]+, lsl
2\\]\\n 2 (found 0 times)
gcc.target/aarch64/sve/loop_add_2.c -march=armv8.2-a+sve 
scan-assembler-times \\tst1w\\tz[0-9]+.s, p[0-7]+, \\[x[0-9]+, x[0-9]+, lsl
2\\]\\n 1 (found 0 times)
gcc.target/aarch64/sve/loop_add_3.c -march=armv8.2-a+sve 
scan-assembler-times \\tld1w\\tz[0-9]+.s, p[0-7]+/z, \\[x[0-9]+, x[0-9]+, lsl
2\\]\\n 7 (found 0 times)
gcc.target/aarch64/sve/loop_add_3.c -march=armv8.2-a+sve 
scan-assembler-times \\tst1w\\tz[0-9]+.s, p[0-7]+, \\[x[0-9]+, x[0-9]+, lsl
2\\]\\n 1 (found 0 times)
gcc.target/aarch64/sve/while_1.c -march=armv8.2-a+sve  scan-assembler-times
\\tld1b\\tz[0-9]+\\.b, p[0-7]/z, \\[x0, x[0-9]+\\]\\n 2 (found 0 times)
gcc.target/aarch64/sve/while_1.c -march=armv8.2-a+sve  scan-assembler-times
\\tld1d\\tz[0-9]+\\.d, p[0-7]/z, \\[x0, x[0-9]+, lsl 3\\]\\n 3 (found 0 times)
gcc.target/aarch64/sve/while_1.c -march=armv8.2-a+sve  scan-assembler-times
\\tld1h\\tz[0-9]+\\.h, p[0-7]/z, \\[x0, x[0-9]+, lsl 1\\]\\n 2 (found 0 times)
gcc.target/aarch64/sve/while_1.c -march=armv8.2-a+sve  scan-assembler-times
\\tld1w\\tz[0-9]+\\.s, p[0-7]/z, \\[x0, x[0-9]+, lsl 2\\]\\n 3 (found 0 times)
gcc.target/aarch64/sve/while_1.c -march=armv8.2-a+sve  scan-assembler-times
\\tst1b\\tz[0-9]+\\.b, p[0-7], \\[x0, x[0-9]+\\]\\n 2 (found 0 times)
gcc.target/aarch64/sve/while_1.c -march=armv8.2-a+sve  scan-assembler-times
\\tst1d\\tz[0-9]+\\.d, p[0-7], \\[x0, x[0-9]+, lsl 3\\]\\n 3 (found 0 times)
gcc.target/aarch64/sve/while_1.c -march=armv8.2-a+sve  scan-assembler-times
\\tst1h\\tz[0-9]+\\.h, p[0-7], \\[x0, x[0-9]+, lsl 1\\]\\n 2 (found 0 times)
gcc.target/aarch64/sve/while_1.c -march=armv8.2-a+sve  scan-assembler-times
\\tst1w\\tz[0-9]+\\.s, p[0-7], \\[x0, x[0-9]+, lsl 2\\]\\n 3 (found 0 times)
gcc.target/aarch64/sve/while_2.c -march=armv8.2-a+sve  scan-assembler-times
\\tld1b\\tz[0-9]+\\.b, p[0-7]/z, \\[x0, x[0-9]+\\]\\n 2 (found 0 times)
gcc.target/aarch64/sve/while_2.c -march=armv8.2-a+sve  scan-assembler-times
\\tld1d\\tz[0-9]+\\.d, p[0-7]/z, \\[x0, x[0-9]+, lsl 3\\]\\n 3 (found 0 times)
gcc.target/aarch64/sve/while_2.c -march=armv8.2-a+sve  scan-assembler-times
\\tld1h\\tz[0-9]+\\.h, p[0-7]/z, \\[x0, x[0-9]+, lsl 1\\]\\n 2 (found 0 times)
gcc.target/aarch64/sve/while_2.c -march=armv8.2-a+sve  scan-assembler-times
\\tld1w\\tz[0-9]+\\.s, p[0-7]/z, \\[x0, x[0-9]+, lsl 2\\]\\n 3 (found 0 times)
gcc.target/aarch64/sve/while_2.c -march=armv8.2-a+sve  scan-assembler-times
\\tst1b\\tz[0-9]+\\.b, p[0-7], \\[x0, x[0-9]+\\]\\n 2 (found 0 times)
gcc.target/aarch64/sve/while_2.c -march=armv8.2-a+sve  scan-assembler-times
\\tst1d\\tz[0-9]+\\.d, p[0-7], \\[x0, x[0-9]+, lsl 3\\]\\n 3 (found 0 times)
gcc.target/aarch64/sve/while_2.c -march=armv8.2-a+sve  scan-assembler-times
\\tst1h\\tz[0-9]+\\.h, p[0-7], \\[x0, x[0-9]+, lsl 1\\]\\n 2 (found 0 times)
gcc.target/aarch64/sve/while_2.c -march=armv8.2-a+sve  scan-assembler-times
\\tst1w\\tz[0-9]+\\.s, p[0-7], \\[x0, x[0-9]+, lsl 2\\]\\n 3 (found 0 times)
gcc.

[Bug rtl-optimization/80463] [6/7/8 Regression] ICE with -fselective-scheduling2 and -fvar-tracking-assignments

[asolokha at gmx dot com]

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

--- Comment #10 from Arseny Solokha  ---
(In reply to Jakub Jelinek from comment #9)
> Seems this doesn't ICE starting with r248863, so it likely just went latent.

I've seen ICEs in code_motion_process_successors() or bb_note() recently, will
try to bring one soon.

[Bug target/83849] New: New failures on aarch64 -mabi=ilp32 after r256629

[clyon at gcc dot gnu.org]

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

Bug ID: 83849
   Summary: New failures on aarch64 -mabi=ilp32 after r256629
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

I've noticed that r256629 shows new failures on aarch64-none-elf -mabi=ilp32:
gcc.target/aarch64/sve/loop_add_4.c -march=armv8.2-a+sve 
scan-assembler-times \\tincb\\tx[0-9]+\\n 8 (found 40 times)
gcc.target/aarch64/sve/loop_add_4.c -march=armv8.2-a+sve 
scan-assembler-times \\tld1b\\tz[0-9]+\\.b, p[0-7]+/z, \\[x[0-9]+, x[0-9]+\\] 8
(found 0 times)
gcc.target/aarch64/sve/loop_add_4.c -march=armv8.2-a+sve 
scan-assembler-times \\tld1d\\tz[0-9]+\\.d, p[0-7]+/z, \\[x[0-9]+, x[0-9]+, lsl
3\\] 8 (found 0 times)
gcc.target/aarch64/sve/loop_add_4.c -march=armv8.2-a+sve 
scan-assembler-times \\tld1h\\tz[0-9]+\\.h, p[0-7]+/z, \\[x[0-9]+, x[0-9]+, lsl
1\\] 8 (found 0 times)
gcc.target/aarch64/sve/loop_add_4.c -march=armv8.2-a+sve 
scan-assembler-times \\tld1w\\tz[0-9]+\\.s, p[0-7]+/z, \\[x[0-9]+, x[0-9]+, lsl
2\\] 8 (found 0 times)
gcc.target/aarch64/sve/loop_add_4.c -march=armv8.2-a+sve 
scan-assembler-times \\tst1b\\tz[0-9]+\\.b, p[0-7]+, \\[x[0-9]+, x[0-9]+\\] 8
(found 0 times)
gcc.target/aarch64/sve/loop_add_4.c -march=armv8.2-a+sve 
scan-assembler-times \\tst1d\\tz[0-9]+\\.d, p[0-7]+, \\[x[0-9]+, x[0-9]+, lsl
3\\] 8 (found 0 times)
gcc.target/aarch64/sve/loop_add_4.c -march=armv8.2-a+sve 
scan-assembler-times \\tst1h\\tz[0-9]+\\.h, p[0-7]+, \\[x[0-9]+, x[0-9]+, lsl
1\\] 8 (found 0 times)
gcc.target/aarch64/sve/loop_add_4.c -march=armv8.2-a+sve 
scan-assembler-times \\tst1w\\tz[0-9]+\\.s, p[0-7]+, \\[x[0-9]+, x[0-9]+, lsl
2\\] 8 (found 0 times)
gcc.target/aarch64/sve/loop_add_5.c -march=armv8.2-a+sve 
scan-assembler-times \\tld1b\\tz[0-9]+\\.b, p[0-7]+/z, \\[x[0-9]+, x[0-9]+\\] 8
(found 0 times)
gcc.target/aarch64/sve/loop_add_5.c -march=armv8.2-a+sve 
scan-assembler-times \\tld1d\\tz[0-9]+\\.d, p[0-7]+/z, \\[x[0-9]+, x[0-9]+, lsl
3\\] 8 (found 0 times)
gcc.target/aarch64/sve/loop_add_5.c -march=armv8.2-a+sve 
scan-assembler-times \\tld1h\\tz[0-9]+\\.h, p[0-7]+/z, \\[x[0-9]+, x[0-9]+, lsl
1\\] 8 (found 0 times)
gcc.target/aarch64/sve/loop_add_5.c -march=armv8.2-a+sve 
scan-assembler-times \\tld1w\\tz[0-9]+\\.s, p[0-7]+/z, \\[x[0-9]+, x[0-9]+, lsl
2\\] 8 (found 0 times)
gcc.target/aarch64/sve/loop_add_5.c -march=armv8.2-a+sve 
scan-assembler-times \\tst1b\\tz[0-9]+\\.b, p[0-7]+, \\[x[0-9]+, x[0-9]+\\] 8
(found 0 times)
gcc.target/aarch64/sve/loop_add_5.c -march=armv8.2-a+sve 
scan-assembler-times \\tst1d\\tz[0-9]+\\.d, p[0-7]+, \\[x[0-9]+, x[0-9]+, lsl
3\\] 8 (found 0 times)
gcc.target/aarch64/sve/loop_add_5.c -march=armv8.2-a+sve 
scan-assembler-times \\tst1h\\tz[0-9]+\\.h, p[0-7]+, \\[x[0-9]+, x[0-9]+, lsl
1\\] 8 (found 0 times)
gcc.target/aarch64/sve/loop_add_5.c -march=armv8.2-a+sve 
scan-assembler-times \\tst1w\\tz[0-9]+\\.s, p[0-7]+, \\[x[0-9]+, x[0-9]+, lsl
2\\] 8 (found 0 times)

[Bug target/83850] New: [8 Regression] Spills on vector extract, gcc.target/i386/pr80846-1.c FAILs

[rguenth at gcc dot gnu.org]

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

Bug ID: 83850
   Summary: [8 Regression] Spills on vector extract,
gcc.target/i386/pr80846-1.c FAILs
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: missed-optimization, ra
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-*-*

This is a regression from development of the PR80846 patch to the point it
landed on trunk.  We now spill the accumulator:

.L2:
vmovdqa64   (%esp), %zmm3
vpaddd  (%eax), %zmm3, %zmm2
addl$64, %eax
vmovdqa64   %zmm2, (%esp)
cmpl%eax, %edx
jne .L2

which is because of the extraction of the lower/upper half with

  _20 = BIT_FIELD_REF ;
  _13 = BIT_FIELD_REF ;
  _18 = _13 + _20;

which when TERed into the add looks like 

(insn 16 15 18 4 (set (reg:V8SI 107)
(plus:V8SI (subreg:V8SI (reg:V16SI 94 [ vect_sum_11.4 ]) 32)
(subreg:V8SI (reg:V16SI 94 [ vect_sum_11.4 ]) 0))) 3004 {*addv8si3}
 (expr_list:REG_DEAD (reg:V16SI 94 [ vect_sum_11.4 ])
(nil)))

before IRA/LRA but LRA then ends up spilling reg:V16SI 94.  That defeats
the optimization intended by the PR80846 fix.

[Bug target/83850] [8 Regression] Spills on vector extract, gcc.target/i386/pr80846-1.c FAILs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-15
 CC||uros at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Not sure if this is a target or RA issue - the issue is hard to bisect because
the PR80846 fix needs to morph quite a bit during time due to the SVE changes.

[Bug lto/83804] [meta] LTO memory consumption

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
Created attachment 43127
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43127&action=edit
-fmem-report-wpa for Inkscape with -O2 for GCC 6

[Bug lto/83804] [meta] LTO memory consumption

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
Created attachment 43128
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43128&action=edit
CPU & memory consumption for Inkscape with GCC 6

[Bug target/83851] New: [8 regression] gcc.dg/vect/pr53185-2.c fails on armeb after r256634

[clyon at gcc dot gnu.org]

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

Bug ID: 83851
   Summary: [8 regression] gcc.dg/vect/pr53185-2.c fails on armeb
after r256634
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

I've noticed that r256634 introduces regressions on armeb-none-linux-gnueabihf:
FAIL: gcc.dg/vect/pr53185-2.c -flto -ffat-lto-objects execution test

[Bug target/80846] auto-vectorized AVX2 horizontal sum should narrow to 128b right away, to be more efficient for Ryzen and Intel

[rguenth at gcc dot gnu.org]

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

--- Comment #26 from Richard Biener  ---
(In reply to Peter Cordes from comment #25)
> We're getting a spill/reload inside the loop with AVX512:
> 
> .L2:
>   vmovdqa64   (%esp), %zmm3
>   vpaddd  (%eax), %zmm3, %zmm2
>   addl$64, %eax
>   vmovdqa64   %zmm2, (%esp)
>   cmpl%eax, %edx
>   jne .L2
> 
> Loop finishes with the accumulator in memory *and* in ZMM2.  The copy in
> ZMM2 is ignored, and we get
> 
> # narrow to 32 bytes using memory indexing instead of VEXTRACTI32X8 or
> VEXTRACTI64X4
>   vmovdqa 32(%esp), %ymm5
>   vpaddd  (%esp), %ymm5, %ymm0
> 
> # braindead: vextracti128 can write a new reg instead of destroying xmm0
>   vmovdqa %xmm0, %xmm1
>   vextracti128$1, %ymm0, %xmm0
>   vpaddd  %xmm0, %xmm1, %xmm0
> 
> ... then a sane 128b hsum as expected, so at least that part went
> right.

I filed PR83850 for this (I noticed this before committing).  This somehow
regressed in RA or the target.

[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 80846, which changed state.

Bug 80846 Summary: auto-vectorized AVX2 horizontal sum should narrow to 128b 
right away, to be more efficient for Ryzen and Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80846

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

[Bug target/80846] auto-vectorized AVX2 horizontal sum should narrow to 128b right away, to be more efficient for Ryzen and Intel

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #27 from Richard Biener  ---
(In reply to Peter Cordes from comment #21)
> (In reply to Richard Biener from comment #20)
> > Fixed.
> 
> Unfortunately only fixed for integer, not FP.  The OpenMP and vanilla float
> array sum functions from the godbolt link in the initial bug report still
> use 256b shuffles, including a gratuitous vperm2f128 when the upper half
> isn't used, so vextractf128 would have done the same job in 1 uop on Ryzen
> instead of 8.
> 
> Even on Intel CPUs, they're optimized for code-size, not performance
> (vhaddps instead of shuffle / vaddps).  Remember that Intel CPUs with AVX
> only have one FP shuffle unit.  (Including Sandy/Ivybridge, which has 2
> integer-128 shuffle units)
> 
> float sumfloat_autovec(const float arr[]) {
>   arr = __builtin_assume_aligned(arr, 64);
>   float sum=0;
>   for (int i=0 ; i<1024 ; i++)
> sum = sum + arr[i];
>   return sum;
> }
> 
> # gcc 20180113 -mavx2 -ffast-math -O3
> #  (tune=generic, and even with arch=znver1 no-prefer-avx128)
> ...
> vhaddps %ymm0, %ymm0, %ymm0
> vhaddps %ymm0, %ymm0, %ymm1
> vperm2f128  $1, %ymm1, %ymm1, %ymm0   # why not vextract?
> vaddps  %ymm1, %ymm0, %ymm0   # gratuitous 256b
> vzeroupper
> 
> This bug is still present for FP code: it narrows from 256b to scalar only
> in the last step.
> 
> Every VHADDPS is 2 shuffles + 1 add on Intel.  They're in-lane shuffles, but
> it's still 2 uops for port5 vs. VSHUFPS + VADDPS.  (Costing an extra cycle
> of latency because with only 1 shuffle port, the 2 interleave-shuffles that
> feed a vertical-add uop can't run in the same cycle.)  (V)HADDPS with the
> same input twice is almost never the best choice for performance.
> 
> On Ryzen it's an even bigger penalty: HADDPS xmm is 4 uops (vs. 3 on Intel).
> It's also 7c latency (vs. 3 for ADDPS).  256b VHADDPS ymm is 8 uops, one per
> 3 cycle throughput, and Agner Fog reports that it's "mixed domain", i.e.
> some kind of penalty for ivec / fp domain crossing.  I guess the shuffles it
> uses internally are ivec domain?
> 
> With multiple threads on the same core, or even with ILP with surrounding
> code, uop throughput matters as well as latency, so more uops is worse even
> if it didn't have latency costs.
> 
> The sequence I'd recommend (for both Intel and AMD) is:
> (See also
> http://stackoverflow.com/questions/6996764/fastest-way-to-do-horizontal-
> float-vector-sum-on-x86/35270026#35270026)
> 
> 
> vextractf128$1, %ymm0, %xmm1
> vaddps  %xmm1, %xmm0, %xmm0  # narrow to 128b
> 
> vmovshdup   %xmm0, %xmm0, %xmm1  # copy high->low in
> each pair
> vaddps  %xmm1, %xmm0, %xmm0
> 
> vmovhlps%xmm0, %xmm0, %xmm1  # duplicate high 64b
> vaddps  %xmm1, %xmm0, %xmm0
> 
> The MOVSHDUP / MOVHLPS sequence is also what you want without VEX, so you
> can do a 128b hsum with 4 instructions, with no MOVAPS.
> 
> Intel: 6 uops total, 3 shuffles.  vs. 8 total, 5 shuffles
> 
> AMD Ryzen: 6 uops, 3 shuffles.  vs. 26 total uops, 20 of them shuffles.  And
> much worse latency, too.
> 
> Even just fixing this specific bug without fixing the rest of the sequence
> would help AMD *significantly*, because vextractf128 is very cheap, and
> vhaddps xmm is only half the uops of ymm.  (But the latency still sucks).

Note that this is deliberately left as-is because the target advertises
(cheap) support for horizontal reduction.  The vectorizer simply generates
a single statement for the reduction epilogue:

   [local count: 10737418]:
  stmp_sum_11.5_20 = REDUC_PLUS (vect_sum_11.4_6); [tail call]
  return stmp_sum_11.5_20;

so either the target shouldn't tell the vectorizer it supports this or
it simply needs to expand to better code.  Which means - can you open
a separate bug for this?  The backend currently does:

(define_expand "reduc_plus_scal_v8sf"
  [(match_operand:SF 0 "register_operand")
   (match_operand:V8SF 1 "register_operand")]
  "TARGET_AVX"
{
  rtx tmp = gen_reg_rtx (V8SFmode);
  rtx tmp2 = gen_reg_rtx (V8SFmode);
  rtx vec_res = gen_reg_rtx (V8SFmode);
  emit_insn (gen_avx_haddv8sf3 (tmp, operands[1], operands[1]));
  emit_insn (gen_avx_haddv8sf3 (tmp2, tmp, tmp));
  emit_insn (gen_avx_vperm2f128v8sf3 (tmp, tmp2, tmp2, GEN_INT (1)));
  emit_insn (gen_addv8sf3 (vec_res, tmp, tmp2));
  emit_insn (gen_vec_extractv8sfsf (operands[0], vec_res, const0_rtx));
  DONE;
})

changing it to your sequence shouldn't be too difficult.

> -
> 
> Even for integer, this patch didn't fix the MOVDQA + PSRLDQ that we get
> without AVX.  PSHUFD or PSHUFLW to 

[Bug tree-optimization/83847] [8 Regression] ICE in vectorizable_load, at tree-vect-stmts.c:7365

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-01-15
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from rsandifo at gcc dot gnu.org  
---
Mine.

[Bug tree-optimization/83836] [8 regression] gcc.dg/vect/pr79920.c FAILs

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #1 from Christophe Lyon  ---
I can confirm that these regressions are caused by r256639 on arm*.

On arm-linux-gnueabihf, the same commit bring additional regressions:
gcc.dg/vect/no-fast-math-vect16.c scan-tree-dump-times vect "using an in-order
\\(fold-left\\) reduction" 1 (found 0 times)
gcc.dg/vect/vect-reduc-6.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"using an in-order \\(fold-left\\) reduction" 1 (found 0 times)
gcc.dg/vect/vect-reduc-6.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"vectorized 1 loops" 1 (found 0 times)
gcc.dg/vect/vect-reduc-6.c scan-tree-dump-times vect "using an in-order
\\(fold-left\\) reduction" 1 (found 0 times)
gcc.dg/vect/vect-reduc-6.c scan-tree-dump-times vect "vectorized 1 loops" 1
(found 0 times)

[Bug bootstrap/83839] [8 Regression] bootstrap fails in gcc/config/i386/i386.c on darwin

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-15
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Also seen on x86_64-apple-darwin17.

[Bug tree-optimization/83843] [8 Regression] wrong code at -O2

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Started with my r254948.
Debugging...

[Bug tree-optimization/83651] [7/8 regression] 20% slowdown of linux kernel AES cipher

[arnd at linaro dot org]

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

--- Comment #2 from Arnd Bergmann  ---
My kernel patch to use -Os got merged, but caused a regression, so I kept
experimenting with the libressl implementation. Apparently, turning off
-fcode-hoisting is a better way address PR83356, and the performance is the
same as with -Os: New numbers with libressl, same method as before:

  -O2 -Os-O2 -fno-code-hoisting
  gcc-6.3.1   16.716.7-
  gcc-7.0.1   17.516.016.0
  gcc-7.1.1   17.516.016.0
  gcc-7.2.1   17.516.016.0
  gcc-8.0.0   16.815.515.5

[Bug tree-optimization/83836] [8 regression] gcc.dg/vect/pr79920.c FAILs

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-01-15
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Presumably the new scan-tree-dump-times line needs to be restricted to
vect_double.

[Bug target/83850] [8 Regression] Spills on vector extract, gcc.target/i386/pr80846-1.c FAILs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
(insn 16 15 18 4 (set (reg:V8SI 107)
(plus:V8SI (subreg:V8SI (reg:V16SI 94 [ vect_sum_11.4 ]) 32)
(subreg:V8SI (reg:V16SI 94 [ vect_sum_11.4 ]) 0))) 3004 {*addv8si3}
 (expr_list:REG_DEAD (reg:V16SI 94 [ vect_sum_11.4 ])
(nil)))
...

 Choosing alt 1 in insn 16:  (0) v  (1) v  (2) vm {*addv8si3}
alt=0: Bad operand -- refuse
alt=1: Bad operand -- refuse

and then it somehow chooses to spill them rather than not spilling but
code-generating them into a reg?

The lowpart subreg is immediately available and the higpart subreg is
supported by the target as well.  The target originally was supposed to
generate code through

(define_expand "vec_extract"
  [(match_operand: 0 "nonimmediate_operand")
   (match_operand:V_512 1 "register_operand")
   (match_operand 2 "const_0_to_1_operand")]
  "TARGET_AVX512F"
{
  if (INTVAL (operands[2]))
emit_insn (gen_vec_extract_hi_ (operands[0], operands[1]));
  else
emit_insn (gen_vec_extract_lo_ (operands[0], operands[1]));
  DONE;
})

which ends up with a vec_select.  But somehow even .expand already shows

(insn 16 15 17 (set (reg:V8SI 107)
(plus:V8SI (subreg:V8SI (reg:V16SI 94 [ vect_sum_11.4 ]) 32)
(subreg:V8SI (reg:V16SI 94 [ vect_sum_11.4 ]) 0))) -1
 (nil))

For some reason we're not going into

  /* First try to check for vector from vector extractions.  */
  if (VECTOR_MODE_P (GET_MODE (op0))
  && !MEM_P (op0)
  && VECTOR_MODE_P (tmode)
  && known_eq (bitsize, GET_MODE_SIZE (tmode))
  && maybe_gt (GET_MODE_SIZE (GET_MODE (op0)), GET_MODE_SIZE (tmode)))
{

anymore.

(gdb) p debug_rtx (op0)
(reg:V16SI 94 [ vect_sum_11.4 ])
(gdb) p bitsize
$11 = {> = {coeffs = {256}}, }
(gdb) p tmode
$12 = E_V8SImode

so GET_MODE_SIZE (tmode) returns 32 here.  That looks like a change in
behavior?  Richard?

[Bug target/83850] [8 Regression] Spills on vector extract, gcc.target/i386/pr80846-1.c FAILs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Ah, typo - should be GET_MODE_BITSIZE.  Testing fix.

[Bug libstdc++/80276] pretty printer for std::unique_ptr shows type as std::unique_ptr

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Author: redi
Date: Mon Jan 15 11:13:53 2018
New Revision: 256689

URL: https://gcc.gnu.org/viewcvs?rev=256689&root=gcc&view=rev
Log:
PR libstdc++/80276 fix template argument handling in type printers

PR libstdc++/80276
* python/libstdcxx/v6/printers.py (strip_inline_namespaces): New.
(get_template_arg_list): New.
(StdVariantPrinter._template_args): Remove, use get_template_arg_list
instead.
(TemplateTypePrinter): Rewrite to work with gdb.Type objects instead
of strings and regular expressions.
(add_one_template_type_printer): Adapt to new TemplateTypePrinter.
(FilteringTypePrinter): Add docstring. Match using startswith. Use
strip_inline_namespaces instead of strip_versioned_namespace.
(add_one_type_printer): Prepend namespace to match argument.
(register_type_printers): Add type printers for char16_t and char32_t
string types and for types using cxx11 ABI. Update calls to
add_one_template_type_printer to provide default argument dicts.
* testsuite/libstdc++-prettyprinters/80276.cc: New test.
* testsuite/libstdc++-prettyprinters/whatis.cc: Remove tests for
basic_string and basic_string.
* testsuite/libstdc++-prettyprinters/whatis2.cc: Duplicate whatis.cc
to test local variables, without overriding _GLIBCXX_USE_CXX11_ABI.

Added:
trunk/libstdc++-v3/testsuite/libstdc++-prettyprinters/80276.cc
trunk/libstdc++-v3/testsuite/libstdc++-prettyprinters/whatis2.cc
  - copied, changed from r256688,
trunk/libstdc++-v3/testsuite/libstdc++-prettyprinters/whatis.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/python/libstdcxx/v6/printers.py
trunk/libstdc++-v3/testsuite/libstdc++-prettyprinters/whatis.cc

[Bug target/83851] [8 regression] gcc.dg/vect/pr53185-2.c fails on armeb after r256634

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug tree-optimization/83847] [8 Regression] ICE in vectorizable_load, at tree-vect-stmts.c:7365

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |8.0
   Target Milestone|--- |8.0

[Bug target/83845] [8 regression] new failures after r256620

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug rtl-optimization/80463] [6/7/8 Regression] ICE with -fselective-scheduling2 and -fvar-tracking-assignments

[asolokha at gmx dot com]

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

--- Comment #11 from Arseny Solokha  ---
How about this one? It makes only trunk gcc ICE, though.

short int t2;
int cd, aa, ft;

void
dh (void)
{
  int qs = 0;

  if (t2 < 1)
{
  int bq = 0;

  while (bq < 1)
{
}

  while (t2 < 1)
{
  if (t2 == 0)
{
  bq = 0;
  cd = !!cd;
}
  else
{
  bq = 1;
  cd = bq > qs;
}

  t2 += cd;
  bq = (t2 / qs) == bq;

  if (aa != ft)
{
  qs %= 0;
  while (bq != 0)
{
 ro:
  ;
}
}

  ++t2;
}

 ia:
  goto ro;
}

  goto ia;
}

% gcc-8.0.0-alpha20180114 -O2 -fvar-tracking-assignments
-fselective-scheduling2 -ftree-loop-vectorize -fnon-call-exceptions
-fno-tree-vrp -fno-gcse-lm -fno-tree-loop-im -fno-reorder-blocks-and-partition
-fno-reorder-blocks -fno-move-loop-invariants -w -c rsd2aiem.c
during RTL pass: sched2
rsd2aiem.c: In function 'dh':
rsd2aiem.c:51:1: internal compiler error: in
av_set_could_be_blocked_by_bookkeeping_p, at sel-sched.c:3622
 }
 ^
0x64ad85 av_set_could_be_blocked_by_bookkeeping_p
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:3622
0x64ad85 code_motion_process_successors
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:6395
0x64ad85 code_motion_path_driver
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:6617
0xc59886 code_motion_process_successors
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:6351
0xc59886 code_motion_path_driver
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:6617
0xc59886 code_motion_process_successors
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:6351
0xc59886 code_motion_path_driver
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:6617
0xc5aa5a find_used_regs
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:3283
0xc5aa5a collect_unavailable_regs_from_bnds
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:1598
0xc5aa5a find_best_reg_for_expr
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:1661
0xc5aa5a fill_vec_av_set
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:3797
0xc5da87 fill_ready_list
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:4027
0xc5da87 find_best_expr
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:4387
0xc5da87 fill_insns
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:5544
0xc5da87 schedule_on_fences
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:7361
0xc5da87 sel_sched_region_2
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:7499
0xc61737 sel_sched_region_1
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:7541
0xc61737 sel_sched_region(int)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:7642
0xc627a8 run_selective_scheduling()
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:7718
0xc42625 rest_of_handle_sched2
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sched-rgn.c:3729

(as of r256677)

[Bug rtl-optimization/80463] [6/7/8 Regression] ICE with -fselective-scheduling2 and -fvar-tracking-assignments

[abel at gcc dot gnu.org]

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

--- Comment #12 from Andrey Belevantsev  ---
(In reply to Arseny Solokha from comment #11)
> How about this one? It makes only trunk gcc ICE, though.
> 
> short int t2;
> int cd, aa, ft;
> 
> void
> dh (void)
> {
>   int qs = 0;
> 
>   if (t2 < 1)
> {
>   int bq = 0;
> 
>   while (bq < 1)
> {
> }
> 
>   while (t2 < 1)
> {
>   if (t2 == 0)
> {
>   bq = 0;
>   cd = !!cd;
> }
>   else
> {
>   bq = 1;
>   cd = bq > qs;
> }
> 
>   t2 += cd;
>   bq = (t2 / qs) == bq;
> 
>   if (aa != ft)
> {
>   qs %= 0;
>   while (bq != 0)
> {
>  ro:
>   ;
> }
> }
> 
>   ++t2;
> }
> 
>  ia:
>   goto ro;
> }
> 
>   goto ia;
> }
> 
> % gcc-8.0.0-alpha20180114 -O2 -fvar-tracking-assignments
> -fselective-scheduling2 -ftree-loop-vectorize -fnon-call-exceptions
> -fno-tree-vrp -fno-gcse-lm -fno-tree-loop-im
> -fno-reorder-blocks-and-partition -fno-reorder-blocks
> -fno-move-loop-invariants -w -c rsd2aiem.c
> during RTL pass: sched2
> rsd2aiem.c: In function 'dh':
> rsd2aiem.c:51:1: internal compiler error: in
> av_set_could_be_blocked_by_bookkeeping_p, at sel-sched.c:3622
>  }
>  ^
> 0x64ad85 av_set_could_be_blocked_by_bookkeeping_p
>   
> /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> sel-sched.c:3622
> 0x64ad85 code_motion_process_successors
>   
> /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> sel-sched.c:6395
> 0x64ad85 code_motion_path_driver
>   
> /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> sel-sched.c:6617
> 0xc59886 code_motion_process_successors
>   
> /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> sel-sched.c:6351
> 0xc59886 code_motion_path_driver
>   
> /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> sel-sched.c:6617
> 0xc59886 code_motion_process_successors
>   
> /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> sel-sched.c:6351
> 0xc59886 code_motion_path_driver
>   
> /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> sel-sched.c:6617
> 0xc5aa5a find_used_regs
>   
> /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> sel-sched.c:3283
> 0xc5aa5a collect_unavailable_regs_from_bnds
>   
> /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> sel-sched.c:1598
> 0xc5aa5a find_best_reg_for_expr
>   
> /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> sel-sched.c:1661
> 0xc5aa5a fill_vec_av_set
>   
> /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> sel-sched.c:3797
> 0xc5da87 fill_ready_list
>   
> /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> sel-sched.c:4027
> 0xc5da87 find_best_expr
>   
> /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> sel-sched.c:4387
> 0xc5da87 fill_insns
>   
> /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> sel-sched.c:5544
> 0xc5da87 schedule_on_fences
>   
> /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> sel-sched.c:7361
> 0xc5da87 sel_sched_region_2
>   
> /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> sel-sched.c:7499
> 0xc61737 sel_sched_region_1
>   
> /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> sel-sched.c:7541
> 0xc61737 sel_sched_region(int)
>   
> /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> sel-sched.c:7642
> 0xc627a8 run_selective_scheduling()
>   
> /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> sel-sched.c:7718
> 0xc42625 rest_of_handle_sched2
>   
> /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> sched-rgn.c:3729
> 
> (as of r256677)

Give me a few more days for unrelated stuff and I'll have enough time to look
at this.  If that turns to be the same dependence issue, we can check in a
patch without waiting for hot/cold bbs issue to be sorted out.

[Bug tree-optimization/83843] [8 Regression] wrong code at -O2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 43129
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43129&action=edit
gcc8-pr83843.patch

Untested fix.

[Bug rtl-optimization/63384] scheduler loops on endless fence list with -fselective-scheduling2 on x86

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #8 from Arseny Solokha  ---
I believe this PR should be marked either RESOLVED FIXED or DUPLICATE of
PR80463.

[Bug target/83687] [6/7/8 Regression] ARM NEON invalid optimisation for vabd/vabdl

[ktkachov at gcc dot gnu.org]

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Mon Jan 15 11:56:03 2018
New Revision: 256696

URL: https://gcc.gnu.org/viewcvs?rev=256696&root=gcc&view=rev
Log:
[arm] PR target/83687: Fix invalid combination of VSUB + VABS into VABD

In this wrong-code bug we combine a VSUB.I8 and a VABS.S8
into a VABD.S8 instruction . This combination is not valid
for integer operands because in the VABD instruction the semantics
are that the difference is computed in notionally infinite precision
and the absolute difference is computed on that, whereas for a
VSUB.I8 + VABS.S8 sequence the VSUB operation will perform any
wrapping that's needed for the 8-bit signed type before the VABS
gets its hands on it.

This leads to the wrong-code in the PR where the expected
sequence from the intrinsics:
VSUB + VABS of two vectors {-100, -100, -100...}, {100, 100, 100...}
gives a result of {56, 56, 56...} (-100 - 100)

but GCC optimises it into a single
VABD of {-100, -100, -100...}, {100, 100, 100...}
which produces a result of {200, 200, 200...}

The transformation is still valid for floating-point operands,
which is why it was added in the first place I believe (r178817)
but this patch disables it for integer operands.
The HFmode variants though only exist for TARGET_NEON_FP16INST, so
this patch adds the appropriate guards to the new mode iterator

Bootstrapped and tested on arm-none-linux-gnueabihf.

PR target/83687
* config/arm/iterators.md (VF): New mode iterator.
* config/arm/neon.md (neon_vabd_2): Use the above.
Remove integer-related logic from pattern.
(neon_vabd_3): Likewise.

* gcc.target/arm/neon-combine-sub-abs-into-vabd.c: Delete integer
tests.
* gcc.target/arm/pr83687.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/arm/pr83687.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/iterators.md
trunk/gcc/config/arm/neon.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/arm/neon-combine-sub-abs-into-vabd.c

[Bug rtl-optimization/83852] New: [8 Regression] ICE in sel_redirect_edge_and_branch, at sel-sched-ir.c:5644 on 32-bit BE powerpc targets

[asolokha at gmx dot com]

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

Bug ID: 83852
   Summary: [8 Regression] ICE in sel_redirect_edge_and_branch, at
sel-sched-ir.c:5644 on 32-bit BE powerpc targets
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-*-linux-gnu, powerpcspe-*-linux-gnu

gcc-8.0.0-alpha20180114 snapshot (r256677) ICEs when compiling the following
snippet w/ -O2 -fselective-scheduling -fno-if-conversion -fno-tree-dse:

long long int uo;
unsigned int vt;

void
r5 (long long int h8, long long int pu)
{
  short int wj;
  long long int *mh = h8;

  for (wj = 0; wj < 3; ++wj)
{
  int oq;
  long long int ns, xf;

  h8 += 2;
  oq = !!h8 && !!wj;
  ++uo;
  vt ^= oq + uo;
  ns = !!uo && !!vt;
  xf = (h8 != 0) ? mh : 1;
  pu += ns < xf;
}

  for (pu = 0; pu < 1; ++pu)
{
  int *sc;

  sc = (int *)&pu;
  *sc = 0;
}
}

% powerpc-e300c3-linux-gnu-gcc-8.0.0-alpha20180114 -O2 -fselective-scheduling
-fno-if-conversion -fno-tree-dse -w -c dii05jbd.c
during RTL pass: sched1
dii05jbd.c: In function 'r5':
dii05jbd.c:31:1: internal compiler error: in sel_redirect_edge_and_branch, at
sel-sched-ir.c:5644
 }
 ^
0xbeaf73 sel_redirect_edge_and_branch(edge_def*, basic_block_def*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched-ir.c:5644
0xbebea9 maybe_tidy_empty_bb
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched-ir.c:3796
0xbec05b tidy_control_flow(basic_block_def*, bool)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched-ir.c:3833
0xbec718 sel_remove_insn(rtx_insn*, bool, bool)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched-ir.c:3970
0xbec8fe return_nop_to_pool(rtx_insn*, bool)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched-ir.c:1062
0xbfb4c8 remove_temp_moveop_nops
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:4995
0xbfb4c8 schedule_expr_on_boundary
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:5470
0xbff0d1 fill_insns
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:5587
0xc00f0e schedule_on_fences
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:7361
0xc00f0e sel_sched_region_2
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:7499
0xc03711 sel_sched_region_1
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:7541
0xc03711 sel_sched_region(int)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:7642
0xc03de1 run_selective_scheduling()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:7718
0xbdabd4 rest_of_handle_sched
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sched-rgn.c:3715
0xbdabd4 execute
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sched-rgn.c:3825

[Bug libstdc++/83853] New: conditional_variable induces data_race

[rene.r...@fu-berlin.de]

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

Bug ID: 83853
   Summary: conditional_variable induces data_race
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rene.r...@fu-berlin.de
  Target Milestone: ---

[Bug target/83687] [6/7 Regression] ARM NEON invalid optimisation for vabd/vabdl

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |6.5
Summary|[6/7/8 Regression] ARM NEON |[6/7 Regression] ARM NEON
   |invalid optimisation for|invalid optimisation for
   |vabd/vabdl  |vabd/vabdl
  Known to fail|8.0 |

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Fixed on trunk. Will give it a day or two before backporting

[Bug ipa/83051] [8 Regression] ICE on valid code at -O3: in edge_badness, at ipa-inline.c:1024

[zsojka at seznam dot cz]

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

--- Comment #7 from Zdenek Sojka  ---
Created attachment 43130
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43130&action=edit
another degenerate testcase

This degenerate testcase triggers the assertion failure even after the fix. I
don't know if it's the same underlying issue or if a new PR should be opened
for it.

[Bug ipa/83051] [8 Regression] ICE on valid code at -O3: in edge_badness, at ipa-inline.c:1024

[zsojka at seznam dot cz]

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

--- Comment #8 from Zdenek Sojka  ---
(In reply to Zdenek Sojka from comment #7)
> Created attachment 43130 [details]
> another degenerate testcase
> 
> This degenerate testcase triggers the assertion failure even after the fix.
> I don't know if it's the same underlying issue or if a new PR should be
> opened for it.

$ x86_64-pc-linux-gnu-gcc -O -fno-early-inlining testcase.c
during IPA pass: inline
testcase.c:11:1: internal compiler error: in can_inline_edge_p, at
ipa-inline.c:347
 }
 ^
0x1709c51 can_inline_edge_p
/repo/gcc-trunk/gcc/ipa-inline.c:347
0x170ec30 inline_small_functions
/repo/gcc-trunk/gcc/ipa-inline.c:1791
0x17105a3 ipa_inline
/repo/gcc-trunk/gcc/ipa-inline.c:2454
0x17105a3 execute
/repo/gcc-trunk/gcc/ipa-inline.c:2860
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/83847] [8 Regression] ICE in vectorizable_load, at tree-vect-stmts.c:7365

[rsandifo at gcc dot gnu.org]

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

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

Here's the patch I'm testing.

[Bug target/83267] [8 regression] [armeb] gfortran.fortran-torture/execute/scalarize2.f90 fails since r255307

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug c/83854] New: [performance] Improve cse optimization for insn with inout ops

[zhongyunde at huawei dot com]

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

Bug ID: 83854
   Summary: [performance] Improve cse optimization for insn with
inout ops
   Product: gcc
   Version: 4.7.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhongyunde at huawei dot com
  Target Milestone: ---

Now, as we define match_dup in target insn in *.md, so when the cse only try to
replace the SRC and DEST of memory in function cse_insn , see detail as
following:

/* Canonicalize sources and addresses of destinations.
 We do this in a separate pass to avoid problems when a MATCH_DUP is
 present in the insn pattern.  In that case, we want to ensure that
 we don't break the duplicate nature of the pattern.  So we will replace
 both operands at the same time.  Otherwise, we would fail to find an
 equivalent substitution in the loop calling validate_change below.

 We used to suppress canonicalization of DEST if it appears in SRC,
 but we don't do this any more.  */

  for (i = 0; i < n_sets; i++)
{
  rtx dest = SET_DEST (sets[i].rtl);
  rtx src = SET_SRC (sets[i].rtl);
  rtx new_rtx = canon_reg (src, insn);

  validate_change (insn, &SET_SRC (sets[i].rtl), new_rtx, 1);

  if (GET_CODE (dest) == ZERO_EXTRACT)
{
  validate_change (insn, &XEXP (dest, 1),
   canon_reg (XEXP (dest, 1), insn), 1);
  validate_change (insn, &XEXP (dest, 2),
   canon_reg (XEXP (dest, 2), insn), 1);
}

  while (GET_CODE (dest) == SUBREG
 || GET_CODE (dest) == ZERO_EXTRACT
 || GET_CODE (dest) == STRICT_LOW_PART)
dest = XEXP (dest, 0);

  if (MEM_P (dest))
canon_reg (dest, insn);
}

so it will not do optimation for insn with inout ops, as we used to use
match_dup to make the inout ops use same registers. 
But some time, we can see some set ops such as reg_147 in insn_34 will be not
used later, so it can be tried to optimized for both reg_147 in insn_34, but
not only for the SRC of reg_147 in insn_34.
(insn 35 31 34 5 (set (reg:VALIGN 147 [ uu ])
(reg/v:VALIGN 136 [ uu ])) test.c:53 218 {movvalign_internal}
 (expr_list:REG_DEAD (reg/v:VALIGN 136 [ uu ])
(nil)))

(insn 34 35 38 5 (parallel [
(set (reg:VALIGN 147 [ uu ])
(const_int 0 [0]))
(set (mem:VALIGN (plus:SI (reg/f:SI 126 [ D.2594 ])
(const_int 16 [0x10])) [0 MEM[(void *)D.2594_12 +
16B] S16 A8])
(unspec:VALIGN [
(reg:VALIGN 147 [ uu ])
(mem:VALIGN (plus:SI (reg/f:SI 126 [ D.2594 ])
(const_int 16 [0x10])) [0 MEM[(void
*)D.2594_12 + 16B] S16 A8])
] UNSPEC_SVA))
]) test.c:53 453 {sva_f}
 (expr_list:REG_DEAD (reg/f:SI 126 [ D.2594 ])
(expr_list:REG_UNUSED (reg:VALIGN 147 [ uu ])



resolution:
@@ -4386,6 +4386,12 @@ cse_insn (rtx insn)
 || GET_CODE (dest) == STRICT_LOW_PART)
 || GET_CODE (dest) == STRICT_LOW_PART)
dest = XEXP (dest, 0);
dest = XEXP (dest, 0);


  /* Both input and output value will not be used after current insn,
 so the dest can also be updated with regnote REG_UNUSED.  */
  if (REG_P (dest) && find_reg_note (insn, REG_UNUSED, dest))
 validate_change (insn, &SET_DEST (sets[i].rtl),
  canon_reg (dest, insn), 1);

  if (MEM_P (dest))
  if (MEM_P (dest))
canon_reg (dest, insn);
canon_reg (dest, insn);
}
}

[Bug tree-optimization/83438] [8 Regression] 435.gromacs miscompares

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #11 from Richard Biener  ---
Note the miscompare went away ~Jan 3rd.

[Bug c/83855] New: [performance] Improve cse optimization for insn with inout ops

[zhongyunde at huawei dot com]

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

Bug ID: 83855
   Summary: [performance] Improve cse optimization for insn with
inout ops
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhongyunde at huawei dot com
  Target Milestone: ---

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

Now, as we define match_dup in target insn in *.md, so when the cse only try to
replace the SRC and DEST of memory in function cse_insn , see detail as
following:

/* Canonicalize sources and addresses of destinations.
 We do this in a separate pass to avoid problems when a MATCH_DUP is
 present in the insn pattern.  In that case, we want to ensure that
 we don't break the duplicate nature of the pattern.  So we will replace
 both operands at the same time.  Otherwise, we would fail to find an
 equivalent substitution in the loop calling validate_change below.

 We used to suppress canonicalization of DEST if it appears in SRC,
 but we don't do this any more.  */

  for (i = 0; i < n_sets; i++)
{
  rtx dest = SET_DEST (sets[i].rtl);
  rtx src = SET_SRC (sets[i].rtl);
  rtx new_rtx = canon_reg (src, insn);

  validate_change (insn, &SET_SRC (sets[i].rtl), new_rtx, 1);

  if (GET_CODE (dest) == ZERO_EXTRACT)
{
  validate_change (insn, &XEXP (dest, 1),
   canon_reg (XEXP (dest, 1), insn), 1);
  validate_change (insn, &XEXP (dest, 2),
   canon_reg (XEXP (dest, 2), insn), 1);
}

  while (GET_CODE (dest) == SUBREG
 || GET_CODE (dest) == ZERO_EXTRACT
 || GET_CODE (dest) == STRICT_LOW_PART)
dest = XEXP (dest, 0);

  if (MEM_P (dest))
canon_reg (dest, insn);
}

so it will not do optimation for insn with inout ops, as we used to use
match_dup to make the inout ops use same registers. 
But some time, we can see some set ops such as reg_147 in insn_34 will be not
used later, so it can be tried to optimized for both reg_147 in insn_34, but
not only for the SRC of reg_147 in insn_34.
(insn 35 31 34 5 (set (reg:VALIGN 147 [ uu ])
(reg/v:VALIGN 136 [ uu ])) test.c:53 218 {movvalign_internal}
 (expr_list:REG_DEAD (reg/v:VALIGN 136 [ uu ])
(nil)))

(insn 34 35 38 5 (parallel [
(set (reg:VALIGN 147 [ uu ])
(const_int 0 [0]))
(set (mem:VALIGN (plus:SI (reg/f:SI 126 [ D.2594 ])
(const_int 16 [0x10])) [0 MEM[(void *)D.2594_12 +
16B] S16 A8])
(unspec:VALIGN [
(reg:VALIGN 147 [ uu ])
(mem:VALIGN (plus:SI (reg/f:SI 126 [ D.2594 ])
(const_int 16 [0x10])) [0 MEM[(void
*)D.2594_12 + 16B] S16 A8])
] UNSPEC_SVA))
]) test.c:53 453 {sva_f}
 (expr_list:REG_DEAD (reg/f:SI 126 [ D.2594 ])
(expr_list:REG_UNUSED (reg:VALIGN 147 [ uu ])

[Bug libstdc++/83853] conditional_variable induces data_race

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-01-15
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
There's no information here, what is the bug you're reporting?

[Bug libstdc++/83830] has_unique_object_representations_v is missing

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-15
 Ever confirmed|0   |1

[Bug libstdc++/83626] std::experimental::filesystem::remove_all throws exception instead of returning 0 if path doesn't exist

[redi at gcc dot gnu.org]

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

--- Comment #15 from Jonathan Wakely  ---
Author: redi
Date: Mon Jan 15 12:38:52 2018
New Revision: 256697

URL: https://gcc.gnu.org/viewcvs?rev=256697&root=gcc&view=rev
Log:
PR libstdc++/83626 Don't throw for remove("") and remove_all("")

Backport from mainline
2018-01-04  Jonathan Wakely  

PR libstdc++/83626
* src/filesystem/ops.cc (remove(const path&, error_code&))): Do not
return an error for non-existent paths. Remove unnecessary
symlink_status call.
(remove_all(const path&)): Fix type of result variable.
(remove_all(const path&, error_code&))): Use non-throwing increment
for directory iterator. Do not return an error for non-existent paths.
* testsuite/experimental/filesystem/operations/remove.cc: New test.
* testsuite/experimental/filesystem/operations/remove_all.cc: Fix
expected results for non-existent paths.

Added:
   
branches/gcc-6-branch/libstdc++-v3/testsuite/experimental/filesystem/operations/remove.cc
  - copied, changed from r256678,
branches/gcc-6-branch/libstdc++-v3/testsuite/experimental/filesystem/operations/remove_all.cc
Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/src/filesystem/ops.cc
   
branches/gcc-6-branch/libstdc++-v3/testsuite/experimental/filesystem/operations/remove_all.cc

[Bug tree-optimization/79920] [6 Regression] Incorrect floating point results when compiling with -O3

[rsandifo at gcc dot gnu.org]

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

--- Comment #9 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Mon Jan 15 12:38:55 2018
New Revision: 256698

URL: https://gcc.gnu.org/viewcvs?rev=256698&root=gcc&view=rev
Log:
Missing vect_double in gcc.dg/vect/pr79920.c (PR83836)

2018-01-15  Richard Sandiford  

gcc/testsuite/
PR testsuite/79920
* gcc.dg/vect/pr79920.c: Restrict reduction test to vect_double

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/pr79920.c

[Bug lto/83816] [7 Regression] lto1: internal compiler error: compressed stream: data error

[olegendo at gcc dot gnu.org]

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

--- Comment #3 from Oleg Endo  ---
BTW, I'm using -flto-compression-level=0.  In the past (GCC 4.5 ...) I've used
it as a workaround for other "lto compression related" errors.

[Bug libstdc++/83834] [6/7/8 Regression] FAIL: libstdc++-abi/abi_check

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
So, what exact symbols does it report as incompatible?
I can't reproduce with my build from Friday late evening on both targets.

[Bug middle-end/57503] [6/7/8 Regression] Expand uses wrong multiply routine

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Last reconfirmed|2013-10-07 00:00:00 |2018-1-15
  Known to fail||5.5.0, 6.4.1, 7.2.1

--- Comment #15 from Georg-Johann Lay  ---
Confirmed with v5.5, v6.4, v7.2 and current trunk:

With the test case fom comment #8 and

$ avr-gcc -S -Os pr57503.c -mmcu=atmega8 -fdump-rtl-expand && cat pr57503.c
pr57503.c.234r.expand 

long
func1 (unsigned char a, unsigned char b, int c)
{
unsigned ab = a * b;
return (long) ab * c;
}

;; Function func1 (func1, funcdef_no=0, decl_uid=1511, cgraph_uid=0,
symbol_order=0)


;; Generating RTL for gimple basic block 2


...

(note 5 4 8 2 NOTE_INSN_FUNCTION_BEG)
(insn 8 5 9 2 (set (reg:HI 48)
(mult:HI (zero_extend:HI (reg/v:QI 44 [ a ]))
(zero_extend:HI (reg/v:QI 45 [ b ] "pr57503.c":4 -1
 (nil))
(insn 9 8 10 2 (parallel [
(set (reg:SI 47)
(mult:SI (sign_extend:SI (reg:HI 48))
(sign_extend:SI (reg/v:HI 46 [ c ]
(clobber (reg:HI 26 r26))
(clobber (reg:DI 18 r18))
]) "pr57503.c":5 -1
 (nil))

Hence in the 1st MULT the operands are correctly zero-extended, but in the 2nd
one there is still the wrong sign_extend:SI (reg:HI 48).

[Bug lto/83816] [7 Regression] lto1: internal compiler error: compressed stream: data error

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On Mon, 15 Jan 2018, olegendo at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83816
> 
> --- Comment #3 from Oleg Endo  ---
> BTW, I'm using -flto-compression-level=0.  In the past (GCC 4.5 ...) I've used
> it as a workaround for other "lto compression related" errors.

I think it should either work always or never ...

[Bug middle-end/57503] [6/7/8 Regression] Expand uses wrong multiply routine

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Target Milestone|6.5 |---

[Bug c++/83856] New: ICE in tsubst_copy;

[kretz at kde dot org]

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

Bug ID: 83856
   Summary: ICE in tsubst_copy;
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kretz at kde dot org
  Target Milestone: ---

Testcase (cf. https://godbolt.org/g/jFkk7N):
```
#include 

template  struct simd
{
  static constexpr size_t size() { return 4; }
  template  simd(F &&gen, decltype(std::declval()(0)) * = nullptr)
{}
};

template 
void test_tuples(const std::initializer_list> &data,
 F &&... fun_pack)
{
  auto it = data.begin();
  const int remaining = data.size() % V::size();
  if (remaining > 0) {
[](auto...) {
}((fun_pack(V([&](auto i) { return it[i < remaining ? i : 0][0]; })),
0)...);
  }
}

void f()
{
  test_tuples>({}, [](simd x) {});
}
```

Output when compiling with GCC g++-7 (Ubuntu 7.2.0-1ubuntu1~16.04) 7.2.0:
```
ice.cpp: In instantiation of ‘test_tuples(const
std::initializer_list >&, F&& ...):: [with
auto:2 = int; V = simd; F = {f()::)>}]’:
ice.cpp:6:62:   required by substitution of ‘template
simd::simd(F&&, decltype (declval()(0))*) [with F = test_tuples(const
std::initializer_list >&, F&& ...) [with V = simd;
F = {f()::)>}]:: ’
ice.cpp:17:17:   required from ‘void test_tuples(const
std::initializer_list >&, F&& ...) [with V = simd;
F = {f()::)>}]’
ice.cpp:23:52:   required from here
ice.cpp:14:25: internal compiler error: in tsubst_copy, at cp/pt.c:14539
   const int remaining = data.size() % V::size();
 ^~~~
0x5eb5c2 tsubst_copy
../../src/gcc/cp/pt.c:14539
0x5ef666 tsubst_copy
../../src/gcc/cp/pt.c:14515
0x5ef666 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:17831
0x5ef450 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:16769
0x5ef549 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:17611
0x5ef086 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:17232
0x5ef748 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:16934
0x5e83c7 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:16550
0x5e95f1 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:14477
0x5e95f1 tsubst_init
../../src/gcc/cp/pt.c:14483
0x5eb558 tsubst_copy
../../src/gcc/cp/pt.c:14681
0x5ef666 tsubst_copy
../../src/gcc/cp/pt.c:14515
0x5ef666 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:17831
0x5ef765 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:16935
0x5ef81b tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:17477
0x5ef505 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:16967
0x5ef4e9 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:16965
0x5e83c7 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:16550
0x5e7f85 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:15811
0x5e810b tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:16027
```

GCC 8 appears to be fixed.

[Bug tree-optimization/83857] New: [ICE] internal compiler error: in exact_div, at poly-int.h:2139

[vincenzo.innocente at cern dot ch]

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

Bug ID: 83857
   Summary: [ICE] internal compiler error: in exact_div, at
poly-int.h:2139
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincenzo.innocente at cern dot ch
  Target Milestone: ---

Created attachment 43133
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43133&action=edit
directory with all files needed to reproduce problem (no attempt to reduce to
minimum)

c++ -v
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/afs/cern.ch/work/i/innocent/public/w5/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk//configure
--prefix=/afs/cern.ch/user/i/innocent/w5 -enable-languages=c,c++,lto,fortran
--enable-lto -enable-libitm -disable-multilib : (reconfigured)
../gcc-trunk//configure --prefix=/afs/cern.ch/user/i/innocent/w5
-enable-languages=c,c++,lto,fortran --enable-lto -enable-libitm
-disable-multilib : (reconfigured) ../gcc-trunk//configure
--prefix=/afs/cern.ch/user/i/innocent/w5 -enable-languages=c,c++,lto,fortran
--enable-lto -enable-libitm -disable-multilib
Thread model: posix
gcc version 8.0.1 20180115 (experimental) [trunk revision 256692] (GCC) 


[innocent@vinavx3 innocent]$ tar -xzf fastSinCos.tgz 
[innocent@vinavx3 innocent]$ cd fastSinCos
[innocent@vinavx3 fastSinCos]$ c++ -Ofast -fopt-info-vec -Wall testSinCos.cpp
testSinCos.cpp:136:21: note: loop vectorized
during GIMPLE pass: vect
testSinCos.cpp: In function 'int main()':
testSinCos.cpp:22:5: internal compiler error: in exact_div, at poly-int.h:2139
 int main() {
 ^~~~
0x7853bf poly_int<1u, poly_result::is_poly>::type,
poly_coeff_pair_traits::is_poly>::type>::result_kind>::type>
exact_div<1u, unsigned long, unsigned long>(poly_int_pod<1u, unsigned long>
const&, unsigned long)
../../gcc-trunk/gcc/poly-int.h:2139
0x7853bf poly_int<1u, poly_result::result_kind>::type>
exact_div<1u, unsigned long, unsigned long>(poly_int_pod<1u, unsigned long>
const&, poly_int_pod<1u, unsigned long> const&)
../../gcc-trunk/gcc/poly-int.h:2152
0x7853bf vect_get_num_vectors
../../gcc-trunk/gcc/tree-vectorizer.h:1307
0x7853bf vect_get_num_copies
../../gcc-trunk/gcc/tree-vectorizer.h:1318
0x7853bf vectorizable_live_operation(gimple*, gimple_stmt_iterator*,
_slp_tree*, int, gimple**)
../../gcc-trunk/gcc/tree-vect-loop.c:8132
0x1102053 vect_analyze_loop_operations
../../gcc-trunk/gcc/tree-vect-loop.c:1855
0x1102053 vect_analyze_loop_2
../../gcc-trunk/gcc/tree-vect-loop.c:2254
0x1102053 vect_analyze_loop(loop*, _loop_vec_info*)
../../gcc-trunk/gcc/tree-vect-loop.c:2546
0x111b0ad vectorize_loops()
../../gcc-trunk/gcc/tree-vectorizer.c:664
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

btw 
ls /data/data/vin/build/gcc-trunk//gcc/testsuite/gcc.dg/torture/pr83753.c
/data/data/vin/build/gcc-trunk//gcc/testsuite/gcc.dg/torture/pr83753.c
c++ -Ofast -c
/data/data/vin/build/gcc-trunk//gcc/testsuite/gcc.dg/torture/pr83753.c 
-fopt-info-vec 
/data/data/vin/build/gcc-trunk//gcc/testsuite/gcc.dg/torture/pr83753.c:13:14:
note: loop vectorized
/data/data/vin/build/gcc-trunk//gcc/testsuite/gcc.dg/torture/pr83753.c:19:1:
note: basic block vectorized

[Bug target/83335] [8 regression][aarch64,ilp32] gcc.target/aarch64/asm-2.c ICEs since 255481

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug target/82931] Missing Optimization for Bit-Transfer (AVR Target)

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

  Attachment #42575|0   |1
is obsolete||

--- Comment #3 from Georg-Johann Lay  ---
Created attachment 43134
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43134&action=edit
Valid C++ test case

Confirmed for current trunk and the attached test case with

$ avr-g++ pr82931.cc -Os -mmcu=avr4 -fdump-rtl-combine-details && cat
pr82931.cc.265r.combine

The patterns are just getting too complicated due to the involved MEMs:

Failed to match this instruction:
(set (zero_extract:QI (mem:QI (reg/v/f:HI 50 [ dst ]) [0 *dst_11(D)+0 S1 A8])
(const_int 1 [0x1])
(const_int 4 [0x4]))
(lshiftrt:QI (reg:QI 52)
(const_int 4 [0x4])))

Note that the avr BE provides zero_extract, but not with MEM operands:

;; Insert bit $2.$3 into $0.$1
(define_insn "*insv.shiftrt"
  [(set (zero_extract:QI (match_operand:QI 0 "register_operand""+r")
 (const_int 1)
 (match_operand:QI 1 "const_0_to_7_operand" "n"))
(any_shiftrt:QI (match_operand:QI 2 "register_operand"  "r")
(match_operand:QI 3 "const_0_to_7_operand"  "n")))]
  ""
  "bst %2,%3\;bld %0,%1"
  ...

Adding versions with MEM operand would explode the BEs complexity, and such
patches are usually rejected because of that.

Instead, insn combiner should try versions that use the MEMs as a split point
and try REGs instead.

[Bug target/83497] [8 Regression] CPU2000 172.mgrid starts failing with r254730

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-01-15
 Ever confirmed|0   |1

[Bug c++/83502] [6/7/8 Regression] bogus -Wattributes for always_inline and noinline on function template specialization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug libstdc++/83834] [6/7/8 Regression] FAIL: libstdc++-abi/abi_check

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #3)
> So, what exact symbols does it report as incompatible?
> I can't reproduce with my build from Friday late evening on both targets.

It happened during weekend:

2 incompatible symbols
0
_ZZSt9call_onceIMSt6threadFvvEJSt17reference_wrapperIS0_EEEvRSt9once_flagOT_DpOT0_ENKUlvE0_clEv
std::call_once
>(std::once_flag&, void (std::thread::*&&)(),
std::reference_wrapper&&)::{lambda()#2}::operator()() const
version status: incompatible
GLIBCXX_3.4
type: function
status: added


1
_ZZSt9call_onceIMSt6threadFvvEJSt17reference_wrapperIS0_EEEvRSt9once_flagOT_DpOT0_ENUlvE0_4_FUNEv
std::call_once
>(std::once_flag&, void (std::thread::*&&)(),
std::reference_wrapper&&)::{lambda()#2}::_FUN()
version status: incompatible
GLIBCXX_3.4
type: function
status: added

[Bug c++/83503] [8 Regression] bogus -Wattributes for const and pure on function template specialization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug tree-optimization/83518] [8 Regression] Missing optimization: useless instructions should be dropped

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|8.0 |9.0

--- Comment #6 from Richard Biener  ---
Re-targeting to GCC9.

[Bug c++/83825] [8 Regression] ICE on invalid C++ code with shadowed identifiers: in operator[], at vec.h:826

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 43135
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43135&action=edit
gcc8-pr83825.patch

Untested fix.

[Bug middle-end/82931] Missing Optimization for Bit-Transfer

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-15
  Component|target  |middle-end
Summary|Missing Optimization for|Missing Optimization for
   |Bit-Transfer (AVR Target)   |Bit-Transfer
 Ever confirmed|0   |1

--- Comment #4 from Georg-Johann Lay  ---
As lined out in comment #3, this is a middle-end flaw in insn combine:  For
merge1 it should use MEM as split-points.  For merge2 it doesn't even recognize
that the expression is a bit-insertion.

[Bug lto/83816] [7 Regression] lto1: internal compiler error: compressed stream: data error

[olegendo at gcc dot gnu.org]

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

--- Comment #5 from Oleg Endo  ---
(In reply to rguent...@suse.de from comment #4)
> 
> I think it should either work always or never ...

Yep.  In the past the compression-level setting showed different
success/failure rates.  In this case here, it seems consistent in this regard.

[Bug rtl-optimization/83530] [8 Regression] ICE in reset_sched_cycles_in_current_ebb, at sel-sched.c:7150

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug ipa/83619] [8 Regression] ICE in inliner: caller edge count does not match BB count

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug rtl-optimization/83620] [8 Regression] ICE: in assign_by_spills, at lra-assigns.c:1470: unable to find a register to spill with -flive-range-shrinkage --param=max-sched-ready-insns=0

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug tree-optimization/83651] [7/8 regression] 20% slowdown of linux kernel AES cipher

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/83663] [8 regression] aarch64_be regressions after r255946

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
THus fixed.

[Bug libstdc++/83834] [6/7/8 Regression] FAIL: libstdc++-abi/abi_check

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
I updated glibc on Fedora 27 on Friday.

[Bug middle-end/83665] [8 regression] Big code size regression and some code quality improvement at Jan 2 2018

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Unsure what to do about this bug -- things have gone back a bit but as you say
the cap introduced artificial limit back in times.  But we do have
large-function-growth to limit big_speedup for large functions, no?

There was big size improvement with the big_speedup fuckup and comparing to
before that we only "regressed" for a few cases, like overall size is still
improving.

So is this fixed or do you plan more changes?

[Bug testsuite/83706] [8 regression] gcc.dg/ipa/inline-2.c and gcc.dg/ipa/inline-3.c fail starting with r256279

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug c++/83714] [8 Regression] ICE in build_address, at cp/typeck.c:5733

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1