[Bug target/83208] New: [arm-linux-gnueabi-gcc] wrong code at optimization level -O2 and -O3 for union assignment

[yangyibiao at nju dot edu.cn]

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

Bug ID: 83208
   Summary: [arm-linux-gnueabi-gcc] wrong code at optimization
level -O2 and -O3 for union assignment
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyibiao at nju dot edu.cn
  Target Milestone: ---

$ arm-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/arm-linux-gnueabi/5/lto-wrapper
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
5.4.0-6ubuntu1~16.04.4' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm
--disable-libquadmath --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-armel-cross/jre
--enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-armel-cross
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-armel-cross
--with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--disable-libgcj --enable-objc-gc --enable-multiarch --enable-multilib
--disable-sjlj-exceptions --with-arch=armv5t --with-float=soft --disable-werror
--enable-multilib --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=arm-linux-gnueabi
--program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4)

$ cat small.c
int printf(const char*, ...);

union {
  int a;
} b = {1};

int *c = (int*)
long *d = (long*)

int main() {
  *d = 0;
  *c = *c | 4;
  printf("%d\n", b.a);
}

$ arm-linux-gnueabi-gcc -static -O0 small.c; ./a.out
4

$ arm-linux-gnueabi-gcc -static -O1 small.c; ./a.out
4

$ arm-linux-gnueabi-gcc -static -O2 small.c; ./a.out
5

$ arm-linux-gnueabi-gcc -static -O3 small.c; ./a.out
5


As we can find, the output is inconsistent between optimization -O1 and
-O2/-O3.

[Bug target/81363] [8 regression] FAIL: gcc.dg/vect/pr51581-1.c (internal compiler error)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Jakub Jelinek  ---
.

[Bug driver/83206] -mfpu=auto does not work on ARM (armv7l-unknown-linux-gnueabihf)

[andrewm.roberts at sky dot com]

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

--- Comment #1 from Andrew Roberts  ---
This was tested using:

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

and its wasn't a ODROID-XU3 it was a Hardkernel Odroid XU4

[Bug driver/83207] New: On ARM -mcpu=native does not detect ARM big/little cpu combinations correctly (armv7l-unknown-linux-gnueabihf)

[andrewm.roberts at sky dot com]

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

Bug ID: 83207
   Summary: On ARM -mcpu=native does not detect ARM big/little cpu
combinations correctly
(armv7l-unknown-linux-gnueabihf)
   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: ---

On ARM autodetection of the CPU using -mcpu=native does not give the expected
results on ARM big/little combinations.

/usr/local/gcc/bin/gcc -mcpu=native -Q --help=target | grep mcpu
  -mcpu=cortex-a7

So it didn't pick:
  cortex-a15.cortex-a7

Tested on Hardkernel Odroid XU4
CPU Model:
4 x Cortex-A15 rev 3 (0x4100c0f0)
4 x Cortex-A7 rev 3 (0x4100c070)

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

[Bug driver/83206] New: -mfpu=auto does not work on ARM (armv7l-unknown-linux-gnueabihf)

[andrewm.roberts at sky dot com]

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

Bug ID: 83206
   Summary: -mfpu=auto does not work on ARM
(armv7l-unknown-linux-gnueabihf)
   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: ---

On ARM an option to -mfpu is auto, this is given when you do:

/usr/local/gcc/bin/gcc -mcpu=native -Q --help=target
...
  Known ARM FPUs (for use with the -mfpu= option):
auto crypto-neon-fp-armv8 fp-armv8 fpv4-sp-d16 fpv5-d16 fpv5-sp-d16 neon
neon-fp-armv8 neon-fp16 neon-vfpv3 neon-vfpv4 vfp vfp3 vfpv2 vfpv3
vfpv3-d16
vfpv3-d16-fp16 vfpv3-fp16 vfpv3xd vfpv3xd-fp16 vfpv4 vfpv4-d16

If you try:
/usr/local/gcc/bin/gcc -mcpu=native -mfpu=auto -Q --help=target
You get:
  -mfpu=auto

But if you try to use it:
gcc -march=native -mcpu=native -mtune=native -mfpu=auto -Ofast -o matrix
matrix.c
You get:
cc1: error: -mfloat-abi=hard: selected processor lacks an FPU
which isn't true as:
gcc -march=native -mcpu=native -mtune=native -mfpu=neon -Ofast -o matrix
matrix.c
works
as does
-mfpu=vfpv3-d16
etc

This is true on:
armv7l and armv6l at least, tested on:
ODROID-XU3: (ARM big/little Cortex-A15/A7)
Raspbery Pi B: (ARM ARM1176)
Raspberry Pi 2B v1: (ARM Cortex-A7)
Raspberry Pi 3B: (ARM Cortex-A53)

[Bug fortran/83191] [7/8 Regression] Writing a namelist with repeated complex numbers

[jvdelisle at gcc dot gnu.org]

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

--- Comment #5 from Jerry DeLisle  ---
(In reply to Jerry DeLisle from comment #4)
> Alternatively one could do this:
> 
> @@ -1809,9 +1809,11 @@ write_complex (st_parameter_dt *dtp, const char
> *source, int kind, size_t size)
> precision, buf_size, result1, _len1);
>get_float_string (dtp, , source + size / 2 , kind, 0, buffer,
> precision, buf_size, result2, _len2);
> -  lblanks = width - res_len1 - res_len2 - 3;
> -
> -  write_x (dtp, lblanks, lblanks);
> +  if (!dtp->u.p.namelist_mode)
> +{
> +  lblanks = width - res_len1 - res_len2 - 3;
> +  write_x (dtp, lblanks, lblanks);
> +}
>write_char (dtp, '(');
>write_float_string (dtp, result1, res_len1);
>write_char (dtp, semi_comma);

With the following tweak:

@@ -1950,6 +1952,7 @@ list_formatted_write (st_parameter_dt *dtp, bt type, void
*p, int kind,
  size * GFC_SIZE_OF_CHAR_KIND(kind) : size;

   tmp = (char *) p;
+  dtp->u.p.namelist_mode = 0;

   /* Big loop over all the elements.  */
   for (elem = 0; elem < nelems; elem++)
@@ -2394,6 +2397,7 @@ namelist_write (st_parameter_dt *dtp)
   char c;
   char *dummy_name = NULL;

+  dtp->u.p.namelist_mode = 1;
   /* Set the delimiter for namelist output.  */
   switch (dtp->u.p.current_unit->delim_status)
 {

[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 #29 from Andrew Roberts  ---
And rerunning all the tests for matrix.c on Ryzen using:
-march=$amarch -mtune=$amtune -mprefer-vector-width=none -mno-fma -O3

The winners were:
mult took 118145 clocks -march=broadwell -mtune=broadwell
mult took 118912 clocks -march=core-avx2 -mtune=core-avx2

Top -mtune=znver1
mult took 121845 clocks -march=core-avx2 -mtune=znver1
mult took 129241 clocks -march=znver1 -mtune=znver1

And the bottom of the list no longer has a cluster of -mtune= btverX, bdverX,
znver1

Worst cases:
mult took 253400 clocks -march=x86-64 -mtune=haswell
mult took 254006 clocks -march=bonnell -mtune=westmere
mult took 254624 clocks -march=bonnell -mtune=silvermont
mult took 258577 clocks -march=bonnell -mtune=nehalem
mult took 260612 clocks -march=bonnell -mtune=corei7
mult took 277789 clocks -march=nocona -mtune=nano-x4

-

And rerunning all the tests for matrix.c on Ryzen using:
-march=$amarch -mtune=$amtune -mprefer-vector-width=none -mno-fma -mno-avx2
-Ofast

The winners were:
mult took 116405 clocks -march=broadwell -mtune=broadwell
mult took 117314 clocks -march=ivybridge -mtune=haswell
mult took 117551 clocks -march=broadwell -mtune=bdver2

Top znver1:
mult took 119951 clocks -march=knl -mtune=znver1
mult took 120442 clocks -march=znver1 -mtune=znver1

Worst cases:
mult took 239640 clocks -march=nehalem -mtune=bdver3
mult took 240623 clocks -march=athlon64-sse3 -mtune=silvermont
mult took 241143 clocks -march=eden-x2 -mtune=nano-2000
mult took 241547 clocks -march=core2 -mtune=intel
mult took 241870 clocks -march=nehalem -mtune=bdver2
mult took 248251 clocks -march=nocona -mtune=intel

The differences between broadwell and znver1 is within the margin of error I
would suggest, with these options.

[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 #28 from Andrew Roberts  ---
Adding -mno-avx2 into the mix was a marginal win, but only just showing out of
the noise:

/usr/local/gcc/bin/gcc -march=znver1 -mtune=znver1 -mprefer-vector-width=none
-mno-fma -mno-avx2 -O3 matrix.c -o matrix
   mult took 121397 clocks
   mult took 124373 clocks
   mult took 125345 clocks

/usr/local/gcc/bin/gcc -march=znver1 -mtune=znver1 -mprefer-vector-width=none
-mno-fma -O3 matrix.c -o matrix
mult took 123262 clocks
mult took 128193 clocks
mult took 125891 clocks

Using -Ofast instead of -O3

/usr/local/gcc/bin/gcc -march=znver1 -mtune=znver1 -mprefer-vector-width=none
-mno-fma -Ofast matrix.c -o matrix
mult took 125163 clocks
mult took 123799 clocks
mult took 122808 clocks

/usr/local/gcc/bin/gcc -march=znver1 -mtune=znver1 -mprefer-vector-width=none
-mno-fma -mno-avx2 -Ofast matrix.c -o matrix
mult took 130189 clocks
mult took 122726 clocks
mult took 123686 clocks

[Bug libfortran/83168] FAIL: gfortran.dg/fmt_f0_2.f90 with a sanitized libgfortran

[jvdelisle at gcc dot gnu.org]

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

--- Comment #6 from Jerry DeLisle  ---
Author: jvdelisle
Date: Wed Nov 29 03:07:43 2017
New Revision: 255225

URL: https://gcc.gnu.org/viewcvs?rev=255225=gcc=rev
Log:
2017-11-28  Jerry DeLisle  

PR libgfortran/83168
* io/write.c (select_string): Bump size by one to avoid
overrun.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/write.c

[Bug c++/83205] New: ICE on structured binding with ill-formed negative std::tuple_size::value

[jcemmett1 at gmail dot com]

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

Bug ID: 83205
   Summary: ICE on structured binding with ill-formed negative
std::tuple_size::value
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jcemmett1 at gmail dot com
  Target Milestone: ---

The following ill-formed code results in an ICE with GCC 8. Needs only
-std=c++17.

=
struct Foo { int i; };

namespace std {
template  struct tuple_size;

template <> struct tuple_size {
static constexpr int value = -1;
};
}

int main()
{
auto [i] = Foo{};
}
=

Output: 

GNU C++17 (GCC-Explorer-Build) version 8.0.0 20171128 (experimental)
(x86_64-linux-gnu)
compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 6355e9ef8f7b704fe373fdf166e4fd6e
: In function 'int main()':
14 : :14:20: internal compiler error: in tree_to_uhwi, at tree.c:6643
 auto [i] = Foo{};
^
mmap: Cannot allocate memory
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
Compiler exited with result code 1

Godbolt link: https://godbolt.org/g/NJ6fLG

[Bug target/81363] [8 regression] FAIL: gcc.dg/vect/pr51581-1.c (internal compiler error)

[wschmidt at gcc dot gnu.org]

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

--- Comment #2 from Bill Schmidt  ---
(In reply to Jakub Jelinek from comment #1)
> This went away with r250295 which reverted some earlier commit.  Was the
> patch reverted because of this LRA ICE, or for some other reason.  I.e. can
> we close it as RESOLVED/FIXED, or is there a plan to reapply the patch
> eventually and something we should get RA folks involved in?

I don't think this problem matches the reason for the revert directly, but it
might have caused it indirectly.  Carl's original code was fine, but he added
some standard patterns we had been missing before, allowing vectorization to
kick in for cases where it previously hadn't.  This exposed a bug in the
powerpc back end, which I fixed in https://gcc.gnu.org/r251161.  Carl then
re-committed his patches in https://gcc.gnu.org/r252027.

I don't believe the bug that I fixed could have caused the mismatched vector
modes that showed up in this bug report, but I could be wrong.  It's
theoretically possible that there is an RA bug hiding here, but it doesn't
reproduce anymore.

At this point I'd suggest closing this as RESOLVED/FIXED since the work on
vec_mule and vec_mulo is complete, and the bug is no longer occurring.

burculi.com

[Sarah Perez]

Hi!

I noticed you have liburcu.org. Are you intrested in burculi.com? If so please
let me know and I will send you more information about the sale.
If you have any questions feel free to ask, we would be happy to hear from you. 

Sarah Perez

[Bug fortran/83191] [7/8 Regression] Writing a namelist with repeated complex numbers

[jvdelisle at gcc dot gnu.org]

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

--- Comment #4 from Jerry DeLisle  ---
Alternatively one could do this:

@@ -1809,9 +1809,11 @@ write_complex (st_parameter_dt *dtp, const char *source,
int kind, size_t size)
precision, buf_size, result1, _len1);
   get_float_string (dtp, , source + size / 2 , kind, 0, buffer,
precision, buf_size, result2, _len2);
-  lblanks = width - res_len1 - res_len2 - 3;
-
-  write_x (dtp, lblanks, lblanks);
+  if (!dtp->u.p.namelist_mode)
+{
+  lblanks = width - res_len1 - res_len2 - 3;
+  write_x (dtp, lblanks, lblanks);
+}
   write_char (dtp, '(');
   write_float_string (dtp, result1, res_len1);
   write_char (dtp, semi_comma);

[Bug c++/83204] New: [6/7/8 Regression] c++ -std=c++14 ICE in maybe_undo_parenthesized_ref, at cp/semantics.c:1694

[doko at gcc dot gnu.org]

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

Bug ID: 83204
   Summary: [6/7/8 Regression] c++ -std=c++14 ICE in
maybe_undo_parenthesized_ref, at cp/semantics.c:1694
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

[forwarded from https://bugs.debian.org/882855]

not seen with GCC 5, but with the 6, 7 branches and the trunk, not seen in
c++11 mode.

$ cat test.cpp
int rand();

template
struct s
{
int count() { return rand(); }
};

template
int f(s a)
{
int const x = a.count();
int r = 0;
auto l = [&](int& r)
{
for(int y = 0, yend = (x); y < yend; ++y)
{
r += y;
}
};
l(r);
}

template int f(s);

int main()
{
}

$ g++ -std=c++14 -c test.cpp 
test.cpp: In instantiation of 'f(s):: [with v = float]':
test.cpp:14:16:   required from 'struct f(s) [with v =
float]::'
test.cpp:20:5:   required from 'int f(s) [with v = float]'
test.cpp:24:24:   required from here
test.cpp:16:33: internal compiler error: in maybe_undo_parenthesized_ref, at
cp/semantics.c:1694
 for(int y = 0, yend = (x); y < yend; ++y)
 ^
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug fortran/83191] [7/8 Regression] Writing a namelist with repeated complex numbers

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
The following patch does the trick:

--- ../_clean/libgfortran/io/write.c2017-11-22 20:37:44.0 +0100
+++ libgfortran/io/write.c  2017-11-28 23:45:55.0 +0100
@@ -1552,7 +1552,7 @@ select_string (st_parameter_dt *dtp, con
   int kind)
 {
   char *result;
-  *size = size_from_kind (dtp, f, kind) + f->u.real.d;
+  *size = size_from_kind (dtp, f, kind) + f->u.real.d + 1;
   if (*size > BUF_STACK_SZ)
  result = xmalloc (*size);
   else
@@ -1769,7 +1769,8 @@ write_real_g0 (st_parameter_dt *dtp, con


 static void
-write_complex (st_parameter_dt *dtp, const char *source, int kind, size_t
size)
+write_complex (st_parameter_dt *dtp, const char *source, int kind, size_t
size,
+   bool justify)
 {
   char semi_comma =
dtp->u.p.current_unit->decimal_status == DECIMAL_POINT ? ',' : ';';
@@ -1809,9 +1810,12 @@ write_complex (st_parameter_dt *dtp, con
precision, buf_size, result1, _len1);
   get_float_string (dtp, , source + size / 2 , kind, 0, buffer,
precision, buf_size, result2, _len2);
-  lblanks = width - res_len1 - res_len2 - 3;
+  if (justify)
+{
+  lblanks = width - res_len1 - res_len2 - 3;

-  write_x (dtp, lblanks, lblanks);
+  write_x (dtp, lblanks, lblanks);
+}
   write_char (dtp, '(');
   write_float_string (dtp, result1, res_len1);
   write_char (dtp, semi_comma);
@@ -1889,7 +1893,7 @@ list_formatted_write_scalar (st_paramete
   write_real (dtp, p, kind);
   break;
 case BT_COMPLEX:
-  write_complex (dtp, p, kind, size);
+  write_complex (dtp, p, kind, size, true);
   break;
 case BT_CLASS:
   {
@@ -2202,7 +2206,7 @@ nml_write_obj (st_parameter_dt *dtp, nam
   case BT_COMPLEX:
  dtp->u.p.no_leading_blank = 0;
  num++;
-  write_complex (dtp, p, len, obj_size);
+  write_complex (dtp, p, len, obj_size, false);
   break;

case BT_DERIVED:

[Bug lto/83201] SPEC CPU2017 505.mcf_f produces incorrect output when built with -flto and FDO

[pthaugen at gcc dot gnu.org]

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

--- Comment #2 from Pat Haugen  ---
(In reply to Pat Haugen from comment #0)
> 
> It appears to work fine with r254943. I'll start a bisect and post results.

My bisect showed that r254946 was where it started failing on trunk. And yes,
it fails with current GCC 7 branch too.

[Bug target/83203] New: Inefficient int to avx2 vector conversion

[zoltan at hidvegi dot com]

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

Bug ID: 83203
   Summary: Inefficient int to avx2 vector conversion
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zoltan at hidvegi dot com
  Target Milestone: ---
Target: x86_64-*-*

__m256i foo(long x) { return (__m256i){x}; }

gcc -mavx2 -O2 generates

  20:   c5 f9 ef c0 vpxor  %xmm0,%xmm0,%xmm0
  24:   c4 e3 f9 22 c7 00   vpinsrq $0x0,%rdi,%xmm0,%xmm0
  2a:   c5 f9 6f c0 vmovdqa %xmm0,%xmm0

It should just use vmovq  %rdi,%xmm0

Workaround is to use _mm256_castsi128_si256((__m128i){x})

[Bug c/82050] [8 Regression] ICE on invalid code on x86_64-linux-gnu in column_range, at diagnostic-show-locus.c:1403

[dmalcolm at gcc dot gnu.org]

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

--- Comment #8 from David Malcolm  ---
Author: dmalcolm
Date: Tue Nov 28 21:45:56 2017
New Revision: 255219

URL: https://gcc.gnu.org/viewcvs?rev=255219=gcc=rev
Log:
Handle very long lines when printing fix-it hints

When fixing PR c/82050 I noticed a bug in how we print fix-it hints
for very long lines: we weren't taking into account the x-offset for
the line when printing the fix-it hint.

This could lead to output where instead of printing:

foo.c:14:3944: error: etc
  = foo.field
^
replacement

where the lines have been offset to start printing at about column 3900,
the "replacement" line was erroneously *not* offset, and was thus
prefixed by thousands of spaces, leading to large whitespace gaps in
the output, and the replacement failing to line up with the source to be
replaced.

Fixed thusly.

gcc/ChangeLog:
* diagnostic-show-locus.c (layout::print_trailing_fixits): Handle
m_x_offset.
(layout::move_to_column): Likewise.

gcc/testsuite/ChangeLog:
* gcc.dg/plugin/diagnostic-test-show-locus-bw.c
(test_very_wide_line): Update expected output to include a
fix-it hint.
* gcc.dg/plugin/diagnostic-test-show-locus-color.c
(test_very_wide_line): Likewise.
* gcc.dg/plugin/diagnostic_plugin_test_show_locus.c
(test_show_locus): Add a fix-it hint to "test_very_wide_line".


Modified:
trunk/gcc/ChangeLog
trunk/gcc/diagnostic-show-locus.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/plugin/diagnostic-test-show-locus-bw.c
trunk/gcc/testsuite/gcc.dg/plugin/diagnostic-test-show-locus-color.c
trunk/gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_test_show_locus.c

[Bug tree-optimization/83202] Try joining operations on consecutive array elements during tree vectorization

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
  Component|c   |tree-optimization
   Severity|normal  |enhancement

[Bug c/83202] Try joining operations on consecutive array elements during tree vectorization

[bugzi...@poradnik-webmastera.com]

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

--- Comment #1 from Daniel Fruzynski  ---
This was compiled with -O3 -mavx -ftree-vectorize
After sending this I noticed that I wrote inner loop incorrectly, I meant one
below. Anyway, it it also not optimized:
for (int j = 0; j < i; j+=4)

I also checked code which could be optimized using operations on YMM registers:

void test(double data[8][8])
{
  for (int i = 0; i < 8; i++)
  {
for (int j = 0; j < i; j+=4)
{
  data[i][j] *= data[i][j];
  data[i][j+1] *= data[i][j+1];
  data[i][j+2] *= data[i][j+2];
  data[i][j+3] *= data[i][j+3];
}
  }
}

gcc output is, hmm, interesting:

test(double (*) [8]):
  vmovupd xmm0, XMMWORD PTR [rdi+64]
  vinsertf128 ymm0, ymm0, XMMWORD PTR [rdi+80], 0x1
  vmulpd ymm0, ymm0, ymm0
  vmovups XMMWORD PTR [rdi+64], xmm0
  vextractf128 XMMWORD PTR [rdi+80], ymm0, 0x1
  vmovupd xmm0, XMMWORD PTR [rdi+128]
  vinsertf128 ymm0, ymm0, XMMWORD PTR [rdi+144], 0x1
  vmulpd ymm0, ymm0, ymm0
  vmovups XMMWORD PTR [rdi+128], xmm0
  vextractf128 XMMWORD PTR [rdi+144], ymm0, 0x1
  vmovupd xmm0, XMMWORD PTR [rdi+192]
  vinsertf128 ymm0, ymm0, XMMWORD PTR [rdi+208], 0x1
  vmulpd ymm0, ymm0, ymm0
  vmovups XMMWORD PTR [rdi+192], xmm0
  vextractf128 XMMWORD PTR [rdi+208], ymm0, 0x1
  vmovupd xmm0, XMMWORD PTR [rdi+256]
  vinsertf128 ymm0, ymm0, XMMWORD PTR [rdi+272], 0x1
  vmulpd ymm0, ymm0, ymm0
  vmovups XMMWORD PTR [rdi+256], xmm0
  vextractf128 XMMWORD PTR [rdi+272], ymm0, 0x1
  vmovupd xmm0, XMMWORD PTR [rdi+320]
  vinsertf128 ymm0, ymm0, XMMWORD PTR [rdi+336], 0x1
  vmulpd ymm0, ymm0, ymm0
  vmovups XMMWORD PTR [rdi+320], xmm0
  vextractf128 XMMWORD PTR [rdi+336], ymm0, 0x1
  vmovupd xmm0, XMMWORD PTR [rdi+352]
  vinsertf128 ymm0, ymm0, XMMWORD PTR [rdi+368], 0x1
  vmulpd ymm0, ymm0, ymm0
  vmovups XMMWORD PTR [rdi+352], xmm0
  vextractf128 XMMWORD PTR [rdi+368], ymm0, 0x1
  vmovupd xmm0, XMMWORD PTR [rdi+384]
  vinsertf128 ymm0, ymm0, XMMWORD PTR [rdi+400], 0x1
  vmulpd ymm0, ymm0, ymm0
  vmovups XMMWORD PTR [rdi+384], xmm0
  vextractf128 XMMWORD PTR [rdi+400], ymm0, 0x1
  vmovupd xmm0, XMMWORD PTR [rdi+416]
  vinsertf128 ymm0, ymm0, XMMWORD PTR [rdi+432], 0x1
  vmulpd ymm0, ymm0, ymm0
  vmovups XMMWORD PTR [rdi+416], xmm0
  vextractf128 XMMWORD PTR [rdi+432], ymm0, 0x1
  vmovupd xmm0, XMMWORD PTR [rdi+448]
  vinsertf128 ymm0, ymm0, XMMWORD PTR [rdi+464], 0x1
  vmulpd ymm0, ymm0, ymm0
  vmovups XMMWORD PTR [rdi+448], xmm0
  vextractf128 XMMWORD PTR [rdi+464], ymm0, 0x1
  vmovupd xmm0, XMMWORD PTR [rdi+480]
  vinsertf128 ymm0, ymm0, XMMWORD PTR [rdi+496], 0x1
  vmulpd ymm0, ymm0, ymm0
  vmovups XMMWORD PTR [rdi+480], xmm0
  vextractf128 XMMWORD PTR [rdi+496], ymm0, 0x1
  vzeroupper
  ret

[Bug sanitizer/81275] [6/7/8 Regression] -fsanitize=thread produce incorrect -Wreturn-type warning

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Tue Nov 28 21:24:32 2017
New Revision: 255218

URL: https://gcc.gnu.org/viewcvs?rev=255218=gcc=rev
Log:
PR sanitizer/81275
* cp-tree.h (SWITCH_STMT_ALL_CASES_P): Define.
(SWITCH_STMT_NO_BREAK_P): Define.
(note_break_stmt, note_iteration_stmt_body_start,
note_iteration_stmt_body_end): Declare.
* decl.c (struct cp_switch): Add has_default_p, break_stmt_seen_p
and in_loop_body_p fields. 
(push_switch): Clear them.
(pop_switch): Set SWITCH_STMT_CANNOT_FALLTHRU_P if has_default_p
and !break_stmt_seen_p.  Assert in_loop_body_p is false.
(note_break_stmt, note_iteration_stmt_body_start,
note_iteration_stmt_body_end): New functions.
(finish_case_label): Set has_default_p when both low and high
are NULL_TREE.
* parser.c (cp_parser_iteration_statement): Use
note_iteration_stmt_body_start and note_iteration_stmt_body_end
around parsing iteration body.
* pt.c (tsubst_expr): Likewise.
* cp-objcp-common.c (cxx_block_may_fallthru): Return false for
SWITCH_STMT which contains no BREAK_STMTs, contains a default:
CASE_LABEL_EXPR and where SWITCH_STMT_BODY isn't empty and
can't fallthru.
* semantics.c (finish_break_stmt): Call note_break_stmt.
* cp-gimplify.c (genericize_switch_stmt): Copy SWITCH_STMT_ALL_CASES_P
bit to SWITCH_ALL_CASES_P.  Assert that if SWITCH_STMT_NO_BREAK_P then
the break label is not TREE_USED.

* g++.dg/warn/pr81275-1.C: New test.
* g++.dg/warn/pr81275-2.C: New test.
* g++.dg/warn/pr81275-3.C: New test.
* c-c++-common/tsan/pr81275.c: Skip for C++ and -O2.

Added:
trunk/gcc/testsuite/g++.dg/warn/pr81275-1.C
trunk/gcc/testsuite/g++.dg/warn/pr81275-2.C
trunk/gcc/testsuite/g++.dg/warn/pr81275-3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/cp/cp-objcp-common.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c
trunk/gcc/cp/parser.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/tsan/pr81275.c

[Bug sanitizer/81275] [6/7/8 Regression] -fsanitize=thread produce incorrect -Wreturn-type warning

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Tue Nov 28 21:22:52 2017
New Revision: 255217

URL: https://gcc.gnu.org/viewcvs?rev=255217=gcc=rev
Log:
PR sanitizer/81275
* tree.c (block_may_fallthru): Return false if SWITCH_ALL_CASES_P
is set on SWITCH_EXPR and !block_may_fallthru (SWITCH_BODY ()).
c/
* c-typeck.c (c_finish_case): Set SWITCH_ALL_CASES_P if
c_switch_covers_all_cases_p returns true.
c-family/
* c-common.c (c_switch_covers_all_cases_p_1,
c_switch_covers_all_cases_p): New functions.
* c-common.h (c_switch_covers_all_cases_p): Declare.
testsuite/
* c-c++-common/tsan/pr81275.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/tsan/pr81275.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c-family/c-common.h
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c
trunk/gcc/tree.h

[Bug c/83202] New: Try joining operations on consecutive array elements during tree vectorization

[bugzi...@poradnik-webmastera.com]

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

Bug ID: 83202
   Summary: Try joining operations on consecutive array elements
during tree vectorization
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugzi...@poradnik-webmastera.com
  Target Milestone: ---

void test(double data[4][4])
{
  for (int i = 0; i < 4; i++)
  {
for (int j = i; j < 4; j+=2)
{
  data[i][j] = data[i][j] * data[i][j];
  data[i][j+1] = data[i][j+1] * data[i][j+1];
}
  }
}

gcc creates this:

test(double (*) [4]):
  vmovsd xmm0, QWORD PTR [rdi]
  vmulsd xmm0, xmm0, xmm0
  vmovsd QWORD PTR [rdi], xmm0
  vmovsd xmm0, QWORD PTR [rdi+8]
  vmulsd xmm0, xmm0, xmm0
  vmovsd QWORD PTR [rdi+8], xmm0
  vmovsd xmm0, QWORD PTR [rdi+16]
  vmulsd xmm0, xmm0, xmm0
  vmovsd QWORD PTR [rdi+16], xmm0
  vmovsd xmm0, QWORD PTR [rdi+24]
  vmulsd xmm0, xmm0, xmm0
  vmovsd QWORD PTR [rdi+24], xmm0
  vmovsd xmm0, QWORD PTR [rdi+40]
  vmulsd xmm0, xmm0, xmm0
  vmovsd QWORD PTR [rdi+40], xmm0
  vmovsd xmm0, QWORD PTR [rdi+48]
  vmulsd xmm0, xmm0, xmm0
  vmovsd QWORD PTR [rdi+48], xmm0
  vmovsd xmm0, QWORD PTR [rdi+56]
  vmulsd xmm0, xmm0, xmm0
  vmovsd QWORD PTR [rdi+56], xmm0
  vmovsd xmm0, QWORD PTR [rdi+64]
  vmulsd xmm0, xmm0, xmm0
  vmovsd QWORD PTR [rdi+64], xmm0
  vmovsd xmm0, QWORD PTR [rdi+80]
  vmulsd xmm0, xmm0, xmm0
  vmovsd QWORD PTR [rdi+80], xmm0
  vmovsd xmm0, QWORD PTR [rdi+88]
  vmulsd xmm0, xmm0, xmm0
  vmovsd QWORD PTR [rdi+88], xmm0
  vmovsd xmm0, QWORD PTR [rdi+120]
  vmulsd xmm0, xmm0, xmm0
  vmovsd QWORD PTR [rdi+120], xmm0
  vmovsd xmm0, QWORD PTR [rdi+128]
  vmulsd xmm0, xmm0, xmm0
  vmovsd QWORD PTR [rdi+128], xmm0
  ret

clang detects that it is possible to use packed operations instead of scalar
ones, and produces this. Please implement similar optimization in gcc too.

test(double (*) [4]): # @test(double (*) [4])
  vmovupd xmm0, xmmword ptr [rdi]
  vmovupd xmm1, xmmword ptr [rdi + 16]
  vmovupd xmm2, xmmword ptr [rdi + 40]
  vmovupd xmm3, xmmword ptr [rdi + 56]
  vmulpd xmm0, xmm0, xmm0
  vmovupd xmmword ptr [rdi], xmm0
  vmulpd xmm0, xmm1, xmm1
  vmovupd xmmword ptr [rdi + 16], xmm0
  vmulpd xmm0, xmm2, xmm2
  vmovupd xmmword ptr [rdi + 40], xmm0
  vmulpd xmm0, xmm3, xmm3
  vmovupd xmmword ptr [rdi + 56], xmm0
  vmovupd xmm0, xmmword ptr [rdi + 80]
  vmulpd xmm0, xmm0, xmm0
  vmovupd xmmword ptr [rdi + 80], xmm0
  vmovupd xmm0, xmmword ptr [rdi + 120]
  vmulpd xmm0, xmm0, xmm0
  vmovupd xmmword ptr [rdi + 120], xmm0
  ret

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

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 Target|x86_64-*-*  |x86_64-*-* arm aarch64
 CC||clyon at gcc dot gnu.org

--- Comment #1 from Christophe Lyon  ---
Confirmed on arm and aarch64 as well.

[Bug lto/83201] SPEC CPU2017 505.mcf_f produces incorrect output when built with -flto and FDO

[wschmidt at gcc dot gnu.org]

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

--- Comment #1 from Bill Schmidt  ---
It may be latent for a while -- the same problem exists with GCC 7.  (Well,
technically with branches/ibm/gcc-7-branch.)

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

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 Target|x86_64-*-*  |x86_64-*-* arm aarch64
 CC||clyon at gcc dot gnu.org

--- Comment #8 from Christophe Lyon  ---
Confirmed on arm and aarch64 as well.

[Bug lto/83201] New: SPEC CPU2017 505.mcf_f produces incorrect output when built with -flto and FDO

[pthaugen at gcc dot gnu.org]

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

Bug ID: 83201
   Summary: SPEC CPU2017 505.mcf_f produces incorrect output when
built with -flto and FDO
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pthaugen at gcc dot gnu.org
CC: dje at gcc dot gnu.org, hubicka at gcc dot gnu.org,
marxin at gcc dot gnu.org, segher at gcc dot gnu.org,
wschmidt at gcc dot gnu.org
  Target Milestone: ---
  Host: powerpc64le-unknown-linux-gnu
Target: powerpc64le-unknown-linux-gnu
 Build: powerpc64le-unknown-linux-gnu

505.mcf_f produces incorrect output when built with both LTO/FDO. Using either
option separately is fine. GCC trunk r255207 was used. Following are options
used.

OPTIMIZE= -O3 -mcpu=power8 -flto

PASS1_FLAGS   = -fprofile-generate
PASS1_LDFLAGS  = -fprofile-generate
PASS2_FLAGS   = -fprofile-use
PASS2_LDFLAGS  = -fprofile-use


Contents of inp.out.mis (miscompares).

0010:  simplex iterations : 107102
   simplex iterations : 107598
   ^
0014:  simplex iterations : 152479
   simplex iterations : 149876
 ^
0016:  erased arcs: 995716
   erased arcs: 995702
^
0017:  new implicit arcs  : 2995716
   new implicit arcs  : 2995702
 ^
0019:  simplex iterations : 253145
   simplex iterations : 248008
 ^
0020:  objective value: 12161789395
   objective value: 12171761765
   ^
0021:  erased arcs: 2991635
   erased arcs: 2991537
^
0022:  new implicit arcs  : 2991635
   new implicit arcs  : 2991537
^
0024:  simplex iterations : 398127
   simplex iterations : 385785
 ^
0025:  objective value: 11729854482
   objective value: 11769820561
   ^


It appears to work fine with r254943. I'll start a bisect and post results.

[Bug gcov-profile/83200] New: Unable to manipulate (prefix, strip) coverage/profile data file (.gcda) paths at compile time

[kevin.worth at hpe dot com]

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

Bug ID: 83200
   Summary: Unable to manipulate (prefix, strip) coverage/profile
data file (.gcda) paths at compile time
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kevin.worth at hpe dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 42739
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42739=edit
Patch to add options -fprofile-dir-prefix, -fprofile-dir-strip

Using the run-time environment variables GCOV_PREFIX and GCOV_PREFIX_STRIP is
not always practical, e.g. profiling a large number of components in a system,
especially things like system daemons that are launched with their own
environment.

Utilizing similar logic to the parsing of those variables at compile-time
allows for path manipulation independent of the run-time modifications. This is
particularly useful in order to get the current working directory at the time
of compilation, which in complex build systems may be hard to reproduce
statically with an -fprofile-dir parameter.

The attached patch has been tested (and is being used) against gcc-5.3.0 and
cleanly ports to current trunk/master (though is presently unused/untested) and
seems to help address this issue for my uses.

[Bug target/80881] [7/8 Regression] null pointer access in libgomp.h

[daniel.f.starke at freenet dot de]

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

--- Comment #7 from Daniel Starke  ---
Error report from Dr.Memory:
Error #1: UNADDRESSABLE ACCESS: reading 0x-0x0008 8
byte(s)
# 0 gomp_resolve_num_threads  
[../../../../src/gcc-7.1.0/libgomp/libgomp.h:677]
# 1 GOMP_parallel 
[../../../../src/gcc-7.1.0/libgomp/parallel.c:166]
# 2 main   [h:\Temp\cpp017/test.c:11]
Note: @0:00:00.450 in thread 3376
Note: instruction: mov%fs:0x00 -> %rax

Backtrace from SIGSEGV in GDB:
#0  gomp_resolve_num_threads (specified=specified@entry=0, count=count@entry=0)
at ../../../../src/gcc-7.1.0/libgomp/parallel.c:47
threads_requested = 
max_num_threads = 
num_threads = 
busy = 
pool = 
#1  0x0040184f in GOMP_parallel (fn=fn@entry=0x401520 ,
data=data@entry=0x22fe60, num_threads=num_threads@entry=0, 
flags=flags@entry=0) at ../../../../src/gcc-7.1.0/libgomp/parallel.c:166
No locals.
#2  0x00401604 in main () at test.c:11
var = {3.72983052e-039, 0, 7.3767739e+033, 0, 7.34706519e+033, 0,
3.20827844e-039, 0, 9.03661843e-038, 0, 3.20798697e-039, 0, 
  3.67341985e-039, 0, 6.86636248e-044, 0, 1.40129846e-045, 0,
7.53898574e-043, 0, 2, 0, 3.67341985e-039, 0, 3.67341985e-039, 0, 
  1.07899982e-043, 0, 2.75506488e-040, 0, 7.67135411e+033, 0, 0, 0,
8.59029811e+009, 0, 0, 0, 3.67390189e-039, 0, 0, 0, 5.60519386e-045, 0, 
  7.53898574e-043, 0, 2.2337, 0, 1.07899982e-043, 0,
4.20389539e-045, 0, 1.77964905e-043, 0, 7.41472914e+033, 0, 3.71850803e-039, 0, 
  8.59029811e+009, 0, 3.67420457e-039, 0, 4.20389539e-043, 0,
3.20836812e-039, 0, 1.8758415e-012, 0, 3.72900095e-039, 0, 1.40129846e-045, 
  0, 3.67420457e-039, 0, 0, 0, 3.67390189e-039, 0, 0, 0,
1.07899982e-043, 0, 4.48415509e-044, 4.20389539e-045, 3.67420457e-039, 0, 0, 0, 
  2.80259693e-045, 0, 3.67420457e-039, 0, 0, 0, 1.40129846e-045, 0, 0,
0, 1.56945428e-043, 0, 0, 0, 0, 0, 3.72904579e-039, 0, 
  5.60519386e-044, 0, 3.20930979e-039, 0, 8.51989466e-043, 0,
3.20865959e-039, 0, 9.82653682e-039, 4.49998415e-039, 5.87344331e+022, 
  2.67781571e+020, 0, 0, 6.74539118e-039, 0, 2.38775653e-039, 0,
-2.81029619e+037, 2.86705666e-042, 0, 0, 1.83673515e-039, 0, 0, 0, 
  1.56945428e-043, 0, 0, 0, 0, 0, 0, 0, 0, 0, 9.93057972e-035, 0, 0, 0,
0, 0, 0, 0, 0, 0, 9.1315e-039, 0, 3.21108104e-039, 0, 
  3.20936585e-039, 0, 7.34316878e+033, 0, 3.20935604e-039, 0,
3.72902337e-039, 0, 0, 0, 3.67341985e-039, 0, 0, 1.34524653e-043, 
  7.18866112e-043, 2.80259693e-045, 3.67341985e-039, 0,
7.63497105e+033, 0, 3.67341985e-039, 0, 3.72900095e-039, 0, 3.21121556e-039, 0, 
  1.34524653e-043, 0, 0, 0, 0, 0, -nan(0x7dd000), 2.86845796e-042,
1.82959882e-018, 0, 3.67341985e-039, 0, 7.48008123e+033, 0, 0, 0, 
  3.72902337e-039, 0...}
PI = 3.14159274

Stack level 0, frame at 0x22edd0:
 rip = 0x401629 in gomp_resolve_num_threads
(../../../../src/gcc-7.1.0/libgomp/parallel.c:47); saved rip 0x40184f
 called by frame at 0x22ee30
 source language c.
 Arglist at 0x22ed88, args: specified=specified@entry=0, count=count@entry=0
 Locals at 0x22ed88, Previous frame's sp is 0x22edd0
 Saved registers:
  rbx at 0x22edb0, rsi at 0x22edb8, rdi at 0x22edc0, rip at 0x22edc8, xmm15 at
0x22edc8

Used mingw-w64-v5.0.2.

[Bug c/82050] [8 Regression] ICE on invalid code on x86_64-linux-gnu in column_range, at diagnostic-show-locus.c:1403

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #7 from David Malcolm  ---
Fixed on trunk for gcc 8 by r255214.

Candidate followup patch for test coverage:
  https://gcc.gnu.org/ml/gcc-patches/2017-11/msg02459.html

[Bug fortran/53796] I/O INQUIRE of RECL: If not specified in OPEN, the default value should be returned (sequential access)

[jb at gcc dot gnu.org]

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

--- Comment #19 from Janne Blomqvist  ---
Author: jb
Date: Tue Nov 28 19:28:50 2017
New Revision: 255215

URL: https://gcc.gnu.org/viewcvs?rev=255215=gcc=rev
Log:
PR 53796 Improve INQUIRE(RECL=...) handling

The current F2018 draft (N2137) specifies behavior of the RECL=
specifier in the INQUIRE statement, where it previously was left as
undefined. Namely:

- If the unit is not connected, RECL= should be given the value -1.
- If the unit is connected with stream access, RECL= should be given
  the value -2.

Further, as PR 53796 describes, the handling of RECL= is poor in other
ways as well. When the recl is set to the maximum possible
(GFC_INTEGER_8_HUGE / LLONG_MAX), which it does by default except for
preconnected units, and when INQUIRE(RECL=) is used with a 4 byte
integer, the value is truncated and the 4 byte value is thus
-1. Fixing this to generate an error is a lot of work, as currently
the truncation is done by the frontend, the library sees only an 8
byte value with no indication that the frontend is going to copy it to
a 4 byte one. Instead, this patch does a bit twiddling trick such that
the truncated 4 byte value is GFC_INTEGER_4_HUGE while still being
0. * GFC_INTEGER_8_HUGE which is large enough for all
practical purposes.

Finally, the patch removes GFORTRAN_DEFAULT_RECL which was used only
for preconnected units, and instead uses the same approach as describe
above.

Regtested on x86_64-pc-linux-gnu, Ok for trunk.

gcc/fortran/ChangeLog:

2017-11-28  Janne Blomqvist  

PR fortran/53796
* gfortran.texi: Remove mentions of GFORTRAN_DEFAULT_RECL.

libgfortran/ChangeLog:

2017-11-28  Janne Blomqvist  

PR fortran/53796
* io/inquire.c (inquire_via_unit): Set recl to -1 for unconnected
units.
* io/io.h (default_recl): New variable.
* io/open.c (new_unit): Set recl to default_recl for sequential,
-2 for stream access.
* io/transfer.c (read_block_form): Test against default_recl
instead of DEFAULT_RECL.
(write_block): Likewise.
* io/unit.c (init_units): Calculate max_offset, default_recl.
* libgfortran.h (DEFAULT_RECL): Remove.
* runtime/environ.c: Remove GFORTRAN_DEFAULT_RECL.

gcc/testsuite/ChangeLog:

2017-11-28  Janne Blomqvist  

PR fortran/53796
* gfortran.dg/inquire_recl_f2018.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/inquire_recl_f2018.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.texi
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/io/inquire.c
trunk/libgfortran/io/io.h
trunk/libgfortran/io/open.c
trunk/libgfortran/io/transfer.c
trunk/libgfortran/io/unit.c
trunk/libgfortran/libgfortran.h
trunk/libgfortran/runtime/environ.c

[Bug c/82050] [8 Regression] ICE on invalid code on x86_64-linux-gnu in column_range, at diagnostic-show-locus.c:1403

[dmalcolm at gcc dot gnu.org]

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

--- Comment #6 from David Malcolm  ---
Author: dmalcolm
Date: Tue Nov 28 19:24:35 2017
New Revision: 255214

URL: https://gcc.gnu.org/viewcvs?rev=255214=gcc=rev
Log:
Reject fix-it hints for various awkward boundary cases (PR c/82050)

PR c/82050 reports a failed assertion deep within diagnostic_show_locus's
code for printing fix-it hints.

The root cause is a fix-it hint suggesting a textual replacement,
where the affected column numbers straddle the LINE_MAP_MAX_COLUMN_NUMBER
boundary, so that the start of the range has a column number, but the
end of the range doesn't.

The fix is to verify that the column numbers are sane when adding fix-it
hints to a rich_location, rejecting fix-it hints where they are not.

libcpp/ChangeLog:
PR c/82050
* include/line-map.h (LINE_MAP_MAX_COLUMN_NUMBER): Move here.
* line-map.c (LINE_MAP_MAX_COLUMN_NUMBER): ...from here.
(rich_location::maybe_add_fixit): Reject fix-it hints in which
the start column exceeds the next column.


Modified:
trunk/libcpp/ChangeLog
trunk/libcpp/include/line-map.h
trunk/libcpp/line-map.c

[Bug fortran/54613] [F03] [F08] Add FINDLOC plus support MAXLOC/MINLOC with KIND=/BACK=

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #4 from Thomas Koenig  ---
KIND is done (PR 29600).

Still to do: FINDLOC and BACK.

[Bug ipa/82808] [7/8 Regression] LTO clone wrong value

[jamborm at gcc dot gnu.org]

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

--- Comment #9 from Martin Jambor  ---
Author: jamborm
Date: Tue Nov 28 18:52:49 2017
New Revision: 255212

URL: https://gcc.gnu.org/viewcvs?rev=255212=gcc=rev
Log:
[PR 82808] Use proper result types for arithmetic jump functions

2017-11-28  Prathamesh Kulkarni  
Martin Jambor  

PR ipa/82808
* tree.h (expr_type_first_operand_type_p): Declare
* tree.c (expr_type_first_operand_type_p): New function.
* ipa-prop.h (ipa_get_type): Allow i to be out of bounds.
(ipa_value_from_jfunc): Adjust declaration.
* ipa-cp.c (ipa_get_jf_pass_through_result): New parameter RES_TYPE.
Use it as result type for arithmetics, unless it is NULL in which case
be more conservative.
(ipa_value_from_jfunc): New parameter PARM_TYPE, pass it to
ipa_get_jf_pass_through_result.
(propagate_vals_across_pass_through): Likewise.
(propagate_scalar_across_jump_function): New parameter PARM_TYPE, pass
is to propagate_vals_across_pass_through.
(propagate_constants_across_call): Pass PARM_TYPE to
propagate_scalar_across_jump_function.
(find_more_scalar_values_for_callers_subset): Pass parameter type to
ipa_value_from_jfunc.
(cgraph_edge_brings_all_scalars_for_node): Likewise.
* ipa-fnsummary.c (evaluate_properties_for_edge): Renamed parms_info
to caller_parms_info, pass parameter type to ipa_value_from_jfunc.
* ipa-prop.c (try_make_edge_direct_simple_call): New parameter
target_type, pass it to ipa_value_from_jfunc.
(update_indirect_edges_after_inlining): Pass parameter type to
try_make_edge_direct_simple_call.

testsuite/
* gcc.dg/ipa/pr82808.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/ipa/pr82808.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-cp.c
trunk/gcc/ipa-fnsummary.c
trunk/gcc/ipa-prop.c
trunk/gcc/ipa-prop.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c
trunk/gcc/tree.h

[Bug libfortran/83097] Use __BYTE_ORDER__ instead of runtime test

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #5 from Thomas Koenig  ---
(In reply to Janne Blomqvist from comment #4)

> Since most targets of interest for GFortran usage are little endian (x86,
> arm, ppc64le) I'm not sure it's worth the bother to do the memcmp_char4
> optimization.

In that case, let's just close this.

[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 #27 from Jan Hubicka  ---
Hi,
one of problem here is use of vgather instruction.  It is hardly a win on Zen
architecture.
It is also on my TODO to adjust the code model to disable it for most loops.  I
only want
to benchmark if it is a win at all in some cases or not at all to set proper
weights.
You can disable it with -mno-avx2

Still the code is bit worse than for -march=amdfam10 -mtune=k8 which is bit
funny.
I will take a look at that.

Honza

[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 #26 from Jan Hubicka  ---
On you matrix benchmarks I get:

  Vector inside of loop cost: 44
  Vector prologue cost: 12
  Vector epilogue cost: 0
  Scalar iteration cost: 40
  Scalar outside cost: 0
  Vector outside cost: 12
  prologue iterations: 0
  epilogue iterations: 0
  Calculated minimum iters for profitability: 1
mult.c:15:7: note:   Runtime profitability threshold = 4
mult.c:15:7: note:   Static estimate profitability threshold = 4

  Vector inside of loop cost: 2428
  Vector prologue cost: 4
  Vector epilogue cost: 0
  Scalar iteration cost: 2428
  Scalar outside cost: 0
  Vector outside cost: 4
  prologue iterations: 0
  epilogue iterations: 0
  Calculated minimum iters for profitability: 1
mult.c:30:7: note:   Runtime profitability threshold = 4
mult.c:30:7: note:   Static estimate profitability threshold = 4


for 128bit vectorization and for 256bit

  Vector inside of loop cost: 88
  Vector prologue cost: 24
  Vector epilogue cost: 0
  Scalar iteration cost: 40
  Scalar outside cost: 0
  Vector outside cost: 24
  prologue iterations: 0
  epilogue iterations: 0
  Calculated minimum iters for profitability: 1
mult.c:15:7: note:   Runtime profitability threshold = 8
mult.c:15:7: note:   Static estimate profitability threshold = 8

  Vector inside of loop cost: 6472
  Vector prologue cost: 8
  Vector epilogue cost: 0
  Scalar iteration cost: 2428
  Scalar outside cost: 0
  Vector outside cost: 8
  prologue iterations: 0
  epilogue iterations: 0
  Calculated minimum iters for profitability: 1
mult.c:30:7: note:   Runtime profitability threshold = 8
mult.c:30:7: note:   Static estimate profitability threshold = 8

So if vectorizer knew to preffer bigger vector sizes when cost is about double,
it would vectoriye first loop to
256 as expected.

[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 #25 from Jan Hubicka  ---
Hi,
I agree that the matric multiplication fma issue is important and hopefully it
will be fixed for GCC 8.  See
https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00437.html

The irregularity of tune/arch is probably originating from enabling/disabling
fma
and avx256 preferrence.  I get
jh@d136:~> /home/jh/trunk-install-new3/bin/gcc -Ofast -march=native -mno-fma
mult.c
jh@d136:~> ./a.out
mult took 193593 clocks
jh@d136:~> /home/jh/trunk-install-new3/bin/gcc -Ofast -march=native -mno-fma
-mprefer-vector-width=256 mult.c
jh@d136:~> ./a.out
mult took 104745 clocks
jh@d136:~> /home/jh/trunk-install-new3/bin/gcc -Ofast -march=haswell
-mprefer-vector-width=256 mult.c
jh@d136:~> ./a.out
mult took 160123 clocks
jh@d136:~> /home/jh/trunk-install-new3/bin/gcc -Ofast -march=haswell
-mprefer-vector-width=256 -mno-fma mult.c
jh@d136:~> ./a.out
mult took 102048 clocks

90% difference on a common loop is quite noticeable.

Continuing my benchmarkings on spec2k.
This is -Ofast -march=native -mprefer-vector-width=none compared to 
-Ofast -march=native -mtune=haswell -mprefer-vector-width=128.
So neither of those are win compared to -mtune=native.

   164.gzip  140058.22407* 140057.92419*
   175.vpr   140037.53731* 140037.83704*
   176.gcc   110020.05494* 110020.05497*
   181.mcf   180021.68324* 180020.88660*
   186.crafty100020.94790* 100021.24722*
   197.parser180051.43499* 180051.83472*
   252.eon   130019.36749* 130018.27143*
   253.perlbmk   X X
   254.gap   X X
   255.vortexX X
   256.bzip2 150043.13483* 150043.53444*
   300.twolf 300056.65302* 300057.05267*
   Est. SPECint_base2000 4563
   Est. SPECint20004591

   168.wupwise   160030.95179* 160029.75387*
   171.swim  310027.411309* 310026.411739*
   172.mgrid 180031.05814* 180026.16895*
   173.applu 210025.78175* 210025.98096*
   177.mesa  140023.36006* 140023.36001*
   178.galgelX X
   179.art   260011.023702* 260011.023718*
   183.equake130013.010033* 130013.19944*
   187.facerec   190024.07931* 190017.211040*
   188.ammp  220034.46394* 220035.26249*
   189.lucas 200020.39864* 200020.89603*
   191.fma3d 210031.46686* 210030.07011*
   200.sixtrack  110041.72641* 110038.52856*
   301.apsi  260034.17630* 260034.27612*
   Est. SPECfp_base2000  7570
   Est. SPECfp2000 7947

[Bug debug/83199] New: FAIL: gdb.base/async.exp & gdb.base/skip.exp

[thopre01 at gcc dot gnu.org]

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

Bug ID: 83199
   Summary: FAIL: gdb.base/async.exp & gdb.base/skip.exp
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: wrong-debug
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thopre01 at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---
Target: arm-none-eabi

Hi,

The following tests regressed on arm-none-eabi targets after r254010:

PASS->FAIL: gdb.base/async.exp: nexti&
PASS->FAIL: gdb.base/async.exp: finish&
PASS->FAIL: gdb.base/skip.exp: step after disabling 3: step 3
PASS->FAIL: gdb.base/skip.exp: step after disabling 3: step 5
PASS->FAIL: gdb.base/skip.exp: step using -fu for baz: step 3
PASS->FAIL: gdb.base/skip.exp: step using -fu for baz: step 5
PASS->FAIL: gdb.base/skip.exp: step using -rfu for baz: step 3
PASS->FAIL: gdb.base/skip.exp: step using -rfu for baz: step 5

GCC was configured as: --target=arm-none-eabi --with-newlib --with-mode=thumb
--with-cpu=cortex-m3

The 2 async tests fail because the addresses are missing:

-(gdb) 0x81729x = 5; x = 5; x = 5;
+(gdb) 9  x = 5; x = 5; x = 5;

-Run till exit from #0  0x8172 in foo ()
+Run till exit from #0  foo ()

The skip tests fail because the wrong line is shown by gdb after doing step.

[Bug fortran/83196] ICE in gfc_build_compare_string, at fortran/trans-expr.c:3609 (and others)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-28
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (8.0). My instrumented gfortran gives

../../work/gcc/fortran/trans-expr.c:3627:7: runtime error: member access within
null pointer of type 'union tree_node'

[Bug c/83198] [7/8 regression] ICE internal compiler error: in format_floating, at gimple-ssa-sprintf.c:1900

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
Summary|ICE internal compiler   |[7/8 regression] ICE
   |error: in format_floating,  |internal compiler error: in
   |at  |format_floating, at
   |gimple-ssa-sprintf.c:1900   |gimple-ssa-sprintf.c:1900

[Bug c/83198] ICE internal compiler error: in format_floating, at gimple-ssa-sprintf.c:1900

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-28
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||7.2.0, 8.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  A simplified test case is below.  As the -Wformat warning suggests,
the sprintf calls are undefined, but the printf-return-value pass isn't
prepared to handle them.

$ cat pr83198.c && gcc -O2 -S -Wall pr83198.c 
void f (char *d, int x)
{
  __builtin_sprintf (d, "%.a", x);
}
pr83198.c: In function ‘f’:
pr83198.c:3:28: warning: format ‘%a’ expects argument of type ‘double’, but
argument 3 has type ‘int’ [-Wformat=]
   __builtin_sprintf (d, "%.a", x);
  ~~^   ~
  %.d
during GIMPLE pass: printf-return-value
pr83198.c:1:6: internal compiler error: in format_floating, at
gimple-ssa-sprintf.c:1900
 void f (char *d, int x)
  ^
0x1b13be5 format_floating
/ssd/src/gcc/git/gcc/gimple-ssa-sprintf.c:1900
0x1b15e5f format_directive
/ssd/src/gcc/git/gcc/gimple-ssa-sprintf.c:2755
0x1b17c9d compute_format_length
/ssd/src/gcc/git/gcc/gimple-ssa-sprintf.c:3483
0x1b18e2b handle_gimple_call
/ssd/src/gcc/git/gcc/gimple-ssa-sprintf.c:3970
0x1b18f78 before_dom_children
/ssd/src/gcc/git/gcc/gimple-ssa-sprintf.c:4003
0x1ac8f59 dom_walker::walk(basic_block_def*)
/ssd/src/gcc/git/gcc/domwalk.c:308
0x1b18feb execute
/ssd/src/gcc/git/gcc/gimple-ssa-sprintf.c:4023
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/83197] ICE in strip_float_extensions, at tree.c:11935

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Even r104500 ICEs -> this is ancient.

[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|WAITING |NEW
 CC||hainque at gcc dot gnu.org

--- Comment #9 from Eric Botcazou  ---
Correction: we can reproduce.

[Bug c/83197] ICE in strip_float_extensions, at tree.c:11935

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug target/80819] [6/7/8 regression] Useless store to the stack in _mm_set_epi64x with SSE4 -mno-avx

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Patch I'm going to test.

[Bug c/83198] New: ICE internal compiler error: in format_floating, at gimple-ssa-sprintf.c:1900

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

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

Bug ID: 83198
   Summary: ICE internal compiler error: in format_floating, at
gimple-ssa-sprintf.c:1900
   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 this snippet :

$ cat z1.c
void f (int x)
{
  char d[40];
  int a = __builtin_sprintf (d, "%.a", x, 1.0);
  int b = __builtin_sprintf (d, "%.*a", x, '1');
  int c = __builtin_sprintf (d, "%.*a", 1.0, x);
}


$ gcc-6-20171122 -c z1.c
$ gcc-8-20171126 -c z1.c
during GIMPLE pass: printf-return-value
z1.c: In function 'f':
z1.c:1:6: internal compiler error: in format_floating, at
gimple-ssa-sprintf.c:1900
 void f (int x)
  ^
0x1107ee6 format_floating
../../gcc/gimple-ssa-sprintf.c:1900
0x110507e format_directive
../../gcc/gimple-ssa-sprintf.c:2755
0x110507e compute_format_length
../../gcc/gimple-ssa-sprintf.c:3483
0x110507e handle_gimple_call
../../gcc/gimple-ssa-sprintf.c:3970
0x110507e before_dom_children
../../gcc/gimple-ssa-sprintf.c:4003
0x10d9f57 dom_walker::walk(basic_block_def*)
../../gcc/domwalk.c:308
0x11027cf execute
../../gcc/gimple-ssa-sprintf.c:4023

[Bug c++/81610] bogus fix-it hint for a call to an undeclared function: for

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Candidate patch:
  https://gcc.gnu.org/ml/gcc-patches/2017-11/msg02048.html

[Bug c++/80567] bogus fixit hint for undeclared memset: else

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
Candidate patch:
  https://gcc.gnu.org/ml/gcc-patches/2017-11/msg02048.html

[Bug c/83197] New: ICE in strip_float_extensions, at tree.c:11935

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

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

Bug ID: 83197
   Summary: ICE in strip_float_extensions, at tree.c:11935
   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: ---

Depending on function, at different optimization levels :


$ cat z1.c
double sqrt ();
void f (float a)
{
  a = sqrt ();
}


$ cat z2.c
double sin ();
void f (float a)
{
  a = sin ();
}


$ gcc-8-20171126 -c z1.c -O0
$ gcc-8-20171126 -c z1.c -O1
z1.c: In function 'f':
z1.c:4:3: internal compiler error: Segmentation fault
   a = sqrt ();
   ^
0xac9f1f crash_signal
../../gcc/toplev.c:325
0xcfa588 strip_float_extensions(tree_node*)
../../gcc/tree.c:11935
0x787b30 convert_to_real_1
../../gcc/convert.c:197
0x682148 convert(tree_node*, tree_node*)
../../gcc/c/c-convert.c:137
0x6b6003 convert_and_check(unsigned int, tree_node*, tree_node*)
../../gcc/c-family/c-common.c:1557
0x66eaf9 convert_for_assignment
../../gcc/c/c-typeck.c:6509
0x67d54c build_modify_expr(unsigned int, tree_node*, tree_node*, tree_code,
unsigned int, tree_node*, tree_node*)
../../gcc/c/c-typeck.c:5956
0x692d16 c_parser_expr_no_commas
../../gcc/c/c-parser.c:6739
0x692eb2 c_parser_expression
../../gcc/c/c-parser.c:9476
0x694729 c_parser_expression_conv
../../gcc/c/c-parser.c:9509
0x6a50ec c_parser_statement_after_labels
../../gcc/c/c-parser.c:5667
0x6a1265 c_parser_compound_statement_nostart
../../gcc/c/c-parser.c:5179
0x6a19aa c_parser_compound_statement
../../gcc/c/c-parser.c:5012
0x6a310e c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2343
0x6a98f3 c_parser_external_declaration
../../gcc/c/c-parser.c:1656
0x6aa369 c_parser_translation_unit
../../gcc/c/c-parser.c:1536
0x6aa369 c_parse_file()
../../gcc/c/c-parser.c:19041
0x6f15b5 c_common_parse_file()
../../gcc/c-family/c-opts.c:1127


$ gcc-8-20171126 -c z2.c -O2
$ gcc-8-20171126 -c z2.c -O3
$ gcc-8-20171126 -c z2.c -Ofast
z2.c: In function 'f':
z2.c:4:3: internal compiler error: Segmentation fault
#...

[Bug fortran/83196] ICE in gfc_build_compare_string, at fortran/trans-expr.c:3609 (and others)

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

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

--- Comment #2 from G. Steinmetz  ---

Slightly modified :


$ cat z3.f90
program p
   call s
contains
   subroutine s
  if ( f /= '' ) call abort
   end
   character(3) function f()
  f = ''
   end
end


$ gfortran-8-20171126 -c z3.f90 -O2
z3.f90:5:0:

   if ( f /= '' ) call abort

internal compiler error: Segmentation fault
0xb6848f crash_signal
../../gcc/toplev.c:325
0x94ef4d is_gimple_reg_type
../../gcc/gimple-expr.h:75
0x94ef4d gimplify_arg(tree_node**, gimple**, unsigned int, bool)
../../gcc/gimplify.c:3061
0x95a23c gimplify_call_expr
../../gcc/gimplify.c:3309
0x953e10 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11312
0x953a3c gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:12070
0x9598fc gimplify_cond_expr
../../gcc/gimplify.c:3957
0x9543f0 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11297
0x956d26 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6556
0x9545cb gimplify_statement_list
../../gcc/gimplify.c:1736
0x9545cb gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11769
0x956d26 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6556
0x95827f gimplify_bind_expr
../../gcc/gimplify.c:1294
0x954510 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11541
0x956d26 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6556
0x958ac1 gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:12538
0x958ea5 gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:12696
0xbebb22 gimplify_all_functions
../../gcc/tree-nested.c:3318
0xbebb07 gimplify_all_functions
../../gcc/tree-nested.c:3320
0xbefd5f lower_nested_functions(tree_node*)
../../gcc/tree-nested.c:3337

[Bug fortran/83196] ICE in gfc_build_compare_string, at fortran/trans-expr.c:3609 (and others)

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

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

--- Comment #1 from G. Steinmetz  ---

With reversed order, i.e. definition of "f" first :


$ cat z2.f90
program p
   call s
contains
   character(3) function f()
  f = 'abc'
   end
   subroutine s
  if ( f /= 'abc' ) call abort
   end
end


$ gfortran-8-20171126 -c z2.f90
z2.f90:8:13:

   if ( f /= 'abc' ) call abort
 1
Error: Function 'f' requires an argument list at (1)

[Bug fortran/83196] New: ICE in gfc_build_compare_string, at fortran/trans-expr.c:3609 (and others)

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

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

Bug ID: 83196
   Summary: ICE in gfc_build_compare_string, at
fortran/trans-expr.c:3609 (and others)
   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: ---

This function reference in "s" misses obligatory parentheses :


$ cat z1.f90
program p
   call s
contains
   subroutine s
  if ( f /= 'abc' ) call abort
   end
   character(3) function f()
  f = 'abc'
   end
end


$ gfortran-8-20171126 -c z1.f90 -O2
z1.f90:5:0:

   if ( f /= 'abc' ) call abort

internal compiler error: Segmentation fault
0xb6848f crash_signal
../../gcc/toplev.c:325
0x7600d6 gfc_build_compare_string(tree_node*, tree_node*, tree_node*,
tree_node*, int, tree_code)
../../gcc/fortran/trans-expr.c:3609
0x76a0ae gfc_conv_expr_op
../../gcc/fortran/trans-expr.c:3385
0x769993 gfc_conv_expr_val(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:7905
0x7989a7 gfc_trans_if_1
../../gcc/fortran/trans-stmt.c:1319
0x79f71a gfc_trans_if(gfc_code*)
../../gcc/fortran/trans-stmt.c:1356
0x734747 trans_code
../../gcc/fortran/trans.c:1916
0x75b42c gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6437
0x75b2a7 gfc_generate_contained_functions
../../gcc/fortran/trans-decl.c:5449
0x75b2a7 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6366
0x6ed280 translate_all_program_units
../../gcc/fortran/parse.c:6092
0x6ed280 gfc_parse_file()
../../gcc/fortran/parse.c:6295
0x731abf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204



Nearby with -O0 :

$ gfortran-8-20171126 -c z1.f90 -O0
z1.f90:5:0:

   if ( f /= 'abc' ) call abort

internal compiler error: Segmentation fault
0xb6848f crash_signal
../../gcc/toplev.c:325
0x76000f gfc_build_compare_string(tree_node*, tree_node*, tree_node*,
tree_node*, int, tree_code)
../../gcc/fortran/trans-expr.c:3629
#...

[Bug target/80819] [6/7/8 regression] Useless store to the stack in _mm_set_epi64x with SSE4 -mno-avx

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Ok, I'll bootstrap/regtest removing that; dunno if that is sufficient though,
if there shouldn't be some performance analysis.  That said, it is solely about
the SSE4, for AVX we use different alternatives.  And, before r218303 there was
no * on the rm.

[Bug tree-optimization/83195] [8 regression] pr82929.c scan for "Merging successful" fail

[sudi.das at arm dot com]

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

--- Comment #4 from Sudakshina Das  ---
I think this is the only test that fails on arm.

[Bug tree-optimization/83195] [8 regression] pr82929.c scan for "Merging successful" fail

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-11-28
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

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

Untested fix.

[Bug rtl-optimization/81025] [8 Regression] gcc ICE while building glibc for MIPS soft-float multi-lib variant

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  ---
Can't reproduce with current trunk, at least not on the #c4 testcase.
Generally, if delay slots contain frame related instructions it is always a
problem how to express that in the unwind info which doesn't have a concept of
delay slots or something similar.

[Bug target/80819] [6/7/8 regression] Useless store to the stack in _mm_set_epi64x with SSE4 -mno-avx

[ubizjak at gmail dot com]

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

--- Comment #8 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #7)
> Note it is already postreload that propagates the %rsi register directly
> into vec_concatv2di.  And the reason why DSE does nothing is that since LRA
> introduction the DSE spill removal has been disabled and last year even
> removed altogether.
> Removing the * from the first alternative fixes this.
> Uros, what is the purpose of those two *s and can't they be replaced by say
> ^ or $ ?

The (*x,0,rm) alternative was introduced together with Yr to avoid REX
prefixes, but the reason for *rm escaped my mind... probably is there from the
reload times, and could hopefully be removed.

[Bug tree-optimization/83195] [8 regression] pr82929.c scan for "Merging successful" fail

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #2 from ktkachov at gcc dot gnu.org ---
I agree it's simpler to skip the test on arm, unless we want to go down the
route of testing the movmisalign optab availability, which seems yucky.

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

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
You definitely cannot assume strcmp (s, t) == -strcmp (t, s), only that 
the result has the correct sign in each case.

There should be no need to preserve the exact return value (of the correct 
sign) chosen by the implementation in a particular case.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
The strlen pass doesn't track of all the string lengths though, that would be
prohibitive, at least with the current infrastructure (say char a[100] =
{}; just notes that strlen(a) is 0, not that strlen(a + 253) is also 0.
Generally, the entry for such a pointer is only created when such pointer is
constructed, and at that point it is too late to find the length from the
earlier initializer.

[Bug fortran/83021] [7/8 Regression] gfortran segfault in polymorphic assignment

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #14 from Paul Thomas  ---
Fixed! Thanks for the report.

Paul

[Bug fortran/83021] [7/8 Regression] gfortran segfault in polymorphic assignment

[pault at gcc dot gnu.org]

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

--- Comment #13 from Paul Thomas  ---
Author: pault
Date: Tue Nov 28 15:38:55 2017
New Revision: 255205

URL: https://gcc.gnu.org/viewcvs?rev=255205=gcc=rev
Log:
2017-11-28  Paul Thomas  

PR fortran/83021
* resolve.c (resolve_component): Only escape for use assciated
vtypes if the current namespace has no proc_name and is most
particularly block data.


Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/resolve.c

[Bug tree-optimization/83195] [8 regression] pr82929.c scan for "Merging successful" fail

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
That is because arm is cheating:
proc check_effective_target_non_strict_align {} {

# On ARM, the default is to use STRICT_ALIGNMENT, but there
# are interfaces defined for misaligned access and thus
# depending on the architecture levels unaligned access is
# available.
if [istarget "arm*-*-*"] {
return [check_effective_target_arm_unaligned]
}

return [check_no_compiler_messages non_strict_align assembly {
char *y;
typedef char __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__))) c;
c *z;
void foo(void) { z = (c *) y; }
} "-Wcast-align"]
}

proc check_effective_target_store_merge { } {
if { [is-effective-target non_strict_align ] && [is-effective-target
int32plus] } {
return 1
}

return 0
}

The testcase really cares about:
  bool allow_unaligned_store
= !STRICT_ALIGNMENT && PARAM_VALUE (PARAM_STORE_MERGING_ALLOW_UNALIGNED);
  bool allow_unaligned_load = allow_unaligned_store;
If that is not true, then in this case the optimization is not beneficial.

Is this the only store merging testcase that fails on arm?
I'd prefer not to add __builtin_assume_aligned and similar to the testcase so
that it tests the !STRICT_ALIGNMENT behavior (perhaps we can have another one
with that builtin), so do I need to uglify by using { target { store_merge && {
! arm*-*-* } } } ?

[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 #24 from Andrew Roberts  ---
For the mt19937ar test:

/usr/local/gcc/bin/gcc -march=znver1 -mtune=znver1 -O3 mt19937ar.c -o mt19937ar
  mt19937ar took 462062 clocks

/usr/local/gcc/bin/gcc -march=znver1 -mtune=znver1 -mprefer-vector-width=none
-O3 mt19937ar.c -o mt19937ar
  mt19937ar took 412449 clocks

/usr/local/gcc/bin/gcc -march=znver1 -mtune=znver1 -mprefer-vector-width=none
-mno-fma -O3 mt19937ar.c -o mt19937ar
  mt19937ar took 419284 clocks

/usr/local/gcc/bin/gcc -march=haswell -mtune=haswell -mprefer-vector-width=none
-mno-fma -O3 mt19937ar.c -o mt19937ar
  mt19937ar took 436768 clocks

/usr/local/gcc/bin/gcc -march=corei7-avx -mtune=skylake -O3 mt19937ar.c -o
mt19937ar
  mt19937ar took 410302 clocks

[Bug lto/69866] lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:158

[thopre01 at gcc dot gnu.org]

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

--- Comment #14 from Thomas Preud'homme  ---
Author: thopre01
Date: Tue Nov 28 15:19:14 2017
New Revision: 255203

URL: https://gcc.gnu.org/viewcvs?rev=255203=gcc=rev
Log:
Fix ICE in add_symbol_to_partition_1

2017-11-28  Thomas Preud'homme  

Backport from mainline
2017-06-15  Jan Hubicka  
Thomas Preud'homme  

gcc/lto/
PR lto/69866
* lto-symtab.c (lto_symtab_merge_symbols): Drop useless definitions
that resolved externally.

Backport from mainline
2017-06-15  Thomas Preud'homme  

gcc/testsuite/
PR lto/69866
* gcc.dg/lto/pr69866_0.c: New test.
* gcc.dg/lto/pr69866_1.c: Likewise.


Added:
branches/ARM/embedded-7-branch/gcc/lto/ChangeLog.arm
branches/ARM/embedded-7-branch/gcc/testsuite/gcc.dg/lto/pr69866_0.c
branches/ARM/embedded-7-branch/gcc/testsuite/gcc.dg/lto/pr69866_1.c
Modified:
branches/ARM/embedded-7-branch/gcc/lto/lto-partition.c
branches/ARM/embedded-7-branch/gcc/lto/lto-symtab.c
branches/ARM/embedded-7-branch/gcc/testsuite/ChangeLog.arm

[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 #23 from Andrew Roberts  ---
Thanks Honza,

getting closer, with original matrix.c on Ryzen:

/usr/local/gcc/bin/gcc -march=znver1 -mtune=znver1 -O3 matrix.c -o matrix
mult took 364850 clocks

/usr/local/gcc/bin/gcc -march=znver1 -mtune=znver1 -mprefer-vector-width=none
-O3 matrix.c -o matrix
   mult took 194517 clocks

/usr/local/gcc/bin/gcc -march=znver1 -mtune=znver1 -mprefer-vector-width=none
-mno-fma -O3 matrix.c -o matrix
mult took 130343 clocks

/usr/local/gcc/bin/gcc -march=haswell -mtune=haswell -mprefer-vector-width=none
-mno-fma -O3 matrix.c -o matrix
mult took 130129 clocks

These last two are comparable with the fastest obtained from trying all
combinations of -march and -mtune

[Bug fortran/83021] [7/8 Regression] gfortran segfault in polymorphic assignment

[pault at gcc dot gnu.org]

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

--- Comment #12 from Paul Thomas  ---
Author: pault
Date: Tue Nov 28 15:13:42 2017
New Revision: 255202

URL: https://gcc.gnu.org/viewcvs?rev=255202=gcc=rev
Log:
2017-11-28  Paul Thomas  

PR fortran/83021
* resolve.c (resolve_component): Only escape for use assciated
vtypes if the current namespace has no proc_name and is most
particularly block data.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c

[Bug tree-optimization/83072] Late VRP optimization

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
The testcase is now optimized early during evrp after r255201.  We still don't
record temporary ranges in SSA range info but we can perform the unreachable ()
trick VRP has.

[Bug tree-optimization/80776] -Wformat-overflow false positive for %d on integer bounded by __builtin_unreachable

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
The original case is now fixed.

[Bug tree-optimization/80776] -Wformat-overflow false positive for %d on integer bounded by __builtin_unreachable

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Tue Nov 28 14:58:11 2017
New Revision: 255201

URL: https://gcc.gnu.org/viewcvs?rev=255201=gcc=rev
Log:
2017-11-28  Richard Biener  

PR tree-optimization/80776
* gimple-ssa-evrp-analyze.h (evrp_range_analyzer::set_ssa_range_info):
Declare.
* gimple-ssa-evrp-analyze.c (evrp_range_analyzer::set_ssa_range_info):
New function.
(evrp_range_analyzer::record_ranges_from_incoming_edges):
If the incoming edge is an effective fallthru because the other
edge only reaches a __builtin_unreachable () then record ranges
derived from the controlling condition in SSA info.
(evrp_range_analyzer::record_ranges_from_phis): Use set_ssa_range_info.
(evrp_range_analyzer::record_ranges_from_stmt): Likewise.

* gcc.dg/pr80776-1.c: New testcase.
* gcc.dg/pr80776-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/pr80776-1.c
trunk/gcc/testsuite/gcc.dg/pr80776-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-evrp-analyze.c
trunk/gcc/gimple-ssa-evrp-analyze.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c
trunk/gcc/tree-vrp.h

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

[hubicka at gcc dot gnu.org]

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

--- Comment #14 from Jan Hubicka  ---
Letting entry block frequency to drop to 0 has bad effect on IPA profile
propagation.  Since new profile count arithmetics is overflow safe, I think we
should just cap it to max_count in such case.

The loop as written will never finish anyway so and if the bounds are not known
we should teach branch prediction to work out that it is not a good idea to
estimate very deep loop nests with "large" trip count.

I will prepare patch that silence the assert.

Honza

[Bug target/80819] [6/7/8 regression] Useless store to the stack in _mm_set_epi64x with SSE4 -mno-avx

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Note it is already postreload that propagates the %rsi register directly into
vec_concatv2di.  And the reason why DSE does nothing is that since LRA
introduction the DSE spill removal has been disabled and last year even removed
altogether.
Removing the * from the first alternative fixes this.
Uros, what is the purpose of those two *s and can't they be replaced by say ^
or $ ?

[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 #22 from Jan Hubicka  ---
Hi,
this is same base (so you can see there is some noise) compared to haswell
tuning
   164.gzip  140057.12452* 140058.72384*
   175.vpr   140037.13776* 140038.33659*
   176.gcc   110020.05500* 110020.15464*
   181.mcf   180021.68327* 180020.98617*
   186.crafty100020.44905* 100021.04760*
   197.parser180051.33506* 180051.93466*
   252.eon   130018.27162* 130019.26781*
   253.perlbmk   X X
   254.gap   X X
   255.vortexX X
   256.bzip2 150042.43537* 150044.13401*
   300.twolf 300056.45317* 300056.35328*
   Est. SPECint_base2000 4632
   Est. SPECint20004548

   168.wupwise   160028.25667* 160028.75580*
   171.swim  310026.311807* 310027.411304*
   172.mgrid 180026.06930* 180031.05810*
   173.applu 210025.58239* 210025.68193*
   177.mesa  140023.45970* 140022.96116*
   178.galgelX X
   179.art   260010.923807* 260010.425014*
   183.equake130012.910039* 130012.910060*
   187.facerec   190017.311009* 190020.89135*
   188.ammp  220034.26441* 220034.26428*
   189.lucas 200020.79683* 200020.79679*
   191.fma3d 210029.77060* 210031.56660*
   200.sixtrack  110038.62847* 110040.92687*
   301.apsi  260033.17866* 260032.77952*
   Est. SPECfp_base2000  8045
   Est. SPECfp2000 7766

So mes, arta and mcf sems to benefit from Haswell tunning.
Mesa is vectorization problem (we vectorize cold loop and introduce too much
of register pressure)

What is however interesting is that zen tuning with 256bit vectorization seems
to be worse than haswell tuning.  I will run haswell with 128bit vector size.

What your  matrix multiplication benchmark runs into is issue with multiply
and add instruction.  Once machine is free I will try it, but disabling fmadd
may solve the regression.

Honza

Honza

[Bug middle-end/70773] Cortex A5 profiled sudoku solver slower due to lack of sdiv/udiv

[tulipawn at gmail dot com]

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

--- Comment #25 from PeteVine  ---
So, the profile data is probably fine, and judging from the size of the final
binary, it's being used. The fix could be real after all :)

[Bug target/80819] [6/7/8 regression] Useless store to the stack in _mm_set_epi64x with SSE4 -mno-avx

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||uros at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
The dead stores are created during LRA, e.g. with -mtune=haswell we get:
(insn 3 5 4 2 (set (mem/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int -16 [0xfff0])) [2 %sfp+-8 S8 A64])
(reg:DI 4 si [ b ])) "pr80819.c":2 85 {*movdi_internal}
 (nil))
(note 4 3 17 2 NOTE_INSN_FUNCTION_BEG)
(insn 17 4 19 2 (set (reg:DI 21 xmm0 [91])
(reg/v:DI 5 di [orig:88 a ] [88])) "include/emmintrin.h":591 85
{*movdi_internal}
 (nil))
(note 19 17 20 2 NOTE_INSN_DELETED)
(note 20 19 7 2 NOTE_INSN_DELETED)
(insn 7 20 12 2 (set (reg:V2DI 21 xmm0 [91])
(vec_concat:V2DI (reg:DI 21 xmm0 [91])
(mem/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int -16 [0xfff0])) [2 %sfp+-8 S8 A64])))
"include/emmintrin.h":591 3738 {vec_concatv2di}
 (nil))
That is weird, because vec_concatv2di has:
(define_insn "vec_concatv2di"
  [(set (match_operand:V2DI 0 "register_operand"
  "=Yr,*x,x ,v ,Yi,v ,x,x,v ,x,x,v")
(vec_concat:V2DI
  (match_operand:DI 1 "nonimmediate_operand"
  "  0, 0,x ,Yv,r ,vm,?!*Yn,0,Yv,0,0,v")
  (match_operand:DI 2 "vector_move_operand"
  "*rm,rm,rm,rm,C ,C ,C ,x,Yv,x,m,m")))]
constraints, so if it is able to reload the first vec_concat operand into the
destination register, why doesn't it pick the alternative (=Yr,0,*rm) or
(=*x,0,rm)?  Is that because of the asterisks?
Shouldn't we help RA and have an alternative with (=Yi,r,r) guarded with x64
isa that would be split into movd + pinsrq?

[Bug middle-end/70773] Cortex A5 profiled sudoku solver slower due to lack of sdiv/udiv

[tulipawn at gmail dot com]

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

--- Comment #24 from PeteVine  ---
Or maybe not, gcov-dump-6 is able to read the file.

$ gcov-dump-6 sudoku.gcda.good

sudoku.gcda.good:data:magic `gcda':version `A80e'
sudoku.gcda.good:warning:current version is `603*'
sudoku.gcda.good:stamp 46451024
sudoku.gcda.good: a300:  82:PROGRAM_SUMMARY checksum=0x1b6601f6
sudoku.gcda.good:   counts=29, runs=1, sum_all=283905002,
run_max=58689000, sum_max=58689000
sudoku.gcda.good:   counter histogram:
sudoku.gcda.good:   0: num counts=2, min counter=0, cum_counter=0
sudoku.gcda.good:   1: num counts=2, min counter=1, cum_counter=2
sudoku.gcda.good:   35: num counts=6, min counter=1000,
cum_counter=6000
sudoku.gcda.good:   41: num counts=2, min counter=3000,
cum_counter=6000
sudoku.gcda.good:   48: num counts=2, min counter=9000,
cum_counter=18000
sudoku.gcda.good:   54: num counts=1, min counter=27000,
cum_counter=27000
sudoku.gcda.good:   55: num counts=1, min counter=29000,
cum_counter=29000
sudoku.gcda.good:   58: num counts=1, min counter=52000,
cum_counter=52000
sudoku.gcda.good:   60: num counts=2, min counter=81000,
cum_counter=162000
sudoku.gcda.good:   82: num counts=1, min counter=3531000,
cum_counter=3531000
sudoku.gcda.good:   86: num counts=4, min counter=6469000,
cum_counter=26033000
sudoku.gcda.good:   92: num counts=1, min counter=19563000,
cum_counter=19563000
sudoku.gcda.good:   98: num counts=4, min counter=58411000,
cum_counter=234478000
sudoku.gcda.good: 0100:   3:FUNCTION ident=108032747,
lineno_checksum=0x0ceca33f, cfg_checksum=0x73ff2042
sudoku.gcda.good:  01a1:   6:COUNTERS arcs 3 counts
sudoku.gcda.good:  01af:   2:COUNTERS ior 1 counts
sudoku.gcda.good: 0100:   3:FUNCTION ident=82881,
lineno_checksum=0x3ae31d81, cfg_checksum=0x707619b8
sudoku.gcda.good:  01a1:  14:COUNTERS arcs 7 counts
sudoku.gcda.good:  01af:   2:COUNTERS ior 1 counts
sudoku.gcda.good: 0100:   3:FUNCTION ident=1633341470,
lineno_checksum=0xf25ea178, cfg_checksum=0x1bd90f34
sudoku.gcda.good:  01a1:  22:COUNTERS arcs 11 counts
sudoku.gcda.good:  01af:   2:COUNTERS ior 1 counts
sudoku.gcda.good: 0100:   3:FUNCTION ident=535938890,
lineno_checksum=0x375a9f34, cfg_checksum=0x5d41b59e
sudoku.gcda.good:  01a1:  16:COUNTERS arcs 8 counts
sudoku.gcda.good:  01af:   2:COUNTERS ior 1 counts

[Bug middle-end/70773] Cortex A5 profiled sudoku solver slower due to lack of sdiv/udiv

[tulipawn at gmail dot com]

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

--- Comment #23 from PeteVine  ---
$ gcov-dump-6 sudoku.gcda.bad

sudoku.gcda.bad:data:magic `gcda':version `603*'
sudoku.gcda.bad:stamp 46515746
sudoku.gcda.bad: a300:  77:PROGRAM_SUMMARY checksum=0x12ec1c02
sudoku.gcda.bad:counts=29, runs=1, sum_all=342403001,
run_max=58689000, sum_max=58689000
sudoku.gcda.bad:counter histogram:
sudoku.gcda.bad:0: num counts=2, min counter=0, cum_counter=0
sudoku.gcda.bad:1: num counts=1, min counter=1, cum_counter=1
sudoku.gcda.bad:35: num counts=6, min counter=1000,
cum_counter=6000
sudoku.gcda.bad:41: num counts=1, min counter=3000,
cum_counter=3000
sudoku.gcda.bad:48: num counts=3, min counter=9000,
cum_counter=27000
sudoku.gcda.bad:54: num counts=1, min counter=27000,
cum_counter=27000
sudoku.gcda.bad:55: num counts=1, min counter=29000,
cum_counter=29000
sudoku.gcda.bad:60: num counts=3, min counter=81000,
cum_counter=243000
sudoku.gcda.bad:82: num counts=1, min counter=3531000,
cum_counter=3531000
sudoku.gcda.bad:86: num counts=4, min counter=6469000,
cum_counter=26033000
sudoku.gcda.bad:92: num counts=1, min counter=19563000,
cum_counter=19563000
sudoku.gcda.bad:98: num counts=5, min counter=58411000,
cum_counter=292941000
sudoku.gcda.bad: 0100:   3:FUNCTION ident=108032747,
lineno_checksum=0x0ceca33f, cfg_checksum=0x73ff2042
sudoku.gcda.bad:  01a1:   6:COUNTERS arcs 3 counts
sudoku.gcda.bad:  01b1:   2:COUNTERS time_profiler 1 counts
sudoku.gcda.bad: 0100:   3:FUNCTION ident=82881,
lineno_checksum=0x3ae31d81, cfg_checksum=0x707619b8
sudoku.gcda.bad:  01a1:  14:COUNTERS arcs 7 counts
sudoku.gcda.bad:  01b1:   2:COUNTERS time_profiler 1 counts
sudoku.gcda.bad: 0100:   3:FUNCTION ident=1633341470,
lineno_checksum=0xf25ea178, cfg_checksum=0x88a084d7
sudoku.gcda.bad:  01a1:  22:COUNTERS arcs 11 counts
sudoku.gcda.bad:  01b1:   2:COUNTERS time_profiler 1 counts
sudoku.gcda.bad: 0100:   3:FUNCTION ident=535938890,
lineno_checksum=0x375a9f34, cfg_checksum=0x5d41b59e
sudoku.gcda.bad:  01a1:  16:COUNTERS arcs 8 counts
sudoku.gcda.bad:  01b1:   2:COUNTERS time_profiler 1 counts

whereas:
$ gcov-dump-8 sudoku.gcda.good 
sudoku.gcda.good:data:magic `gcda':version `A80e'
sudoku.gcda.good:stamp 46451024
sudoku.gcda.good:tag `0052' is invalid
sudoku.gcda.good:0052:459670006:UNKNOWN

so it looks like the profile data is not usable and hence no pessimization?
That's probably not the fix I was hoping for, oops!

[Bug rtl-optimization/80709] [8 Regression] ICE in setup_preferred_alternate_classes_for_new_pseudos, at ira.c:2772

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Can't reproduce this, neither with r248000 nor current trunk:
./cc1plus.248000 -quiet -nostdinc -O2 -mcpu=arm7tdmi -mfloat-abi=soft -marm
pr80709.C
pr80709.C: In function ‘void abort()’:
pr80709.C:12:28: warning: ‘int __builtin_memcmp_eq(const void*, const void*,
unsigned int)’ reading 16 bytes from a region of size 4 [-Wstringop-overflow=]
   if (__builtin_memcmp (, , sizeof (a)))
   ~^~~~

[Bug target/80819] [6/7/8 regression] Useless store to the stack in _mm_set_epi64x with SSE4 -mno-avx

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Honza, thoughts on this?  Given:
movq%rdi, -16(%rsp)
movq-16(%rsp), %xmm0
pinsrq  $1, %rsi, %xmm0
I'd say if pinsrq $1, %rsi, %xmm0 is not too slow on recent AMD, then either
movq %rdi, %xmm0 should be also not too slow, or pinsrq $0, %rdi, %xmm0 should
be the way to go.
Note current trunk still emits a dead store with -mtune=intel -O2 -msse4:
movq%rsi, -16(%rsp)
movq%rdi, %xmm0
pinsrq  $1, %rsi, %xmm0
and with -mtune=generic -O2 -msse4:
movq%rdi, -16(%rsp)
movq%rsi, -24(%rsp)
movq-16(%rsp), %xmm0
pinsrq  $1, %rsi, %xmm0
Wonder why doesn't DSE eliminate it.

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

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
What if strcmp returns INT_MIN?

[Bug debug/81307] [8 regression] g++.dg/debug/debug9.C -gstabs FAILs

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Tue Nov 28 13:03:37 2017
New Revision: 255198

URL: https://gcc.gnu.org/viewcvs?rev=255198=gcc=rev
Log:
PR debug/81307
* dbxout.c (dbx_block_with_cold_children): Fix function comment.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/dbxout.c

[Bug rtl-optimization/81020] [6/7 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||aoliva at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
Dunno.  In any case, reverting your r254875 on current trunk makes the testcase
FAIL again, and applying
http://gcc.gnu.org/ml/gcc-patches/2017-06/msg01656.html
on top of that fixes it again.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
So, the ICE is because without -fsanitize=address we have:
  struct [0:D.1901][1] * aps.0;
  struct [1] * _7;
  aps.0_10 = __builtin_alloca_with_align (_8, 64);
  _7 = &*aps.0_10[4];
  __builtin_va_start (_7, 0);
but with -fsanitize=address
  struct [1] * _7;
  struct [0:D.2257][1] * _17;
  struct [0:D.2257][1] * _18;
  _17 = __builtin_alloca_with_align (_16, 256);
  _18 = _17 + 32;
  __builtin___asan_alloca_poison (_18, _8);
  _7 = [(struct [0:D.2257][1] *)_17 + 32B][4];
  __builtin_va_start (_7, 0);
Now, tree-cfg.c verification is happy about this, in both
&*aps.0_10[4]
as well as
[(struct [0:D.2257][1] *)_17 + 32B][4]
but when the backend feeds that to build_simple_mem_ref_loc we reach:
4687  /* For convenience allow addresses that collapse to a simple base
4688 and offset.  */
4689  if (TREE_CODE (ptr) == ADDR_EXPR
4690  && (handled_component_p (TREE_OPERAND (ptr, 0))
4691  || TREE_CODE (TREE_OPERAND (ptr, 0)) == MEM_REF))
4692{
4693  ptr = get_addr_base_and_unit_offset (TREE_OPERAND (ptr, 0),
);
4694  gcc_assert (ptr);
4695  ptr = build_fold_addr_expr (ptr);
4696  gcc_assert (is_gimple_reg (ptr) || is_gimple_min_invariant
(ptr));
4697}
which ICEs in the -fsanitize=address case, in the former case ptr after
build_fold_addr_expr is a SSA_NAME, but in the latter _REF[SSA_NAME + 32],
and because the base is SSA_NAME, not ADDR_EXPR, we don't really merge the two
offsets together.

So, is this a forwprop bug + checking bug that it created such ADDR_EXPR -
in cddce3 we still had:
  _17 = __builtin_alloca_with_align (_16, 256);
  _18 = _17 + 32;
  __builtin___asan_alloca_poison (_18, _8);
  _7 = &*_18[4];
  __builtin_va_start (_7, 0);
and then forwprop4 turns that into:
  _17 = __builtin_alloca_with_align (_16, 256);
  _18 = _17 + 32;
  __builtin___asan_alloca_poison (_18, _8);
  _7 = [(struct [0:D.2257][1] *)_17 + 32B][4];
  __builtin_va_start (_7, 0);
Or should build_simple_mem_ref_loc deal also with this case (such as seeing
that if ptr fails the above assert, but is ADDR_EXPR of a MEM_REF with SSA_NAME
base and constant, use the ptr base as the constant and add the offset to
offset)?  Or should all the backends and other spots that call
build_simple_mem_ref_loc gimplify the address instead?

[Bug fortran/83191] [7/8 Regression] Writing a namelist with repeated complex numbers

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #2 from Jerry DeLisle  ---
My bad. I will look into it.

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

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #7 from Segher Boessenkool  ---
Was that really a fix though, or did it just fix this particular testcase?
r254875 isn't a bug fix /per se/; it makes combine not miss some combinations
it can do that it would miss without the patch.  This then apparently makes
it not try the "bad" combination.

[Bug tree-optimization/83195] [8 regression] pr82929.c scan for "Merging successful" fail

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||arm
  Component|regression  |tree-optimization
   Target Milestone|--- |8.0

[Bug tree-optimization/83141] SRA and memcpy folding interact badly generating wrong-code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|rguenth at gcc dot gnu.org |jamborm at gcc dot 
gnu.org

--- Comment #4 from Richard Biener  ---
folding part fixed - leaving SRA part to Martin.

[Bug tree-optimization/83141] SRA and memcpy folding interact badly generating wrong-code

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Tue Nov 28 11:58:45 2017
New Revision: 255197

URL: https://gcc.gnu.org/viewcvs?rev=255197=gcc=rev
Log:
2017-11-28  Richard Biener  

PR middle-end/83141
* gimple-fold.c (gimple_fold_builtin_memory_op): For aggregate
copies generated from memcpy use a character array as reference
type.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-fold.c

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

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-28
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r253266.

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

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
The problem is that we have a type (complex double) where
TYPE_CANONICAL (TYPE_MAIN_VARIANT (t)) != TYPE_MAIN_VARIANT (TYPE_CANONICAL
(TYPE_MAIN_VARIANT (t)))
which get_alias_set code asserts on, because it does:
  t = TYPE_MAIN_VARIANT (t);
...
  if (TYPE_STRUCTURAL_EQUALITY_P (t))
...
  else
t = TYPE_CANONICAL (t);
  gcc_checking_assert (t == TYPE_MAIN_VARIANT (t));

Nathan, can you please have a look?

[Bug regression/83195] New: [8 regression] pr82929.c scan for "Merging successful" fail

[sudi.das at arm dot com]

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

Bug ID: 83195
   Summary: [8 regression] pr82929.c scan for "Merging successful"
fail
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sudi.das at arm dot com
  Target Milestone: ---

The test case pr82929.c that got in recently with the store merging patches has
started to fail on native arm-none-linux-gnueabihf and cross bare metals of
arm-none-eabi

FAIL: gcc.dg/pr82929.c scan-tree-dump-times store-merging "Merging successful"
1 (found 0 times)

This has been there since at least r255140.

Thanks
Sudi

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #10 from Jakub Jelinek  ---
Fixed.

[Bug tree-optimization/80788] [8 Regression] ICE in set_value_range, at tree-vrp.c:252

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed.

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

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Tue Nov 28 11:14:52 2017
New Revision: 255196

URL: https://gcc.gnu.org/viewcvs?rev=255196=gcc=rev
Log:
PR c/83117
* gcc.target/x86_64/abi/ms-sysv/gen.cc (make_do_tests_decl): Drop
const from do_test_{u,v}*.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/gen.cc

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

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-28
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed with revision r255159.

[Bug fortran/83191] [7/8 Regression] Writing a namelist with repeated complex numbers

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
  Known to work||6.4.0
   Keywords||wrong-code
   Last reconfirmed||2017-11-28
 CC||jvdelisle at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|Writing a namelist with |[7/8 Regression] Writing a
   |repeated complex numbers|namelist with repeated
   ||complex numbers
   Target Milestone|--- |7.3
  Known to fail||7.2.0, 8.0

--- Comment #1 from Dominique d'Humieres  ---
Likely caused by r237735 (pr48852).

The test in pr48852 comment 0 prints now

 (1.,0.)

It should probably be

(1.,0.)

If I read the code correctly, it is caused by the lines

  lblanks = width - res_len1 - res_len2 - 3;

  write_x (dtp, lblanks, lblanks);

needed to have right justified outputs (case C in pr48852 comment 12).

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-28
 CC||jakub at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r247546.