[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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #8 from Arseny Solokha  ---
I cannot reproduce it anymore w/ r256677.

[Bug other/83508] [8 regression][arm] c-c++-common/Wrestrict.c fails since r255836

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #5 from Jeffrey A. Law  ---
Fixed by Martin's patch on the trunk.

[Bug other/83508] [8 regression][arm] c-c++-common/Wrestrict.c fails since r255836

[law at gcc dot gnu.org]

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

--- Comment #4 from Jeffrey A. Law  ---
Author: law
Date: Mon Jan 15 06:15:09 2018
New Revision: 256683

URL: https://gcc.gnu.org/viewcvs?rev=256683=gcc=rev
Log:
PR other/83508
* builtins.c (check_access): Avoid warning when the no-warning bit
is set.

PR other/83508
* gcc.dg/Wstringop-overflow-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog

[Bug target/83013] MicroBlaze - #ident - Error: operation combines symbols in different segments

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #4 from Jeffrey A. Law  ---
Fixed by Nathan's patch on the trunk.

[Bug target/83013] MicroBlaze - #ident - Error: operation combines symbols in different segments

[law at gcc dot gnu.org]

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

--- Comment #3 from Jeffrey A. Law  ---
Author: law
Date: Mon Jan 15 06:02:19 2018
New Revision: 256681

URL: https://gcc.gnu.org/viewcvs?rev=256681=gcc=rev
Log:
PR target/83013
* config/microblaze/microblaze.c (microblaze_asm_output_ident):
Use .pushsection/.popsection.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/microblaze/microblaze.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 #1 from Oleg Endo  ---
Hmm ... if the program is changed in some places, it can also be triggered on
GCC 6.4.  It seems it happens when adding/removing function calls inside of C++
lambda functions ... how to find the cause?

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||x86_64-pc-linux-gnu
  Component|c   |tree-optimization
   Target Milestone|--- |8.0

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

[peter at cordes dot ca]

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

--- Comment #25 from Peter Cordes  ---
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.

[Bug c/83843] New: [8 Regression] wrong code at -O2

[mednafen at sent dot com]

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

Bug ID: 83843
   Summary: [8 Regression] wrong code at -O2
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mednafen at sent dot com
  Target Milestone: ---

Created attachment 43125
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43125=edit
test case

Linux x86_64

$ /usr/local/gcc8-256680/bin/gcc -Wall -O0 -o crcred crcred.c && ./crcred
fe fd

$ /usr/local/gcc8-256680/bin/gcc -Wall -O2 -o crcred crcred.c && ./crcred
01 02
Aborted

[Bug c/51628] __attribute__((packed)) is unsafe in some cases

[hjl.tools at gmail dot com]

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

--- Comment #38 from H.J. Lu  ---
A patch is posted at

https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01237.html

[Bug target/43462] Suboptimal switch table jump generation

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 CC||olegendo at gcc dot gnu.org

--- Comment #2 from Oleg Endo  ---
PR 56197 looks like the same issue.

[Bug c/83842] extend -Wmemset-elt-size to memcpy and memmove

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=83841,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=83840

--- Comment #1 from Martin Sebor  ---
See also pr83840 and pr83841 for other shortcomings in/possible improvements to
 -Wmemset-elt-size.

[Bug c/83842] New: extend -Wmemset-elt-size to memcpy and memmove

[msebor at gcc dot gnu.org]

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

Bug ID: 83842
   Summary: extend -Wmemset-elt-size to memcpy and memmove
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The -Wmemset-elt-size warning is helpful in pointing out the mistake of passing
the number of array elements to memset rather than the number of bytes.  The
same mistake can happen when calling memcpy and memmove.  It would be useful to
extend the -Wmemset-elt-size to those functions as well (either under the same
option or under a new one).

$ cat z.c && gcc -S -Wall z.c
int a[2];

void f (void)
{
  __builtin_memset (a, 0, 2);   // -Wmemset-elt-size (good)
}

void g (const int *p)
{
  __builtin_memcpy (a, p, 2);   // missing -Wmemcpy-elt-size
}

void h0 (void)
{
  __builtin_memmove (a, [1], 2);   // missing -Wmemmove-elt-size 
}

void h1 (void)
{
  __builtin_memmove ([1], a, 2);   // missing -Wmemmove-elt-size
}

z.c: In function ‘f’:
z.c:5:3: warning: ‘memset’ used with length equal to number of elements without
multiplication by element size [-Wmemset-elt-size]
   __builtin_memset (a, 0, 2);   // -Wmemset-elt-size (good)
   ^~~~

[Bug c/83841] missing -Wmemset-elt-size with array element plus offset

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=83840

--- Comment #1 from Martin Sebor  ---
Whoops.  I didn't read the warning message.  The gcst case triggers
-Wstringop-overflow because it offset is past the end of the array.  It does
not trigger -Wmemset-elt-size even though it arguably should.

See also bug 83840.

[Bug c/83841] New: missing -Wmemset-elt-size with array element plus offset

[msebor at gcc dot gnu.org]

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

Bug ID: 83841
   Summary: missing -Wmemset-elt-size with array element plus
offset
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The -Wmemset-elt-size warning is issued inconsistently when memset is called
with an array plus offset as the first argument.

$ cat z.c && gcc -S -Wall z.c
int a[3];

void fcst (void)
{
  __builtin_memset (a + 1, 0, 2);   // missing -Wmemset-elt-size
}

void gcst (void)
{
  __builtin_memset ( + 1, 0, 2);   // -Wmemset-elt-size (good)
}

void hcst (void)
{
  __builtin_memset ([1], 0, 2);   // missing -Wmemset-elt-size
}

void fvar (unsigned i)
{
  __builtin_memset (a + i, 0, 2);   // missing -Wmemset-elt-size
}

void gvar (unsigned i)
{
  __builtin_memset ( + i, 0, 2);   // missing -Wmemset-elt-size
}

void hvar (unsigned i)
{
  __builtin_memset ([i], 0, 2);   // missing -Wmemset-elt-size
}

z.c: In function ‘gcst’:
z.c:10:3: warning: ‘__builtin_memset’ writing 2 bytes into a region of size 0
overflows the destination [-Wstringop-overflow=]
   __builtin_memset ( + 1, 0, 2);   // -Wmemset-elt-size (good)
   ^~~

[Bug c/83840] New: missing -Wmemset-elt-size with address of array element

[msebor at gcc dot gnu.org]

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

Bug ID: 83840
   Summary: missing -Wmemset-elt-size with address of array
element
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

When passing the address of an array to a function that takes a pointer it's
common (if unnecessarily verbose) practice  to take the address of the first
element of the array and pass it instead.  The test program below shows that
the -Wmemset-elt-size warning doesn't work for this case.

$ cat z.c && gcc -S -Wall z.c
int a[2];

void f (void)
{
  __builtin_memset (a, 0, 2);   // -Wmemset-elt-size (good)
}

void g (void)
{
  __builtin_memset (, 0, 2);   // -Wmemset-elt-size (good)
}

void h (void)
{
  __builtin_memset ([0], 0, 2);   // missing -Wmemset-elt-size
}

z.c: In function ‘void f()’:
z.c:5:28: warning: ‘memset’ used with length equal to number of elements
without multiplication by element size [-Wmemset-elt-size]
   __builtin_memset (a, 0, 2);   // -Wmemset-elt-size (good)
^
z.c: In function ‘void g()’:
z.c:10:29: warning: ‘memset’ used with length equal to number of elements
without multiplication by element size [-Wmemset-elt-size]
   __builtin_memset (, 0, 2);   // -Wmemset-elt-size (good)
 ^

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

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  ---
Created attachment 43124
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43124=edit
Try this patch

[Bug c++/83588] [6/7/8 Regression] struct with two flexible arrays causes an internal compiler error

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01293.html

[Bug bootstrap/83839] New: bootstrap fails in gcc/config/i386/i386.c on darwin

[egallager at gcc dot gnu.org]

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

Bug ID: 83839
   Summary: bootstrap fails in gcc/config/i386/i386.c on darwin
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egallager at gcc dot gnu.org
CC: hjl.tools at gmail dot com
  Target Milestone: ---
  Host: i386-apple-darwin9.8.0
Target: i386-apple-darwin9.8.0
 Build: i386-apple-darwin9.8.0

bootstrapping as of r256664 on i386-apple-darwin9.8.0, I get the following
error:

/usr/local/bin/g++ -std=gnu++98 -fno-PIE -c   -g -mdynamic-no-pic -DIN_GCC
-fPIC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format
-Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I.
-I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include
-I/var/root/gcc-git/my_oddly_named_builddir/./gmp -I/var/root/gcc-git/gmp
-I/var/root/gcc-git/my_oddly_named_builddir/./mpfr/src
-I/var/root/gcc-git/mpfr/src -I/var/root/gcc-git/mpc/src 
-I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/dpd -I../libdecnumber
-I../../gcc/../libbacktrace
-I/var/root/gcc-git/my_oddly_named_builddir/./isl/include
-I/var/root/gcc-git/isl/include -I/usr/local/include -o i386.o -MT i386.o -MMD
-MP -MF ./.deps/i386.TPo ../../gcc/config/i386/i386.c
cc1plus: warning: ‘-mdynamic-no-pic’ overrides ‘-fpic’, ‘-fPIC’, ‘-fpie’ or
‘-fPIE’
../../gcc/config/i386/i386.c: In function ‘void
output_indirect_thunk_function(bool, int)’:
../../gcc/config/i386/i386.c:10961:7: error: ‘ASM_OUTPUT_DEF’ was not declared
in this scope
   ASM_OUTPUT_DEF (asm_out_file, alias, name);
   ^~
../../gcc/config/i386/i386.c:10961:7: note: suggested alternative:
‘ASM_OUTPUTS’
   ASM_OUTPUT_DEF (asm_out_file, alias, name);
   ^~
   ASM_OUTPUTS
make[3]: *** [i386.o] Error 1
make[3]: Leaving directory
`/private/var/root/gcc-git/my_oddly_named_builddir/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/private/var/root/gcc-git/my_oddly_named_builddir'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/private/var/root/gcc-git/my_oddly_named_builddir'
make: *** [all] Error 2

Host compiler info: 

/usr/local/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i386-apple-darwin9.8.0/8.0.0/lto-wrapper
Target: i386-apple-darwin9.8.0
Configured with: ../configure --disable-werror --disable-werror-always
--enable-languages=c,c++,lto,objc,obj-c++ --enable-stage1-checking=release,rtl
-C --with-system-libunwind --enable-secureplt --enable-frame-pointer
--enable-debug --with-isl --disable-host-shared --enable-maintainer-mode
--disable-default-pie --with-ld64 --without-pic --enable-target-optspace
--enable-libstdcxx-debug CC=/usr/local/bin/gcc CXX=/usr/local/bin/g++
AUTOCONF=/usr/local/bin/autoconf AUTOHEADER=/usr/local/bin/autoheader
AUTORECONF=/usr/local/bin/autoreconf AUTOM4TE=/usr/local/bin/autom4te
AUTOSCAN=/usr/local/bin/autoscan AUTOUPDATE=/usr/local/bin/autoupdate
IFNAMES=/usr/local/bin/ifnames
Thread model: posix
gcc version 8.0.0 20170905 (experimental) (GCC)

(I was running this bootstrap with the same configure flags as my host
compiler)

[Bug fortran/82007] DTIO write format stored in a string leads to severe errors

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle  ---
Should I backport this to 7?

[Bug c++/81327] [8 Regression] cast to void* does not suppress -Wclass-memaccess

[msebor at gcc dot gnu.org]

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

--- Comment #17 from Martin Sebor  ---
Author: msebor
Date: Sun Jan 14 21:54:25 2018
New Revision: 256677

URL: https://gcc.gnu.org/viewcvs?rev=256677=gcc=rev
Log:
PR c++/81327 - cast to void* does not suppress -Wclass-memaccess

gcc/ChangeLog:
PR c++/81327
* doc/invoke.texi (-Wlass-memaccess): Document suppression by casting.

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

[Bug libfortran/83811] fortran 'e' format broken for single digit exponents

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #6 from Jerry DeLisle  ---
Fixed and closing.  Thanks for the bug report.

[Bug sanitizer/83356] [7 Regression] excessive stack usage compiling with -O2 -fsanitize=bounds -fsanitize=object-size

[arnd at linaro dot org]

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

--- Comment #12 from Arnd Bergmann  ---
Unfortunately that patch caused a regression (nothing to do with the compiler
really, just the way powerpc linux uses some libgcc functions), and I've done
some more investigation. The new finding is that selectively turning off
'-fcode-hoisting' on gcc-7.2.1 restores the behavior we had on gcc-7.2.1,
solving both the stack consumption problem with UBSAN and the performance
regression (with and without UBSAN) as described in pr83651, with performance
better than my previous workarounds that replaced -O2 with -Os, -O1, or -O2
-fno-tree-sra -fno-tree-pre.

I have to do more performance tests to send an updated kernel patch, but maybe
this already helps analyze the problem further.

[Bug libfortran/83811] fortran 'e' format broken for single digit exponents

[jvdelisle at gcc dot gnu.org]

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

--- Comment #5 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sun Jan 14 21:44:50 2018
New Revision: 256675

URL: https://gcc.gnu.org/viewcvs?rev=256675=gcc=rev
Log:
2018-01-14  Jerry DeLisle  

Backport from trunk
PR libgfortran/83811
* gfortran.dg/fmt_e.f90: New test.

* gfortran.dg/fmt_e.f90: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/fmt_e.f90
Modified:
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/libgfortran/ChangeLog
branches/gcc-7-branch/libgfortran/io/write.c

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

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

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

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?

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

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
Solaris fails these tests due to

sol2.h:#define USE_HIDDEN_LINKONCE 0

We can limit these tests to Linux only.

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

[ro at gcc dot gnu.org]

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

--- Comment #1 from Rainer Orth  ---
Created attachment 43123
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43123=edit
i386-pc-solaris2.11 -m32 assembler output

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

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

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

[ro at gcc dot gnu.org]

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

Bug ID: 83838
   Summary: Many gcc.target/i386/indirect-thunk*.c tests FAIL
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: hjl.tools at gmail dot com
  Target Milestone: ---
Target: i386-pc-solaris2.*

Many of the new gcc.target/i386/indirect-thunk*.c tests FAIL on Solaris/x86
(both 32 and 64-bit):

+FAIL: gcc.target/i386/indirect-thunk-1.c scan-assembler jmp[
\\t]*__x86_indirect_thunk
+FAIL: gcc.target/i386/indirect-thunk-2.c scan-assembler jmp[
\\t]*__x86_indirect_thunk
+FAIL: gcc.target/i386/indirect-thunk-3.c scan-assembler jmp[
\\t]*__x86_indirect_thunk
+FAIL: gcc.target/i386/indirect-thunk-4.c scan-assembler jmp[
\\t]*__x86_indirect_thunk
+FAIL: gcc.target/i386/indirect-thunk-7.c scan-assembler jmp[
\\t]*__x86_indirect_thunk
+FAIL: gcc.target/i386/indirect-thunk-attr-1.c scan-assembler jmp[
\\t]*__x86_indirect_thunk
+FAIL: gcc.target/i386/indirect-thunk-attr-2.c scan-assembler jmp[
\\t]*__x86_indirect_thunk
+FAIL: gcc.target/i386/indirect-thunk-attr-5.c scan-assembler jmp[
\\t]*__x86_indirect_thunk
+FAIL: gcc.target/i386/indirect-thunk-attr-6.c scan-assembler jmp[
\\t]*__x86_indirect_thunk
+FAIL: gcc.target/i386/indirect-thunk-attr-7.c scan-assembler jmp[
\\t]*__x86_indirect_thunk
+FAIL: gcc.target/i386/indirect-thunk-bnd-1.c scan-assembler bnd jmp[
\\t]*__x86_indirect_thunk_bnd
+FAIL: gcc.target/i386/indirect-thunk-bnd-2.c scan-assembler bnd jmp[
\\t]*__x86_indirect_thunk_bnd
+FAIL: gcc.target/i386/indirect-thunk-extern-1.c scan-assembler jmp[
\\t]*__x86_indirect_thunk
+FAIL: gcc.target/i386/indirect-thunk-extern-2.c scan-assembler jmp[
\\t]*__x86_indirect_thunk
+FAIL: gcc.target/i386/indirect-thunk-extern-3.c scan-assembler jmp[
\\t]*__x86_indirect_thunk
+FAIL: gcc.target/i386/indirect-thunk-extern-4.c scan-assembler jmp[
\\t]*__x86_indirect_thunk
+FAIL: gcc.target/i386/indirect-thunk-extern-7.c scan-assembler jmp[
\\t]*__x86_indirect_thunk
+FAIL: gcc.target/i386/indirect-thunk-register-1.c scan-assembler jmp[
\\t]*__x86_indirect_thunk_(r|e)ax
+FAIL: gcc.target/i386/indirect-thunk-register-3.c scan-assembler jmp[
\\t]*__x86_indirect_thunk_(r|e)ax

+FAIL: gcc.target/i386/ret-thunk-1.c scan-assembler jmp[
\\t]*__x86_return_thunk
+FAIL: gcc.target/i386/ret-thunk-10.c scan-assembler __x86_indirect_thunk:
+FAIL: gcc.target/i386/ret-thunk-10.c scan-assembler jmp[
\\t]*__x86_indirect_thunk
+FAIL: gcc.target/i386/ret-thunk-11.c scan-assembler __x86_indirect_thunk:
+FAIL: gcc.target/i386/ret-thunk-11.c scan-assembler jmp[
\\t]*__x86_indirect_thunk
+FAIL: gcc.target/i386/ret-thunk-11.c scan-assembler jmp[
\\t]*__x86_return_thunk
+FAIL: gcc.target/i386/ret-thunk-12.c scan-assembler __x86_indirect_thunk:
+FAIL: gcc.target/i386/ret-thunk-12.c scan-assembler jmp[
\\t]*__x86_indirect_thunk
+FAIL: gcc.target/i386/ret-thunk-13.c scan-assembler jmp[
\\t]*__x86_return_thunk
+FAIL: gcc.target/i386/ret-thunk-14.c scan-assembler jmp[
\\t]*__x86_indirect_thunk
+FAIL: gcc.target/i386/ret-thunk-15.c scan-assembler jmp[
\\t]*__x86_indirect_thunk
+FAIL: gcc.target/i386/ret-thunk-15.c scan-assembler jmp[
\\t]*__x86_return_thunk
+FAIL: gcc.target/i386/ret-thunk-3.c scan-assembler jmp[
\\t]*__x86_return_thunk
+FAIL: gcc.target/i386/ret-thunk-5.c scan-assembler jmp[
\\t]*__x86_return_thunk
+FAIL: gcc.target/i386/ret-thunk-7.c scan-assembler jmp[
\\t]*__x86_return_thunk
+FAIL: gcc.target/i386/ret-thunk-9.c scan-assembler __x86_indirect_thunk:
+FAIL: gcc.target/i386/ret-thunk-9.c scan-assembler jmp[
\\t]*__x86_indirect_thunk
+FAIL: gcc.target/i386/ret-thunk-9.c scan-assembler jmp[
\\t]*__x86_return_thunk

I'm adding gcc.target/i386/indirect-thunk-1.c assembler output as an example.

  Rainer

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

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #23 from Rainer Orth  ---
Created attachment 43122
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43122=edit
i386-pc-solaris2.11 -m32 assembler output

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

[ro at gcc dot gnu.org]

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

--- Comment #24 from Rainer Orth  ---
The new gcc.target/i386/pr80846-1.c testcase FAILs on Solaris/x86 (32 and
64-bit):

+FAIL: gcc.target/i386/pr80846-1.c scan-assembler-times vextracti 2 (found 1
times)

Assembler output attached.

  Rainer

[Bug rtl-optimization/80481] Unoptimal additional copy instructions

[ro at gcc dot gnu.org]

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

--- Comment #5 from Rainer Orth  ---
Created attachment 43121
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43121=edit
i386-pc-solaris2.11 -m64 assembler output

[Bug rtl-optimization/80481] Unoptimal additional copy instructions

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #4 from Rainer Orth  ---
The new testcase FAILs on 64-bit Solaris/x86:

+FAIL: g++.dg/pr80481.C  -std=gnu++11  scan-assembler-not vmovaps
+FAIL: g++.dg/pr80481.C  -std=gnu++14  scan-assembler-not vmovaps
+FAIL: g++.dg/pr80481.C  -std=gnu++98  scan-assembler-not vmovaps

I'm attaching the assembler output.

  Rainer

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

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

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

[ro at gcc dot gnu.org]

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

Bug ID: 83837
   Summary: [8 regression] libgomp.fortran/pointer[12].f90 FAIL
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---

Between 20180112 (r256571) and 20180114 (r256664), two libgomp tests started to
FAIL.  I'm seeing it on Solaris/SPARC and x86, but according to
gcc-testresults,
it happens (almost) everywhere:

+FAIL: libgomp.fortran/pointer1.f90   -O0  (internal compiler error)
+FAIL: libgomp.fortran/pointer1.f90   -O0  (test for excess errors)
+WARNING: libgomp.fortran/pointer1.f90   -O0  compilation failed to produce
executable
+FAIL: libgomp.fortran/pointer1.f90   -O1  (internal compiler error)
+FAIL: libgomp.fortran/pointer1.f90   -O1  (test for excess errors)
+WARNING: libgomp.fortran/pointer1.f90   -O1  compilation failed to produce
executable
+FAIL: libgomp.fortran/pointer1.f90   -O2  (internal compiler error)
+FAIL: libgomp.fortran/pointer1.f90   -O2  (test for excess errors)
+WARNING: libgomp.fortran/pointer1.f90   -O2  compilation failed to produce
executable
+FAIL: libgomp.fortran/pointer1.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error)
+FAIL: libgomp.fortran/pointer1.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
+WARNING: libgomp.fortran/pointer1.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  compilation failed to
produce executable
+FAIL: libgomp.fortran/pointer1.f90   -O3 -g  (internal compiler error)
+FAIL: libgomp.fortran/pointer1.f90   -O3 -g  (test for excess errors)
+WARNING: libgomp.fortran/pointer1.f90   -O3 -g  compilation failed to produce
executable
+FAIL: libgomp.fortran/pointer1.f90   -Os  (internal compiler error)
+FAIL: libgomp.fortran/pointer1.f90   -Os  (test for excess errors)
+WARNING: libgomp.fortran/pointer1.f90   -Os  compilation failed to produce
executable
+FAIL: libgomp.fortran/pointer2.f90   -O0  (internal compiler error)
+FAIL: libgomp.fortran/pointer2.f90   -O0  (test for excess errors)
+WARNING: libgomp.fortran/pointer2.f90   -O0  compilation failed to produce
executable
+FAIL: libgomp.fortran/pointer2.f90   -O1  (internal compiler error)
+FAIL: libgomp.fortran/pointer2.f90   -O1  (test for excess errors)
+WARNING: libgomp.fortran/pointer2.f90   -O1  compilation failed to produce
executable
+FAIL: libgomp.fortran/pointer2.f90   -O2  (internal compiler error)
+FAIL: libgomp.fortran/pointer2.f90   -O2  (test for excess errors)
+WARNING: libgomp.fortran/pointer2.f90   -O2  compilation failed to produce
executable
+FAIL: libgomp.fortran/pointer2.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error)
+FAIL: libgomp.fortran/pointer2.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
+WARNING: libgomp.fortran/pointer2.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  compilation failed to
produce executable
+FAIL: libgomp.fortran/pointer2.f90   -O3 -g  (internal compiler error)
+FAIL: libgomp.fortran/pointer2.f90   -O3 -g  (test for excess errors)
+WARNING: libgomp.fortran/pointer2.f90   -O3 -g  compilation failed to produce
executable
+FAIL: libgomp.fortran/pointer2.f90   -Os  (internal compiler error)
+FAIL: libgomp.fortran/pointer2.f90   -Os  (test for excess errors)

Errors are like this:

Excess errors:
during GIMPLE pass: ompexp
/vol/gcc/src/hg/trunk/local/libgomp/testsuite/libgomp.fortran/pointer1.f90:32:0:
internal compiler error: in tree_to_uhwi, at tree.c:6859
0x931397a tree_to_uhwi(tree_node const*)
/vol/gcc/src/hg/trunk/local/gcc/tree.c:6859
0x8ebed87 expand_omp_atomic
/vol/gcc/src/hg/trunk/local/gcc/omp-expand.c:6539
0x8ebed87 expand_omp
/vol/gcc/src/hg/trunk/local/gcc/omp-expand.c:7770
0x8ebf1c8 expand_omp
/vol/gcc/src/hg/trunk/local/gcc/omp-expand.c:7716
0x8ec0625 execute_expand_omp
/vol/gcc/src/hg/trunk/local/gcc/omp-expand.c:7954

  Rainer

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

[ro at gcc dot gnu.org]

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

Bug ID: 83836
   Summary: [8 regression] gcc.dg/vect/pr79920.c FAILs
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: rsandifo at gcc dot gnu.org
  Target Milestone: ---
Target: sparc-sun-solaris2.*, also on arm-none-eabi,
arm-none-linux-gnueabi, ia64-suse-linux-gnu,
mips64el-unknown-linux-gnu

Between 20180112 (r256571) and 20180114 (r256664), the gcc.dg/vect/pr79920.c
test started to FAIL on a couple of targets:

+FAIL: gcc.dg/vect/pr79920.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"using an in-order (fold-left) reduction" 1 (found 0 times)
+FAIL: gcc.dg/vect/pr79920.c scan-tree-dump-times vect "using an in-order
(fold-left) reduction" 1 (found 0 times)

I'm seeing it on Solaris/SPARC, but several others are also affected according
to gcc-testresults postings.

This is most likely caused by r256639:
2018-01-13  Richard Sandiford  <richard.sandif...@linaro.org>
Alan Hayward  <alan.hayw...@arm.com>
David Sherwood  <david.sherw...@arm.com>
[...]
gcc/testsuite/
[...]
* gcc.dg/vect/pr79920.c: Expect both loops to be vectorized and
check for a message about using in-order reductions.

  Rainer

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

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug target/83677] PPC: The xxpermr instruction is not generated correctly

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #6 from Bill Schmidt  ---
Now fixed everywhere.

[Bug target/83677] PPC: The xxpermr instruction is not generated correctly

[wschmidt at gcc dot gnu.org]

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

--- Comment #5 from Bill Schmidt  ---
Author: wschmidt
Date: Sun Jan 14 17:49:39 2018
New Revision: 256671

URL: https://gcc.gnu.org/viewcvs?rev=256671=gcc=rev
Log:
[gcc]

2018-01-14  Bill Schmidt  

Backport from mainline
2018-01-08  Bill Schmidt  

PR target/83677
* config/rs6000/altivec.md (*altivec_vpermr__internal):
Reverse order of second and third operands in first alternative.
* config/rs6000/rs6000.c (rs6000_expand_vector_set): Reverse order
of first and second elements in UNSPEC_VPERMR vector.
(altivec_expand_vec_perm_le): Likewise.

[gcc/testsuite]

2018-01-14  Bill Schmidt  

Backport from mainline
2018-01-08  Bill Schmidt  

PR target/83677
* gcc.target/powerpc/pr83677.c: New file.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr83677.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/altivec.md
branches/gcc-6-branch/gcc/config/rs6000/rs6000.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug target/83677] PPC: The xxpermr instruction is not generated correctly

[wschmidt at gcc dot gnu.org]

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

--- Comment #4 from Bill Schmidt  ---
Author: wschmidt
Date: Sun Jan 14 17:47:30 2018
New Revision: 256670

URL: https://gcc.gnu.org/viewcvs?rev=256670=gcc=rev
Log:
[gcc]

2018-01-14  Bill Schmidt  

Backport from mainline
2018-01-08  Bill Schmidt  

PR target/83677
* config/rs6000/altivec.md (*altivec_vpermr__internal):
Reverse order of second and third operands in first alternative.
* config/rs6000/rs6000.c (rs6000_expand_vector_set): Reverse order
of first and second elements in UNSPEC_VPERMR vector.
(altivec_expand_vec_perm_le): Likewise.

[gcc/testsuite]

2018-01-14  Bill Schmidt  

Backport from mainline
2018-01-08  Bill Schmidt  

PR target/83677
* gcc.target/powerpc/pr83677.c: New file.


Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr83677.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/rs6000/altivec.md
branches/gcc-7-branch/gcc/config/rs6000/rs6000.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug libfortran/83811] fortran 'e' format broken for single digit exponents

[jvdelisle at gcc dot gnu.org]

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

--- Comment #4 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sun Jan 14 17:36:29 2018
New Revision: 256669

URL: https://gcc.gnu.org/viewcvs?rev=256669=gcc=rev
Log:
2018-01-18  Jerry DeLisle  

PR libgfortran/83811
* write.c (select_buffer): Adjust buffer size up by 1.

* gfortran.dg/fmt_e.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/fmt_e.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/write.c

[Bug libstdc++/81092] Missing symbols for new std::wstring constructors

[schwab at gcc dot gnu.org]

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

--- Comment #15 from Andreas Schwab  ---
Author: schwab
Date: Sun Jan 14 17:32:20 2018
New Revision: 256668

URL: https://gcc.gnu.org/viewcvs?rev=256668=gcc=rev
Log:
PR libstdc++/81092
* config/abi/post/ia64-linux-gnu/baseline_symbols.txt: Update.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config/abi/post/ia64-linux-gnu/baseline_symbols.txt

[Bug rtl-optimization/83628] [8 Regression] performance regression when accessing arrays on alpha

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #11 from Uroš Bizjak  ---
Fixed for 7.2+.

[Bug rtl-optimization/83628] [8 Regression] performance regression when accessing arrays on alpha

[uros at gcc dot gnu.org]

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

--- Comment #10 from uros at gcc dot gnu.org ---
Author: uros
Date: Sun Jan 14 15:45:38 2018
New Revision: 256665

URL: https://gcc.gnu.org/viewcvs?rev=256665=gcc=rev
Log:
Backport from mainline
2018-01-12  Uros Bizjak  

PR target/83628
* config/alpha/alpha.md (*saddsi_1): New insn_ans_split pattern.
(*saddl_se_1): Ditto.
(*ssubsi_1): Ditto.
(*ssubl_se_1): Ditto.

Backport from mainline
2018-01-09  Uros Bizjak  

PR target/83628
* combine.c (force_int_to_mode) : Use mode instead of
op_mode in the force_to_mode call.

testsuite/ChangeLog:

Backport from mainline
2018-01-12  Uros Bizjak  

PR target/83628
* gcc.target/alpha/pr83628-3.c: New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/alpha/pr83628-3.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/combine.c
branches/gcc-7-branch/gcc/config/alpha/alpha.md
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gcc.target/alpha/pr83628-2.c

[Bug target/80870] [7 Regression] ICE building 7.1.0 sh-elf crosscompiler on macOS

[Anders.Montonen at iki dot fi]

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

--- Comment #5 from Anders Montonen  ---
With the patch from comment 4, the GCC 7 branch builds successfully.

[Bug c++/83835] New: constexpr constructor rejected in c++17 mode (regression WRT c++14)

[pdimov at gmail dot com]

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

Bug ID: 83835
   Summary: constexpr constructor rejected in c++17 mode
(regression WRT c++14)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pdimov at gmail dot com
  Target Milestone: ---

This code:

```
class X
{
public:

virtual ~X();
};

class Y
{
private:

class Z: public X
{
private:

Y const * p_;

public:

constexpr explicit Z( Y const * p ): p_( p ) {}
};

Z z_;

public:

constexpr Y() noexcept: z_( this ) {}
};

int main()
{
}
```

is accepted in C++14 mode, and in C++1z mode by g++ 5 or 6, but fails in C++17
mode under g++ 7 or 8 with

```
error: temporary of non-literal type 'Y::Z' in a constant expression
```

[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

H.J. Lu  changed:

   What|Removed |Added

 CC||jwakely.gcc at gmail dot com

--- Comment #2 from H.J. Lu  ---
GCC 8 gave

 libstdc++-v3 check-abi Summary 

# of added symbols:  2
# of missing symbols:0
# of undesignated symbols:   2
# of incompatible symbols:   2

using: baseline_symbols.txt
FAIL: libstdc++-abi/abi_check

[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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #1 from H.J. Lu  ---
On i686, GCC 6 gave

    libstdc++-v3 check-abi Summary 

# of added symbols:  82
# of missing symbols:0
# of undesignated symbols:   2
# of incompatible symbols:   2

using: baseline_symbols.txt
FAIL: libstdc++-abi/abi_check

[Bug libstdc++/83834] New: [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

Bug ID: 83834
   Summary: [6/7/8 Regression] FAIL: libstdc++-abi/abi_check
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

On x86, I got

FAIL: libstdc++-abi/abi_check

[Bug libstdc++/83830] has_unique_object_representations_v is missing

[daniel.kruegler at googlemail dot com]

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

--- Comment #1 from Daniel Krügler  ---
Looks like an oversight on my side when I implemented
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0607r0.html for gcc.

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

[peter at cordes dot ca]

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

--- Comment #22 from Peter Cordes  ---
Forgot the Godbolt link with updated cmdline options:
https://godbolt.org/g/FCZAEj.

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

[peter at cordes dot ca]

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

Peter Cordes  changed:

   What|Removed |Added

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

--- Comment #21 from Peter Cordes  ---
(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).

-

Even for integer, this patch didn't fix the MOVDQA + PSRLDQ that we get without
AVX.  PSHUFD or PSHUFLW to copy+shuffle is cheaper.  I guess I need to report
that bug separately, because it probably won't get fixed soon: if I understand
correctly, there's no mechanism for the back-end to tell the auto-vectorizer
what shuffles it can do efficiently!

It usually won't make too much difference, but for very small arrays (like 8
`int` elements) the hsum is a big part of the cost, although it's probably
still worth auto-vectorizing *if* you can do it efficiently.

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

[peter at cordes dot ca]

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|RESOLVED|REOPENED
 Resolution|FIXED   |---

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

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  ---
On GCC 7 branch, I got

FAIL: gcc.target/i386/avx512vl-vpermb-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpermb-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpermi2b-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpermi2b-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpermt2b-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpermt2b-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpmaddhuq-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpmaddhuq-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpmaddluq-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpmaddluq-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpmultishiftqb-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpmultishiftqb-2.c execution test

[Bug ipa/83532] [8 Regression] ICE in apply_scale, at profile-count.h:955

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Yes, I can confirm python3-base package now builds fine.

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

[hubicka at gcc dot gnu.org]

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

--- Comment #6 from Jan Hubicka  ---
The patch fixes overfow so we no longer ICE, but we probably should try to
prevent branch prediction to predict loop to iterate so many times by special
casing very deep loop nests.

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

[hubicka at gcc dot gnu.org]

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

--- Comment #5 from Jan Hubicka  ---
Author: hubicka
Date: Sun Jan 14 11:20:31 2018
New Revision: 256659

URL: https://gcc.gnu.org/viewcvs?rev=256659=gcc=rev
Log:

PR ipa/83051
* gcc.c-torture/compile/pr83051.c: New testcase.
* ipa-inline.c (edge_badness): Tolerate roundoff errors.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr83051.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-inline.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/83833] New: chi_squared_distribution::param() forgot to change the member gamma_distribution

[rs2740 at gmail dot com]

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

Bug ID: 83833
   Summary: chi_squared_distribution::param() forgot to change the
member gamma_distribution
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

From https://stackoverflow.com/q/48248565/2756719.

The constructor initializes _M_gd with (__n / 2), but param(const param_type&)
forgot to change it:

  void
  param(const param_type& __param)
  { _M_param = __param; }

[Bug target/83832] New: [RX] Improve bittests

[olegendo at gcc dot gnu.org]

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

Bug ID: 83832
   Summary: [RX] Improve bittests
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olegendo at gcc dot gnu.org
  Target Milestone: ---
Target: rx*-*-*

If a bit test is done with only a single bit in the constant, the btst
instruction should be used to get smaller code.

When testing for constants such a 0xFF or 0x a zero_extend is emitted
followed by a compare against zero.  These 2 instructions can be folded into a
single tst instruction to improve execution speed.


These are just a few observations, probably there are more.

int bittest_0 (int x)
{
  return x & 0xFF ? 4 : 60;

  // 5b 11  movu.b  r1, r1
  // 61 01  cmp #0, r1

  // better (speed):
  // fd 78 c1 ff 00 tst #255, r1
}

int bittest_1 (int x)
{
  return x & 0x ? 4 : 60;

  // 5b 11  movu.b  r1, r1
  // 61 01  cmp #0, r1

  // better (speed):
  // fd 78 c1 ff 00 tst #255, r1
}

int bittest_2 (int x)
{
  return x & 0xFE ? 4 : 60;

  // fd 78 c1 fe 00 tst #254, r1
}

int bittest_3 (unsigned int x)
{
  return x & (1 << 1) ? 4 : 60;

  // fd 74 c1 02tst #2, r1

  // better (code size):
  // 7c 11  btst#1, r1
}

int bittest_4 (unsigned char* x)
{
  return *x & (1 << 1) ? 4 : 60;

// cc 1emov.b   [r1], r14
// fd 74 ce 02  tst #2, r14

// better (code size):
// f4 11btst#1, [r1].b
}

[Bug tree-optimization/83501] [8 Regression] strlen(a) not folded after strcpy(a, "...")

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #9 from prathamesh3492 at gcc dot gnu.org ---
Author: prathamesh3492
Date: Sun Jan 14 08:58:58 2018
New Revision: 256657

URL: https://gcc.gnu.org/viewcvs?rev=256657=gcc=rev
Log:
2018-01-14  Prathamesh Kulkarni  

PR tree-optimization/83501
* gcc.dg/strlenopt-39.c: Restrict to i?86 and x86_64-*-* targets.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/strlenopt-39.c

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

[olegendo at gcc dot gnu.org]

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

Bug ID: 83831
   Summary: [6/7/8 Regression][RX] Unused bclr,bnot,bset insns
   Product: gcc
   Version: 6.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olegendo at gcc dot gnu.org
  Target Milestone: ---
Target: rx*-*-*

These cases should be emitting the bclr, bnot, bset instructions.  They are
present in rx.md but I guess the combine pass does not catch them because of
some reasons.  I assume these patterns used to work at some point in time, so
this must be some kind of regression.  It's not working on the latest supported
branch (GCC 6) and trunk (GCC 8).


void expect_blcr (char* x)
{
  x[0] &= 0b'1110;
  x[1] &= 0b'1110;
  x[2] &= 0b'1110;
  x[65000] &= 0b'1110;
}


void expect_bnot (char* x)
{
  x[0] ^= 0b0001';
  x[1] ^= 0b0001';
  x[2] ^= 0b0001';
  x[65000] ^= 0b0001';
}


void expect_bset (char* x)
{
  x[0] |= 0b0001';
  x[1] |= 0b0001';
  x[2] |= 0b0001';
  x[65000] |= 0b0001';
}

[Bug target/80870] [7 Regression] ICE building 7.1.0 sh-elf crosscompiler on macOS

[olegendo at gcc dot gnu.org]

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

--- Comment #4 from Oleg Endo  ---
Right, thanks for checking.  Can you please try out this patch:

Index: gcc/config/sh/sh_optimize_sett_clrt.cc
===
--- gcc/config/sh/sh_optimize_sett_clrt.cc  (revision 256576)
+++ gcc/config/sh/sh_optimize_sett_clrt.cc  (working copy)
@@ -18,6 +18,8 @@
 .  */

 #include "config.h"
+#define INCLUDE_ALGORITHM
+#define INCLUDE_VECTOR
 #include "system.h"
 #include "coretypes.h"
 #include "backend.h"
@@ -27,9 +29,6 @@
 #include "cfgrtl.h"
 #include "tree-pass.h"

-#include 
-#include 
-
 /*
 This pass tries to eliminate unnecessary sett or clrt instructions in cases
 where the ccreg value is already known to be the same as the constant set