This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug rtl-optimization/36419] [4.1/4.3/4.4 Regression] Wrong unwind info with -Os -fasynchronous-unwind-tables
- From: "jakub at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 6 Jun 2008 08:03:06 -0000
- Subject: [Bug rtl-optimization/36419] [4.1/4.3/4.4 Regression] Wrong unwind info with -Os -fasynchronous-unwind-tables
- References: <bug-36419-87@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #7 from jakub at gcc dot gnu dot org 2008-06-06 08:03 -------
Ok, I'll bootstrap/regtest patch 1).
To answer your question about 2), consider e.g.:
__attribute__((noinline))
void foo (int, int)
{
static int n = 0;
void *esp;
asm volatile ("movl %%esp, %0" : "=r" (esp));
__builtin_printf ("foo %p\n", esp);
if (n++ == 0)
throw 1;
}
__attribute__((noinline))
void baz (int, int, int, int, int, int, int)
{
static int n = 1;
void *esp;
asm volatile ("movl %%esp, %0" : "=r" (esp));
__builtin_printf ("baz %p\n", esp);
if (n++ == 0)
throw 1;
}
struct A { A () { }; ~A (); char c[24]; };
__attribute__((noinline))
A::~A ()
{
asm volatile ("" : : : "memory");
}
__attribute__((noinline))
void bar ()
{
A a;
try
{
foo (1, 2);
baz (3, 4, 5, 6, 7, 8, 9);
}
catch (...)
{
}
foo (1, 2);
baz (3, 4, 5, 6, 7, 8, 9);
}
int
main ()
{
bar ();
return 0;
}
with -m32 -Os -fasynchronous-unwind-tables -mpreferred-stack-boundary=4 vs.
-m32 -Os -mpreferred-stack-boundary=4. The generated .text
is identical between both, yet without -fa-u-t it shows correct stack alignment
(both foo calls have the same %esp, baz 16 bytes below it), but with -fa-u-t
the second foo call has %esp 8 bytes below the first foo call's %esp (so
clearly
one of them is not aligned to the preferred stack boundary), and baz is 16
bytes below it.
The problem is that at the first call _Z3fooii in bar -fa-u-t computed
args_size
8, while without -fa-u-t it is 16. The first call _Z3baziiiiiii has wrong
args_size too (with -fa-u-t 28, without -fa-u-t 32). The second call _Z3fooii
already has the same args_size between the two (16) and second call
_Z3baziiiiiii
too (in both cases 32).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36419