[Bug c++/40561] New: code does not compile -- compiles fine when replacing != with !(==)
In file included from /usr/include/boost/config.hpp:35,
from /usr/include/boost/variant/detail/config.hpp:16,
from /usr/include/boost/variant/variant.hpp:20,
from /usr/include/boost/variant.hpp:17,
from tmp.cpp:16:
/usr/include/boost/config/compiler/gcc.hpp:92:7: warning: #warning "Unknown
compiler version - please run the configure tests and report the results"
tmp.cpp: In constructor 'VamsSystemFunction<__ID__, __PCHECK_ARGS__,
__PSET_ID__, __PDUMP__, __GET_TYPE__, __GET_DEP__>::VamsSystemFunction(const
std::string&, int, const std::list >&)
[with SySystemFunction::enumSystemFunctions __ID__ =
epredef_error_with_pos_math, void (VamsFnct::* __PCHECK_ARGS__)(const
std::string&, int) = &VamsFnct::empty_check, void (VamsFnct::*
__PSET_ID__)(SyModule*) = &VamsFnct::empty_setId, void (VamsFnctSystem::*
__PDUMP__)(CWriteIfc*, int, const VamsBase*)const =
&VamsFnctSystem::predef_error_with_pos_math_dump, const TyBase*
(VamsFnctSystem::* __GET_TYPE__)()const = &VamsFnctSystem::empty_getType,
std::set, std::allocator >
(VamsFnct::* __GET_DEP__)()const = &VamsFnct::getNullDependencies]':
tmp.cpp:2259: instantiated from here
tmp.cpp:581: error: invalid operands of types 'bool' and 'int' to binary
'operator=='
--
Summary: code does not compile -- compiles fine when replacing !=
with !(==)
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: peter_foelsche at agilent dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40561
[Bug c++/40561] code does not compile -- compiles fine when replacing != with !(==)
--- Comment #1 from peter_foelsche at agilent dot com 2009-06-26 17:29 --- Created an attachment (id=18074) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18074&action=view) gpperror.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40561
[Bug c++/40561] code does not compile -- compiles fine when replacing != with !(==)
--- Comment #2 from peter_foelsche at agilent dot com 2009-06-26 17:36 --- Created an attachment (id=18075) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18075&action=view) gpperror.cpp -- peter_foelsche at agilent dot com changed: What|Removed |Added Attachment #18074|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40561
[Bug c++/37592] New: compiler gives up optimizing even on 64bit systems
When compiling certain complex calculation files I'm getting the message:
/a/new/scs/glow/d2/pfoelsch/build/opt/linux_x86_64-o/gglib/../../../source_opt/gglib/hicum222/NLM.cpp:
In member function 'void NLM_hicumshxpm::CModel::calcDer(NLM_hicumshxpm*,
double*, CDer<13u, double, const double, CDerHelper>*, CDer<13u, double, const
double, CDerHelper>*) const':
/a/new/scs/glow/d2/pfoelsch/build/opt/linux_x86_64-o/gglib/../../../source_opt/gglib/hicum222/NLM.cpp:1014:
warning: GCSE disabled: 59869 basic blocks and 139067 registers
/a/new/scs/glow/d2/pfoelsch/build/opt/linux_x86_64-o/gglib/../../../source_opt/gglib/hicum222/NLM.cpp:1014:
warning: jump bypassing disabled: 59833 basic blocks and 139067 registers
I think giving up optimizing because of memory problems
should not be done anymore on 64bit systems.
Sorry -- I cannot attach the source code.
--
Summary: compiler gives up optimizing even on 64bit systems
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: peter_foelsche at agilent dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37592
[Bug c++/37592] compiler gives up optimizing even on 64bit systems (GCSE disabled, jump bypassing disabled)
--- Comment #1 from peter_foelsche at agilent dot com 2008-09-19 20:39 --- sorry -- I did discover the matching option to increase memory. -- peter_foelsche at agilent dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37592
[Bug c++/40561] code does not compile -- compiles fine when replacing != with !(==)
--- Comment #4 from peter_foelsche at agilent dot com 2009-08-26 18:06 --- Created an attachment (id=18430) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18430&action=view) gpperror.cpp shorter testcase -- peter_foelsche at agilent dot com changed: What|Removed |Added Attachment #18075|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40561
[Bug c++/40561] code does not compile -- compiles fine when replacing != with !(==)
--- Comment #5 from peter_foelsche at agilent dot com 2009-08-26 18:13 --- seems to be fixed in gcc v4.4.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40561
[Bug c++/42355] New: Segmentation fault
I don't think I can provide the source code. But maybe the debug output already provides some hints. This is using boost 1_39 -- Summary: Segmentation fault Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: peter_foelsche at agilent dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42355
[Bug c++/42355] Segmentation fault
--- Comment #1 from peter_foelsche at agilent dot com 2009-12-12 01:34 --- Created an attachment (id=19280) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19280&action=view) console output of the compiler -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42355
[Bug c++/42355] Segmentation fault
--- Comment #2 from peter_foelsche at agilent dot com 2009-12-12 01:36 --- maybe on Monday I can create an instance like described of the offending classes -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42355
[Bug c++/42355] Segmentation fault
--- Comment #3 from peter_foelsche at agilent dot com 2009-12-12 01:37 --- the compiler takes more than 10GB of RAM. There is 40GB of RAM available. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42355
[Bug c++/42355] Segmentation fault
--- Comment #4 from peter_foelsche at agilent dot com 2009-12-12 01:40 --- the same happens with boost 1_40 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42355
[Bug c++/42355] Segmentation fault
--- Comment #6 from peter_foelsche at agilent dot com 2009-12-15 20:58 --- Created an attachment (id=19313) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19313&action=view) tmp.cpp g++ -c tmp.cpp -I ~/boost_1_40_0 -g -g is important -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42355
[Bug c++/42355] Segmentation fault
--- Comment #9 from peter_foelsche at agilent dot com 2010-01-04 18:12 --- Created an attachment (id=19464) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19464&action=view) tmp.ii -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42355
[Bug c++/42355] Segmentation fault
--- Comment #12 from peter_foelsche at agilent dot com 2010-01-04 20:00 --- (In reply to comment #10) > Please also provide output of g++ -v. If you manage to compile this > successfully then the output of -ftime-report will also be interesting. > Confirmed with -g (-g0 is very fast and lean). G++ 4.1 doesn't want to > grok the testcase. Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ./configure --prefix=/users/pfoelsch --with-mpfr=/users/pfoelsch --with-gmp=/users/pfoelsch Thread model: posix gcc version 4.4.2 (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42355
[Bug c++/42355] Segmentation fault
--- Comment #13 from peter_foelsche at agilent dot com 2010-01-08 21:37 --- boost::mpl::sort seems to be known to be a memory hog. Also on other platforms. I replaced this with other code. -- peter_foelsche at agilent dot com changed: What|Removed |Added Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42355
[Bug c++/34121] New: wrong this pointer passed to constructor of temporary object
When compiling with -O3 everything is fine. When compiling with -g this pointer passed to constructors and destructors don't line up. I guess the this pointer passed to the constructor is bogus. -- Summary: wrong this pointer passed to constructor of temporary object Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: peter_foelsche at agilent dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34121
[Bug c++/34121] wrong this pointer passed to constructor of temporary object
--- Comment #1 from peter_foelsche at agilent dot com 2007-11-16 16:38 --- Created an attachment (id=14564) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14564&action=view) test.cpp contains a main function at the end which calls printf() with some temporary objects. I put printf() into every constructor and every destructor to show the this pointer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34121
[Bug c++/34121] wrong this pointer passed to constructor of temporary object
--- Comment #2 from peter_foelsche at agilent dot com 2007-11-16 16:42 --- the attached piece of source code does exhibit the compiler problem with the new compiler. When compiling using -O3 the code works fine. When compiling using -g the bug happens. Some temporary objects are being created and one constructor call for these temporary objects gets the wrong address. To exhibit this I put calls to printf() into the constructor and destructor showing the this pointer. Look at the end of the code to find the main function with one call to printf() and several temporary objects of my old string class. (Btw I'm not using this class anymore since we have std::string.) Here comes the output of the test showing the problem. You can see that the destructors are called in opposite order to the destructors. CString::CString(): this==0x7fbfff8d30 CString::CString(): this==0x7fbfff8c80 CString::CString(): this==0x7fbfff8dc0 CString::CString(): this==0x7fbfff8d60 CString::CString(): this==0x7fbfff8d00 testÉtest CString::~CString(): this==0x7fbfff8d00 CString::~CString(): this==0x7fbfff8d60 CString::~CString(): this==0x7fbfff8dc0 CString::~CString(): this==0x7fbfff8d90 free(): invalid pointer 0x7fbfff8c88! CString::~CString(): this==0x7fbfff8d30 If you dig deep into this code you will find that one object is of type derived from CString. This is where the compiler calculates the wrong address. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34121
[Bug c++/34121] wrong this pointer passed to constructor of temporary object
--- Comment #3 from peter_foelsche at agilent dot com 2007-11-16 16:45 --- We tested this only for the 64bit version. I don't know if this happens for the 32bit version. The operating system is LINUX: Linux bonfire 2.4.21-47.0.1.EL #1 SMP Fri Oct 13 17:51:36 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34121
