[Bug libstdc++/94051] New: #include & is not enough for operator<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94051
Bug ID: 94051
Summary: #include & is not enough for
operator<<
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
Target Milestone: ---
#include
#include
std::ostream& func( std::ostream& os, std::string_view v )
{
return os << v;
}
This code results in a compile error:
'__ostream_insert' was not declared in this scope
It would be nice if this two includes would be enough to stream a string_view.
This works already for .
Adding the small header to fixes the
problem.
[Bug bootstrap/52887] Bootstrap on AIX failure: Undefined symbol: .std::function::function(std::function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887
--- Comment #22 from Jörg Richter 2012-09-14 07:58:16
UTC ---
I have reduced a real live case. But still using .
$ cat t.cc
#include
struct ClassicUpdate
{
ClassicUpdate();
};
typedef std::vector ClassicUpdates;
struct UpdateData
{
ClassicUpdates classicUpdates;
UpdateData( ClassicUpdates const& classicUpdates )
: classicUpdates( classicUpdates )
{}
};
int main()
{}
$ g++ -std=gnu++0x -o mm t.cc -save-temps
$ grep Construct.*ClassicUpdate *.s
.weak _ZSt10_ConstructI13ClassicUpdateIRKS0_EEvPT_DpOT0_[DS]
...
This should demostrate that GCC compiles a symbol referencing ClassicUpdate
into the executable. When the AIX linker decides to use that symbol you get
an undefined reference error. This is not the case here. But the unreduced
source has the problem.
GCC 4.6.3 doesn't do this. And removing -std=gnu++0x works too.
So it seems this is not regex-related but a deeper bug in GCC 4.7 that emits
functions that are never called.
[Bug c++/57724] New: wrong error: returning a value from a constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57724 Bug ID: 57724 Summary: wrong error: returning a value from a constructor Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: joerg.rich...@pdv-fs.de cat > t.cc <
[Bug c++/57724] wrong error: returning a value from a constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57724 --- Comment #2 from Jörg Richter --- You mean the special case for 'void' does not apply in this case? What a pity.
[Bug c++/57724] wrong error: returning a value from a constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57724 --- Comment #5 from Jörg Richter --- BTW: There is currently a discussion [1] on this topic on the "ISO C++ Standard - Discussion" list. [1] https://groups.google.com/a/isocpp.org/d/msg/std-discussion/ehqGBMsswjk/nbsubYASnPgJ
[Bug bootstrap/50882] internal compiler error: in extract_insn, at recog.c:2109 on powerpc-ibm-aix5.3.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50882 --- Comment #1 from joerg.rich...@pdv-fs.de 2011-10-27 09:07:16 UTC --- Forgot to mention that 4.6.1 builds without problems.
[Bug bootstrap/50882] New: internal compiler error: in extract_insn, at recog.c:2109 on powerpc-ibm-aix5.3.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50882 Bug #: 50882 Summary: internal compiler error: in extract_insn, at recog.c:2109 on powerpc-ibm-aix5.3.0.0 Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: joerg.rich...@pdv-fs.de When building GCC 4.6.2 on AIX: configure --enable-languages=c,c++ --disable-bootstrap --disable-nls --with-local-prefix=/not_existing_directory --prefix=/tools/pkg/gcc/4.6.2 --with-ld=/bin/ld --with-as=/bin/as make ...later... /tools/inst/tmp/tmp/./gcc/xgcc -B/tools/inst/tmp/tmp/./gcc/ -B/tools/pkg/gcc/4.6.2/powerpc-ibm-aix5.3.0.0/bin/ -B/tools/pkg/gcc/4.6.2/powerpc-ibm-aix5.3.0.0/lib/ -isystem /tools/pkg/gcc/4.6.2/powerpc-ibm-aix5.3.0.0/include -isystem /tools/pkg/gcc/4.6.2/powerpc-ibm-aix5.3.0.0/sys-include-g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -mlong-double-128 -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -fno-stack-protector -I. -I. -I../.././gcc -I../../gcc-4.6.2/libgcc -I../../gcc-4.6.2/libgcc/. -I../../gcc-4.6.2/libgcc/../gcc -I../../gcc-4.6.2/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o unwind-dw2-fde.o -MT unwind-dw2-fde.o -MD -MP -MF unwind-dw2-fde.dep -fexceptions -c ../../gcc-4.6.2/libgcc/../gcc/unwind-dw2-fde.c ../../gcc-4.6.2/libgcc/../gcc/unwind-dw2-fde.c: In function 'frame_downheap': c-4.6.2/libgcc/../gcc/unwind-dw2-fde.c:502:1: error: unrecognizable insn: (insn 43 42 44 8 (set (mem/v:DI (plus:DI (reg/f:SI 1 1) (const_int 20 [0x14])) [0 S8 A8]) (reg:SI 2 2)) ../../gcc-4.6.2/libgcc/../gcc/unwind-dw2-fde.c:491 -1 (nil)) ../../gcc-4.6.2/libgcc/../gcc/unwind-dw2-fde.c:502:1: internal compiler error: in extract_insn, at recog.c:2109 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions.
[Bug bootstrap/50882] [4.6 Regression] internal compiler error: in extract_insn, at recog.c:2109 on powerpc-ibm-aix5.3.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50882 --- Comment #3 from joerg.rich...@pdv-fs.de 2011-10-27 10:10:43 UTC --- Snapshot gcc-4.7-20111022 fails with: ../gcc-4.7-20111022/gcc/tree-diagnostic.c:59: error: conflicting types for ‘loc_t’ /usr/include/sys/localedef31.h:195: error: previous declaration of ‘loc_t’ was here svn is still syncing...
[Bug bootstrap/50882] [4.6 Regression] internal compiler error: in extract_insn, at recog.c:2109 on powerpc-ibm-aix5.3.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50882 --- Comment #4 from joerg.rich...@pdv-fs.de 2011-10-27 14:44:14 UTC --- Cannot test svn trunk. The loc_t issue still remains, see bug 50874.
[Bug c++/50956] New: -Wcast-qual does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50956 Bug #: 50956 Summary: -Wcast-qual does not work Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: joerg.rich...@pdv-fs.de -Wcast-qual seems to be broken since at least GCC 4.1.1. cat > t.cc <
[Bug c++/53165] New: multiline raw strings as macro arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53165 Bug #: 53165 Summary: multiline raw strings as macro arguments Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: joerg.rich...@pdv-fs.de With GCC 4.7.0: $ cat t.cc #define XXX( x ) x char const* str = XXX( R"( )" ); $ g++ -std=c++0x -o t t.cc t.cc:2:24: error: unterminated raw string t.cc:2:1: error: stray 'R' in program t.cc:3:2: warning: missing terminating " character [enabled by default] t.cc:2:1: error: missing terminating " character t.cc:2:17: error: expected primary-expression at end of input t.cc:2:17: error: expected ',' or ';' at end of input Following raw string works: char const* str = XXX( R"()" );
[Bug libstdc++/53713] New: undefined reference with -brtl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53713
Bug #: 53713
Summary: undefined reference with -brtl
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joerg.rich...@pdv-fs.de
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/tools/pkg/gcc/4.7.1/libexec/gcc/powerpc-ibm-aix5.3.0.0/4.7.1/lto-wrapper
Target: powerpc-ibm-aix5.3.0.0
Configured with: gcc-4.7.1/configure --enable-languages=c,c++
--disable-bootstrap --disable-nls --with-local-prefix=/not_existing_directory
--prefix=/tools/pkg/gcc/4.7.1 --with-ld=/bin/ld --with-as=/bin/as
Thread model: aix
gcc version 4.7.1 (GCC)
$ cat t.cc
#include
int main( int argc, char** argv )
{
std::string s;
}
$ g++ -Wl,-brtl -o t t.cc
$ t
Could not load program t:
rtld: 0712-001 Symbol
_ZNSt8functionIFvRKNSt7__regex14_PatternCursorERNS0_8_ResultsEEEC1ERKS7_ was
referenced from module
/tools/pkg/gcc/4.7.1/lib/gcc/powerpc-ibm-aix5.3.0.0/4.7.1/../../../libstdc++.a(libstdc++.so.6),
but a runtime definition of the symbol was not found.
rtld: 0712-001 Symbol _ZNSt8functionIFbRKNSt7__regex14_PatternCursorEEEC1ERKS5_
was referenced from module
/tools/pkg/gcc/4.7.1/lib/gcc/powerpc-ibm-aix5.3.0.0/4.7.1/../../../libstdc++.a(libstdc++.so.6),
but a runtime definition of the symbol was not found.
[Bug libstdc++/53713] undefined reference with -brtl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53713 --- Comment #2 from joerg.rich...@pdv-fs.de 2012-06-18 09:39:55 UTC --- (In reply to comment #1) > probably related to PR 52887 Yes, seems to be the same bug. But I've used --disable-bootstrap. I am testing the proposed fixes for PR 52887 and will submit a patch if it works.
[Bug bootstrap/52887] Bootstrap on AIX failure: Undefined symbol: .std::function::function(std::function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887 --- Comment #10 from joerg.rich...@pdv-fs.de 2012-06-18 09:44:30 UTC --- Created attachment 27649 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27649 Fix for undefined references Patch for 4.7.1 with the two missing instantiations. Works for me. Not tested with GCC testsuite. Please consider this for 4.7.2
[Bug bootstrap/52887] Bootstrap on AIX failure: Undefined symbol: .std::function::function(std::function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887 --- Comment #19 from Jörg Richter 2012-06-21 06:58:13 UTC --- See also bug 53713. Hasn't been marked as a dup yet.
[Bug c++/38172] warn_unused_result does not work with structs not containing a copy constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38172
Jörg Richter changed:
What|Removed |Added
CC||joerg.rich...@pdv-fs.de
--- Comment #5 from Jörg Richter 2012-06-25 13:58:26
UTC ---
Adding just a simple struct member makes the warning for Bar2 disappear again.
Reopen? Or should I file a new PR?
$ cat t.cc
struct MyClass
{
int i;
};
typedef struct MyClass MyClass;
int Bar1( void ) __attribute__((warn_unused_result));
MyClass Bar2( void ) __attribute__((warn_unused_result));
void Foo( void )
{
Bar1(); // Warns
Bar2(); // Does not warn
}
$ gcc -c -o /dev/null t.cc
t.cc: In function 'void Foo()':
t.cc:13:9: warning: ignoring return value of 'int Bar1()', declared with
attribute warn_unused_result [-Wunused-result]
$ gcc -v
Using built-in specs.
COLLECT_GCC=/tools/pkg/gcc/4.7.1/bin/gcc
COLLECT_LTO_WRAPPER=/tools/pkg/gcc/4.7.1/libexec/gcc/x86_64-unknown-linux-gnu/4.7.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: gcc-4.7.1/configure --enable-languages=c,c++
--disable-bootstrap --disable-nls --with-local-prefix=/not_existing_directory
--with-as=/tools/pkg/binutils/2.21/bin/as
--with-ld=/tools/pkg/binutils/2.21/bin/ld --prefix=/tools/pkg/gcc/4.7.1
Thread model: posix
gcc version 4.7.1 (GCC)
Also with 4.6.3
[Bug c++/52723] New: No declaration of __cxa_eh_globals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52723 Bug #: 52723 Summary: No declaration of __cxa_eh_globals Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: joerg.rich...@pdv-fs.de include/c++/4.7.0/cxxabi.h has the functions __cxa_get_globals() and __cxa_get_globals_fast() returning a pointer to __cxa_eh_globals struct. But __cxa_eh_globals isn't declared in any installed header file. libstdc++-v3/libsupc++/unwind-cxx.h has the declaration in the source. unwind-cxx.h should be installed, shouldn't it?
[Bug libstdc++/58825] New: endless loop compiling nested bind expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58825
Bug ID: 58825
Summary: endless loop compiling nested bind expression
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
g++ -std=c++11 -x c++ -c - <
using namespace std;
struct Win
{
void setMini( bool );
bool isMini();
};
bool neg( bool val );
void foo( Win* w )
{
function a = bind( &Win::setMini, w, bind( neg, bind( &Win::isMini, w
) ) );
}
EOF
Works with GCC 4.7.3
IMHO there are two bugs. One in libstdc++ that valid code is rejected. The
other one that the error reporting does not stop.
[Bug c++/51157] New: decltype/typeof of template member with default template argument confuses g++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51157
Bug #: 51157
Summary: decltype/typeof of template member with default
template argument confuses g++
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joerg.rich...@pdv-fs.de
cat > t.cc << EOF
struct Key
{
typedef int Ser;
};
template
struct Shell
{
template
typename T::Ser getId() const;
};
void func()
{
decltype(&Shell::getId) a;
}
EOF
g++ -std=gnu++0x -c t.cc
# results in:
# '
# t.cc:13: confused by earlier errors, bailing out
# GCC version 4.6.2
[Bug c/91914] New: Invalid strlen optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91914
Bug ID: 91914
Summary: Invalid strlen optimization
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
Target Milestone: ---
cat > t.c <
#include
struct stringpool_t
{
char stringpool_str4[sizeof("Foo")];
char stringpool_str5[sizeof("Bar")];
};
static const struct stringpool_t stringpool_contents = {
"Foo",
"Bar",
};
#define stringpool ((const char *) &stringpool_contents)
int main( int argc, char** argv )
{
printf( "%zu\n", strlen( stringpool + 4 ) );
volatile int idx = 4;
printf( "%zu\n", strlen( stringpool + idx ) );
return 0;
}
EOF
gcc -o t t.c -Wall
## Output:
3
0
The first strlen() has the warning "offset '4' outside bounds
of constant string [-Warray-bounds]". I think this is a wrong
warning, because of the cast to char*. But the strlen() result is okay.
The second strlen() returns 0. This is more serious as this results in wrong
code.
The stringpool-code is generated by gperf.
[Bug tree-optimization/91914] [9 Regression] Invalid strlen optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91914 --- Comment #4 from Jörg Richter --- The patch in comment #2 fixes the problem for us.
[Bug c++/91964] New: Wrong -Wint-in-bool-context warning for enum constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91964 Bug ID: 91964 Summary: Wrong -Wint-in-bool-context warning for enum constant Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: joerg.rich...@pdv-fs.de Target Milestone: --- cat > t.cc <(C) ) return true; // 3 if( static_cast(C) ) return true; // 4 if( static_cast( static_cast(C) ) ) return true; // 5 return false; } EOF gcc -c -o t.cc.o t.cc -Wall Gives: warning: enum constant in boolean context [-Wint-in-bool-context] GCC 9.2 warns for all cases. GCC 8.3 warns for case 2 & 4. I think all warnings are wrong because nowhere is a enum constant in a boolean context. Enums 'A' and 'B' dont seem to trigger the warning.
[Bug c++/91964] Wrong -Wint-in-bool-context warning for enum constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91964 --- Comment #2 from Jörg Richter --- The only boolean context I see is the if(...). The if() is never used with enum constants/types, but only bool-s and int-s. So according to the warning name (int-in-bool-context) the warning can be expected in cases 1&3. But not in the cases with explicit bool-casts. But if cases 1&3 should warn for 'C'. I don't see a point to not warn for 'A' or 'B'.
[Bug c++/91964] Wrong -Wint-in-bool-context warning for enum constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91964 --- Comment #5 from Jörg Richter --- There needs to be at least a way to suppress the warning with a cast or some other construct (not pragma).
[Bug c++/91964] Wrong -Wint-in-bool-context warning for enum constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91964 --- Comment #7 from Jörg Richter --- Yes, I changed our code already to if( C != Enum() ) But I still think that an explicit cast should always silence this warning.
[Bug c++/92011] New: '' may be used uninitialized in this function with std::optional()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92011
Bug ID: 92011
Summary: '' may be used uninitialized in this
function with std::optional()
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
Target Milestone: ---
cat > t.cc <
struct Bar
{
int size_;
Bar( int size )
: size_( size )
{}
};
template
Bar get( T const& val )
{
return Bar( __builtin_strlen(val) );
}
class Foo
{
int size2_;
public:
Foo()
{}
template
Foo( T const& t )
: size2_( get( t ).size_ )
{}
};
enum Enum
{};
bool parseImpl2( Foo s, Enum* val )
{
*val = Enum();
for(;;)
{
s = "aa";
if( true )
return false;
return true;
}
}
template std::optional parse2( Foo str )
{
T res = T();
if( parseImpl2( str, &res ) )
return res;
return std::optional();
}
Enum transform()
{
if( auto r = parse2( Foo() ) )
return *r;
return {};
}
EOF
gcc -std=c++17 -c -o t.cc.o t.cc -Wall -O1
Gives:
t.cc: In function 'Enum transform()':
t.cc:50:27: warning: '' may be used uninitialized in this function
[-Wmaybe-uninitialized]
50 | return std::optional();
| ^
[Bug c/89256] New: No optimized division by constant for __int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89256
Bug ID: 89256
Summary: No optimized division by constant for __int128
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
Target Milestone: ---
Division by constant is not optimized for __int128 dividend.
// This function will use shift+multiply
int64_t func64( int64_t val )
{
return val / 1000;
}
// This function will call __divti3
__int128 func128( __int128 val )
{
return val / 1000;
}
It would be nice if GCC would use the same optimisation for __int128 and
unsigned __int128.
[Bug c++/89850] New: long compile times with -fsanitize=undefined and -Wduplicated-branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89850
Bug ID: 89850
Summary: long compile times with -fsanitize=undefined and
-Wduplicated-branches
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
Target Milestone: ---
cat > t.cc <
Stream& operator<<( T const& t )
{
return *this;
}
};
void xxx( Stream& os )
{
FooBar bar;
long long foo = 0;
if( !bar.isUnused() )
{
os << foo << foo << foo << foo << foo << foo << foo
<< foo << foo << foo << foo << foo << foo << foo
<< foo << foo << foo << foo << foo << foo << foo
<< foo << foo << foo << foo << foo << foo << foo;
}
}
EOF
g++ -fsanitize=undefined -Wduplicated-branches -c -o t.o t.cc
[Bug c++/89869] New: -fsanitize=undefined miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89869
Bug ID: 89869
Summary: -fsanitize=undefined miscompilation
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
Target Milestone: ---
cat > t.cc <prev_ ? child->prev_->next_ : parent->first_ ) = child->next_;
( child->next_ ? child->next_->prev_ : parent->last_ ) = child->prev_;
}
int main( int argc, char** argv)
{
Object a;
Object b;
unlinkChild( &a, &b );
return 0;
}
EOF
g++ -o t t.cc -Wmaybe-uninitialized -fsanitize=undefined
t
Gives this:
t.cc: In function 'void unlinkChild(Object*, Object*)':
t.cc:13:68: warning: 'child.1' may be used uninitialized in this function
[-Wmaybe-uninitialized]
( child->prev_ ? child->prev_->next_ : parent->first_ ) = child->next_;
~~~^
t.cc:14:67: warning: 'child.5' may be used uninitialized in this function
[-Wmaybe-uninitialized]
( child->next_ ? child->next_->prev_ : parent->last_ ) = child->prev_;
~~~^
t.cc:13:68: runtime error: member access within address 0x00400710 which
does not point to an object of type 'Object'
0x00400710: note: object has invalid vptr
a0 ff ff ff 31 ed 49 89 d1 5e 48 89 e2 48 83 e4 f0 50 54 49 c7 c0 70 15 40
00 48 c7 c1 80 15 40
^~~
invalid vptr
t.cc:14:67: runtime error: member access within address 0x7fff38bf5fa0 which
does not point to an object of type 'Object'
0x7fff38bf5fa0: note: object has invalid vptr
00 00 00 00 01 00 00 00 00 00 00 00 89 63 bf 38 ff 7f 00 00 00 00 00 00 00
00 00 00 8b 63 bf 38
^~~
invalid vptr
There is no compiler warning or runtime error without -fsanitize=undefined.
This was reduced from a much larger testcase where a pointer value was set to
zero by the -fsanitize=undefined code leading to wrong results.
[Bug c++/89883] New: Excessive candidates for ambiguous overload in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89883
Bug ID: 89883
Summary: Excessive candidates for ambiguous overload in error
message
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
Target Milestone: ---
This code:
#include
enum Foo
{
Bar
};
std::ostream operator<<( std::ostream& os, Foo );
std::ostream operator<<( std::ostream& os, Foo const& );
void func( std::ostream& os )
{
os << Bar;
}
Generates around 70 lines of error message.
But in this case there are really only 2 conflicting overloads. One for 'Foo'
and one for 'Foo const&'. They both match better than any other overload.
Can GCC output just the two more matching overloads in this case?
[Bug c/55544] New: invalid optimisation long long->double->long long (with -m32)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55544
Bug #: 55544
Summary: invalid optimisation long long->double->long long
(with -m32)
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joerg.rich...@pdv-fs.de
$ cat t.c
#include
int main( int argc, char** argv )
{
long long v1;
sscanf( argv[1], "%lld", &v1 );
double d = (double)v1;
long long v2 = (long long)d;
printf( "v1=%lld d=%19.0f v2=%lld\n", v1, d, v2 );
return 0;
}
$ gcc -m32 -O -o t t.c
$ t 9223372036854774781
v1=9223372036854774781 d=9223372036854774784 v2=9223372036854774781
please note that v1 == v2. This is wrong
$ gcc -m32 -o t t.c
$ t 9223372036854774781
v1=9223372036854774781 d=9223372036854774784 v2=9223372036854774784
v2 == d. This is correct
-m64 (with or without optimisation) works too
[Bug c++/55544] -fexcess-precision=standard is not implemented for C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55544 Jörg Richter changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Component|c |c++ Resolution|INVALID | Summary|invalid optimisation long |-fexcess-precision=standard |long->double->long long |is not implemented for C++ |(with -m32) | --- Comment #3 from Jörg Richter 2012-11-30 13:07:07 UTC --- Okay thanks. This testcase is derived from C++ source. Using g++ -fexcess-precision=standard results in: cc1plus: sorry, unimplemented: -fexcess-precision=standard for C++ Can we change this bug to an enhancment request? I think I will use volatile then ...
[Bug c++/55544] -fexcess-precision=standard is not implemented for C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55544 --- Comment #5 from Jörg Richter 2012-11-30 13:47:24 UTC --- -ffloat-store works. But I dont want to use it in our project. -msse2 -mfpmath=sse does not work. I still see fildll,fnstcw,... instructions in the assembler listing.
[Bug c++/55544] -fexcess-precision=standard is not implemented for C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55544 --- Comment #7 from Jörg Richter 2012-12-01 09:53:13 UTC --- I see no reference to -fexcess-precision=standard in (garbage sink) bug 323, do you? So IMHO this is not a dup.
[Bug c++/55728] New: std::bad_function_call has misleading what() result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55728
Bug #: 55728
Summary: std::bad_function_call has misleading what() result
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joerg.rich...@pdv-fs.de
cat t.cc << EOF
#include
#include
int main()
{
try
{
std::function()();
}
catch( std::exception const& e )
{
std::cout << e.what() << std::endl;
}
}
EOF
g++ -std=c++11 -o t t.cc
t
# gives me "std::exception"
Not wrong, but "std::bad_function_call" would have saved me some debug time.
[Bug c++/56104] New: Wrong "dereferencing type-punned pointer" warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56104
Bug #: 56104
Summary: Wrong "dereferencing type-punned pointer" warning
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joerg.rich...@pdv-fs.de
cat > t.cc <
struct Wrap
{
inline static void call( Foo cc )
{
(cc.*MEMFUNC)(); // <- warning here
}
};
void bar()
{
Wrap::call( Foo() );
}
EOF
/tools/pkg/gcc/4.7.2/bin/g++ -Wall -O2 -c -o t.o t.cc
Outputs:
t.cc: In instantiation of 'static void Wrap::call(Foo) [with
MEMSIG = void (Foo::*)(); MEMSIG MEMFUNC = &Foo::call]':
t.cc:18:38: required from here
t.cc:12:7: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
I think this warning is wrong.
[Bug c++/70462] New: Unnecessary "base object constructor" for final classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70462
Bug ID: 70462
Summary: Unnecessary "base object constructor" for final
classes
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
Target Milestone: ---
g++ -std=c++11 -c -o t.o -x c++ - << EOF
struct Bar final
{
Bar();
};
Bar::Bar()
{}
EOF
nm t.o
gives:
T _ZN3BarC1Ev
T _ZN3BarC2Ev
'_ZN3BarC2Ev' is the "base object constructor" and can never be called for
'final' classes, AFAICS.
[Bug c++/70462] Unnecessary "base object constructor" for final classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70462 --- Comment #3 from Jörg Richter --- Well, my real problem is related to coverage analysis. Function coverage will show the base object constructor as not called. But my concrete test case is more complex and involves virtual functions and inheritance. Might me that an alias is not enough in the real code. A different solution to my problem might be to exclude the base object constructor from coverage analysis. A related problem: I also have a class that is always used as a base class and will never be constructed directly (because it has pure virtual functions). The "complete object constructor" is emitted nevertheless. But function coverage marks it as never called.
[Bug c++/81671] New: std::nullptr_t incompatible to std::nullptr_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81671
Bug ID: 81671
Summary: std::nullptr_t incompatible to std::nullptr_t
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
Target Milestone: ---
cat > t.cc << EOF
#include
template struct Bar
{};
template struct Bar
{
template struct Bind { constexpr static int const cb = 0;
};
};
int foo()
{
return Bar::Bind::cb;
}
EOF
g++ t.cc
Gives this:
t.cc: In instantiation of 'struct Bar':
t.cc:10:37: required from here
t.cc:6:37: error: '' is not a valid template argument for type
'std::nullptr_t' because it is of type 'std::nullptr_t'
Works with 4.9.3, 5.3.0 and 6.2.0
[Bug c++/81675] New: attribute(noreturn) of destructor in :? not honored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81675
Bug ID: 81675
Summary: attribute(noreturn) of destructor in :? not honored
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
Target Milestone: ---
cat > t.cc << EOF
struct S
{
~S() __attribute__((noreturn));
int a;
};
int foo()
{
false ? 5 : S().a;
}
EOF
g++ -c -Wall t.cc
GCC 6.2.0 prints:
t.cc: In function 'int foo()':
t.cc:9:1: warning: control reaches end of non-void function [-Wreturn-type]
GCC 5.3.0 seems to detect correctly that foo() will never return.
[Bug tree-optimization/81401] False positive sprintf warning at O2 (-Wformat-overflow)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81401
Jörg Richter changed:
What|Removed |Added
CC||joerg.rich...@pdv-fs.de
--- Comment #2 from Jörg Richter ---
See also:
#include
void foo()
{
char buf[2];
for( int i = 0; i < 10; ++i )
sprintf( buf, "%d", i );
}
t.cc: In function 'void foo()':
t.cc:2:6: warning: 'sprintf' may write a terminating nul past the end of the
destination [-Wformat-overflow=]
void foo()
^~~
t.cc:6:12: note: 'sprintf' output between 2 and 3 bytes into a destination of
size 2
sprintf( buf, "%d", i );
~~~^~~~
[Bug c++/81858] New: Wrong strict-aliasing warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81858
Bug ID: 81858
Summary: Wrong strict-aliasing warning
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
Target Milestone: ---
cat > t.cc < struct Quux
{
void foo() const
{
Baz baz;
if( !baz.val )
{
}
}
};
EOF
g++ -O2 -c t.cc -Wall
t.cc: In member function 'void Quux::foo() const':
t.cc:16:16: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
if( !baz.val )
^~~
[Bug libstdc++/81885] New: operator-> not checked by -D_GLIBCXX_ASSERTIONS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81885 Bug ID: 81885 Summary: operator-> not checked by -D_GLIBCXX_ASSERTIONS Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: joerg.rich...@pdv-fs.de Target Milestone: --- unique_ptr::operator* is checked with __glibcxx_assert. But unique_ptr::operator-> uses only _GLIBCXX_DEBUG_PEDASSERT. I think the later can use __glibcxx_assert too. Same for the other pointer templates.
[Bug libstdc++/81885] operator-> not checked by -D_GLIBCXX_ASSERTIONS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81885 --- Comment #2 from Jörg Richter --- Okay, I see your point. But I think calling operator->() to get the pointer is not a very common use-case. Its more like get() is the right function for this task.
[Bug c++/82008] New: nonnull attribute and multiple inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82008
Bug ID: 82008
Summary: nonnull attribute and multiple inheritance
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
Target Milestone: ---
cat > t.cc << EOF
struct Base1
{
char s;
};
struct Base2
{
char x;
};
struct Deriv : Base1, Base2
{};
void funcyyy( Base2* ) __attribute__((nonnull));
void funcxxx( Deriv* d )
{
funcyyy( d );
}
EOF
g++ -c t.cc -o t.o -Wall
template.cc: In function 'void funcxxx(Deriv*)':
template.cc:18:14: warning: null argument where non-null required (argument 1)
[-Wnonnull]
funcyyy( d );
If funcyyy is declared as taking Base1* it works without warning.
[Bug c++/82008] nonnull attribute and multiple inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82008 --- Comment #2 from Jörg Richter --- My original intention was to use the attribute to skip the nullptr check when up-casting. So my preference is to optimize based on the attribute if possible.
[Bug gcov-profile/64634] [4.8/4.9 Regression] gcov reports catch(...) as not executed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64634 --- Comment #6 from Jörg Richter --- Is this stable enough to be considered for 4.9.3?
[Bug target/66019] New: Corrupt libstdc++ on AIX 6.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66019 Bug ID: 66019 Summary: Corrupt libstdc++ on AIX 6.1 Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: joerg.rich...@pdv-fs.de Target Milestone: --- Host: powerpc-ibm-aix6.1.0.0 Target: powerpc-ibm-aix6.1.0.0 Build: powerpc-ibm-aix6.1.0.0 I am building GCC 4.9.2 on AIX 6.1 with the same script I used for AIX 5.3. $ configure --enable-languages=c,c++ --disable-bootstrap --disable-nls --with-local-prefix=/not_existing_directory --enable-frame-pointer --with-ld=/bin/ld --with-as=/bin/as --prefix=/tools/pkg/gcc/4.9.2 make && make install During build of GCC are a lot of warnings like this: ld: 0711-768 WARNING: Object ../src/c++98/.libs/libc++98convenience.a[locale-inst.o], section 1, function .std::istreambuf_iterator >::_M_get() const: The branch at address 0x15534 is not followed by a recognized no-op or TOC-reload instruction. The unrecognized instruction is 0x8D3C0001. There are 3728 ld 0711-768 warnings. On AIX 5.3 there are no warnings using the same script. Nevertheless GCC builds without errors. But when compiling and running application code that calles std::istreambuf_iterator::_M_get() the process termines with SIGSEGV or SIGILL. Here is a gdb/bt of a crashed process: #0 0x090002edc554 in std::istreambuf_iterator >::_M_get () from libstdc++.a(libstdc++.so.6) #1 0x090002e6dce4 in std::istreambuf_iterator > std::num_get > >::_M_extract_int(std::istreambuf_iterator >, std::istreambuf_iterator >, std::ios_base&, std::_Ios_Iostate&, unsigned int&) const [clone .localalias.77] () from libstdc++.a(libstdc++.so.6) #2 0x090002e6db6c in std::num_get > >::do_get(std::istreambuf_iterator >, std::istreambuf_iterator >, std::ios_base&, std::_Ios_Iostate&, unsigned int&) const [clone .localalias.236] () from libstdc++.a(libstdc++.so.6) #3 0x090002e92658 in std::istream& std::istream::_M_extract(unsigned int&) [clone .localalias.69] () from libstdc++.a(libstdc++.so.6) Searching for ld: 0711-768 seem to indicate that this warnings should not be ignored. The error might be related to some missing GNU-tool. The 6.1 machine is not using the same GNU tools like the 5.3 maschine. I know that GCC does not build with AIX-sed/awk. Might be that I missed another GNU tool that will fix this problem. But I have no idea what it can be.
[Bug c++/59739] New: missed optimization: attribute ((pure)) could be honored more often
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59739
Bug ID: 59739
Summary: missed optimization: attribute ((pure)) could be
honored more often
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
Created attachment 31786
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31786&action=edit
Script for demonstration
Attached is a script (t.sh) that creates two .cc files, compiles and executes
them.
It tests whether attribute ((pure)) is used on different functions with this
signatures:
struct Struct { int val; };
int globalInt();
Struct globalStruct();
struct Class {
int classInt();
Struct classStruct();
virtual int classVirtualInt();
virtual Struct classVirtualStruct();
};
The output with GCC is 4.8.2 is this:
globalInt: 1
globalStruct: 0
classInt: 1
classStruct: 0
classVirtualInt: 0
classVirtualStruct: 0
Meaning only globalInt and classInt are optimised.
All other functions are also candidates for attribute-pure optimisation.
[Bug c++/59821] New: __builtin_LINE and __builtin_FILE for new'd objects is wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59821
Bug ID: 59821
Summary: __builtin_LINE and __builtin_FILE for new'd objects is
wrong
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
The script below demonstrates that __builtin_LINE used in constructors
is different when the object is allocated with new. The same is true for
__builtin_FILE and I suspect also for __builtin_FUNCTION.
cat > t.cc <
struct Foo
{
int line;
Foo( int line = __builtin_LINE() )
: line( line )
{}
};
int main()
{
assert( Foo().line == (new Foo)->line );
}
EOF
g++ -o t t.cc
./t
[Bug other/36368] Fixincludes corrupts sysmacros.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36368 Jörg Richter changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Jörg Richter --- Not a bug
[Bug c++/59739] missed optimization: attribute ((pure)) could be honored more often
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59739 --- Comment #1 from Jörg Richter --- clang seems to optimize all cases.
[Bug libstdc++/59603] std::random_shuffle tries to swap element with itself
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59603 Jörg Richter changed: What|Removed |Added CC||joerg.rich...@pdv-fs.de --- Comment #2 from Jörg Richter --- Seems like we have hit this bug too. It happens not only in debug mode. We have a testcase that triggers valgrind errors in non-debug mode while calling random_shuffle. I can try to reduce this testcase if it would help.
[Bug libstdc++/59603] std::random_shuffle tries to swap element with itself
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59603 --- Comment #4 from Jörg Richter --- Are you sure that this is not a iter_swap problem? I have found nothing in the standard that iter_swap( x, x ) is undefined. I always thought types do not have to be prepared to handle self move assignment.
[Bug gcov-profile/64634] New: gcov reports catch(...) as not executed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64634
Bug ID: 64634
Summary: gcov reports catch(...) as not executed
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
cat > t.cc <
void catchEx()
{
exit(0);
try
{}
catch( int )
{}
}
int main()
{
try
{
throw 5;
}
catch(...)
{
catchEx();
}
}
EOF
g++ -o t t.cc -O0 --coverage -g
./t
-
If you now call gcov like this:
gcov -b t.gcda
t.cc.gcov looks like this:
...
=: 18: catch(...)
call0 never executed
call1 never executed
call2 returned 100%
call3 never executed
...
But if you call gcov like this:
gcov -a -b t.gcda
Then t.cc.gcov looks like this:
...
1: 18: catch(...)
%: 18-block 0
call0 never executed
call1 never executed
1: 18-block 1
1: 18-block 2
call2 returned 100%
%: 18-block 3
call3 never executed
...
Note that in the former case the catch(...) on line 18 is
marked as not executed and in the later it is marked as
executed. This results in wrong coverage information.
Calling gcov always with -a is no option for us. Because
gcov -a is much slower.
Works with GCC 4.4.4. Fails since 4.5.
[Bug sanitizer/65365] New: false positive signed negation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65365 Bug ID: 65365 Summary: false positive signed negation Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: joerg.rich...@pdv-fs.de CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org cat > t.c <
[Bug preprocessor/48248] New: Wrong error message location when compiling preprocessed code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48248
Summary: Wrong error message location when compiling
preprocessed code
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joerg.rich...@pdv-fs.de
$ cat > foobar.h << EOF
enum Foo
{
BAR
};
#define BAR(x)
#define BARBAR BAR
EOF
$ cat > main.cc << EOF
#include "foobar.h"
void func()
{
(void)BARBAR;
aaa;
}
EOF
$ g++ -c main.cc
main.cc: In function 'void func()':
main.cc:8:3: error: 'aaa' was not declared in this scope
$ g++ -E main.cc > main.ii
$ g++ -c main.ii
foobar.h: In function 'void func()':
foobar.h:8:3: error: 'aaa' was not declared in this scope
Please notice the wrong filename when compiling the preprocessed source.
GCC 4.4 doesn't have this problem.
[Bug libstdc++/48313] New: std::bind with template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48313
Summary: std::bind with template function
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joerg.rich...@pdv-fs.de
$ cat > t.cc << EOF
#include
template void func( T )
{}
int main( int, char** )
{
std::bind( func, 0 );
}
EOF
$ g++ t.cc -std=gnu++0x
t.cc: In function 'int main(int, char**)':
t.cc:8:27: error: cannot bind 'void(int)' lvalue to 'void (&&)(int)'
...
This is with GCC 4.6.0. This works with GCC 4.5.2.
[Bug preprocessor/48248] [4.5/4.6/4.7 Regression] Wrong error message location when compiling preprocessed code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48248 --- Comment #3 from joerg.rich...@pdv-fs.de 2011-03-28 13:51:55 UTC --- (In reply to comment #2) > Can't reproduce this, neither with g++ 4.5, nor trunk. Did you delete the empty lines?
[Bug libstdc++/49559] New: stable_sort calls self-move-assignment operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49559
Summary: stable_sort calls self-move-assignment operator
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joerg.rich...@pdv-fs.de
$ cat t.cc
#include
#include
#include
struct MyMoveClass
{
int val_;
explicit MyMoveClass( int val = 0 )
: val_( val )
{
std::cout << "ctr this=" << this << std::endl;
}
MyMoveClass( MyMoveClass const& rhs )
: val_( rhs.val_ )
{
std::cout << "ctr copy this=" << this << " rhs=" << &rhs << std::endl;
}
MyMoveClass( MyMoveClass && rhs )
: val_( rhs.val_ )
{
std::cout << "ctr move this=" << this << " rhs=" << &rhs << std::endl;
rhs.val_ = 0;
}
MyMoveClass& operator=( MyMoveClass && rhs )
{
std::cout << "assign move this=" << this << " rhs=" << &rhs << std::endl;
assert( this != &rhs );
val_ = rhs.val_;
rhs.val_ = 0;
return *this;
}
MyMoveClass& operator=( MyMoveClass const& rhs )
{
std::cout << "assign copy this=" << this << " rhs=" << &rhs << std::endl;
val_ = rhs.val_;
return *this;
}
~MyMoveClass()
{
std::cout << "dtr this=" << this << std::endl;
}
bool operator<( MyMoveClass const& rhs ) const
{
return val_ < rhs.val_;
}
};
int main()
{
MyMoveClass v(5);
std::stable_sort( &v, &v+1 );
return 0;
}
$ g++ -std=gnu++0x -o t t.cc
$ ./t
ctr this=0xbfe1730c
ctr move this=0x8afd008 rhs=0xbfe1730c
assign move this=0xbfe1730c rhs=0x8afd008
assign move this=0xbfe1730c rhs=0xbfe1730c
template: template.cc:31: MyMoveClass& MyMoveClass::operator=(MyMoveClass&&):
Assertion `this != &rhs' failed.
>From DR 1204: "Additionally this clarifies that move assignment operators need
not perform the traditional if (this != &rhs) test commonly found (and needed)
in copy assignment operators."
Note that std::sort() calls no copy constructor or assignment operator at all.
Seems sensible when there is only one element.
[Bug libstdc++/49559] [C++0x] stable_sort calls self-move-assignment operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49559
--- Comment #22 from joerg.rich...@pdv-fs.de 2011-07-13 15:11:21 UTC ---
Is it possible to fix it for 4.6.2?
Following program is a 4.4 regression (when using -std=gnu++0x):
---8<-
#include
#include
#include
using namespace std;
int main( int, char** )
{
vector v;
v.push_back( 1 );
stable_sort( &v, &v+1 );
assert( v.size() == 1 );
return 0;
}
---8<-
Works with 4.4.1, fails with 4.5 and 4.6
