https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67015
--- Comment #2 from Roger Leigh ---
Note regex2.cc fails with 4.9.2 but not with 4.9.3 or 5.1, so this appear to
have been fixed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61059
--- Comment #3 from Roger Leigh ---
Thanks for the clarification.
Just for reference for anyone else running into this behaviour:
clang++3.3: compiles and runs
VS2012: compiles and throws regex_error
VS2013: compiles and throws regex_error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53631
--- Comment #9 from Roger Leigh ---
It would be better if did not exist at all until functional. If I do
regular autoconf header checks, plus a check to make sure that the needed types
can be instantiated, then these all succeed despite it being
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52719
--- Comment #4 from Roger Leigh 2012-03-26 08:37:10
UTC ---
I left the priority as "normal", but if this is generally reproducible, and not
a failure on my part, it would mean that std::regex is quite unusable in its
current form.
Thanks,
Roger
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52719
--- Comment #3 from Roger Leigh 2012-03-26 08:31:48
UTC ---
Created attachment 26994
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26994
Machine and compiler specs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52719
--- Comment #2 from Roger Leigh 2012-03-26 08:31:09
UTC ---
Created attachment 26993
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26993
Preprocessed std::regex source (g++ -E)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52719
--- Comment #1 from Roger Leigh 2012-03-26 08:29:23
UTC ---
Created attachment 26992
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26992
Failing code using std::regex
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52719
Bug #: 52719
Summary: C++11 std::regex is broken compiling simple regular
expressions
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
--- Comment #7 from rleigh at debian dot org 2009-07-28 23:15 ---
Ah, so it's a defect in the actual C++ standard rather than GCC?
I was somewhat confused because while this fails:
psess = this->chroot->get_facet();
splitting it into its component parts always succeeds:
--- Comment #6 from rleigh at debian dot org 2009-07-28 23:03 ---
Created an attachment (id=18264)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18264&action=view)
Preprocessed source for g++-4.5.0 (svn 149777)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40897
--- Comment #4 from rleigh at debian dot org 2009-07-28 23:02 ---
Created an attachment (id=18263)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18263&action=view)
Preprocessed source for g++-4.4.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40897
--- Comment #3 from rleigh at debian dot org 2009-07-28 23:02 ---
Created an attachment (id=18262)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18262&action=view)
Preprocessed source for g++-4.3.3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40897
--- Comment #2 from rleigh at debian dot org 2009-07-28 23:00 ---
Yes, the class for the this pointer is a template:
template
class test_chroot_base : public TestFixture
Adding template as you suggest
psess = this->chroot->template get_facet();
does allow the source to c
; '-save-temps' '-DHAVE_CONFIG_H' '-I.' '-I..'
'-I../sbuild' '-I..' '-I/usr/include/uuid' '-DTESTDATADIR="./testdata"'
'-I../bin' '-pthread' '-pedantic' '-Wall' '-Wcast-
--- Comment #10 from rleigh at debian dot org 2007-05-07 13:04 ---
Also fails with GCC 4.1.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14258
everity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rleigh at debian dot org
GCC build triplet: powerpc-linux-gnu
GCC host triplet: powerpc-linux-gnu
GCC target triplet: powerpc-linux-gnu
http://gcc.gnu.org/bugzil
--- Comment #2 from rleigh at debian dot org 2006-06-24 19:21 ---
Sorry, the testcase is broken. This isn't a bug.
--
rleigh at debian dot org changed:
What|Removed |
--- Comment #1 from rleigh at debian dot org 2006-06-24 19:16 ---
Created an attachment (id=11741)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11741&action=view)
Test codecvt roundtrip from narrow->wide->narrow.
Testcase.
--
http://gcc.gnu.org/bugzilla/sh
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rleigh at debian dot org
GCC build triplet: powerpc-linux-gnu
GCC host triplet: powerpc-linux-gnu
GCC target triplet: powerpc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28155
--- Comment #26 from rleigh at debian dot org 2006-06-18 09:51 ---
Thiemo Seufer diagnosed this as a problem with the testcases: mbstate_t needs
explictly initialising to all-bits-zero with memset. After doing this
std::memset(&state, 0, sizeof(mbstate_t));
all the testcases
--- Comment #24 from rleigh at debian dot org 2006-06-18 00:27 ---
../gcc-20060613/configure --enable-languages=c,c++
--prefix=/home/rleigh/gcc-test --enable-shared --with-system-zlib
--without-included-gettext --enable-threads=posix --enable-nls
--enable-__cxa_atexit --enable
--- Comment #23 from rleigh at debian dot org 2006-06-17 14:29 ---
This will take a few more hours. I didn't have a built GCC tree to hand, so
I'm still waiting on "make bootstrap".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28059
--- Comment #22 from rleigh at debian dot org 2006-06-16 18:19 ---
Just to summarise the current tests:
wide wide2 wide3
GCC ver ppc i386 ppc i386 ppc i386
3.4OK OKOK OKOK fail
4.0fail OKOK fail OK fail
4.1fail OK
--- Comment #20 from rleigh at debian dot org 2006-06-16 17:28 ---
> Before I go completely crazy, let's agree at least about a detail:
> let's not involve 3.3: in 3.3 codecvt is known to be broken and was
> completely rewritten for 3.4.
Agreed :)
--
http://g
--- Comment #19 from rleigh at debian dot org 2006-06-16 17:26 ---
Created an attachment (id=11683)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11683&action=view)
C example using mbsnrtowcs
This testcase is the same as the last, but uses C only.
It looks like this:
--- Comment #17 from rleigh at debian dot org 2006-06-16 16:59 ---
Created an attachment (id=11682)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11682&action=view)
Use mbsnrtowcs directly.
This testcase is similar to the original, with the exception that it uses
mbsnrt
--- Comment #15 from rleigh at debian dot org 2006-06-16 16:16 ---
$ uname -a
Linux hardknott 2.6.16.17 #7 Sun May 21 15:39:23 BST 2006 ppc GNU/Linux
$ /lib/libc.so.6
GNU C Library stable release version 2.3.6, by Roland McGrath et al.
Copyright (C) 2005 Free Software Foundation, Inc
--- Comment #12 from rleigh at debian dot org 2006-06-16 14:39 ---
Testing on i486-linux-gnu, the results are:
3.3: fail
3.4: OK
4.0: OK
4.1: OK
4.2 snapshot: OK
So 4.0, 4.1 and 4.2 snapshot are OK on i486-linux-gnu but not on
powerpc-linux-gnu.
--
http://gcc.gnu.org/bugzilla
--- Comment #10 from rleigh at debian dot org 2006-06-16 14:20 ---
Yes, this is all on the same Debian installation. 3.3, 3.4, 4.0, 4.1 and 4.2
(snapshot) are available. All but 3.4 exhibit this problem.
I will test on an i686 system in a moment to check if it's powerpc
--- Comment #6 from rleigh at debian dot org 2006-06-16 13:59 ---
en_US.UTF-8 doesn't work for me either.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28059
--- Comment #5 from rleigh at debian dot org 2006-06-16 13:57 ---
$ g++ --version
g++ (GCC) 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)
$ g++ -o wide wide.cc
$ time ./wide
wide: ../iconv/loop.c:425: utf8_internal_loop_single: Assertion `inptr -
bytebuf > (state->__count &
--- Comment #3 from rleigh at debian dot org 2006-06-16 13:41 ---
The source is UTF-8 encoded, and it assumes you are going to run it in a UTF-8
locale. That might possibly be why you get odd output.
The expected output should be as per the GCC 3.4 output in the original report:
$ g
--- Comment #1 from rleigh at debian dot org 2006-06-16 13:09 ---
Created an attachment (id=11679)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11679&action=view)
Testcase to show codecvt crash
Compile with
g++ -o wide wide.cc
--
http://gcc.gnu.org/bugzilla/show_bug
ible crash)
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rleigh at debian dot org
GCC build triplet: powerpc-linux-gn
--- Comment #3 from rleigh at debian dot org 2006-01-03 23:49 ---
Looking at _M_cfile_created as you suggested, it does look like the
documentation is correct as it stands.
Sorry for the waste of time.
Thanks,
Roger
--
rleigh at debian dot org changed:
What
--- Comment #1 from rleigh at debian dot org 2006-01-03 20:52 ---
On further investigation, it looks like when a stdio_filebuf is destroyed, this
will ultimately invoke __basic_file::close(). This calls fclose(). If
an fd is used, fdopen() is called to create a __c_file*.
If this is
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rleigh at debian dot org
GCC build triplet: powerpc-linux-gnu
GCC host triplet: powerpc-linux-gnu
GCC target triplet: powerpc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25653
--- Comment #5 from rleigh at debian dot org 2006-01-02 00:06 ---
I've tested on hppa-linux-gnu and ia64-linux-gnu in addition to
powerpc-linux-gnu. All show identical behaviour, so this doesn't look
arch-specific.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25625
--- Comment #3 from rleigh at debian dot org 2006-01-01 18:16 ---
This is the original report, in Debian Bug #345550:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345550
This contains all the information already filed here, so this is just for the
record.
--
rleigh at debian
--- Comment #2 from rleigh at debian dot org 2006-01-01 18:03 ---
Created an attachment (id=10574)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10574&action=view)
Preprocessed source
This is the result of running
g++ -frepo -save-temps -c test.cc
--
http://gcc.
--- Comment #1 from rleigh at debian dot org 2006-01-01 18:00 ---
Created an attachment (id=10573)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10573&action=view)
Testcase
This requires the Boost format library (Boost.Format).
--
http://gcc.gnu.org/bugzilla/show_bug
iority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rleigh at debian dot org
GCC build triplet: powerpc-unknown-linux-gnu
GCC host triplet: powerpc-unknown-linux-gnu
GCC target triplet: powerpc-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25625
--- Additional Comments From rleigh at debian dot org 2004-11-29 23:50
---
Sorry about the renaming.
Even though you aren't supposed to intermix std::cout and std::wcout, surely it
would be nicer if the undefined behaviour was the same whichever you used first?
Currently:
std:
--- Additional Comments From rleigh at debian dot org 2004-11-29 22:38
---
I've done a little more investigation, and I've found out some more. It's no
longer related to date formatting, so I changed the bug title.
Here's a C program to test wide character output:
--- Additional Comments From rleigh at debian dot org 2004-11-26 13:52
---
Thanks for the fast response!
I guess how wchar_t output works is implementation-defined, but I'll check up on
how it should work--it's probably working entirely correctly.
Many thanks,
Roger
--- Additional Comments From rleigh at debian dot org 2004-11-26 12:13
---
Yes, I'm using 3.4.3 (and glibc-2.3.2.ds1-18). With respect to the comparisons,
I've now added wcsftime() to the test, and it /does/ match
std::time_put:
$ LANG=ru_RU.UTF-8 LC_ALL=ru_RU.UTF-8 ./dat
46 matches
Mail list logo
