[Bug fortran/68155] ICE on initializing character array in type (len_lhs <> len_rhs)

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #8 from kargl at gcc dot gnu.org ---
The code in the original comment compiles and gives

 gfcx -o z a.f90 && ./z
 y


The code in comment #2 gives

 gfcx -o z a.f90 && ./z
 ab

The code without type gives in comment #6 gives

 gfcx -o z a.f90 && ./z
   2   3 b  c  
   2   3 ab ac 
   2   3 axbaxc
   2   3 axyaxy

when wrapped in TYPE, I get

 gfcx -o z a.f90 && ./z
a.f90:13:0:

 end

internal compiler error: in output_constructor_regular_field, at varasm.c:5125
0x6cd37a output_constructor_regular_field
../../gcc/gcc/varasm.c:5125
0x6cd37a output_constructor
../../gcc/gcc/varasm.c:5433
0xfd4190 output_constant
../../gcc/gcc/varasm.c:4807
0xfd4190 output_constructor_regular_field
../../gcc/gcc/varasm.c:5163
0xfd4190 output_constructor
../../gcc/gcc/varasm.c:5433
0xfd56b1 output_constant
../../gcc/gcc/varasm.c:4807
0xfd56b1 assemble_variable_contents
../../gcc/gcc/varasm.c:2126
0xfdb41f assemble_variable(tree_node*, int, int, int)
../../gcc/gcc/varasm.c:2305
0xfdff99 varpool_node::assemble_decl()
../../gcc/gcc/varpool.c:590
0x934f1c output_in_order
../../gcc/gcc/cgraphunit.c:2385
0x934f1c symbol_table::compile()
../../gcc/gcc/cgraphunit.c:2623
0x937059 symbol_table::compile()
../../gcc/gcc/cgraphunit.c:2537
0x937059 symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2717

So some of this PR is fixed.

[Bug tree-optimization/84824] DCE fails to remove dead code of std::function constructor

[manjian2006 at gmail dot com]

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

--- Comment #15 from linzj  ---
The structalias solve_graph is not resolving the nodes reachable from a source
node, which make my try fail.

[Bug c++/85012] New: GCC does not inline extern "C" functions defined in a different namespace

[m101010a at gmail dot com]

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

Bug ID: 85012
   Summary: GCC does not inline extern "C" functions defined in a
different namespace
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m101010a at gmail dot com
  Target Milestone: ---

$ cat x.cpp
namespace foo { extern "C" void f(); }
extern "C" void f() {}
void f1()
{
foo::f();
foo::f();
}
void f2()
{
f();
f();
}

$ g++ -v -S -O1 x.cpp
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 7.3.1 20180312 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-S' '-O1' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/cc1plus -E -quiet -v -D_GNU_SOURCE
x.cpp -mtune=generic -march=x86-64 -O1 -fpch-preprocess -o x.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../include/c++/7.3.1

/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../include/c++/7.3.1/x86_64-pc-linux-gnu
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../include/c++/7.3.1/backward
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include
 /usr/local/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-S' '-O1' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/cc1plus -fpreprocessed x.ii -quiet
-dumpbase x.cpp -mtune=generic -march=x86-64 -auxbase x -O1 -version -o x.s
GNU C++14 (GCC) version 7.3.1 20180312 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.3.1 20180312, GMP version 6.1.2, MPFR
version 4.0.1, MPC version 1.1.0, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (GCC) version 7.3.1 20180312 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.3.1 20180312, GMP version 6.1.2, MPFR
version 4.0.1, MPC version 1.1.0, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 7db9d5d3f13a1b145edda774ba2b8b66
COMPILER_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-S' '-O1' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'


The generated assembly for f2 contains only a return.  The generated assembly
for f1 contains 2 calls to f.  Since ::f and foo::f refer to the same
function^[1], the same optimizations should be applied to calls using either
name.

[1] n4659 section 10.5 [dcl.link] paragraph 6: Two declarations for a function
with C language linkage with the same function name (ignoring the namespace
names that qualify it) that appear in different namespace scopes refer to the
same function.

[Bug fortran/64925] ICE with same names for dummy arg and internal procedure

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||zeccav at gmail dot com

--- Comment #6 from kargl at gcc dot gnu.org ---
*** Bug 44348 has been marked as a duplicate of this bug. ***

[Bug fortran/44348] ICE in build_function_decl

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #23 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #22)
> (In reply to Harald Anlauf from comment #21)
> > I did not encounter any ICE with the test cases in this PR which I tried.
> > Have they been fixed by Steve's recent patch?
> 
> Yes, at least for comment #2 and #12.  It is a duplicate PR77414.

The code in comment 1 was fixed by 

r223313 | kargl | 2015-05-18 12:25:49 -0700 (Mon, 18 May 2015) | 11 lines

2015-05-18  Steven G. Kargl  

PR fortran/64925
* symbol.c(check_conflict):  Check for a conflict between a dummy
argument and an internal procedure name.

2015-05-18  Steven G. Kargl  

PR fortran/64925
* gfortran.dg/pr64925.f90: New test.

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

[Bug c++/85011] New: GCC complains that 2 identical function prototypes are different

[m101010a at gmail dot com]

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

Bug ID: 85011
   Summary: GCC complains that 2 identical function prototypes are
different
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m101010a at gmail dot com
  Target Milestone: ---

$ cat x.cpp
template  struct foo {
int x;
auto f1() -> decltype(x);
};
template  auto foo::f1() -> decltype ((this)->foo::x) {}

$ g++ -v -fsyntax-only x.cpp
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 7.3.1 20180312 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-fsyntax-only' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/cc1plus -quiet -v -D_GNU_SOURCE x.cpp
-quiet -dumpbase x.cpp -mtune=generic -march=x86-64 -auxbase x -version
-fsyntax-only -o /dev/null
GNU C++14 (GCC) version 7.3.1 20180312 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.3.1 20180312, GMP version 6.1.2, MPFR
version 4.0.1, MPC version 1.1.0, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../include/c++/7.3.1

/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../include/c++/7.3.1/x86_64-pc-linux-gnu
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../include/c++/7.3.1/backward
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include
 /usr/local/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include-fixed
 /usr/include
End of search list.
GNU C++14 (GCC) version 7.3.1 20180312 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.3.1 20180312, GMP version 6.1.2, MPFR
version 4.0.1, MPC version 1.1.0, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 7db9d5d3f13a1b145edda774ba2b8b66
x.cpp:5:25: error: prototype for ‘decltype (((foo*)this)->foo::x)
foo::f1()’ does not match any in class ‘foo’
 template  auto foo::f1() -> decltype ((this)->foo::x) {}
 ^~
x.cpp:3:7: error: candidate is: decltype (((foo*)this)->foo::x)
foo::f1()
  auto f1() -> decltype(x);
   ^~

This error message is nonsensical, since it claims that the prototype for f1 on
lines 3 and 5 differ, yet the error messages list the same prototype for each.

[Bug target/83789] __builtin_altivec_lvx fails for powerpc for altivec-4.c

[Kaushik.Phatak at kpit dot com]

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

--- Comment #21 from Kaushik.Phatak at kpit dot com ---
Hi Peter,
Thanks for your work on this.

>> Kaushik, remind me, you're seeing the same ICE in GCC 7 as well
Yes, this does fail in gcc-7.x.

>> so we need a backport of the patch committed to trunk?
If a backport to GCC 7 is feasible, then that would be very much appreciated.
I tried patching parts of the file as-is, but it fails while patching the hunk
to the file, rs6000-p8swap.c
This file (rs6000-p8swap.c) does not exist in gcc-7.x and was introduced in 8,
I believe.

Thanks & Best Regards,
Kaushik M. Phatak

-Original Message-
From: bergner at gcc dot gnu.org [mailto:gcc-bugzi...@gcc.gnu.org] 
Sent: Tuesday, March 20, 2018 11:02 PM
To: Kaushik Phatak 
Subject: [Bug target/83789] __builtin_altivec_lvx fails for powerpc for
altivec-4.c

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

--- Comment #20 from Peter Bergner  --- Kaushik,
remind me, you're seeing the same ICE in GCC 7 as well, so we need a backport
of the patch committed to trunk?

--
You are receiving this mail because:
You are on the CC list for the bug.
You reported the bug.

[Bug fortran/85001] [6/7/8 Regression] ICE in gfc_build_array_type, at fortran/trans-types.c:1420

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

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

[Bug ada/85010] [8 Regression] gnat bootstrap fails in assemble_variable, at varasm.c:2297 (power*, aarch64)

[doko at gcc dot gnu.org]

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

--- Comment #2 from Matthias Klose  ---
last known successful build is r258631 on power*-linux-gnu and
aarch64-linux-gnu.

[Bug fortran/85001] [6/7/8 Regression] ICE in gfc_build_array_type, at fortran/trans-types.c:1420

[kargl at gcc dot gnu.org]

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

--- Comment #7 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Mar 21 01:27:42 2018
New Revision: 258700

URL: https://gcc.gnu.org/viewcvs?rev=258700=gcc=rev
Log:
2018-03-20  Steven G. Kargl  

PR fortran/85001
* interface.c (symbol_rank): Remove bogus null pointer check that
crept in when translating a ternary operator into an if-else 
constructor.

2018-03-20  Steven G. Kargl  

PR fortran/85001
* gfortran.dg/interface_41.f90: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/interface_41.f90
Modified:
branches/gcc-6-branch/gcc/fortran/interface.c

[Bug fortran/85001] [6/7/8 Regression] ICE in gfc_build_array_type, at fortran/trans-types.c:1420

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Mar 21 01:26:25 2018
New Revision: 258699

URL: https://gcc.gnu.org/viewcvs?rev=258699=gcc=rev
Log:
2018-03-20  Steven G. Kargl  

PR fortran/85001
* interface.c (symbol_rank): Remove bogus null pointer check that
crept in when translating a ternary operator into an if-else 
constructor.

2018-03-20  Steven G. Kargl  

PR fortran/85001
* gfortran.dg/interface_41.f90: New test.

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

[Bug ada/85010] [8 Regression] gnat bootstrap fails in assemble_variable, at varasm.c:2297 (power*, aarch64)

[doko at gcc dot gnu.org]

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

--- Comment #1 from Matthias Klose  ---
... and on aarch64-linux-gnu

[Bug ada/85010] New: [8 Regression] gnat bootstrap fails in assemble_variable, at varasm.c:2297 (power*, aarch64)

[doko at gcc dot gnu.org]

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

Bug ID: 85010
   Summary: [8 Regression] gnat bootstrap fails in
assemble_variable, at varasm.c:2297 (power*, aarch64)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

seen with r258670 on various powerpc* targets:

+===GNAT BUG DETECTED==+
| 8.0.1 20180320 (experimental) [trunk revision 258670] (powerpc-linux-gnu) GCC
error:|
| in assemble_variable, at varasm.c:2297   |
| Error detected around ../../src/gcc/ada/libgnat/s-rident.ads:75:16   |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+


complete build logs at
https://buildd.debian.org/status/fetch.php?pkg=gcc-8=ppc64el=8-20180320-1=1521529621=0
https://buildd.debian.org/status/fetch.php?pkg=gcc-8=ppc64=8-20180320-1=1521530331=0
https://buildd.debian.org/status/fetch.php?pkg=gcc-8=powerpc=8-20180320-1=1521529806=0

powerpc64le configured as

 --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++
 --prefix=/usr
 --with-gcc-major-version-only
 --program-suffix=-8
 --program-prefix=powerpc64le-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
 --enable-plugin
 --enable-default-pie
 --with-system-zlib
 --disable-libphobos
 --enable-objc-gc=auto
 --enable-secureplt
 --with-cpu=power8
 --enable-targets=powerpcle-linux
 --disable-multilib
 --enable-multiarch
 --disable-werror
 --with-long-double-128
 --enable-checking=release
 --build=powerpc64le-linux-gnu
 --host=powerpc64le-linux-gnu
 --target=powerpc64le-linux-gnu

[Bug fortran/85001] [6/7/8 Regression] ICE in gfc_build_array_type, at fortran/trans-types.c:1420

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Mar 21 01:07:43 2018
New Revision: 258698

URL: https://gcc.gnu.org/viewcvs?rev=258698=gcc=rev
Log:
2018-03-20  Steven G. Kargl  

PR fortran/85001
* interface.c (symbol_rank): Remove bogus null pointer check that
crept in when translating a ternary operator into an if-else 
constructor.

2018-03-20  Steven G. Kargl  

PR fortran/85001
* gfortran.dg/interface_41.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/interface_41.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/85001] [6/7/8 Regression] ICE in gfc_build_array_type, at fortran/trans-types.c:1420

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Sigh.  Replaced a NULL pointer dereference with assigning a valid but wrong
pointer to as.

[Bug c/85009] missing -Wdiscarded-qualifiers when dropping _Atomic

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
It's not obvious that this is a bug, in that _Atomic is syntactically a 
qualifier, but excluded semantically for most purposes.  In particular, 
that conversion is permitted by ISO C, so the _Atomic case must *not* be a 
pedwarn, even if it receives a -Wdiscarded-qualifiers warning.

[Bug fortran/85001] [6/7/8 Regression] ICE in gfc_build_array_type, at fortran/trans-types.c:1420

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #2)
> gfortran-8 changed at r254604 (pr78814).
> gfortran-7 changed at r256646.
> gfortran-6 changed at r256647.

Remove myself from CC list.  My patches prevent
a NULL pointer dereference, which force the 
compiler to take a different path.  Whoever 
wrote the CLASS_DATA() macro and abused it
needs to fix the alternative path.

[Bug fortran/85002] [7/8 Regression] ICE in fold_ternary_loc, at fold-const.c:11360

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
  Known to work||6.4.0
   Keywords||ice-on-valid-code
   Last reconfirmed||2018-03-21
 CC||vehre at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |7.4
  Known to fail||7.3.0, 8.0.1

--- Comment #1 from Dominique d'Humieres  ---
Reduced range: r242984 (2016-11-29) is OK, r243219 (2016-11-29) gives the ICE,
r243021?

The test compiles without the line

   y = t2([x])

[Bug c++/84994] Missing accessor hint for private field at -O1 and above when -g is enabled

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Keywords||patch
 Status|NEW |WAITING

--- Comment #3 from David Malcolm  ---
Candidate patch:
  https://gcc.gnu.org/ml/gcc-patches/2018-03/msg01042.html

[Bug c++/84892] Missing accessor hint for private field

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Keywords||patch
 Status|NEW |WAITING

--- Comment #2 from David Malcolm  ---
Candidate patch:
  https://gcc.gnu.org/ml/gcc-patches/2018-03/msg01041.html

[Bug c/85009] New: missing -Wdiscarded-qualifiers when dropping _Atomic

[msebor at gcc dot gnu.org]

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

Bug ID: 85009
   Summary: missing -Wdiscarded-qualifiers when dropping _Atomic
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC issues -Wdiscarded-qualifiers when an assignment loses the const, restrict,
or volatile qualifier but it fails to issue the same warning for the _Atomic
qualifier.  Clang and Oracle CC have the same bug, but Intel ICC does give the
expected warning.

$ cat z.c && gcc -S -Wall -Wextra -Wpedantic z.c
void *p;

void
f (const int *pci, volatile int *pvi, int* restrict* pirp, _Atomic int *pai)
{
  p = pci;// -Wdiscarded-qualifiers (good)
  p = pvi;// -Wdiscarded-qualifiers (good)
  p = pirp;   // -Wdiscarded-qualifiers (good)

  p = pai;// missing -Wdiscarded-qualifiers
}
z.c: In function ‘f’:
z.c:6:5: warning: assignment discards ‘const’ qualifier from pointer target
type [-Wdiscarded-qualifiers]
   p = pci;// -Wdiscarded-qualifiers (good)
 ^
z.c:7:5: warning: assignment discards ‘volatile’ qualifier from pointer target
type [-Wdiscarded-qualifiers]
   p = pvi;// -Wdiscarded-qualifiers (good)
 ^
z.c:8:5: warning: assignment discards ‘restrict’ qualifier from pointer target
type [-Wdiscarded-qualifiers]
   p = pirp;   // -Wdiscarded-qualifiers (good)
 ^
tmp$

[Bug fortran/85001] [6/7/8 Regression] ICE in gfc_build_array_type, at fortran/trans-types.c:1420

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
  Known to work||6.4.0
   Keywords||ice-on-invalid-code
   Last reconfirmed||2018-03-20
 CC||kargl at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |6.5
  Known to fail||6.4.1, 7.3.0, 8.0.1

--- Comment #2 from Dominique d'Humieres  ---
gfortran-8 changed at r254604 (pr78814).
gfortran-7 changed at r256646.
gfortran-6 changed at r256647.

[Bug middle-end/85003] Inline built-in fdim for -fno-math-errno

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-20
  Component|tree-optimization   |middle-end
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug fortran/84957] [8 Regression] ICE in gfc_sym_type, at fortran/trans-types.c:2255

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #2 from Harald Anlauf  ---
ICE is due to null pointer dereference, fixed by:

Index: gcc/fortran/trans-types.c
===
--- gcc/fortran/trans-types.c   (revision 258658)
+++ gcc/fortran/trans-types.c   (working copy)
@@ -2252,6 +2252,7 @@
   && sym->ts.type == BT_CHARACTER
   && sym->ts.u.cl->backend_decl == NULL_TREE
   && sym->ns->proc_name
+  && sym->ns->proc_name->ts.u.cl
   && sym->ns->proc_name->ts.u.cl->backend_decl != NULL_TREE)
 sym->ts.u.cl->backend_decl = sym->ns->proc_name->ts.u.cl->backend_decl;

[Bug c/84919] [8 Regression] error: passing argument 1 to restrict-qualified parameter aliases with argument 5 [-Werror=restrict]

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Target Milestone|8.0 |9.0

--- Comment #13 from Jeffrey A. Law  ---
I think this needs to defer to gcc-9.

[Bug target/84838] Minor grammar fixes for x86 options

[law at gcc dot gnu.org]

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

--- Comment #2 from Jeffrey A. Law  ---
Author: law
Date: Tue Mar 20 22:22:28 2018
New Revision: 258694

URL: https://gcc.gnu.org/viewcvs?rev=258694=gcc=rev
Log:
PR target/84838
* Minor grammar fixes for x86 options.

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

[Bug libstdc++/84998] [8 Regression] std::hash<std::bitset> fails in Debug Mode

[fdumont at gcc dot gnu.org]

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

--- Comment #3 from François Dumont  ---
Author: fdumont
Date: Tue Mar 20 21:45:14 2018
New Revision: 258693

URL: https://gcc.gnu.org/viewcvs?rev=258693=gcc=rev
Log:
2018-03-20  François Dumont  

PR libstdc++/84998
* include/bits/stl_bvector.h: Fix std::hash friend declaration.
* include/std/bitset: Likewise.
* include/bits/stl_map.h (std::map<>): Fix _Rb_tree_merge_helper friend
declaration.
* include/bits/stl_multimap.h (std::multimap<>): Likewise.
* include/bits/stl_multiset.h (std::multiset<>): Likewise.
* include/bits/stl_set.h (std::set<>): Likewise.
* include/bits/unordered_map.h (std::unordered_map<>): Fix
_Hash_merge_helper friend declaration.
(std::unordered_multimap<>): Likewise.
* include/bits/unordered_set.h (std::unordered_set<>): Likewise.
(std::unordered_multiset<>): Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_bvector.h
trunk/libstdc++-v3/include/bits/stl_map.h
trunk/libstdc++-v3/include/bits/stl_multimap.h
trunk/libstdc++-v3/include/bits/stl_multiset.h
trunk/libstdc++-v3/include/bits/stl_set.h
trunk/libstdc++-v3/include/bits/unordered_map.h
trunk/libstdc++-v3/include/bits/unordered_set.h
trunk/libstdc++-v3/include/debug/vector
trunk/libstdc++-v3/include/std/bitset

[Bug c++/84851] missing -Wclass-memaccess for a memcpy in a copy ctor with a non-trivial member

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-20
 CC||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jason Merrill  ---
Agreed; since A isn't trivially copyable, we should warn in C::C.

[Bug c++/85008] New: internal compiler error: lang_* check: failed in decl_cloned_function_p, at cp/class.c:4577

[vegard.nossum at oracle dot com]

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

Bug ID: 85008
   Summary: internal compiler error: lang_* check: failed in
decl_cloned_function_p, at cp/class.c:4577
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vegard.nossum at oracle dot com
CC: webrown.cpp at gmail dot com
  Target Milestone: ---

Input:

void a() {
  struct b {
~b();
__attribute__((c(::~)))
  }
}

Output:

$ cc1plus 
 void a()
:4:27: error: expected class-name before ')' token
:4:27: internal compiler error: lang_* check: failed in
decl_cloned_function_p, at cp/class.c:4577
0x5efa30 lang_check_failed(char const*, int, char const*)
/home/vegard/git/gcc/gcc/cp/tree.c:5373
0x9b16c7 decl_cloned_function_p(tree_node const*, bool)
/home/vegard/git/gcc/gcc/cp/class.c:4577
0x13255c2 decl_linkage(tree_node*)
/home/vegard/git/gcc/gcc/cp/tree.c:4966
0xc6316d mark_used(tree_node*, int)
/home/vegard/git/gcc/gcc/cp/decl2.c:5316
0x12aebcb finish_id_expression(tree_node*, tree_node*, tree_node*, cp_id_kind*,
bool, bool, bool*, bool, bool, bool, bool, char const**, unsigned int)
/home/vegard/git/gcc/gcc/cp/semantics.c:3706
0xf33f42 cp_parser_primary_expression
/home/vegard/git/gcc/gcc/cp/parser.c:5611
0xf7698b cp_parser_postfix_expression
/home/vegard/git/gcc/gcc/cp/parser.c:7030
0xf2a4b7 cp_parser_unary_expression
/home/vegard/git/gcc/gcc/cp/parser.c:8322
0xebfeca cp_parser_cast_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9090
0xf290c9 cp_parser_unary_expression
/home/vegard/git/gcc/gcc/cp/parser.c:8240
0xebfeca cp_parser_cast_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9090
0xec24f6 cp_parser_binary_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9191
0xec62ca cp_parser_assignment_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9486
0xed4304 cp_parser_parenthesized_expression_list
/home/vegard/git/gcc/gcc/cp/parser.c:7764
0xed6ddb cp_parser_gnu_attribute_list
/home/vegard/git/gcc/gcc/cp/parser.c:25056
0xed6ddb cp_parser_gnu_attributes_opt
/home/vegard/git/gcc/gcc/cp/parser.c:24971
0xf886f7 cp_parser_decl_specifier_seq
/home/vegard/git/gcc/gcc/cp/parser.c:13431
0xf8 cp_parser_member_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:23522
0xf142ab cp_parser_member_specification_opt
/home/vegard/git/gcc/gcc/cp/parser.c:23374
0xf142ab cp_parser_class_specifier_1
/home/vegard/git/gcc/gcc/cp/parser.c:22516
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Version:

GNU C++14 (GCC) version 8.0.1 20180306 (experimental) (x86_64-pc-linux-gnu)

7.3.0 says:

: In function 'void a()':
:4:27: error: expected class-name before ')' token
 __attribute__((c(::~)))
   ^
:4:27: error: taking address of destructor 'a()::b::~b'
:5:3: error: expected unqualified-id before '}' token
   }
   ^
:5:4: error: expected ';' after struct definition
   }
^
;
Compiler returned: 1

[Bug target/84990] [8 Regression] Boostrap broken with --enable-checking=release and Ada

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Both powerpc64le-linux and aarch64-linux bootstrapped for me with this change
with --enable-checking=release and Ada enabled.
Sorry for the breakage.

[Bug debug/84875] [6/7 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2348 on s390x

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7/8 Regression] ICE in   |[6/7 Regression] ICE in
   |maybe_record_trace_start,   |maybe_record_trace_start,
   |at dwarf2cfi.c:2348 on  |at dwarf2cfi.c:2348 on
   |s390x   |s390x

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

[Bug debug/84875] [6/7/8 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2348 on s390x

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Mar 20 21:07:13 2018
New Revision: 258692

URL: https://gcc.gnu.org/viewcvs?rev=258692=gcc=rev
Log:
PR debug/84875
* dce.c (delete_unmarked_insns): Don't remove frame related noop moves
holding REG_CFA_RESTORE notes, instead turn them into a USE.

* gcc.dg/pr84875.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr84875.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dce.c
trunk/gcc/testsuite/ChangeLog

[Bug ada/85007] New: -b flag to gnatlink not recognized

[emr-gnu at hev dot psu.edu]

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

Bug ID: 85007
   Summary: -b flag to gnatlink not recognized
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: emr-gnu at hev dot psu.edu
  Target Milestone: ---

Attempting to compile a 64-bit Ada package (using a GPR file) with a gcc
configured with:

LDFLAGS_FOR_TARGET='-Wl,-z,relro' ~/gcc-gcc-7.3.0/configure -v
--with-pkgversion='LOCAL 7.3.0' --enable-languages=c,c++,ada
--prefix=/usr/local/gcc-7.3 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/local/gcc-7.3/lib
--without-included-gettext --enable-threads=posix
--libdir=/usr/local/gcc-7.3/lib --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-default-pie --enable-plugin
--enable-objc-gc=auto --with-arch-32=prescott --with-tune=nehalem
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--disable-nls --without-cuda-driver

When you get to the linker stage, the arguments used are:

gnatlink-7.3 -b x86_64-linux-gnu -v -g --for-linker=-Map
--for-linker=../test.map lib1.a lib2.a --GCC=gcc-7.3 -o ../test driver.ali

It is expected to produce a 64-bit output file, but instead you get the error:

GNATLINK 7.3.0
Copyright (C) 1995-2017, Free Software Foundation, Inc.
gcc-7 -c -gnatA -gnatWb -gnatiw -b x86_64-linux-gnu -g -gnatws b~driver.adb
gcc-7.3: error: x86_64-linux-gnu: No such file or directory
gcc-7.3: error: unrecognized command line option '-b'

I understand by default with this configuration (e.g., without the "-b" flag),
it will produce a 64-bit b~driver.o file, however in this case with the output
format explicitly defined, the gnatlink program should be properly converting
the system configuration string to the equivalent "-m64" flag which gcc-7.3
should be accepting.

The more severe error is when the same compiler attempts to generate 32-bit
objects for the same package, using any valid 32-bit linux linker configuration
string and the '-b' gnatlink argument; all produce an error when attempting to
compile the b~driver.o object, since gcc doesn't recognize this option as
valid.  On MULTIARCH targets, gnatlink.adb should probably parse any '-b'
argument string, and translate it to an appropriate '-m32' or '-m64' argument
for the binder compilation stage.

[Bug c++/59930] template friend declarations, namespaces, and explicit instantiations don't mix

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Target Milestone|--- |8.0

[Bug c++/64816] gcc claims that constructor is private when it should be accessible

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug c++/81347] g++ confused by namespaces and friend classes

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug c++/78724] Incorrect ambiguous reference error when template class was forward declarated as a friend

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug c++/81347] g++ confused by namespaces and friend classes

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Fixed by r255780 so closing as a dup, as Richard suggested.

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

[Bug c++/59930] template friend declarations, namespaces, and explicit instantiations don't mix

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||thomasanderson at google dot 
com

--- Comment #8 from Jonathan Wakely  ---
*** Bug 81347 has been marked as a duplicate of this bug. ***

[Bug c++/59930] template friend declarations, namespaces, and explicit instantiations don't mix

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||loic.yhuel at gmail dot com

--- Comment #7 from Jonathan Wakely  ---
*** Bug 78724 has been marked as a duplicate of this bug. ***

[Bug c++/78724] Incorrect ambiguous reference error when template class was forward declarated as a friend

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Fixed by r255780 so closing as a dup, as Richard suggested.

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

[Bug c++/59930] template friend declarations, namespaces, and explicit instantiations don't mix

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||thakis at chromium dot org

--- Comment #6 from Jonathan Wakely  ---
*** Bug 64816 has been marked as a duplicate of this bug. ***

[Bug c++/64816] gcc claims that constructor is private when it should be accessible

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
Fixed by r255780 so closing as a dup, as Richard suggested.

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

[Bug c++/85006] New: [7/8 Regression] [concepts] ICE with bogus parameter pack

[reichelt at gcc dot gnu.org]

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

Bug ID: 85006
   Summary: [7/8 Regression] [concepts] ICE with bogus parameter
pack
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following invalid code snippet (compiled with "-fconcepts"
triggers an ICE since GCC 7.1.0:


template struct A {};

template A foo() { return {}; }

void bar()
{
  foo();
}


bug.cc: In substitution of 'template A foo() [with
 = {}]':
bug.cc:7:7:   required from here
bug.cc:3:34: internal compiler error: in tsubst_pack_expansion, at
cp/pt.c:11826
 template A foo() { return {}; }
  ^~~
0x6482a9 tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:11826
0x97fb7a tsubst_template_args
../../gcc/gcc/cp/pt.c:12062
0x97fa88 tsubst_template_args
../../gcc/gcc/cp/pt.c:12080
0x97c425 tsubst_aggr_type
../../gcc/gcc/cp/pt.c:12293
0x9769ee tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:13925
0x9796a4 tsubst_function_type
../../gcc/gcc/cp/pt.c:13637
0x976253 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:14391
0x95f6dd tsubst_function_decl
../../gcc/gcc/cp/pt.c:12556
0x97c626 tsubst_decl
../../gcc/gcc/cp/pt.c:12955
0x976aef tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:13843
0x985662 instantiate_template_1
../../gcc/gcc/cp/pt.c:18824
0x985662 instantiate_template(tree_node*, tree_node*, int)
../../gcc/gcc/cp/pt.c:18880
0x98c5c7 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool)
../../gcc/gcc/cp/pt.c:19260
0x82b09f add_template_candidate_real
../../gcc/gcc/cp/call.c:3179
0x82bab0 add_template_candidate
../../gcc/gcc/cp/call.c:3258
0x82bab0 add_candidates
../../gcc/gcc/cp/call.c:5523
0x82bed1 add_candidates
../../gcc/gcc/cp/call.c:4195
0x82bed1 perform_overload_resolution
../../gcc/gcc/cp/call.c:4203
0x82df52 build_new_function_call(tree_node*, vec**, int)
../../gcc/gcc/cp/call.c:4276
0x9abb15 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/gcc/cp/semantics.c:2500
Please submit a full bug report, [etc.]

[Bug c++/84972] [6/7/8 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in extended_tree, at tree.h:5545

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot com

--- Comment #6 from Paolo Carlini  ---
This bit of my in progress patch handles this case:

Index: decl.c
===
--- decl.c  (revision 258674)
+++ decl.c  (working copy)
@@ -5467,7 +5467,9 @@ maybe_deduce_size_from_array_init (tree decl, tree
  failure = 1;
}

-  if (!failure)
+  if (failure)
+   TREE_TYPE (decl) = error_mark_node;
+  else
{
  failure = cp_complete_array_type (_TYPE (decl), initializer,
do_default);

[Bug c++/84972] [6/7/8 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in extended_tree, at tree.h:5545

[paolo.carlini at oracle dot com]

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

--- Comment #5 from Paolo Carlini  ---
Indeed, we want one error, not three ;)

[Bug c++/72825] ICE on invalid C++ code on x86_64-linux-gnu (internal compiler error: tree check: expected array_type, have error_mark in array_ref_low_bound, at tree.c:13013)

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #2 from Paolo Carlini  ---
Mine.

[Bug c++/84972] [6/7/8 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in extended_tree, at tree.h:5545

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

[Bug c++/84972] [6/7/8 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in extended_tree, at tree.h:5545

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org

--- Comment #4 from Paolo Carlini  ---
Ok, but please next time remember to assign the bug to yourself, because, not
seeing much happening, I started working on it and spent quite a bit of time
already trying to figure out a much more encompassing fix covering a couple of
additional bugs (c++/84632, c++/72825). Thus, please send what you have and if
its accepted for 8 I'll keep on working on all three for post-8.

[Bug c++/84647] [6/7 Regression] ICE: segfault with NULL "from" in standard_conversion()

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 Depends on||84798
   Assignee|aoliva at gcc dot gnu.org  |jason at gcc dot gnu.org
Summary|[6/7/8 Regression] ICE: |[6/7 Regression] ICE:
   |segfault with NULL "from"   |segfault with NULL "from"
   |in standard_conversion()|in standard_conversion()

--- Comment #4 from Alexandre Oliva  ---
Fixed with patch for bug 84798.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84798
[Bug 84798] [6/7 Regression] ICE (Segmentation fault) if `auto` appears in a
template argument

[Bug fortran/84615] [8 Regression] Executable Segfault for some tests compiled with -m32 after r256284

[dominiq at lps dot ens.fr]

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

--- Comment #17 from Dominique d'Humieres  ---
> Dominique, can you check whether it also fixes the other -fdefault-real-8 -m32
> issues caused by r256284?

Preliminary tests show that all the failures reported in comment 0 are fixed by
the patch except:

% gfc -m32 -fdefault-integer-8
/opt/gcc/p_work/gcc/testsuite/gfortran.dg/assumed_rank_1.f90
/opt/gcc/p_work/gcc/testsuite/gfortran.dg/assumed_rank_1_c.c
cc1: warning: command line option '-fdefault-integer-8' is valid for Fortran
but not for C
% ./a.out   
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Full test scheduled for tonight. Thanks for the patch.

[Bug c/84999] [7/8 Regression] ICE in make_vector_type, at tree.c:9561

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
  Known to work||6.4.0
   Keywords||ice-on-valid-code
   Last reconfirmed||2018-03-20
 CC||jakub at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |7.4
  Known to fail||7.3.0, 8.0.1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r246965.

[Bug c++/84972] [6/7/8 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in extended_tree, at tree.h:5545

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
Sorry, I already have a patch:

2018-03-20  Marek Polacek  

PR c++/84972
* c-common.c (complete_array_type): Bail for bogus MAXINDEX.

* g++.dg/parse/crash68.C: New test.

diff --git gcc/c-family/c-common.c gcc/c-family/c-common.c
index e1df1d3b73b..108d5f8f2d8 100644
--- gcc/c-family/c-common.c
+++ gcc/c-family/c-common.c
@@ -6332,6 +6332,11 @@ complete_array_type (tree *ptype, tree initial_value,
bool do_default)
  if ((*v)[0].index)
maxindex = (*v)[0].index, fold_p = true;

+ /* If we can't do anything useful with the index,
+signal failure.  */
+ if (maxindex == error_mark_node)
+   return 1;
+
  curindex = maxindex;

  for (cnt = 1; vec_safe_iterate (v, cnt, ); cnt++)
diff --git gcc/testsuite/g++.dg/parse/crash68.C
gcc/testsuite/g++.dg/parse/crash68.C
index e69de29bb2d..b8c47ba155c 100644
--- gcc/testsuite/g++.dg/parse/crash68.C
+++ gcc/testsuite/g++.dg/parse/crash68.C
@@ -0,0 +1,4 @@
+// PR c++/84972
+// { dg-additional-options "-w" }
+
+char a[] ({.a = 0}); // { dg-error "" }

[Bug c++/84972] [6/7/8 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in extended_tree, at tree.h:5545

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|paolo.carlini at oracle dot com|
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #2 from Paolo Carlini  ---
On it.

[Bug c++/85004] ambiguous diagnostic: passing ‘const S’ as ‘this’ argument discards qualifiers

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
   Target Milestone|--- |9.0

[Bug c++/85004] ambiguous diagnostic: passing ‘const S’ as ‘this’ argument discards qualifiers

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-20
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=53281
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
As I said in PR 53281 comment 5, I think we should stop talking about "passing
'const S' as 'this' argument, because it's a leaky abstraction, and inaccurate
(this should be a pointer S* not S).

With the patch there it says:

u.C: In member function 'void S::g() const':
u.C:6:18: error: cannot call non-const member function on object of type 'const
S' [-fpermissive]
 this->f (this);   // which 'this?'
  ^
u.C:2:8: note:   in call to 'void S::f(const S*)'
   void f (const S*);
^
u.C:8:12: error: cannot call non-const member function on object of type 'const
S' [-fpermissive]
 f (this); // ditto
^
u.C:2:8: note:   in call to 'void S::f(const S*)'
   void f (const S*);
^

[Bug target/84826] ICE in extract_insn, at recog.c:2304 on arm-linux-gnueabi

[sudi at gcc dot gnu.org]

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

--- Comment #8 from sudi at gcc dot gnu.org ---
(In reply to Wilco from comment #5)
> It seems a latent bug in arm_r3_live_at_start_p which now triggers much more
> often due to stack clash protection:
> 
>   if (IS_NESTED (arm_current_func_type ())
>   && ((TARGET_APCS_FRAME && frame_pointer_needed && TARGET_ARM)
>   || ((flag_stack_check == STATIC_BUILTIN_STACK_CHECK
>|| flag_stack_clash_protection)
>   && !df_regs_ever_live_p (LR_REGNUM)))
>   && arm_r3_live_at_start_p ()
>   && crtl->args.pretend_args_size == 0)
> 
> Given that liveness can't guarantee dead registers won't look live at start,
> the r3_live_at_start should really be about function parameters which is a
> fixed concept. Is there no query that can accurately tell you which
> registers are used for parameters in the current function?
> 
> For GCC9 we need to redesign this whole area - most of the above checks are
> quite inaccurate (for example a temporary is only used for stack checking if
> the stack size is > 16KB), copy and pasted multiple times in slightly
> different ways, and not cached when computing the frame layout like on
> AArch64.
> 
> However a quick workaround for GCC8 would be to assume
> arm_r3_live_at_start_p is always true in the above code. Also we should
> never change the generated code in functions which do not require stack
> checking, so changing the stack checking enabled test to framesize > 16KB
> would be the right thing to do.

I have created a new report PR 85005 for this cleanup. For now I am only making
changes enough to get rid of the ICE.

[Bug target/85005] Redesign and cleanup arm.c wrt to flag_stack_clash_protection and flag_stack_check

[sudi at gcc dot gnu.org]

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

sudi at gcc dot gnu.org changed:

   What|Removed |Added

 Target||arm*-*-*
 CC||wilco at gcc dot gnu.org
   Target Milestone|--- |9.0

[Bug target/85005] New: Redesign and cleanup arm.c wrt to flag_stack_clash_protection and flag_stack_check

[sudi at gcc dot gnu.org]

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

Bug ID: 85005
   Summary: Redesign and cleanup arm.c wrt to
flag_stack_clash_protection and flag_stack_check
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sudi at gcc dot gnu.org
  Target Milestone: ---

I am creating this for GCC9 as a follow-up on PR 84826 comment 5 by Wilco.
There are several places where the following code is checked.

  if (IS_NESTED (arm_current_func_type ())
  && ((TARGET_APCS_FRAME && frame_pointer_needed && TARGET_ARM)
  || ((flag_stack_check == STATIC_BUILTIN_STACK_CHECK
   || flag_stack_clash_protection)
  && !df_regs_ever_live_p (LR_REGNUM)))
  && arm_r3_live_at_start_p ()
  && crtl->args.pretend_args_size == 0)

Most of these times there is also slight variations on there checks. The flags
being checked (flag_stack_check == STATIC_BUILTIN_STACK_CHECK ||
flag_stack_clash_protection) are also probably not used correctly. This should
be tightened to only have any effect of the frame size is more than 16KB. In
all other cases these flags do not matter. This piece of code is also not
tested given  the number of very specific checks involved and also the fact
that check_effective_target_supports_stack_clash_protection does not list any
Arm backends.

[Bug libstdc++/84998] [8 Regression] std::hash<std::bitset> fails in Debug Mode

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
The change happened with r255780 i.e. PR c++/59930

I'll make the necessary fixes to libstdc++.

[Bug c++/84978] [8 Regression] ICE in cxx_eval_constant_expression at gcc/cp/constexpr.c:4109

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #8 from Marek Polacek  ---
Fixed.

[Bug c++/84978] [8 Regression] ICE in cxx_eval_constant_expression at gcc/cp/constexpr.c:4109

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
Test added in r258691 but I used the wrong commit message :(.

[Bug c++/84927] [7 Regression] ICE with NSDMI and reference

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Author: mpolacek
Date: Tue Mar 20 18:13:38 2018
New Revision: 258691

URL: https://gcc.gnu.org/viewcvs?rev=258691=gcc=rev
Log:
PR c++/84927
* constexpr.c (cxx_eval_bare_aggregate): Update constructor's flags
as we evaluate the elements.
(cxx_eval_constant_expression): Verify constructor's flags
unconditionally.

* g++.dg/cpp1y/nsdmi-aggr9.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/opt/nrv19.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/84978] [8 Regression] ICE in cxx_eval_constant_expression at gcc/cp/constexpr.c:4109

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Tue Mar 20 18:05:59 2018
New Revision: 258689

URL: https://gcc.gnu.org/viewcvs?rev=258689=gcc=rev
Log:
PR c++/84978, ICE with NRVO.

* cvt.c (cp_get_fndecl_from_callee): Add fold parameter.
(cp_get_callee_fndecl_nofold): New.
* cp-gimplify.c (cp_genericize_r): Use it instead.
* call.c (check_self_delegation): Likewise.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/cvt.c

[Bug c++/85004] New: ambiguous diagnostic: passing ‘const S’ as ‘this’ argument discards qualifiers

[msebor at gcc dot gnu.org]

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

Bug ID: 85004
   Summary: ambiguous diagnostic: passing ‘const S’ as ‘this’
argument discards qualifiers
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

When invoking a non-const member function from a const one, GCC issues an error
message like those below.  The error message is ambiguous: it doesn't make is
clear which this it refers to.  In the first case, underling the first "this"
would help.  In the second case rephrasing the error to say something like
"passing ‘const S’ as the implicit ‘this’ argument discards qualifiers" would
help avoid the confusion.

$ cat u.C && gcc -S -Wall u.C
struct S {
  void f (const S*);

  void g () const
  {
this->f (this);   // which 'this?'

f (this); // ditto
  }
};
u.C: In member function ‘void S::g() const’:
u.C:6:18: error: passing ‘const S’ as ‘this’ argument discards qualifiers
[-fpermissive]
 this->f (this);   // which 'this?'
  ^
u.C:2:8: note:   in call to ‘void S::f(const S*)’
   void f (const S*);
^
u.C:8:12: error: passing ‘const S’ as ‘this’ argument discards qualifiers
[-fpermissive]
 f (this); // ditto
^
u.C:2:8: note:   in call to ‘void S::f(const S*)’
   void f (const S*);
^

[Bug libstdc++/84998] [8 Regression] std::hash<std::bitset> fails in Debug Mode

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Also:

#define _GLIBCXX_DEBUG
#include 
int main()
{
  std::vector b;
  std::hash h;
  return h(b);
}

And a number of other debug mode failures related to access. I suspect FE
improvements to lookup have made some of our friend declarations stop working
as intended.

[Bug tree-optimization/85003] New: Inline built-in fdim for -fno-math-errno

[jsm28 at gcc dot gnu.org]

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

Bug ID: 85003
   Summary: Inline built-in fdim for -fno-math-errno
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
  Target Milestone: ---

GCC should support inline code generation for the fdim / fdimf / fdiml
functions, given -fno-math-errno.

glibc's bits/mathinline.h headers for powerpc and sparc (only) have inlines of
the form:

__MATH_INLINE double
__NTH (fdim (double __x, double __y))
{
  return __x <= __y ? 0 : __x - __y;
}

We're moving away from such inlines in glibc, preferring to leave it to the
compiler to inline standard functions under appropriate conditions.  Now, the
above (which lacks a -fno-math-errno conditional) isn't actually correct; you
need to use an unordered comparison, so the appropriate expansion (given
-fno-math-errno) is of the form (considered as an inline not a macro, so
avoiding multiple evaluations of arguments):

__builtin_islessequal (x, y) ? 0 : x - y

Note: as well as -fno-math-errno, for correctness this also requires that, if
standard-conforming excess precision has been requested, the back end does not
add any implicit excess precision for the type in question, as specified by the
targetm.c.excess_precision hook (so it's not correct to do this inline
expansion for 32-bit x86 with x87 floating point for float or double if
-fexcess-precision=standard, in particular).

[Bug fortran/85002] New: [7/8 Regression] ICE in fold_ternary_loc, at fold-const.c:11360

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

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

Bug ID: 85002
   Summary: [7/8 Regression] ICE in fold_ternary_loc, at
fold-const.c:11360
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20161127 and 20161204.
Needs option -fcoarray=single or -fcoarray=lib.


$ cat z1.f90
program p
   type t
  integer, allocatable :: a(:)
   end type
   type t2
  type(t), allocatable :: b(:)
   end type
   type(t) :: x
   type(t2) :: y(2)[*]
   allocate (x%a(2))
   x%a = 123
   y = t2([x])
end


$ gfortran-7-20161127 -c z1.f90 -fcoarray=single
$ gfortran-7-20161127 -c z1.f90 -fcoarray=lib
$
$ gfortran-8-20180318 -c z1.f90 -fcoarray=single
z1.f90:12:0:

y = t2([x])

internal compiler error: Segmentation fault
0xb9bd5f crash_signal
../../gcc/toplev.c:325
0x91b998 fold_ternary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*, tree_node*)
../../gcc/fold-const.c:11360
0x91d323 fold_build3_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*, tree_node*)
../../gcc/fold-const.c:12388
0x75d91a structure_alloc_comps
../../gcc/fortran/trans-array.c:8848
0x75d510 structure_alloc_comps
../../gcc/fortran/trans-array.c:8403
0x75d9b5 structure_alloc_comps
../../gcc/fortran/trans-array.c:8955
0x777a91 gfc_trans_scalar_assign(gfc_se*, gfc_se*, gfc_typespec, bool, bool,
bool)
../../gcc/fortran/trans-expr.c:8936
0x7861f9 gfc_trans_assignment_1
../../gcc/fortran/trans-expr.c:10260
0x74a3b7 trans_code
../../gcc/fortran/trans.c:1828
0x7716b9 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6507
0x7009c0 translate_all_program_units
../../gcc/fortran/parse.c:6121
0x7009c0 gfc_parse_file()
../../gcc/fortran/parse.c:6324
0x74755f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/85001] [6/7/8 Regression] ICE in gfc_build_array_type, at fortran/trans-types.c:1420

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

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

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

These two variants compile without any errors :


$ cat z2.f90
program p
   type t
   end type
   call s
contains
   real function f(x)
  class(t) :: x(:)
  f = 1.0
   end
   subroutine s
  type(t) :: x(2)
  real :: z
  z = f(x)
   end
end


$ cat z3.f90
program p
   type t
   end type
   call s
contains
   real function f(x)
  type(t) :: x
  dimension :: x(:)
  f = 1.0
   end
   subroutine s
  type(t) :: x(2)
  real :: z
  z = f(x)
   end
end


$ gfortran-8-20180318 -c z2.f90
$ gfortran-8-20180318 -c z3.f90
$

[Bug fortran/85001] New: [6/7/8 Regression] ICE in gfc_build_array_type, at fortran/trans-types.c:1420

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

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

Bug ID: 85001
   Summary: [6/7/8 Regression] ICE in gfc_build_array_type, at
fortran/trans-types.c:1420
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

gfortran-8 changed between 20171105 and 20171112.
gfortran-7 changed between 20180111 and 20180125.
gfortran-6 changed between 20180110 and 20180207.


$ cat z1.f90
program p
   type t
   end type
   call s
contains
   real function f(x)
  class(t) :: x
  dimension :: x(:)
  f = 1.0
   end
   subroutine s
  type(t) :: x(2)
  real :: z
  z = f(x)
   end
end


The error message was formerly a bit misleading :

$ gfortran-8-20171105 -c z1.f90
z1.f90:14:12:

   z = f(x)
1
Error: Rank mismatch in argument 'x' at (1) (scalar and rank-1)


$ gfortran-8-20180318 -c z1.f90
z1.f90:6:0:

real function f(x)

internal compiler error: Segmentation fault
0xb9bd5f crash_signal
../../gcc/toplev.c:325
0x7c0de7 gfc_build_array_type
../../gcc/fortran/trans-types.c:1420
0x7c264f gfc_get_derived_type(gfc_symbol*, int)
../../gcc/fortran/trans-types.c:2768
0x7c2f28 gfc_typenode_for_spec(gfc_typespec*, int)
../../gcc/fortran/trans-types.c:1203
0x7c31b4 gfc_sym_type(gfc_symbol*)
../../gcc/fortran/trans-types.c:2267
0x7c19a4 gfc_get_function_type(gfc_symbol*)
../../gcc/fortran/trans-types.c:3067
0x766a9f build_function_decl
../../gcc/fortran/trans-decl.c:2233
0x768506 gfc_create_function_decl(gfc_namespace*, bool)
../../gcc/fortran/trans-decl.c:2909
0x771529 gfc_generate_contained_functions
../../gcc/fortran/trans-decl.c:5510
0x771529 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6436
0x7009c0 translate_all_program_units
../../gcc/fortran/parse.c:6121
0x7009c0 gfc_parse_file()
../../gcc/fortran/parse.c:6324
0x74755f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug c/85000] ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:895

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

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

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

Configured with --enable-checking=yes :


$ gcc-8-20180318 -c z1.c -O2 -fopenmp
during GIMPLE pass: omplower
z1.c: In function 'foo':
z1.c:8:6: internal compiler error: in scan_omp_1_op, at omp-low.c:3014
 n++;
 ~^~
0xb3f192 scan_omp_1_op
../../gcc/omp-low.c:3014
0xf66e22 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../../gcc/tree.c:11387
0xf67276 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../../gcc/tree.c:11703
0x9c00f0 walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:203
0x9c072c walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:586
0x9c0918 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0x9c07d2 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:596
0x9c0918 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0x9c07d2 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:596
0x9c0918 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0xb3e169 scan_omp
../../gcc/omp-low.c:3205
0xb4a50a scan_omp_parallel
../../gcc/omp-low.c:1796
0xb4a50a scan_omp_1_stmt
../../gcc/omp-low.c:3123
0x9c06fa walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:568
0x9c0918 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0x9c07d2 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:596
0x9c0918 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0xb3e169 scan_omp
../../gcc/omp-low.c:3205
0xb5460a execute_lower_omp
../../gcc/omp-low.c:8999
0xb5460a execute
../../gcc/omp-low.c:9056

[Bug c/85000] New: ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:895

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

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

Bug ID: 85000
   Summary: ICE in copy_reference_ops_from_ref, at
tree-ssa-sccvn.c:895
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least 4.8 :


$ cat z1.c
void
foo (void)
{
  #pragma omp parallel
  {
int n;
int bar (void) { return n; }
n++;
  }
}


$ gcc-8-20180318 -c z1.c -O2
$ gcc-8-20180318 -c z1.c -O2 -fopenmp
during GIMPLE pass: fre
z1.c: In function 'foo._omp_fn.0':
z1.c:10:1: internal compiler error: in copy_reference_ops_from_ref, at
tree-ssa-sccvn.c:895
 }
 ^
0xc5b7a3 copy_reference_ops_from_ref
../../gcc/tree-ssa-sccvn.c:895
0xc5c665 valueize_shared_reference_ops_from_ref
../../gcc/tree-ssa-sccvn.c:1536
0xc5eb1a vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind,
vn_reference_s**, bool)
../../gcc/tree-ssa-sccvn.c:2492
0xc637ed visit_reference_op_load
../../gcc/tree-ssa-sccvn.c:3754
0xc637ed visit_use
../../gcc/tree-ssa-sccvn.c:4101
0xc65886 process_scc
../../gcc/tree-ssa-sccvn.c:4332
0xc65886 extract_and_process_scc_for_name
../../gcc/tree-ssa-sccvn.c:4434
0xc65886 DFS
../../gcc/tree-ssa-sccvn.c:4484
0xc65d8f sccvn_dom_walker::before_dom_children(basic_block_def*)
../../gcc/tree-ssa-sccvn.c:4926
0x112cd0f dom_walker::walk(basic_block_def*)
../../gcc/domwalk.c:353
0xc66849 run_scc_vn(vn_lookup_kind)
../../gcc/tree-ssa-sccvn.c:5033
0xc66f6a execute
../../gcc/tree-ssa-sccvn.c:6015

[Bug middle-end/84997] Optimize integer operations on floating point constants without -ffast-math

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
On Tue, 20 Mar 2018, antoshkka at gmail dot com wrote:

> For example
> 
> int test2(int lhs) {
> lhs += 2.0;
> return lhs;
> }

That would need -fno-trapping-math, because if the addition results in a 
double value larger than INT_MAX, under Annex F the conversion back to int 
is defined to raise FE_INVALID along with producing an unspecified value.

> int test2(int lhs) {
> lhs += 2.001;
> return lhs;
> }

That's not correct to optimize unless you generate separate code for lhs 
>= -2 and lhs < -2; conversion from double to int truncates, so test2 (-3) 
== 0.

[Bug c/84999] New: [7/8 Regression] ICE in make_vector_type, at tree.c:9561

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

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

Bug ID: 84999
   Summary: [7/8 Regression] ICE in make_vector_type, at
tree.c:9561
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed before 20171019, ICEs with option -m32 :


$ cat z1.c
void
foo (void)
{
  __attribute__ ((__vector_size__ (4 * sizeof (unsigned __float128 a;
  0 != a;
}


$ gcc-7-20170226 -c z1.c -m64
$ gcc-7-20170226 -c z1.c -m32
$
$ gcc-8-20180318 -c z1.c -m64
$ gcc-8-20180318 -c z1.c -m32
z1.c: In function 'foo':
z1.c:5:3: internal compiler error: Segmentation fault
   0 != a;
   ^
0xaec94f crash_signal
../../gcc/toplev.c:325
0xd3619e make_vector_type
../../gcc/tree.c:9561
0xd367bc build_opaque_vector_type(tree_node*, poly_int<1u, long>)
../../gcc/tree.c:10536
0x68bef3 build_binary_op(unsigned int, tree_code, tree_node*, tree_node*, bool)
../../gcc/c/c-typeck.c:11668
0x68d9d4 parser_build_binary_op(unsigned int, tree_code, c_expr, c_expr)
../../gcc/c/c-typeck.c:3635
0x6a2b3a c_parser_binary_expression
../../gcc/c/c-parser.c:7037
0x6a31f5 c_parser_conditional_expression
../../gcc/c/c-parser.c:6645
0x6a3780 c_parser_expr_no_commas
../../gcc/c/c-parser.c:6562
0x6a3a02 c_parser_expression
../../gcc/c/c-parser.c:9292
0x6a4f09 c_parser_expression_conv
../../gcc/c/c-parser.c:9325
0x6b4941 c_parser_statement_after_labels
../../gcc/c/c-parser.c:5540
0x6b0bda c_parser_compound_statement_nostart
../../gcc/c/c-parser.c:5078
0x6b12e6 c_parser_compound_statement
../../gcc/c/c-parser.c:4912
0x6b29e0 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2341
0x6b8623 c_parser_external_declaration
../../gcc/c/c-parser.c:1644
0x6b9099 c_parser_translation_unit
../../gcc/c/c-parser.c:1524
0x6b9099 c_parse_file()
../../gcc/c/c-parser.c:18411
0x6fbd55 c_common_parse_file()
../../gcc/c-family/c-opts.c:1132

[Bug target/83789] __builtin_altivec_lvx fails for powerpc for altivec-4.c

[bergner at gcc dot gnu.org]

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

--- Comment #20 from Peter Bergner  ---
Kaushik, remind me, you're seeing the same ICE in GCC 7 as well, so we need a
backport of the patch committed to trunk?

[Bug libstdc++/84998] [8 Regression] std::hash<std::bitset> fails in Debug Mode

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-03-20
  Known to work||7.3.0
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1
  Known to fail||8.0.1

[Bug libstdc++/84998] New: [8 Regression] std::hash<std::bitset> fails in Debug Mode

[redi at gcc dot gnu.org]

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

Bug ID: 84998
   Summary: [8 Regression] std::hash fails in
Debug Mode
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#define _GLIBCXX_DEBUG
#include 
int main()
{
  std::bitset<1> b;
  std::hash> h;
  return h(b);
}

In file included from bs.cc:2:
/home/jwakely/gcc/8/include/c++/8.0.1/bitset: In instantiation of 'std::size_t
std::hash >::operator()(const
std::__cxx1998::bitset<_Nb>&) const [with long unsigned int _Nb = 1;
std::size_t = long unsigned int]':
/home/jwakely/gcc/8/include/c++/8.0.1/debug/bitset:421:56:   required from
'std::size_t std::hash >::operator()(const
std::__debug::bitset<_Nb>&) const [with long unsigned int _Nb = 1; std::size_t
= long unsigned int]'
bs.cc:7:13:   required from here
/home/jwakely/gcc/8/include/c++/8.0.1/bitset:1568:30: error: 'const _WordT*
std::__cxx1998::_Base_bitset<1>::_M_getdata() const' is inaccessible within
this context
  return std::_Hash_impl::hash(__b._M_getdata(), __clength);
 ~^
/home/jwakely/gcc/8/include/c++/8.0.1/bitset:415:7: note: declared here
   _M_getdata() const noexcept
   ^~
/home/jwakely/gcc/8/include/c++/8.0.1/bitset:1568:30: error:
'std::__cxx1998::_Base_bitset<1>' is not an accessible base of 'const
std::__cxx1998::bitset<1>'
  return std::_Hash_impl::hash(__b._M_getdata(), __clength);
 ~^

[Bug target/83789] __builtin_altivec_lvx fails for powerpc for altivec-4.c

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #19 from Peter Bergner  ---
Fixed on trunk.

[Bug middle-end/84996] Adding or substracting 0.0 could be optimized away even without -ffast-math

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
Adding +0.0 and -0.0 produces +0.0 except in FE_DOWNWARD mode.  I.e., 
optimizing away an addition of +0.0 requires -fno-signed-zeros (not the 
default), as well as -fno-signaling-nans (which is the default).  And if 
you pass -fno-signed-zeros, this code (the first test in this bug) is 
*already* optimized.

It's true that if you add +0.0 to a value that cannot be -0.0 or a 
signaling NaN - such as a value resulting from a conversion from integer 
type - then it's a no-op regardless of compilation options.  So the second 
test could be better optimized.

[Bug target/83789] __builtin_altivec_lvx fails for powerpc for altivec-4.c

[bergner at gcc dot gnu.org]

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

--- Comment #18 from Peter Bergner  ---
Author: bergner
Date: Tue Mar 20 17:25:09 2018
New Revision: 258688

URL: https://gcc.gnu.org/viewcvs?rev=258688=gcc=rev
Log:
PR target/83789
* config/rs6000/altivec.md (altivec_lvx__2op): Delete
define_insn.
(altivec_lvx__1op): Likewise.
(altivec_stvx__2op): Likewise.
(altivec_stvx__1op): Likewise.
(altivec_lvx_): New define_expand.
(altivec_stvx_): Likewise.
(altivec_lvx__2op_): New define_insn.
(altivec_lvx__1op_): Likewise.
(altivec_stvx__2op_): Likewise.
(altivec_stvx__1op_): Likewise.
* config/rs6000/rs6000-p8swap.c (rs6000_gen_stvx): Use new expanders.
(rs6000_gen_lvx): Likewise.
* config/rs6000/rs6000.c (altivec_expand_lv_builtin): Likewise.
(altivec_expand_stv_builtin): Likewise.
(altivec_expand_builtin): Likewise.
* config/rs6000/vector.md: Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/altivec.md
trunk/gcc/config/rs6000/rs6000-p8swap.c
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/vector.md

[Bug middle-end/84997] New: Optimize integer operations on floating point constants without -ffast-math

[antoshkka at gmail dot com]

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

Bug ID: 84997
   Summary: Optimize integer operations on floating point
constants without -ffast-math
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

If it is known at compile time that changing the floating point constant to
integral constant results in exactly the same value, then replace the floating
point operation with integral operation.

For example

int test2(int lhs) {
lhs += 2.0;
return lhs;
}

clang optimizes to the following assembly

test2(int): # @test2(int)
  lea eax, [rdi + 2]
  ret

, while GCC produces a suboptimal assembly:

test(int):
pxorxmm0, xmm0
cvtsi2sdxmm0, edi
addsd   xmm0, QWORD PTR .LC0[rip]
cvttsd2si   eax, xmm0
ret
.LC0:
.long   0
.long   1073741824




More complex examples (where clang fails):

#include 

int test2(int lhs) {
lhs += 2.001;
return lhs;
}

int test3(int lhs) {
constexpr auto fp = 2.001;
constexpr int max = std::numeric_limits::max();
constexpr int min = std::numeric_limits::min();

// Checking that the result is same even with max * epsilon
static_assert(
static_cast(fp + max - fp) == max
&& static_cast(fp + min - fp) == min,
""
);

return fp + lhs - fp;
}

[Bug target/82518] [6/7 Regression] gfortran.fortran-torture/execute/in-pack.f90 fails on armeb

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||8.0
Summary|[6/7/8 regression]  |[6/7 Regression]
   |gfortran.fortran-torture/ex |gfortran.fortran-torture/ex
   |ecute/in-pack.f90 fails on  |ecute/in-pack.f90 fails on
   |armeb   |armeb

--- Comment #53 from ktkachov at gcc dot gnu.org ---
Fixed for GCC 8. Will backport fix to branches later if no problems

[Bug target/82518] [6/7/8 regression] gfortran.fortran-torture/execute/in-pack.f90 fails on armeb

[ktkachov at gcc dot gnu.org]

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

--- Comment #52 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Tue Mar 20 17:13:16 2018
New Revision: 258687

URL: https://gcc.gnu.org/viewcvs?rev=258687=gcc=rev
Log:
This PR shows that we get the load/store_lanes logic wrong for arm big-endian.
It is tricky to get right. Aarch64 does it by adding the appropriate
lane-swapping
operations during expansion.

I'd like to do the same on arm eventually, but we'd need to port and validate
the VTBL-generating
code and add it to all the right places and I'm not comfortable enough doing it
for GCC 8, but I am keen
in getting the wrong-code fixed.
As I say in the PR, vectorisation on armeb is already severely restricted (we
disable many patterns on BYTES_BIG_ENDIAN)
and the load/store_lanes patterns really were not working properly at all, so
disabling them is not
a radical approach.

The way to do that is to return false in ARRAY_MODE_SUPPORTED_P for
BYTES_BIG_ENDIAN.

Bootstrapped and tested on arm-none-linux-gnueabihf.
Also tested on armeb-none-eabi.


 PR target/82518
 * config/arm/arm.c (arm_array_mode_supported_p): Return false for
 BYTES_BIG_ENDIAN.

 * lib/target-supports.exp (check_effective_target_vect_load_lanes):
 Disable for armeb targets.
 * gcc.target/arm/pr82518.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/arm/pr82518.c
Modified:
trunk/gcc/config/arm/arm.c
trunk/gcc/testsuite/lib/target-supports.exp

[Bug target/84826] ICE in extract_insn, at recog.c:2304 on arm-linux-gnueabi

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou  ---
> Oops I think I missed the artificial defs. Then the liveness makes sense.
> Out of curiosity why are all the argument register defined? This function
> for instance does not need 4 argument register.

Historical quirk inherited from the original flow.c I presume.

[Bug tree-optimization/84960] [8 Regression] ICE in GIMPLE pass: isolate-paths

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
  Component|c++ |tree-optimization

--- Comment #2 from Jakub Jelinek  ---
C testcase:

/* PR tree-optimization/84960 */
/* { dg-do compile } */
/* { dg-options "-O2 -fwrapv" } */

void
foo (int a, float b, void *c)
{
lab:
  if ((b - (a %= 0) < 1) * -1)
;
  else
{
  long f = a;
  __builtin_unreachable ();
  __builtin_prefetch (&);
}
  goto *c;
}

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

[willschm at gcc dot gnu.org]

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

Will Schmidt  changed:

   What|Removed |Added

 CC||willschm at gcc dot gnu.org

--- Comment #7 from Will Schmidt  ---
The ICE is triggered on the gcc_unreachable() at the bottom of the
switch(gimple_code(stmt)) clause in gimple-low.c: lower_stmt().

We enter the switch with our gimple_code(stmt) == GIMPLE_WITH_CLEANUP_EXPR.

# cfun at this point is:
(gdb) pcfun
get_word (__vector __bool int v)
{
  unsigned int D.3236;

  {
const unsigned int _B2;

_B2 = 32;
D.3235 = v;
<<< Unknown GIMPLE statement: gimple_with_cleanup_expr >>>

retval.0 = BIT_FIELD_REF ;
  }
  D.3236 = retval.0;
  return D.3236;
}


Doing some code-browsing, I see some logic to handle GIMPLE_WITH_CLEANUP_EXPR
in remap_gimple_stmt() and in gimple_copy() , but not in lower_stmt().

However, at gimplify.c: gimplify_cleanup_point_expr() i see the comment:

/* Gimplify a CLEANUP_POINT_EXPR.  Currently this works by adding
   GIMPLE_WITH_CLEANUP_EXPRs to the prequeue as we encounter cleanups while
   gimplifying the body, and converting them to TRY_FINALLY_EXPRs when we
   return to this function.

Debug on the logic there...
  for (iter = gsi_start (body_sequence); !gsi_end_p (iter); )
{
  gimple *wce = gsi_stmt (iter);
  if (gimple_code (wce) == GIMPLE_WITH_CLEANUP_EXPR)

does not show any matches with GIMPLE_WITH_CLEANUP_EXPR. (one GIMPLE_ASSIGN, 3
GIMPLE_BIND).  so we're not catching and generating TRY_FINALLY_EXPRS on the
way out like we want or need to.

(I can scratch and dig around some more,.. but could use a hint or do a
hand-off to someone..  :-)   



Additional debug, possibly not relevant:
During (first?) gimple pass, we get to gimple_build_wce by way of multiple
calls through ..  hard to paraphrase, heres the bt. 

(gdb) bt
#0  0x1088da08 in gimple_build_wce (cleanup=0x109e00f0) at
gimple.c:742
#1  0x108e9984 in gimple_push_cleanup (var=0x10080a20,
cleanup=, eh_only=false, pre_p=0x3fffd7a0,
force_uncond=true) at gimplify.c:6528
#2  0x108f7cbc in gimplify_target_expr (expr_p=0x106b0d38,
pre_p=0x3fffd7a0, post_p=0x3fffd390) at gimplify.c:6611
#3  0x108e3410 in gimplify_expr (expr_p=0x106b0d38,
pre_p=0x3fffd7a0, post_p=0x3fffd390, gimple_test_f=0x1089b130
, 
fallback=) at gimplify.c:11815
#4  0x108e2f28 in gimplify_expr (expr_p=0x108c8e50,
pre_p=0x3fffd7a0, post_p=0x3fffd390, gimple_test_f=0x108d1660
, 
fallback=1) at gimplify.c:11739
#5  0x108f9cdc in gimplify_modify_expr (expr_p=0x106ff598,
pre_p=0x3fffd7a0, post_p=0x3fffd390, want_value=false) at
gimplify.c:5626
#6  0x108e3430 in gimplify_expr (expr_p=0x106ff598,
pre_p=0x3fffd7a0, post_p=0x3fffd390, gimple_test_f=0x108d6cc0
, fallback=0)
at gimplify.c:11435
#7  0x108e7288 in gimplify_stmt (stmt_p=,
seq_p=0x3fffd7a0) at gimplify.c:6658
#8  0x108e402c in gimplify_statement_list (pre_p=,
expr_p=0x106b0c80) at gimplify.c:1767
#9  gimplify_expr (expr_p=0x106b0c80, pre_p=0x3fffd7a0,
post_p=0x3fffd5c0, gimple_test_f=0x108d6cc0 ,
fallback=0) at gimplify.c:11863
#10 0x108e72dc in gimplify_stmt (stmt_p=0x106b0c80,
seq_p=0x3fffd7a0) at gimplify.c:6658
#11 0x108e8b8c in gimplify_bind_expr (expr_p=0x108c8e00,
pre_p=0x3fffe0d0) at gimplify.c:1335
#12 0x108e31ec in gimplify_expr (expr_p=0x108c8e00,
pre_p=0x3fffe0d0, post_p=0x3fffdc20, gimple_test_f=0x108d1660
, 
fallback=1) at gimplify.c:11635
#13 0x108f9cdc in gimplify_modify_expr (expr_p=0x3fffde70,
pre_p=0x3fffe0d0, post_p=0x3fffdc20, want_value=false) at
gimplify.c:5626
#14 0x108e3430 in gimplify_expr (expr_p=0x3fffde70,
pre_p=0x3fffe0d0, post_p=0x3fffdc20, gimple_test_f=0x108d6cc0
, fallback=0)
at gimplify.c:11435
#15 0x108e72dc in gimplify_stmt (stmt_p=0x3fffde70,
seq_p=0x3fffe0d0) at gimplify.c:6658
#16 0x108e3cc0 in gimplify_and_add (seq_p=0x3fffe0d0, t=) at gimplify.c:441
#17 gimplify_return_expr (pre_p=0x3fffe0d0, stmt=) at
gimplify.c:1571
#18 gimplify_expr (expr_p=0x109b4bd8, pre_p=0x3fffe0d0,
post_p=0x3fffde50, gimple_test_f=0x108d6cc0 ,
fallback=0) at gimplify.c:11695
#19 0x108e72dc in gimplify_stmt (stmt_p=,
seq_p=0x3fffe0d0) at gimplify.c:6658
#20 0x108e3050 in gimplify_cleanup_point_expr (pre_p=,
expr_p=0x106b0cb0) at gimplify.c:6400
#21 gimplify_expr (expr_p=0x106b0cb0, pre_p=0x3fffe260,
post_p=0x3fffe080, gimple_test_f=0x108d6cc0 

[Bug middle-end/84996] Adding or substracting 0.0 could be optimized away even without -ffast-math

[antoshkka at gmail dot com]

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

--- Comment #2 from Antony Polukhin  ---
Then let's change the example to 

int test(int lhs) {
return 0.0 + lhs;
}

In that case no signaling Nan is possible, but the code still does additions

test(int):
pxorxmm0, xmm0
cvtsi2sdxmm0, edi
addsd   xmm0, QWORD PTR .LC0[rip]
cvttsd2si   eax, xmm0
ret

[Bug middle-end/84996] Adding or substracting 0.0 could be optimized away even without -ffast-math

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Iirc it can't due to signaling nans.

[Bug middle-end/84996] New: Adding or substracting 0.0 could be optimized away even without -ffast-math

[antoshkka at gmail dot com]

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

Bug ID: 84996
   Summary: Adding or substracting 0.0 could be optimized away
even without -ffast-math
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

The code 

float test(float lhs) { return lhs + 0.0; }

generates suboptimal assembly

test(float):
addss   xmm0, DWORD PTR .LC0[rip]
ret
.LC0:
.long   0



Optimal assembly would be 

test(float): # @test(float)
  ret

[Bug rtl-optimization/84989] [8 Regression] _mm512_broadcast_f32x4 triggers ICE in simplify_const_unary_operation, at simplify-rtx.c:1731

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.  VEC_DUPLICATE is very unlike other unary ops.

[Bug lto/84934] Installing the lto plugin where binutils will look for it

[dilyan.palauzov at aegee dot org]

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

--- Comment #4 from Дилян Палаузов  ---
Oh, I have typed on this matter already in the past:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70345

[Bug lto/84995] New: Documentation gcc-ar and gcc-ranlib vs {libdir}/bfd-plugins

[dilyan.palauzov at aegee dot org]

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

Bug ID: 84995
   Summary: Documentation gcc-ar and gcc-ranlib vs
{libdir}/bfd-plugins
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dilyan.palauzov at aegee dot org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

While ar, ranlib and nm work with LTO, if the plugin is installed in
{libdir}/bfd-plugin, the gcc manual (Optimizing options) recommends the use of
gcc-ar and gcc-ranlib.

Why doesn't the manual recommend installing instead the plugin under
/bfd-plugin?  

Providing that both gcc and clang offer LTO and provide linker plugins, none of
them installs by default the plugins under {libdir}/bfd-plugins, gcc recommends
the usage of gcc-ar/gcc-ranlib, clang installs instead clang-ar/clang-ranlib,
how are ./configure scripts supposed to be written in portable way to enable
LTO compilation?

If several gcc versions are installed on a system and hence
/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/liblto_plugin.so.0.0.0 and
/usr/local/libexec/gcc/x86_64-pc-linux-gnu/6.4.1/liblto_plugin.so.0.0.0
co-exist, will gcc-ar always use
/gcc/x86_64-pc-linux-gnu/6.4.1/liblto_plugin.so.0.0.0, if the code is compiled
with x86_64-pc-linux-gnu-gcc-6.4.1?

[Bug c++/84994] Missing accessor hint for private field at -O1 and above when -g is enabled

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

Summary|Missing accessor hint for   |Missing accessor hint for
   |private field at -O1 and|private field at -O1 and
   |above   |above when -g is enabled

--- Comment #2 from David Malcolm  ---
Adding -v shows that godbolt.org is silently injecting "-g"; this is also
needed to show the issue i.e. the problem occurs at -O1 and above when -g is
enabled.

[Bug c++/84962] [8 Regression] ICE in get_fns, at cp/tree.c:2505

[nathan at gcc dot gnu.org]

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

--- Comment #3 from Nathan Sidwell  ---
Author: nathan
Date: Tue Mar 20 16:01:08 2018
New Revision: 258686

URL: https://gcc.gnu.org/viewcvs?rev=258686=gcc=rev
Log:
[PR c++/84962] ICE with anon-struct member

https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00961.html
PR c++/84962
* name-lookup.c (pushdecl_class_level): Push anon-struct's
member_vec, if there is one.

PR c++/84962
* g++.dg/lookup/pr84962.C: New.

Added:
trunk/gcc/testsuite/g++.dg/lookup/pr84962.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/84962] [8 Regression] ICE in get_fns, at cp/tree.c:2505

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #2 from Nathan Sidwell  ---
Fixed r258686.

[Bug c++/84970] [8 Regression] ICE in tsubst_copy, at cp/pt.c:15085

[nathan at gcc dot gnu.org]

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

--- Comment #3 from Nathan Sidwell  ---
Author: nathan
Date: Tue Mar 20 15:57:30 2018
New Revision: 258685

URL: https://gcc.gnu.org/viewcvs?rev=258685=gcc=rev
Log:
[PR c++/84970] lookup marking

https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00973.html
PR c++/84970
* cp-tree.h (lookup_list_keep): Declare.
* tree.c (lookup_list_keep): New, broken out of ...
(build_min): ... here.  Call it.
* decl.c (cp_finish_decl): Call lookup_list_keep.

PR c++/84970
* g++.dg/lookup/pr84970.C: New.

Added:
trunk/gcc/testsuite/g++.dg/lookup/pr84970.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/84970] [8 Regression] ICE in tsubst_copy, at cp/pt.c:15085

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

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

[Bug c++/71638] [6/7/8 Regression] ICE on invalid C++ code on x86_64-linux-gnu with -Wall (internal compiler error: non-constant element in constant CONSTRUCTOR)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords|error-recovery, |ice-on-valid-code
   |ice-on-invalid-code |
   Priority|P4  |P2

--- Comment #9 from Marek Polacek  ---
Another test case, which is valid; raising priority thus.

// PR c++/71638

struct A {
  struct {
int i;
int  = i;
  } b;
  int a = b.j;
};

void bar (A);

void
foo ()
{
  bar (A{});
}

[Bug tree-optimization/84969] [8 Regression] Wrong code with -ftree-loop-distribute-patterns

[amker at gcc dot gnu.org]

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

--- Comment #2 from amker at gcc dot gnu.org ---
I see, there are two issues here.
 - wrong code issue: fuse_memset_builtins breaks dependence between two
intersect memset call;
 - efficiency issue: The loop should not be distributed into two memset calls
by some model.

I will fix the first one now and check if the second should be fixed at this
point or not.

[Bug c++/83258] Rejecting function pointer non-type template parameter without linkage

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
With this patch:

--- a/gcc/cp/pt.c   
+++ b/gcc/cp/pt.c   
@@ -6259,7 +6259,8 @@ convert_nontype_argument_function (tree type, tree expr,  
 }  

   linkage = decl_linkage (fn_no_ptr);  
-  if (cxx_dialect >= cxx11 ? linkage == lk_none : linkage != lk_external)  
+  if ((cxx_dialect < cxx11 && linkage != lk_external)
+  || (cxx_dialect < cxx17 && linkage == lk_none))
 {
   if (complain & tf_error)
{

We accept Barry's testcase in C++17 mode.

I think we also need this for some non-type arguments without linkage:


@@ -6979,7 +6980,8 @@ convert_nontype_argument (tree type, tree expr,
tsubst_flags_t complain)

  /* DR 1155 allows internal linkage in C++11 and up.  */
  linkage_kind linkage = decl_linkage (expr);
- if (linkage < (cxx_dialect >= cxx11 ? lk_internal : lk_external))
+ if ((cxx_dialect < cxx11 && linkage < lk_external)
+ || (cxx_dialect < cxx17 && linkage < lk_internal))
{
  if (complain & tf_error)
error ("%qE is not a valid template argument for type %qT "


but that second change causes a new ice-on-invalid for this in C++17 mode (but
seems to correctly compile it when VALID is defined):


template  struct TestClass
{
  TestClass() : _val(val) { }
  T _val;
};

extern constexpr float e = 2.72;// external linkage
static constexpr float pi = 3.14;   // internal linkage

int main()
{
#ifdef VALID
  static
#endif
  constexpr float one = 1; // no linkage

  TestClass test1;

  TestClass test2;

  TestClass test3;
}


linkage.cc: In constructor 'TestClass::TestClass() [with T = float;
const T& val = one]':
linkage.cc:3:3: error: Local declaration from a different function
   TestClass() : _val(val) { }
   ^
one
linkage.cc:3:25: note: in statement
   TestClass() : _val(val) { }
 ^
one.2_1 = one;
during GIMPLE pass: cfg
linkage.cc:3:3: internal compiler error: verify_gimple failed
   TestClass() : _val(val) { }
   ^
0xdfad0d verify_gimple_in_cfg(function*, bool)
/home/jwakely/src/gcc/gcc/gcc/tree-cfg.c:5579
0xcc6956 execute_function_todo
/home/jwakely/src/gcc/gcc/gcc/passes.c:1994
0xcc79d2 execute_todo
/home/jwakely/src/gcc/gcc/gcc/passes.c:2048
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.