[Bug c++/35594] New: using vector::resize within a recursive function causes a crash
The below code fragment (.ii attached) causes a segmentation fault. I can't
see anything logically wrong with the code, but I am guessing an optimization
of the pointers within "out" are causing the problem: a reallocation occurs in
a deeper stack level, and the outer stack still maintains an old pointer.
However, since this code is logically valid, shouldn't it work, or shouldn't
there are least be some way for it to work? Or, am I missing something obvious
here.
My first attempt was to mark "vector" volatile, but I then can't call any of
its functions...
--
#include
using namespace std;
unsigned append( unsigned count, vector& out )
{
unsigned base = out.size();
unsigned need = count * 2;
out.resize( base + need );
unsigned at = base;
for( unsigned i = 0; i < count; i ++ )
{
out.at(at++) = i;
out.at(at++) = append( count-1, out );
}
return base;
}
int main()
{
vector v;
append( 50, v );
}
--
g++ (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
Linux version 2.6.22-1-mepis64-smp ([EMAIL PROTECTED]) (gcc version 4.1.2
20061115
(prerelease) (Debian 4.1.1-21)) #1 SMP PREEMPT Mon Feb 18 23:03:02 EST 2008
--
Summary: using vector::resize within a recursive function causes
a crash
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eda-qa at disemia dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35594
[Bug c++/35594] using vector::resize within a recursive function causes a crash
--- Comment #1 from eda-qa at disemia dot com 2008-03-14 21:19 --- Created an attachment (id=15323) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15323&action=view) g++ --save-temp fail.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35594
[Bug c++/35594] using vector::resize within a recursive function causes a crash
--- Comment #3 from eda-qa at disemia dot com 2008-03-14 21:34 --- Agreed. That was the obvious bit I was missing. Sorry about that, just didn't recognize it at first. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35594
[Bug c++/57178] New: bogus warning with -O3 using boost::optional
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57178 Bug #: 57178 Summary: bogus warning with -O3 using boost::optional Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: eda...@disemia.com GCC appears to be producing a bogus warning about an unitialized value. This happens at optimization levels -O1 and higher. It uses a boost optional as I was unable to reduce it to something more fundamental. Command line: g++ -c uninit_warn.cpp --std=c++0x -Wuninitialized -O1 Warning: uninit_warn.cpp: In function ‘void test(boost::optional)’: uninit_warn.cpp:17:12: warning: ‘*((void*)& q +4)’ may be used uninitialised in this function [-Wuninitialized]
[Bug c++/57178] bogus warning with -O3 using boost::optional
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57178 --- Comment #1 from eda-qa at disemia dot com 2013-05-05 14:56:35 UTC --- Created attachment 30034 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30034 example
[Bug c++/50455] New: duplicate class/constructor silently accepted, wrong constructor linked
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50455 Bug #: 50455 Summary: duplicate class/constructor silently accepted, wrong constructor linked Classification: Unclassified Product: gcc Version: 4.4.5 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: eda...@disemia.com Created attachment 25316 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25316 1 of 2 reproduction source files
[Bug c++/50455] duplicate class/constructor silently accepted, wrong constructor linked
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50455 --- Comment #1 from eda-qa at disemia dot com 2011-09-19 12:20:24 UTC --- The compiler/linker is silently ignoring that a class has been defined twice and this results in the linker linking to the incorrect constructor at instantiation time. This was found in a large set of libraries, but the two attached files reproduce the same problem. Reproduce: - Compile a program using the attached files and the instantiation in main() will use the wrong constructor. g++ -o test main.cpp duplicate.cpp Now, with optimizations the correct constructor is used, presumably since it is inlined and thus not subject to linking: g++ -O3 -o test main.cpp duplicate.cpp NOTE: The code is *invalid* but emits no diagnostic as one would expect. The issue is thus that the linker would be expected to emit a diagnostic message, likely an error about duplicate symbol.
[Bug c++/50455] duplicate class/constructor silently accepted, wrong constructor linked
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50455 --- Comment #2 from eda-qa at disemia dot com 2011-09-19 12:21:24 UTC --- Created attachment 25317 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25317 2 of 2 reproduction source files
[Bug c++/50455] duplicate class/constructor silently accepted, wrong constructor linked
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50455 --- Comment #3 from eda-qa at disemia dot com 2011-09-19 12:23:13 UTC --- Triage notes: As the issue is that no diagnostic is produced I was uncertain how to locate duplicates -- I tried a few search queries and came up empty. Also note that both source files are needed to reproduce the error, it cannot be reproduced (to my knowledge) with a single source file. The error *happens* at link time, but I'm uncertain what part in the tool chain is truly responsible for it.
[Bug c++/50455] duplicate class/constructor silently accepted, wrong constructor linked
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50455 --- Comment #4 from eda-qa at disemia dot com 2011-09-19 12:25:08 UTC --- g++ (GCC) 4.4.5 20101112 (Red Hat 4.4.5-2) GNU ld version 2.20.51.0.2-20.fc13 20091009 Linux devbox 2.6.34.9-69.fc13.x86_64 #1 SMP Tue May 3 09:23:03 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
[Bug c++/50455] duplicate class/constructor silently accepted, wrong constructor linked
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50455 --- Comment #8 from eda-qa at disemia dot com 2011-09-19 12:53:33 UTC --- I agree that this is a violation of the ODR. I agree this might be difficult for the linker to detect. However for a user this is a serious problem that can be very hard to determine without the help of the tool chain. Consider that in my original project the duplicate definition was in some other library in the automake setup. This implies that linking with *any* external library/object can introduce this error into your project without any compiler/linker diagnostic. I would suspect an average user would expect a "duplicate symbol" error for this type of error. Otherwise this makes it unsafe to add new classes to any C++ library, ever: any new class may silently replace the constructor of some class by the user of the library.
[Bug c++/22588] New: lookup error in template base class (regression/works in 3.3)
Name resolution in a template class derived from another template class does not
appear to be working.
This worked fine in 3.3.
Attached code produces the following compile-time error:
tpl_struct.cc: In member function 'void ArchiverStdNorm::Write(const T&)':
tpl_struct.cc:28: error: 's' was not declared in this scope
GCC Version:
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr--enable-shared
--with-system-zlib --libexecdir=/usr/lib --enable-nls --without-included-gettext
--enable-threads=posix --program-suffix=-4.0 --enable-__cxa_atexit
--enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug
--enable-java-gc=boehm --enable-java-awt=gtk
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr
--disable-werror --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.0.1 (Debian 4.0.1-2)
--
Summary: lookup error in template base class (regression/works in
3.3)
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eda-qa at disemia dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22588
[Bug c++/22588] lookup error in template base class (regression/works in 3.3)
--- Additional Comments From eda-qa at disemia dot com 2005-07-21 13:24 --- Created an attachment (id=9317) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9317&action=view) Testcase/demonstration of defect -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22588
[Bug c++/22597] New: pure attribute produces incorrect results
In the attached code the pure attribute is causing the result to be random/junk
on the final calculation in main. According to the docs the function seems to
qualify for pure status -- it uses only the parameters given. It does however
create a temporary (but as this exists on the stack I assumed it is okay, since
it still doesn't violate the notion of being pure).
Expected result (with -DNOATTRIB or -DNOCOPYCTOR flags):
5, 5
1, 1
Actual Result (compiled with g++ -o test point_err.cc):
5, 5
338848, 4.85849e-270
(NOTE: Worked on 3.3)
It is curious also that no declaring the copy constructor also allows this code
to work with the pure attribute.
So, either this is a bug in the 4.0 "pure" handling, or the documentation for
"pure" is omitting some vital point which my code violates.
--
Summary: pure attribute produces incorrect results
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eda-qa at disemia dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22597
[Bug c++/22597] pure attribute produces incorrect results
--- Additional Comments From eda-qa at disemia dot com 2005-07-21 19:54 --- Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr--enable-shared --with-system-zlib --libexecdir=/usr/lib --enable-nls --without-included-gettext --enable-threads=posix --program-suffix=-4.0 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-werror --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.0.1 (Debian 4.0.1-2) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22597
[Bug c++/22597] pure attribute produces incorrect results
--- Additional Comments From eda-qa at disemia dot com 2005-07-21 19:55 --- Created an attachment (id=9325) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9325&action=view) demostration of the error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22597
[Bug c++/19741] New: less than optimal error message (actually, just appears wrong, use of ?)
(Such an error also appears to exist in 5458)
In the attached example the following error appears:
tpladdr.cc: In function `int main()':
tpladdr.cc:21: error: no matching function for call to `Op::Exec(int,
)'
tpladdr.cc:14: error: candidates are: static bool Op::Exec(T, bool (*)(T))
[with T = int]
In this case the error does not help (actually it misleads) as to what the
problem is. The reference to seems to indicate that it doesn't
know the type of that paremeter, when in indeed it actually does, but the
function type has the wrong signature...
Simply correcting the function signature to:
bool Func( T param )
Allows the program to work as it should.
Thus the error message is simply very confusing.
--
Summary: less than optimal error message (actually, just appears
wrong, use of ?)
Product: gcc
Version: 3.3.1
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eda-qa at disemia dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19741
[Bug c++/19741] less than optimal error message (actually, just appears wrong, use of ?)
--- Additional Comments From eda-qa at disemia dot com 2005-02-01 14:06 --- Created an attachment (id=8121) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8121&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19741
[Bug c++/16224] [3.3/3.4/3.5 Regression] internal compiler error: in write_unscoped_name (template/namespace)
--- Additional Comments From eda-qa at disemia dot com 2004-06-28 05:40 --- Agreed. The redux and my original code are invalid, putting the template specialization in its proper namespace removes the error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16224
[Bug c++/18756] New: Optimize setting causes a double/float comparison to break
The code demonstrates a case where the optimizer breaks the correctness of the
code. That is, without optimization the code works as intended, but with
optimization the code triggers the assertion error.
Reproduce:
Compile code: g++ -O0 dlbcomp.cc
Execute:
Okay
Compile code: g++ -O3 dlbcomp.cc
Execute:
Okay
a.out: dlbcomp.cc:40: int main(int, char**): Assertion `b == d.scalar()' failed.
Aborted
(Code Attached)
(Sorry, I do not have access to a newer GCC build at this time)
> g++ -v -save-temps -O3 dlbcomp.cc
Reading specs from /usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.3.1/specs
Configured with: ../configure --prefix=/usr --libdir=/usr/lib
--with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info
--enable-shared --enable-threads=posix --disable-checking --enable-long-long
--enable-__cxa_atexit --enable-languages=c,c++,ada,f77,objc,java,pascal
--host=i586-mandrake-linux-gnu --with-system-zlib
Thread model: posix
gcc version 3.3.1 (Mandrake Linux 9.2 3.3.1-2mdk)
/usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.3.1/cc1plus -E -D__GNUG__=3
-quiet -v -iprefix /usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.3.1/
-D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=1 -D_GNU_SOURCE dlbcomp.cc
-O3 dlbcomp.ii
ignoring nonexistent directory "/usr/i586-mandrake-linux-gnu/include"
ignoring nonexistent directory "/usr/i586-mandrake-linux-gnu/include"
ignoring duplicate directory "/usr/include/c++/3.3.1"
ignoring duplicate directory "/usr/include/c++/3.3.1/i586-mandrake-linux-gnu"
ignoring duplicate directory "/usr/include/c++/3.3.1/backward"
ignoring duplicate directory
"/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.3.1/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/3.3.1
/usr/include/c++/3.3.1/i586-mandrake-linux-gnu
/usr/include/c++/3.3.1/backward
/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.3.1/include
/usr/local/include
/usr/include
End of search list.
/usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.3.1/cc1plus -fpreprocessed
dlbcomp.ii -quiet -dumpbase dlbcomp.cc -auxbase dlbcomp -O3 -version -o
dlbcomp.s
GNU C++ version 3.3.1 (Mandrake Linux 9.2 3.3.1-2mdk) (i586-mandrake-linux-gnu)
compiled by GNU C version 3.3.1 (Mandrake Linux 9.2 3.3.1-2mdk).
GGC heuristics: --param ggc-min-expand=47 --param ggc-min-heapsize=31972
as -V -Qy -o dlbcomp.o dlbcomp.s
GNU assembler version 2.14.90.0.5 (i586-mandrake-linux-gnu) using BFD version
2.14.90.0.5 20030722
/usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.3.1/collect2 --eh-frame-hdr
-m elf_i386 -dynamic-linker /lib/ld-linux.so.2
/usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.3.1/../../../crt1.o
/usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.3.1/../../../crti.o
/usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.3.1/crtbegin.o
-L/usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.3.1
-L/usr//bin/../lib/gcc-lib -L/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.3.1
-L/usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.3.1/../../..
-L/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.3.1/../../.. dlbcomp.o -lstdc++ -lm
-lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.3.1/crtend.o
/usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.3.1/../../../crtn.o
--
Summary: Optimize setting causes a double/float comparison to
break
Product: gcc
Version: 3.3.1
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eda-qa at disemia dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18756
[Bug c++/18756] Optimize setting causes a double/float comparison to break
--- Additional Comments From eda-qa at disemia dot com 2004-12-01 15:10 --- Created an attachment (id=7649) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7649&action=view) Non preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18756
[Bug c++/18756] Optimize setting causes a double/float comparison to break
--- Additional Comments From eda-qa at disemia dot com 2004-12-01 15:12 --- Created an attachment (id=7650) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7650&action=view) ii file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18756
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Additional Comments From eda-qa at disemia dot com 2004-12-01 16:24 --- To summarize, this defect effectively states that: assert( (x/y) == (x/y) ) may cause an assertion if compiled with optimization. While I understand why it happens, that doesn't mean it isn't a defect. This makes it impossible to turn on the optimizer with any code using floating point and still expect to get a correct result. Perhaps in some situations this is okay, but in general this is not. This would also mean the following are also invalid code -- which I'm fairly certain the C/C++ standards would state otherwise: a = (x/y); assert( a == x/y ) //may Abort if( a == x/y ) assert( a == x/y ) //may Abort -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
