|
|
Hi,
This is the ACATS c953002 failure. The problem was introduced with:
2004-11-03 Andrew Pinski <pinskia@xxxxxxxxxxxxxx>
PR tree-opt/18231
* tree.c (staticp) <case FUNCTION_DECL>: Nested functions are static
also.
which causes the compiler to now accept
struct S {
void (*f)(int);
};
extern void baz(struct S *);
extern void p(int);
void foo(void)
{
int u;
void bar(int val)
{
u = val;
}
static struct S s = { bar };
baz(&s);
p(u);
}
and of course no trampoline is built for 'bar'.
The patch looks questionable to me:
- /* Nested functions aren't static, since taking their address
- involves a trampoline. */
- return ((decl_function_context (arg) == 0 || DECL_NO_STATIC_CHAIN
(arg))
- && ! DECL_NON_ADDR_CONST_P (arg)
- ? arg : NULL);
+ /* Nested functions are static, even though taking their address will
+ involve a trampoline as we unnest the nested function and create
+ the trampoline on the tree level. */
given the head comment of staticp:
/* If arg is static -- a reference to an object in static storage -- then
return the object. This is not the same as the C meaning of `static'.
If arg isn't static, return NULL. */
It seems to me that we have introduced an implementation bias. Reverting the
patch fixes c95300[123] and c980002, and introduces no regression since no
testcase was commited with the patch.
However the change was made partly because of pessimization problems, so it is
perhaps better to keep it. Another alternative is to test for nested
functions in the ADDR_EXPR case of initializer_constant_valid_p.
Bootstrapped/regtested on i586-mandrake-linux-gnu.
2005-01-10 Eric Botcazou <ebotcazou@xxxxxxxxxxxxxx>
PR middle-end/18820
* varasm.c (initializer_constant_valid_p) <ADDR_EXPR>: Return
zero for nested functions needing a static chain or functions with
a non-constant address.
2005-01-10 Eric Botcazou <ebotcazou@xxxxxxxxxxxxxx>
* gcc.dg/nested-func-2.c: New test.
--
Eric Botcazou
nested_func_init.diff
Description: Text Data
nested-func-2.c
Description: Text Data
|
|