[Bug c++/58336] internal compiler error when using a static int for the size of a char array within a class

[holger.brunck at keymile dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58336

--- Comment #2 from holger.brunck at keymile dot com ---
With a g++ verison 4.7.2 it's definetely crashing on my side, but I
doublechecked with a 4.7.3 compiler and the problem seems already to be fixed.

g++ --version
g++ (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3

~$ g++ -g -c file.cpp

[Bug other/58347] New: Build fails on x86_64-unknown-linux-gnu in libvtv on ENABLE_VTABLE_VERIFY not in not appear in AM_CONDITIONAL

[dschroetter at mac dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58347

Bug ID: 58347
   Summary: Build fails on x86_64-unknown-linux-gnu in libvtv on
ENABLE_VTABLE_VERIFY not in not appear in
AM_CONDITIONAL
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dschroetter at mac dot com

Build on current git snapshot fails with the following error messages:

cd /home/ubuntu/gcc/libvtv && /bin/bash /home/ubuntu/gcc/missing --run
automake-1.11 --foreign
configure.ac:129: omit leading './' from config file names such as
'./Makefile';
configure.ac:129: remake rules might be subtly broken otherwise
testsuite/Makefile.am:42: ENABLE_VTABLE_VERIFY does not appear in
AM_CONDITIONAL
make[3]: *** [/home/ubuntu/gcc/libvtv/Makefile.in] Error 1
make[3]: Leaving directory `/home2/gccobj/x86_64-unknown-linux-gnu/libvtv'

[Bug other/58348] New: Build fails on x86_64-unknown-linux-gnu in libvtv on ENABLE_VTABLE_VERIFY not in AM_CONDITIONAL

[dschroetter at mac dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58348

Bug ID: 58348
   Summary: Build fails on x86_64-unknown-linux-gnu in libvtv on
ENABLE_VTABLE_VERIFY not in AM_CONDITIONAL
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dschroetter at mac dot com

Build on current git snapshot fails with the following error messages:

cd /home/ubuntu/gcc/libvtv && /bin/bash /home/ubuntu/gcc/missing --run
automake-1.11 --foreign
configure.ac:129: omit leading './' from config file names such as
'./Makefile';
configure.ac:129: remake rules might be subtly broken otherwise
testsuite/Makefile.am:42: ENABLE_VTABLE_VERIFY does not appear in
AM_CONDITIONAL
make[3]: *** [/home/ubuntu/gcc/libvtv/Makefile.in] Error 1
make[3]: Leaving directory `/home2/gccobj/x86_64-unknown-linux-gnu/libvtv'

[Bug other/58348] Build fails on x86_64-unknown-linux-gnu in libvtv on ENABLE_VTABLE_VERIFY not in AM_CONDITIONAL

[dschroetter at mac dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58348

--- Comment #1 from Dirk Schroetter  ---
Created attachment 30758
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30758&action=edit
configure log

[Bug c/58349] New: ARMv7: ICE in vect_determine_vectorization_factor, at tree-vect-loop.c:349

[pascal.massimino at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58349

Bug ID: 58349
   Summary: ARMv7: ICE in vect_determine_vectorization_factor, at
tree-vect-loop.c:349
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pascal.massimino at gmail dot com

Created attachment 30759
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30759&action=edit
preprocessed source to repro the ICE

[Got an ICE on ARMv7, and a suggestion to file a bug for it. Here it goes.]

The ICE disappeared when i changed the 'uint8_t' types to just 'int' in the
offending code.

The code is from the 'libwebp' open-source project:
http://git.chromium.org/webm/libwebp.git

Diagnostic:

gcc -v -save-temps  -O3 -DNDEBUG -DWEBP_HAVE_PNG -DWEBP_HAVE_JPEG
-DWEBP_HAVE_TIFF -DWEBP_USE_THREAD -Wextra -Wold-style-definition
-Wmissing-prototypes -Wmissing-declarations -Wdeclaration-after-statement
-Wshadow -march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a8 -Isrc/
-Wall -c src/dsp/upsampling.c -o src/dsp/upsampling.o
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --enable-multilib --disable-sjlj-exceptions
--with-arch=armv7-a --with-float=hard --with-fpu=vfpv3-d16 --with-mode=thumb
--disable-werror --enable-checking=release --build=arm-linux-gnueabihf
--host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-D' 'NDEBUG' '-D' 'WEBP_HAVE_PNG'
'-D' 'WEBP_HAVE_JPEG' '-D' 'WEBP_HAVE_TIFF' '-D' 'WEBP_USE_THREAD' '-Wextra'
'-Wold-style-definition' '-Wmissing-prototypes' '-Wmissing-declarations'
'-Wdeclaration-after-statement' '-Wshadow' '-march=armv7-a' '-mfloat-abi=hard'
'-mfpu=neon' '-mtune=cortex-a8' '-I' 'src/' '-Wall' '-c' '-o'
'src/dsp/upsampling.o' '-mthumb'
 /usr/lib/gcc/arm-linux-gnueabihf/4.6/cc1 -E -quiet -v -I src/ -imultilib .
-imultiarch arm-linux-gnueabihf -D NDEBUG -D WEBP_HAVE_PNG -D WEBP_HAVE_JPEG -D
WEBP_HAVE_TIFF -D WEBP_USE_THREAD src/dsp/upsampling.c -march=armv7-a
-mfloat-abi=hard -mfpu=neon -mtune=cortex-a8 -mthumb -Wextra
-Wold-style-definition -Wmissing-prototypes -Wmissing-declarations
-Wdeclaration-after-statement -Wshadow -Wall -O3 -fpch-preprocess
-fstack-protector -o upsampling.i
ignoring nonexistent directory "/usr/local/include/arm-linux-gnueabihf"
ignoring nonexistent directory
"/usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../../arm-linux-gnueabihf/include"
#include "..." search starts here:
#include <...> search starts here:
 src/
 /usr/lib/gcc/arm-linux-gnueabihf/4.6/include
 /usr/local/include
 /usr/lib/gcc/arm-linux-gnueabihf/4.6/include-fixed
 /usr/include/arm-linux-gnueabihf
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-D' 'NDEBUG' '-D' 'WEBP_HAVE_PNG'
'-D' 'WEBP_HAVE_JPEG' '-D' 'WEBP_HAVE_TIFF' '-D' 'WEBP_USE_THREAD' '-Wextra'
'-Wold-style-definition' '-Wmissing-prototypes' '-Wmissing-declarations'
'-Wdeclaration-after-statement' '-Wshadow' '-march=armv7-a' '-mfloat-abi=hard'
'-mfpu=neon' '-mtune=cortex-a8' '-I' 'src/' '-Wall' '-c' '-o'
'src/dsp/upsampling.o' '-mthumb'
 /usr/lib/gcc/arm-linux-gnueabihf/4.6/cc1 -fpreprocessed upsampling.i -quiet
-dumpbase upsampling.c -march=armv7-a -mfloat-abi=hard -mfpu=neon
-mtune=cortex-a8 -mthumb -auxbase-strip src/dsp/upsampling.o -O3 -Wextra
-Wold-style-definition -Wmissing-prototypes -Wmissing-declarations
-Wdeclaration-after-statement -Wshadow -Wall -version -fstack-protector -o
upsampling.s
GNU C (Ubuntu/Linaro 4.6.3-1ubuntu5) version 4.6.3 (arm-linux-gnueabihf)
compiled by GNU C version 4.6.3, GMP version 5.0.2, MPFR version 3.1.0-p3,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=91 --param ggc-min-heapsize=115799
GNU C (Ubuntu/Linaro 4.6.3-1ubuntu5) version 4.6.3 (arm-linux-gnueabihf)
compiled by GNU C version 4.6.3, GMP version 5.0.2, MPFR version 3.1.0-p3,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=91 --param ggc-min-heapsize=115799
Compiler executable checksum: ffcbc490dd19d9f3c1e5842c6cc7a10d
src/dsp/upsampling.c: In function ‘Yuv444ToRgb565’:
src/dsp/upsampling.c:223:13: internal compiler error: in
vect_determine_vectorization_facto

[Bug bootstrap/58350] New: libvtv/testsuite: Makefile:369: *** missing separator. Stop.

[dimhen at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58350

Bug ID: 58350
   Summary: libvtv/testsuite: Makefile:369: *** missing separator.
 Stop.
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimhen at gmail dot com

rev. 202352
Fedora 19/x86_64
configured as

 ~/src/gcc_current/configure --prefix=/usr/local/gcc_current
--with-multilib-list=m64 --enable-checking=release --enable-languages=c,c++,lto
--enable-plugin --with-tune=native --with-arch=native
--enable-version-specific-runtime-libs [--disable-vtv]

'--disable-vtv' change nothing in make's output

make
[...]
make[4]: Entering directory
`/home/dimhen/build/gcc_current/x86_64-unknown-linux-gnu/libvtv'
Makefile:839: warning: overriding recipe for target `multi-do'
Makefile:770: warning: ignoring old recipe for target `multi-do'
Makefile:887: warning: overriding recipe for target `multi-clean'
Makefile:818: warning: ignoring old recipe for target `multi-clean'
Making all in testsuite
make[5]: Entering directory
`/home/dimhen/build/gcc_current/x86_64-unknown-linux-gnu/libvtv/testsuite'
Makefile:369: *** missing separator.  Stop.

[Bug other/58347] Build fails on x86_64-unknown-linux-gnu in libvtv on ENABLE_VTABLE_VERIFY not in not appear in AM_CONDITIONAL

[sch...@linux-m68k.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58347

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Schwab  ---
.

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

[Bug other/58348] Build fails on x86_64-unknown-linux-gnu in libvtv on ENABLE_VTABLE_VERIFY not in AM_CONDITIONAL

[sch...@linux-m68k.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58348

--- Comment #2 from Andreas Schwab  ---
*** Bug 58347 has been marked as a duplicate of this bug. ***

[Bug c++/58201] [4.9 Regression] Undefined reference to `B::B(void const**)'

[hubicka at ucw dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58201

--- Comment #13 from Jan Hubicka  ---
> I'm a bit worried, because normally we don't check in the testsuite that those
> messages about the instantiation point have the right line number, thus, we 
> may
> well have a pretty serious diagnostic regression, beyond the specific failure.

I put some analysis here
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00456.html
It is latent bug in C++ FE using stale source_location.  Prior my change the
error
came on different location based on optimization flags and -flto. After my
change
it is consistently wrong ;)

Sadly i am not sure how to get correct location within the mangling hook and
where it is supposed to point.

[Bug c++/58317] Calling a method while preparing to call the constructor should be illegal

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58317

--- Comment #5 from Jonathan Wakely  ---
(In reply to Oleg Smolsky from comment #2)
> Hey Jonathan, here is a simpler and more natural way to rewrite your example:
> 
> struct A {
>   static int f() { return 0; }
>   A(int) { }
> };
> 
> int main() {
>   A a(A::f());  // it is static!
> }

Yes, I know, that's not the point. The standard doesn't disallow everything
that can be written another way. The point is that the original code is
syntactically legal.

> So, do you happen do have a reference to the Standard? Or is it one of the
> things that are not mentioned explicitly?

3.3.2 [basic.scope.pdecl] paragraph 1.

I already said GCC fails to warn, but it should not reject the code.

[Bug bootstrap/58340] [4.9 regression] gcc/cp/pt.c:7064:1: internal compiler error: in propagate_threaded_block_debug_into, at tree-ssa-threadedge.c:623

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58340

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org
   Target Milestone|--- |4.9.0
   Severity|normal  |blocker

--- Comment #6 from Eric Botcazou  ---
It comes from:

2013-09-06  Jeff Law  

* tree-ssa-dom.c (cprop_into_successor_phis): Also propagate
edge implied equivalences into successor phis.

[Bug bootstrap/58340] [4.9 regression] gcc/cp/pt.c:7064:1: internal compiler error: in propagate_threaded_block_debug_into, at tree-ssa-threadedge.c:623

[sch...@linux-m68k.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58340

--- Comment #7 from Andreas Schwab  ---
It's also causing miscompare on ia64.

[Bug libstdc++/58341] Doc conflicts with standard on forbidden range of `result` in copy_backward()

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58341

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||documentation
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-09-07
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
The docs just haven't been updated to show the DR resolution

[Bug c/58349] ARMv7: ICE in vect_determine_vectorization_factor, at tree-vect-loop.c:349

[mikpe at it dot uu.se]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58349

--- Comment #1 from Mikael Pettersson  ---
I can't reproduce the ICE with either one of gcc 4.6.3, 4.6.4, 4.7.3, or 4.8.1,
configured as crosses to armv7l-linux-gnueabi from x86_64-linux, with options
-march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a8 -mthumb -O3
-fstack-protector.

Looks like you're running a heavily modified native compiler from Ubuntu. 
Please report this ICE to them (unless you can reproduce with a vanilla FSF
version).

[Bug fortran/58351] New: ICE using c_f_pointer subroutine and derived types

[h.lars...@fz-juelich.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58351

Bug ID: 58351
   Summary: ICE using c_f_pointer subroutine and derived types
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: h.lars...@fz-juelich.de

I got an segmentation fault using the c_f_pointer-subroutine and derived types:
program blah
   use,intrinsic:: ISO_C_BINDING
   type t_m
  real,dimension(:),pointer::m
   end type t_m
   type foo 
  type(t_m)::i 
   end type foo
   real,dimension(:,:),pointer::e
   type(foo),target::b
   call C_F_POINTER(C_LOC(b%i%m), e ,[1,1])
end program blah

It works fine and correct with ifort 13.1.0.

% gfortan -Wall -Wextra ice.f90 
ice.f90: In function ‘blah’:
ice.f90:11:0: internal compiler error: Segmentation fault
call C_F_POINTER(C_LOC(b%i%m), e ,[1,1])
 ^
Please submit a full bug report,

% gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc/src/gcc-4.8-20130725/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 --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--enable-gnu-unique-object --enable-linker-build-id --enable-cloog-backend=isl
--disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default
--enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu
--disable-install-libiberty --disable-multilib --disable-libssp
--disable-werror --enable-checking=release
Thread model: posix
gcc version 4.8.1 20130725 (prerelease) (GCC)

[Bug c++/58352] New: infinite template instantiation depth errors

[1zeeky at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58352

Bug ID: 58352
   Summary: infinite template instantiation depth errors
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 1zeeky at gmail dot com

Created attachment 30760
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30760&action=edit
testcase

The attached testcase yields (seemingly?) infinite output of
"
integral_constant_test.cpp:8:74:   template instantiation depth exceeds maximum
of 900 (use -ftemplate-depth= to increase the maximum) substituting
‘template using IndexType = std::integral_constant [with long unsigned int i = 1ul]’
".

When using -ftemplate-depth=2, there's another message printed, but it still
doesn't stop:
"
integral_constant_test.cpp:8:13:   required by substitution of ‘template void foo(IndexType) [with A = int; long
unsigned int index = ]’
integral_constant_test.cpp:8:74:   template instantiation depth exceeds maximum
of 2 (use -ftemplate-depth= to increase the maximum) substituting
‘template using IndexType = std::integral_constant [with long unsigned int i = 0ul]’
".
The "index = " looks weird, too. What does that mean?


I'm not 100% sure the attached testcase *should* compile. It does when I move
the "specialized" foo (for IndexType<1>) before the general-case foo.
Compiling with -ftemplate-depth=1 points to the "specialized" version though:
"
integral_constant_test.cpp:11:13: error: template instantiation depth exceeds
maximum of 1 (use -ftemplate-depth= to increase the maximum) substituting
‘template using IndexType = std::integral_constant [with long unsigned int i = 1ul]’
 static void foo(const IndexType<1>) {}
 ^
integral_constant_test.cpp:11:13:   required by substitution of ‘template void foo(IndexType<1ul>) [with A = int]’
integral_constant_test.cpp:15:25:   required from here

integral_constant_test.cpp:8:13: error: template instantiation depth exceeds
maximum of 1 (use -ftemplate-depth= to increase the maximum) substituting
‘template using IndexType = std::integral_constant [with long unsigned int i = index]’
 static void foo(const IndexType) { foo(IndexType()); }
 ^
integral_constant_test.cpp:8:13:   required by substitution of ‘template void foo(IndexType) [with A = int; long
unsigned int index = ]’
integral_constant_test.cpp:15:25:   required from here
"

[Bug fortran/58351] ICE using c_f_pointer subroutine and derived types

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58351

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2013-09-07
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
I see the ICE with 4.8.1, but not with 4.9.0 (trunk). I'll try later to find
around which revision it has been fixed (r196783 gives the ICE, r198300 not).

[Bug bootstrap/58340] [4.9 regression] gcc/cp/pt.c:7064:1: internal compiler error: in propagate_threaded_block_debug_into, at tree-ssa-threadedge.c:623

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58340

--- Comment #8 from Dominique d'Humieres  ---
Also seen on x86_64-apple-darwin10.

[Bug bootstrap/58350] libvtv/testsuite: Makefile:369: *** missing separator. Stop.

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58350

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-09-07
 CC||ebotcazou at gcc dot gnu.org
   Target Milestone|--- |4.9.0
 Ever confirmed|0   |1
   Severity|normal  |blocker

--- Comment #1 from Eric Botcazou  ---
Confirmed with make 3.80.

[Bug c++/58201] [4.9 Regression] Undefined reference to `B::B(void const**)'

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58201

--- Comment #14 from Jakub Jelinek  ---
Perhaps use error_at and DECL_SOURCE_LOCATION of the expr being mangled?
Perhaps temporary set input_location to DECL_SOURCE_LOCATION for the duration
of mangle_decl, and use error_at (EXPR_LOC_OR_HERE (expr), instead of error?

[Bug c++/58201] [4.9 Regression] Undefined reference to `B::B(void const**)'

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58201

--- Comment #15 from Paolo Carlini  ---
Oh, I was just assuming that we didn't have the information! Indeed normally
exprs do have locations!

[Bug rtl-optimization/58210] 400.perlbench fails with ICE

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58210

--- Comment #4 from Marc Glisse  ---
Now that PR 58137 is fixed, can you still reproduce? Note that not everyone has
access to spec benchmarks.

[Bug rtl-optimization/58210] 400.perlbench fails with ICE

[Ganesh.Gopalasubramanian at amd dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58210

GGanesh  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug rtl-optimization/58210] 400.perlbench fails with ICE

[Ganesh.Gopalasubramanian at amd dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58210

--- Comment #5 from GGanesh  ---
(In reply to Marc Glisse from comment #4)
> Now that PR 58137 is fixed, can you still reproduce? Note that not everyone
> has access to spec benchmarks.

Thanks. The issue is solved. I am changing the status as fixed.
Next time I post issues related to spec benchmarks, I will make sure that I
post the preprocessed code.

[Bug c++/58353] New: Internal Compiler Error with Variadic Templates

[spamjunk at stny dot rr.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58353

Bug ID: 58353
   Summary: Internal Compiler Error with Variadic Templates
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: spamjunk at stny dot rr.com

bug.cpp: In instantiation of 'struct seq_t::gen<1, 123,
123, 123, 123>':
bug.cpp:11:12:   recursively required from 'struct seq_t::gen<4, 123>'
bug.cpp:11:12:   required from 'struct seq_t::gen<5>'
bug.cpp:21:59:   required from 'static constexpr seq_t::bits_t seq_t::init() [
with E = int; E V = 123; int CNT = 5]'
bug.cpp:30:42:   required from here
bug.cpp:11:12: internal compiler error: in tsubst, at cp/pt.c:11306
  struct gen : gen{};



Test Code:

#include 

using namespace std;

template
struct seq_t
{
 template struct seq{};

 template
 struct gen : gen{};

 template
 struct gen<0, Es...> : seq{};

 struct bits_t{ E e[CNT]; };

 template
 static constexpr bits_t init(seq) {return {{Es...}};}

 static constexpr bits_t init() {return init(gen{});}
};



int main()
{
 typedef seq_t wow;

 constexpr wow::bits_t bits(wow::init());

 cout << bits.e[0] << endl;
 cout << bits.e[1] << endl;
 cout << bits.e[2] << endl;
 cout << bits.e[3] << endl;
 cout << bits.e[4] << endl;
}

[Bug c++/58352] infinite template instantiation depth errors

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58352

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
The code example has undefined behaviour and moving your specialization to the
top is required to make it work. You hit [temp.dep.candidate] p1:

"For a function call where the postfix-expression is a dependent name, the
candidate functions are found using
the usual lookup rules (3.4.1, 3.4.2) except that:
— For the part of the lookup using unqualified name lookup (3.4.1), only
function declarations from the template definition context are found.
[..]

If the call would be ill-formed or would find a better match had the lookup
within the associated namespaces considered all the function declarations with
external linkage introduced in those namespaces in all translation units, not
just considering those declarations found in the template definition and
template
instantiation contexts, then the program has undefined behavior."

[Bug c++/58352] infinite template instantiation depth errors

[1zeeky at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58352

--- Comment #2 from 1zeeky at gmail dot com ---
I am aware that the code is invalid; I'm not saying there shouldn't be an
error.

The problem is, that g++ does not stop printing the error and needs to be
killed to stop. At least mine doesn't, maybe my downstream g++, or some
component (library) it uses, is broken somehow.

[Bug c++/58352] infinite template instantiation depth errors

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58352

--- Comment #3 from Daniel Krügler  ---
(In reply to 1zeeky from comment #2)
> I am aware that the code is invalid; I'm not saying there shouldn't be an
> error.

Then I was mislead by your comment: "I'm not 100% sure the attached testcase
*should* compile.". I agree that the diagnostics could be improved.

[Bug c++/58352] infinite template instantiation depth errors

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58352

--- Comment #4 from Daniel Krügler  ---
Maybe related to bug 16564?

[Bug c++/58352] infinite template instantiation depth errors

[1zeeky at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58352

--- Comment #5 from 1zeeky at gmail dot com ---
Ah, sorry. I wrote that before I found out that this was the issue with the
code.

[Bug c++/58354] New: variadic template ambigous

[1zeeky at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58354

Bug ID: 58354
   Summary: variadic template ambigous
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 1zeeky at gmail dot com

Created attachment 30761
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30761&action=edit
testcase

I have a templated function, which recursively calls itself.
The stopping criterion is provided via a std::integral_constant
that gets incremented each iteration and upon a certain value should call an
overload that does not recurse.

There are two requirements to get g++ to claim that the call is ambiguous:
There must be an extra template-parameter that is explicitly specified when
recursing (typename T in the testcase) and variadic templates must be used.
If either is not present, it compiles fine.
If variadic templates are present, but no additional arguments are passed (like
the second parameter for foo (0) in the testcase), it compiles fine.

clang 3.3 compiles this code fine, and given that the mentioned extra
requirements must be met to make the call ambiguous I'm somewhat confident that
it is valid C++.

This is the specific output the attached testcase generates for g++ 4.8.1:

test.cpp: In instantiation of ‘void foo(IndexType, Arguments ...) [with
T = int; long unsigned int index = 0ul; Arguments = {}; IndexType =
std::integral_constant]’:
test.cpp:15:25:   required from here
test.cpp:11:76: error: call of overloaded ‘foo(IndexType<1ul>, int)’ is
ambiguous
 void foo(IndexType, Arguments...) { foo(IndexType(), 0);
}
^
test.cpp:11:76: note: candidates are:
test.cpp:8:6: note: void foo(IndexType<1ul>, Arguments ...) [with T = int;
Arguments = {int}; IndexType<1ul> = std::integral_constant]
 void foo(IndexType<1>, Arguments...) { }
  ^
test.cpp:11:6: note: void foo(IndexType, Arguments ...) [with T = int;
long unsigned int index = 1ul; Arguments = {int}; IndexType =
std::integral_constant]
 void foo(IndexType, Arguments...) { foo(IndexType(), 0);
}
  ^

[Bug fortran/58351] ICE using c_f_pointer subroutine and derived types

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58351

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #2 from Dominique d'Humieres  ---
Likely fixed by revision 197053 (r197010 works for me but with a patch).
According to comment #12

> ... by r197053, apparently. Since this looks way too large for backporting, 
> I guess it will not be fixed on the 4.7 and 4.8 branches, right?

the fix won't be backported to 4.8.2.

[Bug other/58348] Build fails on x86_64-unknown-linux-gnu in libvtv on ENABLE_VTABLE_VERIFY not in AM_CONDITIONAL

[andris.pavenis at iki dot fi]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58348

Andris Pavenis  changed:

   What|Removed |Added

 CC||andris.pavenis at iki dot fi

--- Comment #3 from Andris Pavenis  ---
Also run into the same problem:

Test

if ENABLE_VTABLE_VERIFY

has been removed from libvtv/Makefile.am but not libvtv/testsuite/Makefile.am.

[Bug bootstrap/58340] [4.9 regression] gcc/cp/pt.c:7064:1: internal compiler error: in propagate_threaded_block_debug_into, at tree-ssa-threadedge.c:623

[gerald at pfeifer dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58340

--- Comment #9 from Gerald Pfeifer  ---
(In reply to Jeffrey A. Law from comment #3)
> Just to be sure, what version of the trunk are both of you using?

202346

[Bug regression/58244] global variable: many THOUSANDS times slower execution

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58244

Marc Glisse  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #9 from Marc Glisse  ---
OP said there was no bug.

[Bug ipa/58329] [4.9 Regression] ld: Invalid symbol type for plabel (.libs/libstdc++.lax/libc++11convenience.a/system_error.o, std::error_category::default_error_condition(int) const [clone .localalia

[dave.anglin at bell dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58329

--- Comment #9 from dave.anglin at bell dot net ---
On 6-Sep-13, at 8:05 AM, hubicka at ucw dot cz wrote:

> perhaps we want to simply check for ASM_OUTPUT_DEF in symtab and  
> refuse
> to use local aliases then?  I think the other macros alow only weak  
> aliases.

The attached patch gets past the error.  Testing.

Dave
--
John David Anglindave.ang...@bell.net

[Bug c++/58353] Internal Compiler Error with Variadic Templates

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58353

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
Removing library dependencies and simplifying a bit (The problem seems not
related to contexpr, for example):

template
struct seq_t
{
 template struct seq{};

 template
 struct gen : gen{};

 template
 struct gen<0, Es...> : seq{};

 struct bits_t{ E e[CNT]; };

 template
 static bits_t init(seq) {return {{Es...}};}

 static bits_t init() {return init(gen{});}
};

typedef seq_t wow;

int main()
{
  wow::init();
}

[Bug fortran/58355] New: ICE with TYPE, EXTENDS before parent TYPE defined

[abensonca at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58355

Bug ID: 58355
   Summary: ICE with TYPE, EXTENDS before parent TYPE defined
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com

With gfortran 4.9.0 the following causes an ICE:

module ct
  public :: cfc, cfl, cfde
  type :: cfc
  end type cfc
  type, extends(cfl) :: cfde
  end type cfde
  type, extends(cfc) :: cfl
  end type cfl
end module ct


$ gfortran -v
Using built-in specs.
COLLECT_GCC=/opt/gcc-trunk/bin/gfortran
COLLECT_LTO_WRAPPER=/opt/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/opt/gcc-trunk
--enable-languages=c,c++,fortran --disable-multilib
Thread model: posix
gcc version 4.9.0 20130808 (experimental) (GCC) 

$ gfortran -c bug.F90 -o bug.o
f951: internal compiler error: Segmentation fault
0x97d66f crash_signal
../../gcc-trunk/gcc/toplev.c:335
0x52dec1 check_extended_derived_type
../../gcc-trunk/gcc/fortran/decl.c:7412
0x52dec1 gfc_match_derived_decl()
../../gcc-trunk/gcc/fortran/decl.c:7541
0x5770d9 match_word
../../gcc-trunk/gcc/fortran/parse.c:65
0x578561 decode_statement
../../gcc-trunk/gcc/fortran/parse.c:502
0x5796a4 next_free
../../gcc-trunk/gcc/fortran/parse.c:784
0x5796a4 next_statement
../../gcc-trunk/gcc/fortran/parse.c:977
0x579f34 parse_spec
../../gcc-trunk/gcc/fortran/parse.c:2741
0x57ccf8 parse_module
../../gcc-trunk/gcc/fortran/parse.c:4313
0x57ccf8 gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.c:4625
0x5b8ce5 gfc_be_parse_file
../../gcc-trunk/gcc/fortran/f95-lang.c:189
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

The PUBLIC statement is required for the ICE to happen. switching the order of
the definitions of the "cfde" and "cfl" types results in a success compile.

I can't currently test this with the most recent revision of gfortran due to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58350

[Bug other/58319] explicit cast doesn't disable -Wconversion warning.

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58319

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #4 from Manuel López-Ibáñez  ---
(In reply to Jonathan Wakely from comment #3)
> You can ensure the value is not too large for the target:
> 
> X x = { .field = ( u & (-1u >> 1) ) };

It would be nice if gcc accepted (unsigned int:31) as a valid type when
casting. It would help to avoid other Wconversion warnings. It seems a useful
extension to me. Just throwing out the idea there if someone (like the
reporter) considered to give it a try.

[Bug tree-optimization/18501] [4.7/4.8/4.9 Regression] Missing 'used uninitialized' warning (CCP)

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||tkhai at yandex dot ru

--- Comment #65 from Manuel López-Ibáñez  ---
*** Bug 58323 has been marked as a duplicate of this bug. ***

[Bug c/58323] [-Wall] No warning when uninitialized integer

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58323

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #1 from Manuel López-Ibáñez  ---
99% sure that this is bug 18501

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

[Bug c++/51488] ICE on infinite template recursion

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51488

--- Comment #4 from Manuel López-Ibáñez  ---
(In reply to Paolo Carlini from comment #2)
> Manuel, looks like these 3 testcases are instances of the very same issue:
> our template instantiation depth control mechanism doesn't handle this case.
> I'm attaching below a piece of a stack trace, to show you the infinite
> recursion.
> 
> I seem to remember you did work in this area: any tips to handle this case
> too?

Sorry, no idea. Have you tried using a very small -ftemplate-depth? It crashes
because out of memory or something else?

[Bug bootstrap/58340] [4.9 regression] gcc/cp/pt.c:7064:1: internal compiler error: in propagate_threaded_block_debug_into, at tree-ssa-threadedge.c:623

[law at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58340

--- Comment #10 from Jeffrey A. Law  ---
Zhengong's testcase fails for me, so I'll work with that first.

[Bug c/53119] -Wmissing-braces wrongly warns about universal zero initializer {0}

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119

--- Comment #11 from Manuel López-Ibáñez  ---
(In reply to JamesH from comment #10)
> 
> Therefore, is there any progress on this bug?

I wouldn't expect any soon, unless new developers join GCC development and
decide to work on the C FE. Any takers?

[Bug c++/58336] internal compiler error when using a static int for the size of a char array within a class

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58336

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||4.7.3, 4.8.0, 4.9.0
 Resolution|--- |FIXED

--- Comment #3 from Paolo Carlini  ---
Thanks.

[Bug c++/51488] ICE on infinite template recursion

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51488

--- Comment #5 from Paolo Carlini  ---
Infinite recursion, which nothing stops. In the meanwhile I posted this:
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01348.html

I think those issue should be fixable relatively easily.

[Bug c++/58354] variadic template ambiguous

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58354

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-09-07
 Ever confirmed|0   |1

[Bug bootstrap/58340] [4.9 regression] gcc/cp/pt.c:7064:1: internal compiler error: in propagate_threaded_block_debug_into, at tree-ssa-threadedge.c:623

[law at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58340

--- Comment #11 from Jeffrey A. Law  ---
I've found a minor error in the tree-ssa-threadedge.c changes.  I can easily
see how it affects Zhengong's testcase and I can speculate how it might be
triggering the ia64 failure.

I'm testing it on x86_64-unknown-linux-gnu at the moment.  I'll spin up a test
on ia64 at some point over the weekend as well.

[Bug fortran/58356] New: ICE with finalization and type extension

[abensonca at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58356

Bug ID: 58356
   Summary: ICE with finalization and type extension
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com

The following causes an ICE in gfortran 4.9.0:

module ct
  type :: cfl
   contains
 final :: cfld
  end type cfl
  type, extends(cfl) :: cfde
   contains
  end type cfde
contains
  subroutine cfld(self)
implicit none
type(cfl), intent(inout) :: self
return
  end subroutine cfld
end module ct

$ gfortran -v
Using built-in specs.
COLLECT_GCC=/opt/gcc-trunk/bin/gfortran
COLLECT_LTO_WRAPPER=/opt/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/opt/gcc-trunk
--enable-languages=c,c++,fortran --disable-multilib
Thread model: posix
gcc version 4.9.0 20130808 (experimental) (GCC) 

$ gfortran -c bug.F90 -o bug.o
f951: internal compiler error: Segmentation fault
0x97d66f crash_signal
../../gcc-trunk/gcc/toplev.c:335
0x51dd10 generate_finalization_wrapper
../../gcc-trunk/gcc/fortran/class.c:1950
0x51dd10 gfc_find_derived_vtab(gfc_symbol*)
../../gcc-trunk/gcc/fortran/class.c:2398
0x51fc87 gfc_is_finalizable(gfc_symbol*, gfc_expr**)
../../gcc-trunk/gcc/fortran/class.c:2464
0x5954a7 resolve_fl_derived0
../../gcc-trunk/gcc/fortran/resolve.c:12368
0x594fcf resolve_fl_derived0
../../gcc-trunk/gcc/fortran/resolve.c:11992
0x594fcf resolve_fl_derived0
../../gcc-trunk/gcc/fortran/resolve.c:11980
0x59683f resolve_fl_derived0
../../gcc-trunk/gcc/fortran/resolve.c:12402
0x59683f resolve_fl_derived
../../gcc-trunk/gcc/fortran/resolve.c:12425
0x591559 resolve_symbol
../../gcc-trunk/gcc/fortran/resolve.c:12695
0x5a8133 do_traverse_symtree
../../gcc-trunk/gcc/fortran/symbol.c:3571
0x594582 resolve_types
../../gcc-trunk/gcc/fortran/resolve.c:14400
0x590430 gfc_resolve
../../gcc-trunk/gcc/fortran/resolve.c:14497
0x57d0af gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.c:4645
0x5b8ce5 gfc_be_parse_file
../../gcc-trunk/gcc/fortran/f95-lang.c:189
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

I can't currently test this with the most recent revision of gfortran due to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58350

[Bug libstdc++/58341] Doc conflicts with standard on forbidden range of `result` in copy_backward()

[paolo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58341

--- Comment #4 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Sat Sep  7 22:57:49 2013
New Revision: 202357

URL: http://gcc.gnu.org/viewcvs?rev=202357&root=gcc&view=rev
Log:
2013-09-07  Paolo Carlini  

PR libstdc++/58341
* include/bits/stl_algobase.h (copy_backward): Fix documentation
per DR 1206.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_algobase.h

[Bug libstdc++/58341] Doc conflicts with standard on forbidden range of `result` in copy_backward()

[paolo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58341

--- Comment #5 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Sat Sep  7 22:58:04 2013
New Revision: 202358

URL: http://gcc.gnu.org/viewcvs?rev=202358&root=gcc&view=rev
Log:
2013-09-07  Paolo Carlini  

PR libstdc++/58341
* include/bits/stl_algobase.h (copy_backward): Fix documentation
per DR 1206.

Modified:
branches/gcc-4_8-branch/libstdc++-v3/ChangeLog
branches/gcc-4_8-branch/libstdc++-v3/include/bits/stl_algobase.h

[Bug libstdc++/58341] Doc conflicts with standard on forbidden range of `result` in copy_backward()

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58341

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.8.2

--- Comment #6 from Paolo Carlini  ---
Done for 4.9.0 and 4.8.2.

[Bug c++/58282] g++.dg/tm/noexcept-1.C -fno-exceptions SIGSEGV in gimple_build_eh_must_not_throw

[vries at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58282

--- Comment #6 from vries at gcc dot gnu.org ---
Author: vries
Date: Sat Sep  7 23:31:48 2013
New Revision: 202359

URL: http://gcc.gnu.org/viewcvs?rev=202359&root=gcc&view=rev
Log:
Handle noexcept on transactions with -fno-exceptions

2013-09-08  Tom de Vries  

PR c++/58282
* except.c (build_must_not_throw_expr): Handle
flag_exceptions.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/except.c

[Bug libstdc++/58357] New: In C++11 std::rotate(first, middle, last) now should return a forward iterator to first + (last - middle).

[mhcox at bluezoosoftware dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58357

Bug ID: 58357
   Summary: In C++11 std::rotate(first, middle, last) now should
return a forward iterator to  first + (last - middle).
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mhcox at bluezoosoftware dot com

According to section 25.3.11, the rotate(first, middle, last) algorithm should
return a forward iterator that points to (first + (last - middle)).

Compiled with -std=c++11.

[Bug c++/58282] g++.dg/tm/noexcept-1.C -fno-exceptions SIGSEGV in gimple_build_eh_must_not_throw

[vries at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58282

--- Comment #7 from vries at gcc dot gnu.org ---
Author: vries
Date: Sat Sep  7 23:31:58 2013
New Revision: 202360

URL: http://gcc.gnu.org/viewcvs?rev=202360&root=gcc&view=rev
Log:
Testcase for PR58282

2013-09-08  Tom de Vries  

PR c++/58282
* g++.dg/tm/noexcept-6.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/tm/noexcept-6.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/54659] [4.8 Regression] Bootstrap with --disable-nls broken under Windows

[fragabr at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54659

Dâniel Fraga  changed:

   What|Removed |Added

 CC||fragabr at gmail dot com

--- Comment #30 from Dâniel Fraga  ---
(In reply to Diego Novillo from comment #29)
> Fixed in gcc-4_8-branch at rev 198708 and trunk at rev 198711.

Diego, I'm using gcc 4.8.2 20130905 snapshot and it's generating libstdc++ with
those symbols:

 nm /usr/local/lib64/libstdc++.so.6.0.18|grep libintl
 U libintl_bindtextdomain
 U libintl_gettext
 U libintl_textdomain

 And I get the same problem reported in this bug.

 It started with gcc 4.8.0 and until now my workaround was to add
"LDFLAGS=-lintl" when I compile some software.

So I'm afraid this bug still exist or it was reintroduced at some point.

Is there any test I can do for you?

Thank you.

[Bug libstdc++/58358] New: search_n has a Complexxity violation for random access iterator

[kariya_mitsuru at hotmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358

Bug ID: 58358
   Summary: search_n has a Complexxity violation for random access
iterator
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kariya_mitsuru at hotmail dot com

Following code should print less than or equal to 11, but it prints 20.

#include 
#include 
#include 

int main()
{
  std::vector a{2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1};
  int count = 0;
  std::search_n(a.begin(), a.end(), 10, 1, [&count](int t, int u){ ++count;
return t == u; });
  std::cout << count << std::endl;
}

[Bug libstdc++/58358] search_n has a Complexity violation for random access iterator

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358

Marc Glisse  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-09-08
 Ever confirmed|0   |1

--- Comment #1 from Marc Glisse  ---
The indexes of the values that are tested:
9 8 7 6 5 4 3 2 1 0 10 9 8 7 6 5 4 3 2 1

It starts well, first checking 9 because if that one fails we can skip testing
0-8. The backtrack is normal. Once the backtracking fails, the code jumps to a
sensible place (so that backtracking will go precisely to the last place before
we failed) but it forgets that it has already tested many of those values.