[Bug c++/44311] New: no error with switch over enum class and integer case
$ cat t.cc
enum class A { Val0, Val1 };
void foo( A a )
{
switch( a )
{
case A::Val0: break;
case 1: break;
}
}
$ g++ -std=c++0x -c template.cc
works
I think there should be a compile error in line 8.
--
Summary: no error with switch over enum class and integer case
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44311
[Bug driver/43970] New: configure --with-local-prefix=no does nothing
$ gcc -v Using built-in specs. COLLECT_GCC=/tools/pkg/gcc/4.5.0/bin/gcc COLLECT_LTO_WRAPPER=/tools/pkg/gcc/4.5.0/libexec/gcc/i386-pc-solaris2.10/4.5.0/lto-wrapper Target: i386-pc-solaris2.10 Configured with: gcc-4.5.0/configure --enable-languages=c,c++ --disable-bootstrap --disable-nls --with-local-prefix=no --with-as=/tools/pkg/binutils/2.19/bin/as --with-ld=/tools/pkg/binutils/2.19/bin/ld --prefix=/tools/pkg/gcc/4.5.0 Thread model: posix gcc version 4.5.0 (GCC) I got this '--with-local-prefix=no' from looking at gcc/configure But it doesn't work as expected: $ touch a.c $ gcc -v a.c ... #include ... search starts here: #include ... search starts here: /usr/local/include /tools/pkg/gcc/4.5.0/include /tools/pkg/gcc/4.5.0/lib/gcc/i386-pc-solaris2.10/4.5.0/include /tools/pkg/gcc/4.5.0/lib/gcc/i386-pc-solaris2.10/4.5.0/include-fixed /usr/include End of search list. ... /usr/local/include is still there. What is the correct way to have no local prefix? -- Summary: configure --with-local-prefix=no does nothing Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joerg dot richter at pdv-fs dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43970
[Bug c++/43932] New: conditional operator can't convert 0 to pointer
$ cat t.cc
void* func( bool b )
{
return b ? 0 : throw 5;
}
$ g++ -c t.cc
template.cc: In function 'void* func(bool)':
template.cc:3:24: error: invalid conversion from 'int' to 'void*'
Replace 'throw 5' with '0' and it compiles as expected.
--
Summary: conditional operator can't convert 0 to pointer
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43932
[Bug c++/43932] conditional operator can't convert 0 to pointer
--- Comment #2 from joerg dot richter at pdv-fs dot de 2010-04-29 12:54
---
But throw can be part of ?: operator:
$ cat t.cc
int func( bool b )
{
return b ? 0 : throw 5;
}
$ g++ -c t.cc
works
--
joerg dot richter at pdv-fs dot de changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43932
[Bug libstdc++/40925] [c++0x] std::pairT*,U* constructor doesn't accept (0, 0)
--- Comment #5 from joerg dot richter at pdv-fs dot de 2009-09-18 13:47 --- I found Doug Gregors workaround for this pair problem: http://gcc.gnu.org/ml/libstdc++/2008-10/msg00080.html I wonder why it was reverted 9 days later? I couldn't find any discussion on gcc-patches nor libstdc++. Perhaps I have missed something. Was this patch not good enough? The reason I ask is that I want to use C++0x. Currently I do this with -std=gnu++0x -U__GXX_EXPERIMENTAL_CXX0X__ I undefine __GXX_EXPERIMENTAL_CXX0X__ just because of the pair(0) problem. But unfortunately this doesn't give me the library features of C++0x :( -- joerg dot richter at pdv-fs dot de changed: What|Removed |Added CC||joerg dot richter at pdv-fs ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40925
[Bug c++/41373] New: attribute error and warning dont show the instantiation stack
Using functions with attribute error/warning from templates doesn't
output the instantiation stack. With attribute deprecated this works.
Consider this program:
/
void func() __attribute__ ((error(error)));
//void func() __attribute__ ((warning(warning)));
//void func() __attribute__ ((deprecated));
void func()
{}
templateclass T
void bar()
{
func();
}
int main( int, char** )
{
barint();
}
/
With attribute error:
t.cc: In function 'void bar() [with T = int]':
t.cc:11: error: call to 'func' declared with attribute error: error
With attribute deprecated:
t.cc: In function 'void bar() [with T = int]':
t.cc:16: instantiated from here
t.cc:11: warning: 'void func()' is deprecated (declared at t.cc:5)
--
Summary: attribute error and warning dont show the instantiation
stack
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41373
[Bug libstdc++/32354] libstdc++.so.6 missing RPATH
--- Comment #6 from joerg dot richter at pdv-fs dot de 2009-07-15 13:15 --- I stumpled across the same problem recently. Executable references both libstdc++.so and libgcc_s.so. libstdc++.so references libgcc_s.so. Both executable dependencies will be correctly resolved (due to RPATH). But when the dynamic linker tries to resolve the second reference to libgcc_s.so it is not using the RPATH of the executable. Only the (not existing) RPATH of libstdc++.so. Which is correct IMHO. So it goes on and tries the system default search directories. There it finds another libgcc_s.so. But this time it is an old version. The executable refused to start, because some versioned symbols could not be found. If libstdc++.so would be linked with -rpath '$ORIGIN' this would work. Note that this even works, when libstdc++.so and libgcc_s.so are moved to a different location. So I think this bug should be reopened. Note: this was observed on solaris2.10 -- joerg dot richter at pdv-fs dot de changed: What|Removed |Added CC||joerg dot richter at pdv-fs ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32354
[Bug libstdc++/36363] New: set_union and _GLIBCXX_DEBUG does not compile
#include algorithm
#include vector
using namespace std;
int main( int, char** )
{
vectorint v1;
vectorint v2;
vectorint v3;
set_union( v1.begin(), v1.end(), v2.begin(), v2.end(), v3.begin() );
return 0;
}
$ g++ -o t t.cc -D_GLIBCXX_DEBUG
...
debug/functions.h:317: error: no matching function for call to
__check_sorted_set_aux()
...
--
Summary: set_union and _GLIBCXX_DEBUG does not compile
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36363
[Bug other/36368] New: Fixincludes corrupts sysmacros.h
Compiling this program:
#include sys/types.h
$ gcc a.c
In file included from /usr/include/sys/types.h:219,
from a.c:1:
/pdv/.tools/pkg/gcc/4.3.0/bin/../lib/gcc/i686-pc-linux-gnu/4.3.0/include-fixed/sys/sysmacros.h:52:
error: expected ',' or ';' before '{' token
/pdv/.tools/pkg/gcc/4.3.0/bin/../lib/gcc/i686-pc-linux-gnu/4.3.0/include-fixed/sys/sysmacros.h:58:
error: expected ',' or ';' before '{' token
/pdv/.tools/pkg/gcc/4.3.0/bin/../lib/gcc/i686-pc-linux-gnu/4.3.0/include-fixed/sys/sysmacros.h:64:
error: expected ',' or ';' before '{' token
$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with:
/ws/jrichter/nfs/src/bld/cfg/build/tmp.evo4.19802/gcc-4.3.0/configure
--prefix=/tools/pkg/gcc/4.3.0 --enable-languages=c,c++ --disable-threads
--with-gmp=/tools/pkg/gmp/4.2.2 --with-mpfr=/tools/pkg/mpfr/2.3.1
Thread model: single
gcc version 4.3.0 (GCC)
$ uname -a
Linux evo4 2.4.21-47.0.1.ELsmp #1 SMP Fri Oct 13 17:56:20 EDT 2006 i686 i686
i386 GNU/Linux
Here is the relevant part of diff -u /usr/include/sys/sysmacros.h
.../include-fixed/sys/sysmacros.h
# if defined __GNUC__ __GNUC__ = 2
-__extension__ extern __inline unsigned int
-__NTH (gnu_dev_major (unsigned long long int __dev))
+__extension__ extern __inline __attribute__ ((__gnu_inline__)) unsigned int
+gnu_dev_major (unsigned long long int __dev) __THROW
{
return ((__dev 8) 0xfff) | ((unsigned int) (__dev 32) ~0xfff);
}
Note that __THROW expands to __attribute__ ((__nothrow__)) when compiling in C.
But it seems this attribute isn't allowed on function definitions.
--
Summary: Fixincludes corrupts sysmacros.h
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36368
[Bug other/36368] Fixincludes corrupts sysmacros.h
--- Comment #2 from joerg dot richter at pdv-fs dot de 2008-05-29 12:21 --- Seems I've used gcc on a machine with a newer libc than it was built on. Sorry for the noise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36368
[Bug c++/36372] New: printf format and templates doesn't work anymore
templateclass T void
myPrintf( const char * fmt, ... )
__attribute__ ((__format__ (__printf__, 1, 2)));
templateclass T void
myPrintf( const char * fmt, ... )
{
}
void func()
{
myPrintfint( test );
}
$ g++ t.cc
t.cc: In function 'void func()':
t.cc:6: error: '__printf__' was not declared in this scope
t.cc:6: error: unrecognized format specifier
Works with GCC 4.1.1
--
Summary: printf format and templates doesn't work anymore
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36372
[Bug c++/35398] New: unable to take address of template function
templateint
void foo()
{}
void test()
{
foo1(); // (1)
void (*func)() = foo1; // (2)
foo1;// (3)
void* d = (void*)foo1; // (4)
}
(1) and (2) are OK.
(3) fails with:
error: statement cannot resolve address of overloaded function
(4) fails with:
error: insufficient contextual information to determine type
--
Summary: unable to take address of template function
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35398
[Bug libstdc++/31957] Build of compiler fails with 'error: #endif without #if'
--- Comment #12 from joerg dot richter at pdv-fs dot de 2007-07-05 11:17 --- Of course, you are right. :) Just want to confirm, that all s,g,g, and s,^,, and b seem to work fine with AIX-sed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31957
[Bug libstdc++/31957] Build of compiler fails with 'error: #endif without #if'
--- Comment #9 from joerg dot richter at pdv-fs dot de 2007-07-05 11:00 --- I think the last g in 's,g,g,g' is the important one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31957
[Bug libstdc++/31957] Build of compiler fails with 'error: #endif without #if'
--- Comment #4 from joerg dot richter at pdv-fs dot de 2007-07-04 19:48 --- Any chance that this gets fixed with 4.2.1? This is the only thing on AIX that prevents an unpatched bootstrap. Or perhaps its only missing documentation that GNU sed must be used. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31957
[Bug libstdc++/31957] Build of compiler fails with 'error: #endif without #if'
--- Comment #3 from joerg dot richter at pdv-fs dot de 2007-06-07 10:03 --- Well, $ which sed /usr/bin/sed $ /usr/bin/sed -e '' sed: 0602-429 No editing script was provided. Usage: sed [-n] Script [File ...] sed [-n] [-e Script] ... [-f Script_file] ... [File ...] Can it be that everyone else is using GNU-sed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31957
[Bug libstdc++/31957] Build of compiler fails with 'error: #endif without #if'
--- Comment #1 from joerg dot richter at pdv-fs dot de 2007-05-30 08:47
---
AIX/sed doesn't allow sed -e ''.
Can't currently attach patches. Here is it inline:
--- libstdc++-v3/include/Makefile.in.old2007-05-30 10:03:19.0
+0200
+++ libstdc++-v3/include/Makefile.in2007-05-30 10:06:03.0 +0200
@@ -1372,7 +1372,7 @@
@date=`cat ${toplevel_srcdir}/gcc/DATESTAMP` ;\
nsa_version=`cat stamp-namespace-version` ;\
visibility=`cat stamp-visibility` ;\
- ldbl_compat='' ;\
+ ldbl_compat='s,g,g,g' ;\
grep ^[]*#[]*define[ ][
]*_GLIBCXX_LONG_DOUBLE_COMPAT[ ][ ]*1[]*$$ \
${CONFIG_HEADER} /dev/null 21 \
ldbl_compat='s,^#undef _GLIBCXX_LONG_DOUBLE_COMPAT$$,#define
_GLIBCXX_LONG_DOUBLE_COMPAT 1,' ;\
--
joerg dot richter at pdv-fs dot de changed:
What|Removed |Added
Component|bootstrap |libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31957
[Bug bootstrap/31957] New: Build of compiler fails with 'error: #endif without #if'
$ configure --enable-languages=c,c++ --with-ld=/bin/ld --with-as=/bin/as $ make leads to: In file included from .../obj/powerpc-ibm-aix5.2.0.0/libstdc++-v3/include/cctype:50, from .../gcc-4.2.0/libstdc++-v3/include/precompiled/stdc++.h:38: .../obj/powerpc-ibm-aix5.2.0.0/libstdc++-v3/include/powerpc-ibm-aix5.2.0.0/bits/c++config.h:1087:2: error: #endif without #if While doing: make[4]: Entering directory `/pdv/.ws/jrichter/gcc420/obj/powerpc-ibm-aix5.2.0.0/libstdc++-v3/include' sed: 0602-429 No editing script was provided. Usage: sed [-n] Script [File ...] sed [-n] [-e Script] ... [-f Script_file] ... [File ...] if [ ! -d ./powerpc-ibm-aix5.2.0.0/bits/stdc++.h.gch ]; then \ mkdir -p ./powerpc-ibm-aix5.2.0.0/bits/stdc++.h.gch; \ fi; \ /ws/jrichter/gcc420/obj/./gcc/xgcc -shared-libgcc -B/ws/jrichter/gcc420/obj/./gcc -nostdinc++ -L/ws/jrichter/gcc420/obj/powerpc-ibm-aix5.2.0.0/libstdc++-v3/src -L/ws/jrichter/gcc420/obj/powerpc-ibm-aix5.2.0.0/libstdc++-v3/src/.libs -B/usr/local/powerpc-ibm-aix5.2.0.0/bin/ -B/usr/local/powerpc-ibm-aix5.2.0.0/lib/ -isystem /usr/local/powerpc-ibm-aix5.2.0.0/include -isystem /usr/local/powerpc-ibm-aix5.2.0.0/sys-include -Winvalid-pch -Wno-deprecated -x c++-header -g -O2 -I/ws/jrichter/gcc420/obj/powerpc-ibm-aix5.2.0.0/libstdc++-v3/include/powerpc-ibm-aix5.2.0.0 -I/ws/jrichter/gcc420/obj/powerpc-ibm-aix5.2.0.0/libstdc++-v3/include -I/ws/jrichter/gcc420/gcc-4.2.0/libstdc++-v3/libsupc++ -O0 -g /ws/jrichter/gcc420/gcc-4.2.0/libstdc++-v3/include/precompiled/stdc++.h -o powerpc-ibm-aix5.2.0.0/bits/stdc++.h.gch/O0g.gch the file .../powerpc-ibm-aix5.2.0.0/libstdc++-v3/include/powerpc-ibm-aix5.2.0.0/bits/c++config.h has as the last line: #endif // _CXXCONFIG_ but no corresponding #ifndef/#define lines of his header guard -- Summary: Build of compiler fails with 'error: #endif without #if' Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joerg dot richter at pdv-fs dot de GCC build triplet: powerpc-ibm-aix5.2.0.0 GCC host triplet: powerpc-ibm-aix5.2.0.0 GCC target triplet: powerpc-ibm-aix5.2.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31957
[Bug c/31695] New: __builtin_ctzll slower than 2*__builtin_ctz
int func1( unsigned long long val )
{
return __builtin_ctzll( val );
}
int func2( unsigned long long val )
{
unsigned lo = (unsigned)val;
return lo ? __builtin_ctz(lo) : __builtin_ctz(unsigned(val32)) + 32;
}
func1 is more than 2 times slower than func2.
But it should be at least as fast as func2
__builtin_ctzll is not expanded inline like __builtin_ctz.
--
Summary: __builtin_ctzll slower than 2*__builtin_ctz
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31695
[Bug c++/28093] New: Wrong overload resolution with templates and namespaces
$ cat t.cc
#include cstdio
using namespace std;
namespace ident {
templateclass T void
foo( T*, void* )
{
printf( generic\n );
}
}
using namespace ident;
templateclass T void func( T val )
{
foo( val, (T*)0 );
}
struct Base
{};
struct Deriv : public Base
{};
namespace ident {
templateclass T void
foo( T* val, Base* )
{
printf( special\n );
}
}
int main()
{
Deriv d;
func( d );
}
$ g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /tools/inst/jrichter/tmp.evo1.18630/gcc-4.1.1/configure
--prefix=/tools/pkg/gcc/4.1.1 --enable-languages=c,c++ --disable-threads
Thread model: single
gcc version 4.1.1
$ g++ -o t t.cc
$ t
generic
While GCC 3.4.3 outputs special
--
Summary: Wrong overload resolution with templates and namespaces
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28093
[Bug c++/28025] New: multiple template friend compile error
$ cat t.cc
class BaseSubmit
{
templateclass T friend class PeriodicSubmit;
};
templateclass ID
class ValuesSubmit
{
templateclass T friend class PeriodicSubmit;
};
class A;
class MultiSubmit : public ValuesSubmitA
{
};
$ g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /tools/inst/gcc-4.1.1/configure --prefix=/tools/pkg/gcc/4.1.1
--enable-languages=c,c++ --disable-threads
Thread model: single
gcc version 4.1.1
$ g++ -c -o t.o t.cc
t.cc: In instantiation of 'ValuesSubmitA':
t.cc:13: instantiated from here
t.cc:8: error: declaration of template 'templateclass T struct
PeriodicSubmit'
t.cc:3: error: conflicts with previous declaration 'templateclass T struct
PeriodicSubmit'
t.cc:8: error: declaration of 'templateclass T struct PeriodicSubmit'
t.cc:3: error: conflicts with previous declaration 'templateclass T struct
PeriodicSubmit'
Makeing BaseSubmit to a class template lets this error disappear.
The same if you add 'templateclass T class PeriodicSubmit;' as the first
line.
Note that there is a minor additional error. The line number t.cc:8 is wrong.
It should be t.cc:9.
--
Summary: multiple template friend compile error
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28025
[Bug c++/21264] duplicate symbol warnings for complex template class
--- Comment #4 from joerg dot richter at pdv-fs dot de 2006-05-31 07:21 --- I can't see the problem with 4.1.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21264
[Bug c++/25973] [4.0/4.1/4.2 Regression] Wrong warning: control reaches end of non-void function
--- Comment #4 from joerg dot richter at pdv-fs dot de 2006-05-30 09:43
---
Before I file a new bug, here is another testcase:
struct Block
{
public:
Block();
~Block();
};
bool func( bool bar )
{
Block block;
bool foo = false;
if( !foo || bar )
do { return true; } while( 0 );
else
do { return false; } while( 0 );
}
--
joerg dot richter at pdv-fs dot de changed:
What|Removed |Added
CC||joerg dot richter at pdv-fs
||dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25973
[Bug c++/27791] New: assert() without -ansi doesnt print the failing condition
$ cat t.cc
#include cassert
int main()
{
assert( false );
}
$ g++ -v
Using built-in specs.
Target: powerpc-ibm-aix5.2.0.0
Configured with: /tools/inst/jrichter/gcc-4.1.1/configure
--prefix=/tools/pkg/gcc/4.1.1 --enable-languages=c,c++ --disable-threads
--with-ld=/bin/ld --with-as=/bin/as
Thread model: aix
gcc version 4.1.1
$ g++ -o t t.cc
$ t
Assertion failed: __EX, file t.cc, line 4
Resources lost(coredump)
$ g++ -ansi -o t t.cc
Assertion failed: false, file t.cc, line 4
Resources lost(coredump)
Normally assert outputs the conditions that failed in the error message. But
not without -ansi.
Here follows the relevant part of
lib/gcc/powerpc-ibm-aix5.2.0.0/4.1.1/include/assert.h
#include standards.h
#if !defined(__NO_ASSERT_C99) !defined(_NOISOC99_SOURCE)
#if __STDC_VERSION__ 199901L !defined(__C99__FUNC__)
#undef __ASSERT_C99
#else
#if !defined(_ALL_SOURCE) (!defined(_POSIX_C_SOURCE) || _POSIX_C_SOURCE =
200112L)
#define __ASSERT_C99
#endif
#endif
#endif
#ifdef __ASSERT_C99
#if defined(__STRICT_ANSI__)
#define assert(__EX) ((__EX) ? ((void)0) : __assert_c99(# __EX, __FILE__,
__LINE__, __func__))
#else
#define assert(__EX) ((__EX) ? ((void)0) : __assert_c99(__EX, __FILE__,
__LINE__, __func__))
#endif /* __STDC__*/
#else/* else if __ASSERT_C99 not defined */
#if defined(__STRICT_ANSI__)
#define assert(__EX) ((__EX) ? ((void)0) : __assert(# __EX, __FILE__,
__LINE__))
#else
#define assert(__EX) ((__EX) ? ((void)0) : __assert(__EX, __FILE__,
__LINE__))
#endif /* __STDC__*/
#endif /* __ASSERT_C99 */
#endif /* NDEBUG */
You can see, depending on __STRICT_ANSI__ __EX is stringified or output as
string. I think the macro expansion of __EX in string literals is pre-standard
and should not be used in a gcc header.
--
Summary: assert() without -ansi doesnt print the failing
condition
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
GCC host triplet: powerpc-ibm-aix5.2.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27791
[Bug target/27791] assert() without -ansi doesnt print the failing condition
--- Comment #2 from joerg dot richter at pdv-fs dot de 2006-05-29 08:31 --- I think this is a GCC problem, because this is the header installed by GCC. Removing the header works, because then /usr/include/assert.h is used. And this system header works as expected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27791
[Bug c++/25156] New: wrong error message (int instead of bool)
bool func()
{
return;
}
a.cc:3: error: return-statement with no value, in function returning 'int'
--
Summary: wrong error message (int instead of bool)
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25156
[Bug preprocessor/21815] -E output depends on -g
--- Additional Comments From joerg dot richter at pdv-fs dot de 2005-06-06 12:33 --- Whoever has the same problem: -fno-working-directory solves it -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21815
[Bug c/21815] New: -E output depends on -g
$ gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.0.0/configure --prefix=/tools/pkg/gcc/4.0.0 --enable- languages=c,c++ --disable-threads Thread model: single gcc version 4.0.0 $ touch a.c $ gcc -E a.c # 1 a.c # 1 built-in # 1 command line # 1 a.c $ gcc -E -g a.c # 1 a.c # 1 /home/jrichter// # 1 built-in # 1 command line # 1 a.c This in conjunction with ccache and multiple users make ccache relative senseless (for our environment). Even if this is closed as a non-bug please give me a hint where this output is coming from. (So that I can change it in our tree) Failes also with GCC 3.4.3 Works with GCC 3.3.3 -- Summary: -E output depends on -g Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joerg dot richter at pdv-fs dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21815
[Bug preprocessor/21815] -E output depends on -g
--- Additional Comments From joerg dot richter at pdv-fs dot de 2005-05-30 11:41 --- Well, but I want all generated objects to be the same between our developers. This makes an extremly good cache hit rate with ccache. We arranged with it that we don't have the current/source directory compiled in. And I think there is no reason to output this line unconditional when using -g. You can always use absolute paths if you really want the source path compiled in. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21815
[Bug target/21642] New: wrong code with -O2
$ gcc -v
Reading specs from /pdv/.tools/pkg/gcc/3.4.3/bin/../lib/gcc/powerpc-ibm-
aix5.2.0.0/3.4.3/specs
Configured with: ../gcc-3.4.3/configure --prefix=/tools/pkg/gcc/3.4.3 --with-
ld=/bin/ld --with-as=/bin/as --disable-threads --enable-languages=c,c++
Thread model: aix
gcc version 3.4.3
// foo.c //
#include stdio.h
inline void
reverse( char* beg, char* end )
{
while( beg --end )
{
char t = *end;
*end = *beg;
*beg++ = t;
}
}
void doIt( int* val )
{
reverse( (char*)val, (char*)val + sizeof( *val ) );
}
int main()
{
int d = 0x12345678;
printf( %x\n, d );
doIt( d );
printf( %x\n, d );
return 0;
}
$ gcc -o foo foo.c -O2
$ foo
12345678
78345612
$ gcc -o foo foo.c
$ foo
12345678
78563412
Works with GCC 3.3.3
--
Summary: wrong code with -O2
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-ibm-aix5.2.0.0
GCC host triplet: powerpc-ibm-aix5.2.0.0
GCC target triplet: powerpc-ibm-aix5.2.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21642
[Bug c++/21264] New: duplicate symbol warnings for complex template class
/// template.cc /
struct VirtualBase
{
virtual ~VirtualBase();
};
struct Foo
{};
struct Bar
{
virtual ~Bar();
};
templateclass OtherBase
class Test : public VirtualBase, public OtherBase
{
};
void func()
{
TestFoo foo;
TestBar bar;
}
//
$ /tools/pkg/gcc/3.4.3/bin/g++ -shared -Wl,-G -o lib343.so template.cc
$ dump -Tv lib343.so | c++filt
IMEX Sclass Type IMPid Name
EXP DS Ldef[noIMid] TestBar::~Test()
EXP DS Ldef[noIMid] TestBar::~Test()
wEXP DS SECdef[noIMid] non-virtual thunk to TestBar::~Test()
wEXP DS SECdef[noIMid] non-virtual thunk to TestBar::~Test()
wEXP DS SECdef[noIMid] TestFoo::~Test()
wEXP DS SECdef[noIMid] TestFoo::~Test()
$ /tools/pkg/gcc/3.3.3/bin/g++ -shared -Wl,-G -o lib333.so template.cc
$ dump -Tv lib333.so | c++filt
IMEX Sclass Type IMPid Name
wEXP DS SECdef[noIMid] TestBar::~Test()
wEXP DS SECdef[noIMid] TestBar::~Test()
wEXP DS SECdef[noIMid] non-virtual thunk to TestBar::~Test()
wEXP DS SECdef[noIMid] non-virtual thunk to TestBar::~Test()
wEXP DS SECdef[noIMid] TestFoo::~Test()
wEXP DS SECdef[noIMid] TestFoo::~Test()
Note that I edited the dump output to reduce its size.
Here you can see, that the Test...::~Test() destructor gets a different IMEX.
Depending on its template parameter and/or compiler version.
I dont know exactly what the difference between EXP and wEXP is, but I suspect
that this has something to do with weak symbols. But on the other hand, I
always read that AIX supports no weak symbols.
Nevertheless, when using the class TestBar in different shared libraries
which get linked together, you get warnings about duplicate symbols. This
warnings were not present with GCC 3.3.3.
I am very nervous when seeing duplicate symbols. Especially on AIX. I had great
times in the past analysing problems with uncaught exceptions that were caused
by duplicate symbols.
--
Summary: duplicate symbol warnings for complex template class
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-ibm-aix5.2.0.0
GCC host triplet: powerpc-ibm-aix5.2.0.0
GCC target triplet: powerpc-ibm-aix5.2.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21264
[Bug preprocessor/19753] New: different LANG settings and ccache don't work together
$ touch a.cc $ LANG=C g++ -E a.cc # 1 a.cc # 1 built-in # 1 command line # 1 a.cc $ LANG=de_DE g++ -E a.cc # 1 a.cc # 1 eingebaut # 1 Kommandozeile # 1 a.cc IMHO, preprocessor output should be independend of LANG settings. This prevents ccache (http://ccache.samba.org) from working for different users using different LANG settings. A workaround for my problem is to set LANG always to C. But then you can't see translated errors/warnings. -- Summary: different LANG settings and ccache don't work together Product: gcc Version: 3.4.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joerg dot richter at pdv-fs dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19753
[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf
--- Additional Comments From joerg dot richter at pdv-fs dot de 2005-01-27 08:08 --- std::cout.imbue( std::locale( C ) ); nor std::cout.imbue( std::locale::classic() ); nor export LANG=C does change anything Joerg -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642
[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf
--- Additional Comments From joerg dot richter at pdv-fs dot de 2005-01-27 12:39 --- A quick test shows, that std::setlocale(LC_ALL, NULL) returns C C C C C C. But std::setlocale(LC_NUMERIC, NULL) returns C I think it is enough to test LC_NUMERIC. I'll try to test a modified patch. But this may take a while. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642
[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf
--- Additional Comments From joerg dot richter at pdv-fs dot de 2005-01-27 12:54 --- I think this runtimes of the different setlocale() calls might be interesting: (This is for 100 calls) category locale time LC_ALL00.70s LC_NUMERIC00.29s LC_ALL C 1.63s LC_NUMERIC C 8.98s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642
[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf
--- Additional Comments From joerg dot richter at pdv-fs dot de 2005-01-27 15:05 --- With patch draft_19642_3 and count=100 $ time t /dev/null real 0,64 user 0,60 sys0,01 $ time t cout /dev/null real 1,14 user 1,12 sys0,00 Now its only 2 times slower than sprintf. Much better than the ~75 times before. Also note, that when an other locale than C is in place the times also get better: without patch: (count=10) real 28,27 user 6,34 sys21,87 with: real 5,66 user 1,89 sys3,78 (sprintf:0,07s) This case is still horrible slow, but 4-5 times better than before. Good work so far, but I think the final solution is to avoid any frequent setlocale() calls. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642
[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf
--- Additional Comments From joerg dot richter at pdv-fs dot de 2005-01-28 07:54 --- (In reply to comment #26) Excellent. Can you please check whether on AIX this is ok (de_DE is just an example, any actually installed named locale should do): [code] In short, we should make sure that any change to LC_ALL is reflected to LC_NUMERIC. I have checked that this is the case with glibc and also FreeBSD but we should check all the supported OSes. Thanks again! I've checked it with all installed locales I've found. It works for all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642
[Bug c++/19642] New: streaming doubles is very slow compared to sprintf
$ g++ -v
Configured with: ../gcc-3.4.2/configure --prefix=/tools/pkg/gcc/3.4.2 --enable-
languages=c,c++ --with-ld=/bin/ld --with-as=/bin/as --disable-threads
Thread model: aix
gcc version 3.4.2
/// t.cc
#include iostream
#include cstdio
using namespace std;
int main( int argc, char** argv )
{
std::ios_base::sync_with_stdio( false );
int count = 10;
if( argc 1 )
for( int i = 0; i count; ++i )
std::cout (double)i;
else
for( int i = 0; i count; ++i )
{
char buf[50];
sprintf( buf, %g, (double)i );
std::cout buf;
}
return 0;
}
///
$ g++ -o t t.cc
$ time t /dev/null
real0m0.07s
user0m0.05s
sys 0m0.00s
$ time t cout /dev/null
real0m4.22s
user0m2.60s
sys 0m1.60s
The std::ios_base::sync_with_stdio( false ); seems to have no effect.
Note: On i686-pc-linux-gnu, both cout and sprintf/(char*) take the same time.
Using the AIX system g++ 2.9-aix51-020209, there is also no difference (both
are fast).
--
Summary: streaming doubles is very slow compared to sprintf
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-ibm-aix5.2.0.0
GCC host triplet: powerpc-ibm-aix5.2.0.0
GCC target triplet: powerpc-ibm-aix5.2.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642
[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf
--- Additional Comments From joerg dot richter at pdv-fs dot de 2005-01-26 15:00 --- I took some backtraces during a longer run of the program and most of the time it looked like this: (I removed some templates to make it readable) __issetuid load_locale setlocale int std::__convert_from_vdouble(...) std::ostreambuf_iterator std::num_put::_M_insert_floatdouble(...) const std::num_put::do_put(std::ostreambuf_iterator, std::ios_base, char, double) const std::basic_ostream::operator(double) main -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642
[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf
--- Additional Comments From joerg dot richter at pdv-fs dot de 2005-01-26 15:18 --- Ok, lets say I took 100 backtraces and got 99 times this one. I hope this is enough percentage. _GLIBCXX_USE_C99 is defined -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642
[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf
--- Additional Comments From joerg dot richter at pdv-fs dot de 2005-01-26 15:41 --- ;) No, I mean *relative* percentages: setlocal in your profile is on top, higher than __convert_from_v and everything else. I'm asking: is consuming 1%, 10%, or 99% of the total runtime? Doesn't a function that is on 99% of all call stacks automatically consume 99% of the runtime? Ok, the time can also be spend in the childs like here in __issetuid, but this is an implementation detail of setlocale, isn't it? In this case, can you possibly check whether, for some reason, snprintf is slower than sprintf, on AIX? I rewrote the original program to use snprintf and got the same time as with sprintf. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642
[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf
--- Additional Comments From joerg dot richter at pdv-fs dot de 2005-01-26 16:00 --- If it helps you, here the first lines of prof. But in practice some backtraces help me a lot more than a a [g]prof output. Its very fast in finding big bottlenecks, like setlocale in this PR. count = 100 Name %Time Seconds Cumsecs #Calls msec/call .strncpy 31.55.365.36 .getenv 19.63.348.70 500 0.0007 .mystrncpy 6.21.069.76 700 0.0002 .getgidx.GL5.50.94 10.70 .__mcount 5.30.90 11.60 ._doprnt 5.20.88 12.48 201 0.0004 .setlocale 4.60.79 13.27 300 0.0003 .strchr4.20.72 13.99 .__issetuid3.40.58 14.57 600 0.0001 .getuidx.GL3.40.57 15.14 ._ZNSolsEd 1.10.18 15.32 .main 0.80.13 15.45 1130.0 .malloc_y_start0.80.13 15.58 .text 0.70.12 15.70 ._ZNKSt7num_putIcSt1 0.60.11 15.81 .malloc_y 0.60.11 15.92 107 0.0001 .strcmp0.60.10 16.02 .free_y0.60.10 16.12 102 0.0001 .malloc_y_heap 0.50.08 16.20 107 0.0001 .strcpy0.40.07 16.27 .text 0.30.05 16.32 .sprintf 0.30.05 16.37 100 0.0001 .__nl_langinfo_std 0.30.05 16.42 200 0. .mf2x2 0.20.04 16.46 99 0. .strcmp0.20.04 16.50 ._ZNKSt7num_putIcSt1 0.20.04 16.54 ._ZdaPv.GL 0.20.04 16.58 .setlocale.GL 0.20.03 16.61 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642
[Bug c++/18976] New: [3.4 Regression] can't pass anonymous enum to function template
bug.cc:
///
enum { FOO } foo;
templateclass T void
bar( T const t )
{}
void
test()
{
bar( foo );
}
///
$ ~/gcc/3.4.2/bin/g++ -o /dev/null -c bug.cc
bug.cc: In function `void test()':
bug.cc:10: Fehler: no matching function for call to `bar(anonymous enum)'
Works with GCC 3.3.3
Fix: give the enum a name
--
Summary: [3.4 Regression] can't pass anonymous enum to function
template
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18976
[Bug c++/7740] builtins, and functions marked as extern C++ with incorrect C linkage
--- Additional Comments From joerg dot richter at pdv-fs dot de 2004-11-03 08:20
---
In a recent discussion on comp.lang.c++.moderated was this example to give
bar C++ linkage and foo C linkage. But g++ gives them both C linkage. It
might be anonther instance of this problem.
extern C++ {
typedef void (cpp_func)(int);
}
extern C void foo(int a){
cpp_func bar;
bar(a);
}
nm x.o
U bar
T foo
--
What|Removed |Added
CC||joerg dot richter at pdv-fs
||dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7740
[Bug c++/17947] New: bad warning with implicit conversion and __attribute__((deprecated))
///
struct Foo
{
operator int() __attribute__((deprecated));
};
int main()
{
Foo f;
(int)f;
}
///
gives:
warning: `operator 1' is deprecated
In real code the '1' is often a bigger number.
--
Summary: bad warning with implicit conversion and
__attribute__((deprecated))
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17947
