http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43808
--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> 2010-11-09
12:47:56 UTC ---
The first patch bootstrapped/regtested fine on both x86_64-linux and
i686-linux, the second one caused a couple of regressions on x86_64-linux (and
worked fine on i686-linux):
FAIL: gcc.target/x86_64/abi/test_3_element_struct_and_unions.c compilation,
-O0 (internal compiler error)
UNRESOLVED: gcc.target/x86_64/abi/test_3_element_struct_and_unions.c execution,
-O0
FAIL: gcc.target/x86_64/abi/test_basic_array_size_and_align.c compilation, -O0
(internal compiler error)
UNRESOLVED: gcc.target/x86_64/abi/test_basic_array_size_and_align.c execution,
-O0
FAIL: gnat.dg/gen_disp.adb (test for excess errors)
FAIL: gnat.dg/specs/private_with.ads (test for excess errors)
All of these are ICEs in update_alias_info_with_stack_vars, short testcase on
x86_64-linux is:
int
main (void)
{
{
struct S1 { long double t1; long double t2; float t3; } s1;
}
{
struct S2 { long double t1; long double t2; double t3; } s2;
}
}
The ICE is in:
/* We should never end up partitioning SSA names (though they
may end up on the stack). Neither should we allocate stack
space to something that is unused and thus unreferenced. */
gcc_assert (DECL_P (decl)
&& referenced_var_lookup (DECL_UID (decl)));
decl is s1 (VAR_DECL), but referenced_var_lookup returns NULL on it.
Wonder if we just shouldn't add && optimize into the assert, or whether it is
really a problem if a non-referenced var makes it in.
