[Bug target/81803] [7/8 regression] miscompilation at -O1 on mips64el
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81803 Chen Qi changed: What|Removed |Added CC||qi.chen at windriver dot com --- Comment #11 from Chen Qi --- mpf, I'm working on Yocto project. I also encountered a similar problem. In brief, on qemumips64, `systemctl status ' has the output of `systemctl show '. I debugged a little bit and found that it's not the code logic's problem. Instead it's gcc optimization problem. With '-O1', the problem is reproduced; with '-O0', the problem is gone. Please see https://bugzilla.yoctoproject.org/show_bug.cgi?id=12266 for more details. I used the patch you created in attachment. And things work correctly with '-O2'. Is there any plan sending the patch to gcc mailing list? Is there any known problem about the patch? Best Regards, Chen Qi (In reply to mpf from comment #9) > Created attachment 42075 [details] > Proposed fix > > Off-thread James pointed out that one of my patches I did last year appeared > to fix this issue but it was one I reverted owing to breaking ARM (and > probably others). The thread was: > > https://gcc.gnu.org/ml/gcc-patches/2017-02/msg00518.html > > At the time I thought I had fixed the same problem twice and that the > changes to simplify_operand_subreg were sufficient. It occurs to me however > that simplify_operand_subreg only has the opportunity to fix > WORD_REGISTER_OPERATIONS issues affecting subreg(mem) patterns not > subreg(reg) patterns where reg is a pseudo that may yet be spilled. > > I can't say that I am 100% convinced yet with my thinking here but I've > attached an updated version of the original patch with some changes: > > * Incorporated Eric's feedback on the original patch to check > GET_MODE_PRECISION instead of GET_MODE_SIZE for comparing whether a mode is > strictly narrower > * Limited the test to word sized inner modes or smaller > * Limited the test to OP_OUT or OP_INOUT as I can't see any reason why it > would matter if we do a narrower input reload > > This is barely tested but does fix testcase-c which is the only one I can > get to trigger.
[Bug sanitizer/82517] use-after-scope for a variable with big alignment causes a false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82517 --- Comment #3 from Jim Wilson --- Author: wilson Date: Mon Oct 30 01:57:59 2017 New Revision: 254211 URL: https://gcc.gnu.org/viewcvs?rev=254211=gcc=rev Log: Fix cygwin builds, broken by PR sanitizer/82517 fix. gcc/ * gimplify.c: Include tm_p.h. Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c
[Bug c/58884] OPTIONAL warning when a temprary value is created and not used.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58884 --- Comment #4 from Max TenEyck Woodbury --- I think there is a misunderstanding here... These patches, when I submit them, will add a new warning option. It is not appropriate to add this to the normal "unused-value" warning because the situation being diagnosed has a side effect that is important. In fact you do not want to see this warning in almost all circumstances. It becomes important only when enforcing -very- pedantic stylistic rules and when abusing the definition of the prefix and postfix operators in C++. I repeat -- this is a warning option you do -not- want to turn on under normal circumstances. It is also inappropriate to conflate this diagnostic with the usual 'unused value' diagnostic; they are -not- equivalent. On the other hand, under rare circumstances, this option could provide vital information. The patches, again when submitted, document the problem in several places. The most important is in the gimplify module where the postix operator is converted to a prefix operator under certain specific conditions. This transformation is -not- under the control of any optimization option; it is -always- done. Situations where you could change this so that you -can- control this optimization, which I am -not- recommending, need to be identified first and would stress the optimization system in ways it has not been stressed before. The patches, when submitted, would add that identification capability. Before actually changing the code generator, there should be an investigation of what impact the change would have. These patches, when submitted, would provide that information. All the other places where this situation can be identified simply ignore the problem. Part of the patch set, when submitted, will include adding diagnostics in those places. That brings us back to comment 2. This is a new option and it adds at least one and possibly more than one diagnostic messages that will need translation. While I can figure out what the English text of these messages should be, I am aware that changes to the message translation infrastructure should be made when the new messages are added. I am -not- conversant with that procedure. I am looking for directions on how to add new messages into the translation infrastructure. I want to provide the information needed to start the translation process as part of the patch submission.
[Bug libfortran/80850] Sourced allocate() fails to allocate a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80850 --- Comment #22 from DIL --- On the other hand, I have another test which also crashes in clone_object() for the same reason, but does not involve gfc_vector.F90. It goes through line 710 of gfc_list.F90, function ListIterAppend(), where again a concrete type is argument associated with an unlimited polymorphic dummy variable. So I suspect the _len corruption happens here as well.
[Bug libfortran/80850] Sourced allocate() fails to allocate a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80850 --- Comment #21 from DIL --- Paul, And as you have noticed, this characteristic construct is there (gfc_vector:806) :) call this%container%vec_tile(q(4))%tile_batch(q(3))%batch_seg(q(2))%seg_elem(q(1))%& _elem_ctor(elem_val,ierr,assoc_only=assoc)
[Bug libfortran/80850] Sourced allocate() fails to allocate a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80850 --- Comment #20 from DIL --- So, if we for a second trust valgrind executed on an -O3 optimized binary, then line 1402 of gfc_graph.F90, namely, ierr=git%append_vertex(vrt) should be the origin. The object vrt (type graph_vertex_t) is the object being cloned in clone_object() that contains an uninitialized field (you mentioned _len in the previous comments). In line 1113 of gfc_graph.F90, this graph_vertex_t object is passed into VectorIterAppend() (gfc_vector.F90:773) as an unlimited polymorphic dummy argument, so I guess that's where it acquires the _len field, right?
[Bug libfortran/80850] Sourced allocate() fails to allocate a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80850 --- Comment #19 from DIL --- On my Ubuntu 16.04, removing STAT= from the allocate() statement does not help unfortunately, but it now crashes via a different path, although for the same reason. I will experiment more to see if I can finally reproduce this problem in a debugger, so far I was unlucky. Interestingly, valgrind passes the DEV version (the one which fails if run standalone), but complains with the OPT version about an uninitialized stack variable. However, further inspecting the function referred to as the origin of an uninitialized stack variable does not really reveal anything. But this explains why -fno-automatic helps. Somehow it seems like an uninitialized field appears on the stack. I will continue digging to see if I can find something useful for you to inspect. Thanks for looking into this issue! Below is the valgrind output from the OPT binary: ==16508== Conditional jump or move depends on uninitialised value(s) ==16508==at 0x41D597: __stsubs_MOD_clone_object (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x424D67: __gfc_base_MOD_contelemconstruct (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x408667: __gfc_vector_MOD_vectorelemconstruct (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x40AC5B: __gfc_vector_MOD_vectoriterappend (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x418ACD: __gfc_graph_MOD_graphiterappendvertex (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x4195B7: __gfc_graph_test_MOD_test_gfc_graph (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x401FB8: MAIN__ (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x40169E: main (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508== Uninitialised value was created by a stack allocation ==16508==at 0x4191D4: __gfc_graph_test_MOD_test_gfc_graph (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508== ==16508== Conditional jump or move depends on uninitialised value(s) ==16508==at 0x4C2DB3C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==16508==by 0x41D5B0: __stsubs_MOD_clone_object (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x424D67: __gfc_base_MOD_contelemconstruct (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x408667: __gfc_vector_MOD_vectorelemconstruct (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x40AC5B: __gfc_vector_MOD_vectoriterappend (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x418ACD: __gfc_graph_MOD_graphiterappendvertex (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x4195B7: __gfc_graph_test_MOD_test_gfc_graph (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x401FB8: MAIN__ (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x40169E: main (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508== Uninitialised value was created by a stack allocation ==16508==at 0x4191D4: __gfc_graph_test_MOD_test_gfc_graph (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508== ==16508== Conditional jump or move depends on uninitialised value(s) ==16508==at 0x41D597: __stsubs_MOD_clone_object (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x424D67: __gfc_base_MOD_contelemconstruct (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x408667: __gfc_vector_MOD_vectorelemconstruct (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x40AE0D: __gfc_vector_MOD_vectoriterappend (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x418ACD: __gfc_graph_MOD_graphiterappendvertex (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x4195B7: __gfc_graph_test_MOD_test_gfc_graph (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x401FB8: MAIN__ (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x40169E: main (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508== Uninitialised value was created by a stack allocation ==16508==at 0x4191D4: __gfc_graph_test_MOD_test_gfc_graph (in /home/div/src/ExaTensor/GFC/test_gfc.x)
[Bug tree-optimization/82762] [8 Regression] ICE at -O3: in compute_antic, at tree-ssa-pre.c:2397
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82762 Martin Liška changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2017-10-29 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Target Milestone|--- |8.0 Summary|ICE at -O3: in |[8 Regression] ICE at -O3: |compute_antic, at |in compute_antic, at |tree-ssa-pre.c:2397 |tree-ssa-pre.c:2397 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r254005.
[Bug c++/82764] [7/8 Regression] ICE in output_constructor_regular_field, at varasm.c:5030
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82764 Martin Liška changed: What|Removed |Added Known to work||8.0 --- Comment #2 from Martin Liška --- Looks current trunk is OK.
[Bug tree-optimization/82765] [6/7/8 Regression] ICE at -Os on valid code on x86_64-linux-gnu: in tree_to_shwi, at tree.c:6611
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82765 Martin Liška changed: What|Removed |Added Keywords||needs-bisection Status|UNCONFIRMED |NEW Last reconfirmed||2017-10-29 CC||marxin at gcc dot gnu.org Summary|ICE at -Os on valid code on |[6/7/8 Regression] ICE at |x86_64-linux-gnu: in|-Os on valid code on |tree_to_shwi, at|x86_64-linux-gnu: in |tree.c:6611 |tree_to_shwi, at ||tree.c:6611 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with GCC 4.7.0.
[Bug c++/82764] [7/8 Regression] ICE in output_constructor_regular_field, at varasm.c:5030
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82764 Martin Liška changed: What|Removed |Added Target||arm-linux-gnueabi-gcc Status|UNCONFIRMED |NEW Known to work||6.4.0 Keywords||needs-bisection Last reconfirmed||2017-10-29 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 Summary|internal compiler error: in |[7/8 Regression] ICE in |output_constructor_regular_ |output_constructor_regular_ |field, at varasm.c:5030 |field, at varasm.c:5030 Known to fail||7.2.0 --- Comment #1 from Martin Liška --- Confirmed.
[Bug target/68192] AIX libstdc++ TLS symbols not exported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68192 Brian Groose changed: What|Removed |Added CC||brian at groose dot com --- Comment #6 from Brian Groose --- I recently bumped into this while using g++ 5.3.0. Do I need to configure gcc with any specific options when building gcc for this to work properly? I do see the expected "L" symbols type in libstdc++: $ /usr/bin/nm /opt/act-gcc-5.3.0/lib/gcc/powerpc-ibm-aix6.1.8.0/5.3.0/../../../pthread/libstdc++.a | grep __once_callable ._ZSt15__once_callable d 537213852 4 _ZSt15__once_callable L 4294935556 _ZSt15__once_callable d 537213856 4 _ZSt15__once_callable:G139 - 4
[Bug tree-optimization/82455] missing -Warray-bounds on strcpy offset in an out-of-bounds range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82455 Martin Sebor changed: What|Removed |Added Keywords||patch Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-10-29 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Patch posted for review: https://gcc.gnu.org/ml/gcc-patches/2017-10/msg02143.html
[Bug libfortran/80850] Sourced allocate() fails to allocate a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80850 --- Comment #18 from Paul Thomas --- It is the _len field of the unlimited polymorphic 'object' that is not being initialized... somewhere. Paul
[Bug c++/66268] struct { volatile int x; } should not be trivially copyable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66268 Jonathan Wakely changed: What|Removed |Added CC||jpakkane at gmail dot com --- Comment #2 from Jonathan Wakely --- *** Bug 82763 has been marked as a duplicate of this bug. ***
[Bug c++/82763] std::is_pod works incorrectly with volatile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82763 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Jonathan Wakely --- Yes I think it's a dup. That issue also has a reference to the core issue that affects this trait. *** This bug has been marked as a duplicate of bug 66268 ***
Enquiry
Hello, I got your email from a directory on Google. I am currently undergoing a building project, and i will like to purchase items to make a few unique installments i'm sure your company will be able to provide me with the services. kindly get back to me if you can so we can discuss Quote,specification and estimate. Regards. Karim Smith
[Bug libfortran/80850] Sourced allocate() fails to allocate a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80850 --- Comment #17 from Paul Thomas --- (In reply to Paul Thomas from comment #16) > (In reply to Jerry DeLisle from comment #15) > > (In reply to Paul Thomas from comment #14) > > > PS If I remove the STAT= from the allocate, the code runs just fine in DEV > > > mode. > > > > > > Paul > > > > I have not looke at this one. Have you tried with valgrind or sanitize tools > > to see if there are any further hints? > > You will see from the above that the reporter himself has done this already. > Just for the record, the backtrace from the error is: > > Program aborted. Backtrace: > #0 0x4595c4 in __stsubs_MOD_clone_object > at > /home/pault/prs/pr80850/GFC-master-790d92e9ccc22c559db4118f2b8a51170c135b19/ > stsubs.F90:305 > #1 0x470f0e in __gfc_base_MOD_contelemconstruct > at > /home/pault/prs/pr80850/GFC-master-790d92e9ccc22c559db4118f2b8a51170c135b19/ > gfc_base.F90:354 > #2 0x438586 in __gfc_vector_MOD_vectorelemconstruct > at > /home/pault/prs/pr80850/GFC-master-790d92e9ccc22c559db4118f2b8a51170c135b19/ > gfc_vector.F90:211 > #3 0x4266cd in __gfc_vector_MOD_vectoriterappend > at > /home/pault/prs/pr80850/GFC-master-790d92e9ccc22c559db4118f2b8a51170c135b19/ > gfc_vector.F90:807 > #4 0x44a83e in __gfc_graph_MOD_graphiterappendvertex > at > /home/pault/prs/pr80850/GFC-master-790d92e9ccc22c559db4118f2b8a51170c135b19/ > gfc_graph.F90:1113 > #5 0x45022e in __gfc_graph_test_MOD_test_gfc_graph > at > /home/pault/prs/pr80850/GFC-master-790d92e9ccc22c559db4118f2b8a51170c135b19/ > gfc_graph.F90:1402 > #6 0x403ac1 in MAIN__ > at > /home/pault/prs/pr80850/GFC-master-790d92e9ccc22c559db4118f2b8a51170c135b19/ > main.F90:94 > #7 0x403ed5 in main > > gfc_vector.F90:807 contains a call that looks horribly like the problem line > in PR81758 > call > this%container%vec_tile(q(4))%tile_batch(q(3))%batch_seg(q(2))%seg_elem(q(1)) > %& > _elem_ctor(elem_val,ierr,assoc_only=assoc) > > However, it is definitely the allocate that is the problem as evidenced by > it disappearing if STAT is not used. > > Unfortunately, as Dmitry reports above, the fault also goes away in gdb :-( > > Cheers > > Paul I instrumented trans.c:(gfc_allocate_using_malloc) by setting the STAT variable to the requested size, when an allocation error is detected. When the code fails, this is a typical outcome: > errc = 1713129088 #ERROR(stsubs:clone_object): sourced allocate() failed: Attempt to allocate an allocated object Somewhere, use is being made of an uninitialized variable upstream from stsubs.F90(clone_object). Paul
[Bug target/54006] __atomic_always_lock_free inconsistent with __GCC_ATOMIC_INT_LOCK_FREE et al. on crisv32 and hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54006 Eric Gallager changed: What|Removed |Added Component|c |target Summary|__atomic_always_lock_free |__atomic_always_lock_free |inconsistent with |inconsistent with |__GCC_ATOMIC_INT_LOCK_FREE |__GCC_ATOMIC_INT_LOCK_FREE |et al. |et al. on crisv32 and hppa --- Comment #7 from Eric Gallager --- (In reply to Hans-Peter Nilsson from comment #6) > On Fri, 28 Jul 2017, egallager at gcc dot gnu.org wrote: > > Testcase compiles, runs, and exits with 0 for me on i386-apple-darwin9.8.0. > > I'm not sure how that target is relevant? > > (I forgot to set a target and can't edit the bug at present > other than replying by email, but see the original description > for a list of targets where the test was known to fail or > expected to fail. Note also that the test is brittle and may be > undesirably optimized to always pass.) oh ok, I missed that part at first; retitling to include the targets. > > > Can you try again? > > Not for a couple of weeks, sorry. > > brgds, H-P
[Bug c++/81702] [7/8 Regression] ICE in gimple_get_virt_method_for_vtable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81702
--- Comment #6 from Adam Lackorzynski ---
So assuming removing the assert is ok, the following would address it:
--- gimple-fold.c (revision 254205)
+++ gimple-fold.c (working copy)
@@ -6439,7 +6439,6 @@
gcc_assert (init);
if (init == error_mark_node)
{
- gcc_assert (in_lto_p);
/* Pass down that we lost track of the target. */
if (can_refer)
*can_refer = false;
Do you think this could be applied?
[Bug c++/82722] [7 Regression] ICE in finish_member_declaration, at cp/semantics.c:2984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82722 --- Comment #4 from berni.w11 at gmx dot net --- Created attachment 42497 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42497=edit another testcase
[Bug c++/82737] [ICE] Compiler segfault on compilation of a certain file (full cause unknown) (file too large for upload, link provided)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82737 --- Comment #10 from Matti Bryce --- If anyone knows how to get gcc with debug symbols, that'd be useful, because I could get a better stack trace.
[Bug c++/82737] [ICE] Compiler segfault on compilation of a certain file (full cause unknown) (file too large for upload, link provided)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82737 --- Comment #9 from Matti Bryce --- (In reply to Martin Liška from comment #2) > Hi. I can't build your pre-process source file. Please follow steps to > reduce the segfault: > https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction > > And please try to run it in gdb (adding -wrapper gdb,--args), and print > back-trace. Thanks. I added a backtrace (though my GCC doesn't have debug symbols). It seems the stack is corrupt at some point.
[Bug c++/82737] [ICE] Compiler segfault on compilation of a certain file (full cause unknown) (file too large for upload, link provided)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82737 --- Comment #8 from Matti Bryce --- Created attachment 42496 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42496=edit Backtrace
[Bug target/82725] [8 Regression] [x86_64] internal compiler error: in change_address_1, at emit-rtl.c:2162
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82725 --- Comment #6 from Uroš Bizjak --- I'm testing following patch: --cut here-- Index: i386.c === --- i386.c (revision 254199) +++ i386.c (working copy) @@ -15079,10 +15079,16 @@ legitimate_pic_address_disp_p (rtx disp) break; op0 = XEXP (XEXP (disp, 0), 0); op1 = XEXP (XEXP (disp, 0), 1); - if (!CONST_INT_P (op1) - || INTVAL (op1) >= 16*1024*1024 + if (!CONST_INT_P (op1)) + break; + if (GET_CODE (op0) == UNSPEC + && (XINT (op0, 1) == UNSPEC_DTPOFF + || XINT (op0, 1) == UNSPEC_NTPOFF) + && trunc_int_for_mode (INTVAL (op1), SImode) == INTVAL (op1)) + return true; + if (INTVAL (op1) >= 16*1024*1024 || INTVAL (op1) < -16*1024*1024) -break; + break; if (GET_CODE (op0) == LABEL_REF) return true; if (GET_CODE (op0) == CONST --cut here-- As suggested, the patch allows offsetted UNSPEC_DTPOFF/UNSPEC_NTPOFF relocations in legitimate_pic_address_disp_p. In fact, these are already allowed in x86_64_immediate_operand, with the immediate limited to SImode values.
[Bug c++/82737] [ICE] Compiler segfault on compilation of a certain file (full cause unknown) (file too large for upload, link provided)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82737 --- Comment #7 from Matti Bryce --- (In reply to Martin Liška from comment #5) > Confirmed with cross compiler, I reduce a test-case. I've attempted to reduce a test case, but after 2 days of running creduce, the produced file won't generate the error. I'm going to run gdb now.(In reply to Martin Liška from comment #5), and see if I can do anything with it (though if someone could give me tips for what to look for, that'd be great).
