* patch that caused regression PR optimization/4382
@ 2002-12-19 16:57 Janis Johnson
2003-01-24 21:42 ` Richard Henderson
0 siblings, 1 reply; 2+ messages in thread
From: Janis Johnson @ 2002-12-19 16:57 UTC (permalink / raw)
To: gcc, rth; +Cc: rodrigc, bangerth
The regression reported in PR optimization/4382 showed up starting
with this patch:
2000-12-20 Richard Henderson <rth@redhat.com>
* rtl.h (REG_NON_LOCAL_GOTO): New.
* rtl.c (reg_note_name): Update.
* stmt.c (expand_goto): Emit a REG_NON_LOCAL_GOTO note.
* builtins.c (expand_builtin_longjmp): Likewise.
* flow.c (make_edges): Check for REG_NON_LOCAL_GOTO and do
not emit an edge.
Here's the test case I used, which is in the PR. There's also a
smaller one in the PR that causes the same ICE.
-------------------
struct jmp_buf {
void *p[5];
};
static void jumpaway(struct jmp_buf *ptr)
{
__builtin_longjmp(ptr ,1);
abort();
}
int main(void)
{
struct jmp_buf buf;
if (__builtin_setjmp(&buf) == 0) {
} else
return 0;
jumpaway(&buf);
abort();
return 0;
}
-------------------
Output from the compiler when compiled with -O3 using mainline:
4382.c: In function `main':
4382.c:20: error: Wrong amount of branch edges after unconditional jump 0
4382.c:20: internal compiler error: verify_flow_info failed
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
I'll add this information to the PR.
Janis
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: patch that caused regression PR optimization/4382
2002-12-19 16:57 patch that caused regression PR optimization/4382 Janis Johnson
@ 2003-01-24 21:42 ` Richard Henderson
0 siblings, 0 replies; 2+ messages in thread
From: Richard Henderson @ 2003-01-24 21:42 UTC (permalink / raw)
To: Janis Johnson; +Cc: gcc, rodrigc, bangerth
On Thu, Dec 19, 2002 at 03:25:13PM -0800, Janis Johnson wrote:
> The regression reported in PR optimization/4382 showed up ...
This is _really_ borderline, but ok. We'll hack around
this problem like so.
If you call both __builtin_setjmp and __builtin_longjmp in
the same function, expect things to crash again, however.
All I can say is, Don't Do That.
r~
* tree-inline.c (find_builtin_longjmp_call_1): New.
(find_builtin_longjmp_call): New.
(inlinable_function_p): Use it.
Index: tree-inline.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree-inline.c,v
retrieving revision 1.40
diff -c -p -d -r1.40 tree-inline.c
*** tree-inline.c 24 Dec 2002 08:30:33 -0000 1.40
--- tree-inline.c 24 Jan 2003 21:14:47 -0000
*************** static tree add_stmt_to_compound PARAMS
*** 125,130 ****
--- 125,132 ----
#endif /* INLINER_FOR_JAVA */
static tree find_alloca_call_1 PARAMS ((tree *, int *, void *));
static tree find_alloca_call PARAMS ((tree));
+ static tree find_builtin_longjmp_call_1 PARAMS ((tree *, int *, void *));
+ static tree find_builtin_longjmp_call PARAMS ((tree));
/* The approximate number of instructions per statement. This number
need not be particularly accurate; it is used only to make
*************** tree_inlinable_function_p (fn)
*** 873,879 ****
return inlinable_function_p (fn, NULL);
}
! /* if *TP is possibly call to alloca, return nonzero. */
static tree
find_alloca_call_1 (tp, walk_subtrees, data)
tree *tp;
--- 875,881 ----
return inlinable_function_p (fn, NULL);
}
! /* If *TP is possibly call to alloca, return nonzero. */
static tree
find_alloca_call_1 (tp, walk_subtrees, data)
tree *tp;
*************** find_alloca_call_1 (tp, walk_subtrees, d
*** 885,892 ****
return NULL;
}
! /* Return subexpression representing possible alloca call,
! if any. */
static tree
find_alloca_call (exp)
tree exp;
--- 887,893 ----
return NULL;
}
! /* Return subexpression representing possible alloca call, if any. */
static tree
find_alloca_call (exp)
tree exp;
*************** find_alloca_call (exp)
*** 894,899 ****
--- 895,926 ----
return walk_tree (&exp, find_alloca_call_1, NULL, NULL);
}
+ static tree
+ find_builtin_longjmp_call_1 (tp, walk_subtrees, data)
+ tree *tp;
+ int *walk_subtrees ATTRIBUTE_UNUSED;
+ void *data ATTRIBUTE_UNUSED;
+ {
+ tree exp = *tp, decl;
+
+ if (TREE_CODE (exp) == CALL_EXPR
+ && TREE_CODE (TREE_OPERAND (exp, 0)) == ADDR_EXPR
+ && (decl = TREE_OPERAND (TREE_OPERAND (exp, 0), 0),
+ TREE_CODE (decl) == FUNCTION_DECL)
+ && DECL_BUILT_IN_CLASS (decl) == BUILT_IN_NORMAL
+ && DECL_FUNCTION_CODE (decl) == BUILT_IN_LONGJMP)
+ return decl;
+
+ return NULL;
+ }
+
+ static tree
+ find_builtin_longjmp_call (exp)
+ tree exp;
+ {
+ return walk_tree (&exp, find_builtin_longjmp_call_1, NULL, NULL);
+ }
+
/* Returns nonzero if FN is a function that can be inlined into the
inlining context ID_. If ID_ is NULL, check whether the function
can be inlined at all. */
*************** inlinable_function_p (fn, id)
*** 933,938 ****
--- 960,973 ----
allowance for extern inline functions, though. */
else if (! (*lang_hooks.tree_inlining.disregard_inline_limits) (fn)
&& currfn_insns > MAX_INLINE_INSNS_SINGLE)
+ ;
+ /* We can't inline functions that call __builtin_longjmp at all.
+ The non-local goto machenery really requires the destination
+ be in a different function. If we allow the function calling
+ __builtin_longjmp to be inlined into the function calling
+ __builtin_setjmp, Things will Go Awry. */
+ /* ??? Need front end help to identify "regular" non-local goto. */
+ else if (find_builtin_longjmp_call (DECL_SAVED_TREE (fn)))
;
/* Refuse to inline alloca call unless user explicitly forced so as this may
change program's memory overhead drastically when the function using alloca
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2003-01-24 21:20 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-12-19 16:57 patch that caused regression PR optimization/4382 Janis Johnson
2003-01-24 21:42 ` Richard Henderson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).