[Bug target/66140] New: ICE at extract_insn, at recog.c:2343 when compiling for alpha with gcc-5.1.1

[dhowells at redhat dot com]

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

Bug ID: 66140
   Summary: ICE at extract_insn, at recog.c:2343 when compiling
for alpha with gcc-5.1.1
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com
  Target Milestone: ---

Created attachment 35539
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35539&action=edit
Reduced test case

I'm seeing the following ICE:

alpha-linux-gnu-gcc -O2 -c alpha-reduced.c
alpha-reduced.c: In function 'lpfc_bg_scsi_prep_dma_buf_s3':
alpha-reduced.c:51:1: error: unrecognizable insn:
 }
 ^
(insn 88 87 89 9 (set (reg:DI 3 $3)
(mem:DI (and:DI (plus:DI (mem/c:DI (plus:DI (reg/f:DI 30 $30)
(const_int 64 [0x40])) [6 %sfp+0 S8 A64])
(const_int 3 [0x3]))
(const_int -8 [0xfff8])) [0  S8 A64]))
alpha-reduced.c:35 -1
 (nil))
alpha-reduced.c:51:1: internal compiler error: in extract_insn, at recog.c:2343

with the attached test case when cross-compiling for alpha with gcc-5.1.1.

The compiler is built from SVN rev 222331 dated 20150422 with no patches
applied and is running on an x86_64 Linux system.  The binutils is 2.25 based.

The compiler was configured thus:

CC=gcc \
CXX=g++ \
CFLAGS='-O2 -g -Wall -Wformat-security -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=generic' \
CXXFLAGS=' -O2 -g -Wformat-security -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=generic ' \
CFLAGS_FOR_TARGET='-g -O2 -Wall -fexceptions' \
AR_FOR_TARGET=/usr/bin/alpha-linux-gnu-ar \
AS_FOR_TARGET=/usr/bin/alpha-linux-gnu-as \
DLLTOOL_FOR_TARGET=/usr/bin/alpha-linux-gnu-dlltool \
LD_FOR_TARGET=/usr/bin/alpha-linux-gnu-ld \
NM_FOR_TARGET=/usr/bin/alpha-linux-gnu-nm \
OBJDUMP_FOR_TARGET=/usr/bin/alpha-linux-gnu-objdump \
RANLIB_FOR_TARGET=/usr/bin/alpha-linux-gnu-ranlib \
READELF_FOR_TARGET=/usr/bin/alpha-linux-gnu-readelf \
STRIP_FOR_TARGET=/usr/bin/alpha-linux-gnu-strip \
WINDRES_FOR_TARGET=/usr/bin/alpha-linux-gnu-windres \
WINDMC_FOR_TARGET=/usr/bin/alpha-linux-gnu-windmc \
LDFLAGS='-Wl,-z,relro ' \
../gcc-5.1.1-20150422/configure --bindir=/usr/bin
--build=x86_64-redhat-linux-gnu --datadir=/usr/share --disable-decimal-float
--disable-dependency-tracking --disable-gold --disable-libgcj --disable-libgomp
--disable-libmudflap --disable-libquadmath --disable-libssp
--disable-libunwind-exceptions --disable-nls --disable-plugin --disable-shared
--disable-silent-rules --disable-sjlj-exceptions --disable-threads
--with-ld=/usr/bin/alpha-linux-gnu-ld --enable-__cxa_atexit
--enable-checking=release --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-initfini-array --enable-languages=c,c++
--enable-linker-build-id --enable-nls --enable-obsolete --enable-plugin
--enable-targets=all --exec-prefix=/usr --host=x86_64-redhat-linux-gnu
--includedir=/usr/include --infodir=/usr/share/info --libexecdir=/usr/libexec
--localstatedir=/var --mandir=/usr/share/man --prefix=/usr
--program-prefix=alpha-linux-gnu- --sbindir=/usr/sbin --sharedstatedir=/var/lib
--sysconfdir=/etc --target=alpha-linux-gnu
--with-bugurl=http://bugzilla.redhat.com/bugzilla/ --with-isl
--with-linker-hash-style=gnu --with-newlib
--with-sysroot=/usr/alpha-linux-gnu/sys-root --with-system-libunwind
--with-system-zlib --without-headers

and built thus:

AR_FOR_TARGET=/usr/bin/alpha-linux-gnu-ar \
AS_FOR_TARGET=/usr/bin/alpha-linux-gnu-as \
DLLTOOL_FOR_TARGET=/usr/bin/alpha-linux-gnu-dlltool \
LD_FOR_TARGET=/usr/bin/alpha-linux-gnu-ld \
NM_FOR_TARGET=/usr/bin/alpha-linux-gnu-nm \
OBJDUMP_FOR_TARGET=/usr/bin/alpha-linux-gnu-objdump \
RANLIB_FOR_TARGET=/usr/bin/alpha-linux-gnu-ranlib \
READELF_FOR_TARGET=/usr/bin/alpha-linux-gnu-readelf \
STRIP_FOR_TARGET=/usr/bin/alpha-linux-gnu-strip \
WINDRES_FOR_TARGET=/usr/bin/alpha-linux-gnu-windres \
WINDMC_FOR_TARGET=/usr/bin/alpha-linux-gnu-windmc \
make -C alpha-linux-gnu -j5 tooldir=/usr all-gcc
make -C alpha-linux-gnu -j5 tooldir=/usr all-target-libgcc

[Bug c/66127] Division by zero gets folded away

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

  Component|middle-end  |c

--- Comment #9 from Marek Polacek  ---
This is going to be solved in c_fully_fold_internal so changing the component.

[Bug fortran/66141] New: Invalid code generation with -O1, -O2, -O3 for x86_64 target for array reference in Fortran COMMON

[george at gly dot bris.ac.uk]

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

Bug ID: 66141
   Summary: Invalid code generation with -O1, -O2, -O3 for x86_64
target for array reference in Fortran COMMON
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: george at gly dot bris.ac.uk
  Target Milestone: ---

Created attachment 35540
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35540&action=edit
Self-contained program to show buggy functionality

Attached short Fortran program functions properly with no optimization or -O0
but not when -O1, -O2, or -O3 used.  Code generation for references to storage
in Fortran COMMON incorrect.

Expected output, when compiled with -O0 or no optimization is:

 kvalue should be OK but is OK

Output when compiled with -O1, -O2, or -O3 is:

 kvalue should be OK but is UNDEFINE

[Program generates warning on compilation, but this is allowed under the
semantics of Fortran COMMON (allocated COMMON storage is longest among any of
its definition).]

[Bug fortran/66141] Invalid code generation with -O1, -O2, -O3 for x86_64 target for array reference in Fortran COMMON

[george at gly dot bris.ac.uk]

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

--- Comment #1 from george at gly dot bris.ac.uk ---
uname -m -r -s -p output:
Darwin 13.4.0 x86_64 i386

[Bug fortran/66141] Invalid code generation with -O1, -O2, -O3 for x86_64 target for array reference in Fortran COMMON

[george at gly dot bris.ac.uk]

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

--- Comment #2 from george at gly dot bris.ac.uk ---
#gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/4.9.2/libexec/gcc/x86_64-apple-darwin13.4.0/4.9.2/lto-wrapper
Target: x86_64-apple-darwin13.4.0
Configured with: ../configure --build=x86_64-apple-darwin13.4.0
--prefix=/usr/local/Cellar/gcc/4.9.2
--enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-4.9
--with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr
--with-mpc=/usr/local/opt/libmpc --with-cloog=/usr/local/opt/cloog
--with-isl=/usr/local/opt/isl --with-system-zlib
--enable-version-specific-runtime-libs --enable-libstdcxx-time=yes
--enable-stage1-checking --enable-checking=release --enable-lto
--disable-werror --with-pkgversion='Homebrew gcc 4.9.2'
--with-bugurl=https://github.com/Homebrew/homebrew/issues --enable-plugin
--disable-nls --enable-multilib
Thread model: posix
gcc version 4.9.2 (Homebrew gcc 4.9.2)

[Bug libstdc++/66018] opendir configure test not working when GCC_NO_EXECUTABLES

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

 CC||thopre01 at gcc dot gnu.org

--- Comment #8 from Thomas Preud'homme  ---
(In reply to Christophe Lyon from comment #6)
> Looking at libstdc++'s config.log, I noticed that GCC_NO_EXECUTABLES is set
> because the default GCC link command fails on aarch64-none-elf and
> arm-none-eabi --with-mode=thumb because librdimon.a is not used by default.

GCC_NO_EXECUTABLES is set whenever cross-compilation is done (see around line
55 in libstdc++-v3/configure.ac). This is because in such a case host headers
cannot be used.

> 
> Could it be that this opendir test is the first link test in libstc++'s
> configure for those targets? (And thus that the above problem was unnoticed
> for months?)

Not months, just a few days. The change that introduced this issue is the
addition of AC_STRUCT_DIRENT_D_TYPE in libstdc++-v3/configure.ac as part of
@222654. Commenting this directive allows the build to work.

[Bug fortran/53086] [4.8 Regression] 416.gamess in SPEC CPU 2006 miscompiled

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||george at gly dot bris.ac.uk

--- Comment #16 from Dominique d'Humieres  ---
*** Bug 66141 has been marked as a duplicate of this bug. ***

[Bug fortran/66141] Invalid code generation with -O1, -O2, -O3 for x86_64 target for array reference in Fortran COMMON

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #3 from Dominique d'Humieres  ---
> [Program generates warning on compilation, but this is allowed under
> the semantics of Fortran COMMON (allocated COMMON storage is longest
> among any of its definition).]

Nope! see the second item below:

5.7.2.5 Dierences between named common and blank common

1 A blank common block has the same properties as a named common block,
  except for the following.

 Execution of a RETURN or END statement might cause data objects in a named
 common block to become undefined unless the common block has the SAVE
attribute,
 but never causes data objects in blank common to become undefined (16.6.6).

 Named common blocks of the same name shall be of the same size in all scoping
 units of a program in which they appear, but blank common blocks may be of
 different sizes.

 A data object in a named common block may be initially defined by means of
 a DATA statement or type declaration statement in a block data program unit
 (11.3), but objects in blank common shall not be initially defined.

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

[Bug libstdc++/66018] opendir configure test not working when GCC_NO_EXECUTABLES

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
I think the right solution is just to stop using AC_STRUCT_DIRENT_D_TYPE which
expands to the opendir link test.

The autoconf manual doesn't say anything about it doing a link test, I was only
trying to find whether DIR.d_type exists :-(

[Bug rtl-optimization/63277] ARM - NEON excessive use of vmov for vtbl2 / uint8x8x2 for shuffling data unnecessarily around

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Keywords||ra
 CC||ramana at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org
  Component|target  |rtl-optimization

--- Comment #5 from Ramana Radhakrishnan  ---
Adding Vlad to CC.

[Bug libstdc++/66018] opendir configure test not working when GCC_NO_EXECUTABLES

[thopre01 at gcc dot gnu.org]

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

--- Comment #10 from Thomas Preud'homme  ---
(In reply to Jonathan Wakely from comment #9)
> I think the right solution is just to stop using AC_STRUCT_DIRENT_D_TYPE
> which expands to the opendir link test.
> 
> The autoconf manual doesn't say anything about it doing a link test, I was
> only trying to find whether DIR.d_type exists :-(

It links to check which library contains opendir. I'm not sure why it searches
this though. Maybe a bug in autoconf?

Best regards,

Thomas

[Bug libstdc++/66018] opendir configure test not working when GCC_NO_EXECUTABLES

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
It seems very intentional, not a bug. I have a patch to stop using it but I
can't regenerate the configure script because of the move to automake-1.11.6

[Bug c/66127] Division by zero gets folded away

[mpolacek at gcc dot gnu.org]

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

--- Comment #10 from Marek Polacek  ---
Author: mpolacek
Date: Thu May 14 11:42:53 2015
New Revision: 223193

URL: https://gcc.gnu.org/viewcvs?rev=223193&root=gcc&view=rev
Log:
PR c/66066
PR c/66127
* c-common.c (c_fully_fold): Pass false down to c_fully_fold_internal.
(c_fully_fold_internal): Fold C_MAYBE_CONST_EXPRs with
C_MAYBE_CONST_EXPR_INT_OPERANDS set.  Add FOR_INT_CONST argument and
use it.  If FOR_INT_CONST, require that all evaluated operands be
INTEGER_CSTs.

* c-typeck.c (digest_init): Call pedwarn_init with OPT_Wpedantic
rather than with 0.

* gcc.dg/pr14649-1.c: Add -Wpedantic.
* gcc.dg/pr19984.c: Likewise.
* gcc.dg/pr66066-1.c: New test.
* gcc.dg/pr66066-2.c: New test.
* gcc.dg/pr66066-3.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr66066-1.c
trunk/gcc/testsuite/gcc.dg/pr66066-2.c
trunk/gcc/testsuite/gcc.dg/pr66066-3.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/pr14649-1.c
trunk/gcc/testsuite/gcc.dg/pr19984.c

[Bug c/66066] [6 Regression] r222889 causes bogus error: initializer element is not constant

[mpolacek at gcc dot gnu.org]

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

--- Comment #18 from Marek Polacek  ---
Author: mpolacek
Date: Thu May 14 11:42:53 2015
New Revision: 223193

URL: https://gcc.gnu.org/viewcvs?rev=223193&root=gcc&view=rev
Log:
PR c/66066
PR c/66127
* c-common.c (c_fully_fold): Pass false down to c_fully_fold_internal.
(c_fully_fold_internal): Fold C_MAYBE_CONST_EXPRs with
C_MAYBE_CONST_EXPR_INT_OPERANDS set.  Add FOR_INT_CONST argument and
use it.  If FOR_INT_CONST, require that all evaluated operands be
INTEGER_CSTs.

* c-typeck.c (digest_init): Call pedwarn_init with OPT_Wpedantic
rather than with 0.

* gcc.dg/pr14649-1.c: Add -Wpedantic.
* gcc.dg/pr19984.c: Likewise.
* gcc.dg/pr66066-1.c: New test.
* gcc.dg/pr66066-2.c: New test.
* gcc.dg/pr66066-3.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr66066-1.c
trunk/gcc/testsuite/gcc.dg/pr66066-2.c
trunk/gcc/testsuite/gcc.dg/pr66066-3.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/pr14649-1.c
trunk/gcc/testsuite/gcc.dg/pr19984.c

[Bug c/66127] Division by zero gets folded away

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #11 from Marek Polacek  ---
Ought to be fixed.

[Bug c/66066] [6 Regression] r222889 causes bogus error: initializer element is not constant

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66066
Bug 66066 depends on bug 66127, which changed state.

Bug 66127 Summary: Division by zero gets folded away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66127

   What|Removed |Added

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

[Bug c/66066] [6 Regression] r222889 causes bogus error: initializer element is not constant

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #19 from Marek Polacek  ---
Ought to be fixed.

[Bug libstdc++/66018] opendir configure test not working when GCC_NO_EXECUTABLES

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
Author: redi
Date: Thu May 14 11:47:19 2015
New Revision: 223194

URL: https://gcc.gnu.org/viewcvs?rev=223194&root=gcc&view=rev
Log:
PR libstdc++/66018
* acinclude.m4 (GLIBCXX_CHECK_FILESYSTEM_DEPS): Check for struct
dirent.d_type.
* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac (AC_STRUCT_DIRENT_D_TYPE): Remove.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/acinclude.m4
trunk/libstdc++-v3/config.h.in
trunk/libstdc++-v3/configure
trunk/libstdc++-v3/configure.ac

[Bug libstdc++/66018] opendir configure test not working when GCC_NO_EXECUTABLES

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

Version|unknown |6.0

--- Comment #13 from Jonathan Wakely  ---
This should be fixed now, please check.

[Bug c++/66121] internal compiler error: in strip_typedefs, at cp/tree.c:1369

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-14
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Fixed on trunk with r222529.

[Bug c++/66061] [5/6 Regression] Internal Compiler Error when specializing a variable template when the specialization is variadic

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-14
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |5.2
Summary|Internal Compiler Error |[5/6 Regression] Internal
   |when specializing a |Compiler Error when
   |variable template when the  |specializing a variable
   |specialization is variadic  |template when the
   ||specialization is variadic
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with r220183.

[Bug c++/66130] "invalid use of non-static member function" message could be clearer

[tromey at gcc dot gnu.org]

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

--- Comment #5 from Tom Tromey  ---
(In reply to Manuel López-Ibáñez from comment #4)

> For this testcase, my patch gives:
> 
> test.cc:8:34: error: invalid use of non-static member function ‘void X::m()’

That seems great to me.

[Bug target/65955] [arm] ICE during movcond_addsi split

[ktkachov at gcc dot gnu.org]

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

--- Comment #16 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Thu May 14 13:16:32 2015
New Revision: 223195

URL: https://gcc.gnu.org/viewcvs?rev=223195&root=gcc&view=rev
Log:
[ARM] Fix PR 65955: Do not take REGNO on non-REG operand in movcond_addsi

Backport from mainline
2015-05-12  Kyrylo Tkachov  

PR target/65955
* config/arm/arm.md (movcond_addsi): Check that operands[2] is a
REG before taking its REGNO.

Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/arm/arm.md

[Bug libstdc++/66011] [6 Regression] call to '__open_missing_mode' declared with attribute error

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Thu May 14 13:23:14 2015
New Revision: 223196

URL: https://gcc.gnu.org/viewcvs?rev=223196&root=gcc&view=rev
Log:
PR libstdc++/66011
* acinclude.m4 (GLIBCXX_CHECK_FILESYSTEM_DEPS): Check for fchmod and
sendfile.
* config.h.in: Regenerate.
* configure: Regenerate.
* src/filesystem/ops.cc (do_copy_file): Fix arguments to open(). Do
not return after copying contents. Use fchmod, fchmodat, and sendfile
when available.
(current_path, permissions, space): Use errno not return value.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/acinclude.m4
trunk/libstdc++-v3/config.h.in
trunk/libstdc++-v3/configure
trunk/libstdc++-v3/src/filesystem/ops.cc

[Bug libstdc++/66011] [6 Regression] call to '__open_missing_mode' declared with attribute error

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Fixed

[Bug libstdc++/66055] hash containers missing required reserving constructors

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Thu May 14 13:47:19 2015
New Revision: 223198

URL: https://gcc.gnu.org/viewcvs?rev=223198&root=gcc&view=rev
Log:
2015-05-14  Nathan Myers  
Jonathan Wakely  

PR libstdc++/66055
* include/std/unordered_map (unordered_map, unordered_multimap): Add
missing constructors.
* include/std/unordered_set (unordered_set, unordered_multiset):
Likewise.
* testsuite/23_containers/unordered_map/cons/66055.cc: New.
* testsuite/23_containers/unordered_multimap/cons/66055.cc: New.
* testsuite/23_containers/unordered_multiset/cons/66055.cc: New.
* testsuite/23_containers/unordered_set/cons/66055.cc: New.

Added:
trunk/libstdc++-v3/testsuite/23_containers/unordered_map/cons/66055.cc
trunk/libstdc++-v3/testsuite/23_containers/unordered_multimap/cons/66055.cc
trunk/libstdc++-v3/testsuite/23_containers/unordered_multiset/cons/66055.cc
trunk/libstdc++-v3/testsuite/23_containers/unordered_set/cons/66055.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/unordered_map.h
trunk/libstdc++-v3/include/bits/unordered_set.h

[Bug libstdc++/66055] hash containers missing required reserving constructors

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Fixed on trunk so far.

[Bug tree-optimization/66142] New: Loop is not vectorized because not sufficient support for GOMP_SIMD_LANE

[ysrumyan at gmail dot com]

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

Bug ID: 66142
   Summary: Loop is not vectorized because not sufficient support
for GOMP_SIMD_LANE
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ysrumyan at gmail dot com
  Target Milestone: ---

The attached test-case compiled with "-Ofast -fopenmp -march=core-avx2" options
contains loop marked with pragma omp simd which is not vectorized:
t1.cpp:66:20: note: not vectorized: data ref analysis failed MEM[(struct vec_
*)_9] = 1.0e+0;
where index is defined as
  _12 = GOMP_SIMD_LANE (simduid.0_11(D));
  _9 = &D.4231[_12].org;

Note that this test was extracted from important benchmark and loop in question
is vectorized if we revert fix for 59984.

[Bug tree-optimization/66142] Loop is not vectorized because not sufficient support for GOMP_SIMD_LANE

[ysrumyan at gmail dot com]

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

--- Comment #1 from Yuri Rumyantsev  ---
Created attachment 35541
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35541&action=edit
test-case to reproduce

Must be compiled with -Ofast -fopenmp -march=core-avx2 options.

[Bug rtl-optimization/65862] [MIPS] IRA/LRA issue: integers spilled to floating-point registers

[wdijkstr at arm dot com]

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

--- Comment #13 from Wilco  ---
(In reply to Vladimir Makarov from comment #9)
> Created attachment 35503 [details]
> ira-hook.patch
> 
> Here is the patch.  Could you try it and give me your opinion about it. 
> Thanks.

I tried it out and when forcing ALL_REGS to either GENERAL_REGS or FP_REGS
based on mode it generates significantly smaller spillcode, especially on some
of the high register pressure SPECFP2006 benchmarks like gamess. It is better
than avoiding ALL_REGS if the cost is higher (like the PPC patch mentioned
earlier) - this indicates that the case for preferring ALL_REGS for generic
loads/stores is pretty thin and likely not beneficial overall.

I'm glad with this we're moving towards a more conventional allocation scheme
where the decision of which register class to use is made early rather than
independently for each operand during allocation.

I didn't do a full performance regression test but early results show identical
performance with smaller codesize.

Note that this doesn't solve the lra-constraints issue where it ignores the
allocno class during spilling and just chooses the first variant that matches.

[Bug target/65955] [arm] ICE during movcond_addsi split

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #17 from ktkachov at gcc dot gnu.org ---
Should now be fixed on GCC 6, 5 and 4.9 branches.

[Bug ada/66143] New: __gnat_set_executable insufficient for correct gprinstall

[jeditekunum at gmail dot com]

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

Bug ID: 66143
   Summary: __gnat_set_executable insufficient for correct
gprinstall
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeditekunum at gmail dot com
  Target Milestone: ---

When installing asis the tool executables installed by gprinstall have
permissions rwxr--r--.

gprinstall eventually calls __gnat_set_executable in adaint.c which adds only
S_IXUSR to chmod. This should probably be (S_IXUSR | S_IXGRP | S_IXOTH) and
should probably be filtered through current umask setting.

Additionally, similar problems may exist for __gnat_set_writable and
__gnat_set_non_writable, __gnat_set_readable, __gnat_set_non_readable. Readable
uses S_IREAD which in the same source file is defined as (S_IRUSR | S_IRGRP |
S_IROTH) for vxworks and android. However, S_IREAD is only S_IRUSR on OS X and
Solaris and indeed is an obsolete BSD compatibility that is suppose to be only
S_IRUSR.

[Bug target/66144] New: vector element operator produces very bad code

[mkg at us dot ibm.com]

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

Bug ID: 66144
   Summary: vector element operator produces very bad code
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mkg at us dot ibm.com
  Target Milestone: ---

Compiling the following input
#include 

vector char
test( vector char a, vector char b)
{
return a == b;
}

generates the following output with gcc from from trunk/head with -O3 


test:
vcmpequb 2,2,3
xxlxor 32,32,32
vspltisw 1,-1
xxsel 34,32,33,34
blr

The original first instruction already has the right answer, then it's
recomputed!

The inverted condition
#include 

vector char
test( vector char a, vector char b)
{
return a != b;
}


produces
test:
vcmpequb 2,2,3
xxlxor 33,33,33
vspltisw 0,-1
xxsel 34,32,33,34
blr

[Bug target/66144] vector element operator produces very bad code

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

Version|tree-ssa|4.9.0

--- Comment #1 from Andrew Pinski  ---
I suspect a == b is all equals and not element by element equals.

[Bug target/66144] vector element operator produces very bad code

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> I suspect a == b is all equals and not element by element equals.

I am wrong.

>From the manual:
Vector comparison is supported with standard comparison operators: ==, !=, <,
<=, >, >=. Comparison operands can be vector expressions of integer-type or
real-type. Comparison between integer-type vectors and real-type vectors are
not supported. The result of the comparison is a vector of the same width and
number of elements as the comparison operands with a signed integral element
type.

Vectors are compared element-wise producing 0 when comparison is false and -1
(constant of the appropriate type where all bits are set) otherwise. Consider
the following example.

 typedef int v4si __attribute__ ((vector_size (16)));

 v4si a = {1,2,3,4};
 v4si b = {3,2,1,4};
 v4si c;

 c = a >  b; /* The result would be {0, 0,-1, 0}  */
 c = a == b; /* The result would be {0,-1, 0,-1}  */

[Bug c++/66130] "invalid use of non-static member function" message could be clearer

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||paolo.carlini at oracle dot com

--- Comment #6 from Manuel López-Ibáñez  ---
(In reply to Tom Tromey from comment #5)
> (In reply to Manuel López-Ibáñez from comment #4)
> 
> > For this testcase, my patch gives:
> > 
> > test.cc:8:34: error: invalid use of non-static member function ‘void X::m()’
> 
> That seems great to me.

Perhaps Jason or Paolo know how to extract a declaration from an offset_ref for
the testcase in comment #2.

[Bug other/63513] Error to build gcc loaded from svn

[zfefm at gmx dot de]

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

zf  changed:

   What|Removed |Added

 CC||zfefm at gmx dot de

--- Comment #2 from zf  ---
I have the same problem when I try to build gcc (4.92 or 5.1) on my Macbook OS
10.9.5.
On my MacPro, also runing 10.9.5, this builds without problems. I have not yet
found the reason for this difference.

[Bug libstdc++/66145] New: std::ios_base::failure objects thrown from libstdc++.so use old ABI

[redi at gcc dot gnu.org]

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

Bug ID: 66145
   Summary: std::ios_base::failure objects thrown from
libstdc++.so use old ABI
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: ABI
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
CC: doko at gcc dot gnu.org
  Target Milestone: ---

Using the new cxx11 ABI in GCC5 (and trunk) the exception here isn't caught:

#define _GLIBCXX_USE_CXX11_ABI 1
#include 
#include 

int main()
{
  std::fstream f;
  f.exceptions(std::ios::badbit);
  try {
f.pword(std::numeric_limits::max());
  } catch (const std::ios_base::failure&) {
return 0;
  }
  throw 1;
}


terminate called after throwing an instance of 'std::ios_base::failure'
  what():  ios_base::_M_grow_words is not valid
Aborted (core dumped)

This is because src/c++11/functexcept.cc has:

// We don't want to change the type thrown by __throw_ios_failure (yet?)
#define _GLIBCXX_USE_CXX11_ABI 0

I actually planned to change it for GCC5 but missed it. If we change the ABI
used to compile functexcept.cc then the code above would fail when using the
old ABI instead.

One option to make both forms work would be to hack the EH runtime to make
handlers for std::ios_base::failure able to catch
std::ios_base::failure[abi:cxx11] objects, and vice versa, creating an object
of the other type on the fly.

[Bug libstdc++/66146] New: call_once not C++11-compliant on ppc64le

[andrey.vul at gmail dot com]

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

Bug ID: 66146
   Summary: call_once not C++11-compliant on ppc64le
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrey.vul at gmail dot com
  Target Milestone: ---

std::call_once is not C++11 (or even N2447) compliant on ppc64le.

According to N2447, "If the invocation of func results in an exception being
thrown, the exception is propagated to the caller and the effects are as-if
this invocation of call_once did not occur."

Given the code

#include 

int call_count = 0;
void func_() {
printf("Inside func_ call_count %d\n", call_count);
if (++call_count < 2)
throw 0;
}
int main() {
std::once_flag flag_;
printf("Before calling call_once flag_: %d\n", *(int*)&flag_);
try { std::call_once(flag_, func_); } catch(...) { printf("Inside catch all
excepton flag_: %d\n", *(int*)&flag_); }
printf("before the 2nd call to call_once flag_: %d\n", *(int*)&flag_);
std::call_once(flag_, func_);
}

the output on amd64 is
Before calling call_once flag_: 0
Inside func_ call_count 0
Inside catch all excepton flag_: 0
before the 2nd call to call_once flag_: 0

but on ppc64el is
Before calling call_once flag_: 0
Inside func_ call_count 0
Inside catch all excepton flag_: 1
before the 2nd call to call_once flag_: 1

amd64 has the correct behavior.

ppc64le gcc tested:
$gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/powerpc64le-linux-gnu/4.9/lto-wrapper
Target: powerpc64le-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.9.1-16ubuntu6'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libsanitizer
--disable-libquadmath --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-ppc64el/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-ppc64el
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-ppc64el
--with-arch-directory=ppc64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-secureplt --with-cpu=power7 --with-tune=power8
--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
Thread model: posix
gcc version 4.9.1 (Ubuntu 4.9.1-16ubuntu6) 

$gcc-5.1 -v
Using built-in specs.
COLLECT_GCC=/home/andreyv/nfs/gcc/bin/gcc-5.1
COLLECT_LTO_WRAPPER=/nfs/home/andreyv/gcc/bin/../libexec/gcc/powerpc64le-unknown-linux-gnu/5.1.0/lto-wrapper
Target: powerpc64le-unknown-linux-gnu
Configured with: ../gcc-5.1.0/configure --prefix=/nfs/home/andreyv/gcc/
--program-suffix=-5.1 --enable-languages=c,c++,lto CFLAGS='-O2 -mtune=native'
CXXFLAGS='-O2 -mtune=native'
Thread model: posix
gcc version 5.1.0 (GCC) 

Both versions compiled and run on Ubuntu 14.10 on a Power8.
gcc-5.1 invocation: $ ~/nfshome/gcc/bin/g++-5.1 -std=c++11 -lpthread
-Wl,-rpath=~/nfshome/gcc/lib64 -Wall -Wextra a.cc
gcc-4.9 invocation: g++ -std=c++11 -lpthread -Wall -Wextra a.cc

[Bug go/66147] New: [5/6 Regression] go fails to cross build

[doko at gcc dot gnu.org]

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

Bug ID: 66147
   Summary: [5/6 Regression] go fails to cross build
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: doko at gcc dot gnu.org
CC: cmang at google dot com
  Target Milestone: ---

cross building gccgo succeeded in 4.9, it fails on the gcc-5 branch and on the
trunk.

patch posted at
https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00444.html

[Bug target/66140] ICE at extract_insn, at recog.c:2343 when compiling for alpha with gcc-5.1.1

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-14
 CC||rth at gcc dot gnu.org,
   ||ubizjak at gmail dot com
 Ever confirmed|0   |1

--- Comment #1 from Uroš Bizjak  ---
Confirmed with a cross from x86_64-linux-gnu.

The problem is with (insn 56), where reload does:

Reloads for insn # 56
Reload 0: reload_in (DI) = (reg/v/f:DI 71 [ bpl ])
GENERAL_REGS, RELOAD_FOR_OUTPUT_ADDRESS (opnum = 0)
reload_in_reg: (reg/v/f:DI 71 [ bpl ])
reload_reg_rtx: (reg:DI 4 $4)
Reload 1: GENERAL_REGS, RELOAD_FOR_OUTPUT_ADDRESS (opnum = 0), can't combine,
secondary_reload_p
reload_reg_rtx: (reg:TI 2 $2)
Reload 2: reload_out (QI) = (mem:QI (plus:DI (reg/v/f:DI 71 [ bpl ])
(const_int 3 [0x3])) [1
*bpl_5+3 S1 A8])
GENERAL_REGS, RELOAD_FOR_OUTPUT (opnum = 0)
reload_out_reg: (mem:QI (plus:DI (reg/v/f:DI 71 [ bpl ])
(const_int 3 [0x3])) [1
*bpl_5+3 S1 A8])
reload_reg_rtx: (reg:QI 5 $5)
secondary_out_reload = 1

secondary_out_icode = reload_outqi

Tracing the RTX through reload_outqi, we enter with operands[0]:

(mem:QI (plus:DI (reg/v/f:DI 71 [ bpl ])
(const_int 3 [0x3])) [1 *bpl_5+3 S1 A8])

and get_unaligned_addr returns:

(plus:DI (reg/v/f:DI 71 [ bpl ])
(const_int 3 [0x3]))

But ... (reg/v/f:DI 71 [ bpl ]) is scheduled for reload in Reload 0, and got
its replacement register (reg:DI 4 $4).

So, we have to call find_replacement in get_unaligned_address, even if (ref) is
otherwise correct memory_address_p operand.

With the (totaly untested) patch below, get_unaligned_address returns:

(plus:DI (reg:DI 4 $4)
(const_int 3 [0x3]))

--cut here--
Index: alpha.c
===
--- alpha.c (revision 223201)
+++ alpha.c (working copy)
@@ -1602,8 +1602,7 @@ get_unaligned_address (rtx ref)

   gcc_assert (MEM_P (ref));

-  if (reload_in_progress
-  && ! memory_address_p (GET_MODE (ref), XEXP (ref, 0)))
+  if (reload_in_progress)
 {
   base = find_replacement (&XEXP (ref, 0));

--cut here--

[Bug middle-end/66148] New: [6 regression] build/genpreds: Internal error: abort in choose_enum_order, at genpreds.c:1006

[danglin at gcc dot gnu.org]

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

Bug ID: 66148
   Summary: [6 regression] build/genpreds: Internal error: abort
in choose_enum_order, at genpreds.c:1006
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

/test/gnu/gcc/objdir/./prev-gcc/xg++ -B/test/gnu/gcc/objdir/./prev-gcc/
-B/opt/g
nu64/gcc/gcc-5.0/hppa64-hp-hpux11.11/bin/ -nostdinc++
-B/test/gnu/gcc/objdir/pre
v-hppa64-hp-hpux11.11/libstdc++-v3/src/.libs
-B/test/gnu/gcc/objdir/prev-hppa64-
hp-hpux11.11/libstdc++-v3/libsupc++/.libs 
-I/test/gnu/gcc/objdir/prev-hppa64-hp
-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11 
-I/test/gnu/gcc/objdir/prev
-hppa64-hp-hpux11.11/libstdc++-v3/include 
-I/test/gnu/gcc/gcc/libstdc++-v3/libs
upc++ -L/test/gnu/gcc/objdir/prev-hppa64-hp-hpux11.11/libstdc++-v3/src/.libs
-L/test/gnu/gcc/objdir/prev-hppa64-hp-hpux11.11/libstdc++-v3/libsupc++/.libs  
-g -O2 -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W
-Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror   -DHAVE_CONFIG_H -DGENERATOR_FILE
-static-libstdc++ -static-libgcc  -o build/genconditions \
build/genconditions.o build/rtl.o build/read-rtl.o build/ggc-none.o
build/vec.o build/min-insn-modes.o build/gensupport.o build/print-rtl.o
build/read-md.o build/errors.o .././libiberty/libiberty.a
build/genpreds -c ../../gcc/gcc/common.md ../../gcc/gcc/config/pa/pa.md >
tmp-constrs.h
build/genpreds: Internal error: abort in choose_enum_order, at genpreds.c:1006

First seen in r223163.  r222861 was okay.

[Bug debug/66149] New: ICE: tree check: expected field_decl, have template_decl in int_bit_position, at tree.h:5012 with -std=c++14 -gstabs

[zsojka at seznam dot cz]

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

Bug ID: 66149
   Summary: ICE: tree check: expected field_decl, have
template_decl in int_bit_position, at tree.h:5012 with
-std=c++14 -gstabs
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---

Created attachment 35542
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35542&action=edit
reduced testcase

Compiler output:
$ gcc -std=c++14 -gstabs testcase.C
testcase.C:1:8: internal compiler error: tree check: expected field_decl, have
template_decl in int_bit_position, at tree.h:5012
 struct A
^
0x107683c tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/mnt/svn/gcc-5/gcc/tree.c:9297
0xa0bde9 tree_check(tree_node const*, char const*, int, char const*, tree_code)
/mnt/svn/gcc-5/gcc/tree.h:3102
0xa0bde9 int_bit_position(tree_node const*)
/mnt/svn/gcc-5/gcc/tree.h:5012
0xa04a0f dbxout_type_fields
/mnt/svn/gcc-5/gcc/dbxout.c:1544
0xa04a0f dbxout_type
/mnt/svn/gcc-5/gcc/dbxout.c:2221
0xa08af2 dbxout_symbol(tree_node*, int)
/mnt/svn/gcc-5/gcc/dbxout.c:2793
0xd1a0c2 rest_of_type_compilation(tree_node*, int)
/mnt/svn/gcc-5/gcc/passes.c:309
0x79b854 finish_struct_1(tree_node*)
/mnt/svn/gcc-5/gcc/cp/class.c:6714
0x79cf94 finish_struct(tree_node*, tree_node*)
/mnt/svn/gcc-5/gcc/cp/class.c:6879
0x7d743d cp_parser_class_specifier_1
/mnt/svn/gcc-5/gcc/cp/parser.c:19855
0x7d743d cp_parser_class_specifier
/mnt/svn/gcc-5/gcc/cp/parser.c:20083
0x7d743d cp_parser_type_specifier
/mnt/svn/gcc-5/gcc/cp/parser.c:14726
0x7eaeef cp_parser_decl_specifier_seq
/mnt/svn/gcc-5/gcc/cp/parser.c:11957
0x7fc121 cp_parser_simple_declaration
/mnt/svn/gcc-5/gcc/cp/parser.c:11534
0x7f5d83 cp_parser_block_declaration
/mnt/svn/gcc-5/gcc/cp/parser.c:11481
0x7ffc29 cp_parser_declaration
/mnt/svn/gcc-5/gcc/cp/parser.c:11378
0x7fe2ba cp_parser_declaration_seq_opt
/mnt/svn/gcc-5/gcc/cp/parser.c:11264
0x7fe5cf cp_parser_translation_unit
/mnt/svn/gcc-5/gcc/cp/parser.c:4100
0x7fe5cf c_parse_file()
/mnt/svn/gcc-5/gcc/cp/parser.c:33192
0x935952 c_common_parse_file()
/mnt/svn/gcc-5/gcc/c-family/c-opts.c:1057
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Tested revisions:
r223190 - ICE
5 r222437 - ICE

[Bug c++/66150] New: [C++11] cv-qualifiers on function types are not ignored.

[eric at efcs dot ca]

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

Bug ID: 66150
   Summary: [C++11] cv-qualifiers on function types are not
ignored.
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

Currently GCC does not ignore cv-qualifiers applied to a function type.

Example:

typedef void T();
static_assert(std::is_same::value, "");

According to the C++11 standard:
[dcl.fct]p7:
The effect of a cv-qualifier-seq in a function declarator is not the
same as adding cv-qualification on top of the function type. In the
latter case, the cv-qualifiers are ignored.

[Bug fortran/65903] [5/6 Regression] Line continuation followed by comment character in string fails to compile

[laurent.chardon at gmail dot com]

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

--- Comment #4 from Laurent Chardon  ---
Thanks for the fix. If I may suggest a modification of the testcase in order to
check also when there are no blanks between the & and !. I know in Fortran it
shouldn't matter, but I don't see any harm in making sure... 

! { dg-do run }
! { dg-options "-std=gnu" }
! 
character(20) :: astring

100 format ("& notblank !")
200 format ("&  !")
300 format ("&!")

write(astring,100)
if (astring.ne."& notblank !") call abort
!print *, astring
write(astring,200)
if (astring.ne."&  !") call abort
!print *, astring
write(astring,300)
if (astring.ne."&!") call abort
!print *, astring

end

[Bug c++/66151] New: different "override" options

[tromey at gcc dot gnu.org]

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

Bug ID: 66151
   Summary: different "override" options
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tromey at gcc dot gnu.org
  Target Milestone: ---

clang has a "-Winconsistent-missing-override", which is in
use at Mozilla now.

This option will warn about a missing "override" (like -Wsuggest-override),
but only if the class already has some other use of "override".

It would be nice if GCC had this option as well.


Another proposed style at Mozilla is to allow just one of
"override", "final", or "virtual".  So an option to warn when
this style is violated would also be nice.

[Bug target/66144] vector element operator produces very bad code

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-14
 CC||segher at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Segher Boessenkool  ---
Confirmed.  This code is generated by rs6000_emit_vector_cond_expr
and combine doesn't know how to simplify it (it tries though).

[Bug rtl-optimization/65862] [MIPS] IRA/LRA issue: integers spilled to floating-point registers

[vmakarov at gcc dot gnu.org]

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

--- Comment #14 from Vladimir Makarov  ---
Author: vmakarov
Date: Thu May 14 20:40:44 2015
New Revision: 223202

URL: https://gcc.gnu.org/viewcvs?rev=223202&root=gcc&view=rev
Log:
2015-05-14  Vladimir Makarov  

PR rtl-optimization/65862
* target.def (ira_change_pseudo_allocno_class): New hook.
* targhooks.c (default_ira_change_pseudo_allocno_class): Default
value of the hook.
* targhooks.h (default_ira_change_pseudo_allocno_class): New
extern
* doc/tm.texi.in (TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS): Add the
hook.
* ira-costs.c (find_costs_and_classes): Call the hook and change
classes when it is necessary.
* doc/tm.texi: Update.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/tm.texi
trunk/gcc/doc/tm.texi.in
trunk/gcc/ira-costs.c
trunk/gcc/target.def
trunk/gcc/targhooks.c
trunk/gcc/targhooks.h

[Bug rtl-optimization/66152] New: suboptimal load bytes to stack

[SztfG at yandex dot ru]

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

Bug ID: 66152
   Summary: suboptimal load bytes to stack
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: SztfG at yandex dot ru
  Target Milestone: ---

for code

void foo(char *);

void bar(void)
{
  char a[] = {0,1,2,3,4,5,6,7};
  foo(a);
}

gcc generates many movb instructions:
subq$24, %rsp
movq%rsp, %rdi
movb$0, (%rsp)
movb$1, 1(%rsp)
movb$2, 2(%rsp)
movb$3, 3(%rsp)
movb$4, 4(%rsp)
movb$5, 5(%rsp)
movb$6, 6(%rsp)
movb$7, 7(%rsp)

clang produces:
pushq   %rax
movabsq $506097522914230528, %rax # imm = 0x706050403020100
movq%rax, (%rsp)
leaq(%rsp), %rdi

for 16-byte array, gcc 5.1.0 builds the array separately and copies it using
movqda and movaps instruction i.e. :
  char a[] = {0,1,2,3,4,5,6,7,0,1,2,3,4,5,6,7};
produces:
subq$24, %rsp
movdqa  .LC0(%rip), %xmm0
movq%rsp, %rdi
movaps  %xmm0, (%rsp)
but if I make a 17-byte array, it again create movb instruction for each byte

[Bug ipa/65972] ICE after applying a patch to enable verify_ssa

[dehao at google dot com]

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

--- Comment #5 from Dehao Chen  ---
Could you try if the following patch fixes the bug?

Thanks,
Dehao

Index: gcc/auto-profile.c
===
--- gcc/auto-profile.c  (revision 223204)
+++ gcc/auto-profile.c  (working copy)
@@ -1470,6 +1470,7 @@ afdo_vpt_for_early_inline (stmt_set *promoted_stmt
   if (has_vpt)
 {
   optimize_inline_calls (current_function_decl);
+  update_ssa (TODO_update_ssa);
   return true;
 }

[Bug c++/66153] New: Internal compiler error in nested template function

[paboyle at ph dot ed.ac.uk]

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

Bug ID: 66153
   Summary: Internal compiler error in nested template function
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: paboyle at ph dot ed.ac.uk
  Target Milestone: ---

Created attachment 35543
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35543&action=edit
Preprocessed source

Peters-MacBook-Pro:gcc5_debug pab$ g++-5 -std=c++11 broken.cc -o broken
'
Internal compiler error: Error reporting routines re-entered.

broken.cc: In substitution of 'template Container(arg.data[0]))> function(const Container&) [with int N = 1;
obj = ]':
broken.cc:43:101:   recursively required by substitution of 'template Container(arg.data[0]))> function(const
Container&) [with int N = 1; obj = ]'
broken.cc:43:101:   required by substitution of 'template
Container(arg.data[0]))> function(const Container&)
[with int N = 1; obj = ]'
broken.cc:45:33:   Abort trap: 6
 template auto function(const Container & arg)->
Container(arg.data[0]))>
   
 ^
g++-5: internal compiler error: Abort trap: 6 (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

==
#include 
#include 
#include 
#include 

typedef std::complex ComplexD;

template  class TypeMapper {
public:
  enum { NestLevel = T::NestLevel };
};

template<> class TypeMapper {
public:
  enum { NestLevel = 0 };
};

template class Container {
 public:
  std::vector data;
  Container(int size) : data (size){};
};

template class Recursive {
public:
  enum { NestLevel = TypeMapper::NestLevel + 1};
  obj internal;
};

template::type * =
nullptr > auto function(const obj &arg)-> obj
{
  std::cout<<"Leaf "<::type * =
nullptr > auto function(const obj &arg)-> obj
{
  std::cout<<"Node "<(arg.internal);
  return ret;
}

template auto function(const Container & arg)->
Container(arg.data[0]))>
{
  Container(arg.data[0]))> ret(arg.data.size());
  for(int ss=0;ss(arg.data[ss]);
  }
  return ret;
}


int main(int argc,char **argv)
{
  Container > > array(10);
  Container > > ret(10);

  ret = function<1>(array);
}
==

For reference, works on Intel 15, Clang++ multiple versions.

Peters-MacBook-Pro:gcc5_debug pab$ icpc -std=c++11 broken.cc -o broken
Peters-MacBook-Pro:gcc5_debug pab$ clang++  -std=c++11 broken.cc -o broken
Peters-MacBook-Pro:gcc5_debug pab$ clang++ --version
Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.1.0
Thread model: posix
Peters-MacBook-Pro:gcc5_debug pab$ icpc --version
icpc (ICC) 15.0.3 20150408
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

Output with both icpc and clang++ is:

Peters-MacBook-Pro:gcc5_debug pab$ ./broken 
Node 2
Leaf 1
Node 2
Leaf 1
Node 2
Leaf 1
Node 2
Leaf 1
Node 2
Leaf 1
Node 2
Leaf 1
Node 2
Leaf 1
Node 2
Leaf 1
Node 2
Leaf 1
Node 2
Leaf 1

[Bug rtl-optimization/66152] suboptimal load bytes to stack

[SztfG at yandex dot ru]

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

--- Comment #1 from SztfG at yandex dot ru ---
If array of char is initialized using string, gcc can use larger mov
instruction, like movabsq, movq, movl etc. but not movdqa, movaps or other xmm
But if zero byte appears in string, compiler always create a separate array and
copy it to stack, using various mov instruction, except xmm-based

void bar(void)
{
  char a[4] = "\x00\x02\x03\x04";
  foo(a);
}

produces

.LC0:
.string ""
.string "\002\003\004"

bar:
subq$24, %rsp
movl.LC0(%rip), %eax
movq%rsp, %rdi
movl%eax, (%rsp)
callfoo
addq$24, %rsp
ret

[Bug testsuite/66154] New: ReserveShadowMemoryRange test suite errors when memory overcommitting is turned off on Linux

[f.heckenb...@fh-soft.de]

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

Bug ID: 66154
   Summary: ReserveShadowMemoryRange test suite errors when memory
overcommitting is turned off on Linux
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: f.heckenb...@fh-soft.de
  Target Milestone: ---

[Bug testsuite/66154] ReserveShadowMemoryRange test suite errors when memory overcommitting is turned off on Linux

[f.heckenb...@fh-soft.de]

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

--- Comment #1 from Frank Heckenbach  ---
Somehow this got sent before the text was inserted, so here goes:

Also reported on Debian, but I was asked to report it here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785249

When I tried to build gcc on Debian jessie from sources
(debuild -us -uc), I got a number of errors like this:

FAIL: g++.dg/asan/interception-malloc-test-1.C  -O1  output pattern test, is
==25380==ERROR: AddressSanitizer failed to allocate 0xdfff0001000
(15392894357504) bytes at address 0x02008fff7000 (12)
==25380==ReserveShadowMemoryRange failed while trying to map 0xdfff0001000
bytes. Perhaps you're using ulimit -v
, should match malloc call.*(
|
)[^
]*heap-use-after-free

In fact I wasn't using ulimit -v, but I had turned off memory
overcommitting (sysctl: vm.overcommit_memory=2). Obviously I have
less than 14 TB of RAM in my system. ;) After I turned it on, these
errors disappeared.

So I suggest:

- If possible, amend the test to use a more reasonable allocation.
  Not sure what it's actually testing, but I wonder what I can do
  with 14 TB (which is way short of the 64 bit address range) that
  it couldn't do with, say 6 GB (larger than 32 bit range, in case
  that matters). Otherwise:

- In the wording of the message, add "or have turned off memory
  overcommitting" as a possible reason, at least for Linux systems.

- Verify [ `sysctl -n vm.overcommit_memory` -eq 0 ] early in the
  build process, so you don't get to see such errors after a long
  time building.

  Same for a ulimit check if there isn't one already.

[Bug sanitizer/66154] ReserveShadowMemoryRange test suite errors when memory overcommitting is turned off on Linux

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||dodji at gcc dot gnu.org,
   ||dvyukov at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||kcc at gcc dot gnu.org
  Component|testsuite   |sanitizer

--- Comment #2 from Andrew Pinski  ---
I think sanitizer in general needs overcommit turned on.  You should file this
bug upstream to them.

[Bug libstdc++/66018] opendir configure test not working when GCC_NO_EXECUTABLES

[thopre01 at gcc dot gnu.org]

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

--- Comment #14 from Thomas Preud'homme  ---
(In reply to Jonathan Wakely from comment #13)
> This should be fixed now, please check.

It is indeed. Thanks.

[Bug target/63810] gcc sets incorrect macro for OS X deployment targets

[vq at larryv dot me]

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

--- Comment #20 from Lawrence Velázquez  ---
(In reply to Francois-Xavier Coudert from comment #18)
> (In reply to Lawrence Velázquez from comment #17)
> 
> Hey Lawrence, do you have a copyright assignment in place with the FSF? If
> so, please submit your trunk patch to gcc-patc...@gcc.gnu.org for review. If
> not, ask on the g...@gcc.gnu.org list for the paperwork to be sent to you.

Sorry, it took me a while to obtain the paperwork, and even longer to get
around to submitting it.

https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01377.html