[Bug target/81616] Update -mtune=generic for the current Intel and AMD processors

[andrewm.roberts at sky dot com]

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

--- Comment #20 from Andrew Roberts  ---
Again those latest mt19937ar results above were with the current snapshot:

/usr/local/gcc/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-8.0.0/libexec/gcc/x86_64-unknown-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-8.0.0/configure --prefix=/usr/local/gcc-8.0.0
--program-suffix= --disable-werror --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --enable-gnu-indirect-function --with-isl
--enable-languages=c,c++,fortran,lto --disable-libgcj --enable-lto
--enable-multilib --with-tune=generic --with-arch_32=i686
--host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu
--disable-bootstrap
Thread model: posix
gcc version 8.0.0 20171126 (experimental) (GCC)

[Bug target/81616] Update -mtune=generic for the current Intel and AMD processors

[andrewm.roberts at sky dot com]

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

--- Comment #19 from Andrew Roberts  ---
Created attachment 42735
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42735=edit
modified mt19937ar test program, test script and results

modified mt19937ar test program, test script and results

tar -tf mt19937ar-test.tar.gz
./doit.csh   <= Test script, change path to gcc!
./mt19937ar.c<= main function altered to give test results
./mt19937ar-haswell.txt  <= full results on Intel Core i5-4570S
./mt19937ar-ryzen.txt<= full results on AMD Ryzen 7 1700 Eight-Core
Processor

[Bug target/81616] Update -mtune=generic for the current Intel and AMD processors

[andrewm.roberts at sky dot com]

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

--- Comment #18 from Andrew Roberts  ---
Ok trying an entirely different algorith, same results:

Using Mersenne Twister algorithm from here:
http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/MT2002/emt19937ar.html

alter main program to comment out original test harness, and replace
main with:

int main(void)
{
int i;
unsigned long init[4]={0x123, 0x234, 0x345, 0x456}, length=4;
init_by_array(init, length);
clock_t e, s=clock();
int j=genrand_int32();
for(i=0; i<1; i++)
{
  j ^= genrand_int32();
}
e=clock();
if (j != -549769613) printf("Error j != -549769613 (%d)\n", j);
printf("mt19937ar took %ld clocks ", (long)(e-s));
return 0;
}

So nothing complicated.
On Ryzen:


Top 5:
mt19937ar took 354877 clocks -march=amdfam10 -mtune=k8
mt19937ar took 356203 clocks -march=bdver2 -mtune=eden-x2
mt19937ar took 356534 clocks -march=nano-x2 -mtune=nano-1000
mt19937ar took 357321 clocks -march=athlon-fx -mtune=nano-x4
mt19937ar took 357634 clocks -march=bdver3 -mtune=nano-x2

Bot 5:
mt19937ar took 675052 clocks -march=nano -mtune=btver1
mt19937ar took 679826 clocks -march=k8 -mtune=nocona
mt19937ar took 681118 clocks -march=opteron -mtune=atom
mt19937ar took 689604 clocks -march=core2 -mtune=broadwell
mt19937ar took 699840 clocks -march=skylake -mtune=generic

Top -mtune=znver1
mt19937ar took 369722 clocks -march=nano-x2 -mtune=znver1

Top -march=znver1
mt19937ar took 375286 clocks -march=znver1 -mtune=silvermont

-march=znver1 -mtune=znver1 (aka native)
mt19937ar took 430875 clocks -march=znver1 -mtune=znver1

-march=haswell -mtune=haswell
mt19937ar took 402963 clocks -march=haswell -mtune=haswell

-march=k8 -mtune=k8
mt19937ar took 367890 clocks -march=k8 -mtune=k8

so -march=znver1 -mtune=znver1 is:
7% slower than tuning for haswell
17% slower than tuning for k8

Again -mtune=znver1, -mtune=bdverX, -mtune=btverX all cluster at the bottom

On Haswell:
--

Top 5:
mt19937ar took 29 clocks -march=amdfam10 -mtune=barcelona
mt19937ar took 29 clocks -march=amdfam10 -mtune=bdver1
mt19937ar took 29 clocks -march=amdfam10 -mtune=bdver2
mt19937ar took 29 clocks -march=amdfam10 -mtune=bdver3
mt19937ar took 29 clocks -march=amdfam10 -mtune=bdver4

Bot 5:
mt19937ar took 37 clocks -march=znver1 -mtune=bdver3
mt19937ar took 37 clocks -march=znver1 -mtune=bdver4
mt19937ar took 37 clocks -march=znver1 -mtune=btver2
mt19937ar took 37 clocks -march=znver1 -mtune=znver1
mt19937ar took 38 clocks -march=knl -mtune=bdver1

Top -mtune=haswell
mt19937ar took 30 clocks -march=bdver4 -mtune=haswell

Top -march=haswell
mt19937ar took 30 clocks -march=haswell -mtune=broadwell

-march=haswell -mtune=haswell (aka native)
mt19937ar took 30 clocks -march=haswell -mtune=haswell

Best performing pair:
mt19937ar took 29 clocks -march=barcelona -mtune=barcelona

so the haswell options are pretty much optimal on that hardware
 as from other test.

[Bug bootstrap/81470] [8 Regression] Bootstrap comparison failures in gcc/ada

[rai...@emrich-ebersheim.de]

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

--- Comment #8 from Rainer Emrich <rai...@emrich-ebersheim.de> ---
(In reply to Eric Botcazou from comment #7)
> And what's the output of 'gcc -v' for the base compiler?
Same gcc without ada:

$
/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-8.0.0/bin/gcc
-v
Using built-in specs.
COLLECT_GCC=D:\opt\devel\gnu\gcc\MINGW_NT\x86_64-w64-mingw32\mingw-w64-runtime-trunk-svn\gcc-8.0.0\bin\gcc.exe
COLLECT_LTO_WRAPPER=d:/opt/devel/gnu/gcc/mingw_nt/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-8.0.0/bin/../libexec/gcc/x86_64-w64-mingw32/8.0.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with:
../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-8.0.0/configure
--prefix=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-8.0.0
--with-gnu-as
--with-as=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-8.0.0/bin/as
--with-gnu-ld
--with-ld=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-8.0.0/bin/ld
--build=x86_64-w64-mingw32 --enable-threads=posix --enable-languages=c,c++,lto
--with-gmp-include=/opt/devel/SCRATCH/tmp.EwWpLRvKY3/install/include
--with-gmp-lib=/opt/devel/SCRATCH/tmp.EwWpLRvKY3/install/lib64
--with-mpfr-include=/opt/devel/SCRATCH/tmp.EwWpLRvKY3/install/include
--with-mpfr-lib=/opt/devel/SCRATCH/tmp.EwWpLRvKY3/install/lib64
--with-mpc-include=/opt/devel/SCRATCH/tmp.EwWpLRvKY3/install/include
--with-mpc-lib=/opt/devel/SCRATCH/tmp.EwWpLRvKY3/install/lib64
--with-isl-include=/opt/devel/SCRATCH/tmp.EwWpLRvKY3/install/include
--with-isl-lib=/opt/devel/SCRATCH/tmp.EwWpLRvKY3/install/lib64
--with-local-prefix=/opt/devel/tec/devel/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-8.0.0
--enable-libgomp --enable-fully-dynamic-string --disable-multilib
--enable-checking=release --disable-werror --with-sysroot=/x86_64-w64-trunk
Thread model: posix
gcc version 8.0.0 20171127 (experimental) [trunk revision 255161] (GCC)


The bootstrap compiler is:
$
/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-7.2.0/bin/gcc
-v
Using built-in specs.
COLLECT_GCC=D:\opt\devel\gnu\gcc\MINGW_NT\x86_64-w64-mingw32\mingw-w64-runtime-trunk-svn\gcc-7.2.0\bin\gcc.exe
COLLECT_LTO_WRAPPER=d:/opt/devel/gnu/gcc/mingw_nt/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-7.2.0/bin/../libexec/gcc/x86_64-w64-mingw32/7.2.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with:
../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-7.2.0/configure
--prefix=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-7.2.0
--with-gnu-as
--with-as=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-7.2.0/bin/as
--with-gnu-ld
--with-ld=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-7.2.0/bin/ld
--build=x86_64-w64-mingw32 --enable-threads=posix
--enable-languages=c,ada,c++,fortran,lto,objc,obj-c++
--with-gmp-include=/opt/devel/SCRATCH/tmp.mrT4RMFK5P/install/include
--with-gmp-lib=/opt/devel/SCRATCH/tmp.mrT4RMFK5P/install/lib64
--with-mpfr-include=/opt/devel/SCRATCH/tmp.mrT4RMFK5P/install/include
--with-mpfr-lib=/opt/devel/SCRATCH/tmp.mrT4RMFK5P/install/lib64
--with-mpc-include=/opt/devel/SCRATCH/tmp.mrT4RMFK5P/install/include
--with-mpc-lib=/opt/devel/SCRATCH/tmp.mrT4RMFK5P/install/lib64
--with-isl-include=/opt/devel/SCRATCH/tmp.mrT4RMFK5P/install/include
--with-isl-lib=/opt/devel/SCRATCH/tmp.mrT4RMFK5P/install/lib64
--with-local-prefix=/opt/devel/tec/devel/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-7.2.0
--enable-libgomp --enable-fully-dynamic-string --disable-multilib
--enable-checking=release --disable-werror --with-sysroot=/x86_64-w64-trunk
Thread model: posix
gcc version 7.2.0 (GCC)

[Bug tree-optimization/83194] New: Possibly missed simplification with strcmp(s, t) == strcmp(t, s)

[prathamesh3492 at gcc dot gnu.org]

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

Bug ID: 83194
   Summary: Possibly missed simplification with strcmp(s, t) ==
strcmp(t, s)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: prathamesh3492 at gcc dot gnu.org
  Target Milestone: ---

Hi,
FRE transforms
_1 = strcmp(s, t)
_2 = strcmp(s, t)
return _1 == _2

to:
return 1

However it does't transform if
_2 = strcmp(t, s)

I assume strcmp(s, t) == -strcmp(t, s) ?
Would it be safe to transform to following ?
_1 = strcmp (s, t)
_2 = -_1
return _1 == _2

Thanks,
Prathamesh

[Bug tree-optimization/83142] Missed tail-call opportunity

[prathamesh3492 at gcc dot gnu.org]

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

prathamesh3492 at gcc dot gnu.org changed:

   What|Removed |Added

 CC||prathamesh3492 at gcc dot 
gnu.org

--- Comment #1 from prathamesh3492 at gcc dot gnu.org ---
Hi,
I had submitted a patch for a similar case involving __builtin_memcpy:
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02485.html

IIUC, there was following issue:
Marking it as tailcall at GIMPLE won't necessarily make it a tail-call during
RTL tail-call emission. To address this issue, the patch created artificial lhs
and returned that instead for the tail-call to be in more "natural" form:

_memcpy(dest, src, n)
return dest
to
_1 = memcpy(dest, src, n)
return _1

And I think later it was concluded that this was better handled in FRE/PRE, for
which you had posted a patch:
https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00424.html

Thanks,
Prathamesh

[Bug driver/83193] Help for invalid -march= options from cc1 omits -march=native on x86-64, arm. aarch64, output also inconsistent

[andrewm.roberts at sky dot com]

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

--- Comment #1 from Andrew Roberts  ---
The same comments also apply to the -mcpu and -mtune options as well. Double
output on arm for -mcpu, and missing help for native.

also:

gcc -Q --help=target
used to document the allowable -mcpu/-mtune options, but now only documents the
allowable -mfpu/-mfpmath= options (across ARM, AARCH64 and X86-64). This was
really helpful.

And on aarch64 the -Q --help-target option doesn't properly display -march,
-mcpu -mtune, it displays -march=ARCH, -mcpu=CPU, -mtune=CPU, rather than
-march=, -mcpu=, -mtune= as other systems do.

AARCH64
/usr/local/gcc/bin/gcc -Q --help=target
The following options are target specific:
...  
  -march=ARCH   armv8-a
...
  -mcpu=CPU
...
  -mtune=CPU

ARM
/usr/local/gcc/bin/gcc -Q --help=target
The following options are target specific:
...
  -march=   armv7-a+fp
...
  -mcpu=
...
  -mtune=



X86-64
/usr/local/gcc/bin/gcc -Q --help=target
The following options are target specific:
...
  -march=   x86-64
...
  -mcpu= 
... 
  -mtune=   generic

Sorry to be so pedantic.

[Bug tree-optimization/83190] missing strlen optimization of the empty string

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
sizeof "012\0" is 5.  There are two NULs at the end, one explicit in the
initializer string and one implicitly appended by the compiler.

That the size is 5 can also be seen in the dump of g():

g ()
{
  char a[5];
  ...
}

[Bug driver/83193] New: Help for invalid -march= options from cc1 omits -march=native on x86-64, arm. aarch64, output also inconsistent

[andrewm.roberts at sky dot com]

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

Bug ID: 83193
   Summary: Help for invalid -march= options from cc1 omits
-march=native on x86-64, arm. aarch64, output also
inconsistent
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrewm.roberts at sky dot com
  Target Milestone: ---

-march=native no longer documented in cc1 help message  and the help output is
buggy and inconsistent (missing on aarch64, given twice on arm)

ON X86-64
-

The cc1 help message when invalid -march= values are passed omits "native" as
an option on x86-64. This is happening on at least 8.0 snapshots and 7.2
branch.

/usr/local/gcc/bin/gcc -march=fdsfks -E - < /dev/null
# 1 ""
cc1: error: bad value (‘fdsfks’) for ‘-march=’ switch
cc1: note: valid arguments to ‘-march=’ switch are: nocona core2 nehalem corei7
westmere sandybridge corei7-avx ivybridge core-avx-i haswell core-avx2
broadwell skylake skylake-avx512 cannonlake bonnell atom silvermont slm knl knm
x86-64 eden-x2 nano nano-1000 nano-2000 nano-3000 nano-x2 eden-x4 nano-x4 k8
k8-sse3 opteron opteron-sse3 athlon64 athlon64-sse3 athlon-fx amdfam10
barcelona bdver1 bdver2 bdver3 bdver4 znver1 btver1 btver2

/usr/local/gcc/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-8.0.0/libexec/gcc/x86_64-unknown-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-8.0.0/configure --prefix=/usr/local/gcc-8.0.0
--program-suffix= --disable-werror --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --enable-gnu-indirect-function --with-isl
--enable-languages=c,c++,fortran,lto --disable-libgcj --enable-lto
--enable-multilib --with-tune=generic --with-arch_32=i686
--host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu
--disable-bootstrap
Thread model: posix
gcc version 8.0.0 20171126 (experimental) (GCC) 

ON ARM
--

On arm native it was included in the list as of 7.x, now it is also missing,
AND THE INFO IS DISPLAYED TWICE:

/usr/local/gcc/bin/gcc -march=fdsfks -E - < /dev/null
gcc: error: unrecognized -march target: fdsfks
gcc: note: valid arguments are: armv2 armv2a armv3 armv3m armv4 armv4t armv5
armv5t armv5e armv5te armv5tej armv6 armv6j armv6k armv6z armv6kz armv6zk
armv6t2 armv6-m armv6s-m armv7 armv7-a armv7ve armv7-r armv7-m armv7e-m armv8-a
armv8.1-a armv8.2-a armv8.3-a armv8-m.base armv8-m.main armv8-r iwmmxt iwmmxt2
gcc: error: unrecognized -march target: fdsfks
gcc: note: valid arguments are: armv2 armv2a armv3 armv3m armv4 armv4t armv5
armv5t armv5e armv5te armv5tej armv6 armv6j armv6k armv6z armv6kz armv6zk
armv6t2 armv6-m armv6s-m armv7 armv7-a armv7ve armv7-r armv7-m armv7e-m armv8-a
armv8.1-a armv8.2-a armv8.3-a armv8-m.base armv8-m.main armv8-r iwmmxt iwmmxt2
gcc: error: missing argument to ‘-march=’

/usr/local/gcc/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-8.0.0/libexec/gcc/armv7l-unknown-linux-gnueabihf/8.0.0/lto-wrapper
Target: armv7l-unknown-linux-gnueabihf
Configured with: ../gcc-8.0.0/configure --prefix=/usr/local/gcc-8.0.0
--program-suffix= --disable-werror --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin
--enable-gnu-indirect-function --enable-lto --with-isl
--enable-languages=c,c++,fortran,lto --disable-libgcj --enable-clocale=gnu
--disable-libstdcxx-pch --enable-install-libiberty --disable-multilib
--disable-libssp --enable-default-pie --enable-default-ssp
--host=armv7l-unknown-linux-gnueabihf --build=armv7l-unknown-linux-gnueabihf
--with-arch=armv7-a --with-float=hard --with-fpu=vfpv3-d16 --disable-bootstrap
Thread model: posix
gcc version 8.0.0 20171126 (experimental) (GCC)

ON AARCH64
--

On aarch64 no help is given:

/usr/local/gcc/bin/gcc -march=fdsfks -E - < /dev/null
# 1 ""
cc1: error: unknown value ‘fdsfks’ for -march

/usr/local/gcc/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-8.0.0/libexec/gcc/aarch64-unknown-linux-gnu/8.0.0/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: ../gcc-8.0.0/configure --prefix=/usr/local/gcc-8.0.0
--program-suffix= --disable-werror --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu 

[Bug fortran/83192] New: ICE for printing derived type

[vivekrao4 at yahoo dot com]

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

Bug ID: 83192
   Summary: ICE for printing derived type
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vivekrao4 at yahoo dot com
  Target Milestone: ---

For GNU Fortran (GCC) 8.0.0 20170430 (experimental) on Windows 10, compiling
the code

module xyz_mod
implicit none
type, public :: bar 
   integer :: i
end type bar
contains
!
subroutine efg()
character (len=100) :: fmt_
type(bar) :: foo
foo = bar(1)
fmt_ = "(i0)"
write (*,fmt_) foo
end subroutine efg
end module xyz_mod

gives output

c:\fortran\2015>gfortran -c date_series_stats_bug.f90
f951.exe: internal compiler error: Segmentation fault
libbacktrace could not find executable to open

[Bug fortran/83191] New: Writing a namelist with repeated complex numbers

[ccyang at unlv dot edu]

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

Bug ID: 83191
   Summary: Writing a namelist with repeated complex numbers
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ccyang at unlv dot edu
  Target Milestone: ---

This is a program that generates the bug on my Mac OS 10.12.6 and 10.13.1 with
the latest MacPorts port gcc7:

program test

implicit none

integer, parameter :: UNIT = 1
character(len=8), parameter :: FILE = "namelist"

complex, dimension(3) :: a = (/ (0.0, 0.0), (0.0, 0.0), (0.0, 0.0) /)

namelist /complex_namelist/ a

open(UNIT, file=FILE)
write(UNIT, nml=complex_namelist)
close(UNIT)

open(UNIT, file=FILE)
read(UNIT, nml=complex_namelist)
close(UNIT)

end program test

It compiles without any warning, but when run, it fails at reading the newly
created namelist:

$ gfortran test.f90 -o test -Wall -Wextra
$ ./test 
At line 17 of file test.f90 (unit = 1, file = 'namelist')
Fortran runtime error: Cannot match namelist object name (0.0.)

Error termination. Backtrace:
#0  0x10320d0dc
#1  0x10320d99c
#2  0x10320dfff
#3  0x10329b03a
#4  0x1032a0b78
#5  0x1032a0d9f
#6  0x103203df8
#7  0x103203e6c
$

The problem is in the content of the namelist file:

$ cat namelist
_NAMELIST
 A= 3*(0.,0.),
 /
$

where the repeated count (3*) has a gap of blanks to the complex number that
needs to be repeated.

If I have a namelist file without that gap, it can be read in by a program
correctly.

In summary, the reading and writing of a namelist file with a repeated count is
not mutually valid.

[Bug target/81288] [6/7/8 Regression] ICE on 32-bit BE powerpc targets -w -misel -O2 (-O3, -Ofast, -Os)

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
Author: segher
Date: Tue Nov 28 01:28:57 2017
New Revision: 255188

URL: https://gcc.gnu.org/viewcvs?rev=255188=gcc=rev
Log:
rs6000: Improve comparison rtx_cost (PR81288)

The current rs6000 rtx_cost for comparisons against 0 is very high if
TARGET_ISEL && !TARGET_MFCRF, much higher than for reg-reg comparisons,
much higher than a load of 0 and such a reg-reg-comparison.  This leads
to infinite recursion in CSE (see PR81288).

This patch removes the too-high cost, also simplifying this code.


PR 81288/target
* config/rs6000/rs6000.c (rs6000_rtx_costs): Do not handle
TARGET_ISEL && !TARGET_MFCRF differently.  Simplify code.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c

[Bug tree-optimization/83190] missing strlen optimization of the empty string

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Isn't the sizeof a, 4?
If so the call to strlen in g is undefined.

[Bug tree-optimization/83190] missing strlen optimization of the empty string

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #1 from Martin Sebor  ---
Clang emits optimal code for both functions.

[Bug tree-optimization/83190] New: missing strlen optimization of the empty string

[msebor at gcc dot gnu.org]

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

Bug ID: 83190
   Summary: missing strlen optimization of the empty string
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The tree-ssa-strlen pass keeps track of the lengths of strings as they are
created, including by initialization of local arrays.  As a result, it is able
to determine that the result of the strlen() call in function f() below is 0
and perform this substitution.  But the pass misses that the same is true in
function g(), and so it unnecessarily emits a call to strlen() there.  It
should be possible to enhance the pass to handle this case as well and perform
the same transformation in both cases.

$ cat a.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout a.c
int f (void)
{
  char a[] = "012\0";

  return __builtin_strlen (a + 3);   // folded into 0
}

int g (void)
{
  char a[] = "012\0";

  return __builtin_strlen (a + 4);   // not folded
}

;; Function f (f, funcdef_no=0, decl_uid=1892, cgraph_uid=0, symbol_order=0)

f ()
{
   [local count: 1073741825]:
  return 0;

}



;; Function g (g, funcdef_no=1, decl_uid=1896, cgraph_uid=1, symbol_order=1)

g ()
{
  char a[5];
  long unsigned int _1;
  int _4;

   [local count: 1073741825]:
  a = "012";
  _1 = __builtin_strlen ([(void *) + 4B]);
  _4 = (int) _1;
  a ={v} {CLOBBER};
  return _4;

}

[Bug c++/83058] [6/7/8 Regression] ICE on C++ code with negative array index: in warn_placement_new_too_small, at cp/init.c:2666

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
Fixed in r255182.

[Bug c++/83058] [6/7/8 Regression] ICE on C++ code with negative array index: in warn_placement_new_too_small, at cp/init.c:2666

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Author: msebor
Date: Tue Nov 28 00:02:17 2017
New Revision: 255182

URL: https://gcc.gnu.org/viewcvs?rev=255182=gcc=rev
Log:
PR c++/83058 - ICE on C++ code with negative array index: in
warn_placement_new_too_small

gcc/cp/ChangeLog:

PR c++/83058
* init.c (warn_placement_new_too_small): Use offset_int instead of
HOST_WIDE_INT.

gcc/testsuite/ChangeLog:

PR c++/83058
* g++.dg/warn/Wplacement-new-size-5.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/warn/Wplacement-new-size-5.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/83189] New: [8 regression] internal compiler error: in probability_in, at profile-count.h:1050

[skpgkp1 at gmail dot com]

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

Bug ID: 83189
   Summary: [8 regression] internal compiler error: in
probability_in, at profile-count.h:1050
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skpgkp1 at gmail dot com
  Target Milestone: ---

This issue appear in GCC 8 espresso build. GCC 7 works fine. Following are
steps to reproduce.

$cat radin_mod.f90
Module radin_mod
  INTEGER, PARAMETER :: DP = selected_real_kind(14,200)
Contains
  Subroutine SPLIFT (X,Y,YP,YPP,N,IERR,ISX,A1,B1,AN,BN)
Integer,  Intent(in) :: N,ISX
Real(dp), Intent(in) :: X(N),Y(N),A1,B1,AN,BN
Real(dp), Intent(out) :: YP(N),YPP(N)
Real(dp), Allocatable, Dimension(:,:) :: W
NM1  = N-1
NM2  = N-2
If (ISX.Gt.0) GO TO 40
Do I=2,N
   If (X(I)-X(I-1) .Le. 0) Then
  IERR = 3
  Return
   Endif
End Do
Allocate(W(N,3))
40  YPP(1) = 4*B1
DOLD = (Y(2)-Y(1))/W(2,2)
Do  I=2,NM2
   DNEW   = (Y(I+1) - Y(I))/W(I+1,2)
   YPP(I) = 6*(DNEW - DOLD)
   YP(I)  = DOLD
   DOLD = DNEW
End Do
Return
  End Subroutine SPLIFT
End Module radin_mod

$gfortran --version
GNU Fortran (GCC) 8.0.0 20171127 (experimental)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$gfortran -O3 -x f95-cpp-input -c radin_mod.f90
during GIMPLE pass: pcom
radin_mod.f90:4:0:

   Subroutine SPLIFT (X,Y,YP,YPP,N,IERR,ISX,A1,B1,AN,BN)

internal compiler error: in probability_in, at profile-count.h:1050
0x6ed972 profile_count::probability_in(profile_count) const
../../gcc-main.3O1J/gcc/profile-count.h:1050
0x6ed972 tree_transform_and_unroll_loop(loop*, unsigned int, edge_def*,
tree_niter_desc*, void (*)(loop*, void*), void*)
../../gcc-main.3O1J/gcc/tree-ssa-loop-manip.c:1382
0xe16b26 tree_predictive_commoning_loop
../../gcc-main.3O1J/gcc/tree-predcom.c:3274
0xe182b0 tree_predictive_commoning()
../../gcc-main.3O1J/gcc/tree-predcom.c:3308
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.


### Work fine with GCC 7

$gfortran --version
GNU Fortran (GCC) 7.2.1 20171127
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$gfortran -O3 -x f95-cpp-input -c radin_mod.f90
$echo $?
0

[Bug ipa/83179] [8 regression] gcc.dg/ipa/inline-1.c fail

[jamborm at gcc dot gnu.org]

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

--- Comment #7 from Martin Jambor  ---
(In reply to Andrey Guskov from comment #6)
> Simple. Those fails are due to the same revision.

I see, I have missed the very first line in your bug description and
then wondered whether that was the case.  The vectorizer issue looks
different but of course it makes sense to keep these together until we
know otherwise.

[Bug bootstrap/83163] bootstrap comparison failure with --enable-languages=all,jit

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #3 from Martin Sebor  ---
I've tried various permutations of --enable-languages= arguments but I'm not
able to reproduce the failure anymore, not even with all,jit.  It must have
been a some fluke or pilot error.  Resolving as WorksForSome.

[Bug c/83117] [8 Regression] FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c (test for excess errors)

[daniel.santos at pobox dot com]

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

Daniel Santos  changed:

   What|Removed |Added

 CC||daniel.santos at pobox dot com

--- Comment #8 from Daniel Santos  ---
(In reply to Jakub Jelinek from comment #6)
> The warning is nothing new, GCC has been warning for that for years.  What
> my patch did is just better optimization, so the compiler can see the UB.
> 
> Try:
> extern long do_test_aligned ();
> 
> static long (*const do_test_v1) (long a, ...) = (void *) do_test_aligned;
> 
> extern void check_results (long);
> 
> int test (long a)
> {
>   long ret;
> 
>   ret = do_test_v1 (a);
>   ret += (long (*) (long a, ...)) do_test_aligned;
>   check_results (ret);
> }
> 
> We've warned about the latter, but not the former, since we weren't able to
> fold a const var to its initializer.
> 
> So, either the tests shouldn't use const on these, something like:
> -  out << "static __attribute__ ((ms_abi)) long (*const do_test_"
> +  out << "static __attribute__ ((ms_abi)) long (*do_test_"
> or they should use const volatile, or -w, or should use proper prototypes.
> 
> Daniel needs to decide what to do, it isn't obviously clear what the intent
> is.

Sorry for my slow response.  do_test and do_test_aligned are assembly hacks
that verify that the actual test functions do not alter registers that are
volatile for sysv_abi, but non-volatile for ms_abi (the ms to sysv clobbers). 
So the intention was to lie to the compiler about how to call the function, but
now your patch got smart and figured out that I was lying. :(

So in this example, the function msabi_00_v1 is the real function that is being
tested:

  init_test (msabi_00_v1, "msabi_00_v1", ALIGNMENT_NOT_TESTED,
SHRINK_WRAP_NONE, a);
  ret = do_test_v1 (a);
  check_results (ret);

More specifically, the assembly proxy stubs:
1. store rdi, rsi, xmm6-15,
2. populates them with random data
3. pops the return address and stores it
4. calls the function specified in the init_test call prior
upon return it:
5. stores the new values of rdi, rsi xmm6-15 (for later comparison)
6. restores them to what they were originally
7. jumps to the original return address

The test program is a single-threaded and there is no recursion of of these
hacked calls, so I'm just using globals.

Is there a way to disable this warning with -Wno-xxx?  Otherwise, what is the
proper way to lie to a compiler?  I want the compiler to construct the function
call since that is part of what is being tested.

[Bug ada/83188] New: A class-wide type is considered different than itself

[porton at narod dot ru]

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

Bug ID: 83188
   Summary: A class-wide type is considered different than itself
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: porton at narod dot ru
  Target Milestone: ---

Created attachment 42734
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42734=edit
a valid program which does not compile

The attached valid program (run `gnatchop script.all`) does not compile.

Weirdly enough, it compiles if I add `subtype X is Script_Info'Class;` in the
beginning of Resource.Parser package and replace all occurrences of
Script_Info'Class in resource-parser.ads and resource-parser.adb with `X`.

$ gcc --version
gcc (Debian 7.2.0-16) 7.2.0

$ make
gprbuild -p main.gpr
Compile
   [Ada]  resource-parser.adb
resource-parser.ads:10:24: not subtype conformant with operation inherited at
line 7
resource-parser.ads:10:24: return type does not match

[Bug other/83182] undefined behavior in generic_wide_int due to missing input validation

[rsandifo at gcc dot gnu.org]

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

--- Comment #1 from rsandifo at gcc dot gnu.org  
---
wi::to_offset does check for an INTEGER_CST, via the tree.h accessor macros. 
Are you sure you have a normal --enable-checking=yes build?  I get:

cc1: internal compiler error: tree check: expected integer_cst, have
trunc_div_expr in get_len, at tree.h:5315

with the quoted example.

But yeah, I've certainly no objection in principle to extra
gcc_checking_asserts in wide-int.h itself.

[Bug c++/81888] [7 Regression] Structured bindings stopped working

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[7/8 Regression] Structured |[7 Regression] Structured
   |bindings stopped working|bindings stopped working

--- Comment #5 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug c++/81888] [7/8 Regression] Structured bindings stopped working

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Mon Nov 27 21:54:25 2017
New Revision: 255180

URL: https://gcc.gnu.org/viewcvs?rev=255180=gcc=rev
Log:
PR c++/81888
* parser.c (cp_parser_decomposition_declaration): Reject just
BRACE_ENCLOSED_INITIALIZER_P initializers with nelts != 1 rather
than all such CONSTRUCTORs, and only if is_direct_init is true.

* g++.dg/cpp1z/decomp30.C: Add a test for structured binding with
= {} and = { a, a } initializers.
* g++.dg/cpp1z/decomp31.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/decomp31.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp1z/decomp30.C

[Bug c/83139] error: null destination pointer [-Werror=format-truncation=] for second call with same destination pointer

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #3 from Martin Sebor  ---
A reduced test case showing the IL the checker sees is below.  Your analysis is
correct.  The checker determines that the call to snprintf takes place when the
destination pointer is null and so issues a warning.  The call can also be made
when the destination pointer isn't null, so arguably the checker could walk up
the CFG to try to distinguish these two cases and issue a "destination pointer
may be null" kind of a warning to make it clear that the call may but need not
be safe.  But I think the warning is useful regardless of how it's phrased so
I'll go ahead and resolve this report as invalid.

$ cat c.c && gcc -O2 -S -Wall -fdump-tree-printf-return-value=/dev/stdout c.c
 /ssd/build/gcc-svn/gcc/xgcc -B /ssd/build/gcc-svn/gcc -O2 -S -Wall
-fdump-tree-printf-return-value=/dev/stdout c.c

;; Function get_config_path (get_config_path, funcdef_no=1, decl_uid=1897,
cgraph_uid=1, symbol_order=1)

c.c:13: __builtin_snprintf: objsize = 4294967295, fmtstr = "abc"
  Directive 1 at offset 0: "abc", length = 3
Result: 3, 3, 3, 3 (3, 3, 3, 3)
  Directive 2 at offset 3: "", length = 1
  Substituting 3 for return value.

c.c: In function ‘get_config_path’:
c.c:20:2: warning: null destination pointer [-Wformat-truncation=]
  __builtin_snprintf (pbuf, bufsize, "def");
  ^
c.c:20: __builtin_snprintf: objsize = 4294967295, fmtstr = "def"
  Directive 1 at offset 0: "def", length = 3
Result: 3, 3, 3, 3 (3, 3, 3, 3)
  Directive 2 at offset 3: "", length = 1
  Substituting 3 for return value.

get_config_path (char * default_path, char * pbuf, unsigned int bufsize)
{
  long unsigned int _1;
  char * _2;
  char _10;
  char _11;
  char _12;

   [local count: 1073741825]:
  if (default_path_4(D) != 0B)
goto ; [70.00%]
  else
goto ; [30.00%]

   [local count: 751619277]:
  _10 = *default_path_4(D);
  if (_10 != 0)
goto ; [34.00%]
  else
goto ; [66.00%]

   [local count: 818191271]:
  _1 = (long unsigned int) bufsize_6(D);
  __builtin_snprintf (pbuf_7(D), _1, "abc");
  if (pbuf_7(D) != 0B)
goto ; [70.00%]
  else
goto ; [30.00%]

   [local count: 572733889]:
  _11 = *pbuf_7(D);
  if (_11 != 0)
goto ; [34.00%]
  else
goto ; [66.00%]

   [local count: 560844966]:

   [local count: 1073741823]:
  # _2 = PHI <0B(9), default_path_4(D)(3), pbuf_7(D)(6), 0B(8)>
  return _2;

   [local count: 436423223]:
  __builtin_snprintf (pbuf_7(D), _1, "def");
  _12 = *pbuf_7(D);
  if (_12 != 0)
goto ; [83.89%]
  else
goto ; [16.11%]

   [local count: 187038523]:
  __builtin_snprintf (0B, _1, "def");
  goto ; [100.00%]

}

[Bug c/83172] -Wstack-size= doesn't detect the correct stack size with VLA or alloca

[hao.hou at utah dot edu]

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

--- Comment #4 from Hao Hou  ---
(In reply to Eric Botcazou from comment #3)
> > The same result:
> > 
> > $ gcc-7 -Wvla-larger-than=128 -Wstack-usage=102400 -O0 -c t.c 
> > t.c: In function ‘stack_usage_only’:
> > t.c:23:5: warning: stack usage might be unbounded [-Wstack-usage=]
> >  int stack_usage_only(unsigned x)
> >  ^~~~
> > t.c: In function ‘alloca_fails_even_with_const’:
> > t.c:32:5: warning: stack usage might be unbounded [-Wstack-usage=]
> >  int alloca_fails_even_with_const()
> >  ^~~~
> > 
> > -O1 results the same.
> 
> Try -Wvla-larger-than=100 though.
> 
> In any case, note that for:
> 
> int vla_size_only(unsigned x)
> {
>  if(x > 128) __builtin_unreachable();
>  char buf[x];
>  do_something(buf);
>  return 0;
> }
> 
> the warning is expected since the code may allocate more than 128 bytes.
> 
> -Wstack-usage is designed to be *conservatively* correct and to yield the
> same result at all optimization levels, i.e. it will never say that the
> stack usage is bounded if there is a path where it may not be.  So it's very
> different from 
> -Wvla-larger-than or -Walloca-larger-than which say nothing at -O0 or -O1
> and are not conservatively correct.

Thanks Eric, that's a good point. I understand that eventhough the behavior of
the code when x > 128 is undefined, but it's up to the compiler if take this
case into consideration. 

I tried to modify the code a little bit: 

int stack_usage_only(unsigned x)
{
if(x <= 128)
{
if(x > 128) __builtin_unreachable();
char buf[x];
do_something(buf);
}
return 0;
}


The warning is stil there. I totally understand that the compiler infers the
size conservatively. But this case makes -Wstack-size= somehow equivalent to
-Wvla.

My idea on this warning is that it actually make much more sense when the VLA
or alloca has been used in the code, since it preventing VLA or alloca
allocating unbounded size of memory. That is why I was expecting it actually
infers the range of the x, thus it's an useful indicator of using VLA
correctly.

[Bug ipa/83179] [8 regression] gcc.dg/ipa/inline-1.c fail

[andrey.y.guskov at intel dot com]

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

--- Comment #6 from Andrey Guskov  ---
Simple. Those fails are due to the same revision.

I decided not to create a truckload of separate bugs (there`s also a chance
that there are more cases to come, as 3 CPU2006 regressions are still not done
being bisected) because everything being in one place lowers the chance that
Honza accidentally misses one while fixing the others.

Is my logic flawed?

[Bug c/83180] MINGW: Linking to libpq.dll produced with MSVC-x64 generates invalid code

[l...@greiz-reinsdorf.de]

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

Lars Kanis  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED

--- Comment #3 from Lars Kanis  ---
Thank you Andrew! I posted this issue on
https://sourceware.org/bugzilla/show_bug.cgi?id=22504

[Bug c++/69638] array out of bounds access accepted in constexpr function invocation

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
  Known to work||7.2.0, 8.0
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=77830
 Resolution|--- |FIXED
  Known to fail|6.0 |6.2.0

--- Comment #3 from Martin Sebor  ---
Bisection shows this bug was fixed in r243873 (GCC 7.0.0) committed to fix
pr77830.

[Bug c++/83187] New: [8 regression] internal compiler error: in get_alias_set, at alias.c:923

[skpgkp1 at gmail dot com]

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

Bug ID: 83187
   Summary: [8 regression] internal compiler error: in
get_alias_set, at alias.c:923
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skpgkp1 at gmail dot com
  Target Milestone: ---

This issue appear in GCC 8. GCC 7 works fine. Following are steps to reproduce.

$cat OFDM.i.cpp
extern "C" {
double cos(double);
double sin(double);
}
template  class a;
template <> struct a {
  typedef __complex__ b;
  a(double c, double p2) : k{c, p2} {}
  b k;
};
typedef double d;
d e;
class f {
  a g;
  void h();
};
void f::h() {
  const d i = e;
  g = a(cos(e), sin(e));
}

$g++ --version
g++ (GCC) 8.0.0 20171127 (experimental)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$g++  -O1 -c -o OFDM.i.cpp.o OFDM.i.cpp
during RTL pass: expand
OFDM.i.cpp: In member function ‘void f::h()’:
OFDM.i.cpp:19:5: internal compiler error: in get_alias_set, at alias.c:923
   g = a(cos(e), sin(e));
   ~~^~
0x6653a7 get_alias_set(tree_node*)
../../gcc-main.3O1J/gcc/alias.c:923
0xb2dc4e component_uses_parent_alias_set_from(tree_node const*)
../../gcc-main.3O1J/gcc/alias.c:657
0xc38693 set_mem_attributes_minus_bitpos(rtx_def*, tree_node*, int, long)
../../gcc-main.3O1J/gcc/emit-rtl.c:1920
0xc7185d expand_assignment(tree_node*, tree_node*, bool)
../../gcc-main.3O1J/gcc/expr.c:5181
0xb6a2f8 expand_gimple_stmt_1
../../gcc-main.3O1J/gcc/cfgexpand.c:3675
0xb6a2f8 expand_gimple_stmt
../../gcc-main.3O1J/gcc/cfgexpand.c:3773
0xb6b637 expand_gimple_basic_block
../../gcc-main.3O1J/gcc/cfgexpand.c:5772
0xb704c6 execute
../../gcc-main.3O1J/gcc/cfgexpand.c:6373
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.

### GCC 7 works fine.

$g++ --version
g++ (GCC) 7.2.1 20171127
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$g++  -O1 -c -o OFDM.i.cpp.o OFDM.i.cpp
$echo $?
0

[Bug rtl-optimization/80818] LRA clobbers live hard reg clobbered during rematerialization

[vmakarov at gcc dot gnu.org]

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

--- Comment #9 from Vladimir Makarov  ---
(In reply to Andreas Krebbel from comment #8)
> Hi Vladimir. What do you think about the additional patch?

Andreas, sorry for the delay with the answer.  The patch looks reasonable for
me.  If your additional patch works for you we could try to incorporate it into
my patch.  I'll do it and test the new patch and, if everything is ok, I'll
commit it tomorrow or on Wednesday.

[Bug c++/80916] Spurious "declared 'static' but never defined" warning

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-27
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||7.2.0, 8.0

--- Comment #2 from Martin Sebor  ---
Confirmed with GCC 8.0.

[Bug c++/70834] Incorrect warning for placement new when conditionally used

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail||6.4.0, 7.2.0, 8.0

--- Comment #6 from Martin Sebor  ---
No change in 8.0.

[Bug c/83172] -Wstack-size= doesn't detect the correct stack size with VLA or alloca

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #3 from Eric Botcazou  ---
> The same result:
> 
> $ gcc-7 -Wvla-larger-than=128 -Wstack-usage=102400 -O0 -c t.c 
> t.c: In function ‘stack_usage_only’:
> t.c:23:5: warning: stack usage might be unbounded [-Wstack-usage=]
>  int stack_usage_only(unsigned x)
>  ^~~~
> t.c: In function ‘alloca_fails_even_with_const’:
> t.c:32:5: warning: stack usage might be unbounded [-Wstack-usage=]
>  int alloca_fails_even_with_const()
>  ^~~~
> 
> -O1 results the same.

Try -Wvla-larger-than=100 though.

In any case, note that for:

int vla_size_only(unsigned x)
{
 if(x > 128) __builtin_unreachable();
 char buf[x];
 do_something(buf);
 return 0;
}

the warning is expected since the code may allocate more than 128 bytes.

-Wstack-usage is designed to be *conservatively* correct and to yield the same
result at all optimization levels, i.e. it will never say that the stack usage
is bounded if there is a path where it may not be.  So it's very different from 
-Wvla-larger-than or -Walloca-larger-than which say nothing at -O0 or -O1 and
are not conservatively correct.

[Bug c++/45975] template keyword is not allowed, however, accepted by g++

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 CC||msebor at gcc dot gnu.org
  Known to fail||4.5.4, 4.8.3, 4.9.3, 5.3.0,
   ||6.2.0, 7.1.0, 8.0

--- Comment #1 from Martin Sebor  ---
The invalid code is still accepted by GCC 8.0/

[Bug tree-optimization/83055] [8 Regression] ICE in operator>, at profile-count.h:834

[skpgkp1 at gmail dot com]

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

Sunil Pandey  changed:

   What|Removed |Added

 CC||skpgkp1 at gmail dot com

--- Comment #1 from Sunil Pandey  ---
This bug also appear during Linux kernel build from LFS with GCC 8. Work fine
with GCC 7.

$cat main.i.c
void __attribute__((__cold__)) a(void);
void b(void);
__attribute__((noinline)) c(void) { a(); }
d(void) {
  b();
  c();
}

$gcc --version
gcc (GCC) 8.0.0 20171127 (experimental)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$gcc   -Os  -fprofile-arcs -c -o main.i.c.o main.i.c -w
during IPA pass: profile
main.i.c:7:1: internal compiler error: in operator>, at profile-count.h:834
 }
 ^
0x66a5a5 profile_count::operator>(long) const
../../gcc-main.3O1J/gcc/profile-count.h:834
0x66a5a5 handle_missing_profiles()
../../gcc-main.3O1J/gcc/predict.c:3289
0xdc63fd tree_profiling
../../gcc-main.3O1J/gcc/tree-profile.c:750
0xdc63fd execute
../../gcc-main.3O1J/gcc/tree-profile.c:780
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.

[Bug middle-end/82333] [8 Regression] powerpc64le _Float128 ICE in as_a, at machmode.h:345

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #6 from Michael Meissner  ---
Fixed in subversion id 255177.

[Bug c++/83058] [6/7/8 Regression] ICE on C++ code with negative array index: in warn_placement_new_too_small, at cp/init.c:2666

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2017-11/msg02324.html

[Bug fortran/83076] [8 Regression] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1598

[pault at gcc dot gnu.org]

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

--- Comment #6 from Paul Thomas  ---
Created attachment 42733
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42733=edit
A partial fix for the PR

This fixes the testcase and, indeed, some more elaborate versions. However,
coarray_allocate_5.f08 with the type 'foo' declared in a module offends gimple
horribly. It appears that the vtable is completely screwed up such that
accessing 'copy' gets 'def_init' instead.

That said, this does at least regtest OK.

Paul

[Bug c++/83186] New: [8 regression] internal compiler error: in build_address, at cp/typeck.c:5667

[skpgkp1 at gmail dot com]

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

Bug ID: 83186
   Summary: [8 regression] internal compiler error: in
build_address, at cp/typeck.c:5667
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skpgkp1 at gmail dot com
  Target Milestone: ---

It appear with webtoolkit application(wt) build with GCC8. It works fine with
GCC7.2.1. Following are steps to reproduce.

$ cat WDate.i.C
class a {
  operator unsigned();
};
template  void b() { static_cast(a{}); }

$g++ --version
g++ (GCC) 8.0.0 20171127 (experimental)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$g++  -O0  -o WDate.i.C.o -c WDate.i.C
WDate.i.C: In function ‘void b()’:
WDate.i.C:4:54: internal compiler error: in build_address, at cp/typeck.c:5667
 template  void b() { static_cast(a{}); }
  ^
0x63fed3 build_address(tree_node*)
../../gcc-main.3O1J/gcc/cp/typeck.c:5667
0x8e4ce5 add_function_candidate
../../gcc-main.3O1J/gcc/cp/call.c:2158
0x8e5eff add_candidates
../../gcc-main.3O1J/gcc/cp/call.c:5514
0x8e207e add_candidates
../../gcc-main.3O1J/gcc/cp/call.c:5425
0x8e207e build_user_type_conversion_1
../../gcc-main.3O1J/gcc/cp/call.c:3841
0x8e34a9 implicit_conversion
../../gcc-main.3O1J/gcc/cp/call.c:1889
0x8e8295 perform_direct_initialization_if_possible(tree_node*, tree_node*,
bool, int)
../../gcc-main.3O1J/gcc/cp/call.c:10635
0xa9ed67 build_static_cast_1
../../gcc-main.3O1J/gcc/cp/typeck.c:6959
0xa9f9a4 build_static_cast(tree_node*, tree_node*, int)
../../gcc-main.3O1J/gcc/cp/typeck.c:7141
0x9eebb0 cp_parser_postfix_expression
../../gcc-main.3O1J/gcc/cp/parser.c:6698
0x9f10fa cp_parser_unary_expression
../../gcc-main.3O1J/gcc/cp/parser.c:8365
0x9d295f cp_parser_cast_expression
../../gcc-main.3O1J/gcc/cp/parser.c:9133
0x9d3147 cp_parser_binary_expression
../../gcc-main.3O1J/gcc/cp/parser.c:9234
0x9d4ad4 cp_parser_assignment_expression
../../gcc-main.3O1J/gcc/cp/parser.c:9521
0x9d51ba cp_parser_expression
../../gcc-main.3O1J/gcc/cp/parser.c:9690
0x9d6e98 cp_parser_expression_statement
../../gcc-main.3O1J/gcc/cp/parser.c:11208
0x9dcb16 cp_parser_statement
../../gcc-main.3O1J/gcc/cp/parser.c:11024
0x9dda50 cp_parser_statement_seq_opt
../../gcc-main.3O1J/gcc/cp/parser.c:11351
0x9ddb27 cp_parser_compound_statement
../../gcc-main.3O1J/gcc/cp/parser.c:11305
0x9f49f0 cp_parser_function_body
../../gcc-main.3O1J/gcc/cp/parser.c:21841
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.

## Work fine with GCC 7.

$g++ --version
g++ (GCC) 7.2.1 20171127
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$g++  -O0  -o WDate.i.C.o -c WDate.i.C
$echo $?
0

[Bug middle-end/83069] [8 Regression] internal compiler error: in from_gcov_type, at profile-count.h:676

[skpgkp1 at gmail dot com]

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

Sunil Pandey  changed:

   What|Removed |Added

 CC||skpgkp1 at gmail dot com

--- Comment #10 from Sunil Pandey  ---
Seems like I hit the same bug while compiling mariadb with GCC8.

$cat CMap.i.cc
void a() {
  int b = 0;
  for (; b < 256; ++b)
a();
}

$g++ --version
g++ (GCC) 8.0.0 20171127 (experimental)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$g++ -O3  -o CMap.i.cc.o -c CMap.i.cc
during IPA pass: inline
CMap.i.cc: In function ‘void a()’:
CMap.i.cc:1:6: internal compiler error: in from_gcov_type, at
profile-count.h:676
 void a() {
  ^
0x712c42 estimate_bb_frequencies(bool)
../../gcc-main.3O1J/gcc/profile-count.h:676
0xe73137 rebuild_frequencies()
../../gcc-main.3O1J/gcc/predict.c:3911
0xe59904 execute_function_todo
../../gcc-main.3O1J/gcc/passes.c:1975
0xe5a28e execute_todo
../../gcc-main.3O1J/gcc/passes.c:2048
0x70fc43 execute_one_ipa_transform_pass
../../gcc-main.3O1J/gcc/passes.c:2245
0x70fc43 execute_all_ipa_transforms()
../../gcc-main.3O1J/gcc/passes.c:2281
0xba1a8a cgraph_node::expand()
../../gcc-main.3O1J/gcc/cgraphunit.c:2132
0xba2cab expand_all_functions
../../gcc-main.3O1J/gcc/cgraphunit.c:2275
0xba2cab symbol_table::compile()
../../gcc-main.3O1J/gcc/cgraphunit.c:2623
0xba4fc9 symbol_table::compile()
../../gcc-main.3O1J/gcc/cgraphunit.c:2537
0xba4fc9 symbol_table::finalize_compilation_unit()
../../gcc-main.3O1J/gcc/cgraphunit.c:2716
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.

[Bug c++/83170] ice in verify_use with -O3

[skpgkp1 at gmail dot com]

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

Sunil Pandey  changed:

   What|Removed |Added

 CC||skpgkp1 at gmail dot com

--- Comment #3 from Sunil Pandey  ---
Seems like I hit the same bug with following test case. It appear during
GCompris and mednafen application build with GCC8.

$cat book.i.c
a;
char b[8];
c() {
  int d = 0;
  for (; d < 2; d++) {
b[d] = 5;
b[4 + d] = a >> d * 8;
  }
}

$gcc --version
gcc (GCC) 8.0.0 20171126 (experimental)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$gcc -O2  -c -o book.i.c.o book.i.c -w
during GIMPLE pass: store-merging
book.i.c: In function ‘c’:
book.i.c:3:1: internal compiler error: Segmentation fault
 c() {
 ^
0xd1e4ff crash_signal
../../gcc-main.3O1I/gcc/toplev.c:325
0x7713a71f ???
   
/usr/src/debug/glibc-2.26-65-ga76376df7c/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0xebac4b verify_use
../../gcc-main.3O1I/gcc/tree-ssa.c:864
0x72478b verify_ssa(bool, bool)
../../gcc-main.3O1I/gcc/tree-ssa.c:1141
0xc50eed execute_function_todo
../../gcc-main.3O1I/gcc/passes.c:2001
0xc5184e execute_todo
../../gcc-main.3O1I/gcc/passes.c:2048
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/83183] Out of memory with option -finit-derived

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-27
 CC||foreese at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
I get an ICE

gfortran: internal compiler error: Segmentation fault: 11 (program f951)

with both 7.2.0 and trunk (8.0).

[Bug ipa/83179] [8 regression] gcc.dg/ipa/inline-1.c fail

[jamborm at gcc dot gnu.org]

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

--- Comment #5 from Martin Jambor  ---
Andrey, what makes you think that the g++.dg/pr79095-4.C and regex.c
issues are related to dump scan failure of ipa/inline-1.c?

[Bug fortran/83184] Out of memory or ICE with option -fdec

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-27
 CC||foreese at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed on 6.4.0, 7.2.0, and trunk (8.0), configured with/without
--enable-checking=yes.

[Bug tree-optimization/46186] Clang creates code running 1600 times faster than gcc's

[hiraditya at msn dot com]

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

AK  changed:

   What|Removed |Added

 CC||hiraditya at msn dot com

--- Comment #27 from AK  ---
Seems PR65855 is related to this. btw, it may be worthwhile to try the patch
posted by Sebastian https://gcc.gnu.org/bugzilla/attachment.cgi?id=22201

[Bug c/83180] MINGW: Linking to libpq.dll produced with MSVC-x64 generates invalid code

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
I suspect this is a binutils bug and should be reported to them
(https://sourceware.org/bugzilla/ ).

[Bug rtl-optimization/81020] [6/7/8 Regression] wrong code with -O -fno-tree-bit-ccp -fno-tree-coalesce-vars -fno-tree-vrp

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
This was fixed with r254875.  Before that combine was throwing away the masking
by 1 and testing against 0, effectively replacing the
  u32_1 &= 1;
  u32_0 |= 0 < u32_1;
with
  u32_0 |= u32_1;
I'll add the testcase and close.

[Bug c/83172] -Wstack-size= doesn't detect the correct stack size with VLA or alloca

[hao.hou at utah dot edu]

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

--- Comment #2 from Hao Hou  ---
(In reply to Eric Botcazou from comment #1)
> What happens for -Wvla-larger-than= if you use -O0 or -O1 instead of -O3?

The same result:

$ gcc-7 -Wvla-larger-than=128 -Wstack-usage=102400 -O0 -c t.c 
t.c: In function ‘stack_usage_only’:
t.c:23:5: warning: stack usage might be unbounded [-Wstack-usage=]
 int stack_usage_only(unsigned x)
 ^~~~
t.c: In function ‘alloca_fails_even_with_const’:
t.c:32:5: warning: stack usage might be unbounded [-Wstack-usage=]
 int alloca_fails_even_with_const()
 ^~~~

-O1 results the same.

[Bug middle-end/83069] [8 Regression] internal compiler error: in from_gcov_type, at profile-count.h:676

[sudi.das at arm dot com]

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

Sudakshina Das  changed:

   What|Removed |Added

 CC||sudi.das at arm dot com

--- Comment #9 from Sudakshina Das  ---
Confirmed on aarch64-none-linux-gnu

[Bug c++/82336] [6/7/8 Regression] GCC requires but does not emit defaulted constructors in certain cases

[nathan at gcc dot gnu.org]

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

--- Comment #3 from Nathan Sidwell  ---
When checking the default arg during parsing, we perform an implicit conversion
inside an unevaluated_operand context.  That's needed to fix 54198, where an
ill-formed instantiation occurs otherwise.  

However, here, that implicit conversion is altering arg itself, via
reshape_init, and we lose an enclosing target_expr.

[Bug c/83185] New: ICE with -fsanitize=address in build_simple_mem_ref_loc, at tree.c:4696

[gs...@t-online.de]

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

Bug ID: 83185
   Summary: ICE with -fsanitize=address in
build_simple_mem_ref_loc, at tree.c:4696
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With option -fsanitize=address and -Os|1+ :

$ cat z1.c
#include 

void
f (int i, ...)
{
  va_list aps[g()];
  va_start (aps[4], i);
}


$ gcc-8-20171126 -c z1.c -O2 -fsanitize=address
z1.c: In function 'f':
z1.c:6:15: warning: implicit declaration of function 'g'
[-Wimplicit-function-declaration]
   va_list aps[g()];
   ^
during RTL pass: expand
In file included from z1.c:1:
z1.c:7:3: internal compiler error: in build_simple_mem_ref_loc, at tree.c:4696
   va_start (aps[4], i);
   ^~~~
0xd037df build_simple_mem_ref_loc(unsigned int, tree_node*)
../../gcc/tree.c:4696
0xd78a55 ix86_va_start
../../gcc/config/i386/i386.c:9803
0x72f443 expand_builtin_va_start
../../gcc/builtins.c:4819
0x72f443 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
../../gcc/builtins.c:7115
0x8352d8 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:10851
0x749f8c expand_expr
../../gcc/expr.h:276
0x749f8c expand_call_stmt
../../gcc/cfgexpand.c:2673
0x749f8c expand_gimple_stmt_1
../../gcc/cfgexpand.c:3607
0x749f8c expand_gimple_stmt
../../gcc/cfgexpand.c:3773
0x74b0d3 expand_gimple_basic_block
../../gcc/cfgexpand.c:5772
0x7503d6 execute
../../gcc/cfgexpand.c:6373

[Bug fortran/83184] New: Out of memory or ICE with option -fdec

[gs...@t-online.de]

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

Bug ID: 83184
   Summary: Out of memory or ICE with option -fdec
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With invalid code and option -fdec-structure or -fdec :

$ cat z1.f90
program p
   structure /s/
  integer n(..) /1/
   end structure
end

$ cat z2.f90
program p
   structure /s/
  integer n(..) /2*1/
   end structure
end


$ gfortran-8-20171126 -c z1.f90 -fdec
f951: out of memory allocating 18446744073709551600 bytes after a total of
499712 bytes

---

Configured with --enable-checking=yes :

$ gfortran-8-20171126-chk -c z1.f90
z1.f90:2:12:

structure /s/
1
Error: STRUCTURE at (1) is a DEC extension, enable with '-fdec-structure'
z1.f90:4:6:

end structure
  1
Error: Expecting END PROGRAM statement at (1)
z1.f90:3:19:

   integer n(..) /1/
   1
Error: Assumed-rank array at (1) must be a dummy argument

in gfc_format_decoder, at fortran/error.c:934
0x6be93e gfc_format_decoder
../../gcc/fortran/error.c:934
0x152fe43 pp_format(pretty_printer*, text_info*)
../../gcc/pretty-print.c:1351
0x152033b diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/diagnostic.c:984
0x6be7a7 gfc_error_opt
../../gcc/fortran/error.c:1299
0x6bfce0 gfc_error(char const*, ...)
../../gcc/fortran/error.c:1328
0x7279f6 resolve_variable
../../gcc/fortran/resolve.c:5267
0x7279f6 gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:6706
0x72b238 resolve_data_variables
../../gcc/fortran/resolve.c:15504
0x733f30 resolve_data
../../gcc/fortran/resolve.c:15529
0x733f30 resolve_types
../../gcc/fortran/resolve.c:16356
0x72f6ac gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:16445
0x71903a resolve_all_program_units
../../gcc/fortran/parse.c:6031
0x71903a gfc_parse_file()
../../gcc/fortran/parse.c:6281
0x75e67f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug tree-optimization/82604] [8 Regression] SPEC CPU2006 410.bwaves ~50% performance regression with trunk@253679 when ftree-parallelize-loops is used

[amker at gcc dot gnu.org]

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

--- Comment #8 from amker at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #7)
> The #c5 approach sounds better to me, we can have memsets in the IL even
> from the user, so would be nice if we handled those in the dr analysis too.

Yeah, I plan to look into that way after interchange stuff, unless Richi gets
to it earlier :)

[Bug bootstrap/81470] [8 Regression] Bootstrap comparison failures in gcc/ada

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou  ---
And what's the output of 'gcc -v' for the base compiler?

[Bug fortran/83183] New: Out of memory with option -finit-derived

[gs...@t-online.de]

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

Bug ID: 83183
   Summary: Out of memory with option -finit-derived
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With ./gcc/testsuite/gfortran.dg/move_alloc_17.f90 or this reduction :

$ cat z1.f90
program p
  type :: linked_list
 type(linked_list), allocatable :: link
 integer :: value
  end type
  type(linked_list) :: test
  allocate(test % link)
end program


$ gfortran-8-20171126 -c z1.f90
$
$ ulimit -v 400  # optional
$
$ gfortran-8-20171126 -c z1.f90 -finit-derived
f951: out of memory allocating 80 bytes after a total of 3240341504 bytes

[Bug fortran/78238] [7/8 Regression] [OOP] ICE: verify_gimple failed, with -fdefault-integer-8

[gs...@t-online.de]

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

G. Steinmetz  changed:

   What|Removed |Added

 CC||gs...@t-online.de

--- Comment #9 from G. Steinmetz  ---
While gcc configured with --enable-checking=yes,
the ICE has changed between 20170924 (ICE: verify_gimple failed)
and 20171015 (ICE in decompose), today :


$ gfortran-8-20171126 -fdefault-integer-8 -c z1.f90
z1.f90:1:0:

 program p

internal compiler error: in decompose, at wide-int.h:935
0x617319 wi::int_traits::decompose(long*,
unsigned int, generic_wide_int const&)
../../gcc/wide-int.h:935
0x1061853 wi::int_traits::decompose(long*,
unsigned int, generic_wide_int const&)
../../gcc/tree.h:3472
0x1061853 wide_int_ref_storage::wide_int_ref_storage(generic_wide_int const&, unsigned int)
../../gcc/wide-int.h:983
0x1061853 generic_wide_int
>::generic_wide_int(generic_wide_int const&, unsigned int)
../../gcc/wide-int.h:760
0x1061853 wi::binary_traits
>, generic_wide_int,
wi::int_traits >
>::precision_type, wi::int_traits::precision_type>::result_type
wi::bit_and_not >,
generic_wide_int
>(generic_wide_int > const&,
generic_wide_int const&)
../../gcc/wide-int.h:2250
0x1061853 gimple_simplify_10
/gcc/gimple-match.c:1311
0x10e2111 gimple_simplify_EQ_EXPR
/gcc/gimple-match.c:62577
0x106b725 gimple_simplify
/gcc/gimple-match.c:72958
0x106cc0b gimple_resimplify2(gimple**, code_helper*, tree_node*, tree_node**,
tree_node* (*)(tree_node*))
../../gcc/gimple-match-head.c:165
0x11405ba gimple_simplify(gimple*, code_helper*, tree_node**, gimple**,
tree_node* (*)(tree_node*), tree_node* (*)(tree_node*))
../../gcc/gimple-match-head.c:763
0xa0b041 fold_stmt_1
../../gcc/gimple-fold.c:4631
0xa2d7f2 gimplify_cond_expr
../../gcc/gimplify.c:4009
0xa23fe4 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11297
0xa28816 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6556
0xa23a1b gimplify_statement_list
../../gcc/gimplify.c:1736
0xa23a1b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11769
0xa28816 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6556
0xa29b0d gimplify_bind_expr
../../gcc/gimplify.c:1294
0xa241aa gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11541
0xa28816 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6556

[Bug c/83172] -Wstack-size= doesn't detect the correct stack size with VLA or alloca

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-11-27
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
What happens for -Wvla-larger-than= if you use -O0 or -O1 instead of -O3?

[Bug tree-optimization/82604] [8 Regression] SPEC CPU2006 410.bwaves ~50% performance regression with trunk@253679 when ftree-parallelize-loops is used

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
The #c5 approach sounds better to me, we can have memsets in the IL even from
the user, so would be nice if we handled those in the dr analysis too.

[Bug bootstrap/81470] [8 Regression] Bootstrap comparison failures in gcc/ada

[rai...@emrich-ebersheim.de]

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

--- Comment #6 from Rainer Emrich  ---
(In reply to Eric Botcazou from comment #5)
> r247301 is the switch to native exceptions for the compiler proper and we
> know that this works on 64-bit Windows.  How do you configure the compiler?

../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-8.0.0/configure
--prefix=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-8.0.0
--with-gnu-as
--with-as=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-8.0.0/bin/as
--with-gnu-ld
--with-ld=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-8.0.0/bin/ld
--build=x86_64-w64-mingw32 --enable-threads=posix
--enable-languages=c,c++,ada,lto
--with-gmp-include=/opt/devel/SCRATCH/tmp.8Ly5oNHx4u/install/include
--with-gmp-lib=/opt/devel/SCRATCH/tmp.8Ly5oNHx4u/install/lib64
--with-mpfr-include=/opt/devel/SCRATCH/tmp.8Ly5oNHx4u/install/include
--with-mpfr-lib=/opt/devel/SCRATCH/tmp.8Ly5oNHx4u/install/lib64
--with-mpc-include=/opt/devel/SCRATCH/tmp.8Ly5oNHx4u/install/include
--with-mpc-lib=/opt/devel/SCRATCH/tmp.8Ly5oNHx4u/install/lib64
--with-isl-include=/opt/devel/SCRATCH/tmp.8Ly5oNHx4u/install/include
--with-isl-lib=/opt/devel/SCRATCH/tmp.8Ly5oNHx4u/install/lib64
--with-local-prefix=/opt/devel/tec/devel/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-8.0.0
--enable-libgomp --enable-fully-dynamic-string --disable-multilib
--enable-checking=release --disable-werror --with-sysroot=/x86_64-w64-trunk

[Bug bootstrap/81470] [8 Regression] Bootstrap comparison failures in gcc/ada

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-11-27
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Eric Botcazou  ---
r247301 is the switch to native exceptions for the compiler proper and we know
that this works on 64-bit Windows.  How do you configure the compiler?

[Bug other/83182] New: undefined behavior in generic_wide_int due to missing input validation

[msebor at gcc dot gnu.org]

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

Bug ID: 83182
   Summary: undefined behavior in generic_wide_int due to missing
input validation
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

A number of members of the wide_int classes use the expression (LEN - 1) as an
index into a small member array.  For example:

  template 
  inline HOST_WIDE_INT
  generic_wide_int ::sign_mask () const
  {
unsigned int len = this->get_len ();
unsigned HOST_WIDE_INT high = this->get_val ()[len - 1];
...
  }

However, the wide_int constructors do not sufficiently validate their
preconditions.  As a result, when the get_len () function resturns zero the
behavior of the functions that use the decremented result as an index is
undefined.

The problem can be triggered by the following test case.  When the use of the
invalid offset_int is far removed from its construction it can be difficult to
debug.  To make debugging easier, the constructor and/or the wi::to_offset
function should validate their input when checking is enabled.  Functions that
use the result of (LEN - 1) as an index should also assert that the result is
valid.

  {
// Create an expression that doesn't evaluate to INTEGER_CST.
tree x = build2 (TRUNC_DIV_EXPR, integer_type_node, integer_one_node,
integer_zero_node);

offset_int a = wi::to_offset (integer_one_node);

// Create an invalid offset_int.  The function expects an INTEGER_CST
// but doesn't do any input validation..
offset_int b = wi::to_offset (x);

// Trigger a SIGSEGV.
if (a < b)
  return;
  }


Program received signal SIGSEGV, Segmentation fault.
0x012f255e in selt (a=0x7fffcaf0, len=0, blocks_needed=2,
small_prec=0, index=4294967295, sgn=SIGNED) at
/ssd/src/gcc/svn/gcc/wide-int.cc:404
404 val = SIGN_MASK (a[len - 1]);
(gdb) p len
$1 = 0
(gdb) bt
0x012f255e in selt (a=0x7fffcaf0, len=0, blocks_needed=2,
small_prec=0, index=4294967295, sgn=SIGNED) at
/ssd/src/gcc/svn/gcc/wide-int.cc:404
404 val = SIGN_MASK (a[len - 1]);
(gdb) bt
#0  0x012f255e in selt (a=0x7fffcaf0, len=0, blocks_needed=2,
small_prec=0, index=4294967295, sgn=SIGNED) at
/ssd/src/gcc/svn/gcc/wide-int.cc:404
#1  0x012f27c4 in wi::lts_p_large (op0=0x7fffcad0, op0len=1,
precision=128, op1=0x7fffcaf0, op1len=0) at
/ssd/src/gcc/svn/gcc/wide-int.cc:480
#2  0x00866be1 in
wi::lts_p >,
generic_wide_int > > (x=..., y=...) at
/ssd/src/gcc/svn/gcc/wide-int.h:1835
#3  0x008664e5 in operator<
 >,
generic_wide_int > > (x=..., y=...) at
/ssd/src/gcc/svn/gcc/wide-int.h:3124

[Bug rtl-optimization/81019] [6/7/8 Regression] wrong code with -O -fno-tree-ccp

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-27
 CC||aoliva at gcc dot gnu.org,
   ||segher at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Jakub Jelinek  ---
/* PR rtl-optimization/81019 */
/* { dg-do run } */
/* { dg-options "-O -fno-tree-ccp" } */

unsigned long long __attribute__((noinline, noclone))
foo (unsigned char a, unsigned short b, unsigned c, unsigned long long d,
 unsigned char e, unsigned short f, unsigned g, unsigned long long h)
{
  g = e;
  c &= 0 < d;
  b *= d;
  g ^= -1;
  g &= 1;
  c |= 1;
  a -= 0 < g;
  g >>= 1;
  f = b | (f >> b);
  return a + c + d + f + g + h;
}

int
main (void)
{
  if (foo (0, 0, 0, 0, 0, 0, 0, 0) != 0x100)
__builtin_abort ();
  return 0;
}

This is indeed miscompiled in the combiner if the r249850 change is reverted
(which changes costs and thus combiner decides to try different optimizations).
With the change reverted, the g &= 1 masking is lost.

Alex/Segher, what is the current state of the patch?
I see https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00363.html as the last mail
on the subject.

[Bug preprocessor/83173] C preprocessor generates incorrect linemarkers

[mgulick at mathworks dot com]

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

--- Comment #1 from Mike Gulick  ---
Just a minor update.  I re-tested the reproducer on gcc 5.4 as well as 4.9.2,
and the issue is present in both of those.  I had originally thought the bug
was not present in gcc 5.4 or earlier, however this is likely because the
source code I was testing it on was not pushing the line map source location >
0x6000 in these versions of the compiler.

[Bug ipa/83179] [8 regression] gcc.dg/ipa/inline-1.c fail

[andrey.y.guskov at intel dot com]

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

--- Comment #4 from Andrey Guskov  ---
32-bit SPEC CPU2017::507/607 also affected:

during GIMPLE pass: vect
gnu/regex.c: In function 'regexec.constprop':
gnu/regex.c:5751:1: internal compiler error: in vectorizable_mask_load_store,
at tree-vect-stmts.c:2349
 regexec (preg, string, nmatch, pmatch, eflags)
 ^
0x74786d vectorizable_mask_load_store
../../../gcc/gcc/tree-vect-stmts.c:2348
0x7510ad vectorizable_call
../../../gcc/gcc/tree-vect-stmts.c:2652
0xe6ee48 vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*, _slp_tree*,
_slp_instance*)
../../../gcc/gcc/tree-vect-stmts.c:8826
0x760faa vect_transform_loop(_loop_vec_info*)
../../../gcc/gcc/tree-vect-loop.c:7559
0xe8355d vectorize_loops()
../../../gcc/gcc/tree-vectorizer.c:761
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: g++ returned 1 exit status
compilation terminated.
/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug c++/83181] New: [C++17] Invalid deduction guide accepted

[redi at gcc dot gnu.org]

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

Bug ID: 83181
   Summary: [C++17] Invalid deduction guide accepted
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

template struct enable_if { using type = void; };
template<> struct enable_if { };
template struct is_foo { static const bool value = false; };

template
using RequireFoo = typename enable_if::type;

template struct init_list { };

template struct X
{
  X(init_list, A) { }
};

template>
  X(init_list, A) -> X;

struct Alloc { };

template<> struct is_foo { static const bool value = true; };

int main()
{
  init_list l;
  Alloc a;
  X x(l, a);
}

The RequireFoo template parameter is invalid (it's missing "typename =") but
G++ accepts it. CLang rejects it with this error:


prog.cc:15:49: error: deduction guide template contains a template parameter
that cannot be deduced
template> X(init_list, A) -> X;
^
prog.cc:15:47: note: non-deducible template parameter (anonymous)
template> X(init_list, A) -> X;
  ^

[Bug gcov-profile/79392] MinGW-w64 backend: programs built with --coverage do not create *.gcda files

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|RESOLVED|WAITING
 Resolution|WORKSFORME  |---

--- Comment #4 from Jonathan Wakely  ---
Maybe it's a Debian-specific bug then. Please provide the missing information
requested by https://gcc.gnu.org/bugs/

[Bug c/83180] MINGW: Linking to libpq.dll produced with MSVC-x64 generates invalid code

[l...@greiz-reinsdorf.de]

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

--- Comment #1 from Lars Kanis  ---
Created attachment 42732
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42732=edit
The DLL in question produced by MSVC

[Bug c/83180] New: MINGW: Linking to libpq.dll produced with MSVC-x64 generates invalid code

[l...@greiz-reinsdorf.de]

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

Bug ID: 83180
   Summary: MINGW: Linking to libpq.dll produced with MSVC-x64
generates invalid code
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: l...@greiz-reinsdorf.de
  Target Milestone: ---

Created attachment 42731
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42731=edit
Test source code to link to libpq.dll

Hi! I'm a maintainer of the Ruby binding to PostgreSQL. I'm faced with a linker
issue when linking to PQgetvalue() in the libpq.dll for x64 provided by the
PostgreSQL project. The DLL in question is attached. It is part of the official
PostgreSQL download for Windows-x64:
https://get.enterprisedb.com/postgresql/postgresql-10.0-1-windows-x64.exe

The error can be reproduced by using the attached "segfault.c" file like so. It
fails when auto-import is disabled:

$ x86_64-w64-mingw32-gcc -o segfault.exe segfault.c
-IC:/PROGRA~1/POSTGR~1/10/include -LC:/PROGRA~1/POSTGR~1/10/lib
-Wl,--enable-auto-image-base,--disable-auto-import -lpq
C:\Users\kanis\AppData\Local\Temp\cce46Itr.o:segfault.c:(.text+0x11e):
undefined reference to `PQgetvalue'
collect2.exe: error: ld returned 1 exit status


When auto-import is enabled, then linking succeeds, but the generated code is
invalid:

$ x86_64-w64-mingw32-gcc -o segfault.exe segfault.c
-IC:/PROGRA~1/POSTGR~1/10/include -LC:/PROGRA~1/POSTGR~1/10/lib
-Wl,--enable-auto-image-base,--enable-auto-import -lpq
$ objdump -d segfault.exe

[...]
  401650:   48 8b 45 f0 mov-0x10(%rbp),%rax
  401654:   41 b8 00 00 00 00   mov$0x0,%r8d
  40165a:   ba 00 00 00 00  mov$0x0,%edx
  40165f:   48 89 c1mov%rax,%rcx
  401662:   e8 d9 17 00 00  callq  402e40 
  401667:   89 45 ecmov%eax,-0x14(%rbp)
  40166a:   8b 45 ecmov-0x14(%rbp),%eax
  40166d:   89 c2   mov%eax,%edx
  40166f:   48 8d 0d e4 29 00 00lea0x29e4(%rip),%rcx#
40405a <.rdata+0x5a>
  401676:   e8 25 16 00 00  callq  402ca0 
  40167b:   48 8b 45 f0 mov-0x10(%rbp),%rax
  40167f:   41 b8 00 00 00 00   mov$0x0,%r8d
  401685:   ba 00 00 00 00  mov$0x0,%edx
  40168a:   48 89 c1mov%rax,%rcx
  40168d:   e8  .byte 0xe8

0040168e <__fu0_PQgetvalue>:
  40168e:   66 6d   insw   (%dx),%es:(%rdi)
  401690:   00 00   add%al,(%rax)
  401692:   48 89 45 e0 mov%rax,-0x20(%rbp)
  401696:   48 8b 45 e0 mov-0x20(%rbp),%rax
  40169a:   48 89 c2mov%rax,%rdx
  40169d:   48 8d 0d bf 29 00 00lea0x29bf(%rip),%rcx#
404063 <.rdata+0x63>
  4016a4:   e8 f7 15 00 00  callq  402ca0 
[...]

$ ./segfault.exe
conn: 007AA7D0
PQlibVersion: 10
res: 007B7120
len: 3

... The call to PQgetlength() and printf() runs through, but it segfaults on
0x40168d, because the address of callq (opcode 0xe8) is invalid. Obviously the
debug information also doesn't fit to the produced code, so that the opcodes
are not properly decoded.

Other functions like PQgetlength() are not affected. They link fine with
auto-import being enabled or disabled. The only function with this odd behavior
is PQgetvalue().

As a workaround "-l:libpq.lib" can be used to trigger linking to libpq.dll per
MSVC import library. This works for gcc-7.2.0, but older versions of gcc
(4.7.2) fail to link to any function of a MSVC produced libpq.lib file (for
some obviously fixed reason).

The issue doesn't appear when building for 32 bit x86 or when linking to a
libpq.dll produced by MINGW.


The root issue is also reproducible on Appveyor:
https://ci.appveyor.com/project/larskanis/ruby-pg-xa3f5/build/1.0.65/job/b06idaids8el773r


My environment:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-7.2.0/configure --prefix=/mingw64
--with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
--with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include
--libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64
--with-tune=generic --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada
--enable-shared --enable-static --enable-libatomic --enable-threads=posix
--enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-time=yes
--disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check
--enable-lto --enable-libgomp --disable-multilib --enable-checking=release

[Bug middle-end/83069] [8 Regression] internal compiler error: in from_gcov_type, at profile-count.h:676

[andrey.y.guskov at intel dot com]

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

Andrey Guskov  changed:

   What|Removed |Added

 CC||andrey.y.guskov at intel dot 
com

--- Comment #8 from Andrey Guskov  ---
Also happens on Haswell and Silvermont.

[Bug tree-optimization/80198] [6/7/8 Regression] does not vectorize generic inplace integer operation

[law at redhat dot com]

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

--- Comment #10 from Jeffrey A. Law  ---
Yea.  The code that was recording NAME = NAME conditional equivalences was
largely disabled back in August.  They'll only be recorded now if one name is
cheaper to compute than the other.

So if the conditional equivalences are still a problem with this BZ, then we
need to look at the costing of the SSA_NAME's defining statement.

[Bug rtl-optimization/81019] [6/7/8 Regression] wrong code with -O -fno-tree-ccp

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Started with r228320.

[Bug ipa/83179] [8 regression] gcc.dg/ipa/inline-1.c fail

[jamborm at gcc dot gnu.org]

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

--- Comment #3 from Martin Jambor  ---
Started with Honza's r255103.

[Bug middle-end/83164] [8 regression] internal compiler error: verify_gimple failed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
This is a checking ICE, not a user facing diagnostics.  Not need to spend time
on anything but fixing the ICE.

[Bug target/81616] Update -mtune=generic for the current Intel and AMD processors

[andrewm.roberts at sky dot com]

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

--- Comment #17 from Andrew Roberts  ---
The general consensus in userland is that the znver1 optimization is much worse
than 0.5%, or even 2% off. Most people are using -march=haswell if they care
about performance.

Just taking one part of one of my apps I see a 5% difference with
-march=haswell vs -march=znver1, and this is just general code (loading GL
extensions). 

The trick is to remove system dependencies from things I could benchmark. If
there are no recommendations, I'll come up with some tests myself for various
workloads, and try across various march/tune combos.

I'll also look at some other real world benchmarks that are available online.

[Bug bootstrap/83163] bootstrap comparison failure with --enable-languages=all,jit

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Target||x86_64-pc-linux-gnu
   Host||x86_64-pc-linux-gnu
  Build||x86_64-pc-linux-gnu

--- Comment #2 from Martin Sebor  ---
The build was done on Fedora 25 with the system GCC, version 6.3.1 20161221
(Red Hat 6.3.1-1).

I don't see the failure with --enable-languages=c,c++,jit.  Let me try to
narrow it down further.

[Bug middle-end/83164] [8 regression] internal compiler error: verify_gimple failed

[dmalcolm at gcc dot gnu.org]

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

--- Comment #7 from David Malcolm  ---
BZ mangled the underline a bit in comment #6; the caret is on the '-'
character, like this simplified version:

thunk->callback = LHS - RHS;
  ^

[Bug middle-end/83164] [8 regression] internal compiler error: verify_gimple failed

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #6 from David Malcolm  ---
(In reply to Gerald Pfeifer from comment #0)
[...]
> Also the diagnostics look quite odd, don't they?
[...]

If I strip out the line directives from the .i file, then I get:

ddeml.i:8322:28: error: type mismatch in pointer diff expression
 static struct ddeml_thunk* DDEML_AddThunk(DWORD instId, DWORD pfn16)
^~

from this line in tree-cfg.c:

3996error ("type mismatch in pointer diff expression");

which is less odd (though not great).

If I use stmt->location for the diagnostic (rather than the implicit use of
input_location), then I get the much more useful:

(gdb) call inform (stmt->location, "")
ddeml.i: In function ‘DDEML_AddThunk’:
ddeml.i:8342:61: note: 
 thunk->callback = (char *)WDML_InvokeCallback16 - (char
*)(>callback + 1);
  
~~^~~~

[Bug target/81616] Update -mtune=generic for the current Intel and AMD processors

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Biener  ---
(In reply to Jan Hubicka from comment #13)
> > So is this option still helping with the latest microcode? Not in this case 
> > at
> > least.
> 
> It is on my TODO list to re-benchmark 256bit vectorization for Zen.  I do not
> think microcode is a big difference here.  Using 256 bit vectors has
> advantage
> of exposing more of parallelism but also disadvantage of requiring more
> involved setup.  So for loops that vectorize naturally (like matrix
> multiplication) it can be win, while for loops that are difficult to
> vectorize
> it is a loss. So I think the early benchmarks did not look consistent and it
> is
> why 128bit mode was introduced.
> 
> It is not that different form vectorizing for K8 which had split SSE
> registers
> in a similar fashion or for kabylake which splits 512 bit operations.
> 
> While rewriting the cost-model I tried to keep this in mind and more
> acurately
> model the split operations, so it may be possible to switch to 256 by
> default.
> 
> Ideally vectorizer should make a deicsion whether 128 or 256 is win for
> partiuclar loop but it doesn't seem to have infrastructure to do so.
> My plan is to split current flag into two - preffer 128bit and assume
> that registers are internally split and see if that is enough to get
> consistent
> win for 256 bit vectorization.
> 
> Richi may know better.

The vectorizer cannot currently evaluate both (or multiple) vector length
vectorization costs against each other.  Doing so with the current
implementation would have prohibitive cost (basically do the analysis
phase twice and if unlucky and the "first" wins, re-do analysis phase
of the winner).

Hmm, maybe not _too_ bad in the end...

But first and foremost costing is not aware of split AVX256 penalties,
so I'm not sure if doing the above would help.

I can cook up some "quick" prototype (maybe hidden behind a --param
paywall) so one could benchmark such mode.

Is there interest?

> Honza

[Bug ipa/83179] [8 regression] gcc.dg/ipa/inline-1.c fail

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug ipa/83178] [8 regression] g++.dg/ipa/devirt-22.C fail

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug target/81616] Update -mtune=generic for the current Intel and AMD processors

[hubicka at ucw dot cz]

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

--- Comment #15 from Jan Hubicka  ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616
> 
> --- Comment #14 from Andrew Roberts  ---
> It would be nice if znver1 for -march and -mtune could be improved before the
> gcc 8 release. At present -march=znver1 -mtune=znver1 looks be to about the
> worst thing you could do, and not just on this vectorizable code. And given we
> tell people to use -march=native which gives this, it would be nice to 
> improve.

We benchmarked znver1 tuning quite thoroughly with spec2000, spec2006 and 2017
and istuation is not that bad. 
In August, with -O2 native tuning is about 0.3% (for both in and fp) better
than generic (this does not include vectorization becuase of -O2 and keep in
mind that spec is often bound by memory, 0.3% difference is quite noticable).
All regressions in individual benchmarks were under 2% and some fixed since
then.

For -Ofast the difference is about 0.5% for integer with two notable
regressions
wich have WIP solutions for.

Integer/core tuning went worse than generic so things was as indtended.

I will quickly re-test 256bit vectorization with specfp2k (that is fast).
Please attach regressing testcases you have and I will take a look, too.

Honza

[Bug target/83158] [8 regression] gcc.target/i386/pr78057.c fail

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Or rather

   && ((TYPE_PRECISION (TREE_TYPE (*vr0min))
>= TYPE_PRECISION (integer_type_node))
   || POINTER_TYPE_P (TREE_TYPE (*vr0min)))

targeting DOS real-mode might get you 16bit pointers but 32bit integers (not
sure if 16bit pointers are exposed as such for C).

[Bug target/83158] [8 regression] gcc.target/i386/pr78057.c fail

[rguenth at gcc dot gnu.org]

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

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

Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c  (revision 255173)
+++ gcc/tree-vrp.c  (working copy)
@@ -6021,11 +6021,13 @@ intersect_ranges (enum value_range_type
   && vrp_val_is_max (vr1max))
;
  /* Choose the anti-range if it is ~[0,0], that range is special
-enough to special case when vr1's range is relatively wide.  */
+enough to special case when vr1's range is relatively wide.
+At least for types bigger than int - this covers pointers
+and arguments to functions like ctz.  */
  else if (*vr0min == *vr0max
   && integer_zerop (*vr0min)
   && (TYPE_PRECISION (TREE_TYPE (*vr0min))
-  == TYPE_PRECISION (ptr_type_node))
+  >= TYPE_PRECISION (integer_type_node))
   && TREE_CODE (vr1max) == INTEGER_CST
   && TREE_CODE (vr1min) == INTEGER_CST
   && (wi::clz (wi::to_wide (vr1max) - wi::to_wide (vr1min))

[Bug target/81616] Update -mtune=generic for the current Intel and AMD processors

[andrewm.roberts at sky dot com]

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

--- Comment #14 from Andrew Roberts  ---
It would be nice if znver1 for -march and -mtune could be improved before the
gcc 8 release. At present -march=znver1 -mtune=znver1 looks be to about the
worst thing you could do, and not just on this vectorizable code. And given we
tell people to use -march=native which gives this, it would be nice to improve.

With the attached example switching to larger vectors still only gets to 20
clocks, whereas other combinations get down to 116045

mult took 116045 clocks -march=corei7-avx -mtune=skylake

So there is more going on here than just the vector length.

If there is any testing to isolate other options I would be happy to help, just
point me in the right direction. If there are good (open) benchmarks I can
routinely test on a range of targets I would be happy to. I have ryzen,
haswell, skylake, arm, aarch64, etc.

[Bug target/58693] GCC aarch64 arm_neon.h missing intrinsics from ACLE 2.0

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

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

--- Comment #7 from Tamar Christina  ---
Closing as duplicate of #71233

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

[Bug target/71233] [ARM, AArch64] missing AdvSIMD intrinsics

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

 CC||lennox at cs dot columbia.edu

--- Comment #16 from Tamar Christina  ---
*** Bug 58693 has been marked as a duplicate of this bug. ***

[Bug target/81616] Update -mtune=generic for the current Intel and AMD processors

[hubicka at ucw dot cz]

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

--- Comment #13 from Jan Hubicka  ---
> So is this option still helping with the latest microcode? Not in this case at
> least.

It is on my TODO list to re-benchmark 256bit vectorization for Zen.  I do not
think microcode is a big difference here.  Using 256 bit vectors has advantage
of exposing more of parallelism but also disadvantage of requiring more
involved setup.  So for loops that vectorize naturally (like matrix
multiplication) it can be win, while for loops that are difficult to vectorize
it is a loss. So I think the early benchmarks did not look consistent and it is
why 128bit mode was introduced.

It is not that different form vectorizing for K8 which had split SSE registers
in a similar fashion or for kabylake which splits 512 bit operations.

While rewriting the cost-model I tried to keep this in mind and more acurately
model the split operations, so it may be possible to switch to 256 by default.

Ideally vectorizer should make a deicsion whether 128 or 256 is win for
partiuclar loop but it doesn't seem to have infrastructure to do so.
My plan is to split current flag into two - preffer 128bit and assume
that registers are internally split and see if that is enough to get consistent
win for 256 bit vectorization.

Richi may know better.

Honza

[Bug target/58693] GCC aarch64 arm_neon.h missing intrinsics from ACLE 2.0

[tnfchris at gcc dot gnu.org]

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

--- Comment #6 from Tamar Christina  ---
Sorry, I phrased it incorrectly, I meant to say, bug #71233 should supersede
this one. As in deed it has more details and is more up to date.

[Bug target/58693] GCC aarch64 arm_neon.h missing intrinsics from ACLE 2.0

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #5 from Christophe Lyon  ---
Well, I think bug #71233 has more details, and is more up-to-date.

[Bug target/83158] [8 regression] gcc.target/i386/pr78057.c fail

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Indeed it's related.  We now have range-info for

x_16 = x_15(D) + 2;

and thus:

Visiting conditional with predicate: if (x_16 == 0)

With known ranges
x_16: [-2147483646, +INF]
...
Intersecting
  ~[0, 0]  EQUIVALENCES: { x_16 } (1 elements)
and
  [-2147483646, +INF]
to
  [-2147483646, +INF]  EQUIVALENCES: { x_16 } (1 elements)

arguably the newly chosen range is smaller ...

we don't have the ability (limitation of the equivalence representation)
to keep ~[0, 0] as equivalence and it wouldn't help in this case given
the info is later supposed to be taken from SSA_NAME_RANGE_INFO.

We do special-case ~[0, 0] in the range intersection code but only for
pointer-type sized ranges...

  /* Choose the anti-range if it is ~[0,0], that range is special
 enough to special case when vr1's range is relatively wide.  */
  else if (*vr0min == *vr0max
   && integer_zerop (*vr0min)
   && (TYPE_PRECISION (TREE_TYPE (*vr0min))
   == TYPE_PRECISION (ptr_type_node))
   && TREE_CODE (vr1max) == INTEGER_CST
   && TREE_CODE (vr1min) == INTEGER_CST
   && (wi::clz (wi::to_wide (vr1max) - wi::to_wide (vr1min))
   < TYPE_PRECISION (TREE_TYPE (*vr0min)) / 2))
;

thus a "fix" is (I guess I'm ok with that if it doesn't regress any testcase
we have):

Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c  (revision 255167)
+++ gcc/tree-vrp.c  (working copy)
@@ -6024,8 +6024,6 @@ intersect_ranges (enum value_range_type
 enough to special case when vr1's range is relatively wide.  */
  else if (*vr0min == *vr0max
   && integer_zerop (*vr0min)
-  && (TYPE_PRECISION (TREE_TYPE (*vr0min))
-  == TYPE_PRECISION (ptr_type_node))
   && TREE_CODE (vr1max) == INTEGER_CST
   && TREE_CODE (vr1min) == INTEGER_CST
   && (wi::clz (wi::to_wide (vr1max) - wi::to_wide (vr1min))

[Bug ipa/83179] [8 regression] gcc.dg/ipa/inline-1.c fail

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-27
 CC||jamborm at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Jambor  ---
I see this too and thus confirmed.

[Bug tree-optimization/83177] [7/8 Regression] ICE with -mmpx -fcheck-pointer-bounds + __builtin___bnd_narrow_ptr_bounds + _setjmp

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |NEW
  Known to work||6.4.1
   Keywords||needs-reduction
   Last reconfirmed||2017-11-27
 Ever confirmed|0   |1
Summary|ICE with -mmpx  |[7/8 Regression] ICE with
   |-fcheck-pointer-bounds +|-mmpx
   |__builtin___bnd_narrow_ptr_ |-fcheck-pointer-bounds +
   |bounds + _setjmp|__builtin___bnd_narrow_ptr_
   ||bounds + _setjmp
   Target Milestone|--- |7.3
  Known to fail||7.2.1, 8.0

--- Comment #2 from Richard Biener  ---
Confirmed.  Seems to work on the GCC 6 branch and when optimizing.

[Bug tree-optimization/65930] Reduction with sign-change not handled

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Created attachment 42730
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42730=edit
WIP patch

What I have sitting in my tree.  Steps to make this clean is

 1) refactor things to record the original scalar reduction code somewhere
(add place in stmt vinfo?)
 2) make it less awkward ...
 3) somehow merge SLP reduction detection with the more generic path detection
(the cases that interest us are SLP reductions, I think the case with just
a path is handled already)

Oh, the patch exposes lots of ICEs, I didn't really finish it.

[Bug target/58693] GCC aarch64 arm_neon.h missing intrinsics from ACLE 2.0

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

--- Comment #4 from Tamar Christina  ---
I believe this report should supersede this one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71233

[Bug c++/81675] [6/7/8 Regression] attribute(noreturn) of destructor in :? not honored

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Mon Nov 27 13:13:22 2017
New Revision: 255167

URL: https://gcc.gnu.org/viewcvs?rev=255167=gcc=rev
Log:
PR c++/81675
* cp-gimplify.c (cp_fold) : Don't return immediately
for VOID_TYPE_P COND_EXPRs, instead fold the operands and if op0 is
INTEGER_CST, ensure that both op1 and op2 are non-NULL and fall
through into normal folding, otherwise just rebuild x if any op
changed.

* g++.dg/warn/pr81675.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/warn/pr81675.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug target/82066] #pragma GCC target documentation does not say it is implemented for aarch64

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

--- Comment #3 from Tamar Christina  ---
@Steve I believe this can be closed now can't it? or is there something left to
do?

[Bug ipa/83179] [8 regression] gcc.dg/ipa/inline-1.c fail

[andrey.y.guskov at intel dot com]

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

--- Comment #1 from Andrey Guskov  ---
g++.dg/pr79095-4.C also affected:

spawn -ignore SIGHUP /work/gcc/testsuite/g++2/../../xg++
-B/work/gcc/testsuite/g++2/../../ /source/gcc/testsuite/g++.dg/pr79095-4.C
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/work/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/work/x86_64-pc-linux-gnu/libstdc++-v3/include
-I/source/libstdc++-v3/libsupc++ -I/source/libstdc++-v3/include/backward
-I/source/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++98 -Wall -O3
-fdump-tree-vrp2 -S -o pr79095-4.s
FAIL: g++.dg/pr79095-4.C  -std=gnu++98  (test for warnings, line )

[Bug middle-end/80929] [6/7/8 Regression] Division with constant no more optimized to mult highpart

[jakub at gcc dot gnu.org]

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

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

Like this untested patch.