[Bug libstdc++/63199] New: Inserting std::wregex to std::vector looses some std::wregex values

2014-09-07 Thread stefan at schweter dot it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63199

Bug ID: 63199
   Summary: Inserting std::wregex to std::vector looses some
std::wregex values
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefan at schweter dot it

Created attachment 33456
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33456action=edit
Example program

Hi,

using GCC 4.9.1 I can reproduce a strange behavior with inserting
std::wregex values to a std::vector.

I'm using a loop which creates some std::wregex with imbuing and assigning.

After compiling and executing the program code, a core dump is returned.
Having a deeper look with gdb into the std::vector I can see, that only
the half of the std::wregex values have been properly inserted - see
the _M_original_str variable.

Used GCC:

[root@098bff401751 /]# LC_MESSAGES=C g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc/src/gcc-4.9.1/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
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-cloog-backend=isl --disable-isl-version-check
--disable-cloog-version-check --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu --disable-multilib
--disable-werror --enable-checking=release
Thread model: posix
gcc version 4.9.1 (GCC)


I compiled the program with:

g++ -g -std=c++11 std_regex.cpp

I also attached the example code and the gdb trace for the used regex_vector.


[Bug libstdc++/63199] Inserting std::wregex to std::vector looses some std::wregex values

2014-09-07 Thread stefan at schweter dot it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63199

--- Comment #1 from Stefan Schweter stefan at schweter dot it ---
Created attachment 33457
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33457action=edit
GDB trace for regex_vectpr


[Bug c++/62268] New: ICE: segmentation fault with Boost.Asio 1.55

2014-08-26 Thread stefan at schweter dot it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62268

Bug ID: 62268
   Summary: ICE: segmentation fault with Boost.Asio 1.55
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefan at schweter dot it

Hi,

I'm using GCC 5 (on Debian Testing):

g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /usr/src/gcc/configure --disable-multilib
--enable-languages=c,c++
Thread model: posix
gcc version 5.0.0 20140826 (experimental) (GCC)

Boost version is 1.55.

When compiling this code with g++ -std=c++11 or g++ -lboost_system:

#include boost/asio.hpp

int main()
{
return 0;
}

An ICE occurs:

test1.cpp:6:1: internal compiler error: Segmentation fault
 }
 ^

Can anyone confirm this error?


Thanks in advance + regards,

Stefan


[Bug c++/46476] Missing Warning about unreachable code after return

2014-02-25 Thread stefan at schweter dot it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46476

Stefan stefan at schweter dot it changed:

   What|Removed |Added

 CC||stefan at schweter dot it

--- Comment #3 from Stefan stefan at schweter dot it ---
As the *-Wunreachable-code* was removed, why isn't there any *deprecated*
message or *warning* shown to the user, when using this option? That leads to
the illusion *-Wunreachable-code* is working - which is obviously not the
case.