[Bug libgomp/83589] [nvptx] mode-transitions.c and private-variables.{c,f90} execution FAILs at GOMP_NVPTX_JIT=-O0

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries  ---
(In reply to Tom de Vries from comment #2)
> This looks like another nvidia driver problem (with driver version 384.111).

Confirmed.

The empty branch

>  @ %r36 bra $L5;
>  $L5:

is translated into:
...
/*0128*/   @P0 BRA `(.L_1);
.L_1:
...
so, no sync after the branch (or ssy before the branch).

Consequently, when executing the shfl.idx a bit later:
...
/*0158*/   SHFL.IDX PT, R0, R0, RZ, 0x1f;
/*0168*/   SHFL.IDX PT, R2, R2, RZ, 0x1f;
...
we are in divergent mode and get undefined results.

Inserting some sort of nop in the branched-around part:
...
  @ %r36 bra $L5;
{
  .reg .u32 %nop_src;
  .reg .u32 %nop_dst;
  mov.u32 %nop_dst, %nop_src;
}
  $L5:
...
makes the test pass, because then we generate:
...
/*0128*/   SSY `(.L_1);
/*0130*/   @P0 SYNC (*"TARGET= .L_1 "*);
/*0138*/   SYNC (*"TARGET= .L_1 "*);
.L_1:
...

[Bug fortran/83900] [8 Regression] ICE in gfc_simplify_matmul, at fortran/simplify.c:4593

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sat Jan 20 07:00:43 2018
New Revision: 256913

URL: https://gcc.gnu.org/viewcvs?rev=256913=gcc=rev
Log:
2018-01-19  Steven G. Kargl  

PR fortran/83900
* simplify.c (gfc_simplify_matmul): Delete bogus assertion.

2018-01-19  Steven G. Kargl  

PR fortran/83900
* gfortran.dg/matmul_17.f90: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/matmul_17.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/simplify.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/83900] [8 Regression] ICE in gfc_simplify_matmul, at fortran/simplify.c:4593

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sat Jan 20 06:15:55 2018
New Revision: 256912

URL: https://gcc.gnu.org/viewcvs?rev=256912=gcc=rev
Log:
2018-01-19  Steven G. Kargl  

PR fortran/83900
* simplify.c (gfc_simplify_matmul): Delete bogus assertion.

2018-01-19  Steven G. Kargl  

PR fortran/83900
* gfortran.dg/matmul_17.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/matmul_17.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/simplify.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/83950] New: [8 regression] error: no matching function for call to ‘folly::dynamic::at(size_t&) const’

[skpgkp1 at gmail dot com]

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

Bug ID: 83950
   Summary: [8 regression] error: no matching function for call to
‘folly::dynamic::at(size_t&) const’
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skpgkp1 at gmail dot com
CC: hjl.tools at gmail dot com
  Target Milestone: ---

This bug appear during latest HHVM build with GCC 8. GCC 7 works fine.

$ cat AsyncLog.cpp
template  struct c { static constexpr a d = b; };
template  struct e : c<bool, false> {};
template <int, typename a = void> struct f { typedef a h; };
typedef int size_t;
namespace folly {
struct dynamic {
  template <class, class = void> struct g;
  dynamic(char *);
  template ::h> dynamic(k);
  void at(dynamic) const;
  const dynamic *j(dynamic);
};
template  struct dynamic::g<k, typename f<e::d>::h> {
  using h = long;
};
}
template  class l;
struct m {
  folly::dynamic json;
};
template  class G : l { const int (); };
template  const int ::p() {
  m jpool;
  auto json = jpool.json;
  try {
auto jservers = json.j("");
for (size_t i;;)
  jservers->at(i);
  } catch (int) {
  }
}


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

$ g++ -O3 -c AsyncLog.cpp -w
AsyncLog.cpp: In member function ‘const int& G::p()’:
AsyncLog.cpp:28:21: error: no matching function for call to
‘folly::dynamic::at(size_t&) const’
   jservers->at(i);
 ^
AsyncLog.cpp:10:8: note: candidate: ‘void folly::dynamic::at(folly::dynamic)
const’
   void at(dynamic) const;
^~
AsyncLog.cpp:10:8: note:   no known conversion for argument 1 from ‘size_t’
{aka ‘int’} to ‘folly::dynamic’


GCC 7 works fine:

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

$ g++ -O3 -c AsyncLog.cpp -w
$ echo $?
0

[Bug fortran/66310] Problems with intrinsic repeat for large number of copies

[jvdelisle at gcc dot gnu.org]

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

--- Comment #18 from Jerry DeLisle  ---
Can this be closed.

[Bug fortran/80768] NULL pointer dereferenced in gfc_check_num_images at fortran/check.c

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |6.5

--- Comment #10 from kargl at gcc dot gnu.org ---
fixed

[Bug fortran/80768] NULL pointer dereferenced in gfc_check_num_images at fortran/check.c

[kargl at gcc dot gnu.org]

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

--- Comment #9 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Jan 19 23:51:18 2018
New Revision: 256908

URL: https://gcc.gnu.org/viewcvs?rev=256908=gcc=rev
Log:
2018-01-19  Steven G. Kargl  

Backport of r250734 from mainline
PR fortran/80768
* check.c (gfc_check_num_images): Fix typo.

2018-01-19  Steven G. Kargl  

PR fortran/80768
* gfortran.dg/num_images_1.f90:  New test that tests fix in r250734.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/num_images_1.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/check.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug fortran/80768] NULL pointer dereferenced in gfc_check_num_images at fortran/check.c

[kargl at gcc dot gnu.org]

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

--- Comment #8 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Jan 19 23:37:29 2018
New Revision: 256907

URL: https://gcc.gnu.org/viewcvs?rev=256907=gcc=rev
Log:
2018-01-19  Steven G. Kargl  

Backport of r250734 from mainline
PR fortran/80768
* check.c (gfc_check_num_images): Fix typo.

2018-01-19  Steven G. Kargl  

PR fortran/80768
* gfortran.dg/num_images_1.f90:  New test that tests fix in r250734.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/num_images_1.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/check.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/80768] NULL pointer dereferenced in gfc_check_num_images at fortran/check.c

[kargl at gcc dot gnu.org]

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

--- Comment #7 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Jan 19 23:28:18 2018
New Revision: 256906

URL: https://gcc.gnu.org/viewcvs?rev=256906=gcc=rev
Log:
2018-01-19  Steven G. Kargl  

PR fortran/80768
* gfortran.dg/num_images_1.f90:  New test that tests fix in r250734.

Added:
trunk/gcc/testsuite/gfortran.dg/num_images_1.f90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug debug/83728] [8 regression] FAIL: gcc.dg/guality/pr68037-1.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/83919] [8 regression] spurious -Wignored-qualifiers warning

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/81167] [8 Regression] ICE on valid C++ code in deferred_printed_type, at cp/error.c:118

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug libstdc++/61458] std::aligned_storage is bigger than expected

[arthur.j.odwyer at gmail dot com]

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

Arthur O'Dwyer  changed:

   What|Removed |Added

 CC||arthur.j.odwyer at gmail dot 
com

--- Comment #10 from Arthur O'Dwyer  ---
Could we revisit this issue? Libstdc++'s behavior here seems to be "conforming
but sadistic," in that it gratuitously breaks the ABI of user/library code that
assumes aligned_storage_t is appropriately aligned for objects of size
Cap.

For example, SG14's "stdext::inplace_function" was recently declared as
follows:

  template<
typename Signature,
size_t Capacity = detail::InplaceFunctionDefaultCapacity,
size_t Alignment =
std::alignment_of::value
  >
  class inplace_function;

This works great on Clang/libc++, but gives a different ABI on GCC/libstdc++
because on libstdc++ the default alignment is "always 16 bytes" instead of
"appropriately aligned for Capacity".

using IPF = stdext::inplace_function;
if (sizeof(IPF) == 16) {
puts("MSVC and libc++ pack aligned_storage_t appropriately!");
} else if (sizeof(IPF) == 32) {
puts("libstdc++ breaks ABI by adding lots of padding for no reason!");
}

I'm not 100% sure yet, but it *seems* like the only workaround is for all
library writers to implement their own version of aligned_storage_t; the
standard version is not portable to platforms that use libstdc++.

Here is a conforming version of "aligned_storage", checked into the SG14 repo
as a workaround for the ongoing libstdc++ issue.
https://github.com/WG21-SG14/SG14/commit/98baf1aeab

[Bug c++/83949] internal compiler error: Segmentation fault (only with -g)

[peter_foelsche at mentor dot com]

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

--- Comment #3 from Peter Foelsche  ---
also happens with 

pfoelsch@TXA-PFOELSCH-LT:/mnt/d/BSIMSOI$ g++-7 --version
g++-7 (Ubuntu 7.2.0-1ubuntu1~16.04) 7.2.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

pfoelsch@TXA-PFOELSCH-LT:/mnt/d/BSIMSOI$ g++-7 -v
Using built-in specs.
COLLECT_GCC=g++-7
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.2.0-1ubuntu1~16.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.2.0 (Ubuntu 7.2.0-1ubuntu1~16.04)
pfoelsch@TXA-PFOELSCH-LT:/mnt/d/BSIMSOI$

[Bug c++/81167] [8 Regression] ICE on valid C++ code in deferred_printed_type, at cp/error.c:118

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Fri Jan 19 22:37:37 2018
New Revision: 256905

URL: https://gcc.gnu.org/viewcvs?rev=256905=gcc=rev
Log:
PR c++/81167
* call.c (joust): Use TREE_TYPE (source) if source is
a POINTER_TYPE_P rather than if ! DECL_CONSTRUCTOR_P (w->fn).

* g++.dg/cpp0x/pr81167.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr81167.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog

[Bug debug/83728] [8 regression] FAIL: gcc.dg/guality/pr68037-1.c

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Fri Jan 19 22:36:04 2018
New Revision: 256904

URL: https://gcc.gnu.org/viewcvs?rev=256904=gcc=rev
Log:
PR debug/81570
PR debug/83728
* dwarf2cfi.c (DEFAULT_INCOMING_FRAME_SP_OFFSET): Define to
INCOMING_FRAME_SP_OFFSET if not defined.
(scan_trace): Add ENTRY argument.  If true and
DEFAULT_INCOMING_FRAME_SP_OFFSET != INCOMING_FRAME_SP_OFFSET,
emit a note to adjust the CFA offset.
(create_cfi_notes): Adjust scan_trace callers.
(create_cie_data): Use DEFAULT_INCOMING_FRAME_SP_OFFSET rather than
INCOMING_FRAME_SP_OFFSET in the CIE.
* config/i386/i386.h (DEFAULT_INCOMING_FRAME_SP_OFFSET): Define.
* config/stormy16/stormy16.h (DEFAULT_INCOMING_FRAME_SP_OFFSET):
Likewise.
* doc/tm.texi.in (DEFAULT_INCOMING_FRAME_SP_OFFSET): Document.
* doc/tm.texi: Regenerated.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.h
trunk/gcc/config/stormy16/stormy16.h
trunk/gcc/doc/tm.texi
trunk/gcc/doc/tm.texi.in
trunk/gcc/dwarf2cfi.c

[Bug debug/81570] create_pseudo_cfg assumes that INCOMING_FRAME_SP_OFFSET is a constant

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Fri Jan 19 22:36:04 2018
New Revision: 256904

URL: https://gcc.gnu.org/viewcvs?rev=256904=gcc=rev
Log:
PR debug/81570
PR debug/83728
* dwarf2cfi.c (DEFAULT_INCOMING_FRAME_SP_OFFSET): Define to
INCOMING_FRAME_SP_OFFSET if not defined.
(scan_trace): Add ENTRY argument.  If true and
DEFAULT_INCOMING_FRAME_SP_OFFSET != INCOMING_FRAME_SP_OFFSET,
emit a note to adjust the CFA offset.
(create_cfi_notes): Adjust scan_trace callers.
(create_cie_data): Use DEFAULT_INCOMING_FRAME_SP_OFFSET rather than
INCOMING_FRAME_SP_OFFSET in the CIE.
* config/i386/i386.h (DEFAULT_INCOMING_FRAME_SP_OFFSET): Define.
* config/stormy16/stormy16.h (DEFAULT_INCOMING_FRAME_SP_OFFSET):
Likewise.
* doc/tm.texi.in (DEFAULT_INCOMING_FRAME_SP_OFFSET): Document.
* doc/tm.texi: Regenerated.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.h
trunk/gcc/config/stormy16/stormy16.h
trunk/gcc/doc/tm.texi
trunk/gcc/doc/tm.texi.in
trunk/gcc/dwarf2cfi.c

[Bug c++/83919] [8 regression] spurious -Wignored-qualifiers warning

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri Jan 19 22:35:09 2018
New Revision: 256903

URL: https://gcc.gnu.org/viewcvs?rev=256903=gcc=rev
Log:
PR c++/83919
* typeck.c (convert_for_assignment): Suppress warn_ignored_qualifiers
for direct enum init.
* decl.c (reshape_init): Likewise.

* g++.dg/cpp0x/pr83919.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr83919.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/83949] internal compiler error: Segmentation fault (only with -g)

[peter_foelsche at mentor dot com]

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

--- Comment #2 from Peter Foelsche  ---
Created attachment 43193
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43193=edit
*.ii compressed

[Bug c++/83949] internal compiler error: Segmentation fault (only with -g)

[peter_foelsche at mentor dot com]

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

--- Comment #1 from Peter Foelsche  ---
Created attachment 43192
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43192=edit
compiler stdout/stderr

[Bug c++/83949] New: internal compiler error: Segmentation fault (only with -g)

[peter_foelsche at mentor dot com]

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

Bug ID: 83949
   Summary: internal compiler error: Segmentation fault (only with
-g)
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter_foelsche at mentor dot com
  Target Milestone: ---

Version:

[pfoelsch@ orw-ams-ms21 /scratch/pfoelsch/resistor]%
/scratch/pfoelsch/TDA/rfsim/rfsim/debug/afs_root/tiburonda/tools/Linux_x86_64/bin/g++
--version
g++ (GCC) 5.3.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

OS version:

[pfoelsch@ orw-ams-ms21 /scratch/pfoelsch/resistor]% uname -a Linux
orw-ams-ms21 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22 03:15:09 UTC 2013 x86_64
x86_64 x86_64 GNU/Linux


Configure:

[pfoelsch@ orw-ams-ms21 /scratch/pfoelsch/resistor]% g++ -v Using built-in
specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/scratch/gcc-5.3.0/libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.3.0/configure --prefix=/scratch/gcc-5.3.0
--with-gmp=/scratch/gcc-5.3.0 --with-mpfr=/scratch/gcc-5.3.0
--with-mpc=/scratch/gcc-5.3.0 --with-isl-include=/scratch/gcc-5.3.0/include
--with-isl-lib=/scratch/gcc-5.3.0/lib --enable-languages=c,c++,fortran Thread
model: posix gcc version 5.3.0 (GCC)


Commandline to create crash:

/scratch/pfoelsch/TDA/rfsim/rfsim/debug/afs_root/tiburonda/tools/Linux_x86_64/bin/g++
/scratch/pfoelsch/resistor/bsimsoi_devcalc.c -std=c++17 -g -Og -DNDEBUG -fPIC
-I
/scratch/pfoelsch/TDA/rfsim/rfsim/debug/afs_root/tiburonda/fast_compact/include
-I /scratch/pfoelsch/boost_1_65_1 -shared -o module_bsimsoi_1.so|& tee make.out

Output attached (make.out)

Preprocessed file.ii attached (compressed)

[Bug rtl-optimization/83147] LRA inheritance undo on multiple sets problem

[vmakarov at gcc dot gnu.org]

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

--- Comment #4 from Vladimir Makarov  ---
Author: vmakarov
Date: Fri Jan 19 22:16:30 2018
New Revision: 256902

URL: https://gcc.gnu.org/viewcvs?rev=256902=gcc=rev
Log:
2018-01-19  Andreas Krebbel  

PR rtl-optimization/83147
* lra-constraints.c (remove_inheritance_pseudos): Use
lra_substitute_pseudo_within_insn.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c

RE: internal compiler error: Segmentation fault (all required info contained)

[Foelsche, Peter]

Note that crash only happens when using -g

Peter

-Original Message-
From: gcc-bugs-ow...@gcc.gnu.org [mailto:gcc-bugs-ow...@gcc.gnu.org] On Behalf 
Of Foelsche, Peter
Sent: Friday, January 19, 2018 16:06
To: gcc-bugs@gcc.gnu.org
Subject: FW: internal compiler error: Segmentation fault (all required info 
contained)

I removed the compressed preprocessed file, as your email server does not 
accept an email of this size.
I tried before to get an account at GCC bug tracker but was ignored.

Peter

From: Foelsche, Peter
Sent: Friday, January 19, 2018 16:01
To: 'gcc-bugs@gcc.gnu.org' 
Subject: internal compiler error: Segmentation fault (all required info 
contained)

Version:

[pfoelsch@ orw-ams-ms21 /scratch/pfoelsch/resistor]% 
/scratch/pfoelsch/TDA/rfsim/rfsim/debug/afs_root/tiburonda/tools/Linux_x86_64/bin/g++
 --version
g++ (GCC) 5.3.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO 
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

OS version:

[pfoelsch@ orw-ams-ms21 /scratch/pfoelsch/resistor]% uname -a Linux 
orw-ams-ms21 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22 03:15:09 UTC 2013 x86_64 
x86_64 x86_64 GNU/Linux


Configure:

[pfoelsch@ orw-ams-ms21 /scratch/pfoelsch/resistor]% g++ -v Using built-in 
specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/scratch/gcc-5.3.0/libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.3.0/configure --prefix=/scratch/gcc-5.3.0 
--with-gmp=/scratch/gcc-5.3.0 --with-mpfr=/scratch/gcc-5.3.0 
--with-mpc=/scratch/gcc-5.3.0 --with-isl-include=/scratch/gcc-5.3.0/include 
--with-isl-lib=/scratch/gcc-5.3.0/lib --enable-languages=c,c++,fortran Thread 
model: posix gcc version 5.3.0 (GCC)


Commandline to create crash:

/scratch/pfoelsch/TDA/rfsim/rfsim/debug/afs_root/tiburonda/tools/Linux_x86_64/bin/g++
 /scratch/pfoelsch/resistor/bsimsoi_devcalc.c -std=c++17 -g -Og -DNDEBUG -fPIC 
-I 
/scratch/pfoelsch/TDA/rfsim/rfsim/debug/afs_root/tiburonda/fast_compact/include 
-I /scratch/pfoelsch/boost_1_65_1 -shared -o module_bsimsoi_1.so|& tee make.out

Output attached (make.out)

Preprocessed file.ii attached (compressed)

FW: internal compiler error: Segmentation fault (all required info contained)

[Foelsche, Peter]

I removed the compressed preprocessed file, as your email server does not 
accept an email of this size.
I tried before to get an account at GCC bug tracker but was ignored.

Peter

From: Foelsche, Peter 
Sent: Friday, January 19, 2018 16:01
To: 'gcc-bugs@gcc.gnu.org' 
Subject: internal compiler error: Segmentation fault (all required info 
contained)

Version:

[pfoelsch@ orw-ams-ms21 /scratch/pfoelsch/resistor]% 
/scratch/pfoelsch/TDA/rfsim/rfsim/debug/afs_root/tiburonda/tools/Linux_x86_64/bin/g++
 --version
g++ (GCC) 5.3.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

OS version:

[pfoelsch@ orw-ams-ms21 /scratch/pfoelsch/resistor]% uname -a
Linux orw-ams-ms21 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22 03:15:09 UTC 2013 
x86_64 x86_64 x86_64 GNU/Linux


Configure:

[pfoelsch@ orw-ams-ms21 /scratch/pfoelsch/resistor]% g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/scratch/gcc-5.3.0/libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.3.0/configure --prefix=/scratch/gcc-5.3.0 
--with-gmp=/scratch/gcc-5.3.0 --with-mpfr=/scratch/gcc-5.3.0 
--with-mpc=/scratch/gcc-5.3.0 --with-isl-include=/scratch/gcc-5.3.0/include 
--with-isl-lib=/scratch/gcc-5.3.0/lib --enable-languages=c,c++,fortran
Thread model: posix
gcc version 5.3.0 (GCC)


Commandline to create crash:

/scratch/pfoelsch/TDA/rfsim/rfsim/debug/afs_root/tiburonda/tools/Linux_x86_64/bin/g++
 /scratch/pfoelsch/resistor/bsimsoi_devcalc.c -std=c++17 -g -Og -DNDEBUG -fPIC 
-I 
/scratch/pfoelsch/TDA/rfsim/rfsim/debug/afs_root/tiburonda/fast_compact/include 
-I /scratch/pfoelsch/boost_1_65_1 -shared -o module_bsimsoi_1.so|& tee make.out

Output attached (make.out)

Preprocessed file.ii attached (compressed)


make.out
Description: make.out

[Bug libfortran/83948] Thread safety issue writing to internal file - libgfortran

[longb at cray dot com]

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

--- Comment #1 from Bill Long  ---
The same code compiles and executes OK at 20 threads with other compilers.  The
size of the internal file is small (700 bytes).

[Bug libfortran/83948] New: Thread safety issue writing to internal file - libgfortran

[longb at cray dot com]

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

Bug ID: 83948
   Summary: Thread safety issue writing to internal file -
libgfortran
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: longb at cray dot com
  Target Milestone: ---

> cat test.f90
  subroutine sub (a1, i1, f1, i2, i3, i4, out)
implicit none
character(30),intent(in) :: a1
integer,intent(in) :: i1, i2, i3, i4
real,intent(in) :: f1
character(700), intent(out) :: out 
character(700) :: local_out   ! local stack variable

write (local_out, "(A,A30,A,I8,A,I8,A,F8.6,A,I3,A,I3)") &
   "Same pole re-projecting area source: ", a1, &
 ': IndexVal=', i1, &
 '  Indexval*2=', i2, &
 '  RandomValue=', f1, &
 ", RandomValue*999=", i3, &
 ", iThread=", i4

out = local_out

  end subroutine sub


  program test
use omp_lib
implicit none

integer,parameter :: n = 1000, cn = 700

character(cn) :: table(n)
character(30) :: a1
integer :: i1, i2, i3, i4
real :: f1
integer :: i

!$omp parallel do private (i1, i2, i3, i4, f1, a1)
do i = 1,n
   call random_number(f1)
   i1 = min(i,)
   i2 = min(2*i, )
   i3 = f1*999  
   i4 = omp_get_thread_num()
   a1 = "Beginnng of new record:"
   call sub (a1, i1, f1, i2, i3, i4, table(i))
end do
!$omp end parallel do

do i = max(1,n-5), n
   print *, "Table element number = ", i, trim(table(i))
end do
  end program test

OK : 10 threads 

> export OMP_NUM_THREADS=10
> ftn -fopenmp -O3 test.f90
> srun -n1 -c10 ./a.out
 Table element number =  995 Same pole re-projecting area source:
Beginnng of new record:   : IndexVal= 995  Indexval*2=1990 
RandomValue=0.733033, RandomValue*999=732, iThread=  9
 Table element number =  996 Same pole re-projecting area source:
Beginnng of new record:   : IndexVal= 996  Indexval*2=1992 
RandomValue=0.609290, RandomValue*999=608, iThread=  9
 Table element number =  997 Same pole re-projecting area source:
Beginnng of new record:   : IndexVal= 997  Indexval*2=1994 
RandomValue=0.810925, RandomValue*999=810, iThread=  9
 Table element number =  998 Same pole re-projecting area source:
Beginnng of new record:   : IndexVal= 998  Indexval*2=1996 
RandomValue=0.617685, RandomValue*999=617, iThread=  9
 Table element number =  999 Same pole re-projecting area source:
Beginnng of new record:   : IndexVal= 999  Indexval*2=1998 
RandomValue=0.820912, RandomValue*999=820, iThread=  9
 Table element number = 1000 Same pole re-projecting area source:
Beginnng of new record:   : IndexVal=1000  Indexval*2=2000 
RandomValue=0.617121, RandomValue*999=616, iThread=  9

Fails: 20 threads


> export OMP_NUM_THREADS=20
> srun -n1 -c20 ./a.out
At line 15 of file test.f90
Internal Error: stash_internal_unit(): Stack Size Exceeded

Error termination. Backtrace:
#0  0x403ca0 in ???
#1  0x403e0f in ???
#2  0x4059cd in gomp_thread_start
at
../../../cray-gcc-7.2.0-201709081833.7aac99f36ce61/libgomp/team.c:120
#3  0x41a263 in start_thread
at /home/abuild/rpmbuild/BUILD/glibc-2.22/nptl/pthread_create.c:334
#4  0x4a1488 in ???
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
#5  0x in ???

[Bug middle-end/78809] Inline strcmp with small constant strings

[wilco at gcc dot gnu.org]

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

--- Comment #25 from Wilco  ---
(In reply to Qing Zhao from comment #24)
> From the above, we can see:
> even with n is as big as 20, inlined version is much faster than the
> non-inlined version, both on aarch64 (no hardware string compare insn
> provided) and X86 (hardware string compare insn provided)
> 
> So, it's reasonable to do the inline as much as possible.

Those numbers look too good to be true. I get around 2x speed up at n=3 (using
old GLIBC header which does the inlining), you get 7x on AArch64 and 21x on
x86...

In general it's not a good idea to inline too much because of code size bloat
and branch mispredictions (a good strcmp implementation processes 8 or 16 chars
at a time rather than requiring 1 branch per character). n=4 seems reasonable
since you need 3 instructions per character on most targets.

[Bug c++/83947] New: ICE on invalid C++ code with auto: in tsubst_decl, at cp/pt.c:13046

[su at cs dot ucdavis.edu]

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

Bug ID: 83947
   Summary: ICE on invalid C++ code with auto: in tsubst_decl, at
cp/pt.c:13046
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

This appears to be a recent regression. 

$ g++tk -v
Using built-in specs.
COLLECT_GCC=g++tk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/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.1 20180117 (experimental) [trunk revision 256779] (GCC)
$
$ g++-7.2.0 -c tmp.cpp
tmp.cpp: In instantiation of ‘auto g<0>’:
tmp.cpp:3:10:   required from here
tmp.cpp:2:23: error: use of ‘auto f()’ before deduction of ‘auto’
 template < int > auto g (f);
   ^
$
$ g++tk -c tmp.cpp
tmp.cpp:2:23: internal compiler error: in tsubst_decl, at cp/pt.c:13046
 template < int > auto g (f);
   ^
0x86faa0 tsubst_decl
../../gcc-source-trunk/gcc/cp/pt.c:13046
0x876996 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-source-trunk/gcc/cp/pt.c:13562
0x8749b5 instantiate_template_1
../../gcc-source-trunk/gcc/cp/pt.c:18569
0x8749b5 instantiate_template(tree_node*, tree_node*, int)
../../gcc-source-trunk/gcc/cp/pt.c:18625
0x8c81b6 finish_id_expression(tree_node*, tree_node*, tree_node*, cp_id_kind*,
bool, bool, bool*, bool, bool, bool, bool, char const**, unsigned int)
../../gcc-source-trunk/gcc/cp/semantics.c:3679
0x80a1a2 cp_parser_primary_expression
../../gcc-source-trunk/gcc/cp/parser.c:5615
0x817443 cp_parser_postfix_expression
../../gcc-source-trunk/gcc/cp/parser.c:7029
0x82087c cp_parser_unary_expression
../../gcc-source-trunk/gcc/cp/parser.c:8281
0x7fa8a9 cp_parser_cast_expression
../../gcc-source-trunk/gcc/cp/parser.c:9049
0x7fafa5 cp_parser_binary_expression
../../gcc-source-trunk/gcc/cp/parser.c:9151
0x7fb890 cp_parser_assignment_expression
../../gcc-source-trunk/gcc/cp/parser.c:9439
0x7fc883 cp_parser_constant_expression
../../gcc-source-trunk/gcc/cp/parser.c:9721
0x7fcd67 cp_parser_initializer_clause
../../gcc-source-trunk/gcc/cp/parser.c:21842
0x7ffcfb cp_parser_initializer
../../gcc-source-trunk/gcc/cp/parser.c:21780
0x8227a4 cp_parser_init_declarator
../../gcc-source-trunk/gcc/cp/parser.c:19601
0x824248 cp_parser_simple_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12997
0x8250cf cp_parser_block_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12815
0x830770 cp_parser_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12712
0x82f3b4 cp_parser_declaration_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:12588
0x82f6f7 cp_parser_translation_unit
../../gcc-source-trunk/gcc/cp/parser.c:4559
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$


---


auto f ();
template < int > auto g (f);
auto h = g < 0 > ();

[Bug target/83946] [7/8 Regression] Safe Indirect Jumps broken on AIX

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |wschmidt at gcc dot 
gnu.org

--- Comment #5 from Bill Schmidt  ---
Mine, in progress.

[Bug middle-end/78809] Inline strcmp with small constant strings

[qing.zhao at oracle dot com]

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

--- Comment #24 from Qing Zhao  ---
From the above, we can see:
even with n is as big as 20, inlined version is much faster than the
non-inlined version, both on aarch64 (no hardware string compare insn provided)
and X86 (hardware string compare insn provided)

So, it's reasonable to do the inline as much as possible.

[Bug middle-end/78809] Inline strcmp with small constant strings

[qing.zhao at oracle dot com]

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

--- Comment #23 from Qing Zhao  ---
I have an implementation for the part C of this task in my private space:

 part C: for strcmp (s1, s2), strncmp (s1, s2, n):

  if the result is NOT used to do simple equality test against zero, one of 
"s1" or "s2" is a small constant string, n is a constant, and the Min value of 
the length of the constant string and "n" is smaller than a predefined 
threshold T, 
  inline the call by a byte-to-byte comparision sequence to avoid calling 
overhead. 


with this implementation, I was able to measure the performance impact of the
inlining transformation on different value of "n", n is the length of the
string need to be compared. In order to decide the following two concerns:
A. what's the default value of n.
B. on a platform that support string compare hardware insns (for exmaple,
X86), which should be done first for a call to strcmp/strncmp, the inline or
the hardware insns?


On both aarch64 and X86, I tried the following small testing case for the
performance experiments:

qinzhao@gcc116:~/Bugs/78809/const_cmp$ cat t_p.c
#include 

char array[]= "fishi";

#define NUM 10
int __attribute__ ((noinline))
cmp2 (const char *p)
{
  int result = 0;
  int i;
  for (i=0; i< NUM; i++) {
result |=  strcmp (p, "fishi"); 
  }
  return result;
}

int result = 0;

int main()
{
  for (int i = 0; i < 25; i++)
 result += cmp2 (array);
  return 0;
}

and the option I used was:  -O -fno-tree-loop-im and the corresponding option
to enable or disable the added inlining, the following is the performance
result:

aarch64  strcmp

n=  3   4   5   6   10  20

inline  31  41  62  72  114 242
no-inline   229 229 229 229 272 333

aarch64  strncmp

n=  3   4   5   6   10  20

inline  41  62  62  76  125 250
no-inline   291 291 291 291 364 427


X86  strcmp

n=  4   5   6   10  20

inline  21  25  31  42  163
no-inline   445 461 488 529 672


X86  strncmp

n=  4   5   6   10  20

inline  21  25  28  43  77
no-inline   412 435 442 495 638

From the above, we can see:

[Bug target/83946] [7/8 Regression] Safe Indirect Jumps broken on AIX

[dje at gcc dot gnu.org]

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

--- Comment #4 from David Edelsohn  ---
The rest of rs6000.md uses "$" unconditionally for the same purpose, although
common parts of GCC uses ".".

[Bug target/83946] [7/8 Regression] Safe Indirect Jumps broken on AIX

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Does $ instead of . work on non-AIX though, and even if it does, isn't .
preferrable?  I.e. shouldn't the changes be conditional on AIX (or just AIX
assembler, GAS should handle . on all targets)?

[Bug target/83946] [7/8 Regression] Safe Indirect Jumps broken on AIX

[dje at gcc dot gnu.org]

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

--- Comment #2 from David Edelsohn  ---
Created attachment 43191
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43191=edit
proposed patch

[Bug target/83660] ICE with vec_extract inside expression statement

[kelvin at gcc dot gnu.org]

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

kelvin at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|kelvin at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org

--- Comment #5 from kelvin at gcc dot gnu.org ---
The ICE in verify_gimple_stmt apparently occurs because gimplification wants to
produce an "<<< Unknown GIMPLE statement: gimple_with_cleanup_expr >>>".  The
cleanup expression is a CLOBBER directive on a temporary variable that is
introduced with a match_scratch pattern in the expansion for this built-in.

The Power9 version of the expansion does not introduce the scratch operand, nor
the CLOBBER directive, which explains why it does not exhibit this problem.

Based on other observations captured in the comments of this problem report, it
appears that the problem is introduced by the C++ parser and its handling of
the compound statement nested within the return expression.

I'm going to unassign myself from this task for now.

[Bug target/82303] Better PIE/PIC code generation for kernel code (x86_64 & arm64)

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu  ---
(In reply to Thomas Garnier from comment #9)
> I tested the change against a modified version of the proposed Linux x86_64
> PIE support. The changes removes all the PLT32 and GOT64 entry but I still
> get R_X86_64_GOTPC64 & R_X86_64_GOTOFF64 relocations on the head64.c file
> that is built with -mcmodel=large (to prevent odd logic on early boot with
> different VA).
> 
> Do you think the suggested patch can be changed to remove these?
> 

I believe that is the nature of the large PIE model.

[Bug target/83946] [7/8 Regression] Safe Indirect Jumps broken on AIX

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-19
   Target Milestone|--- |7.3
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug target/83946] New: [7/8 Regression] Safe Indirect Jumps broken on AIX

[dje at gcc dot gnu.org]

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

Bug ID: 83946
   Summary: [7/8 Regression] Safe Indirect Jumps broken on AIX
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, rguenth at gcc dot gnu.org,
segher at gcc dot gnu.org, wschmidt at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc-ibm-aix*

The patches to inhibit speculation for powerpc are incorrect for AIX. Some of
the MD file changes use

b .

which is illegal syntax on AIX.  AIX requires "$" for the current position. 
This patch also was backported to GCC 7 branch, which means that the GCC 7.3.0
RC1 is broken.

[Bug target/82303] Better PIE/PIC code generation for kernel code (x86_64 & arm64)

[thgarnie at google dot com]

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

--- Comment #9 from Thomas Garnier  ---
I tested the change against a modified version of the proposed Linux x86_64 PIE
support. The changes removes all the PLT32 and GOT64 entry but I still get
R_X86_64_GOTPC64 & R_X86_64_GOTOFF64 relocations on the head64.c file that is
built with -mcmodel=large (to prevent odd logic on early boot with different
VA).

Do you think the suggested patch can be changed to remove these?

To repro, build the object file with: gcc -mcmodel=large -c -fstatic-pie
./test.c -o test

The objdump -dr output of the testcase:

 :
   0:   55  push   %rbp
   1:   48 89 e5mov%rsp,%rbp
   4:   48 83 ec 20 sub$0x20,%rsp
   8:   48 8d 05 f9 ff ff fflea-0x7(%rip),%rax# 8 
   f:   49 bb 00 00 00 00 00movabs $0x0,%r11
  16:   00 00 00
11: R_X86_64_GOTPC64_GLOBAL_OFFSET_TABLE_+0x9
  19:   4c 01 d8add%r11,%rax
  1c:   89 7d ecmov%edi,-0x14(%rbp)
  1f:   48 89 75 e0 mov%rsi,-0x20(%rbp)
  23:   48 ba 00 00 00 00 00movabs $0x0,%rdx
  2a:   00 00 00
25: R_X86_64_GOTOFF64   _text-0x1023
  2d:   48 8d 14 10 lea(%rax,%rdx,1),%rdx
  31:   89 55 fcmov%edx,-0x4(%rbp)
  34:   8b 55 ecmov-0x14(%rbp),%edx
  37:   48 63 d2movslq %edx,%rdx
  3a:   48 8b 4d e0 mov-0x20(%rbp),%rcx
  3e:   48 89 cemov%rcx,%rsi
  41:   48 b9 00 00 00 00 00movabs $0x0,%rcx
  48:   00 00 00
43: R_X86_64_GOTOFF64   _text
  4b:   48 8d 3c 08 lea(%rax,%rcx,1),%rdi
  4f:   48 b9 00 00 00 00 00movabs $0x0,%rcx
  56:   00 00 00
51: R_X86_64_GOTOFF64   memcpy
  59:   48 8d 04 08 lea(%rax,%rcx,1),%rax
  5d:   ff d0   callq  *%rax
  5f:   8b 45 fcmov-0x4(%rbp),%eax
  62:   c9  leaveq
  63:   c3  retq

[Bug target/82303] Better PIE/PIC code generation for kernel code (x86_64 & arm64)

[thgarnie at google dot com]

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

Thomas Garnier  changed:

   What|Removed |Added

  Attachment #43189|0   |1
is obsolete||

--- Comment #8 from Thomas Garnier  ---
Created attachment 43190
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43190=edit
testcase for mcmodel=large

[Bug fortran/83901] [8 Regresion] ICE in fold_convert_loc, at fold-const.c:2402

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #2 from Paul Thomas  ---
I had better clean this up since I caused it.

I have some time tomorrow.

Paul

[Bug target/82303] Better PIE/PIC code generation for kernel code (x86_64 & arm64)

[thgarnie at google dot com]

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

--- Comment #7 from Thomas Garnier  ---
Created attachment 43189
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43189=edit
testcase for mcmodel=large

Build with: gcc -mcmodel=large -c -fstatic-pie ./test.c -o test
Dump relocations on the object file: objdump -dr ./test

[Bug middle-end/83945] [7/8 Regression] internal compiler error: Segmentation fault with -O -fcode-hoisting

[jakub at gcc dot gnu.org]

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

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

[Bug middle-end/83945] [7/8 Regression] internal compiler error: Segmentation fault with -O -fcode-hoisting

[jakub at gcc dot gnu.org]

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

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

[Bug c/83943] internal compiler error: in get_constraint_for_ptr_offset, at tree-ssa-structalias.c:3155

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

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

[Bug c/83944] internal compiler error: Segmentation fault with -O -ftree-pre

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
This is a dup of PR83945.

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

[Bug middle-end/83945] [7/8 Regression] internal compiler error: Segmentation fault with -O -fcode-hoisting

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

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

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #1 from rsandifo at gcc dot gnu.org  
---
I'll look at these next week.

[Bug target/83888] [8 regression] new failures after r256639 on armhf

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #1 from rsandifo at gcc dot gnu.org  
---
I'll look at these next week.

[Bug middle-end/83889] [8 regression] new failures on some arm targets after r256644

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #1 from rsandifo at gcc dot gnu.org  
---
I'll look at these next week.

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

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
I'll look at these next week.

[Bug debug/83758] ICE building gccgo on powerpc64le --with-cpu=power8

[acsawdey at gcc dot gnu.org]

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

--- Comment #15 from acsawdey at gcc dot gnu.org ---
The build succeeds with -fno-split-stack. Turned out that willow2 had
glibc-2.17 so split-stack was disabled and genoa has 2.23 which enables it. So
this issue has something to with compiling for split-stack that is perhaps
causing memory corruption within the compiler.

[Bug c/83945] [7/8 Regression] internal compiler error: Segmentation fault with -O -fcode-hoisting

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |7.3
Summary|internal compiler error:|[7/8 Regression] internal
   |Segmentation fault with -O  |compiler error:
   |-fcode-hoisting |Segmentation fault with -O
   ||-fcode-hoisting

--- Comment #2 from Jakub Jelinek  ---
Works with 5.0.0 20150407, so a regression, not sure if 6.x works or not.

[Bug c/83945] internal compiler error: Segmentation fault with -O -fcode-hoisting

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Cleaned up testcase which still ICEs with -O2 on the current trunk:
struct S { int a[1]; };
__thread struct T { int c; } e;
int f;
void bar (int);

void
foo (int f, int x)
{
  struct S *h = (struct S *) 
  for (;;)
{
  int *a = h->a, i;
  for (i = x; i; i--)
bar (a[f]);
  bar (a[f]);
}
}

[Bug c++/83942] [8 Regression] False -Wunused-but-set-variable when const scoped enum is cast to int

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-19
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |8.0
Summary|False   |[8 Regression] False
   |-Wunused-but-set-variable   |-Wunused-but-set-variable
   |when const scoped enum is   |when const scoped enum is
   |cast to int |cast to int
 Ever confirmed|0   |1

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

[Bug target/83920] [8 Regression] [nvptx] bad predicate reset

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
Version|unknown |8.0
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #13 from Tom de Vries  ---
Patch with c and fortran test-case committed to trunk. Marking resolved-fixed.

[Bug c/83945] New: internal compiler error: Segmentation fault with -O -fcode-hoisting

[matt.sexton at redlinetrading dot com]

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

Bug ID: 83945
   Summary: internal compiler error: Segmentation fault with -O
-fcode-hoisting
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matt.sexton at redlinetrading dot com
  Target Milestone: ---

This bug has been observed with MinGW-w64 on Fedora 27 (gcc 7.2.0).  It is not
observed with a native Linux compile on Fedora 27 (gcc 7.2.1).

$ cat bug.c
typedef struct {
  struct {
int a[0]
  }
} b;
typedef struct { int c } d;
__thread d e;
f;
g() {
  b *h = 
  for (;;) {
int *a = h->a;
int i;
for (; i; i--)
  j(a[f]);
j(a[f]);
  }
}


$ x86_64-w64-mingw32-gcc -c -O -fcode-hoisting bug.c
bug.c:4:3: warning: no semicolon at end of struct or union
   }
   ^
bug.c:5:1: warning: no semicolon at end of struct or union
 } b;
 ^
bug.c:6:24: warning: no semicolon at end of struct or union
 typedef struct { int c } d;
^
bug.c:8:1: warning: data definition has no type or storage class
 f;
 ^
bug.c:8:1: warning: type defaults to 'int' in declaration of 'f'
[-Wimplicit-int]
bug.c:9:1: warning: return type defaults to 'int' [-Wimplicit-int]
 g() {
 ^
bug.c: In function 'g':
bug.c:10:10: warning: initialization from incompatible pointer type
[-Wincompatible-pointer-types]
   b *h = 
  ^
bug.c:15:7: warning: implicit declaration of function 'j'
[-Wimplicit-function-declaration]
   j(a[f]);
   ^
bug.c:9:1: internal compiler error: Segmentation fault
 g() {
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$ x86_64-w64-mingw32-gcc -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-w64-mingw32/7.2.0/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../configure --prefix=/usr --bindir=/usr/bin
--includedir=/usr/include --mandir=/usr/share/man --infodir=/usr/share/info
--datadir=/usr/share --build=x86_64-redhat-linux-gnu
--host=x86_64-redhat-linux-gnu --with-gnu-as --with-gnu-ld --verbose
--without-newlib --disable-multilib --disable-plugin --with-system-zlib
--disable-nls --without-included-gettext --disable-win32-registry
--enable-languages=c,c++,objc,obj-c++,fortran
--with-bugurl=http://bugzilla.redhat.com/bugzilla --with-cloog
--enable-threads=posix --enable-libgomp --target=x86_64-w64-mingw32
--with-sysroot=/usr/x86_64-w64-mingw32/sys-root
--with-gxx-include-dir=/usr/x86_64-w64-mingw32/sys-root/mingw/include/c++
Thread model: posix
gcc version 7.2.0 20170814 (Fedora MinGW 7.2.0-1.fc27) (GCC) 

$ rpm -qf `which x86_64-w64-mingw32-gcc`
mingw64-gcc-7.2.0-1.fc27.x86_64

$ uname -a
Linux build-fedora27 4.14.6-300.fc27.x86_64 #1 SMP Thu Dec 14 15:31:24 UTC 2017
x86_64 x86_64 x86_64 GNU/Linux

[Bug c/83944] New: internal compiler error: Segmentation fault with -O -ftree-pre

[matt.sexton at redlinetrading dot com]

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

Bug ID: 83944
   Summary: internal compiler error: Segmentation fault with -O
-ftree-pre
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matt.sexton at redlinetrading dot com
  Target Milestone: ---

This bug has been observed with MinGW-w64 on Fedora 27 (gcc 7.2.0).  It is not
observed with a native Linux compile on Fedora 27 (gcc 7.2.1).

$ cat bug.c
typedef enum { a } b;
typedef struct { b action } c;
d;
inline e(void *p1) {
  long *f = p1;
  long g = f[g] = d;
}
typedef struct { int h } i;
__thread i j;
k() {
  int *l = 
  c *entryp = l;
  int m = [m];
  for (;;) {
e([m]);
entryp[m].action = a;
  }
}

$ x86_64-w64-mingw32-gcc -c -O -ftree-pre bug.c
bug.c:2:27: warning: no semicolon at end of struct or union
 typedef struct { b action } c;
   ^
bug.c:3:1: warning: data definition has no type or storage class
 d;
 ^
bug.c:3:1: warning: type defaults to 'int' in declaration of 'd'
[-Wimplicit-int]
bug.c:4:8: warning: return type defaults to 'int' [-Wimplicit-int]
 inline e(void *p1) {
^
bug.c:8:24: warning: no semicolon at end of struct or union
 typedef struct { int h } i;
^
bug.c:10:1: warning: return type defaults to 'int' [-Wimplicit-int]
 k() {
 ^
bug.c: In function 'k':
bug.c:12:15: warning: initialization from incompatible pointer type
[-Wincompatible-pointer-types]
   c *entryp = l;
   ^
bug.c:13:11: warning: initialization makes integer from pointer without a cast
[-Wint-conversion]
   int m = [m];
   ^
bug.c:10:1: internal compiler error: Segmentation fault
 k() {
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$ x86_64-w64-mingw32-gcc -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-w64-mingw32/7.2.0/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../configure --prefix=/usr --bindir=/usr/bin
--includedir=/usr/include --mandir=/usr/share/man --infodir=/usr/share/info
--datadir=/usr/share --build=x86_64-redhat-linux-gnu
--host=x86_64-redhat-linux-gnu --with-gnu-as --with-gnu-ld --verbose
--without-newlib --disable-multilib --disable-plugin --with-system-zlib
--disable-nls --without-included-gettext --disable-win32-registry
--enable-languages=c,c++,objc,obj-c++,fortran
--with-bugurl=http://bugzilla.redhat.com/bugzilla --with-cloog
--enable-threads=posix --enable-libgomp --target=x86_64-w64-mingw32
--with-sysroot=/usr/x86_64-w64-mingw32/sys-root
--with-gxx-include-dir=/usr/x86_64-w64-mingw32/sys-root/mingw/include/c++
Thread model: posix
gcc version 7.2.0 20170814 (Fedora MinGW 7.2.0-1.fc27) (GCC) 

$ rpm -qf `which x86_64-w64-mingw32-gcc`
mingw64-gcc-7.2.0-1.fc27.x86_64

$ uname -a
Linux build-fedora27 4.14.6-300.fc27.x86_64 #1 SMP Thu Dec 14 15:31:24 UTC 2017
x86_64 x86_64 x86_64 GNU/Linux

[Bug target/83920] [8 Regression] [nvptx] bad predicate reset

[vries at gcc dot gnu.org]

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

--- Comment #12 from Tom de Vries  ---
Author: vries
Date: Fri Jan 19 16:29:41 2018
New Revision: 256894

URL: https://gcc.gnu.org/viewcvs?rev=256894=gcc=rev
Log:
[nvptx] Fix bug in jit bug workaround

2018-01-19  Tom de Vries  
Cesar Philippidis  

PR target/83920

* config/nvptx/nvptx.c (nvptx_single): Fix jit workaround.

* testsuite/libgomp.oacc-c-c++-common/pr83920.c: New test.
* testsuite/libgomp.oacc-fortran/pr83920.f90: New test.

Added:
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr83920.c
trunk/libgomp/testsuite/libgomp.oacc-fortran/pr83920.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/nvptx/nvptx.c
trunk/libgomp/ChangeLog

[Bug tree-optimization/83081] [8 regression][arm] gcc.dg/pr80218.c fails since r254888

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug c/83943] New: internal compiler error: in get_constraint_for_ptr_offset, at tree-ssa-structalias.c:3155

[matt.sexton at redlinetrading dot com]

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

Bug ID: 83943
   Summary: internal compiler error: in
get_constraint_for_ptr_offset, at
tree-ssa-structalias.c:3155
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matt.sexton at redlinetrading dot com
  Target Milestone: ---

This bug has been observed with MinGW-w64 on Fedora 27 (gcc 7.2.0) and Fedora
25 (gcc 6.4.0).  It is not seen on any native Linux builds, including gcc
7.2.0, or on MinGW-w64 on Fedora 21 (gcc 4.9.2).

$ cat bug.c 
typedef struct {
  struct {
int a[0]
  }
} b;
typedef struct { int c } d;
__thread d e;
f;
g() {
  b *h = 
  int *a = h->a;
  i(a[f]);
  i(a[f]);
}

$ x86_64-w64-mingw32-gcc -c -O2 bug.c 
bug.c:4:3: warning: no semicolon at end of struct or union
   }
   ^
bug.c:5:1: warning: no semicolon at end of struct or union
 } b;
 ^
bug.c:6:24: warning: no semicolon at end of struct or union
 typedef struct { int c } d;
^
bug.c:8:1: warning: data definition has no type or storage class
 f;
 ^
bug.c:8:1: warning: type defaults to 'int' in declaration of 'f'
[-Wimplicit-int]
bug.c:9:1: warning: return type defaults to 'int' [-Wimplicit-int]
 g() {
 ^
bug.c: In function 'g':
bug.c:10:10: warning: initialization from incompatible pointer type
[-Wincompatible-pointer-types]
   b *h = 
  ^
bug.c:12:3: warning: implicit declaration of function 'i'
[-Wimplicit-function-declaration]
   i(a[f]);
   ^
bug.c:9:1: internal compiler error: in get_constraint_for_ptr_offset, at
tree-ssa-structalias.c:3155
 g() {
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$ x86_64-w64-mingw32-gcc -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-w64-mingw32/7.2.0/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../configure --prefix=/usr --bindir=/usr/bin
--includedir=/usr/include --mandir=/usr/share/man --infodir=/usr/share/info
--datadir=/usr/share --build=x86_64-redhat-linux-gnu
--host=x86_64-redhat-linux-gnu --with-gnu-as --with-gnu-ld --verbose
--without-newlib --disable-multilib --disable-plugin --with-system-zlib
--disable-nls --without-included-gettext --disable-win32-registry
--enable-languages=c,c++,objc,obj-c++,fortran
--with-bugurl=http://bugzilla.redhat.com/bugzilla --with-cloog
--enable-threads=posix --enable-libgomp --target=x86_64-w64-mingw32
--with-sysroot=/usr/x86_64-w64-mingw32/sys-root
--with-gxx-include-dir=/usr/x86_64-w64-mingw32/sys-root/mingw/include/c++
Thread model: posix
gcc version 7.2.0 20170814 (Fedora MinGW 7.2.0-1.fc27) (GCC) 

$ rpm -qf `which x86_64-w64-mingw32-gcc`
mingw64-gcc-7.2.0-1.fc27.x86_64

$ uname -a
Linux build-fedora27 4.14.6-300.fc27.x86_64 #1 SMP Thu Dec 14 15:31:24 UTC 2017
x86_64 x86_64 x86_64 GNU/Linux

[Bug rtl-optimization/83147] LRA inheritance undo on multiple sets problem

[krebbel at gcc dot gnu.org]

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

--- Comment #3 from Andreas Krebbel  ---
(In reply to Vladimir Makarov from comment #2)
> (In reply to Andreas Krebbel from comment #1)
> > Created attachment 42714 [details]
> > Experimental patch
> > 
> > This patch appears to fix the problem for me. However, it isn't really
> > tested yet.
> 
> Hi, Andreas.  Thank you for working on this problem.
> 
> Although I can not reproduce the bug on today trunk, I am completely agree
> with your analysis and the patch.  If you don't mind i'll test the patch
> (under your name) and commit it to the trunk if it is ok for you.  Please,
> let me know.

Of course. Thanks!

[Bug c++/83942] New: False -Wunused-but-set-variable when const scoped enum is cast to int

[sbergman at redhat dot com]

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

Bug ID: 83942
   Summary: False -Wunused-but-set-variable when const scoped enum
is cast to int
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

With recent trunk "g++ (GCC) 8.0.1 20180119 (experimental)" towards GCC 8:

> $ cat test.cc
> enum class E { E1 };
> int main() {
> E const e = E::E1;
> return static_cast(e);
> }
> 
> $ g++ -Wall test.cc
> test.cc: In function ‘int main()’:
> test.cc:3:13: warning: variable ‘e’ set but not used 
> [-Wunused-but-set-variable]
>  E const e = E::E1;
>  ^

(which hit me when trying to build LibreOffice)

[Bug target/79262] [6/7/8 Regression] load gap with store gap causing performance regression in 462.libquantum

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

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

--- Comment #5 from Wilco  ---
Commit related to this:

commit a1b0b75cfc4f82162fc7e9b1f7255c98359a1078
Author: pinskia 
Date:   Wed Feb 1 18:30:50 2017 +

2017-02-01  Andrew Pinski  

* tree-vect-loop.c (vect_compute_single_scalar_iteration_cost):
Pass
stmt_info to record_stmt_cost.
(vect_get_known_peeling_cost): Pass stmt_info if known to
record_stmt_cost.
* config/aarch64/aarch64-protos.h (cpu_vector_cost): Split
cpu_vector_cost field into
scalar_int_stmt_cost and scalar_fp_stmt_cost.  Split vec_stmt_cost
field into vec_int_stmt_cost and vec_fp_stmt_cost.
* config/aarch64/aarch64.c (generic_vector_cost): Update for the
splitting of scalar_stmt_cost and vec_stmt_cost.
(thunderx_vector_cost): Likewise.
(cortexa57_vector_cost): LIkewise.
(exynosm1_vector_cost): Likewise.
(xgene1_vector_cost): Likewise.
(thunderx2t99_vector_cost): Improve after the splitting of the two
fields.
(aarch64_builtin_vectorization_cost): Update for the splitting of
scalar_stmt_cost and vec_stmt_cost.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@245101
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug rtl-optimization/83147] LRA inheritance undo on multiple sets problem

[vmakarov at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ra

--- Comment #2 from Vladimir Makarov  ---
(In reply to Andreas Krebbel from comment #1)
> Created attachment 42714 [details]
> Experimental patch
> 
> This patch appears to fix the problem for me. However, it isn't really
> tested yet.

Hi, Andreas.  Thank you for working on this problem.

Although I can not reproduce the bug on today trunk, I am completely agree with
your analysis and the patch.  If you don't mind i'll test the patch (under your
name) and commit it to the trunk if it is ok for you.  Please, let me know.

[Bug target/83008] [performance] Is it better to avoid extra instructions in data passing between loops?

[sergey.shalnov at intel dot com]

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

--- Comment #29 from sergey.shalnov at intel dot com ---
Richard,
Thank you for your latest patch. I would like to clarify 
the multiple_p() function usage in if() clause.

First of all,  I assume that architectures with fixed 
size of HW registers (x86) should go to if(){} branch, 
but arch with unknown registers size should go to else{}.
This is because is_constant() function used.

The problem is in multiple_p() function. In the test case 
we have group_size=16 and const_nunits=8.
So, the multiple_p(16, 8) returns 1 and with 
–march=skylake-avx512 (or –march=znver1) we go to 
else{} branch which is not correct.

I used following change in your patch and test works as I expect.
--- a/gcc/tree-vect-slp.c
+++ b/gcc/tree-vect-slp.c
@@ -1923,7 +1923,7 @@ vect_analyze_slp_cost_1 (slp_instance instance, slp_tree
node,
  unsigned HOST_WIDE_INT const_nunits;
  unsigned nelt_limit;
  if (TYPE_VECTOR_SUBPARTS (vectype).is_constant (_nunits)
- && ! multiple_p (group_size, const_nunits))
+ && multiple_p (group_size, const_nunits))
{
  num_vects_to_check = ncopies_for_cost * const_nunits /
group_size;
  nelt_limit = const_nunits;
-- 

Other thing here is what we should do if group_size is, for example, 17. 
In this case (after my changes) wrong else{} branch will be taken.

I would propose to change this particular if() in following way.

  if (TYPE_VECTOR_SUBPARTS (vectype).is_constant (_nunits))
{
If(multiple_p (group_size, const_nunits))
  {
num_vects_to_check = ncopies_for_cost * const_nunits /
group_size;
nelt_limit = const_nunits;
  }
else
  {
...not clear what we should have here...
  }
}
  else
{
  num_vects_to_check = 1;
  nelt_limit = group_size;
}

Or perhaps multiple_p() should not be here at all?

Sergey

[Bug sanitizer/82517] use-after-scope for a variable with big alignment causes a false positive

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Liška  ---
Does not make sense to backport as we're not planning to change shadow memory
mapping.

[Bug tree-optimization/83081] [8 regression][arm] gcc.dg/pr80218.c fails since r254888

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
I think the bug is in do_compare_rtx_and_jump probability handling, looking
into this now.

[Bug debug/83941] Debug info generated with -flto contains useless forwarders

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
So just use some needed bit on each DIE and only prune those which don't cary
any additional information from their abstract origin and aren't referenced by
anything?
E.g. there is die_mark bit that could be used for these purposes.

[Bug testsuite/83934] [8 regression] new test case g++.dg/torture/pr83619.C fails starting with its introduction in r256850

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Try r256890.  Sorry for screwing it up.

[Bug testsuite/83934] [8 regression] new test case g++.dg/torture/pr83619.C fails starting with its introduction in r256850

[seurer at gcc dot gnu.org]

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

--- Comment #4 from seurer at gcc dot gnu.org ---
These tests started failing again somewhere in the revision 256866 to 256871
range.

New failures:
FAIL: g++.dg/torture/pr83619.C   -O0   (test for warnings, line 27)
FAIL: g++.dg/torture/pr83619.C   -O1   (test for warnings, line 27)
FAIL: g++.dg/torture/pr83619.C   -O2 -flto -fno-use-linker-plugin
-flto-partition=none   (test for warnings, line 27)
FAIL: g++.dg/torture/pr83619.C   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects   (test for warnings, line 27)
FAIL: g++.dg/torture/pr83619.C   -O2   (test for warnings, line 27)
FAIL: g++.dg/torture/pr83619.C   -O3 -g   (test for warnings, line 27)
FAIL: g++.dg/torture/pr83619.C   -Os   (test for warnings, line 27)

[Bug target/83790] Update nvptx target to work with cuda 9

[cesar at gcc dot gnu.org]

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

--- Comment #1 from cesar at gcc dot gnu.org ---
Author: cesar
Date: Fri Jan 19 14:21:08 2018
New Revision: 256891

URL: https://gcc.gnu.org/viewcvs?rev=256891=gcc=rev
Log:
[nvptx] Add support for CUDA 9

PR target/83790

gcc/
* config/nvptx/nvptx.c (output_init_frag): Don't use generic address
spaces for function labels.

gcc/testsuite/
* gcc.target/nvptx/indirect_call.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/nvptx/indirect_call.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/nvptx/nvptx.c
trunk/gcc/testsuite/ChangeLog

[Bug target/83920] [8 Regression] [nvptx] bad predicate reset

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

   Keywords||openacc, patch
 CC||tschwinge at gcc dot gnu.org

--- Comment #11 from Tom de Vries  ---
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01729.html

[Bug tree-optimization/83081] [8 regression][arm] gcc.dg/pr80218.c fails since r254888

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
Even:
/* { dg-options "-O2 -fdump-rtl-ira-details-blocks -mcpu=cortex-a9
-march=armv7-a -mfpu=vfp -mfloat-abi=soft" } */
/* { dg-require-effective-target c99_runtime } */

void foo (float *);

void
f2 (float *x)
{
  __builtin_sqrtf (x[0]);
  foo (x);
}

/* { dg-final { scan-rtl-dump-not "Invalid sum" "ira" } } */
reproduces it with a cross, the Invalid sum messages still don't appear in the
*.optimized jump, but do appear in the *.expand jump.

[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
(In reply to Jonathan Wakely from comment #4)
> Ah, or maybe the typedef std::__cxx11::string is not in the debug info, so
> the type printer doesn't know that std::__cxx11::basic_string is the
> same type as std::__cxx11::string.
> 
> In testsuite/libstdc++-prettyprinters/whatis.cc we have a relevant comment:
> 
> // This test is written in a somewhat funny way.
> // Each type under test is used twice: first, to form a pointer type,
> // and second, as a template parameter.  This is done to work around
> // apparent GCC oddities.  The pointer type is needed to ensure that
> // the typedef in question ends up in the debuginfo; while the
> // template type is used to ensure that a typedef-less variant is
> // presented to gdb.
> 
> 
> Does this patch help?
> 
> --- a/libstdc++-v3/testsuite/libstdc++-prettyprinters/80276.cc
> +++ b/libstdc++-v3/testsuite/libstdc++-prettyprinters/80276.cc
> @@ -36,6 +36,7 @@ placeholder(const T *s)
>  int
>  main()
>  {
> +  std::string *string_ptr;
>using namespace std;
>unique_ptr>> p1;
>unique_ptr>[]> p2;
> @@ -50,6 +51,7 @@ main()
>placeholder();
>placeholder();
>placeholder();
> +  placeholder(_ptr);
>  
>std::cout << "\n";
>return 0;

This doesn't explain why does it fail at random.

[Bug tree-optimization/83510] [8 Regression] Recent changes for -Warray-bounds trigger false positive

[sirl at gcc dot gnu.org]

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

--- Comment #6 from Franz Sirl  ---
The patch in comment 5 applied to r256877 fixes the warning in both the
testcase and the original code.

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Liška  ---
I've got patch for that.

[Bug debug/83941] Debug info generated with -flto contains useless forwarders

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
I didn't yet try to quantify the amount of possible savings with pruning (well,
I tried with the simple patch but that keeps ICEing ... ;)).

Jakub, any opinion on the best approach here?

We eventually could, for DW_TAG_variables in local scopes, prune them when
we fail to annotate them (aka create them late) - that's maybe early enough
to avoid references from location lists (OTOH debug stmts might contain
references to them...).

Of course a post-processing tool like dwz could also remove them if they are
unused.

[Bug debug/83941] Debug info generated with -flto contains useless forwarders

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Created attachment 43186
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43186=edit
broken patch

This is an attempt at solving this by pruning those DIEs that didn't receive
any further annotation.  The issue with this is that for example
gcc.dg/torture/pr67253.c still ICEs with this because location lists might
refer to the
pruned dies - in this particular case via DW_OP_GNU_parameter_ref.

I'm unsure if all such references can be adjusted to refer to the original
debug - at least code that uses get_ref_die_offset would need to be
replaced with get_ref_die_offset_label as is used elsewhere to allow
references to $early-debug-symbol + offset.  This replacement might also
come with a larger cost than simply keeping the forwarder.

So a better approach would compute whether the forwarder is used and only
then prune it.

[Bug debug/83941] New: Debug info generated with -flto contains useless forwarders

[rguenth at gcc dot gnu.org]

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

Bug ID: 83941
   Summary: Debug info generated with -flto contains useless
forwarders
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: lto, missed-optimization
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

Currently for

int main()
{
  int i;
  return 0;
}

we emit

 <1><174>: Abbrev Number: 2 (DW_TAG_subprogram)
<175>   DW_AT_external: 1
<175>   DW_AT_name: (indirect string, offset: 0x152): main
<179>   DW_AT_decl_file   : 1
<17a>   DW_AT_decl_line   : 1
<17b>   DW_AT_decl_column : 5
<17c>   DW_AT_type: <0x18f>
<180>   DW_AT_sibling : <0x18f>
 <2><184>: Abbrev Number: 3 (DW_TAG_variable)
<185>   DW_AT_name: i
<187>   DW_AT_decl_file   : 1
<188>   DW_AT_decl_line   : 3
<189>   DW_AT_decl_column : 7
<18a>   DW_AT_type: <0x18f>
 <2><18e>: Abbrev Number: 0
 <1><18f>: Abbrev Number: 4 (DW_TAG_base_type)
<190>   DW_AT_byte_size   : 4
<191>   DW_AT_encoding: 5   (signed)
<192>   DW_AT_name: int

in the early unit and

 <1><1c9>: Abbrev Number: 3 (DW_TAG_subprogram)
<1ca>   DW_AT_abstract_origin: <0x174>
<1ce>   DW_AT_low_pc  : 0x4004b6
<1d6>   DW_AT_high_pc : 0x6
<1de>   DW_AT_frame_base  : 1 byte block: 9c(DW_OP_call_frame_cfa)
<1e0>   DW_AT_GNU_all_call_sites: 1
 <2><1e0>: Abbrev Number: 4 (DW_TAG_variable)
<1e1>   DW_AT_abstract_origin: <0x184>

in the late one.  Note the "useless" DIE for 'i' which isn't necessary
to make gdb print '' - gdb happily picks up variables
for name lookup without the extra forwarder via the DW_TAG_subprogram
abstract origin children.

[Bug middle-end/81657] [8 Regression] FAIL: gcc.dg/20050503-1.c scan-assembler-not call

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek  ---
strchr with a c == 0 codepath doesn't have to be the same inner loop as strlen
and for the returning of pointer rather than length can be more efficient than
strlen.

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

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Rounding errors, I'll make it check within a tolerance.

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

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #6 from Rainer Orth  ---
The new test FAILs on 32-bit x86 (seen on i386-pc-solaris2.*,
x86_64-pc-linux-gnu -m32,
and i686-pc-linux-gnu):

+FAIL: 26_numerics/random/chi_squared_distribution/83833.cc execution test

/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/26_numerics/random/chi_squared_distribution/83833.cc:32:
void test01(): Assertion 'd1(r1) == d2(r2)' failed.

  Rainer

[Bug middle-end/81657] [8 Regression] FAIL: gcc.dg/20050503-1.c scan-assembler-not call

[hjl.tools at gmail dot com]

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

--- Comment #18 from H.J. Lu  ---
(In reply to Wilco from comment #17)
> (In reply to Jakub Jelinek from comment #16)
> > (In reply to Wilco from comment #15)
> > > I don't think it's safe to compare different benchmark results like that.
> > > But yes the kernel for both should be very similar. The key difference is
> > > that strchr needs 2x the number of comparisons, which is why an optimized
> > > strlen will always be faster than strchr.
> > 
> > That is of course not true, it can do e.g. just the number of comparisons
> > strlen needs + 1.
> 
> No, strchr searches for 2 characters, strlen for just 1. Of course if you
> want to special case strchr (p, 0) to use strlen because that is faster then
> I guess we agree that is the right transformation.

This is true for strchr vs strlen.  But it isn't true for memcpy vs
mempcpy.  x86 doesn't want mempcpy -> memcpy conversion.

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

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Looking at other PRs first, but intend to get to this soon.

[Bug rtl-optimization/83886] [8 Regression] ICE in cfg_layout_redirect_edge_and_branch, at cfgrtl.c:4433

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-19
 CC||hubicka at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Started with r254832.

[Bug fortran/78797] It is time perhaps to implement -std=f2015

[vladimir.fuka at gmail dot com]

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

Vladimir Fuka  changed:

   What|Removed |Added

 CC||vladimir.fuka at gmail dot com

--- Comment #9 from Vladimir Fuka  ---
(In reply to janus from comment #3)
> (In reply to Paul Thomas from comment #2)
> > I will post the existence of this PR to the list over the weekend togetehr
> > with: ftp://ftp.nag.co.uk/sc22wg5/n1551-n1600/n1579.pdf
> 
> This document describes the new features of Fortran 2003, and I know that
> there is also one for 2008. But what about 2015?

There is one for Fortran 2015 as well. https://doi.org/10.1145/3131212.3131213
I am not sure if there is a non-paywall version.

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

[rguenther at suse dot de]

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

--- Comment #16 from rguenther at suse dot de  ---
On Fri, 19 Jan 2018, arnd at linaro dot org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83651
> 
> --- Comment #15 from Arnd Bergmann  ---
> (In reply to rguent...@suse.de from comment #14)
> 
> > Would be nice if somebody can bisect it.  It doesn't look like a PRE
> > specific issue because there's no relevant PRE changes in the rev. range.
> > I can't reproduce the slowdown when comparing 7.1.0 against 7.2.0
> > btw, so the regression must occur somewhere between 7.2.0 and now
> > (or 7.1.1 got faster for a few revs).
> 
> I've checked r251376 (the one I mentioned in comment #11), and confirmed that
> this caused the difference between my old 7.1.1 and the current 7.2.1.

Ok, this is a bugfix and simply makes PRE do its job "properly" ...

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

[arnd at linaro dot org]

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

--- Comment #15 from Arnd Bergmann  ---
(In reply to rguent...@suse.de from comment #14)

> Would be nice if somebody can bisect it.  It doesn't look like a PRE
> specific issue because there's no relevant PRE changes in the rev. range.
> I can't reproduce the slowdown when comparing 7.1.0 against 7.2.0
> btw, so the regression must occur somewhere between 7.2.0 and now
> (or 7.1.1 got faster for a few revs).

I've checked r251376 (the one I mentioned in comment #11), and confirmed that
this caused the difference between my old 7.1.1 and the current 7.2.1.

[Bug middle-end/81657] [8 Regression] FAIL: gcc.dg/20050503-1.c scan-assembler-not call

[wilco at gcc dot gnu.org]

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

--- Comment #17 from Wilco  ---
(In reply to Jakub Jelinek from comment #16)
> (In reply to Wilco from comment #15)
> > I don't think it's safe to compare different benchmark results like that.
> > But yes the kernel for both should be very similar. The key difference is
> > that strchr needs 2x the number of comparisons, which is why an optimized
> > strlen will always be faster than strchr.
> 
> That is of course not true, it can do e.g. just the number of comparisons
> strlen needs + 1.

No, strchr searches for 2 characters, strlen for just 1. Of course if you want
to special case strchr (p, 0) to use strlen because that is faster then I guess
we agree that is the right transformation.

[Bug middle-end/81657] [8 Regression] FAIL: gcc.dg/20050503-1.c scan-assembler-not call

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
(In reply to Wilco from comment #15)
> I don't think it's safe to compare different benchmark results like that.
> But yes the kernel for both should be very similar. The key difference is
> that strchr needs 2x the number of comparisons, which is why an optimized
> strlen will always be faster than strchr.

That is of course not true, it can do e.g. just the number of comparisons
strlen needs + 1.

[Bug middle-end/81657] [8 Regression] FAIL: gcc.dg/20050503-1.c scan-assembler-not call

[wilco at gcc dot gnu.org]

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

--- Comment #14 from Wilco  ---
(In reply to Jakub Jelinek from comment #11)
> No matter what, I don't see how you could use much common infrastructure
> here.
> Say if the tailcall pass sees strlen (something) + something being returned,
> it could turn that into strchr (something, 0), because both functions are
> standard.
> We can't do that if we see memcpy (x, y, len) + len, because mempcpy is not
> a C standard function, while memcpy is, so if the information that mempcpy
> was originally used is lost, then it is completely lost.

I believe there is a way to check whether you've seen a declaration. If that
fails you can still know whether a function originally contained mempcpy just
like alloca.

[Bug middle-end/81657] [8 Regression] FAIL: gcc.dg/20050503-1.c scan-assembler-not call

[wilco at gcc dot gnu.org]

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

--- Comment #15 from Wilco  ---
(In reply to H.J. Lu from comment #13)
> (In reply to Wilco from comment #12)
> 
> > > 
> > > Do you have data to show that?
> > 
> > Yes, on x64 I get these timings for a simple function containing just the
> > library call:
> > 
> > size  1024 - 13845 21025 14449 (rawmemchr/memchr/strlen)
> 
> On Skylake/x86-64, I got
> 
> strlen:
> 
> Length 1024, alignment  0:178.781
> Length 1024, alignment  7:162.625
> Length 1024, alignment 10:161.969
> 
> strchr:
> 
> Length 1024, alignment in bytes  0:   83.7812
> Length 1024, alignment in bytes  6:   82.0938
> 
> strchr is 2X faster.  It uses a very different algorithm. I will
> check if I can fold strlen into strchr.

I don't think it's safe to compare different benchmark results like that. But
yes the kernel for both should be very similar. The key difference is that
strchr needs 2x the number of comparisons, which is why an optimized strlen
will always be faster than strchr.

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

[rguenther at suse dot de]

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

--- Comment #14 from rguenther at suse dot de  ---
On Fri, 19 Jan 2018, arnd at linaro dot org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83651
> 
> --- Comment #13 from Arnd Bergmann  ---
> Created attachment 43185
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43185=edit
> Linux kernel version of AES algorithm, ported to standalone executable
> 
> I've had another look at extracting a test case from the Linux kernel copy of
> this code. This now also shows the gcc-7.2.1 specific problem:
> 
> $ x86_64-linux-gcc-7.1.1 -Wall -O2 -fsanitize=bounds -fsanitize=object-size
> aes_generic.c -o aes_generic; time ./aes_generic
> real0m9.406s
> 
> $ x86_64-linux-gcc-7.1.1 -Wall -O2 -fsanitize=bounds -fsanitize=object-size
> aes_generic.c -o aes_generic -fno-code-hoisting; time ./aes_generic
> real0m8.318s
> 
> $ x86_64-linux-gcc-7.2.1 -Wall -O2 -fsanitize=bounds -fsanitize=object-size
> aes_generic.c -o aes_generic; time ./aes_generic
> real0m22.151s
> 
> $ x86_64-linux-gcc-7.2.1 -Wall -O2 -fsanitize=bounds -fsanitize=object-size
> aes_generic.c -o aes_generic -fno-code-hoisting; time ./aes_generic
> real0m8.439s
> 
> $ x86_64-linux-gcc-7.1.1 -Wall -O2 aes_generic.c -o aes_generic ; time
> ./aes_generic
> real0m3.031s
> 
> $ x86_64-linux-gcc-7.1.1 -Wall -O2 aes_generic.c -o aes_generic
> -fno-code-hoisting ; time ./aes_generic
> real0m2.894s
> 
> $ x86_64-linux-gcc-7.2.1 -Wall -O2 aes_generic.c -o aes_generic  ; time
> ./aes_generic
> real0m3.307s
> 
> $ x86_64-linux-gcc-7.2.1 -Wall -O2 aes_generic.c -o aes_generic
> -fno-code-hoisting ; time ./aes_generic
> real0m2.875s

Would be nice if somebody can bisect it.  It doesn't look like a PRE
specific issue because there's no relevant PRE changes in the rev. range.
I can't reproduce the slowdown when comparing 7.1.0 against 7.2.0
btw, so the regression must occur somewhere between 7.2.0 and now
(or 7.1.1 got faster for a few revs).

[Bug debug/83917] [8 Regression] with -mcall-ms2sysv-xlogues, stepping into x86 tail-call restore stub gives bad backtrace

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
So, is this about debug info (which I believe shouldn't be needed), or missing
unwind info?
I presume the mingw unwind info isn't done through .cfi_* directives, so would
need to be written by hand.  How hard is that, and is this really a regression,
those snippets didn't exist before?

[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Ah, or maybe the typedef std::__cxx11::string is not in the debug info, so the
type printer doesn't know that std::__cxx11::basic_string is the same
type as std::__cxx11::string.

In testsuite/libstdc++-prettyprinters/whatis.cc we have a relevant comment:

// This test is written in a somewhat funny way.
// Each type under test is used twice: first, to form a pointer type,
// and second, as a template parameter.  This is done to work around
// apparent GCC oddities.  The pointer type is needed to ensure that
// the typedef in question ends up in the debuginfo; while the
// template type is used to ensure that a typedef-less variant is
// presented to gdb.


Does this patch help?

--- a/libstdc++-v3/testsuite/libstdc++-prettyprinters/80276.cc
+++ b/libstdc++-v3/testsuite/libstdc++-prettyprinters/80276.cc
@@ -36,6 +36,7 @@ placeholder(const T *s)
 int
 main()
 {
+  std::string *string_ptr;
   using namespace std;
   unique_ptr>> p1;
   unique_ptr>[]> p2;
@@ -50,6 +51,7 @@ main()
   placeholder();
   placeholder();
   placeholder();
+  placeholder(_ptr);

   std::cout << "\n";
   return 0;

[Bug tree-optimization/83940] [8 Regression] ICE in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1531

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
As Jakub says, I think these are preexisting problems in the x86 scatter
support that only kick in now that autovectorised scatters are supported.

[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
That suggests the type printer for std::__cxx11::string is not being used, so
maybe it's conflicting with another printer, and so the result depends which
gets found first.

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

[arnd at linaro dot org]

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

--- Comment #13 from Arnd Bergmann  ---
Created attachment 43185
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43185=edit
Linux kernel version of AES algorithm, ported to standalone executable

I've had another look at extracting a test case from the Linux kernel copy of
this code. This now also shows the gcc-7.2.1 specific problem:

$ x86_64-linux-gcc-7.1.1 -Wall -O2 -fsanitize=bounds -fsanitize=object-size
aes_generic.c -o aes_generic; time ./aes_generic
real0m9.406s

$ x86_64-linux-gcc-7.1.1 -Wall -O2 -fsanitize=bounds -fsanitize=object-size
aes_generic.c -o aes_generic -fno-code-hoisting; time ./aes_generic
real0m8.318s

$ x86_64-linux-gcc-7.2.1 -Wall -O2 -fsanitize=bounds -fsanitize=object-size
aes_generic.c -o aes_generic; time ./aes_generic
real0m22.151s

$ x86_64-linux-gcc-7.2.1 -Wall -O2 -fsanitize=bounds -fsanitize=object-size
aes_generic.c -o aes_generic -fno-code-hoisting; time ./aes_generic
real0m8.439s

$ x86_64-linux-gcc-7.1.1 -Wall -O2 aes_generic.c -o aes_generic ; time
./aes_generic
real0m3.031s

$ x86_64-linux-gcc-7.1.1 -Wall -O2 aes_generic.c -o aes_generic
-fno-code-hoisting ; time ./aes_generic
real0m2.894s

$ x86_64-linux-gcc-7.2.1 -Wall -O2 aes_generic.c -o aes_generic  ; time
./aes_generic
real0m3.307s

$ x86_64-linux-gcc-7.2.1 -Wall -O2 aes_generic.c -o aes_generic
-fno-code-hoisting ; time ./aes_generic
real0m2.875s

[Bug tree-optimization/83940] [8 Regression] ICE in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1531

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Unfortunately, on the trunk, the vect_is_simple_use call for op is hidden in
the new vect_check_store_rhs function and the dt isn't propagated to the
caller, I think we should change that.

The several
vect_is_simple_use (vec_oprnd, vinfo, _stmt, );
calls later on in vectorizable_store also look quite questionable to me,
shouldn't vect_is_simple_use be called with the scalar operand of the original
stmt rather than with whatever we've just created, and shouldn't it be called
in the analysis part of the function so that it can also fail?