[Bug target/83292] __builtin_apply(), __builtin_return() trigger x87 stack exception on 32-bit x86

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
(In reply to Andrew Church from comment #3)
> I use __builtin_return(__builtin_apply(...)) in library function wrappers
> for failure injection in tests, so that I don't need to explicitly write out
> all the arguments multiple times for each wrapped function.  As such, I
> don't need the full functionality of __builtin_apply() in being able to save
> and later return an arbitrary value, but it would be useful to have an
> equivalent to the combination __builtin_return(__builtin_apply(...)) --
> perhaps something which restored the register/stack state to that at
> function entry and jumped to the target function (e.g., jmp *%eax/rax on
> x86).

You can use __attribute__((__target__("no-mmx"))):

(from gcc.target/i386/builtin-apply-mmx.c):

--cut here--
double
foo (double arg)
{
  if (arg != 116.0)
abort ();

  return arg + 1.0;
}

inline double
__attribute__((__target__("no-mmx")))
bar (double arg)
{
  foo (arg);
  __builtin_return (__builtin_apply ((void (*)()) foo,
 __builtin_apply_args (), 16));
}

static void
mmx_test (void)
{
  if (bar (116.0) != 117.0)
abort ();
}
--cut here--

[Bug target/71657] Wrong code on trunk gcc (std::out_of_range), westmere

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

   Keywords||ra, wrong-code
 CC||andrew.burgess at embecosm dot 
com
   ||, claziss at gcc dot gnu.org,
   ||clm at codesourcery dot com,
   ||matthew.fortune at imgtec dot 
com,
   ||vmakarov at redhat dot com,
   ||vries at gcc dot gnu.org

--- Comment #10 from Tom de Vries  ---
> * config/i386/i386.c (TARGET_SPILL_CLASS): #if 0 out the definition.
> (ix86_spill_class): Disable to always return NO_REGS.

This fixes the PR for i386, but I get the impression from "Suspended until the
infrastructure is ready" that the problem is not in the target hook definition. 

Meaning that this PR may still occur for the other archs that define the target
hook: mips and arc.

Shouldn't we disable this optimization in the common code?

[Bug tree-optimization/83299] result of pointer addition can be assumed to be less than or equal to PTRDIFF_MAX

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
As an implementation detail, the argument to POINTER_PLUS is always unsigned...
(maintainers are in favor of changing that, but someone needs to do the work)

Also, we now quickly simplify p-q to -i, which loses this information.

[Bug c++/83300] New: Segmentation fault with template and __attribute__((vector_size (sizeof(int) * N)));

[johnchen902 at paga dot moe]

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

Bug ID: 83300
   Summary: Segmentation fault with template and
__attribute__((vector_size (sizeof(int) * N)));
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johnchen902 at paga dot moe
  Target Milestone: ---

I found this while attempting to write generic vectorized code.
Code:
==
template
using vtsi = int __attribute__((vector_size (sizeof(int) * N)));

void f(vtsi<4>) {}
==
Command line:
g++ a.cpp
==
Output:
g++: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug tree-optimization/83296] missing -Wstringop-overflow due to missing range info for MAX_EXPR

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
Note that -fdump-tree-optimized-all includes the range information in the dump.
Normally, we know how to derive a range for MAX_EXPR, but in this case the
MAX_EXPR only appears in phiopt3, later than VRP2. On the other hand, we knew
the range before phiopt, and phiopt for some reason decided to use a new
SSA_NAME and drop the range, that looks suboptimal.

[Bug tree-optimization/79119] absolute value of a pointer difference can be assumed to be less than or equal to PTRDIFF_MAX

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
With POINTER_DIFF_EXPR, things may be easier. One of the things I suggested
when introducing it was that VRP could always use a range of [ -PTRDIFF_MAX,
PTRDIFF_MAX ] for them. If you had written

  __PTRDIFF_TYPE__ d = q - p;
  __SIZE_TYPE__ n = (d < 0) ? -d : d;

that would suffice to simplify f. (With the code above, g is already optimized)

We could improve phiopt abs_replacement so it understands versions with
MINUS_EXPR (that's necessary for other PRs anyway), and versions with pointers.

Teaching VRP that p0 looks like more work...

[Bug target/83292] __builtin_apply(), __builtin_return() trigger x87 stack exception on 32-bit x86

[achurch+gcc at achurch dot org]

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

--- Comment #3 from Andrew Church  ---
I use __builtin_return(__builtin_apply(...)) in library function wrappers for
failure injection in tests, so that I don't need to explicitly write out all
the arguments multiple times for each wrapped function.  As such, I don't need
the full functionality of __builtin_apply() in being able to save and later
return an arbitrary value, but it would be useful to have an equivalent to the
combination __builtin_return(__builtin_apply(...)) -- perhaps something which
restored the register/stack state to that at function entry and jumped to the
target function (e.g., jmp *%eax/rax on x86).

[Bug libfortran/78549] Very slow formatted internal file output

[jvdelisle at gcc dot gnu.org]

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

--- Comment #30 from Jerry DeLisle  ---
Not quite fixed yet. I have found:

==17070== 88 bytes in 1 blocks are definitely lost in loss record 3 of 9
==17070==at 0x4C31B25: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==17070==by 0x4E580E6: _gfortrani_xcalloc (memory.c:83)
==17070==by 0x503D64E: _gfortrani_open_internal4 (unix.c:1031)
==17070==by 0x503BCCB: _gfortrani_set_internal_unit (unit.c:495)
==17070==by 0x503C2E4: _gfortrani_get_unit (unit.c:556)
==17070==by 0x503A0FF: data_transfer_init (transfer.c:2680)
==17070==by 0x40122E: MAIN__ (dtio_14.f90:59)
==17070==by 0x401442: main (dtio_14.f90:41)

and

==17070==at 0x4C2FB0F: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==17070==by 0x4E58048: _gfortrani_xmalloc (memory.c:42)
==17070==by 0x5043F53: _gfortrani_fbuf_init (fbuf.c:41)
==17070==by 0x503C2F1: _gfortrani_get_unit (unit.c:557)
==17070==by 0x503A0FF: data_transfer_init (transfer.c:2680)
==17070==by 0x401004: MAIN__ (dtio_14.f90:51)
==17070==by 0x401442: main (dtio_14.f90:41)
==17070== 

with valgrind

We are missing freeing these structures.

[Bug tree-optimization/83299] New: result of pointer addition can be assumed to be less than or equal to PTRDIFF_MAX

[msebor at gcc dot gnu.org]

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

Bug ID: 83299
   Summary: result of pointer addition can be assumed to be less
than or equal to PTRDIFF_MAX
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

This may be due to the same underlying limitation as pr79119, but it seems that
it should be easier to infer from the type of the argument of a POINTER_PLUS
expression that the result cannot be less than the first operand when the
integer operand is unsigned.

If it isn't any easier feel free to resolve this as a duplicate of pr79119.

$ cat a.c && gcc -O3 -S -fdump-tree-optimized=/dev/stdout a.c
typedef __SIZE_TYPE__ size_t;

void f (char *p, size_t i)
{
  char *q = p + i;   // i must be less than or equal to PTRDIFF_MAX

  if ((size_t)(p - q) > __PTRDIFF_MAX__)   // cannot be true
__builtin_abort ();
}

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

f (char * p, size_t i)
{
  signed long _5;

   [local count: 1073741825]:
  _5 = (signed long) i_2(D);
  if (_5 > 0)
goto ; [0.00%]
  else
goto ; [99.96%]

   [count: 0]:
  __builtin_abort ();

   [local count: 1073312327]:
  return;

}

[Bug middle-end/83239] False positive from -Wstringop-overflow on simple std::vector code

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #11 from Martin Sebor  ---
I agree that the standard should say more about when max_size() is used.  I
proposed that in LWG 580 but the LWG resolved it as NAD.  It wasn't the first
time this came up.  LWG 197 pointed out the underspecification way back in 1999
but the LWG resolved that one as NAD as well.  The latest discussion only
highlights that the issue hasn't been put to rest.

Jon, I posted an updated patch for you to consider:
https://gcc.gnu.org/ml/libstdc++/2017-12/msg00023.html

[Bug fortran/83282] missing comma in format changes output

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #2 from Jerry DeLisle  ---
Ha Ha, this is like not seeing the forest for the trees. As soon as I figure
out which comma is missing I will try to fix. Dominique, feel free to try to
find the issue, My guess is format.c, in the parsing sequences.

[Bug middle-end/81897] [6/7/8 Regression] spurious -Wmaybe-uninitialized warning

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org

--- Comment #6 from Aldy Hernandez  ---
(In reply to Jeffrey A. Law from comment #5)
> It really depends on the growth necessary to expose the thread.  I haven't
> tried to evaluate that -- clearly if the code growth is unacceptable then
> threading is the wrong answer.
> 
> In general we should start each investigation of this kind of bug with an
> analysis of what the threader has missed and the pros/cons of addressing the
> missed thread.

FWIW, with the newer backwards threader work we thread two different paths of 5
and 7 insns each.  This sets up the CFG in such a way that DOM3 and VRP2 can
continue massaging the input such that by the time we get to the uninit pass,
"dst" is known to have a value of either f() or 0, and no warning is produced:

  dst_23 = f ();
...
...
  # dst_2 = PHI <0(5), dst_23(14), dst_23(16), dst_23(11), dst_23(18)>
  return dst_2;

I don't see a substantial increase in block duplication.  The new threader
yields 11 blocks vs the old threader with 10 (and a spurious warning :)).

But alas, this work won't land in GCC 8 :-(.

[Bug tree-optimization/83298] New: wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

Bug ID: 83298
   Summary: wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

This appears to be a recent regression. 

$ gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.0 20171205 (experimental) [trunk revision 255434] (GCC) 
$ 
$ gcctk -O0 small.c; ./a.out
$ gcc-7.2.0 -O1 small.c; ./a.out
$ 
$ gcctk -O1 small.c
$ ./a.out
Aborted (core dumped)
$ 





int a, b, c = 1;

int main ()
{
  for (; b < 1; b++)
;
  if (!(c * (a < 1))) 
__builtin_abort ();
  return 0; 
}

[Bug c++/79094] Pack expansion in using-declaration rejects an attempt to inherit a pack of constructors

[fidget324 at gmail dot com]

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

--- Comment #2 from Scott Constable  ---
This is still an issue in 7.2.0.

[Bug target/83297] Internal Compiler Error

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |target

--- Comment #1 from Andrew Pinski  ---
/u/suhubdyd/frameworks/pytorch/torch/lib/TH/THMath.h:10:3: internal compiler
error: Illegal instruction
   return 1.0 / (1.0 + exp(-value));

I am 99% sure this is an issue with your GMP and/or MPFR.

[Bug c/83297] New: Internal Compiler Error

[suhubdyd at iro dot umontreal.ca]

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

Bug ID: 83297
   Summary: Internal Compiler Error
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: suhubdyd at iro dot umontreal.ca
  Target Milestone: ---

```bash
gcc -v

└─ λ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--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-4.9-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Debian 4.9.2-10)
```

When compiling a deep learning framework called `Pytorch` I encountered this
ICE


```
(lisa) ┌─── suhubdyd@bart12 [~/frameworks/pytorch] ((v0.3.0))
└─ λ CUDA_VISIBLE_DEVICES="" python setup.py install
running install
running build_deps
CMake Deprecation Warning at CMakeLists.txt:5 (CMAKE_POLICY):
  The OLD behavior for policy CMP0026 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.


CMake Warning (dev) at
/u/suhubdyd/.local/share/cmake-3.9/Modules/FindOpenMP.cmake:277 (if):
  if given arguments:

"TRUE"

  An argument named "TRUE" appears in a conditional statement.  Policy
  CMP0012 is not set: if() recognizes numbers and boolean constants.  Run
  "cmake --help-policy CMP0012" for policy details.  Use the cmake_policy
  command to set the policy and suppress this warning.
Call Stack (most recent call first):
  /u/suhubdyd/.local/share/cmake-3.9/Modules/FindOpenMP.cmake:380
(_OPENMP_GET_SPEC_DATE)
  CMakeLists.txt:86 (FIND_PACKAGE)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Found OpenMP_C: -fopenmp (found version "1.0")
CMake Warning (dev) at
/u/suhubdyd/.local/share/cmake-3.9/Modules/FindOpenMP.cmake:277 (if):
  if given arguments:

"TRUE"

  An argument named "TRUE" appears in a conditional statement.  Policy
  CMP0012 is not set: if() recognizes numbers and boolean constants.  Run
  "cmake --help-policy CMP0012" for policy details.  Use the cmake_policy
  command to set the policy and suppress this warning.
Call Stack (most recent call first):
  /u/suhubdyd/.local/share/cmake-3.9/Modules/FindOpenMP.cmake:380
(_OPENMP_GET_SPEC_DATE)
  CMakeLists.txt:86 (FIND_PACKAGE)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Found OpenMP_CXX: -fopenmp (found version "1.0")
-- Compiling with OpenMP support
-- Could not find hardware support for NEON on this machine.
-- No OMAP3 processor on this machine.
-- No OMAP4 processor on this machine.
-- SSE2 Found
-- SSE3 Found
-- AVX Found
-- TH_SO_VERSION: 1
-- Atomics: using GCC intrinsics
-- Checking for [mkl_gf_lp64 - mkl_gnu_thread - mkl_core - gomp - pthread - m -
dl]
--   Library mkl_gf_lp64: /Tmp/lisa/os_v5/anaconda/lib/libmkl_gf_lp64.so
--   Library mkl_gnu_thread: /Tmp/lisa/os_v5/anaconda/lib/libmkl_gnu_thread.so
--   Library mkl_core: /Tmp/lisa/os_v5/anaconda/lib/libmkl_core.so
CMake Warning (dev) at
/u/suhubdyd/.local/share/cmake-3.9/Modules/FindOpenMP.cmake:277 (if):
  if given arguments:

"TRUE"

  An argument named "TRUE" appears in a conditional statement.  Policy
  CMP0012 is not set: if() recognizes numbers and boolean constants.  Run
  "cmake --help-policy CMP0012" for policy details.  Use the cmake_policy
  command to set the policy and suppress this warning.
Call Stack (most recent call first):
  /u/suhubdyd/.local/share/cmake-3.9/Modules/FindOpenMP.cmake:380
(_OPENMP_GET_SPEC_DATE)
  cmake/FindMKL.cmake:121 (FIND_PACKAGE)
  

[Bug libstdc++/83120] [8 Regression] ext/special_functions/hyperg failure on AIX

[3dw4rd at verizon dot net]

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

--- Comment #4 from Ed Smith-Rowland <3dw4rd at verizon dot net> ---
In my regen of the testcases, I clobbered some dg-extra-options or something.

[Bug tree-optimization/82646] bogus -Wstringop-overflow with -D_FORTIFY_SOURCE=2 on strncpy with range to a member array

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #4 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2017-12/msg00277.html

[Bug tree-optimization/83296] New: missing -Wstringop-overflow due to missing range info for MAX_EXPR

[msebor at gcc dot gnu.org]

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

Bug ID: 83296
   Summary: missing -Wstringop-overflow due to missing range info
for MAX_EXPR
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The call to strncpy() in the program below overflows the destination by 1 byte.
 The overflow is diagnosed when compiled by GCC (as a C program) but not when
compiled by G++ (as a C++ program).  The only difference between the two is
that in C, the prephitmp_10 strncpy argument has range info attached to it,
while in C++ it does not.  As a result, the get_range_info() function used to
retrieve the range succeeds in C but fails in C++.

$ (set -x && cat a.c && for lang in c c++; do gcc -O2 -S -Wstringop-overflow=2
-fdump-tree-optimized=/dev/stdout -x$lang a.c; done)
+ cat a.c
struct S {
  char a[5];
  void (*pf)(void);
};

void f (struct S *s, int n)
{
  if (n < sizeof s->a + 1)
n = sizeof s->a + 1;

  __builtin_strncpy (s->a, "123456", n);   // missing warning in C++
}
+ for lang in c c++
+ gcc -O2 -S -Wstringop-overflow=2 -fdump-tree-optimized=/dev/stdout -xc a.c

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

f (struct S * s, int n)
{
  unsigned int n.0_1;
  char[5] * _3;
  int _4;
  long unsigned int prephitmp_10;

   [local count: 1073741825]:
  n.0_1 = (unsigned int) n_5(D);
  if (n.0_1 <= 5)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870913]:

   [local count: 1073741825]:
  # _4 = PHI 
  prephitmp_10 = (long unsigned int) _4;   // has range info
  _3 = _6(D)->a;
  __builtin_strncpy (_3, "123456", prephitmp_10); [tail call]
  return;

}


a.c: In function ‘f’:
a.c:11:3: warning: ‘__builtin_strncpy’ writing 6 or more bytes into a region of
size 5 overflows the destination [-Wstringop-overflow=]
   __builtin_strncpy (s->a, "123456", n);   // missing warning in C++
   ^
+ for lang in c c++
+ gcc -O2 -S -Wstringop-overflow=2 -fdump-tree-optimized=/dev/stdout -xc++ a.c

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

f (struct S * s, int n)
{
  long unsigned int _1;
  char[5] * _3;
  long unsigned int prephitmp_4;

   [local count: 1073741825]:
  _1 = (long unsigned int) n_5(D);
  prephitmp_4 = MAX_EXPR <6, _1>;   // no range info
  _3 = _6(D)->a;
  __builtin_strncpy (_3, "123456", prephitmp_4); [tail call]
  return;

}

[Bug tree-optimization/80641] [7/8 Regression] Warning with std::vector resize in loop

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #5 from Jeffrey A. Law  ---
So an interesting little bug.   Definitely similar to 79095 from last round.

So I'm going to highlight two blocks.
  [local count: 1073086475]:
  # c$D15286$_M_impl$_M_finish_32 = PHI 
  _15 = c$D15286$_M_impl$_M_finish_32 - _130;
  _14 = _15 /[ex] 4;
  _11 = (long unsigned int) _14;
  if (c$D15286$_M_impl$_M_finish_32 != _130)
goto ; [92.50%]
  else
goto ; [7.50%]

Assume that bb7 is uninteresting and that it transfers control to bb8.

  [local count: 918159614]:
  sz_17 = _11 + 18446744073709551615;
  if (_11 < sz_17)
goto ; [33.00%]
  else
goto ; [67.00%]

If you review 79095, you'll see the similarities.  The difference is the
pointer arithmetic doesn't sink into a convenient spot (which would be bb8).  
I believe if the pointer arith sunk into bb8, then the right things would "just
happen".

bb6->bb7->bb8 implies that _32 != _130.  From that we can derive that _15, _14
and _11 are all ~[0, 0].  Which should then allow us to optimize the overflow
test in bb8 so that it always transfers control to bb12 which would in turn
avoid the warning.

So the first problem is sinking doesn't think it's profitable to sink those
statements.  If I hack around that BB8 looks like this after sinking:

 _15 = c$D15286$_M_impl$_M_finish_32 - _39;
  _14 = _15 /[ex] 4;
  _11 = (long unsigned int) _14;
  sz_17 = _11 + 18446744073709551615;
  if (_11 < sz_17)
goto ; [33.00%]
  else
goto ; [67.00%]

So.  Progress.   But not enough. ch_vect (copy headers for vectorizer?) comes
along and turns that into:

  # c$D15286$_M_impl$_M_finish_56 = PHI <_37(27),
c$D15286$_M_impl$_M_finish_115(28)>
  _15 = c$D15286$_M_impl$_M_finish_56 - _39;
  _14 = _15 /[ex] 4;
  _11 = (long unsigned int) _14;
  sz_17 = _11 + 18446744073709551615;
  if (_11 < sz_17)
goto ; [33.00%]
  else
goto ; [67.00%]


The PHI is undesirable.  If I turn off vectorization to disable vect_ct DOM (by
way of its embedded EVRP analyzer) is able to discover bb8 must transfer
control to bb12 -- which makes the problematic memset unreachable and the
warning disappear.

So two things..

1. Figure out why sinking is so pessimistic.

2. Avoid loop header copying

And this will "just work"

[Bug c/83294] int32_t & related definitions wrong with -funsigned-bitfields

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
FWIW, current glibc already uses signed int for int32_t (via using it for 
__int32_t which is used to define int32_t), entirely as an accident 
following a header refactoring, but not for other types such as 
int_least32_t or int_fast32_t (so a glibc issue would still be appropriate 
for those other types).

[Bug c/83294] int32_t & related definitions wrong with -funsigned-bitfields

[bugdal at aerifal dot cx]

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

--- Comment #2 from Rich Felker  ---
I agree it's not clear if there's a conformance distinction or just a QoI
issue, but it seems really unfortunate for int32_t not to be usable in
bitfields if -funsigned-bitfields might be passed to GCC, since the exact-sized
types from stdint.h are ideally suited to the same sort of "fixed memory
layout" situations where people like to use bitfields, and since there's no
other portable way to request a 32-bit signed type. So I think it would be nice
to "fix" this either way.

[Bug c/83294] int32_t & related definitions wrong with -funsigned-bitfields

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
I'm not aware of a standard requirement not to use plain int for int32_t 
(even with unsigned bit-fields), though it may well be useful to make the 
signedness explicit.  After all, int is a signed integer type with 32 bits 
in the cases where it's used for int32_t.  (However, plain char is never 
OK as int8_t / uint8_t etc. because char is an integer type but not a 
signed integer type or unsigned integer type.)

On most platforms, except with -ffreestanding GCC just wraps libc's 
stdint.h, so this is mostly a libc quality-of-implementation issue, not 
just a GCC one.

[Bug libgomp/83295] New: libgomp complains about trying to map data that is already mapped

[pophaless at ornl dot gov]

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

Bug ID: 83295
   Summary: libgomp complains about trying to map data that is
already mapped
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pophaless at ornl dot gov
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 42798
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42798=edit
full test to reproduce bug.

Executing the attached code with gcc/7.1.1-20170802 cuda/8.0.61-1

code snippet:
/* Initialize arrays a, b and c */
#pragma omp target enter data if(size > SIZE_THRESHOLD) map(to: size) map(to:
c[0:size])

#pragma omp target if(size > SIZE_THRESHOLD)  \
map(to: a[0:size], b[0:size])  map(tofrom: isHost)\
map(from: isOffloading)
{
isOffloading = !omp_is_initial_device();
isHost = omp_is_initial_device();
int alpha = (isHost ? 0 : 1);
int j = 0;
for (j = 0; j < size; j++) {
  // c[j] is zero if executed in the host
  // c[j] is 1+j if executed on the device
  c[j] = alpha*(a[j] + b[j]);
}
} // end target
#pragma omp target exit data if(size > SIZE_THRESHOLD) map(from: c[0:size])

/*Check if array c was updated correctly*/

Compile line: gcc -O3 -std=c99 -fopenmp -foffload="-lm" -lm test.c -o tst
Compiles without error.

Error message at execution:
libgomp: Trying to map into device [0x3fffc8f1a9e0..0x3fffc8f1b9e0) object when
[0x3fffc8f1a9e0..0x3fffc8f1b5e0) is already mapped

[Bug c++/79228] 'i' suffix for __complex__ extension interferes with C++14 UDLs for std::complex

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Dec  5 21:00:15 2017
New Revision: 255434

URL: https://gcc.gnu.org/viewcvs?rev=255434=gcc=rev
Log:
PR c++/79228
* expr.c (interpret_float_suffix): Avoid memcmp.
(interpret_int_suffix): Likewise.  Don't check for if.

Modified:
trunk/libcpp/ChangeLog
trunk/libcpp/expr.c

[Bug c/83294] New: int32_t & related definitions wrong with -funsigned-bitfields

[bugdal at aerifal dot cx]

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

Bug ID: 83294
   Summary: int32_t & related definitions wrong with
-funsigned-bitfields
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugdal at aerifal dot cx
  Target Milestone: ---

The following minimal test case fails with -funsigned-bitfields:

struct { int32_t x:1 } foo;
foo.x = -1;
assert(foo.x < 0);

This is because __INT32_TYPE__, etc. are defined as plain "int" rather than
"signed int", and C specifies that, when the implementation interprets plain
int as unsigned in a bitfield context, it must also do this for typedefs (see
footnote 125 in n1570).

Presumably changing __INT32_TYPE__ and related macros to an explicit "signed
int" will fix the problem.

[Bug tree-optimization/83293] [8 regression] ICE: in gsi_insert_seq_nodes_after, at gimple-iterator.c:278

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-12-05
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r255021.  Will have a look tomorrow.

[Bug tree-optimization/82646] bogus -Wstringop-overflow with -D_FORTIFY_SOURCE=2 on strncpy with range to a member array

[law at redhat dot com]

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

--- Comment #3 from Jeffrey A. Law  ---
Sorry.  I shouldn't have closed this.

[Bug c++/82331] [7/8 Regression] ICE specializing template for function pointer

[paolo.carlini at oracle dot com]

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

--- Comment #5 from Paolo Carlini  ---
Double checked that both the bugs I resolved as duplicates are also fixed.
Thanks!

[Bug libstdc++/83279] std::experimental::filesystem::copy_file can't copy larger files than 2.0GiB

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
OK I'll try to reproduce it as soon as I can.

[Bug middle-end/83239] False positive from -Wstringop-overflow on simple std::vector code

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
It was pointed out to me that the allocator in my example should not allocate
more than its max_size, so the example isn't reasonable. So the invariant in
Martin's patch is OK.

[Bug tree-optimization/83293] New: [8 regression] ICE: in gsi_insert_seq_nodes_after, at gimple-iterator.c:278

[trippels at gcc dot gnu.org]

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

Bug ID: 83293
   Summary: [8 regression] ICE: in gsi_insert_seq_nodes_after,  at
gimple-iterator.c:278
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: needs-bisection
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

trippels@gcc67 ~ % cat XMPMeta-Serialize.ii
typedef long unsigned size_t;
template  struct A {
  _Iterator _M_current;
  A(_Iterator p1) : _M_current(p1) {}
  _Iterator m_fn1() { return _M_current; }
};
template 
int operator==(A<_IteratorL, _Container> p1, A<_IteratorR, _Container> p2) {
  return p1.m_fn1() == p2.m_fn1();
}
struct B {
  struct {
int *_M_start;
int *_M_finish;
  } _M_impl;
};
struct C : B {
  A m_fn2() { return _M_impl._M_start; }
  A m_fn3() { return _M_impl._M_finish; }
  size_t m_fn4() { return _M_impl._M_finish - _M_impl._M_start; }
  int m_fn5() { return m_fn2() == m_fn3(); }
};
struct XMP_Node {
  C qualifiers;
} a;
size_t b;
size_t EstimateRDFSize(int p1) {
  size_t c(p1 * b);
  if (!a.qualifiers.m_fn5()) {
p1 += 2;
for (size_t d = 0, e = a.qualifiers.m_fn4(); d < e; ++d)
  c += EstimateRDFSize(0);
  }
  c += (p1 - 1) * b;
  return c;
}

trippels@gcc67 ~ % g++ -O2 -c XMPMeta-Serialize.ii
during GIMPLE pass: slsr
XMPMeta-Serialize.ii: In function ‘size_t EstimateRDFSize(int)’:
XMPMeta-Serialize.ii:27:8: internal compiler error: in
gsi_insert_seq_nodes_after, at gimple-iterator.c:278
 size_t EstimateRDFSize(int p1) {
^~~
0xada0d3 gsi_insert_seq_nodes_after
../../gcc/gcc/gimple-iterator.c:278
0x154254f insert_initializers
../../gcc/gcc/gimple-ssa-strength-reduction.c:3421
0x154254f analyze_candidates_and_replace
../../gcc/gcc/gimple-ssa-strength-reduction.c:3896
0x154254f execute
../../gcc/gcc/gimple-ssa-strength-reduction.c:3978

[Bug libstdc++/83279] std::experimental::filesystem::copy_file can't copy larger files than 2.0GiB

[ta12ba34 at gmail dot com]

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

--- Comment #5 from T B  ---
Both seem to have large file support enabled, it outputs both times enabled.

[Bug libstdc++/83279] std::experimental::filesystem::copy_file can't copy larger files than 2.0GiB

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
What does this output, for both gcc-5 and gcc-7?

#include 
int main()
{
  std::cout << "Large file support: "
#ifdef _GLIBCXX_USE_LFS
"enabled"
#else
"disabled"
#endif
  "\n";
}

[Bug tree-optimization/82103] spurious stringop-overflow warning

[law at redhat dot com]

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

--- Comment #6 from Jeffrey A. Law  ---
It should.  It may not though because one the n != 0 test is removed, the
resulting range of N is probably VR_VARYING rather than ~[0,0] at the call to
memset.

The former signifies we know nothing about the length and given how often that
likely occurs in practice I suspect the warning code suppresses the warning in
that case.

The latter says we know the range is everything except 0.  With that sliver of
information the warnings kick in.

It's a bit of speculation on my part, but it's informed speculation.

[Bug middle-end/81876] [7 Regression] bogus -Wstrict-overflow warning with -O3

[law at redhat dot com]

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

--- Comment #4 from Jeffrey A. Law  ---
Richi.

I do worry about cases where we exploit strict-overflow semantics.  It'd be
nice to be able to warn about them, but I certainly agree that stability is a
problem.  With instability, messaging to and expectations of the user community
become serious concerns.  I won't object to moving them out of the middle end.

WRT locations/diagnostics for things like ldist where GCC conjures up code that
has little resemblance to what the user wrote.  It's a real issue once we issue
the warning -- the user has no clue what it meant.

On the other hand those warnings (particularly those that result from ldist)
are highlighting real issues.  Bogus user code, poor optimization, even
under-specified language from ISO.  Examples of all can be found in BZ.

[Bug target/83292] __builtin_apply(), __builtin_return() trigger x87 stack exception on 32-bit x86

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
I suspect __builtin_apply, __builtin_return and should most likely be
deprecated and removed latter on.  They are less useful and don't work for most
things.  libffi is more useful than them now.

[Bug target/83292] __builtin_apply(), __builtin_return() trigger x87 stack exception on 32-bit x86

[achurch+gcc at achurch dot org]

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

Andrew Church  changed:

   What|Removed |Added

Summary|__builtin_apply() triggers  |__builtin_apply(),
   |x87 stack exception on  |__builtin_return() trigger
   |32-bit x86  |x87 stack exception on
   ||32-bit x86

--- Comment #1 from Andrew Church  ---
For the record, __builtin_return() has the same problem of mixing x87 and MMX
instructions, so this doesn't work around the problem when using
__builtin_return():

void *retval = __builtin_apply(...);
__asm__ volatile("finit");  // reset x87 state
__builtin_return(retval);  // corrupts x87 state again

[Bug c++/82331] [7/8 Regression] ICE specializing template for function pointer

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Tue Dec  5 18:05:23 2017
New Revision: 255430

URL: https://gcc.gnu.org/viewcvs?rev=255430=gcc=rev
Log:
PR c++/82331 - ICE with variadic partial specialization of auto

* pt.c (unify) [TEMPLATE_PARM_INDEX]: Set processing_template_decl
around call to tsubst.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/nontype-auto13.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c/78768] -Walloca-larger-than and -Wformat-length warnings disabled by -flto

[msebor at gcc dot gnu.org]

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

--- Comment #12 from Martin Sebor  ---
Yes, r244537 is the revision I meant, thank you.  The test still isn't quite
correct, though, because, as pr79062 and pr82770 point out, it fails to detect
the missing sprintf warning in separate compilation.

[Bug c/78768] -Walloca-larger-than and -Wformat-length warnings disabled by -flto

[thopre01 at gcc dot gnu.org]

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

--- Comment #11 from Thomas Preud'homme  ---
(In reply to Martin Sebor from comment #10)
> The test was changed to link-only (to exercise LTO) in r244385.

I think you meant r244537
(https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/testsuite/gcc.dg/pr78768.c?r1=244537=244536=244537)

Best regards,

Thomas

[Bug c++/83287] [8 Regression] ice in tsubst_copy, at cp/pt.c:14884

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #4 from Nathan Sidwell  ---
Fixed 255429.

[Bug libstdc++/83279] std::experimental::filesystem::copy_file can't copy larger files than 2.0GiB

[ta12ba34 at gmail dot com]

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

--- Comment #3 from T B  ---
I recompiled the GCC 7.2.0 with this configuration:
--enable-threads=posix --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu --enable-checking=release --enable-languages=c,c++
--program-suffix=-7.2 --disable-multilib --enable-c99
--enable-libstdcxx-filesystem-ts
But it does not have any effect. It seems that the libstdc++fs is corrupted. If
I replace the libstdc++fs.a file with the lib-file of GCC 5.4 it works fine.
Any ideas?

[Bug target/83292] New: __builtin_apply() triggers x87 stack exception on 32-bit x86

[achurch+gcc at achurch dot org]

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

Bug ID: 83292
   Summary: __builtin_apply() triggers x87 stack exception on
32-bit x86
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: achurch+gcc at achurch dot org
  Target Milestone: ---

Calling a function with __builtin_apply() on 32-bit x86 causes the next x87
instruction to raise an x87 stack exception, as a side effect of mixing MMX
instructions (saving %mm[0-2]) and x87 instructions (fstp after the function
call, I presume to pop possible return values off the x87 stack).

Note that it's not possible to completely work around this with -mfpmath=sse
because fild is still used to load a 64-bit integer (s/int/long long/ in the
test case below).

The problem occurs at least as far back as GCC 5.4.0; I haven't tested earlier
versions.

Editing the generated assembly to bracket the __builtin_apply() code with
fstenv/fldenv seems to fix the problem.

Testcase:
==
void foo(void)
{
}

int main(void)
{
__builtin_apply(foo, __builtin_apply_args(), 0);
volatile int i = 1;
float f = i;
return f==1.0f ? 0 : 1;
}
==

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

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On December 5, 2017 4:23:17 PM GMT+01:00, "sergey.shalnov at intel dot com"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65930
>
>sergey.shalnov at intel dot com changed:
>
>   What|Removed |Added
>
>CC||sergey.shalnov at intel dot com
>
>--- Comment #4 from sergey.shalnov at intel dot com ---
>Richard,
>I can confirm that the issue exists and it can be solved by make data
>types of
>accumulator and equation equal.
>As I can see you propose to introduce intermediate internal accumulator
>in
>uint32 type and store it into accumulator (int) later. Please correct
>me if I'm
>wrong.
>
>Anyway, may I, please, propose a bit simpler way to solve the issue?
>In GIMPLE statement we have (in the place of reduction
>tree-vect=loop.c:2877):
>"sum_12 = (int) _6;"
>
>I believe the issue disappears if we change it to:
>"sum_12 = _6;"
>
>I'm not sure but, if I remember correctly, the C standard treat these
>types
>(uint->int) casting as "undefined behavior". In this case, the compiler
>can do
>this type cast(it might be under some command line switches).
>
>What do you think, could it help?

This is what the patch tries to do transparent in the vectorizer. Doing it
generally isn't valid.

[Bug c++/83287] [8 Regression] ice in tsubst_copy, at cp/pt.c:14884

[nathan at gcc dot gnu.org]

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

--- Comment #3 from Nathan Sidwell  ---
Author: nathan
Date: Tue Dec  5 17:29:58 2017
New Revision: 255429

URL: https://gcc.gnu.org/viewcvs?rev=255429=gcc=rev
Log:
[PR C++/83287] Mark lookup for keeping

https://gcc.gnu.org/ml/gcc-patches/2017-12/msg00242.html
PR c++/83287
* tree.c (build_min): Check CAST_EXPR arg for OVERLOADs.

* g++.dg/lookup/pr83287.C: New.

Added:
trunk/gcc/testsuite/g++.dg/lookup/pr83287.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/82046] [7/8 Regression] Bogus -fsanitize=undefined error with -O2 -Wall

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
I don't have a huge problem with closing this as won't fix.  I do hope to get
around to pr79265 and eliminate some of the unnecessary instrumentation to
improve the efficiency of the instrumented code.  If that also happens to avoid
some warnings that will be a nice bonus.

[Bug middle-end/83239] False positive from -Wstringop-overflow on simple std::vector code

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to Martin Sebor from comment #6)
> This libstdc++ patch helps avoid both the warning and the bogus memset.  if
> Jonathan isn't opposed to this kind of annotation I think there might be
> other places in vector where this approach could improve the emitted object
> code.
> 
> diff --git a/libstdc++-v3/include/bits/vector.tcc
> b/libstdc++-v3/include/bits/vector.tcc
> index eadce3c..8093f5e 100644
> --- a/libstdc++-v3/include/bits/vector.tcc
> +++ b/libstdc++-v3/include/bits/vector.tcc
> @@ -582,8 +582,13 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
>  {
>if (__n != 0)
>   {
> -   if (size_type(this->_M_impl._M_end_of_storage
> - - this->_M_impl._M_finish) >= __n)
> +   size_type __navail = size_type(this->_M_impl._M_end_of_storage
> +- this->_M_impl._M_finish);
> +
> +   if (__navail > max_size () - size ())
> + __builtin_unreachable ();

In principle I'm strongly in favour of adding annotations like this to help the
compiler reason about our components like std::vector.

However, this touches on a topic I raised on the LWG reflector last week: what
does max_size() mean? What happens if we exceed it?

Here's a program which creates a vector larger than its own max_size()

#include 
#include 

template
struct Alloc {
  using value_type = T;
  template struct rebind { using other = Alloc; };
  Alloc() = default;
  template Alloc(const Alloc&) { }

  T* allocate(std::size_t n) { return std::allocator().allocate(n); }
  void deallocate(T* p, std::size_t n) { std::allocator().deallocate(p, n);
}

  std::size_t max_size() const noexcept { return 100; }
};

template
bool operator==(const Alloc&, const Alloc&) { return true; }
template
bool operator!=(const Alloc&, const Alloc&) { return false; }

int main()
{
  std::vector v(Alloc().max_size() + 1);
  assert(v.size() > v.max_size());
}

I think Martin's patch would make this undefined, but the standard doesn't
actually say it's undefined to exceed max_size(). So the patch isn't OK.

I think failing to say what happens if you exceed max_size() is a defect in the
standard, but maybe it's a bug in our implementation and we need to add extra
code to ensure we don't try to grow larger than max_size(). With either of
those changes, the patch seems OK to me.

[Bug testsuite/82770] [8 regression] gcc.dg/pr78768.c xpass

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
So remove the xfail from the test and keep some (non-regression?) PR where you
track the rest?

[Bug testsuite/82770] [8 regression] gcc.dg/pr78768.c xpass

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-12-05
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
The test passes but the problem the assertion is meant to verify (bug 79062)
still persists.  That's because the test is compiled and linked in one step. 
To verify whether or not the problem has been fixed it needs to be compiled and
linked separately.  I think this can be done in the gcc.dg/lto directory but
lto.exp apparently has no support for checking for warnings:

  WARNING: lto.exp does not support dg-warning

So I can confirm the XPASS, but unless there's something I'm missing it will
take some time to handle this the right way.

[Bug middle-end/83239] False positive from -Wstringop-overflow on simple std::vector code

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org

--- Comment #8 from Jeffrey A. Law  ---
Jon's call on the annotation, obviously.

In theory that kind of annotation should be zero cost as there is no code on
the __builtin_unreachable path which in turn allows the various optimizers to
remove the __builtin_unreachable as well as the controlling condition.

I know from recent work a __builtin_unreachable like this can sneak through the
gimple optimizers.  But it was a pretty oddball case involving computed jumps
where the computed jump target was an empty __builtin_unreachable block. 
Similarly I just fixed a bug where the ranges implied by the
__builtin_unreachables were getting lost.

My point for Jon is that while these are supposed to be zero cost ways to
describe situations that aren't supposed to happen, a little verification seems
wise :-)

[Bug tree-optimization/81165] [8 Regression] Regression in GCC-8.0.0's optimizer

[law at redhat dot com]

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

--- Comment #12 from Jeffrey A. Law  ---
In general we can't know if we're going to have a single argument PHI after
threading.   If the block has multiple preds that thread to the same final
destination, then we create a single copy and vector all the preds into that
single copy.

However, there the obvious special case.  If the block starts with just 2
preds, then any PHIs will be single argument PHIs in the copy.  That's probably
enough to address this particular BZ.I don't think that's enough to address
the older BZ in this space though.

[Bug c++/80038] [6/7 Regression] Random segfault using local vectors in Cilk function

[law at redhat dot com]

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

--- Comment #37 from Jeffrey A. Law  ---
There are no plans to backport any additional Cilk+ changes/fixes to the
release branches.

[Bug target/78117] gcc on tilegx builds faulty strstr() function (from glibc)

[cmetcalf at mellanox dot com]

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

Chris Metcalf  changed:

   What|Removed |Added

 CC||cmetcalf at mellanox dot com

--- Comment #6 from Chris Metcalf  ---
This is believed to be due to a bug in the architecture-independent code that
optimizes vector (SIMD) ops.  A smaller test case:

unsigned long test(unsigned long a, unsigned long b)
{
  unsigned long result = __insn_v1cmpeq(a, 0);
  result >>= 8;
  return result;
} 

This will correctly emit the v1cmpeq and a right shift at -O0, but at higher
levels the v1cmpeq is optimized away and replaced with a zero, thus also
causing the right shift to be optimized away, and the function just returns
zero.  Without the right shift, the v1cmpeq is preserved at all optimization
levels.

[Bug c/78768] -Walloca-larger-than and -Wformat-length warnings disabled by -flto

[msebor at gcc dot gnu.org]

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

--- Comment #10 from Martin Sebor  ---
The test was changed to link-only (to exercise LTO) in r244385.

[Bug target/82248] probe_stack can generate unpredictable STR on arm

[ramana at gcc dot gnu.org]

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

--- Comment #6 from Ramana Radhakrishnan  ---
Author: ramana
Date: Tue Dec  5 16:32:55 2017
New Revision: 255428

URL: https://gcc.gnu.org/viewcvs?rev=255428=gcc=rev
Log:
[Patch ARM] Fix probe_stack constraint.

The probe_stack pattern uses r0 as a fixed register. This can cause issues if
we have auto-increment instructions coming out that have r0 as the base
register. 

Tested with a bootstrap and regression run. richi reports that the original
issue was fixed in the run. I did consider whether probe_stack_range was
affected but it all comes back to probe_stack pattern so I think we are ok.

I don't have a testcase that seems to provoke this but it seems to be default
on most distributions so I'm expecting the testcoverage to come from there.

Applied.

Ramana

PR target/82248

* config/arm/arm.md (probe_stack) : Use the 'o' constraint.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.md

[Bug tree-optimization/83026] missing strlen optimization for strcmp of unequal strings

[qing.zhao at oracle dot com]

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

--- Comment #4 from Qing Zhao  ---
Note, this optimization is only valid when the result of the strcmp is used to
compare with zero.

[Bug middle-end/81897] [6/7/8 Regression] spurious -Wmaybe-uninitialized warning

[law at redhat dot com]

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

--- Comment #5 from Jeffrey A. Law  ---
It really depends on the growth necessary to expose the thread.  I haven't
tried to evaluate that -- clearly if the code growth is unacceptable then
threading is the wrong answer.

In general we should start each investigation of this kind of bug with an
analysis of what the threader has missed and the pros/cons of addressing the
missed thread.

IMHO tree-ssa-uninit.c's job is really to deal with cases where we don't want
to thread (usually because of code growth concerns, but there are others).

[Bug testsuite/83289] [8 regression] i386/sse2-init-v2di-2.c, i386/avx256-unaligned-load-1.c, i386/avx256-unaligned-store-*.c fails

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

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

[Bug testsuite/83289] [8 regression] i386/sse2-init-v2di-2.c, i386/avx256-unaligned-load-1.c, i386/avx256-unaligned-store-*.c fails

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Dec  5 16:17:09 2017
New Revision: 255427

URL: https://gcc.gnu.org/viewcvs?rev=255427=gcc=rev
Log:
PR testsuite/83289
* gcc.target/i386/avx256-unaligned-load-1.c: Adjust for -dp
alternative numbers being 0 based instead of former 1 based.
* gcc.target/i386/avx256-unaligned-store-1.c: Likewise.
* gcc.target/i386/avx256-unaligned-store-2.c: Likewise.
* gcc.target/i386/avx256-unaligned-store-3.c: Likewise.
* gcc.target/i386/avx256-unaligned-store-4.c: Likewise.
* gcc.target/i386/sse2-init-v2di-2.c: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/avx256-unaligned-load-1.c
trunk/gcc/testsuite/gcc.target/i386/avx256-unaligned-store-1.c
trunk/gcc/testsuite/gcc.target/i386/avx256-unaligned-store-2.c
trunk/gcc/testsuite/gcc.target/i386/avx256-unaligned-store-3.c
trunk/gcc/testsuite/gcc.target/i386/avx256-unaligned-store-4.c
trunk/gcc/testsuite/gcc.target/i386/sse2-init-v2di-2.c

[Bug testsuite/83281] [8 regression] libgomp.oacc-c-c++-common/reduction-cplx-flt.c and reduction-cplx-dbl.c fail starting with r255335

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
*** Bug 83291 has been marked as a duplicate of this bug. ***

[Bug libgomp/83291] [8 regression] libgomp.oacc-c-c++-common/reduction-cplx-dbl.c, libgomp.oacc-c-c++-common/reduction-cplx-flt.c fails

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Dup.

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

[Bug libgomp/83291] New: [8 regression] libgomp.oacc-c-c++-common/reduction-cplx-dbl.c, libgomp.oacc-c-c++-common/reduction-cplx-flt.c fails

[andrey.y.guskov at intel dot com]

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

Bug ID: 83291
   Summary: [8 regression]
libgomp.oacc-c-c++-common/reduction-cplx-dbl.c,
libgomp.oacc-c-c++-common/reduction-cplx-flt.c fails
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrey.y.guskov at intel dot com
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

r255335 triggers these fails:

---
spawn -ignore SIGHUP /work/gcc/xgcc -B/work/gcc/ -x c++
/source/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/reduction-cplx-dbl.c
-B/work/x86_64-pc-linux-gnu/./libgomp/
-B/work/x86_64-pc-linux-gnu/./libgomp/.libs
-I/work/x86_64-pc-linux-gnu/./libgomp -I/source/libgomp/testsuite/../../include
-I/source/libgomp/testsuite/.. -fmessage-length=0 -fno-diagnostics-show-caret
-Wno-hsa -fdiagnostics-color=never -fopenacc -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -O2 -nostdinc++
-I/work/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/work/x86_64-pc-linux-gnu/libstdc++-v3/include
-I/source/libstdc++-v3/libsupc++ -I/source/libstdc++-v3/include/backward
-I/source/libstdc++-v3/testsuite/util
-B/work/x86_64-pc-linux-gnu/./libgomp/../libstdc++-v3/src/.libs
-L/work/x86_64-pc-linux-gnu/./libgomp/.libs
-L/work/x86_64-pc-linux-gnu/./libgomp/../libstdc++-v3/src/.libs -lstdc++ -lm -o
./reduction-cplx-dbl.exe
FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/reduction-cplx-dbl.c
-DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1  -O2  (test for excess errors)

---
spawn -ignore SIGHUP /work/gcc/xgcc -B/work/gcc/ -x c++
/source/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/reduction-cplx-flt.c
-B/work/x86_64-pc-linux-gnu/./libgomp/
-B/work/x86_64-pc-linux-gnu/./libgomp/.libs
-I/work/x86_64-pc-linux-gnu/./libgomp -I/source/libgomp/testsuite/../../include
-I/source/libgomp/testsuite/.. -fmessage-length=0 -fno-diagnostics-show-caret
-Wno-hsa -fdiagnostics-color=never -fopenacc -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -O2 -nostdinc++
-I/work/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/work/x86_64-pc-linux-gnu/libstdc++-v3/include
-I/source/libstdc++-v3/libsupc++ -I/source/libstdc++-v3/include/backward
-I/source/libstdc++-v3/testsuite/util
-B/work/x86_64-pc-linux-gnu/./libgomp/../libstdc++-v3/src/.libs
-L/work/x86_64-pc-linux-gnu/./libgomp/.libs
-L/work/x86_64-pc-linux-gnu/./libgomp/../libstdc++-v3/src/.libs -lstdc++ -lm -o
./reduction-cplx-flt.exe
FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/reduction-cplx-flt.c
-DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1  -O2  (test for excess errors)


Option set:
-with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-shared
--enable-host-shared --enable-clocale=gnu --enable-cloog-backend=isl
--enable-languages=c,c++,fortran,jit,lto -with-arch=haswell --with-cpu=haswell

Also present on Silvermont.

[Bug middle-end/81897] [6/7/8 Regression] spurious -Wmaybe-uninitialized warning

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
I don't think improving the threader (which is strictly an optimization, and
might not be beneficial/desirable in many cases, if it e.g. needs copying large
amounts of code) is the way to go here.  The tree-ssa-uninit.c code doesn't try
to solve this issue at all, it is about
  if (cond)
v = something;
  some_code;
  if (cond)
use (v);
where the 2 conditions might not be identical, but the latter needs to be a
subset of the former.  While in this case, it is:
  if (cond)
v = something;
  some_code;
  if (!cond)
v = something_else;
  use (v);
i.e. the use is unconditional, but the set is in the end also unconditional.

On the other side, we don't warn for:
int bar (int);

int
foo (int x)
{
  int a;
  if (x)
a = bar (0);
  bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (1;
  bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (2;
  bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (3;
  bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (4;
  bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (5;
  bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (6;
  bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (7;
  bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (8;
  bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (9;
  if (!x)
a = bar (10);
  bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (11;
  bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (12;
  bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (13;
  bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (bar (14;
  return a;
}

which simulates large amounts of code that should make the threader punt.

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

[sergey.shalnov at intel dot com]

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

sergey.shalnov at intel dot com changed:

   What|Removed |Added

 CC||sergey.shalnov at intel dot com

--- Comment #4 from sergey.shalnov at intel dot com ---
Richard,
I can confirm that the issue exists and it can be solved by make data types of
accumulator and equation equal.
As I can see you propose to introduce intermediate internal accumulator in
uint32 type and store it into accumulator (int) later. Please correct me if I'm
wrong.

Anyway, may I, please, propose a bit simpler way to solve the issue?
In GIMPLE statement we have (in the place of reduction tree-vect=loop.c:2877):
"sum_12 = (int) _6;"

I believe the issue disappears if we change it to:
"sum_12 = _6;"

I'm not sure but, if I remember correctly, the C standard treat these types
(uint->int) casting as "undefined behavior". In this case, the compiler can do
this type cast(it might be under some command line switches).

What do you think, could it help?
Sergey

[Bug rtl-optimization/83162] [6/7/8 Regression] x86-64 -Wclobbered issuing more false alarms (regression)

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Both warnings are emitted starting with r235980.  The first one appeared with
r226901.

[Bug tree-optimization/81945] [8 Regression] ICE in operator[], at vec.h:749

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug tree-optimization/83277] [8 Regression] [graphite] Wrong code w/ -O2 -floop-nest-optimize

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Fixed.  Thanks for reporting.

[Bug tree-optimization/83277] [8 Regression] [graphite] Wrong code w/ -O2 -floop-nest-optimize

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Tue Dec  5 15:10:23 2017
New Revision: 255424

URL: https://gcc.gnu.org/viewcvs?rev=255424=gcc=rev
Log:
2017-12-05  Richard Biener  

PR tree-optimization/83277
* graphite-isl-ast-to-gimple.c (should_copy_to_new_region): Make sure
to code-gen liveout vars.

* gcc.dg/graphite/pr83277.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/graphite/pr83277.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-isl-ast-to-gimple.c
trunk/gcc/testsuite/ChangeLog

[Bug testsuite/83289] [8 regression] i386/sse2-init-v2di-2.c, i386/avx256-unaligned-load-1.c, i386/avx256-unaligned-store-*.c fails

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords|wrong-code  |
  Component|target  |testsuite
   Target Milestone|--- |8.0

[Bug libstdc++/83279] std::experimental::filesystem::copy_file can't copy larger files than 2.0GiB

[ta12ba34 at gmail dot com]

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

--- Comment #2 from T B  ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to T B from comment #0)
> > However, when I compiled it with GCC 5.4.0 (g++ -std=c++14 *.cpp *.h
> > -lstdc++fs) everything works fine and I can copy files with a size of over
> > 2.0GiB.
> 
> That's strange, because the code for copy_file is identical.

Then it is really strange. A repetition of my test results in exactly the same
however - with g++ 5.4 it works still fine.
Perhaps it is the fact that I use a prebuild GCC 5.4 and a selfcompiled GCC
7.2.

Could someone else please try it out?
Otherwise I will try to rebuild my GCC 7.2.


It seems that the preprocessed file was too large.
But I can not find anything important inside. If you think there could be
anything inside, I will hand them in later.

[Bug c++/83290] Expressions in anonymous unions inside class templates can't reference the union's members

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-12-05
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Clang and ICC compile it OK.

[Bug target/82964] gfortran.dg/class_array_1.f03 regression since r254388

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-12-05
 CC||wilco at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |wilco at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/83290] New: Expressions in anonymous unions inside class templates can't reference the union's members

[abigail.buccaneer at gmail dot com]

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

Bug ID: 83290
   Summary: Expressions in anonymous unions inside class templates
can't reference the union's members
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abigail.buccaneer at gmail dot com
  Target Milestone: ---

The following code compiles fine (with -std=c++14):

struct A {
union {
int x;
char y[sizeof(x)];
decltype(x) z;
static_assert(sizeof(y) == sizeof(z), "");
};
};

But fails when the struct is replaced with a struct template and instantiated
as follows:

template  struct T {
union {
int x;
char y[sizeof(x)];
decltype(x) z;
static_assert(sizeof(y) == sizeof(z), "");
};
};
template struct T;

The errors all say essentially the same thing:

:13:23: error: 'int Tx' is
inaccessible within this context
char y[sizeof(x)];
 ~^~

[Bug target/82964] gfortran.dg/class_array_1.f03 regression since r254388

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #1 from Wilco  ---
*** Bug 82974 has been marked as a duplicate of this bug. ***

[Bug target/82974] [8 regression] ICE in extract_insn, at recog.c:2305 on aarch64

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||wilco at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from Wilco  ---
Duplicate, same issue with movti not using literal pool when complex.

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

[Bug middle-end/82004] [8 Regression] SPEC CPU2017 628.pop2_s miscompare

[andrey.y.guskov at intel dot com]

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

--- Comment #13 from Andrey Guskov  ---
Nope. The issue persists.

I don`t know whether anyone reported this to SPEC already, but even if so I
share Richard`s pessimism.

[Bug testsuite/83281] [8 regression] libgomp.oacc-c-c++-common/reduction-cplx-flt.c and reduction-cplx-dbl.c fail starting with r255335

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug testsuite/82006] [8 Regression] ERROR: torture-init: torture_without_loops is not empty as expected

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

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

--- Comment #6 from Rainer Emrich  ---
(In reply to Jakub Jelinek from comment #5)
> Any progress on this?

No, I'm under heavy workload at the moment. I don't see how to debug this. I
will bisect to find the commit which causes the issue, hopefully very soon.

[Bug testsuite/83281] [8 regression] libgomp.oacc-c-c++-common/reduction-cplx-flt.c and reduction-cplx-dbl.c fail starting with r255335

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Tue Dec  5 13:34:41 2017
New Revision: 255418

URL: https://gcc.gnu.org/viewcvs?rev=255418=gcc=rev
Log:
PR testsuite/83281
* testsuite/libgomp.oacc-c-c++-common/reduction-cplx-flt.c (main): Use
j suffix instead of i.
* testsuite/libgomp.oacc-c-c++-common/reduction-cplx-dbl.c (main):
Likewise.

Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-cplx-dbl.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-cplx-flt.c

[Bug tree-optimization/83283] [7/8 Regression] Casting from boolean to unsigned char to enum returns incorrect results

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Dec  5 13:33:52 2017
New Revision: 255417

URL: https://gcc.gnu.org/viewcvs?rev=255417=gcc=rev
Log:
PR tree-optimization/83283
* g++.dg/torture/pr83283.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr83283.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug ipa/82027] [7/8 Regression] wrong code with -O3 -flto

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
Martin J., any progress on this?

[Bug middle-end/82004] [8 Regression] SPEC CPU2017 628.pop2_s miscompare

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
So, any progress here?
Has SPEC accepted some fix, or is this still broken?

[Bug testsuite/82006] [8 Regression] ERROR: torture-init: torture_without_loops is not empty as expected

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Any progress on this?

[Bug sanitizer/82046] [7/8 Regression] Bogus -fsanitize=undefined error with -O2 -Wall

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
At least for warnings that require optimizations in order to avoid false
positives like these, I think you need to accept some false positives with
sanitizers, which necessarily cause fewer optimizations (otherwise they
wouldn't be able to diagnose what they need to).  So don't use -Werror with
-fsanitize=undefined...
I'd close this as WONTFIX.

[Bug testsuite/82770] [8 regression] gcc.dg/pr78768.c xpass

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Martin?

[Bug target/83252] [8 Regression] Wrong code with "-march=skylake-avx512 -O3"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-12-05
 CC||vmakarov at gcc dot gnu.org
   Target Milestone|--- |8.0
Summary|Wrong code with |[8 Regression] Wrong code
   |"-march=skylake-avx512 -O3" |with "-march=skylake-avx512
   ||-O3"
 Ever confirmed|0   |1

--- Comment #12 from Jakub Jelinek  ---
This broke again with r255377.
Testcase in patch form at
https://gcc.gnu.org/ml/gcc-patches/2017-12/msg00133.html

[Bug target/83289] [8 regression] i386/sse2-init-v2di-2.c, i386/avx256-unaligned-load-1.c, i386/avx256-unaligned-store-*.c fails

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
Ah.  It seems to be because the testcases test for /5, /4 etc., which is
now printed as /4 resp. /3, because alternatives start counting at 0.

[Bug target/83289] [8 regression] i386/sse2-init-v2di-2.c, i386/avx256-unaligned-load-1.c, i386/avx256-unaligned-store-*.c fails

[segher at gcc dot gnu.org]

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

--- Comment #1 from Segher Boessenkool  ---
Please show output and output from before it failed.  And/or some
analysis that shows why current is wrong.  Etc.  Or even better,
make a patch to fix the testcase ;-)

[Bug bootstrap/83284] bootstrap comparison failure in libiberty/stack-limit.o

[egallager at gcc dot gnu.org]

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

--- Comment #2 from Eric Gallager  ---
Created attachment 42796
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42796=edit
cmp -bl stage2-libiberty/stack-limit.o stage3-libiberty/stack-limit.o

(In reply to Richard Biener from comment #1)
> What's your host compiler?  Which section is the difference in?

Host compiler info: 

/usr/local/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i386-apple-darwin10.8.0/8.0.0/lto-wrapper
Target: i386-apple-darwin10.8.0
Configured with: ../configure --disable-werror --disable-werror-always
--enable-languages=c,c++,objc,obj-c++,lto --enable-stage1-checking=release,rtl
-C --with-system-libunwind --enable-secureplt --enable-frame-pointer
--enable-debug --without-isl --disable-host-shared --enable-maintainer-mode
--disable-default-pie --with-ld64 --without-pic --enable-target-optspace
--disable-nls --with-system-zlib --with-libiconv-prefix=/opt/local
--with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --enable-lto
--enable-libstcxx-time --with-build-config=bootstrap-debug
--with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld
--with-ar=/opt/local/bin/ar --enable-objc-gc --enable-libada --enable-libssp
CC='/usr/bin/gcc-4.2 -arch i386 -arch x86_64' CXX='/usr/bin/g++-4.2 -arch
x86_64' AR_FOR_TARGET=/opt/local/bin/ar AS_FOR_TARGET=/opt/local/bin/as
LD_FOR_TARGET=/opt/local/bin/ld NM_FOR_TARGET=/opt/local/bin/nm
RANLIB_FOR_TARGET=/opt/local/bin/ranlib STRIP_FOR_TARGET=/opt/local/bin/strip
OTOOL=/opt/local/bin/otool OTOOL64=/opt/local/bin/otool
AUTOCONF=/opt/local/bin/autoconf264 AUTOHEADER=/opt/local/bin/autoheader264
AUTOM4TE=/opt/local/bin/autom4te264 AUTORECONF=/opt/local/bin/autoreconf264
AUTOSCAN=/opt/local/bin/autoscan264 AUTOUPDATE=/opt/local/bin/autoupdate264
IFNAMES=/opt/local/bin/ifnames264 ACLOCAL=/sw/bin/aclocal-1.11
PERL=/opt/local/bin/perl CFLAGS='-pipe -g -Os' CXXFLAGS='-pipe -g -Os
-fcheck-new' CPP='/usr/bin/gcc-4.2 -E' CXXCPP='/usr/bin/g++-4.2 -E'
M4=/opt/local/bin/gm4 : (reconfigured) ../configure --disable-werror
--disable-werror-always --enable-languages=c,c++,objc,obj-c++,lto
--enable-stage1-checking=release,rtl -C --with-system-libunwind
--enable-secureplt --enable-frame-pointer --enable-debug --without-isl
--disable-host-shared --enable-maintainer-mode --disable-default-pie
--with-ld64 --without-pic --enable-target-optspace --disable-nls
--with-system-zlib --with-libiconv-prefix=/opt/local --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local --enable-lto
--with-build-config=bootstrap-debug --with-as=/opt/local/bin/as
--with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar --enable-objc-gc
--enable-libada --enable-libssp --disable-libsanitizer CC=/usr/local/bin/gcc
CXX=/usr/local/bin/g++ AR_FOR_TARGET=/opt/local/bin/ar
AS_FOR_TARGET=/opt/local/bin/as LD_FOR_TARGET=/opt/local/bin/ld
NM_FOR_TARGET=/opt/local/bin/nm RANLIB_FOR_TARGET=/opt/local/bin/ranlib
STRIP_FOR_TARGET=/opt/local/bin/strip OTOOL=/opt/local/bin/otool
OTOOL64=/opt/local/bin/otool AUTOCONF=/opt/local/bin/autoconf264
AUTOHEADER=/opt/local/bin/autoheader264 AUTOM4TE=/opt/local/bin/autom4te264
AUTORECONF=/opt/local/bin/autoreconf264 AUTOSCAN=/opt/local/bin/autoscan264
AUTOUPDATE=/opt/local/bin/autoupdate264 IFNAMES=/opt/local/bin/ifnames264
ACLOCAL=/sw/bin/aclocal-1.11 PERL=/opt/local/bin/perl M4=/opt/local/bin/gm4
Thread model: posix
gcc version 8.0.0 20171110 (experimental) (GCC)

Not quite sure how to tell which section the difference is in but I'm attaching
the full cmp -bl output.

[Bug testsuite/83281] [8 regression] libgomp.oacc-c-c++-common/reduction-cplx-flt.c and reduction-cplx-dbl.c fail starting with r255335

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Patch I'll test momentarily.

[Bug c++/83287] [8 Regression] ice in tsubst_copy, at cp/pt.c:14884

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug target/83289] New: [8 regression] i386/sse2-init-v2di-2.c, i386/avx256-unaligned-load-1.c, i386/avx256-unaligned-store-*.c fails

[andrey.y.guskov at intel dot com]

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

Bug ID: 83289
   Summary: [8 regression] i386/sse2-init-v2di-2.c,
i386/avx256-unaligned-load-1.c,
i386/avx256-unaligned-store-*.c fails
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrey.y.guskov at intel dot com
  Target Milestone: ---

r255348 triggers these fails:

---
spawn -ignore SIGHUP /work/gcc/xgcc -B/work/gcc/
/source/gcc/testsuite/gcc.target/i386/sse2-init-v2di-2.c
-B/work/x86_64-pc-linux-gnu/./libmpx/
-B/work/x86_64-pc-linux-gnu/./libmpx/mpxrt
-L/work/x86_64-pc-linux-gnu/./libmpx/mpxrt/.libs
-B/work/x86_64-pc-linux-gnu/./libmpx/
-B/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap
-L/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap/.libs -fno-diagnostics-show-caret
-fdiagnostics-color=never -O2 -msse4 -march=core2 -dp -ffat-lto-objects -S -o
sse2-init-v2di-2.s
PASS: gcc.target/i386/sse2-init-v2di-2.c (test for excess errors)
FAIL: gcc.target/i386/sse2-init-v2di-2.c scan-assembler-times vec_concatv2di/5
1 (found 0 times)

---
spawn -ignore SIGHUP /work/gcc/xgcc -B/work/gcc/
/source/gcc/testsuite/gcc.target/i386/avx256-unaligned-load-1.c
-B/work/x86_64-pc-linux-gnu/./libmpx/
-B/work/x86_64-pc-linux-gnu/./libmpx/mpxrt
-L/work/x86_64-pc-linux-gnu/./libmpx/mpxrt/.libs
-B/work/x86_64-pc-linux-gnu/./libmpx/
-B/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap
-L/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap/.libs -fno-diagnostics-show-caret
-fdiagnostics-color=never -O3 -dp -mavx -mavx256-split-unaligned-load
-mno-prefer-avx128 -ffat-lto-objects -S -o avx256-unaligned-load-1.s
PASS: gcc.target/i386/avx256-unaligned-load-1.c (test for excess errors)
FAIL: gcc.target/i386/avx256-unaligned-load-1.c scan-assembler-not
vmovups[^]*movv8sf_internal/3

---
spawn -ignore SIGHUP /work/gcc/xgcc -B/work/gcc/
/source/gcc/testsuite/gcc.target/i386/avx256-unaligned-store-1.c
-B/work/x86_64-pc-linu
x-gnu/./libmpx/ -B/work/x86_64-pc-linux-gnu/./libmpx/mpxrt
-L/work/x86_64-pc-linux-gnu/./libmpx/mpxrt/.libs -B/work/x86_64-pc-linux-gnu/
./libmpx/ -B/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap
-L/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap/.libs -fno-diagnostics-show-caret
-f
diagnostics-color=never -O3 -dp -mavx -mavx256-split-unaligned-store
-mno-prefer-avx128 -fno-common -ffat-lto-objects -S -o avx256-unali
gned-store-1.s
PASS: gcc.target/i386/avx256-unaligned-store-1.c (test for excess errors)
PASS: gcc.target/i386/avx256-unaligned-store-1.c scan-assembler-not
vmovups.*movv8sf_internal/4
FAIL: gcc.target/i386/avx256-unaligned-store-1.c scan-assembler
vmovups.*movv4sf_internal/4

---
spawn -ignore SIGHUP /work/gcc/xgcc -B/work/gcc/
/source/gcc/testsuite/gcc.target/i386/avx256-unaligned-store-2.c
-B/work/x86_64-pc-linux-gnu/./libmpx/
-B/work/x86_64-pc-linux-gnu/./libmpx/mpxrt
-L/work/x86_64-pc-linux-gnu/./libmpx/mpxrt/.libs
-B/work/x86_64-pc-linux-gnu/./libmpx/
-B/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap
-L/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap/.libs -fno-diagnostics-show-caret
-fdiagnostics-color=never -O3 -mtune-ctrl=sse_typeless_stores -dp -mavx
-mavx256-split-unaligned-store -mno-prefer-avx128 -ffat-lto-objects -S -o
avx256-unaligned-store-2.s
PASS: gcc.target/i386/avx256-unaligned-store-2.c (test for excess errors)
PASS: gcc.target/i386/avx256-unaligned-store-2.c scan-assembler-not
vmovups.*movv32qi_internal/4
FAIL: gcc.target/i386/avx256-unaligned-store-2.c scan-assembler
vmovups.*movv16qi_internal/4

---
spawn -ignore SIGHUP /work/gcc/xgcc -B/work/gcc/
/source/gcc/testsuite/gcc.target/i386/avx256-unaligned-store-3.c
-B/work/x86_64-pc-linux-gnu/./libmpx/
-B/work/x86_64-pc-linux-gnu/./libmpx/mpxrt
-L/work/x86_64-pc-linux-gnu/./libmpx/mpxrt/.libs
-B/work/x86_64-pc-linux-gnu/./libmpx/
-B/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap
-L/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap/.libs -fno-diagnostics-show-caret
-fdiagnostics-color=never -O3 -dp -mavx -mavx256-split-unaligned-store
-mtune=generic -fno-common -ffat-lto-objects -S -o avx256-unaligned-store-3.s
PASS: gcc.target/i386/avx256-unaligned-store-3.c (test for excess errors)
PASS: gcc.target/i386/avx256-unaligned-store-3.c scan-assembler-not
vmovups.*movv4df_internal/4
FAIL: gcc.target/i386/avx256-unaligned-store-3.c scan-assembler
vmovups.*movv2df_internal/4

---
spawn -ignore SIGHUP /work/gcc/xgcc -B/work/gcc/
/source/gcc/testsuite/gcc.target/i386/avx256-unaligned-store-4.c
-B/work/x86_64-pc-linux-gnu/./libmpx/
-B/work/x86_64-pc-linux-gnu/./libmpx/mpxrt
-L/work/x86_64-pc-linux-gnu/./libmpx/mpxrt/.libs
-B/work/x86_64-pc-linux-gnu/./libmpx/
-B/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap
-L/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap/.libs -fno-diagnostics-show-caret
-fdiagnostics-color=never -O3 -dp -mavx -mno-avx256-split-unaligned-load
-mno-avx256-split-unaligned-store -mno-prefer-avx128 -fno-common

[Bug tree-optimization/83283] [7/8 Regression] Casting from boolean to unsigned char to enum returns incorrect results

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from Jakub Jelinek  ---
On the trunk, started with r230098 and got fixed in r253146 aka PR82285, which
got backported to 7.x in r253190.  I'll add the testcase to the testsuite.

[Bug c++/83287] [8 Regression] ice in tsubst_copy, at cp/pt.c:14884

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Started with r248250.  Slightly cleaned up testcase:

void foo ();
namespace {
void foo ();
}
template 
void
bar ()
{
  void *p = (void *) foo;
}

void
baz ()
{
  bar ();
}

[Bug tree-optimization/83288] [8 Regression] polyhedron gas_dyn 2-fold compile-time regression caused by r255103

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Goes from

   textdata bss dec hex filename
  58882  20 8001512 8060414  7afdfe gas_dyn.o

to

   textdata bss dec hex filename
  90002  20 8001512 8091534  7b778e gas_dyn.o

so compile-time changes roughly proportional to text size.

[Bug tree-optimization/83288] [8 Regression] polyhedron gas_dyn 2-fold compile-time regression caused by r255103

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
We're doing a lot more inlining blowing up the CU.  note the bit_speedup thing
below (- is good, + is bad).  Not sure if the intent was to "break" things
like this (SPEC 2k6 int also has some compile-time jumps in this area).

-  enqueuing call qsort.constprop/114 -> qsort.constprop/114, badness -0.00
+  enqueuing call qsort.constprop/114 -> qsort.constprop/114, badness -0.04
...
 Considering cd/11 with 48 size
  to be inlined into drag/12 in gas_dyn.f90:291
- Estimated badness is -0.015686, frequency 1.00.
+ Estimated badness is -1.33, frequency 1.00.
 Badness calculation for drag/12 -> cd/11
-  size growth 42, time 53.00 unspec 55.00  big_speedup
-  -0.003922: guessed profile. frequency 1.00, count -1 caller count -1
time w/o inlining 99.00, time with inlining 85.00 overall growth -6
(current) -6 (original) -6 (compensated)
-  Adjusted by hints -0.015686
+  size growth 42, time 53.00 unspec 55.00 
+  -0.33: guessed profile. frequency 1.00, count -1 caller count -1
time w/o inlining 99.00, time with inlining 85.00 overall growth -6
(current) -6 (original) -6 (compensated)
+  Adjusted by hints -1.33
Accounting size:44.00, time:53.00 on predicate exec:(true)
Accounting size:0.50, time:0.00 on predicate exec:(true)
...
 Considering value/21 with 11 size
  to be inlined into readin/18 in gas_dyn.f90:1393
- Estimated badness is -0.04, frequency 274.47.
+ Estimated badness is -0.106369, frequency 274.47.
 Badness calculation for readin/18 -> value/21
-  size growth 5, time 18.865600 unspec 20.865600  big_speedup
-  -0.04: guessed profile. frequency 274.469895, count -1 caller count
-1 time w/o inlining 27612.909485, time with inlining 23770.330963 overall
growth 85 (current) 85 (original) 7225 (compensated)
-  Adjusted by hints -0.04
+  size growth 5, time 18.865600 unspec 20.865600 
+  -0.106369: guessed profile. frequency 274.469895, count -1 caller count
-1 time w/o inlining 27612.909485, time with inlining 23770.330963 overall
growth 85 (current) 85 (original) 7225 (compensated)
+  Adjusted by hints -0.106369
Accounting size:3.50, time:823.41 on predicate exec:(true)
...
-  enqueuing call value/115 -> value_.part.1/113, badness -0.013826
+  enqueuing call value/115 -> value_.part.1/113, badness -395.421551
...
 Considering value_.part.1/113 with 26 size
  to be inlined into value/115 in unknown:0
- Estimated badness is -0.013826, frequency 134.16.
+ Estimated badness is -395.421551, frequency 134.16.
 Badness calculation for value/115 -> value_.part.1/113
   size growth 19, time 48.00 unspec 50.00 
-  -0.003456: guessed profile. frequency 134.160883, count -1 caller count
-1 time w/o inlining 30478.375122, time with inlining 28600.122757 overall
growth 12 (current) -7 (original) -7 (compensated)
-  Adjusted by hints -0.013826
+  -98.855388: guessed profile. frequency 134.160883, count -1 caller count
-1 time w/o inlining 30478.375122, time with inlining 28600.122757 overall
growth 12 (current) -7 (original) -7 (compensated)
+  Adjusted by hints -395.421551
Accounting size:14.00, time:1744.09 on predicate exec:(true)
...
 Considering qsort.constprop/114 with 82 size
- to be inlined into qsort.constprop/151 in gas_dyn.f90:1614
- Estimated badness is -0.00, frequency 0.26.
-Badness calculation for qsort.constprop/151 -> qsort.constprop/114
+ to be inlined into qsort.constprop/149 in gas_dyn.f90:1614
+ Estimated badness is -0.47, frequency 0.26.
+Badness calculation for qsort.constprop/149 -> qsort.constprop/114
   size growth 72, time 70.186200 unspec 81.186200 IPA hints: loop_stride
-  -0.00: guessed profile. frequency 0.256760, count -1 caller count -1 
time w/o inlining 29073.890945, time with inlining 29068.242218 overall growth
1
44 (current) 82 (original) 6724 (compensated)
-  Adjusted by hints -0.00
-   not inlining recursively: not executed in profile
+  -0.12: guessed profile. frequency 0.256760, count -1 caller count -1 
time w/o inlining 29073.890945, time with inlining 29068.242218 overall growth
144 (current) 82 (original) 6724 (compensated)
+  Adjusted by hints -0.47
+ Peeling recursion with depth 1
(!)

[Bug tree-optimization/83288] [8 Regression] polyhedron gas_dyn 2-fold compile-time regression caused by r255103

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-12-05
 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |8.0
Summary|[8 Regression] polyhedron   |[8 Regression] polyhedron
   |gas_dyn 2-fold compile-time |gas_dyn 2-fold compile-time
   |regression  |regression caused by
   ||r255103
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Caused by r255103

Index: gcc/ChangeLog
===
--- gcc/ChangeLog   (revision 255102)
+++ gcc/ChangeLog   (revision 255103)
@@ -1,5 +1,10 @@
 2017-11-23  Jan Hubicka  

+   * ipa-fnsummary.c (record_modified_bb_info): Use sreal
+   frequencies. Fix estimation of aggregate parameters.
+

[Bug sanitizer/81281] [6/7/8 Regression] UBSAN: false positive, dropped promotion to long type.

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Corresponding diff -upbd for better readability:
--- gcc/match.pd.jj 2017-11-28 09:40:08.0 +0100
+++ gcc/match.pd2017-12-05 11:36:58.855074420 +0100
@@ -1783,9 +1783,8 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(bit_not @0))

   /* (T)(P + A) - (T)P -> (T) A */
-  (for add (plus pointer_plus)
(simplify
-(minus (convert (add @@0 @1))
+   (minus (convert (plus:c @@0 @1))
  (convert @0))
 (if (element_precision (type) <= element_precision (TREE_TYPE (@1))
 /* For integer types, if A has a smaller type
@@ -1796,7 +1795,12 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
undefined behavior, we can assume that there
is no overflow.  */
 || (INTEGRAL_TYPE_P (TREE_TYPE (@0))
-&& TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0)))
+   && TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0
+(convert @1)))
+  (simplify
+   (minus (convert (pointer_plus @@0 @1))
+(convert @0))
+   (if (element_precision (type) <= element_precision (TREE_TYPE (@1))
 /* For pointer types, if the conversion of A to the
final type requires a sign- or zero-extension,
then we have to punt - it is not defined which
@@ -1804,7 +1808,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 || (POINTER_TYPE_P (TREE_TYPE (@0))
 && TREE_CODE (@1) == INTEGER_CST
 && tree_int_cst_sign_bit (@1) == 0))
- (convert @1
+(convert @1)))
(simplify
 (pointer_diff (pointer_plus @@0 @1) @0)
 /* The second argument of pointer_plus must be interpreted as signed, and
@@ -1813,10 +1817,14 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
  (convert (convert:stype @1

   /* (T)P - (T)(P + A) -> -(T) A */
-  (for add (plus pointer_plus)
(simplify
 (minus (convert @0)
- (convert (add @@0 @1)))
+(convert (plus:c @@0 @1)))
+   (if (INTEGRAL_TYPE_P (type)
+   && TYPE_OVERFLOW_UNDEFINED (type)
+&& element_precision (type) <= element_precision (TREE_TYPE (@1)))
+(with { tree utype = unsigned_type_for (type); }
+ (convert (negate (convert:utype @1
 (if (element_precision (type) <= element_precision (TREE_TYPE (@1))
 /* For integer types, if A has a smaller type
than T the result depends on the possible
@@ -1826,7 +1834,17 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
undefined behavior, we can assume that there
is no overflow.  */
 || (INTEGRAL_TYPE_P (TREE_TYPE (@0))
-&& TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0)))
+&& TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0
+ (negate (convert @1)
+  (simplify
+   (minus (convert @0)
+(convert (pointer_plus @@0 @1)))
+   (if (INTEGRAL_TYPE_P (type)
+   && TYPE_OVERFLOW_UNDEFINED (type)
+&& element_precision (type) <= element_precision (TREE_TYPE (@1)))
+(with { tree utype = unsigned_type_for (type); }
+ (convert (negate (convert:utype @1
+(if (element_precision (type) <= element_precision (TREE_TYPE (@1))
 /* For pointer types, if the conversion of A to the
final type requires a sign- or zero-extension,
then we have to punt - it is not defined which
@@ -1843,10 +1861,14 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
  (negate (convert (convert:stype @1)

   /* (T)(P + A) - (T)(P + B) -> (T)A - (T)B */
-  (for add (plus pointer_plus)
(simplify
-(minus (convert (add @@0 @1))
- (convert (add @0 @2)))
+   (minus (convert (plus:c @@0 @1))
+(convert (plus:c @0 @2)))
+   (if (INTEGRAL_TYPE_P (type)
+   && TYPE_OVERFLOW_UNDEFINED (type)
+&& element_precision (type) <= element_precision (TREE_TYPE (@1)))
+(with { tree utype = unsigned_type_for (type); }
+ (convert (minus (convert:utype @1) (convert:utype @2
 (if (element_precision (type) <= element_precision (TREE_TYPE (@1))
 /* For integer types, if A has a smaller type
than T the result depends on the possible
@@ -1856,7 +1878,17 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
undefined behavior, we can assume that there
is no overflow.  */
 || (INTEGRAL_TYPE_P (TREE_TYPE (@0))
-&& TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0)))
+&& TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0
+ (minus (convert @1) (convert @2)
+  (simplify
+   (minus (convert (pointer_plus @@0 @1))
+(convert (pointer_plus @0 @2)))
+   (if (INTEGRAL_TYPE_P (type)
+   && TYPE_OVERFLOW_UNDEFINED (type)
+&& element_precision (type) <= element_precision (TREE_TYPE (@1)))
+(with { tree utype = unsigned_type_for (type); }
+ (convert (minus (convert:utype @1) (convert:utype @2
+(if (element_precision (type) <= element_precision (TREE_TYPE (@1))
 /* For pointer types, if the conversion of A to the
final type requires a sign- or zero-extension,
   

[Bug sanitizer/81281] [6/7/8 Regression] UBSAN: false positive, dropped promotion to long type.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #42785|0   |1
is obsolete||
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

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

Untested fix.