--- Comment #8 from nam3l3ss dot bugreportaccount at gmail dot com
2008-01-04 15:53 ---
I checked again, actually, even the second "bugok" file is a silent failure on
the written environment, so the segfault is kind of an improvement there, but I
could swear the original one run without
--- Comment #7 from pcarlini at suse dot de 2008-01-04 11:31 ---
I don't have much to say. The implementation of std::find (rather simple
besides a bit of unrolling) has not changed at all between 4.1.x and 4.2.x.
--
pcarlini at suse dot de changed:
What|Removed
--- Comment #5 from nam3l3ss dot bugreportaccount at gmail dot com
2008-01-04 03:31 ---
Of course, if you add the check for the appropriate type of end iterator right
before the find gets called, the problem goes away without a trace.
Btw and imho, the worst thing that find may get as
--- Comment #4 from nam3l3ss dot bugreportaccount at gmail dot com
2008-01-04 03:30 ---
Created an attachment (id=14873)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14873&action=view)
THIS is the working, 32bit, older compiler generated version.
Forgot to add -save-temps after
--- Comment #3 from nam3l3ss dot bugreportaccount at gmail dot com
2008-01-04 02:57 ---
Created an attachment (id=14872)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14872&action=view)
This is the working, 32bit, older compiler generated version.
--
http://gcc.gnu.org/bugzil
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-03 16:48 ---
This is obviously an error in your program or LGraph as you can see
#2 0x00402cb3 in std::find<__gnu_cxx::__normal_iterator const*, std::vector,
std::allocator > > >, int> (__first={_M_current =
0x0}, __las
--- Comment #1 from nam3l3ss dot bugreportaccount at gmail dot com
2008-01-03 15:37 ---
Created an attachment (id=14867)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14867&action=view)
Full, preprocessed source code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34650