gcc-5-20150301 is now available
Snapshot gcc-5-20150301 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/5-20150301/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 221092 You'll find: gcc-5-20150301.tar.bz2 Complete GCC MD5=4ff29e74b7dbe8e437ff39c05e10b531 SHA1=e8201396627fc732e5f34891b8060cc594647932 Diffs from 5-20150222 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
loop_latch_edge is NULL during jump threading
In linaro-4.9-branch, with the following (reduced) test case, I run into
a situation where loop_latch_edge is NULL during jump threading. I am
wondering if this a possible during jump threading or the error lies
some where else? I can't reproduce it with the trunk.
int a;
fn1() {
enum { UQSTRING, SQSTRING, QSTRING } b = UQSTRING;
while (1)
switch (a) {
case '\'':
b = QSTRING;
default:
switch (b)
case UQSTRING:
return;
b = SQSTRING;
}
}
x.c:2:1: internal compiler error: Segmentation fault
fn1() {
^
0x83694f crash_signal
/home/kugan.vivekanandarajah/work/sources/gcc-fsf/linaro/gcc/toplev.c:337
0x96d8a8 thread_block_1
/home/kugan.vivekanandarajah/work/sources/gcc-fsf/linaro/gcc/tree-ssa-threadupdate.c:797
0x96da3e thread_block
/home/kugan.vivekanandarajah/work/sources/gcc-fsf/linaro/gcc/tree-ssa-threadupdate.c:941
0x96e59c thread_through_all_blocks(bool)
/home/kugan.vivekanandarajah/work/sources/gcc-fsf/linaro/gcc/tree-ssa-threadupdate.c:1866
0x9d77e9 finalize_jump_threads
/home/kugan.vivekanandarajah/work/sources/gcc-fsf/linaro/gcc/tree-vrp.c:9709
0x9d77e9 execute_vrp
/home/kugan.vivekanandarajah/work/sources/gcc-fsf/linaro/gcc/tree-vrp.c:9864
0x9d77e9 execute
/home/kugan.vivekanandarajah/work/sources/gcc-fsf/linaro/gcc/tree-vrp.c:9938
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
If I apply the following patch, segfault goes away. Is this aright approach?
diff --git a/gcc/tree-ssa-threadupdate.c b/gcc/tree-ssa-threadupdate.c
index d1b289f..0bcef35 100644
--- a/gcc/tree-ssa-threadupdate.c
+++ b/gcc/tree-ssa-threadupdate.c
@@ -794,6 +794,8 @@ thread_block_1 (basic_block bb, bool noloop_only,
bool joiners)
if (loop->header == bb)
{
e = loop_latch_edge (loop);
+ if (!e)
+ return false;
vec *path = THREAD_PATH (e);
if (path
@@ -1114,6 +1116,8 @@ thread_through_loop_header (struct loop *loop,
bool may_peel_loop_headers)
basic_block tgt_bb, atgt_bb;
enum bb_dom_status domst;
+ if (!latch)
+return false;
/* We have already threaded through headers to exits, so all the
threading
requests now are to the inside of the loop. We need to avoid creating
irreducible regions (i.e., loops with more than one entry block), and
Thanks,
Kugan
Re: loop_latch_edge is NULL during jump threading
On 03/01/15 16:32, Kugan wrote: In linaro-4.9-branch, with the following (reduced) test case, I run into a situation where loop_latch_edge is NULL during jump threading. I am wondering if this a possible during jump threading or the error lies some where else? I can't reproduce it with the trunk. There's really no way to tell without a lot more information. If you can't reproduce on the 4.9 branch or the trunk, then you're likely going to have to do the real digging. THe first thing I tend to do with these things is to draw the CFG and annotate it with all the jump threading paths. Then I look at how the jump threading paths interact with each other and the loop structure, then reconcile that with the constraints placed on threading in tree-ssa-threadupdate.c. If I apply the following patch, segfault goes away. Is this aright approach? No way to know for sure without further analysis. jeff
Re: loop_latch_edge is NULL during jump threading
On 02/03/15 15:29, Jeff Law wrote: > On 03/01/15 16:32, Kugan wrote: >> In linaro-4.9-branch, with the following (reduced) test case, I run into >> a situation where loop_latch_edge is NULL during jump threading. I am >> wondering if this a possible during jump threading or the error lies >> some where else? I can't reproduce it with the trunk. > There's really no way to tell without a lot more information. If you > can't reproduce on the 4.9 branch or the trunk, then you're likely going > to have to do the real digging. > > THe first thing I tend to do with these things is to draw the CFG and > annotate it with all the jump threading paths. Then I look at how the > jump threading paths interact with each other and the loop structure, > then reconcile that with the constraints placed on threading in > tree-ssa-threadupdate.c. Thanks Jeff. I will do the same. Kugan
Re: loop_latch_edge is NULL during jump threading
On March 2, 2015 5:32:27 AM CET, Kugan wrote: >On 02/03/15 15:29, Jeff Law wrote: >> On 03/01/15 16:32, Kugan wrote: >>> In linaro-4.9-branch, with the following (reduced) test case, I run >into >>> a situation where loop_latch_edge is NULL during jump threading. I >am >>> wondering if this a possible during jump threading or the error >lies >>> some where else? I can't reproduce it with the trunk. >> There's really no way to tell without a lot more information. If you >> can't reproduce on the 4.9 branch or the trunk, then you're likely >going >> to have to do the real digging. >> >> THe first thing I tend to do with these things is to draw the CFG and >> annotate it with all the jump threading paths. Then I look at how >the >> jump threading paths interact with each other and the loop structure, >> then reconcile that with the constraints placed on threading in >> tree-ssa-threadupdate.c. > >Thanks Jeff. I will do the same. You might want to look at trunk fixes to loop preserving code. Istr some cfg hook fixes. The loop latch test is definitely wrong. Richard. >Kugan
