[Bug c++/39993] New: missing diagnostic on conflicting exception specifications
As mentioned in this post:
http://gcc.gnu.org/ml/libstdc++/2009-05/msg0.html
gcc accepts the ill-formed code below. According to [except.spec], p2:
If any declaration of a function has an exception-specification,
all declarations, including the definition and an explicit
specialization, of that function shall have an exception-
specification with the same set of type-ids.
$ cat t.cpp g++ -c -Wall -Wextra -pedantic t.cpp echo FAIL
extern C void abort(void);
namespace std {
extern C void abort(void) throw();
}
namespace std {
extern C void abort(void) throw();
}
extern C void abort(void);
FAIL
See also bug 32081 and bug 24817 for similar problems in template code.
--
Summary: missing diagnostic on conflicting exception
specifications
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39993
[Bug c++/35722] [C++0x] Variadic templates expansion into non-variadic class template
--- Comment #5 from sebor at roguewave dot com 2009-04-05 14:20 --- (In reply to comment #4) The change was introduced in N2622: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2622.pdf I couldn't find a rationale for the change. Doug might remember -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35722
[Bug c++/39653] New: error referencing a more specialized variadic template from primary
I believe the following program is well-formed but gcc rejects it with
the same error as the one discussed in bug 35722. I'm opening this as
a separate bug since unlike in bug 35722, the referenced template is
variadic.
$ cat t.C g++ --version g++ -std=c++0x t.C
template class T, class ...Types
struct S {
typedef typename STypes...::type type;
};
template class T
struct ST { typedef T type; };
g++ (GCC) 4.5.0 20090404 (experimental)
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
t.C:3: sorry, unimplemented: cannot expand Types ... into a fixed-length
argument list
--
Summary: error referencing a more specialized variadic template
from primary
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39653
[Bug c++/35722] [C++0x] Variadic templates expansion into non-variadic class template
--- Comment #6 from sebor at roguewave dot com 2009-04-05 17:12 --- See also bug 39642 and bug 39653. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35722
[Bug c++/39637] New: ICE on ill-formed sizeof(parameter-pack) in variadic template
gcc 4.3.2 fails with an ICE on the following ill-formed program. A fairly
recent (but not the most recent) version of 4.4 also fails.
$ cat t.C g++ -dumpversion g++ t.C -std=c++0x
template class... Types
void f (Types...)
{
enum { e = sizeof (Types) };
};
int main ()
{
f (0);
}
4.3.2
t.C: In function void f(Types ...) [with Types = int]:
t.C:9: instantiated from here
t.C:4: internal compiler error: in dependent_type_p, at cp/pt.c:15758
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugzilla.redhat.com/bugzilla for instructions.
Preprocessed source stored into /tmp/cca3TXk5.out file, please attach this to
your bugreport.
$ g++ -v g++ t.C
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /home/sebor/gcc/trunk/configure
--prefix=/build/sebor/bin/gcc-4.4.0 --enable-languages=c,c++
--with-mpfr=/usr/local/mpfr-2.3.1
Thread model: posix
gcc version 4.4.0 20081105 (experimental) (GCC)
t.C:1: warning: variadic templates only available with -std=c++0x or
-std=gnu++0x
t.C:2: warning: variadic templates only available with -std=c++0x or
-std=gnu++0x
t.C: In function void f(Types ...) [with Types = int]:
t.C:9: instantiated from here
t.C:4: internal compiler error: in dependent_type_p, at cp/pt.c:15922
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--
Summary: ICE on ill-formed sizeof(parameter-pack) in variadic
template
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39637
[Bug c++/39639] New: no diagnostic for ill-formed pack expansion
gcc 4.3.2 and a recent pull of 4.4 accept the following (presumably) ill-formed
program:
$ cat t.C g++ -v g++ -std=c++0x t.C ./a.out
#include cstdio
template class... Types
struct S: S...Types, S...Types..., S...
{
static const char* f () { return __PRETTY_FUNCTION__; }
};
int main ()
{
std::puts (Svoid::f ());
}
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /home/sebor/gcc/trunk/configure
--prefix=/build/sebor/bin/gcc-4.4.0 --enable-languages=c,c++
--with-mpfr=/usr/local/mpfr-2.3.1
Thread model: posix
gcc version 4.4.0 20081105 (experimental) (GCC)
static const char* STypes::f() [with Types = void]
--
Summary: no diagnostic for ill-formed pack expansion
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39639
[Bug c++/39642] [C++0x] Unimplemented variadic template type expansion
--- Comment #1 from sebor at roguewave dot com 2009-04-04 23:05 --- FWIW, I just happened to run into the same error while doing some work on std::tuple. IIUC, the error is due to bug 35722. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39642
[Bug c++/39219] attribute doesn't work with enums properly
--- Comment #6 from sebor at roguewave dot com 2009-02-18 16:50 ---
(In reply to comment #5)
Should attribute work on enum constants?
Not sure if this is a question for me but IMO, it should. I would expect
individual enumerators to be more heavily referenced than their types
(sometimes even exclusively) and the warning to be of equal importance
for both. In addition, just like declaring a class deprecated implies
that all members of the class are deprecated, so should declaring
an enumeration deprecated imply that all its enumerators are.
Finally, since enumerators of unnamed types can be declared deprecated
not issuing the warning would make such declarations pointless:
$ cat u.cpp g++ -W -Wall -Werror -c u.cpp
enum __attribute__((deprecated)) { e };
int i = e; // warning missing
$
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39219
[Bug c++/39205] Warning when object syntax is used to call a static member function
--- Comment #5 from sebor at roguewave dot com 2009-02-17 15:48 --- (In reply to comment #0) I can't think of a scenario where one would want to write x.f() over X::f() when f() is static. I'd like a warning for this so I can catch with -Werror. FWIW, I've seen x.y when y is a static data member of x in cases such as: extern std::ostream x; x.setf (x.showpos); i.e., instead of spelling showpos as std::ios::showpos. I can envision similar cases where y is a static member function of the class, such as std::ios::sync_with_stdio(): x.sync_with_stdio (false); While I appreciate the desire to find such cases I'm not sure a warning is the appropriate mechanism. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39205
[Bug c++/39219] New: attribute deprecated doesn't work with enums
According to the documentation:
The deprecated attribute results in a warning if the type is used anywhere
in the source file.
The following test case shows that when applied to an enum definition the
attribute has no such effect (this is in contrast to applying the attribute
to a class definition where it does have the expected effect):
$ cat -n u.cpp g++ -dumpversion g++ -W -Wall -Werror -c u.cpp; echo $?
1 enum __attribute__ ((deprecated)) E { e };
2 struct S { enum __attribute__ ((deprecated)) F { f = e }; };
3
4 int main () {
5 E x;
6 x = e;
7
8 S::F y;
9 y = S::f;
10
11 return x + y;
12 }
4.3.1
0
--
Summary: attribute deprecated doesn't work with enums
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39219
[Bug c++/39219] attribute doesn't work with enums properly
--- Comment #4 from sebor at roguewave dot com 2009-02-17 21:00 ---
Thanks for looking into so quickly!
In addition to the missing warnings mentioned in the initial report I would
expect a warning for each of the references to e below (i.e., on lines 3, 9,
and 15), analogously to those already issued:
$ cat -n u.cpp g++ -W -Wall -Werror -c u.cpp; echo $?
1 struct A {
2 enum __attribute__ ((deprecated)) E { e };
3 enum F { f = e }; // missing warning
4 static const E g = e; // missing warning
5 };
6
7 struct B {
8 enum E { e } __attribute__ ((deprecated));
9 enum F { f = e }; // missing warning
10 static const E g = e;
11 };
12
13 struct C {
14 typedef enum { e } E __attribute__ ((deprecated));
15 enum F { f = e }; // missing warning
16 static const E g = e;
17 };
cc1plus: warnings being treated as errors
u.cpp:10: error: 'E' is deprecated (declared at u.cpp:8)
u.cpp:16: error: 'C::E' is deprecated (declared at u.cpp:14)
1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39219
[Bug libstdc++/39168] Incorrect interpretation of CHAR_MAX inside grouping string in monetary and numeric facets.
--- Comment #17 from sebor at roguewave dot com 2009-02-14 21:21 --- Created an attachment (id=17300) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17300action=view) Unified money_get and num_get test case and results. Attached is a unified test case with test results on popular platforms. The assertions reflect the behavior described in comment #4 which may actually turn out to be incorrect in the end. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39168
[Bug libstdc++/39168] Incorrect interpretation of CHAR_MAX inside grouping string in monetary and numeric facets.
--- Comment #18 from sebor at roguewave dot com 2009-02-14 21:41 --- I was too hasty -- the attached test case is buggy: it's missing a seek to the beginning of the stream after the first extraction, making the results for the num_get part meaningless. (In reply to comment #7) Arbitrary length is not quite correct here - 123,456 violates grouping, given with string(1, CHAR_MAX). Standard use term unlimited length, which means(as I understand) that all other digits should incorporate in only one group - only 123456 is correct. That seems like a reasonable interpretation but others appear to be possible as well. Looks like this needs to be clarified. (In reply to comment #12) Let's consider the following situation (seems lifelike to me). Suppose one needs a representation of numbers in which only the last 3 digits are separated from all other digits (grouped), like 1234,567 or 1234567,890. Other separators shouldn't appear. It seems that \003\000 should do that, and unless I'm mistaken, does with libstc++ (but not other implementations). (In reply to comment #13) POSIX seems a good point, probably you should have mentioned it much earlier. Let's hear Martin again, then. Certainly, however, I'm concerned about having a behavior different from all the other implementations mentioned by Martin. I agree. It would be good to reconcile any accidental differences between C++ and POSIX. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39168
[Bug libstdc++/39168] Incorrect interpretation of CHAR_MAX inside grouping string in monetary and numeric facets.
--- Comment #20 from sebor at roguewave dot com 2009-02-14 21:58 --- Created an attachment (id=17301) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17301action=view) Corrected unified demo. Attached a corrected unified demo with assertions removed and with output on popular implementations for reference. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39168
[Bug libstdc++/39168] Incorrect interpretation of CHAR_MAX inside grouping string in monetary and numeric facets.
--- Comment #4 from sebor at roguewave dot com 2009-02-12 16:49 --- (In reply to comment #0) I'm not sure I understand your rationale or I agree that this is a bug. IIUC, string(1, CHAR_MAX) indicates that groups may be of arbitrary length, which includes 123,456 This behavior is the same regardless of whether char is a signed or unsigned type. As a data point WRT existing practice: all implementations I've tried (Apache stdcxx on HP-UX/IPF, HP aCC 6.16, Sun C++ 5.9 with both libCstd and STLport, and IBM XLC++ 9.1) behave the same as libstdc++: they extract 123456 from the stream and set eofbit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39168
[Bug c++/39159] unhelpful attribute warning on matching declaration after definition
--- Comment #1 from sebor at roguewave dot com 2009-02-12 17:02 ---
In addition, as the test case below shows, the warning is issued inconsistently
between classes and functions, suggesting that the instance of the warning on
the class declaration on line 2 might be a bug rather than a feature:
$ cat -n t.C g++ -dumpversion g++ -c t.C
1 struct __attribute__ ((visibility (default))) A { };
2 struct __attribute__ ((visibility (default))) A;
3
4 void __attribute__ ((visibility (default))) foo () { }
5 void __attribute__ ((visibility (default))) foo ();
4.3.1
t.C:2: warning: type attributes ignored after type is already defined
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39159
[Bug c++/39159] New: unhelpful attribute warning on matching declaration after definition
gcc 4.3 issues a warning for the declaration of struct A below despite the
attribute on the declaration being consistent with that on the definition and
thus benign. While the warning is valuable in cases where the attributes
between the declaration and the definition do not match, it is not useful in
benign cases such as the one below. In these cases the warning makes applying
the attribute difficult in existing C++ libraries that rely heavily but not
completely on forward declarations and that also already make use of the Visual
C++ __declspec(dllexport) feature or the Sun C++ __global or __protected
specifiers, neither of which warns about such benign cases.
$ cat t.C g++ -c t.C
struct __attribute__ ((visibility (default))) A { };
struct __attribute__ ((visibility (default))) A;
t.C:2: warning: type attributes ignored after type is already defined
--
Summary: unhelpful attribute warning on matching declaration
after definition
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39159
[Bug c++/38980] New: missing -Wformat warning on const char format string
When compiled with gcc 3.4.6 with -m32 on x86_64 Linux the compiler flags lines
7, 10, and 13 as expected. But when compiled with gcc 4.3.1, only line 7 is
diagnosed.
$ cat -n t.cpp g++ -dumpversion g++ -Wformat -m32 -c t.cpp
1 #include stdio.h
2
3 void foo (size_t n)
4 {
5 char buf [32];
6
7 sprintf (buf, % l u, n);
8
9 static const char fmt0[] = % l u;
10 sprintf (buf, fmt0, n);
11
12 const char fmt1[] = % l u;
13 sprintf (buf, fmt1, n);
14
15 static char fmt2[] = % l u;
16 sprintf (buf, fmt2, n);
17
18 char fmt3[] = % l u;
19 sprintf (buf, fmt3, n);
20 }
3.4.6
t.cpp: In function `void foo(size_t)':
t.cpp:7: warning: long unsigned int format, size_t arg (arg 3)
t.cpp:10: warning: long unsigned int format, size_t arg (arg 3)
t.cpp:13: warning: long unsigned int format, size_t arg (arg 3)
$
$ g++ -dumpversion g++ -Wformat -m32 -c t.cpp
4.3.1
t.cpp: In function 'void foo(size_t)':
t.cpp:7: warning: format '%lu' expects type 'long unsigned int', but argument 3
has type 'size_t'
$
--
Summary: missing -Wformat warning on const char format string
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38980
[Bug libstdc++/38741] Unable to write data to wofstream
--- Comment #12 from sebor at roguewave dot com 2009-01-09 16:57 --- (In reply to comment #3) Created an attachment (id=17044) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17044action=view) [edit] As others have mentioned, the codecvt facet in your test case is broken. The standard allows the codecvt::do_in() and do_out() members to return noconv only when both intern_type and extern_type are the same type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38741
[Bug other/37405] syntax error on __wur in include-fixed/sys/stat.h
--- Comment #2 from sebor at roguewave dot com 2009-01-04 22:37 --- Some additional background on the problem: it's likely that the gcc binary used to reproduce the problem on Red Hat Enterprise Linux AS release 4 has been configured and built on SUSE Linux Enterprise Server 10. Should this be expected to work? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37405
[Bug libstdc++/38476] SIGSEGV on istream::read() in unbuffered mode
--- Comment #3 from sebor at roguewave dot com 2008-12-30 20:08 --- Quoting [lib.istream], p2: Both [formatted and unformatted] input functions are described as if they obtain (or extract) input characters by calling rdbuf()-sbumpc() or rdbuf()-sgetc(). They may use other public members of istream. sgetc() is required to return the result of underflow(), while sbumpc() is required to return the result of uflow() (there's no requirement to actually call either of these virtual functions, i.e., no Effects clause, but that's a defect in the spec). The submitted test case assumes that read() calls rdbuf()-sgetc() rather than sbumpc() which could be argued makes it invalid. An implementation of istream::read() may call streambuf::xsgetn() but it must avoid calling an xsgetn() overridden in a derived class. Let me open a separate issue for this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38476
[Bug c++/38677] New: extern template declaration accepted after explicit instantiation
gcc 4.3.1 fails to diagnose the following ill-formed program:
template class T struct S { T foo (); };
template class T T ST::foo () { return T (); }
template struct Sint;
extern template struct Sint;
int main () { return Sint().foo (); }
See the discussion thread below for more detail:
John H. Spicer wrote:
On Dec 30, 2008, at 2:10 PM, Martin Sebor wrote:
To: C++ core language mailing list
Message c++std-core-13732
The discussion on the subject of extern template and vtables
reminded me of the case below that still passes with at least
one recent compiler and fails with another and which I'm still
not sure is intended to be well-formed or not. I'm hoping this
is a good time to revisit it and get the issue settled.
14.7.2p10 says:
If an entity is the subject of both an explicit instantiation
declaration and an explicit instantiation definition
in the same translation unit, the definition shall follow the declaration.
This makes your example ill-formed.
John Spicer
Edison Design Group
Thanks!
Martin
Martin Sebor wrote:
To: C++ core language mailing list
Message c++std-core-11080
The following piece of code compiles successfully with 2 compilers
and fails with 2 others. I can't tell from N1448 whether it was
intended to be well-formed or (if so) what the expected behavior
should be. Could someone clarify?
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1448.pdf
Thanks in advance!
Martin
template class T struct S { T foo (); };
template class T T ST::foo () { return T (); };
template struct Sint;
extern template struct Sint;
int main () { return Sint().foo (); }
--
Summary: extern template declaration accepted after explicit
instantiation
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38677
[Bug libstdc++/38678] New: istream::read() calls streambuf::xsgetn()
As mentioned in bug 38476, [lib.istream], p2 specifies that:
Both [formatted and unformatted] input functions are described as if
they obtain (or extract) input characters by calling rdbuf()-sbumpc()
or rdbuf()-sgetc(). They may use other public members of istream.
sgetc() is required to return the result of underflow() and sbumpc() is
required to return the result of uflow(). An implementation of
istream::read() may call streambuf::xsgetn() but it must do so in a way
that achieves the as if effect described above. Notably, it must avoid
calling an xsgetn() overridden in a derived class. The test case below
shows that the gcc implementation fails to do so.
$ cat z.cpp g++ z.cpp ./a.out
#include cassert
#include istream
#include streambuf
int main ()
{
static int x = '0';
struct: std::streambuf {
char c;
int_type underflow () {
c = x++;
setg (c, c, c + 1);
return c;
}
std::streamsize xsgetn (char*, std::streamsize) {
assert (!xsgetn should not be called);
return 0;
}
} sb;
std::istream in (sb);
char s [4] = ;
in.read (s, sizeof s);
assert (in.good ());
assert (sizeof s == in.gcount ());
assert ('0' == s [0] '1' == s [1] '2' == s [2] '3' == s [3]);
}
a.out: z.cpp:19: virtual std::streamsize main()::anonymous
struct::xsgetn(char*, std::streamsize): Assertion `!xsgetn should not be
called' failed.
Aborted
--
Summary: istream::read() calls streambuf::xsgetn()
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38678
[Bug c++/38658] New: inefficient code on trivial try/catch statement
I would expect a C++ compiler to generate optimal and equivalently efficient
code for both of the functions below. gcc 4.3 generates much worse code for
bar() than for foo() even at -O3.
int foo () { return 1; }
int bar () { try { throw 1; } catch (int i) { return i; } }
--
Summary: inefficient code on trivial try/catch statement
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38658
[Bug libstdc++/38476] New: SIGSEGV on istream::read() in unbuffered mode
When compiled with gcc 4.3.1 the program below fails with SIGSEGV:
$ cat z.cpp g++ z.cpp ./a.out
#include cassert
#include istream
#include streambuf
int main ()
{
static int x = '0';
struct: std::streambuf {
// unbuffered, always successfully reads one character
int_type underflow () { return x++; }
} sb;
// endless stream that never reaches EOF
std::istream endless (sb);
char s [4] = ;
endless.read (s, sizeof s);
// expect to extract as many characters as requested
assert (endless.good ());
assert (sizeof s == endless.gcount ());
assert ('0' == s [0] '1' == s [1] '2' == s [2] '3' == s [3]);
}
Segmentation fault
--
Summary: SIGSEGV on istream::read() in unbuffered mode
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38476
[Bug c/38126] New: suboptimal code for (a b || !a !b)
I would expect gcc to generate comparable code for both functions below, or
perhaps even better code for foo() than for bar() since the code in foo() is
likely to be more common than the equivalent code in bar(). However, the code
produced for foo() is suboptimal in comparison to the code for bar(). In my
timings on x86 with gcc 4.3.0 at -O2, foo() appears to run about 5% slower than
bar().
$ cat t.c gcc -S -O2 t.c cat t.s
int foo (int *a, int *b) { return a b || !a !b; }
int bar (int *a, int *b) { return !!a == !!b; }
.file t.c
.text
.p2align 4,,15
.globl foo
.type foo, @function
foo:
.LFB2:
testq %rdi, %rdi
je .L2
testq %rsi, %rsi
movl$1, %eax
je .L2
rep
ret
.p2align 4,,10
.p2align 3
.L2:
testq %rdi, %rdi
sete%al
testq %rsi, %rsi
sete%dl
andl%edx, %eax
movzbl %al, %eax
ret
.LFE2:
.size foo, .-foo
.p2align 4,,15
.globl bar
.type bar, @function
bar:
.LFB3:
testq %rdi, %rdi
sete%al
testq %rsi, %rsi
setne %dl
xorl%edx, %eax
movzbl %al, %eax
ret
.LFE3:
.size bar, .-bar
.section.eh_frame,a,@progbits
.Lframe1:
.long .LECIE1-.LSCIE1
.LSCIE1:
.long 0x0
.byte 0x1
.string zR
.uleb128 0x1
.sleb128 -8
.byte 0x10
.uleb128 0x1
.byte 0x3
.byte 0xc
.uleb128 0x7
.uleb128 0x8
.byte 0x90
.uleb128 0x1
.align 8
.LECIE1:
.LSFDE1:
.long .LEFDE1-.LASFDE1
.LASFDE1:
.long .LASFDE1-.Lframe1
.long .LFB2
.long .LFE2-.LFB2
.uleb128 0x0
.align 8
.LEFDE1:
.LSFDE3:
.long .LEFDE3-.LASFDE3
.LASFDE3:
.long .LASFDE3-.Lframe1
.long .LFB3
.long .LFE3-.LFB3
.uleb128 0x0
.align 8
.LEFDE3:
.ident GCC: (GNU) 4.3.0 20080428 (Red Hat 4.3.0-8)
.section.note.GNU-stack,,@progbits
--
Summary: suboptimal code for (a b || !a !b)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38126
[Bug c++/37404] New: ICE on va_arg and template deduction
gcc 4.3.1 gets an ICE on the program below. I didn't try 4.3.2 or 4.4.0.
$ cat t.C gcc t.C
#include stdarg.h
#include string.h
const char* foobar (void*) { return 0; }
template class struct S { static const char* foo () { return 0; } };
template class T, int N
struct ST [N] { static const char* foo () { return foobar (T ()); } };
int main () {
va_list va;
memset (va, 0, sizeof va);
Sva_list::foo ();
}
t.C: In static member function 'static const char* ST [N]::foo() [with T =
__va_list_tag, int N = 1]':
t.C:14: instantiated from here
t.C:8: internal compiler error: in build_special_member_call, at cp/call.c:5325
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--
Summary: ICE on va_arg and template deduction
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37404
[Bug c++/37405] New: syntax error on __wur in include-fixed/sys/stat.h
Here's an odd error I just ran into. The source compiles fine as C but fails
with the C++ compiler.
$ cat t.C cat /etc/redhat-release gcc t.C || cat -n
/amd/devco/contrib/linux/gcc-4.3.1/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/include-fixed/sys/stat.h
| head -n 350 | tail -n 10
#include sys/types.h
#include fcntl.h
#include stdio.h
#include unistd.h
int main () { }
Red Hat Enterprise Linux AS release 4 (Nahant Update 4)
In file included from /usr/include/fcntl.h:37,
from t.C:2:
/amd/devco/contrib/linux/gcc-4.3.1/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.1/include-fixed/sys/stat.h:345:
error: expected initializer before '__wur'
341 #ifdef __USE_ATFILE
342 /* Set file access permissions of FILE relative to
343 the directory FD is open on. */
344 extern int fchmodat (int __fd, __const char *__file, __mode_t mode, int
__flag)
345 __THROW __nonnull ((2)) __wur;
346 #endif /* Use ATFILE. */
347
348
349
350 /* Set the file creation mask of the current process to MASK,
The output of gcc -v:
$ gcc -v t.C
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /nfs/devco/contrib/sources/gcc-4.3.1/configure
--prefix=//nfs/d
evco/contrib/linux/gcc-4.3.1 --disable-nls --enable-shared --enable-static
--wit
h-gmp=/nfs/devco/contrib/linux/gmp-4.2.2
--with-mpfr=/nfs/devco/contrib/linux/mp
fr-2.3.1 --enable-languages=c,c++
Thread model: posix
gcc version 4.3.1 (GCC)
COLLECT_GCC_OPTIONS='-v' '-mtune=generic'
/amd/devco/contrib/linux/gcc-4.3.1/bin/../libexec/gcc/x86_64-unknown-linux-gnu/
4.3.1/cc1plus -quiet -v -iprefix
/amd/devco/contrib/linux/gcc-4.3.1/bin/../lib/g
cc/x86_64-unknown-linux-gnu/4.3.1/ -D_GNU_SOURCE t.C -quiet -dumpbase t.C
-mtune
=generic -auxbase t -version -o /tmp/ccC7bOXX.s
ignoring nonexistent directory
/amd/devco/contrib/linux/gcc-4.3.1/bin/../lib/gc
c/x86_64-unknown-linux-gnu/4.3.1/../../../../x86_64-unknown-linux-gnu/include
ignoring duplicate directory
/amd/devco/contrib/linux/gcc-4.3.1/bin/../lib/gcc/
../../lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../include/c++/4.3.1
ignoring duplicate directory
/amd/devco/contrib/linux/gcc-4.3.1/bin/../lib/gcc/
../../lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../include/c++/4.3.1/x86_6
4-unknown-linux-gnu
ignoring duplicate directory
/amd/devco/contrib/linux/gcc-4.3.1/bin/../lib/gcc/
../../lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../include/c++/4.3.1/backw
ard
ignoring nonexistent directory /usr/local/include
ignoring duplicate directory
/amd/devco/contrib/linux/gcc-4.3.1/bin/../lib/gcc/
../../lib/gcc/x86_64-unknown-linux-gnu/4.3.1/include
ignoring duplicate directory
/amd/devco/contrib/linux/gcc-4.3.1/bin/../lib/gcc/
../../lib/gcc/x86_64-unknown-linux-gnu/4.3.1/include-fixed
ignoring nonexistent directory
/amd/devco/contrib/linux/gcc-4.3.1/bin/../lib/gc
c/../../lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../x86_64-unknown-linux-
gnu/include
#include ... search starts here:
#include ... search starts here:
/amd/devco/contrib/linux/gcc-4.3.1/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.
1/../../../../include/c++/4.3.1
/amd/devco/contrib/linux/gcc-4.3.1/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.
1/../../../../include/c++/4.3.1/x86_64-unknown-linux-gnu
/amd/devco/contrib/linux/gcc-4.3.1/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.
1/../../../../include/c++/4.3.1/backward
/amd/devco/contrib/linux/gcc-4.3.1/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.
1/include
/amd/devco/contrib/linux/gcc-4.3.1/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.
1/include-fixed
/amd/devco/contrib/linux/gcc-4.3.1/bin/../lib/gcc/../../include
/usr/include
End of search list.
GNU C++ (GCC) version 4.3.1 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.3.1, GMP version 4.2.2, MPFR version 2.3.1.
warning: GMP header version 4.2.2 differs from library version 4.1.4.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 189ba05b2677e2c6c2336d7bfe8ccc28
In file included from /usr/include/fcntl.h:37,
from t.C:2:
/amd/devco/contrib/linux/gcc-4.3.1/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.1
/include-fixed/sys/stat.h:345: error: expected initializer before '__wur'
--
Summary: syntax error on __wur in include-fixed/sys/stat.h
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37405
[Bug c++/37256] extern template / explicit instantiation broken in 4.4.0-pre
--- Comment #2 from sebor at roguewave dot com 2008-08-27 16:48 --- Is this by any chance related to bug 24511? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37256
[Bug c++/37070] New: bogus unreachable warning on throw statement
gcc 4.3.0 generates the bogus warning below (4.4.0 behaves the same):
$ cat -n t.C g++ -v g++ -c -Wunreachable-code t.C
1 void f ()
2 {
3 throw 0;
4 }
5
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /home/sebor/gcc/trunk/configure
--prefix=/build/sebor/bin/gcc-4.4.0/ --enable-languages=c,c++
--with-mpfr=/usr/local/mpfr-2.3.1
Thread model: posix
gcc version 4.4.0 20080808 (experimental) (GCC)
t.C: In function void f():
t.C:3: warning: will never be executed
--
Summary: bogus unreachable warning on throw statement
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37070
[Bug c++/37070] bogus unreachable warning on throw statement
--- Comment #2 from sebor at roguewave dot com 2008-08-09 22:51 ---
I'm not sure what you're trying to say but it sure looks like a bug to me.
How else is one supposed to throw an exception without triggering this
warning?
Btw., the argument of a throw expression can throw, and when it does, it
becomes the thrown object:
$ cat t.C g++ -O2 -Wunreachable-code t.C ./a.out; echo $?
struct S { S () { throw 0; } };
void bar () { throw S (); }
int main ()
{
try { bar (); }
catch (int) { return 0; }
return 1;
}
t.C: In constructor S::S():
t.C:1: warning: will never be executed
t.C: In function void bar():
t.C:2: warning: will never be executed
0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37070
[Bug c++/37070] bogus unreachable warning on throw statement
--- Comment #4 from sebor at roguewave dot com 2008-08-10 02:23 --- My gcc is yesterday's build: gcc version 4.4.0 20080808 (experimental) (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37070
[Bug c++/37062] New: missing warning on unreachable return statement
gcc 4.3.0 issues warnings for the unreachable code on lines 7 and 9 below
but fails to issue one for line 17.
$ cat -n t.C g++ -Wunreachable-code -c t.C
1 int f ()
2 {
3 int i = 0;
4
5 if (i == 0) return 0;
6
7 throw i;// unreachable, warning
8 return 1; // unreachable, warning
9 }
10
11 int g ()
12 {
13 int i = 0;
14
15 if (i == 0) return 0;
16
17 return 1; // unreachable, no warning
18 }
19
t.C: In function int f():
t.C:7: warning: will never be executed
t.C:8: warning: will never be executed
--
Summary: missing warning on unreachable return statement
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37062
[Bug c++/37063] New: missing optimiation on unreachable code
I would expect gcc to optimize away the unreachable code in both functions
below but only in the first one is it eliminated. In addition, even though
the call to f1() in f3() can never be executed the compiler issues no
warning.
$ cat -n t.C g++ -Wunreachable-code -O3 -S t.C
1 void f1 ();
2
3 int f2 ()
4 {
5 int x = 0;
6
7 if (x == 0) return 0;
8 f1 ();
9
10 return 1;
11 }
12
13 int f3 ()
14 {
15 static int x;
16
17 if (x == 0) return 0;
18 f1 ();
19
20 return 1;
21 }
22
t.C: In function int f2():
t.C:8: warning: will never be executed
--
Summary: missing optimiation on unreachable code
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37063
[Bug c/37064] New: missing warning on pure function with side-effects
gcc assumes that functions defined with the pure attribute have no side
effects and do not modify program state, including through pointers passed
to such functions as arguments. The function below does modify the object
pointed to by its argument. It would be useful if gcc issued a diagnostic
for this and other similar violations of the pure assumption, analogously
to how it diagnoses noreturn functions that do return.
$ cat -n t.C g++ -c -O2 -Wall -W t.C
1 int f0 () __attribute ((noreturn));
2 int f0 () { return 0; }
3
4 int f1 (int*) __attribute ((pure));
5 int f1 (int *i)
6 {
7 *i = 0;
8 return 0;
9 }
10
t.C: In function int f0():
t.C:2: warning: function declared noreturn has a return statement
t.C:2: warning: noreturn function does return
--
Summary: missing warning on pure function with side-effects
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37064
[Bug c/37064] missing warning on pure function with side-effects
--- Comment #1 from sebor at roguewave dot com 2008-08-08 19:47 ---
Similarly, functions declared with the const attribute such as f1() in the
test case below that violate the compiler's assumptions should be diagnosed:
$ cat -n t.C g++ -c -O2 -Wall -W t.C
1 extern int i;
2 int f1 () __attribute ((const));
3 int f1 ()
4 {
5 return i;
6 }
7
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37064
[Bug c++/36910] New: missing diagnostic for initializing function pointer with incompatible exception specification
Gcc 4.3.1 fails to diagnose the invalid initialization of pf0 (nothrow)
from f0 (may throw) in the following program.
$ cat t.cpp gcc -W -Wall -Wno-unused -c -pedantic t.cpp
void f0 () { }
void f1 () throw () { }
void f2 () __attribute__ ((nothrow));
int main ()
{
void (*pf0)() throw () = f0; // ill-formed
void (*pf1)() throw () = f1; // well-formed
void (*pf2)() throw () = f2; // well-formed
}
--
Summary: missing diagnostic for initializing function pointer
with incompatible exception specification
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36910
[Bug c++/4898] adding an option to verify exception specifications
--- Comment #2 from sebor at roguewave dot com 2008-07-21 16:17 ---
I agree a new warning would be useful. For example, the following code should
be diagnosed:
struct S { S () throw () { throw 0; } };
as should this:
struct S { S () throw (int) { throw ; } };
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4898
[Bug c++/36870] New: __has_nothrow_constructor violates the ODR
The programs below detect an ODR violation in the libstdc++ implementation
of std::has_nothrow_default_constructor and the __has_nothrow_constructor
built-in compiler trait (hence I'm filing this as a bug in the c++ front
end rather than libstdc++).
$cat u.cpp \
g++ -c -std=gnu++0x -o 1.o u.cpp \
g++ -DMAIN -std=gnu++0x u.cpp 1.o \
./a.out
#include cassert
#include type_traits
struct S { S (); };
bool f ();
#ifdef MAIN
int main ()
{
assert (std::has_nothrow_default_constructorS::value == f ());
}
#else
S::S () { }
bool f () { return std::has_nothrow_default_constructorS::value; }
#endif
a.out: u.cpp:12: int main(): Assertion
`std::has_nothrow_default_constructorS::value == f ()' failed.
Aborted
$ cat u.cpp g++ -c -std=gnu++0x u.cpp ./a.out
#include cassert
struct S { S (); };
bool f ();
int main ()
{
assert (__has_nothrow_constructor (S) == f ());
}
S::S () { }
bool f () { return __has_nothrow_constructor (S); }
a.out: u.cpp:12: int main(): Assertion
`std::has_nothrow_default_constructorS::value == f ()' failed.
Aborted
--
Summary: __has_nothrow_constructor violates the ODR
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36870
[Bug c++/36870] __has_nothrow_constructor violates the ODR
--- Comment #5 from sebor at roguewave dot com 2008-07-18 21:47 --- (In reply to comment #4) The ODR is important from an ABI standpoint -- imagine a function template that uses SFINAE and std::has_nothrow_default_constructorT::type. Simply rearranging code or even compiling multiple sources in the same step could change which overload will be selected, potentially causing an ABI breakage. The compiler must give the same answer for the same type regardless of the context. That might mean not considering the body of the function if it can't be done 100% consistently (e.g., for out-of-line functions). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36870
[Bug c++/36870] __has_nothrow_constructor violates the ODR
--- Comment #7 from sebor at roguewave dot com 2008-07-18 22:11 --- FYI: I discussed the wording briefly with Daveed (eccp returns true if and only if the class has a trivial ctor or the ctor has a throw() spec on it, for just this reason). We agree that the wording is unclear and should be tightened up. I plan to bring it up on the reflector and write up an issue if there's consensus on the intent (I hope you and/or Mark can help give guidance). That said, IMO, the ODR requirement is orthogonal and beyond question. I.e., the compiler must return the same result throughout the same program, although it should be allowed to return a more correct result by doing whatever magic it has at its disposal. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36870
[Bug c++/36871] New: __has_nothrow_copy(T) false for T with a template ctor
The program below is expected to run with no assertions (template ctor
is not a copy ctor). Instead, when compiled with gcc 4.3.0, it aborts.
$ cat u.cpp g++ u.cpp -std=c++0x ./a.out
#include cassert
#include type_traits
struct A { template class T A (T) throw (int); };
struct B { B (B) throw (); template class T B (T) throw (int); };
int main ()
{
assert (std::has_nothrow_copy_constructorA::value);
assert (__has_nothrow_copy (A));
assert (std::has_nothrow_copy_constructorB::value);
assert (__has_nothrow_copy (B));
}
a.out: u.cpp:12: int main(): Assertion
`std::has_nothrow_copy_constructorB::value' failed.
Aborted
--
Summary: __has_nothrow_copy(T) false for T with a template ctor
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36871
[Bug c++/36871] __has_nothrow_copy(T) false for T with a template ctor
--- Comment #1 from sebor at roguewave dot com 2008-07-19 00:44 ---
This also fails. Seems that the combination of a copy ctor and template ctor
(even non-throwing) trips the compiler up.
$ cat u.cpp g++ u.cpp -std=c++0x ./a.out
#include cassert
#include type_traits
struct F {
F (const F) throw () { }
template class T F (T) throw () { }
};
int main ()
{
assert (std::has_nothrow_copy_constructorF::value);
assert (__has_nothrow_copy (F));
}
a.out: u.cpp:12: int main(): Assertion
`std::has_nothrow_copy_constructorF::value' failed.
Aborted
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36871
[Bug c++/36872] New: __has_nothrow_copy(T) false for T with a throwing vararg ctor
Similarly to (but not exactly the same as) the template ctor in bug 36871,
gcc 4.3.0 trips up on class with a throwing vararg ctor (regardless of the
number of arguments):
$ cat u.cpp g++ u.cpp -std=c++0x ./a.out
#include cassert
#include type_traits
struct S {
S (const S) throw ();
S (...) throw (int);
};
int main ()
{
assert (std::has_nothrow_copy_constructorS::value);
assert (__has_nothrow_copy (S));
}
a.out: u.cpp:12: int main(): Assertion
`std::has_nothrow_copy_constructorS::value' failed.
Aborted
--
Summary: __has_nothrow_copy(T) false for T with a throwing vararg
ctor
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36872
[Bug c++/36872] __has_nothrow_copy(T) false for T with a throwing vararg ctor
--- Comment #1 from sebor at roguewave dot com 2008-07-19 00:53 ---
Or any other throwing ctor, for that matter:
$ cat u.cpp g++ u.cpp -std=c++0x ./a.out
#include cassert
struct S {
S (const S) throw ();
S (int) throw (int);
};
int main ()
{
assert (__has_nothrow_copy (S));
}
a.out: u.cpp:11: int main(): Assertion `__has_nothrow_copy (S)' failed.
Aborted
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36872
[Bug c++/36856] [c++0x] __is_pod() fails for some pod types
--- Comment #4 from sebor at roguewave dot com 2008-07-16 19:26 --- We're using -std=gnu++0x, so we're expecting the implementation to follow C++ 0x rules. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36856
[Bug c++/36797] ICE on SFINAE and __is_empty
--- Comment #6 from sebor at roguewave dot com 2008-07-14 15:24 --- (In reply to comment #4) ... Is it a reasonable restriction on users to say thou shalt not use __is_empty in an expression that gets mangled? For example, can the user just use std::is_empty instead? As a data point, consider that the user may be an author of a third party implementation of the C++ standard library (such as Apache/Rogue Wave or STLport), and they may not be able to use std::is_empty for reasons unique to their project (e.g., policy or otherwise). My preference would be for gcc to avoid imposing restrictions on the use of these helpers to facilitate portability to other compilers such as EDG eccp (the latest 3.10.1 compiles the test case correctly). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36797
[Bug c++/36797] ICE on SFINAE and __is_empty
--- Comment #8 from sebor at roguewave dot com 2008-07-14 15:41 --- (In reply to comment #7) Subject: Re: ICE on SFINAE and __is_empty sebor at roguewave dot com wrote: My preference would be for gcc to avoid imposing restrictions on the use of these helpers to facilitate portability to other compilers such as EDG eccp (the latest 3.10.1 compiles the test case correctly). How does it mangle it? Like so: int fooA0 (BA0, __is_empty (A0)::X*): _Z3fooI1AILi0EEEiPN1BIT_Xv19builtin16TOS3_EE1XE int fooint(Bint, !__is_empty (int)::X*): _Z3fooIiEiPN1BIT_Xntv19builtin16TOS1_EE1XE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36797
[Bug c++/36797] ICE on SFINAE and __is_empty
--- Comment #10 from sebor at roguewave dot com 2008-07-14 18:43 --- (In reply to comment #9) I'd be happy to provide whatever info you need (e.g., the table of built-ins, if you can explain to me how to get it from the front-end :) As for the semantics of the built-ins, I assume both EDG and gcc used Howard Hinnant's Compiler Support for type_traits as the starting point: http://home.twcny.rr.com/hinnant/cpp_extensions/cpp_extensions AFAICS, the built-ins aren't document in any detail in the EDG eccp manual. Finally, if you intend to provide ABI compatibility with the EDG eccp front end (or vice versa) I'd suggest getting someone from EDG involved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36797
[Bug c++/36813] New: screwy diagnostic on ill-formed call from template with a local typedef
The second error message issued by gcc 4.3.0 for the ill-formed program below
looks wrong. I would expect it to read the same as the first one.
$ cat t.cpp g++ t.cpp
template class T struct A { };
template class T, class U struct B { typedef AT Y; };
template class T void foo (T*) { }
template class T, class U
void bar () {
foo (typename BT, U::Y ());
typedef typename BT, U::Y Y;
foo (Y ()); // line 11
}
int main () {
barint, Aint ();
}
t.cpp: In function void bar() [with T = int, U = Aint]:
t.cpp:15: instantiated from here
t.cpp:8: error: no matching function for call to foo(Aint)
t.cpp:11: error: no matching function for call to foo(bar() [with T = int, U =
Aint]::Y)
--
Summary: screwy diagnostic on ill-formed call from template with
a local typedef
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36813
[Bug c++/36816] New: error deducing template argument taking the address of rvalue reference template
Gcc 4.3.0 diagnoses the line marked error? in the program below.
I'd like to believe the program is well-formed and that the compiler should
be able to correctly deduce the template arguments from the initialed
expression without explicitly providing the template argument list.
template class T void f (T) { }
template class T void g (T) { }
template class T void h (T) { }
int main ()
{
{ void (*pf)(int)= f; } // okay
{ void (*pf)(int) = f; } // okay
{ void (*pf)(int) = f; } // okay
{ void (*pf)(int) = g; } // okay
{ void (*pf)(int) = h; } // okay
{ void (*pf)(int) = h; } // error?
{ void (*pf)(int) = hint; } // okay
// { void (*pf)(int) = hint; } // error!
// { void (*pf)(int) = hint; } // error!
}
t.cpp: In function int main():
t.cpp:14: error: no matches converting function h to type void (*)(int)
t.cpp:3: error: candidates are: templateclass T void h(T)
--
Summary: error deducing template argument taking the address of
rvalue reference template
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36816
[Bug c++/36797] New: ICE on SFINAE and __is_empty
gcc 4.3.0 crashes compiling the program below:
$ cat z.C g++ z.C
template int struct A { };
template class, bool struct B;
template class T struct BT, true { typedef T X; };
template class T
int foo (typename BT, __is_empty (T)::X* = 0) { return 0; }
template class T
int foo (typename BT, !__is_empty (T)::X* = 0) { return 1; }
int main ()
{
fooA0 ();
}
z.C: In function int foo(typename BT, __is_empty(T)::X*) [with T = A0]:
z.C:6: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--
Summary: ICE on SFINAE and __is_empty
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36797
[Bug c++/36799] New: error on va_copy in -std=c++0x mode
The program below compiles successfully in gnu++0x mode but fails to compile
in c++0x mode. Since va_copy() is in C++ 0x I expect the program to compile
regardless.
$ cat t.cpp g++ t.cpp -std=c++0x
#include cstdarg
int main ()
{
va_list x;
va_list y;
va_copy (y, x);
}
t.cpp: In function int main():
t.cpp:7: error: va_copy was not declared in this scope
--
Summary: error on va_copy in -std=c++0x mode
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36799
[Bug c++/36799] error on va_copy in -std=c++0x mode
--- Comment #1 from sebor at roguewave dot com 2008-07-10 23:04 --- I should have mentioned: the same problem exists with stdarg.h. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36799
[Bug c++/36707] New: ICE in build_modify_expr on rvalue reference function template
I haven't found anything about this in Bugzilla or tried 4.3.1:
$ cat t.cpp g++ -std=gnu++0x t.cpp
template class T void foo (T x) { x = T (); }
int main () {
int i;
foo (i);
}
t.cpp: In function void foo(T) [with T = int]:
t.cpp:5: instantiated from here
t.cpp:1: internal compiler error: in build_modify_expr, at cp/typeck.c:5821
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--
Summary: ICE in build_modify_expr on rvalue reference function
template
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36707
[Bug c++/36656] New: useless warning: type qualifiers ignored on function return type in template code
The warning below is unhelpful in generic code and silencing it by removing
the top-level cv qualifiers is unnecessarily tedious.
$ cat t.cpp g++ t.cpp -W
template class T
T foo () { return T (); }
int main ()
{
fooconst int();
}
t.cpp: In function 'int main()':
t.cpp:2: warning: type qualifiers ignored on function return type
--
Summary: useless warning: type qualifiers ignored on function
return type in template code
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36656
[Bug c++/36625] bogus error on __attribute__((aligned(N))) in template code
--- Comment #3 from sebor at roguewave dot com 2008-06-26 20:46 ---
Oddly enough, doubling up on the parens around N works:
template int N
struct A { struct S { short f[3]; } __attribute__ ((aligned ((N; };
int main ()
{
A123::S s;
}
--
sebor at roguewave dot com changed:
What|Removed |Added
Summary|missing diagnostic on |bogus error on
|invalid |__attribute__((aligned(N)))
|__attribute__((aligned(N))) |in template code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36625
[Bug c++/36625] New: missing diagnostic on invalid __attribute__((aligned(N)))
I expected to see a diagnostic for the following program regardless of whether
the template is instantiated or not, or whether the nested type is used or not.
Gcc only diagnoses the attribute when the type is used.
That said, rather than diagnosing it, it'd be even more useful to allow non
type template parameters and other constant integral expressions as arguments
to the attribute.
$ cat t.cpp g++ t.cpp echo PASS g++ -DUSE_IT t.cpp
template int N
struct A {
struct S { short f[3]; } __attribute__ ((aligned (N)));
};
int main ()
{
A123 a;
#ifdef USE_IT
A123::S s;
#endif
}
PASS
t.cpp: In instantiation of A123::S:
t.cpp:10: instantiated from here
t.cpp:3: error: N was not declared in this scope
t.cpp:3: error: requested alignment is not a constant
--
Summary: missing diagnostic on invalid
__attribute__((aligned(N)))
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36625
[Bug libstdc++/11108] iostream causes transform() to not compile with tolower()
--- Comment #11 from sebor at roguewave dot com 2008-06-03 19:16 --- (In reply to comment #10) [...] Quick fix from the PDF (in case it goes away again): Provide a manual cast for toupper to explicitly declare which toupper we mean. std::transform(s[0], s[0] + 5, s[0], static_castint (*)(int)(std::toupper)); Unfortunately, this is also incorrect because std::toupper(int) typically has C linkage while (int (*)(int)) has C++ linkage and pointers to functions with different language linkages are incompatible. That gcc accepts this form is due to bug 2316. Other compilers diagnose the cast. Ironically, using a type with C linkage in the cast isn't guaranteed to be correct either (where correct is defined as 100% portable) because the C++ standard doesn't specify the linkage of C functions such as toupper(int). Although it will work with the majority of implementations. extern C typedef int cfun_t (int); char s [] = abcd; std::transform(s[0], s[0] + 5, s[0], static_castcfun_t*(std::toupper)); The kicker, though, is that extern C declarations cannot appear at local or class scope so the typedef above cannot appear near the call where it's used but way above the definition of the function where the call is made. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11108
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #47 from sebor at roguewave dot com 2008-06-02 23:08 ---
(In reply to comment #46)
[...]
2) -ftransform-exceptions
should catch(X) expand into else if (false) rather than just if (false)?
That said, I don't think there is a way to do this using the preprocessor
alone. Consider that
try { foo (); }
catch (SomeException ex) {
puts (ex.what ());
}
will preprocess to:
try { foo (); }
if (false) {
puts (ex.what ()); // ex undefined
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #48 from sebor at roguewave dot com 2008-06-03 00:07 --- FWIW, let me throw out a suggestion for an implementation of Benjamin's (2) in the C++ front end: 1. try is a no-op 2. catch blocks are syntax-checked but eliminated as dead code 3. throw checks to see if a user-defined handler is installed and if so, calls it with useful arguments (e.g., the what() string); if no handler is installed or if it returns, std::terminate() is called 4. function exception specification is diagnosed as a warning but otherwise ignored (libc, libsupc++, and libstdc++ header should compile cleanly) libsupc++ provides a __set_xxx() function to let users install the handler. AFAIK, IBM XLC++ implements 1, 2, and 4 when -qnoeh is used. Apache stdcxx implements 3 for exceptions thrown by the library. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug c++/35711] New: bad text in -Wcast-qual warning (forgets volatile)
The text of the warning below is incorrect and misleading -- the cast
actually casts away the volatile qualifier, not constness. The warning
is misleading when the type of the source is both const and volatile
qualified.
$ cat t.cpp g++ -c -Wcast-qual t.cpp
int* foo (volatile int *p)
{
return (int*)p;
}
t.cpp: In function int* foo(volatile int*):
t.cpp:3: warning: cast from type volatile int* to type int* casts away
constness
--
Summary: bad text in -Wcast-qual warning (forgets volatile)
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35711
[Bug libstdc++/35176] SIGXFSZ in filebuf
--- Comment #3 from sebor at roguewave dot com 2008-02-13 15:46 --- I used setrlimit() only to emulate low disk space conditions. The same problem occurs in a pure C++ program (i.e., one that makes no POSIX or other non-C++ calls) when it really does run out of disk space. So again, since C++ iostreams is specified in terms of C stdio, I don't see how this is allowed. Can you explain on what basis you think this is conforming behavior? Does stdio generate SIGXFSZ? (I haven't checked any real implementations but I didn't see anything about it in C or POSIX). -- sebor at roguewave dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35176
[Bug libstdc++/35176] SIGXFSZ in filebuf
--- Comment #5 from sebor at roguewave dot com 2008-02-13 16:37 --- I understand that POSIX requires the signal but I'm not sure I see what that has to do with filebuf. C++ specifies that filebuf member functions behave as if by calling the C stdio functions. See 27.8.1, p2: In this subclause, the type name FILE refers to the type FILE declared in cstdio. A File provides an external source/sink stream whose underlaid character type is char (byte). and 27.8.1.4, the description of filebuf::open(): It then opens a file, if possible, whose name is the NTBS s (as if by calling std::fopen(s, modstr)) There is no mention in the C++ standard of filebuf calling POSIX write(), and while I agree that doing so makes sense (our own implementation does it), strictly speaking it doesn't seem to be allowed by the as if clause. In addition, I don't think exposing C++ programs to signals as a result is desirable. So it seems that a conforming implementation of filebuf that chooses to use POSIX I/O needs to suspend signals while making POSIX calls that might lead to signals. If you disagree and think the C++ standard permits this behavior could you point to the relevant wording? -- sebor at roguewave dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35176
[Bug libstdc++/35176] SIGXFSZ in filebuf
--- Comment #7 from sebor at roguewave dot com 2008-02-13 18:15 --- I see I should have checked the actual stdio behavior instead of relying on the standard. Recent Linux and Solaris both do, in fact, generate SIGXFSZ out of C stdio. AIX 5.3 does not, and neither does HP-UX 11.23, although HP-UX 11.33 does, suggesting a bug fix. Do you happen to have a pointer to the text in the POSIX (or C) spec that requires (or allows) this behavior of stdio? Also, even if it is allowed, I still don't think it's desirable. I'm curious what other libstdc++ maintainers think. Benjamin, Paolo? I'll probably raise this on [EMAIL PROTECTED] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35176
[Bug libstdc++/35176] New: SIGXFSZ in filebuf
When compiled with gcc 4.1.2 the program below dies with SIGXFSZ on Linux.
I don't think the standard allows filebuf to report errors using signals
(since it describes file I/O in terms of C stdio), nor does a signal seem
desirable in C++.
$ cat u.cpp g++ u.cpp ./a.out || echo $?
#include fstream
#include sys/resource.h
int main ()
{
rlimit rl;
getrlimit (RLIMIT_FSIZE, rl);
rl.rlim_cur = 32;
setrlimit (RLIMIT_FSIZE, rl);
std::filebuf fb;
if (0 == fb.open (testfile.text, std::ios::out))
return -1;
for (rlim_t i = 0; i != rl.rlim_cur + 1; ++i)
fb.sputc ('*');
}
File size limit exceeded
153
--
Summary: SIGXFSZ in filebuf
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build triplet: x86_64-redhat-linux
GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35176
[Bug libstdc++/34733] numpunct::grouping() doesn't match libc value for Bulgarian (bg_BG) locale
--- Comment #14 from sebor at roguewave dot com 2008-01-12 22:45 --- bg_BG is the only known example on Linux. The original bug report we got was for a fr_FR locale on Tru64. I haven't gone through other locales on Tru64 or any other platforms except for Linux to see how pervasive such locales might be. I'll keep you posted once I have more data. I agree that if the locale is buggy and the bug is rare there's not much point in spending time on this issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34733
[Bug libstdc++/34733] numpunct::grouping() doesn't match libc value for Bulgarian (bg_BG) locale
--- Comment #12 from sebor at roguewave dot com 2008-01-11 15:59 --- (In reply to comment #11) [...] So while I agree that NUL thousands_sep means no grouping to stdio and to iostreams in C++, I should clarify that in C++ it means that only if the NUL comes from libc (e.g., via localeconv), but not from a user-defined numpunct facet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34733
[Bug libstdc++/34733] numpunct::grouping() doesn't match libc value for Bulgarian (bg_BG) locale
--- Comment #11 from sebor at roguewave dot com 2008-01-11 15:56 --- I think the disconnect might be in how each of us is looking at the LC_NUMERIC data. To me, it's just a bunch of values that are independent of one another. You, OTOH, seem to view it more as a set of rules described by the data (if thousands_sep == NUL then grouping doesn't matter). The reason why I don't look at it that way is because I think the rules for the interpretation of the data are separate from the data: in C they are in sprintf and C++ in num_put. So while I agree that NUL thousands_sep means no grouping to stdio and to iostreams in C++, it's just one possible interpretation of the data for the specific purposes of the two libraries. There are other possible and equally valid interpretations/rules that can be drawn from it (e.g., in third party code). Finally, I'm not suggesting or even hoping that anything be done about this in libstdc++ ASAP, or necessarily at any point. I mostly just wanted to make a record of the issue (whether you consider it valid or not) and get your perspective on it, that's all :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34733
[Bug libstdc++/34733] New: numpunct::grouping() doesn't match libc value for Bulgarian (bg_BG) locale
I came across this while investigating (most likely) a related problem in
Apache stdcxx. Btw., I suspect the bg_BG locale is incorrect in defining
thousands_sep to NUL and filed
http://sources.redhat.com/bugzilla/show_bug.cgi?id=5599
$ cat t.cpp g++ -dumpversion g++ t.cpp LC_NUMERIC=bg_BG locale -ck
LC_NUMERIC ./a.out bg_BG | od -c
#include cassert
#include clocale
#include cstdio
#include locale
#include string
int main (int argc, char *argv[])
{
const char* const name = 1 argc ? argv [1] : bg_BG;
const std::locale bg (name);
const std::numpunctchar np =
std::use_facetstd::numpunctchar (bg);
const char ts = np.thousands_sep ();
const std::string grp = np.grouping ();
std::setlocale (LC_ALL, name);
const lconv* const pconv = std::localeconv ();
std::printf ('\\x%02x' == '\\x%02x'\n, ts, *pconv-thousands_sep);
std::printf (\%s\ == \%s\\n, grp.c_str (), pconv-grouping);
assert (ts == *pconv-thousands_sep);
assert (grp == pconv-grouping);
}
4.1.2
LC_NUMERIC
decimal_point=,
thousands_sep=
grouping=3;3
numeric-decimal-point-wc=44
numeric-thousands-sep-wc=0
numeric-codeset=CP1251
a.out: t.cpp:26: int main(int, char**): Assertion `grp == pconv-grouping'
failed.
000 ' \ x 0 0 ' = = ' \ x 0 0 '
020 \n = =003 003 \n
034
--
Summary: numpunct::grouping() doesn't match libc value for
Bulgarian (bg_BG) locale
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34733
[Bug libstdc++/34733] numpunct::grouping() doesn't match libc value for Bulgarian (bg_BG) locale
--- Comment #2 from sebor at roguewave dot com 2008-01-11 02:09 --- Right, in C it does mean that (because thousands_sep is a multibyte string, and so the value is really ). The problem is that in C++ a NUL thousands_sep is a perfectly valid single-byte character, i.e., '\0'. IMO, the way to fix it is by somehow distinguishing a NUL thousands_sep that comes from the system locale (e.g., via localeconv()) and a NUL thousands_sep intentionally supplied by the user (read test suite writer ;-) because they want to see it on output. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34733
[Bug libstdc++/34733] numpunct::grouping() doesn't match libc value for Bulgarian (bg_BG) locale
--- Comment #5 from sebor at roguewave dot com 2008-01-11 03:09 --- It's irrelevant to the implementation but it could be relevant to user-defined formatting (or parsing) code that bypasses num_put (or num_get) but uses numpunct to get the expected formats. IMO, the improvement in any Linux implementation (libstdc++ or stdcxx) lies in figuring out how to preserve the \3\3 grouping and NUL thousands_sep for bg_BG (and expose each via numpunct::grouping() and numpunct::thousdands_sep()) without causing num_put to insert NUL every three digits. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34733
[Bug libstdc++/34733] numpunct::grouping() doesn't match libc value for Bulgarian (bg_BG) locale
--- Comment #7 from sebor at roguewave dot com 2008-01-11 03:37 --- But that's just the libstdc++ interpretation of grouping and thousands_sep (no offense). The C library paints a different picture. If I want to write my own formatter/parser for numbers in the Bulgarian locale that inserts '@' as my own thousands separator every 3 digits I can do it but I have to drop down to C and get the grouping data from localeconv(). Not that there's anything wrong with it but it would be nice if I could also do it in C++ as well. What I'm saying is that if the C library says localeconv()-grouping is \3\3 the C++ numpunct::grouping() shouldn't say it's something else. I'm not sure this is something the C++ standard can do anything about except acknowledge it as a limitation. But that doesn't mean that implementations couldn't do better. For instance, numpunct could append some harmless special character to its internal representation of grouping (say set it to \3\3\0\0) when thousands_sep is NUL. num_put would be instructed to look for the two consecutive NULs in grouping and avoid inserting thousands_sep when NUL. Since user-defined numpunct would almost certainly not return grouping terminated by two NULs if such a facet with a grouping of \3\3 and NUL for thousands_sep num_put would insert the NUL as expected. Yes, it's a hack but it's one that would work in the vast majority of cases: the implementation would pass anal tests while behaving sanely in ordinary situations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34733
[Bug libstdc++/34733] numpunct::grouping() doesn't match libc value for Bulgarian (bg_BG) locale
--- Comment #9 from sebor at roguewave dot com 2008-01-11 05:44 --- I don't agree that localeconv()-grouping is garbage just because thousands_sep is NUL. I'm not aware of anything in C or POSIX that says that. In the case of bg_BG, the grouping is clearly correct. What's questionable in this case is the value of thousands_sep. But that's probably just a bug in the Bulgarian locale definition. Bugs aside, there may be a perfectly valid locale (a user-defined one) in which there is no thsousands_sep (i.e., it's NUL) but where grouping is non-empty. It's trivial to create one as an exercise. The C++ library numpunct should be able to represent such a locale without change. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34733
[Bug libstdc++/34449] use_facetxxx_byname(locale::classic()) returns true
--- Comment #5 from sebor at roguewave dot com 2007-12-14 19:35 --- (In reply to comment #3) That's an interesting interpretation. I agree it's possible although I suspect it was not intended. IMO, the _byname facets are really an implementation detail that was exposed just to show how the facet machinery was meant to be implemented. The other gaping hole in the spec, besides the missing requirement that a named locale actually use the _byname facets, is the effects of their constructors. I.e., what do I get when I invoke std::ctype_bynamewchar_t(en_US.ISO-8859-1)? (Do I get the same behavior I with the ctype facet in locale(en_US.ISO-8859-1) or something else?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34449
[Bug libstdc++/34449] New: use_facetxxx_byname(locale::classic()) returns true
The test case below is expected to pass. With gcc 4.1.2 it aborts in the second
assert.
$ cat t.cpp g++ t.cpp ./a.out
#include cassert
#include locale
struct DerivedCtype: std::ctype_bynamechar {
DerivedCtype (): std::ctype_bynamechar() { }
};
template class Facet
bool check_use_facet (const std::locale locale)
{
try {
std::use_facetFacet(locale);
}
catch (...) {
return false;
}
return true;
}
int main ()
{
const std::locale classic = std::locale::classic ();
const std::locale named (en_US.ISO-8859-1);
const std::locale user (classic, new DerivedCtype);
assert (check_use_facetstd::ctypechar (classic));
assert (!check_use_facetstd::ctype_bynamechar (classic));
assert (!check_use_facetDerivedCtype(classic));
assert (check_use_facetstd::ctypechar (named));
assert (check_use_facetstd::ctype_bynamechar (named));
assert (!check_use_facetDerivedCtype(named));
assert (check_use_facetstd::ctypechar (user));
assert (check_use_facetstd::ctype_bynamechar (user));
assert (check_use_facetDerivedCtype(user));
}
a.out: t.cpp:28: int main(): Assertion
`!check_use_facetstd::ctype_bynamechar
(classic)' failed.
--
Summary: use_facetxxx_byname(locale::classic()) returns true
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build triplet: x86_64-redhat-linux
GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34449
[Bug libstdc++/34449] use_facetxxx_byname(locale::classic()) returns true
--- Comment #1 from sebor at roguewave dot com 2007-12-13 05:41 ---
FWIW, it looks like you need a dynamic_cast in use_facet (it's not enough to
check the id and then downcast using static_cast). Something like this:
--- locale_facets.tcc 2007-10-21 08:33:43.0 -0600
+++ locale_facets.tcc 2007-12-12 22:28:07.0 -0700
@@ -111,9 +111,13 @@
{
const size_t __i = _Facet::id._M_id();
const locale::facet** __facets = __loc._M_impl-_M_facets;
+
+ const locale::facet* __pf;
if (!(__i __loc._M_impl-_M_facets_size __facets[__i]))
-__throw_bad_cast();
- return static_castconst _Facet(*__facets[__i]);
+__pf = 0;
+ else
+__pf = __facets[__i];
+ return dynamic_castconst _Facet(*__pf);
}
// Routine to access a cache for the facet. If the cache didn't
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34449
[Bug libstdc++/34031] money_get:do_get incorrectly sets eofbit for valid input
--- Comment #2 from sebor at roguewave dot com 2007-11-08 18:52 --- Yes, I can confirm that, Paolo. The Apache C++ Standard Library behaves the same (i.e., the facet sets eofbit). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34031
[Bug c/34024] New: infinite loop on longjmp with optimization
When compiled with gcc 3.4.4 through 4.1.2 -O on x86_64 the program below never
terminates. I haven't checked the standard for possible undefined behavior in
this case but since the same program terminates when compiled with many (all?)
all other compilers we have available I'm making the assumption that that this
is a gcc bug. I'll gladly accept a pointer to the chapter and verse that allows
gcc to behave this way.
$ cat t.c gcc -O t.c ./a.out | head -n 10
#include setjmp.h
#include stdio.h
jmp_buf env;
void call_longjmp (int x) {
printf (test_longjmp(%d)\n, x);
longjmp (env, x);
}
int main ()
{
int x = 1;
int y;
y = setjmp (env);
if (0 == y) call_longjmp (x);
else if (y 3)
call_longjmp (++x);
}
test_longjmp(1)
test_longjmp(2)
test_longjmp(2)
test_longjmp(2)
test_longjmp(2)
test_longjmp(2)
test_longjmp(2)
test_longjmp(2)
test_longjmp(2)
test_longjmp(2)
^C
--
Summary: infinite loop on longjmp with optimization
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build triplet: x86_64-redhat-linux
GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34024
[Bug c++/33401] Unwanted memset in default constructor
--- Comment #3 from sebor at roguewave dot com 2007-09-12 03:47 --- You remember correctly :) To avoid zeroing it out use 'new buffer' w/o the parentheses. -- sebor at roguewave dot com changed: What|Removed |Added CC||sebor at roguewave dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33401
[Bug c++/33403] warning: missing sentinel in function call for 0 rather than NULL
--- Comment #2 from sebor at roguewave dot com 2007-09-12 03:56 --- (In reply to comment #1) This is not a bug, 0 will be pasted as the same size as an int which means it will most likely not be passed as the same size as a NULL pointer. I don't know about most likely. sizeof(int) == sizeof(void*) is still pretty common, so my guess would be that the warning is more often wrong than not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33403
[Bug c++/32984] add checking for array new delete
--- Comment #5 from sebor at roguewave dot com 2007-08-05 00:31 --- There are third party tools that track these types of problems. Some of them have started to make their way into compilers. For example, the HP static analysis tool called Code Adviser is integrated into the HP aCC compiler on IPF (see www.hp.com/go/cadvise). -- sebor at roguewave dot com changed: What|Removed |Added CC||sebor at roguewave dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32984
[Bug c++/32525] Request for new warning: useless dynamic_casts
--- Comment #7 from sebor at roguewave dot com 2007-07-15 00:03 --- In cases when the compiler can figure out that the cast is unnecessary it would be even better if it would optimize it away than to complain to the user about not being able to do it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32525
[Bug c++/31176] reorder class data members to minimize space waste
--- Comment #6 from sebor at roguewave dot com 2007-03-15 19:54 --- (In reply to comment #5) I've checked all three but none of them seems to achieve an optimal layout in a modified template case. Let me attach my test program. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31176
[Bug c++/31176] reorder class data members to minimize space waste
--- Comment #7 from sebor at roguewave dot com 2007-03-15 19:55 --- Created an attachment (id=13212) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13212action=view) test case for data member reordering -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31176
[Bug c++/31176] reorder class data members to minimize space waste
--- Comment #8 from sebor at roguewave dot com 2007-03-15 23:51 ---
Some additional comments on the request precipitated by a discussion with the
implementers of another compiler:
The rationale for allowing the attribute on individual members is to provide
fine-grained control over which members the compiler should be allowed to
reorder and which it shouldn't.
For instance, I might want to define an aggregate struct that's optimally laid
out for space except for the first member which needs to be aligned at a
specific boundary:
template class T, class U
struct S __attribute ((aligned (16))) {
size_t refcount;
public: T first __attribute ((reorder));
public: U second __attribute ((reorder));
};
I know I could put T and U in a nested struct but I shouldn't need to do that.
Btw., since today's compiles are allowed to reorder first and second (but not
refcount), I think it's important that the the __attribute ((reorder)) be
considered in conjunction with the access specifier(s) so that when the
compiler implements reordering by default (i.e., w/o the attribute), the layout
of structs with members marked up with the attribute will stay the same even
after removing it. I.e., when gcc 5 comes out in 201X, it would be useful if
struct S below were laid out exactly the same as the struct S above generated
by gcc 4:
template class T, class U
struct S __attribute ((aligned (16)) {
size_t refcount;
public: T first;// no attribute
public: U second; // no attribute
};
Declaring S members with __attribute((reorder)) but without the access
specifiers otherwise necessary to allow the members to be reordered should have
no effect and give a diagnostic (warning or remark):
template class T, class U
struct S __attribute ((aligned (16)) {
size_t refcount;
public:
T first __attribute ((reorder));
U second __attribute ((reorder));
};
Ditto if only first or only second (and not both) had an access specifier.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31176
[Bug c++/31176] New: reorder class data members to minimize space waste
While discussing how today's C++ compilers lay out data members of structs and
classes on the C++ committee's mailing list the observation was made that no
known implementation, including gcc, takes advantage of the permission to
rearrange members declared with their own access specifier (see
c++std-core-11977). For example, the data members of the following struct are
laid out in declaration order even though a more space efficient order is
possible:
struct S { public: char c; public: int i; public: char d; };
This problem is especially hard to solve in template code where the sizes of
one or more data members are not known, such as:
template class T, class U, class V
struct Triple { public: T a; public: U b; public: V c; };
Since reordering of existing structs would introduce a binary incompatibility I
would like to propose that a mechanism be provided whereby authors of new code
can mark up their types and/or data members in order to permit the compiler to
rearrange them in a space efficient manner, until gcc implements a new ABI
where the reordering algorithm becomes the default.
For example, a new type and/or variable attribute could be added (call it
reorder), that could be used to mark up types and/or data members to
participate in the reordering. To allow the compiler to arrange Triple members
in an efficient way the template would be marked up as follows:
template class T, class U, class V
struct Triple __attribute__ ((reorder)) {
public: T a; public: U b; public: V c;
};
or, alternatively, like so:
template class T, class U, class V
struct Triple {
public: T a __attribute__ ((reorder));
public: U b __attribute__ ((reorder));
public: V c __attribute__ ((reorder));
};
The order of members declared in the same section (introduced and closed by an
access specifier) without the attribute would not participate in the reordering
with one another.
Members of reordered aggregates would be initialized in declaration order.
--
Summary: reorder class data members to minimize space waste
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31176
[Bug c++/31176] reorder class data members to minimize space waste
--- Comment #3 from sebor at roguewave dot com 2007-03-14 19:04 --- (In reply to comment #1) Interesting. Do the attributes apply to derived classes automatically? I would say no. [...] Is D also allowed to reorder members a and b? even with an explicit __attribute__((reorder))? I'm afraid I don't know enough to give an informed answer but my gut tells me that it might be safer to have the programmer explicitly ask for the base class padding to be used to store members of the derived class (e.g., via some creative application of the attribute in the definition of the derived class) rather than having the compiler do it automatically for them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31176
[Bug c++/31176] reorder class data members to minimize space waste
--- Comment #4 from sebor at roguewave dot com 2007-03-14 19:05 --- (In reply to comment #2) Note actually some compilers actually do this even without an attribute. This is related to the art hack. Out of curiosity, which compiler does it? And what's the art hack? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31176
[Bug c++/31158] New: wrong line number in warning: overflow in implicit constant conversion
The line number in the warning below points to the closing brace of the
initializer expression making it difficult to find the offending line if the
initializer is many lines long. I would like to suggest that the line number be
that of the problem line (and perhaps include the column number as well, if
possible, when there is more than one initializer per line).
$ cat t.cpp g++ -Wall t.cpp
/* 1 */ int main ()
/* 2 */ {
/* 3 */ const struct { short i; } a[] = {
/* 4 */ { 65535U },
/* 5 */ { 65536U }
/* 6 */ };
/* 7 */ (void)a;
/* 8 */ }
/* 9 */
t.cpp: In function 'int main()':
t.cpp:6: warning: overflow in implicit constant conversion
--
Summary: wrong line number in warning: overflow in implicit
constant conversion
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31158
[Bug c++/30811] __FUNCTION__ allowed in function declaration
--- Comment #6 from sebor at roguewave dot com 2007-03-09 18:25 --- (In reply to comment #5) Good point! I hadn't thought of that. Since that option is out and __FUNCTION__ should simply behave identically to __func__ and be disallowed in global or namespace scope function argument lists, or its documentation should be changed to say that unlike __func__, __FUNCTION__ is allowed in argument lists of C++ functions declared at namespace scope. The point is that if the two are documented to be interchangeable users ought to be able to switch between one and the other with no change in behavior. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30811
[Bug c++/30811] New: __FUNCTION__ allowed in function declaration
The manual says __FUNCTION__ is just another name for __func__ but the two
behave slightly differently (the former is not allowed in function declarations
while the latter is). __PRETTY_FUNCTION__ is also allowed but with slightly
different (and, IMO, rather unusual) effects.
I propose that __FUNCTION__ and __PRETTY_FUNCTION__ either be disallowed in
function declarations (just as __func__ is), or that they have the same meaning
as when used in the body of the function.
$ cat z.cpp g++ z.cpp ./a.out
extern C int puts (const char*);
// void foo (const char *s = __func__) { puts (s); }
void bar (const char *s = __FUNCTION__) { puts (s); }
void baz (const char *s = __PRETTY_FUNCTION__) { puts (s); }
int main () {
// foo ();
bar ();
baz ();
}
top level
--
Summary: __FUNCTION__ allowed in function declaration
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30811
[Bug c++/30812] New: enhancement: exception specification in __PRETTY_FUNCTION__
Even though a function's exception specification isn't part of its type (neither is the fact that the function is virtual) it would be useful to include it in __PRETTY_FUNCTION__ (just as virtual is). This is a request for such an enhancement. -- Summary: enhancement: exception specification in __PRETTY_FUNCTION__ Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sebor at roguewave dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30812
[Bug c++/30811] __FUNCTION__ allowed in function declaration
--- Comment #2 from sebor at roguewave dot com 2007-02-15 21:29 --- No, I'm not aware of any such paper. AFAIK, neither __FUNCTION__ nor __PRETTY_FUNCTION__ is specified by either C or C++, or proposed for inclusion either of them (I could be wrong). They're gcc extensions, aren't they? I'm suggesting that __FUNCTION__ either behave the way it's documented (i.e., just as C99 __func__ does) or, since it is an extension, that it be extended further. Similarly for __PRETTY_FUNCTION__. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30811
[Bug c++/30811] __FUNCTION__ allowed in function declaration
--- Comment #4 from sebor at roguewave dot com 2007-02-15 23:06 --- The wording proposed in N1970 for the C++ __func__ indentifier reads: -1- The identifier __func__ shall be implicitly declared by the translator as if, immediately following the opening brace of each function definition, the declaration static const char __func__[] = function-name; appeared, where function-name is the unqualified name of the lexically enclosing function. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1970.htm. Based on this __func__ would not be defined in a function declaration (except as an extension). Since the gcc __FUNCTION__ extension does not behave the same way as the C99 __func__ indentifier (i.e., it is defined in a function declaration, albeit to the empty string), it might be possible to extend it and make it defined earlier, i.e., even before the opening curly brace. Another option, of course, is to undefine it and make it exactly the same as __func__. I see more value in doing the former than the latter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30811
[Bug c++/30738] New: suboptimal code for min, max, et al
For T being an arithmetic type, gcc 4.1 generates what looks like suboptimal
assembly code for inline C++ functions that take their argument(s) by const
reference (const T) vs the same functions that take their argument(s) by value
(T).
Ideally, the code generated for test_min_ref() and test_min_ptr() below would
be the same as for test_min_val(). The code generated for SPARC at the bottom
shows that the code for both functions is worse.
template class T inline const T min_ref (const T x, const T y) { return x
y ? x : y; }
template class T inline const T* min_ptr (const T *x, const T *y) { return *x
*y ? x : y; }
template class T inline T min_val (T x, T y) { return x y ? x : y; }
int test_min_ref (int x, int y) { return min_ref (x, y); }
int test_min_ptr (int x, int y) { return *min_ptr (x, y); }
int test_min_val (int x, int y) { return min_val (x, y); }
.file t.cpp
.section.text
.align 4
.global _Z12test_min_refii
.type _Z12test_min_refii, #function
.proc 04
_Z12test_min_refii:
.LLFB5:
cmp %o0, %o1
st %o0, [%sp+68]
st %o1, [%sp+72]
bge .LL7
add%sp, 68, %o0
jmp %o7+8
ld [%o0], %o0
.LL7:
add %sp, 72, %o0
jmp %o7+8
ld [%o0], %o0
.LLFE5:
.size _Z12test_min_refii, .-_Z12test_min_refii
.global __gxx_personality_v0
.align 4
.global _Z12test_min_ptrii
.type _Z12test_min_ptrii, #function
.proc 04
_Z12test_min_ptrii:
.LLFB6:
cmp %o0, %o1
st %o0, [%sp+68]
st %o1, [%sp+72]
bge .LL13
add%sp, 68, %o0
jmp %o7+8
ld [%o0], %o0
.LL13:
add %sp, 72, %o0
jmp %o7+8
ld [%o0], %o0
.LLFE6:
.size _Z12test_min_ptrii, .-_Z12test_min_ptrii
.align 4
.global _Z12test_min_valii
.type _Z12test_min_valii, #function
.proc 04
_Z12test_min_valii:
.LLFB7:
cmp %o0, %o1
bg,a.LL17
mov%o1, %o0
.LL17:
jmp %o7+8
nop
.LLFE7:
.size _Z12test_min_valii, .-_Z12test_min_valii
.ident GCC: (GNU) 4.1.0
--
Summary: suboptimal code for min, max, et al
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build triplet: sparc-sun-solaris
GCC host triplet: sparc-sun-solaris
GCC target triplet: sparc-sun-solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30738
[Bug libstdc++/30561] New: istream::operator(int) broken
Here's a test case for the problem I point out in c++std-lib-17897. It shows
that operator(int) behaves differently (and, I claim, incorrectly) from
operator(long) or any other extractor except the one for short (which is
affected for the same reason).
$ cat t.cpp g++ t.cpp -static ./a.out
#include cassert
#include locale
#include sstream
struct NumPunct: std::numpunctchar
{
std::string do_grouping () const { return \3; }
char do_thousands_sep () const { return ';'; }
};
template class T
T extract (const char *s)
{
std::istringstream strm (s);
strm.imbue (std::locale (strm.getloc (), new NumPunct));
T x = T ();
strm x;
assert ((strm.failbit | strm.eofbit) == strm.rdstate ());
return x;
}
int main ()
{
assert (123L == extractlong(1;2;3));
assert (123 == extractint(1;2;3));
}
Assertion failed: 123 == extractint(1;2;3), file t.cpp, line 26
Abort (core dumped)
--
Summary: istream::operator(int) broken
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30561
[Bug c++/30539] Accepts invalid explicit specialization declaration
--- Comment #1 from sebor at roguewave dot com 2007-01-22 16:25 --- Even better, this works too: template void X1::X2::X3::X4::f(); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30539
[Bug libstdc++/30416] New: SIGSEGV in valarray::cshift(n) on empty array
AFAIK, the program below should have well-defined behavior but it abends with
gcc 4.1.0 on Solaris 9.
$ cat t.cpp g++ -g t.cpp -static gdb ./a.out
#include valarray
int main ()
{
const std::valarrayint a;
a.cshift (1);
}
GNU gdb 6.5
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as sparc-sun-solaris2.9...
(gdb) run
Starting program: a.out
Program received signal SIGSEGV, Segmentation fault.
0x00024db8 in memcpy ()
(gdb) where
#0 0x00024db8 in memcpy ()
#1 0x00010368 in std::_Array_copy_ctorint, true::_S_do_it (__b=0x0,
__e=0x4, __o=0xffbffb94)
at
/usr/local/gcc-4.1.0/lib/gcc/sparc-sun-solaris2.9/4.1.0/../../../../include/c++/4.1.0/bits/valarray_array.h:165
#2 0x00010398 in std::__valarray_copy_constructint (__b=0x0, __e=0x4,
__o=0xffbffb94)
at
/usr/local/gcc-4.1.0/lib/gcc/sparc-sun-solaris2.9/4.1.0/../../../../include/c++/4.1.0/bits/valarray_array.h:174
#3 0x0001057c in std::valarrayint::cshift (this=0xffbffc20, __n=1)
at
/usr/local/gcc-4.1.0/lib/gcc/sparc-sun-solaris2.9/4.1.0/../../../../include/c++/4.1.0/valarray:821
#4 0x00010288 in main () at /nfs/b20/sebor/tmp/t.cpp:8
--
Summary: SIGSEGV in valarray::cshift(n) on empty array
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30416
[Bug libstdc++/30416] SIGSEGV in valarray::cshift(n) on empty array
--- Comment #4 from sebor at roguewave dot com 2007-01-09 22:34 --- (In reply to comment #3) The standard refers to (l+n)%size(), so if size()=0, that seems to be undefined. On the other hand, it seems fairly obvious what should happen in this case (ie nothing). The requirement is to return an object of length size() each of whose elements... If there are no elements the ... doesn't/cannot apply. Note that an analogous expression is used in rotate_copy which I assume we all agree is well defined for zero-length ranges. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30416
