[Bug c++/27402] New: error on SFINAE
I believe the program below is well-formed (the latest EDG eccp 3.7 concurs),
but gcc 4.1.0 rejects it.
$ cat t.cpp && gcc --version && gcc t.cpp
template struct A { typedef int I; };
struct X { };
template struct B { typedef typename T::J J; };
template struct B { typedef X J; };
template
typename A::I foo (T) { return 0; }
template typename B::J foo (T) { return typename B::J ();
}
int main ()
{
foo ("");
}
gcc (GCC) 4.1.0
Copyright (C) 2006 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.cpp: In function 'int main()':
t.cpp:15: error: invalid operands of types 'const char*' and 'const char*' to
binary 'operator|'
--
Summary: error on SFINAE
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-solaris2.9
GCC host triplet: sparc-sun-solaris2.9
GCC target triplet: sparc-sun-solaris2.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27402
[Bug c++/27527] New: invalid types produced out of argument deduction (SFINAE bug)
The program below fails to compile with gcc 4.1.0. According to 14.8.2, p2,
template argument deduction must fail if it would result in an invalid type.
Bullet 1 in the same paragraph specifically mentions "attempting to create an
array with an element type that is void" as one possible reason for such a
failure. Thus in the program below the first overload of foo must not be
considered a candidate for overload resolution since doing so would result an
invalid type (A::X where X is an array of void).
See also bug 27402.
$ cat t.cpp && gcc t.cpp
template struct A { typedef U X [1]; };
template struct B { typedef T Y; };
template
A foo (T) { return A(); }
template
B foo (T) { return B(); }
int main ()
{
foo (0);
}
t.cpp: In function 'int main()':
t.cpp:12: error: call of overloaded 'foo(int)' is ambiguous
t.cpp:5: note: candidates are: A foo(T) [with T = int]
t.cpp:8: note: B foo(T) [with T = int]
--
Summary: invalid types produced out of argument deduction (SFINAE
bug)
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=27527
[Bug c++/27527] invalid types produced out of argument deduction (SFINAE bug)
--- Comment #1 from sebor at roguewave dot com 2006-05-10 01:07 ---
Here's a test case designed to exhaustively exercise all cases mentioned in
14.8.2, p2. Hope it helps.
$ cat ~/tmp/t.cpp && (c=1; while [ $c -lt 15 ]; do printf "%s: " "$c"; gcc
-DCASE=$c ~/tmp/t.cpp 2>/dev/null; if [ $? -eq 0 ]; then echo okay; else echo
ERROR; fi; c=`expr $c + 1`; done)
#if CASE == 1
// attempting to create an array with an element type that is void
template struct A { typedef U X [1]; };
#elif CASE == 2
// attempting to create an array with an element type that is function
template struct A { typedef U X [1]; };
#elif CASE == 3
// attempting to create an array with an element type that is a reference
template struct A { typedef U X [1]; };
#elif CASE == 4
// attempting to create an array with size that is zero
template struct A { typedef T X [N]; };
#elif CASE == 5
// attempting to create an array with size that is negative
template struct A { typedef T X [N]; };
#elif CASE == 6
// attempting to use a type that is not a class type in a qualified name
template struct A { typedef typename T::X X; };
#elif CASE == 7
// attempting to use a non-existent member type
template struct A { typedef typename A::X X; };
#elif CASE == 8
// attempting to create a pointer to reference type
template struct A { typedef U* X; };
#elif CASE == 9
// attempting to create a reference to reference type
template struct A { typedef U& X; };
#elif CASE == 10
// attempting to create a reference to void type
template struct A { typedef U& X; };
#elif CASE == 11
// attempting to create a pointer to member of T when T is not class type
template struct A { typedef int T::*X; };
#elif CASE == 12
// attempting to perform an invalid conversion
char ch;
template struct A { typedef T X; };
#elif CASE == 13
// attempting to create a function type with a void parameter
template struct A { typedef T X (U); };
#elif CASE == 14
// attempting to create a cv-qualified function type
template struct A { typedef U& X; };
#else
# error CASE not #defined
#endif
template struct B { typedef T Y; };
template
A foo (T);
template
B foo (T) { return B(); }
int main ()
{
foo (0);
}
The output of running the script with gcc 4.1:
1: ERROR
2: ERROR
3: ERROR
4: ERROR
5: ERROR
6: ERROR
7: ERROR
8: ERROR
9: ERROR
10: ERROR
11: ERROR
12: okay
13: ERROR
14: ERROR
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27527
[Bug c++/27527] invalid types produced out of argument deduction (SFINAE bug)
--- Comment #2 from sebor at roguewave dot com 2006-05-12 16:27 --- EDG points out to me that both the original test case and the one from comment #1 are ambiguous because only the declaration of the signature of the function (and thus only the declaration of its return type and its arguments) is required the be well-formed and not the definition. Since the declaration of both A and B is well-formed in all cases the call is ambiguous. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27527
[Bug c++/27527] invalid types produced out of argument deduction (SFINAE bug)
--- Comment #3 from sebor at roguewave dot com 2006-05-12 16:30 --- Created an attachment (id=11446) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11446&action=view) Corrected test program exercising SFINAE. After modifying the test program from comment #1 to correct these problems most test cases still fail (with both gcc and EDG eccp). The modified test program is in the attachment. Here's a script I used to run the test program: $ (c=1; \ while [ $c -lt 17 ]; do \ printf "%s: " "$c"; \ gcc -DCASE=$c t.cpp 2>/dev/null; \ if [ $? -eq 0 ]; then echo okay; else echo ERROR; fi; \ c=`expr $c + 1`; \ done) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27527
[Bug c/27629] New: SIGSEGV in printstack() on Solaris 9
C and C++ programs compiled with gcc 4.1 die with a SIGSEGV in Solaris 9
printstack(). The same programs run successfully when compiled with 4.0.2 and
prior. If this is due to a Solaris bug it would be great if gcc could work
around it.
$ cat t.c && gcc -g t.c && ./a.out || gdb -q a.out
int printstack (int);
int main ()
{
printstack (1);
}
Segmentation Fault (core dumped)
(gdb) run
Starting program: /tmp/a.out
Program received signal SIGSEGV, Segmentation fault.
0xff2d6f24 in display_stack_info () from /usr/lib/libc.so.1
(gdb) where
#0 0xff2d6f24 in display_stack_info () from /usr/lib/libc.so.1
#1 0xff2d6a84 in walkcontext () from /usr/lib/libc.so.1
#2 0xff2d6fb4 in printstack () from /usr/lib/libc.so.1
#3 0x000105b4 in main () at t.c:5
--
Summary: SIGSEGV in printstack() on Solaris 9
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-solaris2.9
GCC host triplet: sparc-sun-solaris2.9
GCC target triplet: sparc-sun-solaris2.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27629
[Bug target/27629] SIGSEGV in printstack() on Solaris 9
--- Comment #2 from sebor at roguewave dot com 2006-05-16 17:35 --- I'm not sure what you find wrong with my "attitude" but yes, I did send Sun a note about it pointing them to this problem report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27629
[Bug target/27629] SIGSEGV in printstack()
--- Comment #4 from sebor at roguewave dot com 2006-05-17 15:12 --- Here's the verbose output from the compiler driver: $ gcc -v t.c Using built-in specs. Target: sparc-sun-solaris2.9 Configured with: /build/sebor/gcc-4.1.0/configure --enable-languages=c,c++ --prefix=/usr/local/gcc-4.1.0 : (reconfigured) /build/sebor/gcc-4.1.0/configure --enable-languages=c,c++ --prefix=/usr/local/gcc-4.1.0 : (reconfigured) /build/sebor/gcc-4.1.0/configure --enable-languages=c,c++ --prefix=/usr/local/gcc-4.1.0 --with-gnu-as --with-gnu-ld Thread model: posix gcc version 4.1.0 /usr/local/gcc-4.1.0/libexec/gcc/sparc-sun-solaris2.9/4.1.0/cc1 -quiet -v t.c -quiet -dumpbase t.c -mcpu=v7 -auxbase t -version -o /var/tmp//ccDwQbF9.s ignoring nonexistent directory "/usr/local/gcc-4.1.0/lib/gcc/sparc-sun-solaris2.9/4.1.0/../../../../sparc-sun-solaris2.9/include" #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/local/gcc-4.1.0/include /usr/local/gcc-4.1.0/lib/gcc/sparc-sun-solaris2.9/4.1.0/include /usr/include End of search list. GNU C version 4.1.0 (sparc-sun-solaris2.9) compiled by GNU C version 4.1.0. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: fe86d251b0f1007e125f3d9a02434672 /usr/local/gcc-4.1.0/libexec/gcc/sparc-sun-solaris2.9/4.1.0/as -V -Qy -s -xarch=v8 -o /var/tmp//cccuUoEg.o /var/tmp//ccDwQbF9.s GNU assembler version 2.16.1 (sparc-sun-solaris2.9) using BFD version 2.16.1 /usr/local/gcc-4.1.0/libexec/gcc/sparc-sun-solaris2.9/4.1.0/collect2 -V -Y P,/usr/ccs/lib:/usr/lib -rpath-link /usr/lib -Qy /usr/local/gcc-4.1.0/lib/gcc/sparc-sun-solaris2.9/4.1.0/crt1.o /usr/local/gcc-4.1.0/lib/gcc/sparc-sun-solaris2.9/4.1.0/crti.o /usr/ccs/lib/values-Xa.o /usr/local/gcc-4.1.0/lib/gcc/sparc-sun-solaris2.9/4.1.0/crtbegin.o -L/usr/local/gcc-4.1.0/lib/gcc/sparc-sun-solaris2.9/4.1.0 -L/usr/ccs/lib -L/usr/local/gcc-4.1.0/lib/gcc/sparc-sun-solaris2.9/4.1.0/../../.. /var/tmp//cccuUoEg.o -lgcc -lgcc_eh -lc -lgcc -lgcc_eh -lc /usr/local/gcc-4.1.0/lib/gcc/sparc-sun-solaris2.9/4.1.0/crtend.o /usr/local/gcc-4.1.0/lib/gcc/sparc-sun-solaris2.9/4.1.0/crtn.o GNU ld version 2.16.1 Supported emulations: elf32_sparc elf64_sparc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27629
[Bug target/27629] SIGSEGV in printstack()
--- Comment #5 from sebor at roguewave dot com 2006-05-17 17:43 --- I'm told that the fault is due to a known problem in the Sun libc: 6372620 printstack() segfaults when called from static function It this doesn't provide sufficient detail to work around the bug in gcc (assuming you choose to do so) let me know. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27629
[Bug target/27629] SIGSEGV in printstack()
--- Comment #7 from sebor at roguewave dot com 2006-05-17 18:34 --- Maybe it's one of the runtime library functions that's static (maybe _start?). The diff between the two .s files is empty. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27629
[Bug target/27629] SIGSEGV in printstack()
--- Comment #9 from sebor at roguewave dot com 2006-05-17 21:35 ---
Here's what I learned from Sun:
Here is the test case from that bug report:
[Makefile]
main: main.o libshibby.so
gcc -L. -lshibby -Wl,-R. -o main main.o
main.o: main.c
gcc -c -o main.o main.c
libshibby.so: shibby.c
gcc -c shibby.c -fPIC -o shibby.o
/usr/ccs/bin/ld -G -dy -z text -Y P,/usr/ccs/lib:/usr/lib \
-Qy -o libshibby.so shibby.o
clean:
rm *.o *.so
[main.c]
int main(int argc, char *argv[])
{
shibby();
return 0;
}
[shibby.c]
#include
static void foo()
{
printstack(1);
}
void shibby()
{
foo();
}
Here is the workaround:
Making the function calling printstack() global
instead of static will avoid this situation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27629
[Bug c++/27788] New: error casting address of a function template specialization
The well-formed program below fails to compile with gcc 4.1.0:
$ cat t.cpp && gcc -c t.cpp
template void foo (T*) { }
typedef void F ();
F* f = (F*)&foo;
t.cpp:5: error: address of overloaded function with no contextual type
information
--
Summary: error casting address of a function template
specialization
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: all
GCC host triplet: all
GCC target triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27788
[Bug libstdc++/28103] New: std::operator<<(ostream&, string) sets badbit instead of failbit on failure
21.3.7.9, p4 requires the operator to set failbit, not badbit, on failure. This
came up while I was gathering background for c++std-lib-17241.
$ cat ~/tmp/t.cpp && g++ ~/tmp/t.cpp -static && ./a.out
#include
#include
#include
#include
int main ()
{
char buf [3];
std::ostrstream os (buf, sizeof (buf));
os << std::string ("1234");
std::printf ("state = %c%c%c (expected --?)\n",
os.rdstate () & os.badbit ? 'B' : '-',
os.rdstate () & os.eofbit ? 'E' : '-',
os.rdstate () & os.failbit ? 'F' : '-');
std::fflush (stdout);
assert (!(os.rdstate () & os.badbit));
}
In file included from
/usr/local/gcc-4.1.0/lib/gcc/sparc-sun-solaris2.9/4.1.0/../../../../include/c++/4.1.0/backward/strstream:51,
from /nfs/b20/sebor/tmp/t.cpp:4:
/usr/local/gcc-4.1.0/lib/gcc/sparc-sun-solaris2.9/4.1.0/../../../../include/c++/4.1.0/backward/backward_warning.h:32:2:
warning: #warning This file includes at least one deprecated or antiquated
header. Please consider using one of the 32 headers found in section 17.4.1.2
of the C++ standard. Examples include substituting the header for the
header for C++ includes, or instead of the deprecated header
. To disable this warning use -Wno-deprecated.
state = B-- (expected --?)
Assertion failed: !(os.rdstate () & os.badbit), file /nfs/b20/sebor/tmp/t.cpp,
line 21
Abort (core dumped)
--
Summary: std::operator<<(ostream&, string) sets badbit instead of
failbit on failure
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
GCC build triplet: all
GCC host triplet: all
GCC target triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28103
[Bug c++/28351] New: SIGSEGV rethrowing an exception with -m64 -static on ppc/linux
We're seeing the behavior below in 64-bit statically linked programs on
PowerPC/Linux (this has the same effect: gcc -m64 t.cpp -lsupc++). Here's
the stack trace, if it helps at all:
#0 0x100010e8 in .__cxa_get_globals_fast ()
#1 0x1d60 in .__cxa_end_catch ()
#2 0x1a98 in main () at t.cpp:10
$ cat t.cpp && gcc --version && g++ -m64 t.cpp -static && ./a.out
void foo () { throw 0; }
int main ()
{
try {
try {
foo ();
}
catch (...) {
throw;
}
}
catch (...) {
return 0;
}
return 1;
}
$ cat t.cpp && gcc --version && g++ -m64 t.cpp -static && ./a.out
void foo () { throw 0; }
int main ()
{
try {
try {
foo ();
}
catch (...) {
throw;
}
}
catch (...) {
return 0;
}
return 1;
}
gcc (GCC) 3.3.3 (SuSE Linux)
Copyright (C) 2003 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.
Segmentation fault
gcc (GCC) 3.3.3 (SuSE Linux)
Copyright (C) 2003 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.
Segmentation fault
--
Summary: SIGSEGV rethrowing an exception with -m64 -static on
ppc/linux
Product: gcc
Version: 3.3.3
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: powerpc-suse-linux
GCC host triplet: powerpc-suse-linux
GCC target triplet: powerpc-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28351
[Bug c++/28351] SIGSEGV rethrowing an exception with -m64 -static on ppc/linux
--- Comment #2 from sebor at roguewave dot com 2006-07-11 21:42 --- Libc says it's 2.3.3 (20040412). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28351
[Bug c++/28365] error: ' error: 'MyClass::MyClass(const MyClass&)' is private error: within this context
--- Comment #2 from sebor at roguewave dot com 2006-07-13 19:07 --- If it is in our (Rogue Wave) current code, could you please let us know where so we can look into fixing it? (It's doesn't matter whther gcc does the right thing here or not, our code should be portable either way.) Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28365
[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 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
#include
#include
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++/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] 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 struct S { T foo (); };
template T S::foo () { return T (); }
template struct S;
extern template struct S;
int main () { return S().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 struct S { T foo (); };
>>> template T S::foo () { return T (); };
>>> template struct S;
>>> extern template struct S;
>>> int main () { return S().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
#include
#include
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()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 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++/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=17044&action=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 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
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 c++/24948] New: lookup chooses the wrong overload
I believe gcc is in error for calling the int* overload in the program below.
Sorry if this is a duplicate -- I went through the many lookup bugs in Bugzilla
but none of them looked quite like this one.
$ cat t.cpp && g++ -pedantic -W t.cpp && ./a.out
#include
int foo (void*) { return 0; }
template int bar (T *p) { return foo (p); }
int foo (int*) { return 1; }
int main ()
{
assert (0 == bar ((int*)0));
}
Assertion failed: 0 == bar ((int*)0), file t.cpp, line 9
Abort (core dumped)
--
Summary: lookup chooses the wrong overload
Product: gcc
Version: 4.0.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: all
GCC host triplet: all
GCC target triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24948
[Bug libstdc++/25304] New: std::fill_n, std::generate_n incorrect signature
Both template functions are required to return void.
$ cat u.cpp && g++ -c u.cpp
#include
template void std::fill_n (int*, int, const int&);
template void std::generate_n (int*, int, int (*)());
int main () { }
u.cpp:3: error: template-id 'fill_n<>' for 'void std::fill_n(int*, int, const
int&)' does not match any template declaration
u.cpp:4: error: template-id 'generate_n<>' for 'void std::generate_n(int*, int,
int (*)())' does not match any template declaration
--
Summary: std::fill_n, std::generate_n incorrect signature
Product: gcc
Version: 4.0.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: all
GCC host triplet: all
GCC target triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25304
[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature
--- Comment #7 from sebor at roguewave dot com 2005-12-08 00:08 --- FWIW, I think Andrew makes a good point in comment #1. The algorithms really should return the iterator, otherwise the caller may not be able to find out the state of the iterator after the algorithm returns (e.g., when the iterator is ostreambuf_iterator). It may not be a bad idea to open an issue (or at least bring it up on the reflector). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25304
[Bug libstdc++/25306] New: fill_n, generate_n assume Size is modifiable
I came across this while gathering background for my post in c++std-lib-16112.
I thgought I might as well let you know in case you think it's important enough
to worry about (Size is only required to be convertible to an integral type
which doesn't mean it needs to have the predecrement operator defined). The
incorrect return type in this test case works around bug #25304.
$ cat t.cpp && g++ -c t.cpp
#include
struct Size {
operator int() { return 0; }
private:
void operator=(Size&);
};
template int* std::fill_n (int*, Size, const int&);
template int* std::generate_n (int*, Size, int (*)());
int main () { }
/usr/local/gcc-4.0.2/lib/gcc/sparc-sun-solaris2.9/4.0.2/../../../../include/c++/4.0.2/bits/stl_algo.h:
In function '_OutputIterator std::generate_n(_OutputIterator, _Size,
_Generator) [with _OutputIterator = int*, _Size = Size, _Generator = int
(*)()]':
t.cpp:10: instantiated from here
/usr/local/gcc-4.0.2/lib/gcc/sparc-sun-solaris2.9/4.0.2/../../../../include/c++/4.0.2/bits/stl_algo.h:1003:
error: no match for 'operator--' in '--__n'
/usr/local/gcc-4.0.2/lib/gcc/sparc-sun-solaris2.9/4.0.2/../../../../include/c++/4.0.2/bits/stl_algobase.h:
In static member function 'static _OutputIterator
std::__fill_n::fill_n(_OutputIterator, _Size, const _Tp&) [with
_OutputIterator = int*, _Size = Size, _Tp = int]':
/usr/local/gcc-4.0.2/lib/gcc/sparc-sun-solaris2.9/4.0.2/../../../../include/c++/4.0.2/bits/stl_algobase.h:642:
instantiated from '_OutputIterator std::fill_n(_OutputIterator, _Size, const
_Tp&) [with _OutputIterator = int*, _Size = Size, _Tp = int]'
t.cpp:9: instantiated from here
/usr/local/gcc-4.0.2/lib/gcc/sparc-sun-solaris2.9/4.0.2/../../../../include/c++/4.0.2/bits/stl_algobase.h:617:
error: no match for 'operator--' in '--__n'
--
Summary: fill_n, generate_n assume Size is modifiable
Product: gcc
Version: 4.0.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: all
GCC host triplet: all
GCC target triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25306
[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature
--- Comment #10 from sebor at roguewave dot com 2005-12-08 15:51 --- No, I don't. The standard is clear and most of us seem to think it's "by design." Rather I am suggesting is that we might want to discuss with the whole LWG changing the return type as an enhancement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25304
[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature
--- Comment #15 from sebor at roguewave dot com 2005-12-08 16:27 --- (In reply to comment #11) Okay, I see your concern. Well, IMO, your signatures are better than those required by the standard so if you care about 100% compliance you (or Paolo -- and I promise not to beat him ;-) should open an issue with the LWG and try to get the standard changed. I will support the change. Until the LWG issue is resolved (and hopefully even after that) you can leave your signatures alone. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25304
[Bug libstdc++/25306] fill_n, generate_n assume Size is modifiable
--- Comment #3 from sebor at roguewave dot com 2006-01-10 16:14 --- (In reply to comment #2) I'm not sure what you mean. Could you show what one of the algorithms would look like with a Size that's not convertible to an integer? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25306
[Bug c++/28656] New: unhelpful null argument warning on memcpy()
The warning below doesn't seem justified and is not helpful (certainly not in
this case or whenever the last argument can be proven to be 0). IMO, where the
warning would be helpful is the second invocation of memcpy() since that one
has undefined behavior.
$ cat -n t.cpp && g++ -Wall t.cpp
1 #include
2
3 int main ()
4 {
5 memcpy (0, 0, 0);
6
7 int i = 0;
8 memcpy (&i, &i, sizeof i);
9 }
10
t.cpp: In function 'int main()':
t.cpp:5: warning: null argument where non-null required (argument 1)
t.cpp:5: warning: null argument where non-null required (argument 2)
--
Summary: unhelpful null argument warning on memcpy()
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=28656
[Bug libstdc++/29026] std::basic_istream<>::sentry() fails to catch when reading whitespace
--- Comment #3 from sebor at roguewave dot com 2006-09-11 21:25 --- This sounds like it might be related to http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309. If so, and if this case is important to you (the submitter) it might be helpful to give the committee a little nudge on comp.std.c++ to make sure the issue gets addressed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29026
[Bug libstdc++/29026] std::basic_istream<>::sentry() fails to catch when reading whitespace
--- Comment #5 from sebor at roguewave dot com 2006-09-12 00:16 --- The reason why I think library issue 309 may be relevant is because while the arithmetic extraction operator>>() is a formatted input function (and thus subject to 27.6.1.1, p4, and required to begin by constructing a sentry object), the sentry ctor is neither a formatted nor unformatted input function, and thus could be considered exempt from the requirements imposed by 27.6.1.1, p4 on the two groups of input functions. The sentry ctor need not even call sgetc() or sbumpc() (e.g., it could call underflow() directly). Further, since the description of the extraction operators clearly separates the initial construction of the sentry from subsequently "obtaining the requested input," an exception thrown during the construction of the sentry could be considered as having occurred prior to "obtaining the requested input" and thus be allowed, in fact required, to propagate to the caller. Note that the impact of the issue isn't just on the extraction operators defined by the library, it affects user-defined extraction operators as well, specifically those that make use of the sentry and that aim to conform to the general iostream exception safety requirements. My "additional comments" on the issue explain how and why. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29026
[Bug libstdc++/29035] Initialisation of std::ostringstream does not work correctly
--- Comment #5 from sebor at roguewave dot com 2006-09-12 16:16 --- (In reply to comment #4) Shouldn't the output be: 6 azerty123 9 -- sebor at roguewave dot com changed: What|Removed |Added CC||sebor at roguewave dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29035
[Bug libstdc++/29035] Initialisation of std::ostringstream does not work correctly
--- Comment #8 from sebor at roguewave dot com 2006-09-12 17:24 --- No, I'm not sure. I got the output with our implementation but the latest working paper doesn't seem to support it (I had misread the text in 27.7.1.2, p2 to require that pptr() == epptr() uncoditionally rather than just in input mode). I'll need to check more carefully why we do what we do. Sorry for the noise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29035
[Bug libstdc++/29035] Initialisation of std::ostringstream does not work correctly
--- Comment #10 from sebor at roguewave dot com 2006-09-12 17:44 --- I think you're right. Even my own issue 562 is clear on this. I must have a bug in the implementation of the resolution of the issue. http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#562 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29035
[Bug c++/29185] New: inconsistent warning: deleting array
Gcc 4.1.0 warns about the (ill-fomed?) delete expression on line 5 but fails
to issue a diagnostic for the similar expressions on lines 6 and 7. I would
like to request that it consistently diagnose all such cases.
$ cat t.cpp && gcc -c t.cpp
/* 1 */ int a [1];
/* 2 */ struct S { int a [1]; } s;
/* 3 */
/* 4 */ void foo (S *p) {
/* 5 */ delete a;
/* 6 */ delete s.a;
/* 7 */ delete p->a;
/* 8 */ }
t.cpp: In function 'void foo(S*)':
t.cpp:5: warning: deleting array 'int a [1]'
--
Summary: inconsistent warning: deleting array
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: all
GCC host triplet: all
GCC target triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29185
[Bug c++/29185] inconsistent warning: deleting array
--- Comment #2 from sebor at roguewave dot com 2006-09-22 16:57 --- Yes, but 5.3.5, p1 says "The operand shall have a pointer type, or a class type having a single conversion function (12.3.2) to a pointer type." and not "shall be convertible to a pointer type." Note that gcc issues a hard error for a dynamic_cast expression whose argument is an array, so I would expect it to treat the delete expression the same since they both have the same requirement WRT pointers. Btw., I sent an email to EDG to request that they at least warn and to find out whether they think it's well-formed. I'll update the incident with their response. Also note that both IBM XLC++ and HP aCC issue an error for the test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29185
[Bug c++/29185] inconsistent warning: deleting array
--- Comment #3 from sebor at roguewave dot com 2006-09-26 16:31 --- The response I got from EDG is that the expression is well-formed because of 5, p8. They do agree that issuing a warning would be useful and opened an enhancement request. FWIW, I think it should be ill-formed with diagnostic required since the behavior of the expression is always undefined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29185
[Bug c++/29185] inconsistent warning: deleting array
--- Comment #5 from sebor at roguewave dot com 2006-09-26 18:56 ---
You mean something like: if (is_pointer (p)) delete p;
I suppose that could happen but why should it be any different than other
non-sensical but lexically valid constructs with undefined behavior that
require a diagnostic today? E.g.:
template
void foo () {
if (0 < N) {
int array [N];
...
}
}
Or:
template
U* bar (T *p) {
if (is_convertible)
return p;
return 0;
}
Isn't template metaprogramming the expected solution to this type of a problem?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29185
[Bug c++/29185] inconsistent warning: deleting array
--- Comment #7 from sebor at roguewave dot com 2006-09-26 21:43 --- You're right, those weren't the best examples, but I still think they illustrate the point. The code in them is plain ill-formed even though it never gets executed, because it just doesn't make sense. deleting an array also doesn't make sense so it might as well be ill-formed. I'll leave it to the committee to decide if that's a worthwhile change to the language. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29185
[Bug c++/29273] New: error on dynamic_cast(array)
Gcc gives an error for the dynamic_cast below. During the discussion of bug
29185 with EDG it turned out that according to 5, p8, the code is well-formed
and should not be diagnosed.
$ cat t.cpp && gcc t.cpp
struct A { virtual ~A () { } };
struct B: A { } b [1];
void foo ()
{
dynamic_cast(b);
}
t.cpp: In function 'void foo()':
t.cpp:6: error: cannot dynamic_cast 'b' (of type 'struct B [1]') to type
'struct B*' (source is not a pointer)
--
Summary: error on dynamic_cast(array)
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: all
GCC host triplet: all
GCC target triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29273
[Bug c++/29185] inconsistent warning: deleting array
--- Comment #8 from sebor at roguewave dot com 2006-09-28 16:16 --- The EDG guys don't think this is worth spending the committee's time on so I won't be proposing any change to the standard. Issuing just a warning rather than an error is good enough for me. Also, I opened bug 29273 to remove the error from the dynamic_cast expression with an array argument since that one is well-formed as well (see comment 2), according to the same paragraph. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29185
[Bug c++/29298] rejects valid specialization of member template classes
--- Comment #5 from sebor at roguewave dot com 2006-10-02 19:19 --- Interesting. The vanilla EDG front end rejects it as expected. I wonder why Intel accepts it when neither EDG nor gcc does. Maybe we should open a bug with them to find out ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29298
[Bug c++/28656] duplicated null argument warning on memcpy()
--- Comment #3 from sebor at roguewave dot com 2006-10-13 21:02 --- You're right, I missed that. I confess I don't quite understand the rationale for this in the standard and I'm not aware of any plaform that causes problems for such calls but based on Doug Gwyn's response to my query the undefined behavior is intentional. Go figure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28656
[Bug c/29465] New: warning for overlapping memcpy()
I would like to propose that gcc (in both C and C++ modes) issue a warning
for calls to memcpy() with overlapping regions of memory (known at compile
time) such as the one below since the behavior of such calls is undefined.
#include
int main ()
{
int i = 0;
memcpy (&i, &i, sizeof i);
return 0;
}
--
Summary: warning for overlapping memcpy()
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: all
GCC host triplet: all
GCC target triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29465
[Bug c++/28656] duplicated null argument warning on memcpy()
--- Comment #4 from sebor at roguewave dot com 2006-10-13 21:09 --- I opened bug 29465 with a request for the new warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28656
[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 inline const T& min_ref (const T &x, const T &y) { return x
< y ? x : y; }
template inline const T* min_ptr (const T *x, const T *y) { return *x
< *y ? x : y; }
template 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 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++/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++/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++/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
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
struct Triple __attribute__ ((reorder)) {
public: T a; public: U b; public: V c;
};
or, alternatively, like so:
template
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++/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=13212&action=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
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
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
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++/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++/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++/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++/33786] New: "C" data and static const data members mangled the same
When compiled with gcc 4.1.0 on Linux, the program below causes the assembler
to issue an error complaining about foobar being defined twice. I believe the
program is well-formed and should compile and run successfully to completion
(it does with Intel C++ 10.0 on Linux).
$ cat x.cpp && gcc -dumpversion && gcc x.cpp
namespace N {
extern "C" {
extern const int foobar;
const int foobar = 1;
struct S { static const int foobar; };
const int S::foobar = 2;
}
}
int main () { return !(N::foobar + 1 == N::S::foobar); }
4.1.0
/tmp/ccL0oF3c.s: Assembler messages:
/tmp/ccL0oF3c.s:29: Error: symbol `foobar' is already defined
--
Summary: "C" data and static const data members mangled the same
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=33786
[Bug c++/20644] New: bogus uninitialized warning on unused variable
The warning below is inappropriate since j can never be used in the function.
$ cat t.cpp && gcc -c -O -W t.cpp
int foo ()
{
int i;
int j;
for ( ; ; ) {
i = 0;
if (0 == i)
break;
}
if (1 == i)
return j;
return 0;
}
t.cpp: In function `int foo()':
t.cpp:4: warning: 'j' might be used uninitialized in this function
--
Summary: bogus uninitialized warning on unused variable
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: all
GCC host triplet: all
GCC target triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20644
[Bug middle-end/20644] bogus uninitialized warning on unused variable
--- Additional Comments From sebor at roguewave dot com 2005-03-26 01:08 --- I can imagine that it may not be straightforward to fix but I can't think of a reason why a warning could ever be useful in this case (i.e., when the code is provably safe). I could of course be missing something -- could you point me to the discussion where this was decided? Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20644
[Bug c/20951] New: bogus error passing &va_list to va_list*
The program below fails to compile with gcc on EM64T. I believe the program is
well-formed based on 7.15.1.1 of C99, Footnote 212 (I am aware that footnotes
are not normative).
The second program below uses va_copy to get around the compilation error in the
first case fails to compile with the -ansi option (I am aware of gcc-specific
__builtin_va_copy). Even if the program did compile the solution seems
unreasonably complicated.
Can you confirm whether you agree that this is a conformance bug or not and if
not explain why not?
$ cat t.cpp && g++ --version && g++ -c t.cpp
#include
void foo (int, va_list*);
void bar (int i, va_list va)
{
foo (i, &va);
}
g++ (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-47)
Copyright (C) 2002 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.cpp: In function `void bar(int, __va_list_tag*)':
t.cpp:7: cannot convert `__va_list_tag**' to `__va_list_tag (*)[1]' for
argument `2' to `void foo(int, __va_list_tag (*)[1])'
$ cat t.cpp && g++ --version && g++ -ansi t.cpp
#include
#include
#include
int a [3];
int foo (int i, va_list *pva)
{
a [i++] = va_arg (*pva, int);
return i;
}
void bar (int i, va_list va)
{
a [i++] = va_arg (va, int);
#ifdef va_copy
va_list cpy;
va_copy (cpy, va);
va_end (va);
i = foo (i, &cpy);
va_copy (va, cpy);
va_end (cpy);
#else
i = foo (i, &va);
#endif
a [i++] = va_arg (va, int);
}
void baz (int i, ...)
{
va_list va;
va_start (va, i);
bar (i, va);
va_end (va);
}
int main ()
{
baz (0, 1, 2, 3);
printf ("%d, %d, %d\n", a [0], a [1], a [2]);
assert (1 == a [0]);
assert (2 == a [1]);
assert (3 == a [2]);
}
g++ (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-47)
Copyright (C) 2002 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.cpp: In function `void bar(int, __va_list_tag*)':
t.cpp:25: cannot convert `__va_list_tag**' to `__va_list_tag (*)[1]' for
argument `2' to `int foo(int, __va_list_tag (*)[1])'
--
Summary: bogus error passing &va_list to va_list*
Product: gcc
Version: 3.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
CC: gcc-bugs at gcc dot gnu dot org
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=20951
[Bug c/20951] bogus error passing &va_list to va_list*
--- Additional Comments From sebor at roguewave dot com 2005-04-11 17:33 --- (In reply to comment #1) Right. I understand why it doesn't compile and how to work around it (with gcc at least). What I'm still not convinced of is that it's not a strict conformance bug. The same point was raised in the discussion you pointed me to but I couldn't find where it was addressed or if it was communicated to WG14. I.e., even if the requirement in C99 (that makes the test case well-formed) is non-normative and bogus, strictly speaking this would still be a conformance bug in the gcc implementation of va_list (after all, it is a gcc builtin, so it seems that the compiler could do some magic whereby taking the address of a va_list declared as an argument to a function would produce va_list* and not va_list**). Do you happen to know whether there's a C99 issue to fix the footnote? -- What|Removed |Added Component|target |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20951
[Bug c/20951] bogus error passing &va_list to va_list*
--- Additional Comments From sebor at roguewave dot com 2005-04-11 17:51 --- Yes, I read that comment but I still don't see anything in the standard the footnote is in conflict with and I don't see it on the WG14 DR list(*). If the footnote is bogus and va_list can't be universally implemented to allow programs to initialize a va_list* with the address of a va_list function argument,it ought to be taken out of the standard. If you are not aware of an issue against the C standard I'll be happy to send it to the committee myself. (*) http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20951
[Bug c/20951] bogus error passing &va_list to va_list*
--- Additional Comments From sebor at roguewave dot com 2005-04-13 22:06 --- (In reply to comment #5) Thanks for the pointer. Let me try again to explain why I object to the footnote: The footnote assumes that the reader will make the extrapolation that 1) since va_list is an object type, and 2) since array types are (also) object types, and 3) since array types in function arguments are converted to pointers, the actual type of a va_list object when declared as a function argument need not in fact be va_list but va_list*, despite the fact the declaration clearly appears to say otherwise. I am not a casual reader of the standard -- I read and interpret standards for a living. It seems that if I have trouble making that leap above it may not be so obvious to others either (as demonstrated by the lively discussion in the referenced bug). Perhaps removing the footnote is an unnecessarily drastic change. But clarifying it by mentioning the caveat above would, IMO, go a long way toward helping readers avoid the trap that I (and others) fell into. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20951
[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++/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++/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++/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
#include
const char* foobar (void*) { return 0; }
template struct S { static const char* foo () { return 0; } };
template
struct S { static const char* foo () { return foobar (T ()); } };
int main () {
va_list va;
memset (&va, 0, sizeof va);
S::foo ();
}
t.C: In static member function 'static const char* S::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
#include
#include
#include
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 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
#include
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++/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 . 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 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 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 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 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=17300&action=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=17301&action=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 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 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++/39637] New: ICE on ill-formed sizeof() 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
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() 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
template
struct S: S<...Types>, S<...Types...>, S<...>
{
static const char* f () { return __PRETTY_FUNCTION__; }
};
int main ()
{
std::puts (S::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* S::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
